eNom Hosted Custom Domains Showing Intermittent Connectivity Issues

We are seeing reports from owners of several Blogger blogs, published to custom domains, of intermittent connectivity problems, reported in Blogger Help Forum: Something Is Broken.

Recently, I have been unable to load my custom domain blog www.mydomain.com. My browsers (whether Chrome, Firefox, Safari, etc.) all tell me they are "unable to find the server". Various online utilities report problems also. I am able to get to Blogger and my dashboard for the blog, but nothing will load the page. All other services on my computer appear to be working normally.

The problem appears to be somewhat intermittent and varying across different ISPs, and various online utilities which I use.

The domains being reported all appear to be registered with eNom - and at first glance, domain registration appears normal. We have to do some detailed investigation to identify a consistent detail, which appears to be common to all individually reported domains.

At first glance, the typical eNom registered domain - even those with this reported problem - appears to be normal.

REGISTRY WHOIS FOR mydomain.com

Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
Status: clientTransferProhibited

Expiration Date: 2013-04-10
Creation Date: 2012-04-10
Last Update Date: 2012-04-10

Name Servers:
    dns1.name-services.com
    dns2.name-services.com
    dns3.name-services.com
    dns4.name-services.com
    dns5.name-services.com

The clue to this problem is seen in the last sentence, in the above example.

The problem appears to be somewhat intermittent and varying across different ISPs, and various online utilities which I use.

eNom uses 5 DNS servers. We can check the output from each of the 5 servers, using the Kloth online Dig utility, and specifying each server, in turn.

• Domain: mydomain.com
• Server: dns1.name-services.com
• Query: A (IPv4 address)

and repeat for dns2.name-services.com etc.

Running a Dig against each of the 5 servers, we can see a consistency problem. Here is a copy of the 5 Dig logs, concatenated.

-----------------------------------------------------------------------
     
dns1.name-services.com Dig Log

 ; <<>> DiG 9.3.2 <<>> @dns1.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43536
 ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; ANSWER SECTION:
 mydomain.com. 1800 IN A 216.239.32.21
 mydomain.com. 1800 IN A 216.239.34.21
 mydomain.com. 1800 IN A 216.239.36.21
 mydomain.com. 1800 IN A 216.239.38.21
 
 ;; AUTHORITY SECTION:
 mydomain.com. 3600 IN NS dns1.name-services.com.
 mydomain.com. 3600 IN NS dns2.name-services.com.
 mydomain.com. 3600 IN NS dns3.name-services.com.
 mydomain.com. 3600 IN NS dns4.name-services.com.
 mydomain.com. 3600 IN NS dns5.name-services.com.
 
 ;; ADDITIONAL SECTION:
 dns1.name-services.com. 3600 IN A 98.124.192.1
 dns2.name-services.com. 3600 IN A 98.124.197.1
 dns3.name-services.com. 3600 IN A 98.124.193.1
 dns4.name-services.com. 3600 IN A 98.124.194.1
 dns5.name-services.com. 3600 IN A 98.124.196.1

-----------------------------------------------------------------------
     
dns2.name-services.com Dig Log
    
 ; <<>> DiG 9.3.2 <<>> @dns2.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51481
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; ANSWER SECTION:
 mydomain.com. 1800 IN A 216.239.36.21
 mydomain.com. 1800 IN A 216.239.32.21
 mydomain.com. 1800 IN A 216.239.38.21
 mydomain.com. 1800 IN A 216.239.34.21

-----------------------------------------------------------------------
     
dns3.name-services.com Dig Log

 ; <<>> DiG 9.3.2 <<>> @dns3.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9542
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; AUTHORITY SECTION:
 com.   3601 IN SOA dns1.name-services.com. info.name-services.com. 2010 10001 1801 604801 181

-----------------------------------------------------------------------
     
dns4.name-services.com Dig Log
 

 ; <<>> DiG 9.3.2 <<>> @dns4.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2101
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; AUTHORITY SECTION:
 com.   3601 IN SOA dns1.name-services.com. info.name-services.com. 2010 10001 1801 604801 181

-----------------------------------------------------------------------
     
dns5.name-services.com Dig Log
 
 ; <<>> DiG 9.3.2 <<>> @dns5.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13658
 ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; ANSWER SECTION:
 mydomain.com. 1800 IN A 216.239.32.21
 mydomain.com. 1800 IN A 216.239.34.21
 mydomain.com. 1800 IN A 216.239.36.21
 mydomain.com. 1800 IN A 216.239.38.21
 
 ;; AUTHORITY SECTION:
 mydomain.com. 3600 IN NS dns1.name-services.com.
 mydomain.com. 3600 IN NS dns2.name-services.com.
 mydomain.com. 3600 IN NS dns3.name-services.com.
 mydomain.com. 3600 IN NS dns4.name-services.com.
 mydomain.com. 3600 IN NS dns5.name-services.com.
 
 ;; ADDITIONAL SECTION:
 dns1.name-services.com. 3600 IN A 98.124.192.1
 dns2.name-services.com. 3600 IN A 98.124.197.1
 dns3.name-services.com. 3600 IN A 98.124.193.1
 dns4.name-services.com. 3600 IN A 98.124.194.1
 dns5.name-services.com. 3600 IN A 98.124.196.1

-----------------------------------------------------------------------

Examine the Dig logs from "dns3.name-services.com." and "dns3.name-services.com.". See the answer from those servers, which returns only an "SOA" for the ".com" Top Level Domain? This is consistent of a domain, improperly setup by the registrar. In the cases reported in Blogger Help Forum: Something Is Broken, my reply is simple.

