When you setup your Google Custom Domain, you enjoy the personal satisfaction of having your own non BlogSpot URL.
You publish your blog to a non-Blog*Spot URL on a Google server, and your BlogSpot addresses still works. This setup lets people and processes like search engine spiders continue to find your blog in BlogSpot, while you enjoy your non BlogSpot URL.
You define your domain, and how the content is hosted, using a series of "A" and "CNAME" referrals, pointing to Google. Before you can do that, your registrar has to define how the domain is hosted, using a series of "NS", SOA, and related records.
The latter task lets your registrar maintain your domain, and hundreds of others - with each domain sharing their servers, reliably.
Sometimes, even righteous DNS addresses don't result in an accessible blog, when published to the domain.
If the domain is improperly setup, we can't diagnose the problems.
This domain needs to be returned to the registrar, for their action.
The online service IntoDNS is used to diagnose domain setup problems - but some problems even they can't identify. The registrar has to fix this problem.
Here's what I might see, in a Dig log for my domain "nitecruzr.net".
Before I could define the Google servers "216.239.32.21", "216.239.34.21", "216.239.36.21", and "216.239.38.21" as hosting the domain content, my registrar had to define the domain itself to the Internet. Essential domain entries are the "SOA" and the 2 "NS" records.
If my registrar had not setup my domain properly, I might have seen other results.
You publish your blog to a non-Blog*Spot URL on a Google server, and your BlogSpot addresses still works. This setup lets people and processes like search engine spiders continue to find your blog in BlogSpot, while you enjoy your non BlogSpot URL.
You define your domain, and how the content is hosted, using a series of "A" and "CNAME" referrals, pointing to Google. Before you can do that, your registrar has to define how the domain is hosted, using a series of "NS", SOA, and related records.
The latter task lets your registrar maintain your domain, and hundreds of others - with each domain sharing their servers, reliably.
Sometimes, even righteous DNS addresses don't result in an accessible blog, when published to the domain.
If the domain is improperly setup, we can't diagnose the problems.
This domain needs to be returned to the registrar, for their action.
The online service IntoDNS is used to diagnose domain setup problems - but some problems even they can't identify. The registrar has to fix this problem.
Here's what I might see, in a Dig log for my domain "nitecruzr.net".
; <<>> DiG 9.3.2 <<>> @ns54.domaincontrol.com nitecruzr.net ANY ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32937 ;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;nitecruzr.net. IN ANY ;; ANSWER SECTION: nitecruzr.net. 86400 IN SOA ns53.domaincontrol.com. dns.jomax.net. 2008032400 28800 7200 604800 86400 nitecruzr.net. 3600 IN A 216.239.32.21 nitecruzr.net. 3600 IN A 216.239.34.21 nitecruzr.net. 3600 IN A 216.239.36.21 nitecruzr.net. 3600 IN A 216.239.38.21 nitecruzr.net. 3600 IN NS ns53.domaincontrol.com. nitecruzr.net. 3600 IN NS ns54.domaincontrol.com. nitecruzr.net. 604800 IN MX 10 aspmx.l.google.com. nitecruzr.net. 604800 IN MX 20 alt1.aspmx.l.google.com. nitecruzr.net. 604800 IN MX 30 alt2.aspmx.l.google.com. nitecruzr.net. 604800 IN MX 40 aspmx2.googlemail.com. nitecruzr.net. 604800 IN MX 50 aspmx4.googlemail.com. nitecruzr.net. 604800 IN MX 50 aspmx5.googlemail.com. nitecruzr.net. 604800 IN MX 50 aspmx3.googlemail.com. ;; Query time: 152 msec ;; SERVER: 208.109.255.27#53(208.109.255.27) ;; WHEN: Wed Jan 28 04:19:13 2009 ;; MSG SIZE rcvd: 394
Before I could define the Google servers "216.239.32.21", "216.239.34.21", "216.239.36.21", and "216.239.38.21" as hosting the domain content, my registrar had to define the domain itself to the Internet. Essential domain entries are the "SOA" and the 2 "NS" records.
If my registrar had not setup my domain properly, I might have seen other results.
; <<>> DiG 9.3.2 <<>> @localhost myfictiousdomain.com ANY ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61551 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;myfictiousdomain.com. IN ANY ;; AUTHORITY SECTION: com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1233112405 1800 900 604800 900 ;; Query time: 35 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jan 28 04:13:42 2009 ;; MSG SIZE rcvd: 111Here, we see that "myfictiousdomain.com" doesn't exist, excepting in my mind. In this case, we get the "SOA" record for the ".com" TLD.
; <<>> DiG 9.3.2 <<>> @localhost myfictiousdomain.com ANY ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5712 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;myfictiousdomain.com. IN ANY ;; AUTHORITY SECTION: myfictiousdomain.com. 1800 IN SOA dns1.name-services.com. info.name-services.com. 2002050701 10001 1801 604801 181 ;; Query time: 111 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Aug 28 15:41:10 2009 ;; MSG SIZE rcvd: 94Here we see that "myfictiousdomain.com" was registered by eNom ("name-services.com" is an eNom domain), but no DNS addresses have been setup.
; <<>> DiG 9.3.2 <<>> @localhost myfictiousdomain.com ANY ; (2 servers found) ;; global options: printcmd ;; connection timed out; no servers could be reachedHere, we see that "myfictiousdomain.com" is apparently defined to the Internet, but the name servers provided by the registrar are improperly setup, or are simply not responding. In neither of the latter cases will you have a working domain. You, and your readers, will see (yet again)
Server Not Found Error 404or a similar error. Please, know your responsibilities, and your registrar's responsibilities.
Comments