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