In your case, servers #3 and #4 do not appear to properly recognise your domain. Any online service, asking either server #3 or #4 for your domain addresses, will probably have problems. This may explain your inconsistent access problem. As the registered domain owner, you need to contact eNom Customer Support. Show them the Dig logs from the 5 servers, and ask them why servers #3 and #4 seem to have a problem serving your DNS addresses.

The problem appears to involve domains setup on 4/9/2012 - 4/10/2012. Hopefully, enough domain owners will report their problems to eNom Customer Support, so this problem can be investigated and resolved.

---

(Update 6/18): With a small but very intense BloggerFire which involves eNom hosted domains and apparent domain hijackings, we now have a useful diagnostic tool, to analyse DNS inconsistencies like this.

---

>> Top

After Setting Up Your Custom Domain DNS Addresses, Always Verify Your Work

So many problems with custom domain publishing start with incorrectly setup DNS addresses. Sometimes the problems start with misunderstanding about the rigid requirements of DNS addresses, other times misunderstanding about how to use the Domain Manager tools provided - and sometimes the registrar gets involved, and causes problems.

Many times, I'll offer advice in Blogger Help Forum: Something Is Broken, and the reply will indicate the confusion.

Here's a screenshot of my settings - I can't see a problem!

or

I just got my registrar to setup the DNS addresses, as you gave me. Surely, they are right?

But we diagnose the problem, and find that the addresses are still wrong.

In business, we learn of the importance of using well known, standard testing procedures. People setting up a custom domain would do well to learn this concept, also.

I have a diverse assortment of online tools, which I use for diagnosing custom domain publishing problems. Here are three (as always, in alphabetical order), which I use to examine and verify DNS addresses.

• Kloth Dig.
• Name.com Dig / Who.Is Lookup.
• WebMaster Toolkit Dig.

Each tool complements the other two - none of them are a replacement for the other two.

Kloth Dig

• Lets you copy and paste the output, easily.
• Lets you Dig the domain root, or any specific aliases.
• Lets you select what host to perform the Dig.

Name.com Dig / Who.Is Lookup

• Lets you check results promptly, not waiting for TTL to expire.
• Lets you reference the result using an included URL.
• Lets you do a Who Is lookup, to complement the Dig.

WebMaster Toolkit Dig

• Lets you copy and paste the output, easily.
• Lets you Dig the domain root, or any specific aliases.
• Lets you reference the result using an included URL.

Prompt Verification Is Essential.
When you make changes to the DNS addresses, you will want to check your results, promptly - waiting for DNS cache to expire, varying according to TTL, causes confusion. The Name.com Dig accesses the domain master server, so you can generally see results promptly. To cross check the Name.com Dig, you can use the Kloth Dig - and reference the domain master server, explicitly.

All Domain Hosts Must Be Verified.
When you make changes to a Non Root Virtual Host, you'll need to Dig the results. Both Kloth and WebMaster Toolkit let you specify the host name, to target in the Dig, so you can target any host - not just the domain root and "www" aliases.

Ability To Copy And Paste Results Is Useful.
It is useful to copy and paste the results from any Dig transaction. Both Kloth and WebMaster Toolkit Digs provide results that are not table bound, and can be easily copied and pasted.

Ability To Reference The Result In The URL Is Useful.
It is useful to save a one click link to check Dig results, to avoid having to repeatedly paste or type a domain URL to be checked. Both Name.com and WebMaster Toolkit provide results that can be checked by clicking on a link, which you can bookmark.

A WhoIs Lookup Is Useful
Many times, the domain status, examined using a WhoIs lookup, provides an essential clue. Both when a domain purchase is unsuccessful, and when a domain registration has expired, a Name.com Who.Is Lookup will lead to the problem diagnosis.

Each of these tools provide vital details and features, that the others do not provide. And each of these tools, used properly, can help somebody to avoid posting in Blogger Help Forum: Something Is Broken, frantically asking for help.

>> Top

Custom Domains Redirecting To Google Sites

Similar to a redirection to the Google Apps Start Page service, some custom domains will be found to be directed to Google Sites. Again, we'll see an apparently normal (asymmetrical) DNS address configuration.

mydomain.net.            3600    IN      A       216.239.32.21
mydomain.net.            3600    IN      A       216.239.34.21
mydomain.net.            3600    IN      A       216.239.36.21
mydomain.net.            3600    IN      A       216.239.38.21
www.mydomain.net.      3600    IN      CNAME   ghs.google.com.
---
ghs.google.com.         282206  IN      CNAME   ghs.l.google.com.
ghs.l.google.com.       300     IN      A       74.125.43.121 

The diagnosis, again, will be made using an (abbreviated) HTTP trace.

Sending request:

GET / HTTP/1.1
Host: mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://www.mydomain.net(CR)(LF)

Sending request:

GET / HTTP/1.1
Host: www.mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://sites.google.com/a/mydomain.com/sites/system/app/pages/meta/domainWelcome(CR)(LF)

Unlike the generically known "Server Not Found Error 404" symptom, this one won't be solved by merely publishing back to Blog*Spot, then re publishing to the custom domain.

What we see here is that Sites, similar to Start Page, is apparently enabled, and published to "www.mydomain.net". In this case, you're going to first have to disable Sites. If you don't, you're going to see another old friend

Another blog is already hosted at this address.

After doing that, then you can publish back to Blog*Spot, then re publish to the custom domain.

A second variation on this redirect may not start with an explicit "Server Not Found Error 404", and the HTTP trace will be slightly different. You will probably see "Another blog is already hosted at this address." in the usual places.

