Custom Domains And URL Forwarding - A Second Reason Why It's A Bad Idea

Some bloggers, who want to publish their blog to a Google Custom Domain, elect to not purchase the domain using the "Buy A Domain" wizard, still decide to accept their domain DNS configuration from a third party - the domain registrar. Many registrars advise use of URL forwarding, and this is known to cause problems with Blogger.

DaVe L, in Google Blogger Help - Publishing Trouble: 404 Error/Register.com domain issue, writes

Since this past sunday, my blog www.shortandsweetnyc.com has been getting that 404 error when I enter the URL. I registered the domain name through register.com and have called them several times to try to figure out what the issue was. They have been telling me that everything is fine on their end and it looks like the problem is on blogger.com's end.

And here we have yet a third incident involving Register.Com, in a single week.

An HTTP access trace shows us:

Sending request:

GET / HTTP/1.1
Host: shortandsweetnyc.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18
Connection: close

• Finding host IP address...
• Host IP address = 216.21.239.197
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:
HTTP/1.1·302·Found(CR)(LF)
Date:·Fri,·28·Nov·2008·02:51:45·GMT(CR)(LF)
Server:·Apache/1.3.27·(Unix)(CR)(LF)
Location:·http://shortandsweet-nyc.blogspot.com(CR)(LF)

Sending request:

GET / HTTP/1.1
Host: shortandsweet-nyc.blogspot.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18
Connection: close

• Finding host IP address...
• Host IP address = 72.14.207.191
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:
HTTP/1.1·301·Moved·Permanently(CR)(LF)
Location:·http://www.shortandsweetnyc.com/(CR)(LF)

Sending request:

GET / HTTP/1.1
Host: www.shortandsweetnyc.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18
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·404·Not·Found(CR)(LF)

And, an excerpted Dig log shows us the current DNS configuration:

shortandsweetnyc.com. 14400 IN A 216.21.239.197
www.shortandsweetnyc.com. 14400 IN CNAME ghs.google.com.
---
ghs.google.com.  105624 IN CNAME ghs.l.google.com.
ghs.l.google.com. 300 IN A 66.249.91.121

futuresite.register.com (216.21.239.197)
216.21.224.0 - 216.21.239.255
Register.com, Inc

Here, we see two problems.

• The well known "Server Not Found Error 404".
• A DNS configuration using URL forwarding, apparently using the Register.Com parked server ("futuresite").

See the above redirect sequence?

GET / HTTP/1.1
Host: shortandsweetnyc.com

HTTP/1.1·302·Found(CR)(LF)
Date:·Fri,·28·Nov·2008·02:51:45·GMT(CR)(LF)
Server:·Apache/1.3.27·(Unix)(CR)(LF)
Location:·http://shortandsweet-nyc.blogspot.com(CR)(LF)

GET / HTTP/1.1
Host: shortandsweet-nyc.blogspot.com

HTTP/1.1·301·Moved·Permanently(CR)(LF)
Location:·http://www.shortandsweetnyc.com/(CR)(LF)

GET / HTTP/1.1
Host: www.shortandsweetnyc.com

Receiving Header:
HTTP/1.1·404·Not·Found(CR)(LF)

Isn't a more direct sequence possible? It is, using an asymmetrical "A" / "CNAME" referral DNS configuration.

nitecruzr.net.  3600 IN A 64.233.179.121
nitecruzr.net.  3600 IN A 72.14.207.121
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.
---
ghs.google.com.  102141 IN CNAME ghs.l.google.com.
ghs.l.google.com. 300 IN A 66.249.91.121

which gives us a simpler redirect sequence

GET / HTTP/1.1
Host: nitecruzr.net

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

GET / HTTP/1.1
Host: www.nitecruzr.net

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

Now, we still have the problem of the "Server Not Found Error 404" to deal with here, but once that is out of the way, wouldn't the latter HTTP sequence be better for your readers?

>> Top

Blogs And The Redirect Warning

The Blogosphere, and particularly the BlogSpot address space, has been known, for some time, as a space where undesirable content is located. BlogSpot has been used for delivery of visually undesirable content (aka porn), and non visually undesirable content (aka hacking and spam) for some time. In January 2008, that changed, and publishers of blogs containing various forms of hacking / porn / spam found their activities hampered (though not completely shut down).

Many bloggers who wished to continue to provide us with antisocial and illegal content, using Google servers, started to relocate their payload, so Blogger could not detect the malicious blogs by merely scanning all of BlogSpot.

