The Real Blogger Status

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

2008-11-27T19:08:00.000-08:00

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

2008-11-27T17:07:00.000-08:00

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

2008-11-25T17:20:00.000-08:00

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

2008-11-25T10:33:00.000-08:00

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

2008-11-25T07:46:00.000-08:00

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

Why Isn't Google Solving The Server Not Found Error 404 Issue?

2008-11-25T06:26:00.000-08:00

This is a cry echoed by many, and for some time. And there is but one answer.

Google is solving "the problem". One problem, at a time.

But "the problem" will never be solved, as long as bloggers keep referring to it as "the problem". It simply isn't a problem - it's many problems, with the same symptom. If there is a problem with Custom Domains, it is that Custom Domains was not designed with enough specific diagnostic error messages - merely displaying

Another blog is already hosted at this address

Server Not Found Error 403

is simply not enough detail to help bloggers realise the many problems.

And every time that bloggers scream about the problem, they are helping ensure that the problem will never be solved. We have to solve each problem, one case at a time. Let Blogger Support decide which problem is the same as another problem.

Help us to help you.

When you experience your own personal version of the problem, help us to diagnose the problem.

Start a new thread in BHG : Something Is Broken.
Provide the BlogSpot and domain URLs, clearly and accurately.
Describe objectively and accurately what you've done, while attempting to diagnose and / or to solve your problem.
Wait patiently.
Maybe, read some of the previously written posts about known problems and / or about proper domain setups, while you wait. Educate yourself.

Please.

Become part of the problem solving process, not part of the problem.

>> Top

Custom Domains, And Register.Com As The Registrar

2008-11-23T22:46:00.000-08:00

Most people, when setting up a new custom domain, simply use the "Buy A Domain" wizard, and end up with eNom or GoDaddy as a registrar. Neither eNom nor GoDaddy are foolproof, and some folks find new and exciting ways to make their domains not work. Neither the Custom Domain Reset Form, nor the Blogger Help Group, will be retired within this lifetime. For all their flaws, both eNom and GoDaddy are predictable, within limits.

Some folks like to "roll their own", and use third party registrars, and "Advanced Settings". Now, we have challenges.

This evening, we have BHG: Something Is Broken: Custom domain suddenly not working

We've had a custom domain set up perfectly for 2 years. Somehow this morning, with no changes to our DNS nor blogspot .. our blog is fubar.

As usual, I start examining Dig logs (here, unabridged) for the domain. And, I find oddities.


 ; <<>> DiG 9.3.2 <<>> crackedsidewalks.com A
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23743
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;crackedsidewalks.com.  IN A
 
 ;; AUTHORITY SECTION:
 crackedsidewalks.com. 9652 IN SOA dns215.a.register.com.
 root.register.com. 2005111024 28800 7200 604800 14400
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 07:42:34 2008
 ;; MSG SIZE  rcvd: 97

 ; <<>> DiG 9.3.2 <<>> www.crackedsidewalks.com A
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10788
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.crackedsidewalks.com. IN A
 
 ;; Query time: 892 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 07:42:45 2008
 ;; MSG SIZE  rcvd: 42