Sending request:

GET / HTTP/1.1
Host: mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Connection: close

• Finding host IP address...
• Host IP address = 216.239.34.21
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://www.mydomain.net(CR)(LF)

Sending request:

GET / HTTP/1.1
Host: www.mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·200·OK(CR)(LF)

(Here is a short excerpt of the rest of the trace -
you have to look carefully for these clues)

<body·xmlns="http://www.google.com/ns/jotspot"·id="body"·class="·en">(LF)
<div·id="sites-page-toolbar">(LF)
<div·id="sites-status"·class="sites-status"·style="display:none;">(LF)
<div·id="sites-notice"·class="sites-notice">·</div>(LF)
</div>(LF)
</div>(LF)
<div·id="sites-chrome-everything"·style="direction:·ltr">(LF)
<div·id="sites-chrome-page-wrapper">(LF)
<div·id="sites-chrome-page-wrapper-inside">(LF)
<div·xmlns="http://www.w3.org/1999/xhtml"·id="sites-chrome-header-wrapper">(LF)

As shown immediately above, we have Google Sites involved, though less obviously. Resolution of this scenario, too, seems to involve disabling Sites. After doing that, you will likewise need to publish back to Blog*Spot, then re publish to the custom domain.

>> Top

Diagnosing Problems With Custom Domains: An Alternative Dig Tool

As I wrote earlier, when I'm diagnosing a problem with a custom domain - and occasionally, with other blog and network problems - my most frequently used tool is a Kloth online Dig. With Dig being an important diagnostic procedure, it's a good idea to have more than one Dig utility available.

• The Kloth server may be down.
• The Kloth server may not offer the right options.
• It's good practice to occasionally (and sometimes, intentionally) cross check results against another server.

For many Dig investigations, I like to use a second online Dig service - WhoIs, provided by All-NetTools. The All-NetTools WhoIs Dig actually provides more than a standard Dig. A WhoIs Dig, for a domain, provides much valuable information about the domain / registrar relationship. Here, for instance, we can see an All-NetTools WhoIs Dig for this domain, nitecruzr.net.

http://www.who.is/whois/nitecruzr.net/

REGISTRY WHOIS FOR NITECRUZR.NET

Domain Name: nitecruzr.net

Registrar: GODADDY.COM, INC.
Whois Server: whois.godaddy.com
Referral URL: http://registrar.godaddy.com
Status: clientDeleteProhibited, clientRenewProhibited, 
clientTransferProhibited, clientUpdateProhibited

Expiration Date: 2010-03-24
Creation Date: 2008-03-24
Last Update Date: 2009-05-01

Name Servers:
ns11.domaincontrol.com
ns12.domaincontrol.com
ns53.domaincontrol.com
ns54.domaincontrol.com

Here, we see useful information about this domain, including the fact that it expires within the month. In cases where the domain in question is seen to be parked, knowing that a domain recently expired helps us advise a blogger that it's necessary to contact the registrar immediately, and avoid loss of domain registration.

A an All-NetTools DNS Dig against nitecruzr.net provides still more interesting and useful information.

http://www.who.is/dns/nitecruzr.net/

The WhoIs SOA Dig shows us the SOA record.

NITECRUZR.NET SOA RECORD
Name Server  ns11.domaincontrol.com
Email   (masked)
Serial Number  2009121603
Refresh  8 hours
Retry   2 hours
Expiry   7 days
Minimum  1 day

Here, we see the name of the domain master server, and the various expiry times for the domain.

The Whois DNS Dig shows us the well known host records.

NITECRUZR.NET DNS RECORDS
Record  Type   TTL  Priority  Content
mail.nitecruzr.net  CNAME  1 hour   ghs.google.com
nitecruzr.net   A  1 hour   216.239.36.21 (Mountain View, CA, US)
nitecruzr.net   A  1 hour   216.239.32.21 (Mountain View, CA, US)
nitecruzr.net   A  1 hour   216.239.34.21 (Mountain View, CA, US)
nitecruzr.net   A  1 hour   216.239.38.21 (Mountain View, CA, US)
nitecruzr.net   MX  1 hour  10  aspmx.l.google.com
nitecruzr.net   MX  1 hour  20  alt1.aspmx.l.google.com
nitecruzr.net   MX  1 hour  30  alt2.aspmx.l.google.com
nitecruzr.net   MX  1 hour  40  aspmx2.googlemail.com
nitecruzr.net   MX  1 hour  50  aspmx3.googlemail.com
nitecruzr.net   NS  1 hour   ns11.domaincontrol.com
nitecruzr.net   NS  1 hour   ns12.domaincontrol.com
nitecruzr.net   NS  1 hour   ns53.domaincontrol.com
nitecruzr.net   NS  1 hour   ns54.domaincontrol.com
nitecruzr.net   SOA  1 day   ns11.domaincontrol.com. dns.jomax.net. 2009121603 28800 7200 604800 86400
www.nitecruzr.net  CNAME  1 hour   ghs.google.com

This will never replace the Kloth Dig log, completely. The Kloth server offers many more options, such as the ability to selectively Dig against aliases besides the domain root and well known aliases. It is a worthy complement to a Kloth Dig in many cases, and can be used as a backup or cross check.

>> Top

Diagnosing Problems With Custom Domains - Case Study #8

Some time ago, I noted a technique being used by Blogger to combat the spread of spam blog referrals, which was creating some inconvenience for legitimate blogs using custom domains.

That inconvenience seems to continue, even today. A prettier display, but the same inconvenience.


