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

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 - 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 #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