Similar to the Content Warning interstitial advice, Blogger implemented a redirected blog interstitial advice, indicating that the blog reader had just clicked on a link leading away from BlogSpot.


When a blog is published to an external URL, either as a Google Custom Domain, or by FTP to an external hosted server, the BlogSpot URL is redirected to the external URL. This keeps your readers, still using the BlogSpot URL, able to read the blog even with it having a new URL.

Unfortunately, the bad guys can, just as easily, locate their malicious content in a non BlogSpot server, which can't be detected by the Blogger anti hacking porn spam scanning. So, your readers get this unwelcome advice.



Unfortunately, this interstitial warning, like the Content Warning interstitial advice, will interfere with various automated and manual surfing activity.

>> Top

And Now, A Dose Of Paranoia For You

Danasoft - Free Signs For Your Blog

How scared should you be - did I just hack your computer?? Highlight from here, ==>Advice from the makers of the sign: These signs are created and served by our webserver in real-time for each person that views them. Your IP address and other information are only visible to YOU, not to others, but because people see their own IP address and computer information displayed on a blog, they think that their information can be seen by everyone! Get back to work!!<== to here, and find out.

See Geolocation: Where Are My Readers Located? for more advice.

>> Top

New Google Apps Engine Servers Are Not Yet Released

Even though newly setup domains, using the "Buy A Domain" wizard, are apparently using the new "216" series Google Apps servers, I was recently advised that the engineer setting them up has still not given the green light for publicizing these yet. Until advised, I'll still advise you to use the (old) Google Apps servers, in your Asymmetrical Custom Domain DNS setup.

mydomain.com.  3600 IN A 64.233.179.121
mydomain.com.  3600 IN A 72.14.207.121
www.mydomain.com. 3600 IN CNAME ghs.google.com.

Be patient, these are yet to be released officially.

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
www.mydomain.com. 3600 IN CNAME ghs.google.com.

Watch this space, and be patient.

>> Top

Custom Domains, And Register.Com As The Registrar, Redux

During the past week, we had an interesting experience where customers of Register.Com were reporting broken custom domains - domains that were using DNS service provided by Register. We traced the problem to a bogus address record, on a Register DNS server.

 ghs.google.com.  14400 IN CNAME ghs.google.com.

Some time yesterday, the problem was, supposedly, fixed.

Not.

This morning, in reviewing the many threads in BHG: Something Is Broken, I see a reply in one thread

I called Register.com again and walked through changing the DNS server settings one more time, and things are now working again.

In the process of closing that problem, I did a final Dig on the domain, and found an interesting detail.

 ; <<>> DiG 9.3.2 <<>> @dns090.a.register.com www.theresmytwocents.com ANY
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33071
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.theresmytwocents.com. IN ANY
 
 ;; ANSWER SECTION:
 www.theresmytwocents.com. 14400 IN CNAME ghs.google.com.
 ghs.google.com.  21600 IN A 216.21.239.197
 
 ;; Query time: 109 msec
 ;; SERVER: 216.21.231.90#53(216.21.231.90)
 ;; WHEN: Tue Nov 25 16:39:03 2008
 ;; MSG SIZE  rcvd: 83

Compare this to a Dig against my domain, "www.nitecruzr.net".

 ; <<>> DiG 9.3.2 <<>> @ns53.domaincontrol.com www.nitecruzr.net ANY
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59650
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.nitecruzr.net.  IN ANY
 
 ;; ANSWER SECTION:
 www.nitecruzr.net. 3600 IN CNAME ghs.google.com.
 
 ;; AUTHORITY SECTION:
 nitecruzr.net.  3600 IN NS ns53.domaincontrol.com.
 nitecruzr.net.  3600 IN NS ns54.domaincontrol.com.
 
 ;; Query time: 161 msec
 ;; SERVER: 216.69.185.27#53(216.69.185.27)
 ;; WHEN: Tue Nov 25 16:42:17 2008
 ;; MSG SIZE  rcvd: 115

A correctly setup DNS server doesn't include fixed Address records pointing another domain, like "ghs.google.com", to the company parked server. Regardless whether this entry might be ignored by a non-authoritative server when asking for "ghs.google.com".

futuresite.register.com (216.21.239.197)
216.21.224.0 - 216.21.239.255
Register.com, Inc

>> Top