This isn't good for your readers - nobody wants to surf to possibly malicious content - intentionally or otherwise. Nor is it good for your search engine reputation - this extra page will stop the spiders cold. Check your Google Webmaster Tools Logs if you see this one day, if you don't believe me.



Let's look at the browser logs for myblog, and mydomain.

7/14/2008 09:24:54  Trying http://myblog.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Date: Mon, 14 Jul 2008 16:24:56 GMT
Expires: Mon, 14 Jul 2008 16:24:56 GMT
Cache-Control: private, max-age=0
Content-Length: 3473
Content-Type: text/html
Server: GFE/1.3
Connection: Close

Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Date: Mon, 14 Jul 2008 16:24:58 GMT
Expires: Mon, 14 Jul 2008 16:24:57 GMT
Cache-Control: private, max-age=0
Content-Length: 3473
Content-Type: text/html
Server: GFE/1.3
Connection: Close

Neither redirect contains the new location, so the search engines won't update their records to indicate your new custom domain. That's not going to give your new URL any reputation at all.

Compare that with the log for this blog, "bloggerstatusforreal.blogspot.com".

7/14/2008 09:30:01  Trying http://bloggerstatusforreal.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://blogging.nitecruzr.net/
Content-Type: text/html; charset=UTF-8
Date: Mon, 14 Jul 2008 16:30:04 GMT
Expires: Mon, 14 Jul 2008 16:30:04 GMT
Cache-Control: private, max-age=0
Content-Length: 212
Server: GFE/1.3
Connection: Close

See the "301 Moved Permanently" here?

HTTP/1.0 301 Moved Permanently
Location: http://blogging.nitecruzr.net/

That's where the search engines pick up my new URL - "blogging.nitecruzr.net". And that's one of the benefits of having a properly operating custom domain.

>> Top

Diagnosing Problems With Custom Domains - Case Study #7

Google Apps, which I originally identified in my second custom domain case study, and later in a separate article, Custom Domain Publishing, And Google Apps, is what I shall call a Web Services Aggregator. Google Apps gives us the ability to combine a Blogger blog using a non-BlogSpot URL in a domain with other Google and non-Google services.

Google Apps is not the only web services aggregator that we have identifed recently. Yahoo provides a similar setup.

Let's look at a Yahoo Web Services setup, using a hypothetical domain, "mydomain.net" (name changed here to protect the unfortunate).

First, let's dig the DNS records for the primary domain "mydomain.net".

 ;; QUESTION SECTION:
 ;mydomain.net.   IN A
 
 ;; ANSWER SECTION:
 mydomain.net.  1200 IN A 68.180.151.21
 mydomain.net.  1200 IN A 68.180.151.22
 mydomain.net.  1200 IN A 68.180.151.23
 mydomain.net.  1200 IN A 68.180.151.24
 mydomain.net.  1200 IN A 68.180.151.25
 mydomain.net.  1200 IN A 68.180.151.26

p2w12.geo.sp1.yahoo.com (68.180.151.21)
68.180.128.0 - 68.180.255.255
Yahoo 

Next, the "www" alias "www.mydomain.net".

 ;; QUESTION SECTION:
 ;www.mydomain.net.   IN A
 
 ;; ANSWER SECTION:
 www.mydomain.net.  600 IN CNAME ghs.google.com.
 ghs.google.com.  40765 IN CNAME ghs.l.google.com.
 ghs.l.google.com. 300 IN A 72.14.207.121

You'll have no problem with publishing to "www.mydomain.net", as the primary URL for "mydomain.net". I don't think that Yahoo Web Services provides an option to "Redirect mydomain.net to www.mydomain.net.", though.

Yahoo provides 6 servers, in contrast to 3 provided by Google. To date, nobody has succeeded in configuring the 6 Yahoo servers to address anything but Yahoo content. This makes Yahoo Web Services useless for using the primary domain in a Google Custom Domain.

>> Top

Diagnosing Problems With Custom Domains - Case Study #6

In my previous custom domain case study, I presented a poorly working custom domain, where the "www" alias was properly setup, but the primary domain was using URL forwarding. Maybe it's a setup recommended by the DNS host technical support staff, who don't support "CNAME" referral for the primary domain.

Some DNS hosts just don't understand "CNAME" referrals, and the previous case doesn't show how badly domains can be setup.

Let's look at one case, again a fictional example "mydomain.com", setup using the "Advanced Settings" wizard.

There are 4 URLs to study here.

1. The primary domain "mydomain.com".
2. The "www" alias for the domain "www.mydomain.com".
3. The primary BlogSpot URL "myblog.blogspot.com".
4. The "www" alias for the BlogSpot URL "www.myblog.blogspot.com".

First, let's dig the DNS records for the primary domain "mydomain.com".

;; QUESTION SECTION:
;mydomain.com. IN A

;; ANSWER SECTION:
mydomain.com. 3600 IN A 64.202.189.170

Next, the "www" alias "www.mydomain.com".

;; QUESTION SECTION:
;www.mydomain.com. IN A

;; ANSWER SECTION:
www.mydomain.com. 3600 IN CNAME mydomain.com.
mydomain.com. 3600 IN A 64.202.189.170

And examine "64.202.189.170".

pwfwd-v01.prod.mesa1.secureserver.net (64.202.189.170)
64.202.160.0 - 64.202.191.255
GoDaddy.com, Inc.