compared to the similar logs from my domain, "nitecruzr.net", this is not promising.


 ; <<>> DiG 9.3.2 <<>> @localhost nitecruzr.net A
 ; (2 servers found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 175
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;nitecruzr.net.   IN A
 
 ;; ANSWER SECTION:
 nitecruzr.net.  3600 IN A 64.233.179.121
 nitecruzr.net.  3600 IN A 72.14.207.121
 
 ;; Query time: 170 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 08:41:44 2008
 ;; MSG SIZE  rcvd: 63

 ; <<>> DiG 9.3.2 <<>> @localhost www.nitecruzr.net A
 ; (2 servers found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51847
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.nitecruzr.net.  IN A
 
 ;; ANSWER SECTION:
 www.nitecruzr.net. 1911 IN CNAME ghs.google.com.
 ghs.google.com.  436315 IN CNAME ghs.l.google.com.
 ghs.l.google.com. 300 IN A 66.249.91.121
 
 ;; Query time: 167 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 07:59:31 2008
 ;; MSG SIZE  rcvd: 99

So, we Dig deeper. Why do they call it "Dig" anyway?


 ; <<>> DiG 9.3.2 <<>> crackedsidewalks.com ANY
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21071
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;crackedsidewalks.com.  IN ANY
 
 ;; ANSWER SECTION:
 crackedsidewalks.com. 12398 IN SOA dns215.a.register.com.
 root.register.com. 2005111024 28800 7200 604800 14400
 crackedsidewalks.com. 12398 IN NS dns215.a.register.com.
 crackedsidewalks.com. 12398 IN NS dns241.c.register.com.
 crackedsidewalks.com. 12398 IN NS dns249.d.register.com.
 crackedsidewalks.com. 12398 IN NS dns037.b.register.com.
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 08:01:16 2008
 ;; MSG SIZE  rcvd: 180

That should be the authoritative server for the domain.


 ; <<>> DiG 9.3.2 <<>> @dns215.a.register.com crackedsidewalks.com ANY
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55204
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;crackedsidewalks.com.  IN ANY
 
 ;; ANSWER SECTION:
 crackedsidewalks.com. 14400 IN NS dns241.c.register.com.
 crackedsidewalks.com. 14400 IN NS dns249.d.register.com.
 crackedsidewalks.com. 14400 IN NS dns215.a.register.com.
 crackedsidewalks.com. 14400 IN SOA dns215.a.register.com.
 root.register.com. 2005111024 28800 7200 604800 14400
 crackedsidewalks.com. 14400 IN NS dns037.b.register.com.
 
 ;; Query time: 93 msec
 ;; SERVER: 216.21.231.215#53(216.21.231.215)
 ;; WHEN: Mon Nov 24 08:03:06 2008
 ;; MSG SIZE  rcvd: 201

 ; <<>> DiG 9.3.2 <<>> @dns215.a.register.com www.crackedsidewalks.com ANY
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32514
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.crackedsidewalks.com. IN ANY
 
 ;; ANSWER SECTION:
 www.crackedsidewalks.com. 14400 IN CNAME ghs.google.com.
 ghs.google.com.  14400 IN CNAME ghs.google.com.
 
 ;; Query time: 89 msec
 ;; SERVER: 216.21.231.215#53(216.21.231.215)
 ;; WHEN: Mon Nov 24 08:03:24 2008
 ;; MSG SIZE  rcvd: 81

Huh?


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

Let's review.

When we do a normal Dig, we get no address information.


 ; <<>> DiG 9.3.2 <<>> www.crackedsidewalks.com A
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10788
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.crackedsidewalks.com. IN A
 
 ;; Query time: 892 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 07:42:45 2008
 ;; MSG SIZE  rcvd: 42

When we do a targeted Dig, we see this extra "CNAME" pointing to itself.


 ; <<>> DiG 9.3.2 <<>> @dns215.a.register.com www.crackedsidewalks.com ANY
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32514
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.crackedsidewalks.com. IN ANY
 
 ;; ANSWER SECTION:
 www.crackedsidewalks.com. 14400 IN CNAME ghs.google.com.
 ghs.google.com.  14400 IN CNAME ghs.google.com.
 
 ;; Query time: 89 msec
 ;; SERVER: 216.21.231.215#53(216.21.231.215)
 ;; WHEN: Mon Nov 24 08:03:24 2008
 ;; MSG SIZE  rcvd: 81

If we did a Dig against a non existent virtual host, we'd get the SOA for the domain.


 ; <<>> DiG 9.3.2 <<>> @localhost xxx.nitecruzr.net ANY
 ; (2 servers found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54073
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;xxx.nitecruzr.net.  IN ANY
 
 ;; AUTHORITY SECTION:
 nitecruzr.net.  10800 IN SOA ns53.domaincontrol.com. dns.jomax.net. 2008032400 28800 7200 604800 86400
 
 ;; Query time: 174 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 16:08:57 2008
 ;; MSG SIZE  rcvd: 103

If we did a Dig against a non existent domain, we'd get the SOA for the TLD.


 ; <<>> DiG 9.3.2 <<>> @localhost xxx.nodomain.net ANY
 ; (2 servers found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49125
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;xxx.nodomain.net.  IN ANY
 
 ;; AUTHORITY SECTION:
 nodomain.net.  3600 IN SOA promoshare.biz. hostmaster.nodomain.net. 20446 900 600 86400 3600
 
 ;; Query time: 241 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 16:09:33 2008
 ;; MSG SIZE  rcvd: 95

Instead, we see no result. Looks like a dropped connection maybe. Or, a query that results in an endless loop, like a "CNAME" pointing to itself.


 ; <<>> DiG 9.3.2 <<>> www.crackedsidewalks.com A
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10788
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;www.crackedsidewalks.com. IN A
 
 ;; Query time: 892 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Nov 24 07:42:45 2008
 ;; MSG SIZE  rcvd: 42

This looks like a bogus "CNAME" on the Register server "dns215.a.register.com".


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

If you talk directly to a Register CSR, make sure that they assist you properly. You'll need a proper custom domain configuration. Avoid URL forwarding, in any of its many variants.

(Update 11/25): Think this was strange? It gets stranger still the next day.

>> Top

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

2008-11-21T10:16:00.000-08:00

Many bloggers, who want to publish their blog to a Google Custom Domain, elect to not purchase the domain using the "Buy A Domain" wizard. Some folks decide to do so because they want a domain in a TLD that's not provided by the wizard, others just like to do it themselves. And sometimes, "doing it themselves" is where the trouble starts.

KJ, in Google Blogger Help - Something Is Broken: DNS Redirect Errors, asks

I've had some of the same problems as others who have posted, with the blog not showing, error messages, etc...
I've tried to go through and correct the areas that I thought haderrors, but the more I read the more confused I become.
Would someone be able to assist me to see if I have everything set up properly?

Here's what we saw, when we checked out the blog in question.

This isn't going to encourage prospective readers to read your blog.

And, checking out the DNS configuration, we saw:


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

What is "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.

Not a Google server, obviously!

Here, we see yet another example of URL forwarding, and one that's apparently being detected by Blogger as off-site content. Forwarding URLs is a favourite trick of hackers, porn merchants, and spammers, to redirect traffic, from a BlogSpot based spam blog farm, to an off BlogSpot web site containing hacking and porn. So Blogger added a redirect warning interstitial advice, which is what your readers now see.

If you keep your web site on a Google server (using "A" and "CNAME" referrals which go directly to Google servers), you shouldn't get the interstitial.

Either


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


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.

Much better for everybody.

(Update 11/27): Besides causing problems with Blogger issuing redirect advice warnings, URL forwarding causes needless complexity in blog access.

>> Top

Custom Domains, And Major Paradigm Shifts

2008-11-20T21:33:00.000-08:00

If you're reading this, you have a computer (or at least access to one). Your computer is being used as a client, to read this blog, which is located on a server. The Internet is a "Client - Server" application, and Google has thousands of servers, which they use to provide us access to our blogs, and other activities.

I won't go into the details here, but aside from the fact that both clients and servers are types of computers, there are not a lot of significant similarities between the two. Servers are generally not, in a well designed and secured environment, used as clients.

Then there's Google. If a Google server needs to provide you access to your blog that's published to a custom domain, it has to contact a Google DNS server to get the IP address of your blog, located on another Google server. That is, a server becomes a client. And there is one of the weaknesses of the custom domain product, in general.

The Google DNS server has to contact the DNS server for your domain, to get the information that it passes back to the Google "client server". This allows the Google "client server" to access the Google "server server", and provide you access to your blog.

Custom domains are very dependent upon DNS settings, and DNS settings for custom domains are provided, by intention, by outside parties. DNS information for your custom domain is not provided by Google, it has to be provided by a third party.

The stability of your custom domain, with its content hosted on Google servers, is affected by DNS servers that are part of the public infrastructure, and can be located anywhere in the world. And, it's affected by "servers" that are being used as "clients". That's a paradigm shift, and considering the differences between "clients" and "servers", it's substantial.

A second paradigm shift is seen when you try to diagnose a problem with your custom domain. You can run local diagnostics which show what you see, using your local DNS server. You may use a web based diagnostic like Rex Swain's HTTP Viewer, which will show you what can be seen from the DNS server that provides service to Rex Swain's "client server". Neither your local diagnostics, nor diagnostics from Rex Swain, will be 100% identical to the DNS information which the Google "client server" is getting. You can see Custom Domains, DNS, And Time To Live for an illustration of this issue.

And there you see reasons why I say over and over, that the "Magical" Custom Domain Reset Form won't be retired any time soon.

>> Top

Your Browser, In Anonymity And Safety - Browser Isolation

2008-11-20T09:01:00.000-08:00

In the Internet, just as in the real world, there are places where you just don't go, if you want to stay alive and / or safe. Safety on the Internet starts with staying out of web sites where you don't belong, and hardening your browser when you surf web sites that you don't completely trust. Besides hardening your browser, by disabling scripts from untrusted web sites, browser isolation is a new and promising protection technique. We isolate our browsers using two alternate techniques - proxy servers and sandboxes.

A proxy server can be run locally (on your network), or remotely (on the Internet). When run remotely, and provided by a third party, it provides anonymity as well as security. Address traces, such as from a visitor log in our blogs, show visitors as the proxy server and no farther. The security provided by a proxy server is configurable - if all that you desire is anonymity, you can enable many proxy servers to pass browser content that isn't completely safe.

An extreme version of proxy servers is found in onion routing, where you surf (and do other things) using a series of proxy servers between you and the target server.

A sandbox runs locally (on your computer), and provides complete security by isolating specific processes such as your browser from the rest of the operating system. Since a sandbox runs on your computer, it provides no anonymity. Visitor logs show the address of your computer (or your network).

One problem with proxy servers is that they involve a third computer (the proxy server) between your computer and the target computer (the remote server), and this makes surfing with a proxy slower than surfing without a proxy. You can surf unknown websites from a sandboxed browser, and enjoy the same speed as from a browser outside the sandbox, in safety.

Virtual machines, which provide a complete copy of the operating system running as an application on your computer, are the most versatile sandbox. A lightweight virtual machine can be had as SandboxIE, which was originally developed to sandbox Internet Explorer, which is known for being unsafe. With a minimum amount of work, you can run other browsers, and other applications in general, from SandboxIE.

If you want both anonymity and safety, you run a browser from within a sandbox, and surf through a proxy server from the sandboxed browser. This will be no slower than surfing directly within a proxy server, and no less safe than surfing directly using a browser inside the sandbox.

>> Top

The GoDaddy Domain Manager: Removing An Address Entry

2008-11-18T13:52:00.000-08:00

If you have a custom domain that was setup for you by Google Apps, or through the "Buy A Domain For Your Blog" wizard, or if you setup your domain to use the Google Apps standard configuration, you probably reference a Google server that doesn't exist any more. The Google server "66.249.81.121" was taken offline some time ago, yet many custom domains still have this configuration.


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

Reliance upon "66.249.81.121" contributes to at least some of the cases of "Server Not Found Error 404" observed recently. If your custom domain contains a reference to that server, your domain will probably show these symptoms eventually. If your domain is already showing this symptom, that may be why you're here.

Removing the entry in question isn't difficult. Start from the GoDaddy Domain Manager, for your domain.

Find the entry under "A (Host)" for "66.249.81.121". Look to the far right. See the 2 box icons under "Actions"? The one on the left is a pencil in a box ("Edit"), and the one on the right is an "X" in a box ("Delete"). Click on the box with the "X", in the row for "66.249.81.121".

Next, click on "OK".

And, it's gone.


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.

Much better for your domain, now.

>> Top

Your Email Address And Blogger Account #4

2008-11-17T11:46:00.000-08:00

People with multiple identities have been objects of interest for many years, and activity by their less public faces occasionally surfaces. Sometimes, Blogger will make you think that you have a second (or more) personality, one that you (your more public face, you hope) of course aren't aware of.

Occasionally, you may get an intriguing bit of email from Blogger Support.

This email is a response to your request for information about the Blogger account with the username xxxxxxx.

This account has been associated with the Google Account [email address]. You must use this email address to log in to Blogger from now on.

If you have forgotten the password to this Google Account, visit the following URL to reset it.

http://www.blogger.com/forgot.g

This account is a member of the following blogs:

Here you should see a list of your blogs.

If you experience any problems or have further questions, please visit our help site at http://help.blogger.com/

Sincerely,
The Blogger Team

This is a little scary, because you know what your account, and you password is, so why would you have requested this information? Is Blogger Support harassing you?
Cue spooky music.

Or worse yet, is somebody trying to break into your account? OMG, I'm being hacked.
Cue scary music.

But no, the situation is a little more boring. Blogger Support has repeatedly said that they will keep your Blogger account for you, forever, and that they will never disclose your account information to anybody.

That being the case, what happens if, one day, you forget your account information? Hoping that you still have the email account that you used, when you registered your account, you use the Google Account Recovery tool, plug in what you think is your account name (email address), and Blogger will happily send an email to the address associated with the account.

If the account is yours, and the email address is yours, you'll get a copy of the above email. If the account isn't yours, somebody else gets a copy of the above email.

If you just got a copy of the above email, and you didn't request the information, then it's likely that somebody else was trying to guess their account name, and entered your account name instead. Since you got the email, the other person didn't, and you and your account are still yours. You are safe, your account is safe, the other person didn't get any information about you.

Discard the email, and get back to work.

>> Top

Custom Domains And New Google Apps DNS Servers

2008-11-16T17:35:00.000-08:00

We've been getting a lot of reports of some well known problems recently, from blogs published to Google Custom Domains.

Another blog is already hosted at this address.

and

Server Not Found

Error 404

No, Chuck, tell us something that we didn't know.

When I analyse a custom domain problem, I always start with a DNS analysis, expressed using an excerpted Dig log. Typically, I'll see
Symmetrical Main Domain


mydomain.com. 900 IN CNAME ghs.google.com.
www.mydomain.com. 900 IN CNAME ghs.google.com.

or
Asymmetrical Main Domain (aka "Google Apps" configuration)


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

This weekend, though, we're seeing a variant on the latter configuration, reported as usual in anxious queries

For 3 days I received a message that the blog was redirecting. Then I got error 404 for a day and decided to switch to blogspot and back to my custom domain. Got an error that this domain is in use by another blog!!!!!!.


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. 1800 IN CNAME ghs.google.com.

The "216" series IP addresses are the New Google Apps Engine DNS servers. They were supposedly deployed in custom domains to solve the ongoing "Another Blog ..." and "Server Not Found ...." errors. Apparently, even they are not immune to the problem. They are probably just as subject to random factors, like Time To Live variances, as the former Google Apps servers.

It looks like the Custom Domain Reset Form isn't going to be retired any time soon.

(Update 11/25): I was recently advised that the new servers are not yet officially released by the engineer setting them up.

>> Top

Custom Domains, DNS, And Time To Live

2008-11-16T13:13:00.000-08:00

Custom domains, to the typical blogger, should be incredibly simple to setup. Functionally, the setup process is two simple steps.

Create a DNS entry for the URL of your choice, pointing to Google.
Publish the blog to the URL.

But for all of that simplicity, they are seemingly random in their failures.

Why are custom domains so randomly unreliable?

One example, where we can see random behaviour, is in surgical DNS changes. One of the recent causes of the flood of

Another blog is already hosted at this address.

and

Server Not Found

Error 404

is a reference to a DNS server that isn't in service any more.

Many bloggers, lately, complain of the "Server Not Found Error 404" symptom. I'll look at an HTTP Access Log for the domain, and see

Host IP address = 66.249.81.121

followed by

<h1>Server·Not·Found</h1>(LF)
<h2>Error·404< /h2>(LF)

Next, I look at an excerpted Dig log for the domain, and see


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

And the obvious (to me, anyway) advice is

Remove the entry for "66.249.81.121", then republish the blog to the domain.

For all the obvious nature of the problem, the results are just not consistent.

Sometimes, I see an immediate reply
Yay. You're awesome. Thanks. I'll remember you next time I have a problem.
Other times, a different answer
OK, great. Now, I get "Another blog is already hosted at this address." Thanks a lot!
What is up with that?

The latter result possibly results from one basic mistake, ignoring Time To Live.

The Time To Live (aka "TTL") is a caching factor. A DNS entry with a TTL of 3600 seconds, or 1 hour, requires the local ("non authoritative") DNS server, holding that entry, to keep it in its cache for at least 1 hour.

If asked for the IP address of the domain within that hour, the server will re issue the address in cache.
If asked for the IP address after that hour has passed, the server will re query the distant ("authoritative") DNS server, for that domain, for a fresh IP address.

If you make a change to the domain DNS setup, maybe remove the entry for "66.249.81.121", then immediately try to republish the blog to the domain, you're asking the Google "server" to ask it's local (non authoritative) DNS server for the domain address. Now TTL becomes relevant.

If the DNS entry for "mydomain.com" has been sitting in cache, on the Google (non authoritative) DNS server for over an hour, the server will get a fresh entry from the authoritative server. With "64.233.179.121" or "72.14.207.121" provided by the DNS server, the re publishing script should run successfully, and you'll see "Settings Were Saved Successfully".
If the DNS entry for "mydomain.com" was just acquired by the Google DNS server within the past hour, it's going to re issue what it has in cache, and the entry for "66.249.81.121" gets passed back yet again to the Google "server" that's processing the blog republishing. And you're going to see "Another blog is already hosted at this address".

You want to remember an additional detail, and one that's very important. Just because you made the DNS change, maybe refreshed your local DNS cache, and now are able to ping your domain, you're still not guaranteed "Settings Were Saved Successfully" from Blogger.


C:\>ping mydomain.com

Pinging mydomain.com [64.233.179.121] with 32 bytes of data:

Reply from 64.233.179.121: bytes=32 time=221ms TTL=243
Reply from 64.233.179.121: bytes=32 time=212ms TTL=243
Reply from 64.233.179.121: bytes=32 time=204ms TTL=243
Reply from 64.233.179.121: bytes=32 time=208ms TTL=243

Ping statistics for 64.233.179.121:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 204ms, Maximum = 221ms, Average = 211ms

That says that your computer, and maybe your non authoritative DNS server, is getting the right DNS address ("64.233.179.121") from the authoritative DNS server for "mydomain.com". If the DNS entry for "mydomain.com" on the Google non authoritative DNS server is newer than 1 hour, and you try re publishing the blog immediately, the Google "server" will get "66.249.81.121" - and you're still going to see "Another blog is already hosted at this address".

This is one cause of the random nature of the re publishing effort.

Yay. You're awesome. Thanks. I'll remember you next time I have a problem.

OK, great. Now, I get "Another blog is already hosted at this address." Thanks a lot!

We simply can't predict which response we'll get, for any problem report, if we don't allow for TTL.

The proper answer, for a TTL of 3600, is

Remove the entry for "66.249.81.121", wait 1 hour, then republish the blog to the domain.

That won't eliminate all observances of "Another blog is already hosted at this address", but it should increase observances of "Settings Were Saved Successfully" to some degree.

And note yet one more caveat - a TTL of "3600" (1 hour) is normal, but some DNS providers have been seen to use a TTL of "86400" (1 day). This is possibly the motivation for the Blogger "In Transition" period for new custom domain setups created by "Buy A Domain".

>> Top

Your Blog, And Blogger, And Custom Domain Publishing

2008-11-15T14:03:00.000-08:00

Blogger has thousands of computers that they control and support - their servers. They have millions of computers that they don't control, but still try to support - our computers. Then there are the remote servers, to where we (try to) publish blogs using FTP. They don't own, or support those computers, and that relationship creates a lot of challenges when we want to publish our Blogger blogs to those non-Google computers.

If we elect to publish our Blogger blogs to Google computers, but still want a non-BlogSpot URL to address our blogs, we can publish to a Google Custom Domain. Publishing to Google computers gives us all of the advantages of publishing to BlogSpot, and one improvement - a non-BlogSpot URL.

Like FTP Publishing, Custom Domain Publishing requires non-Google resources. FTP Publishing requires external host servers for the blog content. With Custom Domain Publishing, the blog content is hosted on Google servers, but addressing those servers requires DNS hosting, which is not provided by Google. And there is where the problems with custom domains start.

Right now, there are (at least) four classes of custom domain problems.

Problems caused by bloggers, when setting up their custom domains, on their own.
Problems caused by Blogger, by deactivating resources that are in use.
Problems caused by Google, within the Google database.
Problems caused by use of outside (non Google) resources, which Google can't control.

We are seeing a lot of individually reported custom domain symptoms, which are caused by, in my opinion, various combinations of the above issues. And Google causes further confusion, with their problem documentation.

Thursday, August 28, 2008

Some users with custom domains are seeing 404 errors when trying to view their blogs. A similar underlying issue is causing some new custom domain signups to return bX errors.

and a second, later issue of confusion

Tuesday, September 30, 2008

Some users are seeing that their custom domains are forwarding to www.google.com. We are working to resolve the issue.

The outages described here were major in scope, causing many blogs to be offline, and were each fixed shortly after they were identified. Yet the Known Issues blog entries remain labeled as "outstanding", or at least not labeled as "fixed". Various bloggers have been citing these issues, recently, as part of the "outage" which they perceive, based upon their personal involvement in one combination of the above 3 issues.

Blogger Support needs to update Blogger Status and Known Issues, to slightly reduce the confusion.

And bloggers, in general, need to be aware of the above issues, as they report their personal custom domain problems. The well known (and thoroughly disliked) "Another blog is already hosted at this address" and "Server Not Found Error 404" symptoms are caused by a combination of the above issues. Success in immediate recovery, of any one blog, depends upon the combination of issues actively affecting that one blog.

Some blogs can be personally recovered - by recycling domain settings within Google Apps, and / or by recycling publishing settings within Settings - Publishing. Other blogs can't be personally recovered, and will require patient use of the Custom Domain Reset Form.

Bloggers, and Blogger, must become aware of the combination of problem causes, and the issues, and must react appropriately. Each of these named problem causes create different scopes of symptoms, and each require different treatment for resolution.

Problems Caused By Individual bloggers
If you purchase a domain using the "Buy A Domain" wizard, or through Google Apps, the DNS is setup for you, in what I will call "Asymmetrical Configuration", or alternately "Google Apps Configuration". Alternately, Blogger Support may recommend a "Symmetrical Configuration". Any other configuration, created by bloggers who don't understand how simple custom domains should be when setup properly, and who attempt to develop their own, may or may not work. Sometimes, a blogger will attempt to use a setup which "should work!", and predictably cause the "404" by doing so. Additional configurations simply aren't recommended.

Problems Caused By Blogger
The original "Google Apps" configuration was


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

Over a month ago, server "66.249.81.121" was removed from service, and blogs which referenced it were seen to exhibit the "Server Not Found Error 404" symptom. Yet as late as last week, blogs setup using "Buy A Domain" were observed to reference it in their DNS setups.

Problems Caused By Google Database Corruption
Google database corruption is known to be the most common (but not only) cause of the "Another blog ..." symptom. The symptom was, originally, resolved by recycling domain settings, using Google Apps. Later, Blogger Support developed a "Custom Domain Reset Form", which alerts them to a specific problem domain, and they manually examine the Google database, and find and fix the problem. With the recent changes to Google Apps, the "Reset Form" is the only solution for problems in newer domains.

Sometimes, the "Server Not Found Error 404" symptom is seen in a blog, and recycling publishing settings in Settings - Publishing is an effective solution. At other times, the "Another blog ..." error is seen in the Settings - Publishing wizard, during the republishing recycling process, and the "404" remains.

If no 404 error is seen, the blogger attempts to change the blog published to the domain, and sees the "Another blog ..." symptom, the domain settings in the Google database remain corrupt and the 404 error will be seen afterwards.

Sometimes the "Another blog ..." and "Server Not Found" symptoms are seen together. At other times, one symptom, but not the other, will be seen. Maybe the two symptoms have common causes in some cases, but they surely are not one for one. Bloggers observing one symptom in their blog or domain should not assume that a solution used by another blogger will automatically work, for their symptom, in all cases. Neither symptom should be assumed as the cause for the other.

Problems Caused By Use Of Outside (non Google) Resources
Google Custom Domains require the use of DNS servers, that are not provided by Google. The TTL used on non-Google servers is unpredictable, and the age of any DNS record, at any time, causes completely random problems.

The bottom line? The Custom Domain Reset Form isn't going to be retired from service, in this lifetime.
>> Top

Custom Domains And The Blogger Redirect Selection

2008-11-14T15:10:00.000-08:00

One odd question which has been popping up occasionally from puzzled bloggers would be the nature of the Blogger Custom Domain Redirect option

I selected "Redirect mydomain.com to www.mydomain.com.", but I'm still getting a "404 Not Found". What is up here?

Why do I keep getting a parked page, even after I selected the Redirect option?

So, we Dig the DNS configuration, and see


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

or maybe


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

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

And there, ladies and gentlemen, is your answer. The first configuration will give you a 404, because there is no DNS definition for "mydomain.com". The second configuration will give you the GoDaddy server "68.178.232.100", and a parked page display.

If you want the Blogger Redirect option to have any meaning, your DNS has to point into Google, in properly paired entries.


mydomain.com. 900 IN CNAME ghs.google.com.
www.mydomain.com. 900 IN CNAME ghs.google.com.


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

is the only way to make

Redirect mydomain.com to www.mydomain.com.

have any meaning.

The Redirect option starts with proper DNS, it does not substitute for proper DNS.

>> Top

FTP Publishing - November 2008

2008-11-14T13:30:00.000-08:00

This month, we again see reports of several frequent FTP Publishing problem symptoms. The well known

Your publish is taking longer than expected. To continue waiting for it to finish, click here.

and

ConnectException: Connection timed out.

These symptoms have been seen fairly recently, but now we have an additional detail. Some reports are from bloggers who have examined the server activity and firewall logs, and who explicitly state that the server is getting no incoming traffic. This could, conceivably, be another episode of the Server IP address / Name setting change.

If you are suffering from this problem, please provide diagnostic information

The blog BlogSpot URL (if applicable).
The blog domain URL.
The name of the server hosting company.
The Blogger FTP server setting value.

as part of your problem report, in BHG: Publishing Trouble. Please, be socially conscious and start a new thread for your report.

>> Top

FTP Publishing: Moving Ahead - How It's Done

2008-11-13T18:37:00.000-08:00

Some Bloggers, currently publishing by FTP to external servers, might eventually want to move back to BlogSpot. Maybe that's simply the first step in publishing to a custom domain, or maybe you're just tired of the lack of reliability and the uncertainty, you just want to move back. And the actual moving back isn't difficult.

Start from the Settings - Publishing screen. See the advice for "Blog URL"?
"nitecruzrtestftp.blogspot.com will redirect to your FTP blog."

That's the current BlogSpot alias, and soon will be the only URL.

Just select "Switch to: • blogspot.com".

Endure yet another CAPTCHA.

You're done. You're publishing on blogspot.com. And see the Blog*Spot Address?

Just don't try hitting "Save Settings" again.

Home again. Now, if you like, move to a custom domain. Or not.

>> Top

Your DNS Host Domain Manager Wizard, And The Domain Root

2008-11-13T11:05:00.000-08:00

Periodically, when reviewing the many problem reports about Google Custom Domains, and especially those reporting the ubiquitous "Another blog ..." error message, we'll look at the DNS configuration and see a partial DNS setup


www.mydomain.com. 900 IN CNAME ghs.google.com.

yet the blogger reporting the problem states

I setup my domain with both the root, and the "www" alias, defined. This is what I setup! Whatever can the problem be?


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

Using our powers of telepathy, we look deeper, and see not the above, but


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

or maybe


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

SAY WHAT?

This is a typical problem with many GUI Domain Managers, where "mydomain.com" is already known to the wizard (look at the top of the screen). When you specify a "CNAME" for "www.mydomain.com", in the "CNAMES (Aliases)" entry, you don't specify "www.mydomain.com", you simply specify "www". Specifying "www.mydomain.com" for "CNAMES (Aliases)" results in


www.mydomain.com.mydomain.com. 900 IN CNAME ghs.google.com.

Similarly, specifying "mydomain.com" for "A (Host)" results in


mydomain.com.mydomain.com. 900 IN CNAME ghs.google.com.

This will not always be the case, unfortunately. Some DNS Manager wizards automatically extract redundant "mydomain.com" phrases from the "A (Host)" and "CNAMES (Aliases)" entries. Others, like GoDaddy, do not.

For GoDaddy and some (not all) similar wizards

To designate "mydomain.com", enter "@" (that's a Shift-2, on most keyboards), when making an entry under "A (Host)".
To designate "www.mydomain.com", enter "www" when making an entry under "CNAMES (Aliases)".

If you have a third party DNS Host (not eNom or GoDaddy), you are responsible for finding out how they signify the domain root, when entering the "A (Host)" and "CNAMES (Aliases)" records. Try and prevent


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


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

and eliminate one possible cause for the "Another blog ..." error.

>> Top

Your Custom Domain Registration, And The "Buy A Domain" Wizard

2008-11-13T08:20:00.000-08:00

When you purchase a domain using the "Buy A Domain For Your Blog" wizard, from either eNom or GoDaddy, you're paying $10 USD to eNom or GoDaddy, solely as a domain registration fee. And you're buying the domain anonymously. The eNom or GoDaddy name used to access your domain account is random, and doesn't refer, in any way, to your identity as a blogger. This is an intentional registration feature.

To get the account name ("Sign-in name") and the accompanying password, you need access to the Google Apps account that's created by Blogger, when you use the "Buy A Domain" wizard. You have to have the email from "google-apps-do-not-reply", that you received as a receipt, for access to Google Apps (at least initially).

Without the Customer Service PIN, that's provided in the Google Apps display, neither eNom or GoDaddy can help you. I suspect that even the relationship between the PIN and the Sign-in Name is kept secret from the Customer Service Representatives.

The Customer Service PIN is how you identify yourself to the eNom / GoDaddy Customer Service Representatives.
The Sign-in Name (and accompanying Password) is how you identify yourself to the eNom / GoDaddy Domain Manager automated sign-in process.

Two identification components, and two identification processes, both separate from each other. This is a standard practice in IT.

Your anonymity provides your liberty. Support your anonymity.

>> Top

Custom Domain Setup Procedures, Again, Terminating With bX- Codes

2008-11-12T07:17:00.000-08:00

A few months ago, I reported that custom domain repair procedures were reported to be terminating with bX codes. Previously, I had reported of custom domain setup procedures doing likewise. Now, it looks like we are in for a third round of bX codes, when setting up custom domains.

bX-x2qlz6

Additional information
host: www.blogger.com
uri: /blog-publishing.do

bX-x2qlz6

These are the errors that we're seeing right now, all apparently during the custom domain setup procedure.

First and foremost, report your bX code, using the code reporting form!

>> Top