The latter is using URL forwarding, to redirect "mydomain.com" to "myblog.blogspot.com", plus using a "CNAME" referral to direct "www.mydomain.com" to "mydomain.com" (and the URL forwarding). URL forwarding is preferred by some DNS hosts, who prefer to not to provide "CNAME" referral, but it's wrong when used in a custom domain setup. For Google Custom Domains, it will probably work, for a while, but unreliably so. Even if it works for a while, it will potentially cause problems, for everybody.

>> Top

Diagnosing Problems With Custom Domains - Case Study #5

In my first 4 custom domain case studies, I presented working, or semi-working domains, each being a case where the domain owner appeared to have tried to setup the domain properly. By action of the DNS host, or maybe of the Blogger wizard, some of the cases didn't exemplify proper setup, but the owner at least tried to do properly.

In some cases, maybe through ignorance, or stubborness, the owner will simply ignore instruction, and do his own thing. Sometimes, the setup will work, but it will still be wrong. Maybe it's a setup recommended by the DNS host technical support staff.

Let's look at one case, again a fictional example "mydomain.com", setup using the "Advanced Settings" wizard.

There are 4 URLs to study here.

1. The primary domain "mydomain.com".
2. The "www" alias for the domain "www.mydomain.com".
3. The primary BlogSpot URL "myblog.blogspot.com".
4. The "www" alias for the BlogSpot URL "www.myblog.blogspot.com".

First, let's dig the DNS records for the primary domain "mydomain.com".

;; QUESTION SECTION:
;mydomain.com. IN A

;; ANSWER SECTION:
mydomain.com. 3600 IN A 64.202.189.170

Next, the "www" alias "www.mydomain.com".

;; QUESTION SECTION:
;www.mydomain.com. IN A

;; ANSWER SECTION:
www.mydomain.com. 3600 IN CNAME ghs.google.com.
ghs.google.com. 364681 IN CNAME ghs.l.google.com.
ghs.l.google.com. 300 IN A 72.14.207.121

And examine "64.202.189.170".

pwfwd-v01.prod.mesa1.secureserver.net (64.202.189.170)
64.202.160.0 - 64.202.191.255
GoDaddy.com, Inc.

The latter is using URL forwarding, to redirect "mydomain.com" to "myblog.blogspot.com". URL forwarding is preferred by some DNS hosts, who prefer to not to provide "CNAME" referral for the primary domain, but it's wrong when used in a custom domain setup. For Google Custom Domains, it will partially work, for a while, but unreliably at best. Even if it works for a while, it will potentially cause problems, for everybody.

>> Top

Diagnosing Problems With Custom Domains - Case Study #2b

Encouraged by my ability to setup my own personal custom domain, I persuaded my bud Bob to do likewise. Now, Bob isn't a techie (so he would tell you), but he does know how to follow procedure. And I encouraged him to try it.

its easier than it looks

So, just last night, Bob tells me in his usual taciturn way

OK - It's http://robertosblogs.net

then later

EXACTLY the way you described in your post

But - and it seems like there's always a "but" with Blogger - the results were not quite the same.


Let's take a look at "robertosblogs.net".

There are 4 URLs to study here.

1. The primary domain "robertosblogs.net".
2. The "www" alias for the domain "www.robertosblogs.net".
3. The primary BlogSpot URL "roberto-dot-net.blogspot.com".
4. The "www" alias for the BlogSpot URL "www.roberto-dot-net.blogspot.com".

I started by examining his DNS setup. First, the primary domain "robertosblogs.net".

;; QUESTION SECTION:
;robertosblogs.net. IN A

;; ANSWER SECTION:
robertosblogs.net. 3600 IN A 64.233.179.121
robertosblogs.net. 3600 IN A 66.249.81.121
robertosblogs.net. 3600 IN A 72.14.207.121

Next, the "www" alias "www.robertosblogs.net".

;; QUESTION SECTION:
;www.robertosblogs.net. IN A

;; ANSWER SECTION:
www.robertosblogs.net. 3600 IN CNAME ghs.google.com.
ghs.google.com. 520167 IN CNAME ghs.l.google.com.
ghs.l.google.com. 300 IN A 72.14.207.121

DNS looks just like my results. Spot on, Bob.

Look at the browser connect logs. Start with the "www" alias.

4/5/2008 23:26:56 Trying http://www.robertosblogs.net
Header:
HTTP/1.0 200 OK
Content-Type: text/html; charset=UTF-8

OK, here.

4/5/2008 23:26:28 Trying http://robertosblogs.net
Redirect!
Header:
HTTP/1.0 302 Moved Temporarily
Location: http://www.robertosblogs.net
Content-Type: text/html; charset=UTF-8

This looks good too. The key item here being

HTTP/1.0 302 Moved Temporarily
Location: http://www.robertosblogs.net

The BlogSpot results though, not so good. At least, not consistent with mine.

4/5/2008 23:31:12 Trying http://roberto-dot-net.blogspot.com
Header:
HTTP/1.0 200 OK
Content-Type: text/html; charset=UTF-8

look at my BlogSpot

3/29/2008 08:56:48 Trying http://nitecruzr-dot-net.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.nitecruzr.net/
Content-Type: text/html; charset=UTF-8

And his "www" BlogSpot is the same.

4/5/2008 23:44:46 Trying http://www.roberto-dot-net.blogspot.com
Header:
HTTP/1.0 200 OK
Content-Type: text/html; charset=UTF-8

contrasted with mine

3/29/2008 08:56:38 Trying http://www.nitecruzr-dot-net.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.nitecruzr.net/
Content-Type: text/html; charset=UTF-8

And what is very interesting is the link to the blog, from the dashboard!

Roberto Dot Net        View Blog

which leads to a rather intriguing advice

Your blog is in transition

Your blog's new address is http://www.robertosblogs.net/. Since it takes time for this new address to be available all over the Internet, you can still get to it at http://roberto-dot-net.blogspot.com.

Your new address should work for everyone after at most 3 days. At that time we will redirect your readers from your old address to the new one.

Stay tuned, or use the above link ("Roberto Dot Net") from time to time. This will be interesting to watch. I made the above observations, initially, at 23:00 PST, 5/4/2008. It's now 08:00 PDT, 7/4/2008, and the results are the same.

Your blog is in transition

>> (Update 4/26): After much thought, and several interesting discussions in Google Blogger Help, I conclude that the "In Transition" period is simply Blogger allowing the "Buy A Domain" wizard to compensate for DNS latency.

>> (Update 4/9): We see now that Blogger has mentioned this possibility, in How do I buy a custom domain through Blogger?

>> (Update 22:00 4/8): The Roberto Dot Net dashboard link now links directly to Roberto Dot Net.

>> Forum thread links: bX-*00074

>> Copy this tag: bX-*00074

>> Top

Diagnosing Problems With Custom Domains - Case Study #4

In my first 2 custom domain case studies, I presented actual custom domains - all setup and working. Neither of those exemplify all custom domain setups though. In my 3rd post in this series, Diagnosing Problems With Custom Domains - Case Study #3, I showed a custom domain setup that was not only asymmetrical but incomplete. Here's a variation on that, where the primary domain isn't even defined in DNS.

Let's take a look at a fictional example "mydomain.com", setup using the "Advanced Settings" wizard.

There are 4 URLs to study here.

1. The primary domain "mydomain.com".
2. The "www" alias for the domain "www.mydomain.com".
3. The primary BlogSpot URL "myblog.blogspot.com".
4. The "www" alias for the BlogSpot URL "www.myblog.blogspot.com".

First, let's dig the DNS records for the primary domain "mydomain.com".

;; QUESTION SECTION:
;mydomain.com. IN A

;; ANSWER SECTION:
mydomain.com. 86400 IN SOA ns53.domaincontrol.com. dns.jomax.net. 2008032400 28800 7200 604800 86400

Next, the "www" alias "www.mydomain.com".

;; QUESTION SECTION:
;www.mydomain.com. IN A

;; ANSWER SECTION:
www.mydomain.com. 3600 IN CNAME ghs.google.com.
ghs.google.com. 586847 IN CNAME ghs.l.google.com.
ghs.l.google.com. 203 IN A 72.14.207.121

This is different from my previous case study.

mydomain.com. 3600 IN A 68.178.232.100
www.mydomain.com. 3600 IN CNAME ghs.google.com.

Here, only the "www" alias is defined at all - using a "CNAME". You should be able to publish to the "www" alias, but the primary domain just won't exist.

Now, let's look at browser connect logs. First, this is what we get for the primary domain "mydomain.com".

3/29/2008 08:50:42 Trying http://mydomain.com
Invalid Host

No DNS entry = "Invalid Host.

Next, the "www" alias "www.mydomain.com".

3/29/2008 08:50:17 Trying http://www.mydomain.com
Header:
HTTP/1.0 200 OK
Content-Type: text/html; charset=UTF-8

Here, we should see the content of the blog, simply labeled "www.mydomain.com".

Now, let's look at the BlogSpot URLs.

3/29/2008 08:56:48 Trying http://myblog.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.mydomain.com/
Content-Type: text/html; charset=UTF-8

Here, we should see the same content as above, simply labeled "www.mydomain.com".

and

3/29/2008 08:56:38 Trying http://www.myblog.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.mydomain.com/
Content-Type: text/html; charset=UTF-8

Here too, we should see the same content as immediately above, simply labeled "www.mydomain.com".

Both "myblog.blogspot.com" and "www.myblog.blogspot.com" redirect to "www.mydomain.com", again as in the previous study. Since no access to the blog, using the primary domain URL, is possible, this too is an incomplete result.

It's possible that proper DNS server configuration may transform an asymmetrical and incomplete scenario into an asymmetrical and complete one - that is - access to the blog through the primary domain URL.

>> Top

Diagnosing Problems With Custom Domains - Case Study #3

In my first 2 custom domain case studies, I presented actual custom domains - all setup and working. Neither of those exemplify all custom domain setups though. In my previous post in this series, Diagnosing Problems With Custom Domains - Case Study #2, I showed a custom domain setup using the the "Buy A Domain For Your Blog" wizard. Not too long ago, one setup that way would be not only asymmetrical but incomplete.

Let's take a look at a fictional example "mydomain.com", setup when the the "Buy A Domain For Your Blog" wizard was first provided.

There are 4 URLs to study here.

1. The primary domain "mydomain.com".
2. The "www" alias for the domain "www.mydomain.com".
3. The primary BlogSpot URL "myblog.blogspot.com".
4. The "www" alias for the BlogSpot URL "www.myblog.blogspot.com".

First, let's dig the DNS records for the primary domain "mydomain.com".

;; QUESTION SECTION:
;mydomain.com. IN A

;; ANSWER SECTION:
mydomain.com. 3600 IN A 68.178.232.100

Next, the "www" alias "www.mydomain.com".

;; QUESTION SECTION:
;www.mydomain.com. IN A

;; ANSWER SECTION:
www.mydomain.com. 3600 IN CNAME ghs.google.com.
ghs.google.com. 586847 IN CNAME ghs.l.google.com.
ghs.l.google.com. 203 IN A 72.14.207.121

This is different from my previous case study.

mydomain.com. 3600 IN A 68.178.232.100
www.mydomain.com. 3600 IN CNAME ghs.google.com.

Here, only the "www" alias is using a "CNAME", and the wizard automatically publishes the blog to that. In this case, to "www.mydomain.com".

Let's do a Whois lookup on "68.178.232.100", the IP address pointed to by "mydomain.com".

parkwebwin-v01.prod.mesa1.secureserver.net (68.178.232.100)
68.178.128.0 - 68.178.255.255
GoDaddy.com, Inc.

In this case, we will only be able to publish to the "www" alias, "www.mydomain.com". Unless we do some custom DNS work, the primary domain "mydomain.com" will simply redirect to a parked page (the "parkwebwin" servers in GoDaddy name space, for instance).

mydomain.com
This page is parked free, courtesy of GoDaddy.com.

or maybe

Were you looking for mydomain.com?
It's currently being setup, courtesy of GoDaddy.com.

Now, let's look at browser connect logs. First, this is what we get for the primary domain "mydomain.com".

3/29/2008 08:50:42 Trying http://mydomain.com
Header:
HTTP/1.0 200 OK
Content-Type: text/html; charset=UTF-8

Of course, the content shown will be the parked page (immediately above).

Next, the "www" alias "www.mydomain.com".

3/29/2008 08:50:17 Trying http://www.mydomain.com
Header:
HTTP/1.0 200 OK
Content-Type: text/html; charset=UTF-8

Here, we should see the content of the blog, simply labeled "www.mydomain.com".

Now, let's look at the BlogSpot URLs.

3/29/2008 08:56:48 Trying http://myblog.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.mydomain.com/
Content-Type: text/html; charset=UTF-8

Here, we should see the same content as above, simply labeled "www.mydomain.com".

and

3/29/2008 08:56:38 Trying http://www.myblog.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.mydomain.com/
Content-Type: text/html; charset=UTF-8

Here too, we should see the same content as immediately above, simply labeled "www.mydomain.com".

Both "myblog.blogspot.com" and "www.myblog.blogspot.com" redirect to "www.mydomain.com", again as in the previous study. Since no access to the blog, using the primary domain URL, is possible, this is an incomplete result.

It's possible that proper use of Google Apps may transform an asymmetrical and incomplete scenario into an asymmetrical and complete one - that is, resolution of the "Another blog ..." error may also provide access to the blog through the primary domain URL.

An alternative to Google Apps would be a "301 Redirect", again equating "mydomain.com" to "www.mydomain.com".

>> Top

Diagnosing Problems With Custom Domains - Case Study #2

The DNS setup shown in my first custom domain case study, "martinezumc.org", isn't typical for all custom domains. That domain, as I showed in my previous post in this series, Diagnosing Problems With Custom Domains - Case Study #1, was symmetrical - both "martinezumc.org" and "www.martinezumc.org" were defined with "CNAME" referrals, and I could have published the blog to either of the two URLs.

When you setup a custom domain while using the "Buy A Domain For Your Blog" wizard, this isn't going to be the case. In this case, the "www" alias will be defined with a "CNAME", but the primary domain won't be.

Let's take a look at "nitecruzr.net".

There are 4 URLs to study here.

1. The primary domain "nitecruzr.net".
2. The "www" alias for the domain "www.nitecruzr.net".
3. The primary BlogSpot URL "nitecruzr-dot-net.blogspot.com".
4. The "www" alias for the BlogSpot URL "www.nitecruzr-dot-net.blogspot.com".

First, let's dig the DNS records for the primary domain "nitecruzr.net".

;; QUESTION SECTION:
;nitecruzr.net.   IN A
 
;; ANSWER SECTION:
nitecruzr.net.  3600 IN A 64.233.179.121
nitecruzr.net.  3600 IN A 66.249.81.121
nitecruzr.net.  3600 IN A 72.14.207.121

Next, the "www" alias "www.nitecruzr.net".

;; QUESTION SECTION:
;www.nitecruzr.net.  IN A
 
;; ANSWER SECTION:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.
ghs.google.com.  586847 IN CNAME ghs.l.google.com.
ghs.l.google.com. 203 IN A 72.14.207.121

This is different from my previous case study.

nitecruzr.net.  3600 IN A 64.233.179.121
nitecruzr.net.  3600 IN A 66.249.81.121
nitecruzr.net.  3600 IN A 72.14.207.121
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.

Here, only the "www" alias is using a "CNAME", and the wizard automatically publishes the blog to that. In my case, to "www.nitecruzr.net".

Now, let's look at browser connect logs. First, this is what we get for the "www" alias in the domain "nitecruzr.net".

3/29/2008 08:50:42  Trying http://www.nitecruzr.net
Header:
HTTP/1.0 200 OK
Content-Type: text/html; charset=UTF-8

Next, the primary domain "nitecruzr.net".

3/29/2008 08:50:17  Trying http://nitecruzr.net
Redirect!
Header:
HTTP/1.0 302 Moved Temporarily
Location: http://www.nitecruzr.net
Content-Type: text/html; charset=UTF-8

As in the previous study, we see

HTTP/1.0 302 Moved Temporarily
Location: http://www.nitecruzr.net

This appears to be automatic, and it makes sense. When you setup a brand new domain, you'll likely want the primary domain = the "www" alias. The "302 Moved Temporarily" is a bit dodgy though.

Now, let's look at the BlogSpot URLs.

3/29/2008 08:56:48  Trying http://nitecruzr-dot-net.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.nitecruzr.net/
Content-Type: text/html; charset=UTF-8

and

3/29/2008 08:56:38  Trying http://www.nitecruzr-dot-net.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.nitecruzr.net/
Content-Type: text/html; charset=UTF-8

Both "nitecruzr-dot-net.blogspot.com" and "www.nitecruzr-dot-net.blogspot.com" redirect to "www.nitecruzr.net", again as in the previous study. This is a asymmetrical, but complete setup - that is, you can see your blog from any of the 4 aliases enumerated above. In earlier setups using the "Buy a Domain ..." wizard, the above results weren't consistently seen.

>> Top

Diagnosing Problems With Custom Domains - A Caveat

When you work on a custom domain, and the work takes you a few tries while you make one setting, tweak another setting, then republish something, maybe make a change in a post or two, note two issues that may affect your efforts. C a c h e and D N S L a t e n c y.

Besides being dependent upon blog content, examination of custom domain publishing also depends upon DNS content.

• Both blog content and DNS content are subject to caching.
• Transmission of DNS content from the DNS Host (generally, but not always, provided by your domain registrar) to your local DNS server (generally, but not always, provided by your ISP) is affected by DNS Latency.

When you're trying to correct a problem with a custom domain setup, if you want predictable results from any change that you make, you're going to have to deal with both issues. Any change you make may not show up immediately, because of caching and / or latency, and with both issues involved in a given problem, there are possibilities of confusion. If you make two changes, and don't exercise patience, clear caches, and test after the first, you may not be able to diagnose a problem as effectively as you should. For best results

1. Make one change.
2. If your change involves DNS settings, wait - in some cases "up to 24 hours".
3. Clear caches - both browser and DNS.
4. Test results.
5. Repeat as necessary.

This is lots more work than it should be, but when you start running into problems, and the problems don't resolve predictably, or the diagnostic results just don't make sense, you'd better slow down a bit, and work methodically.

>> Top

Diagnosing Problems With Custom Domains - Case Study #1

Google Custom Domains, that give us the possibility of having a blog with a non-Blog*Spot address, are a major improvement over plain old Blog*Spot to many bloggers. Occasionally though, problems arise, and diagnosing the symptoms, to allow us to focus on the problems, will require some technical ability, and the right tools. And, note the possible effects of cache and DNS latency, any time that you diagnose or examine a custom domain problem.

Here's a baseline study, which will show what you should see as the best possible case. My first custom domain, "martinezumc.org", I was able to setup with 2 "CNAME" referrals. I call this "symmetrically configured".

There are 4 URLs to study here.

• The primary domain "martinezumc.org".
• The "www" alias for the domain "www.martinezumc.org".
• The primary BlogSpot URL "martinezumc.blogspot.com".
• The "www" alias for the BlogSpot URL "www.martinezumc.blogspot.com".

First, let's dig the DNS records for the primary domain "martinezumc.org".

;; QUESTION SECTION:
;martinezumc.org. IN A

;; ANSWER SECTION:
martinezumc.org. 3600 IN CNAME ghs.google.com.
ghs.google.com. 61848 IN CNAME ghs.l.google.com.
ghs.l.google.com. 300 IN A 72.14.207.121

Next, the "www" alias "www.martinezumc.org".

;; QUESTION SECTION:
;www.martinezumc.org. IN A

;; ANSWER SECTION:
www.martinezumc.org. 3600 IN CNAME ghs.google.com.
ghs.google.com. 61733 IN CNAME ghs.l.google.com.
ghs.l.google.com. 185 IN A 72.14.207.121

This shows us two "CNAME" referrals in operation, ie "symmetrically configured".

martinezumc.org. 3600 IN CNAME ghs.google.com.
www.martinezumc.org. 3600 IN CNAME ghs.google.com.

Now, let's look at browser connect logs. First, this is what we get for the primary domain "martinezumc.org".

3/28/2008 07:42:11 Trying http://martinezumc.org
Header:
HTTP/1.0 200 OK
Content-Type: text/html; charset=UTF-8

Next, the "www" alias "www.martinezumc.org".

3/28/2008 07:35:25 Trying http://www.martinezumc.org
Redirect!
Header:
HTTP/1.0 302 Moved Temporarily
Location: http://martinezumc.org
Content-Type: text/html; charset=UTF-8

The key item here is

HTTP/1.0 302 Moved Temporarily
Location: http://martinezumc.org

When I setup the domain, the blog "martinezumc.blogspot.com" was published to "martinezumc.org", and I selected "Redirect www.martinezumc.org to martinezumc.org.".

Now, let's look at the BlogSpot URLs.

3/28/2008 07:52:38 Trying http://martinezumc.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://martinezumc.org/
Content-Type: text/html; charset=UTF-8

and

3/28/2008 07:53:33 Trying http://www.martinezumc.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://martinezumc.org/
Content-Type: text/html; charset=UTF-8

Both "martinezumc.blogspot.com" and "www.martinezumc.blogspot.com" redirect to "martinezumc.org". Blogger only recently corrected two design deficiencies in the Custom Domains product

• Allowed "www.martinezumc.blogspot.com" to redirect to "martinezumc.org".
• Allowed me to make the selection "Redirect www.martinezumc.org to martinezumc.org."

When these corrections were made, the Custom Domain product became usable for people with serious domain publishing requirements. This lets all 4 possible URLs (enumerated above) work predictably.

The domain "martinezumc.org" isn't typical of all Custom Domain setups, unfortunately. Next, I'll show an asymmetrically configured domain, my recently setup "nitecruzr.net".

>> Top