Thursday, November 27, 2008

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? URL forwarding is simply another spurious solution.

>> 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 your 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 your blog.

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. If your blog redirects to other than a properly configured external domain, your readers should get this unwelcome advice.



Unfortunately, this interstitial warning, like the Content Warning interstitial advice, will interfere with various automated and manual surfing activity. If you don't want your readers seeing this, you use a properly configured externally published blog.

>> Top

Tuesday, November 25, 2008

And Now, A Dose Of Paranoia For You



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. Better, spend your time publishing informative and interesting content - make your readers feel genuinely welcome.

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

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

This is a cry echoed by many, and for some time. Some, who ask this question, ask a similar question too, "Why Isn't Blogger Solving The "Another blog is already hosted at this address" Problem?" And there is but one answer, to both questions.
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 one problem - it's many problems, with the same symptom.

Sunday, November 23, 2008

Custom Domains, And Register.Com As The Registrar

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

Friday, November 21, 2008

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

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.

or

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. URL forwarding is simply another spurious solution.

>> Top

Thursday, November 20, 2008

Custom Domains, And Major Paradigm Shifts

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.

Your Browser, In Anonymity And Safety - Browser Isolation

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 necessarily safe.

An extreme version of proxy servers is found in onion routing, where you surf (and do other things) using a cascading series of proxy servers between you and the target server.
  • You connect directly to proxy server A.
  • From proxy server A, you connect to proxy server B.
  • From proxy server B, you connect to proxy server C.
  • From proxy server C, you connect to your target.
  • As you feel the need, you may add proxy server D, E, and so on.
Do you see the layers of the onion?

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 (though not anonymity).

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. With browser content that isn't necessarily safe, staying within the sandbox, your computer is safe.

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

Tuesday, November 18, 2008

The GoDaddy Domain Manager: Removing An Address Entry

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

Monday, November 17, 2008

Blogger Accounts, And Unsuccessful Recovery Attempts

People with multiple identities have been objects of interest for many years.

Occasionally, we see activity by the less public faces. Sometimes, odd behaviour by Blogger will make you think that you have a second personality - one that you (your more public face, you hope), of course, aren't aware.

Sunday, November 16, 2008

Custom Domains And New Google Apps DNS Servers

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 12/12): It appears that, though not officially published, the new servers are being used, in service.

>> Top

Custom Domains, DNS, And Time To Live

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 apparently 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
Update the DNS addresses to use the new Google Apps DNS servers, 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". You get DNS information from a server that's local to you. Google gets DNS information from a server that's local to them. Your local DNS server won't be the same as Google's local DNS server.

Even with both your local DNS server, and the Google local DNS server, having the same IP addresses for your domain, they will probably get that information at different times. The cache on one server will expire sooner than the cache on the other. Some time later, the cache on one will expire sooner, and that server will be required to refresh itself. Now the cache on the two servers will possibly be different.

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.
or
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 full 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".

Also, it's likely that there are as many registrars that use "14400" (4 hours) as use "3600" (1 hour) for default TTL. If the registrar for your domain uses "14400" as a default, and you're reading here for advice, use "14400" for your DNS addresses. But remember to wait 4 full hours, after making changes - if you want to be confident of getting the desired results!

>> Top

Saturday, November 15, 2008

Your Blog, And Blogger, And Custom Domain Publishing

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.


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. Some bloggers will listen to advice from the DNS hosting staff, and setup URL forwarding, which can be a problem. And there are still more configurations that 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.

In Octuber 2008, 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 Mid November, domains being setup at that time, apparently by "Buy A Domain", were observed to include that server in their DNS setups. Even in December, we are seeing reports of domains in "404" status, and we see HTTP traces which show attempts to actually use the server in question.

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. Caching policies on non-Google servers are unpredictable, and the status of DNS addresses on any one - or a group - of DNS servers causes completely random problems.

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

Friday, November 14, 2008

Custom Domains And The Blogger Redirect Selection

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?
or
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.

or

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

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

Thursday, November 13, 2008

Custom Domain DNS Addresses And Name Addressing Conventions

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 216.239.32.21
mydomain.com.  3600 IN A 216.239.34.21
mydomain.com.  3600 IN A 216.239.36.21
mydomain.com.  3600 IN A 216.239.38.21
www.mydomain.com. 900 IN CNAME ghs.google.com.

We look deeper, and find not the above, but
mydomain.com.mydomain.com.  3600 IN A 216.239.32.21
mydomain.com.mydomain.com.  3600 IN A 216.239.34.21
mydomain.com.mydomain.com.  3600 IN A 216.239.36.21
mydomain.com.mydomain.com.  3600 IN A 216.239.38.21
www.mydomain.com. 900 IN CNAME ghs.google.com.

or maybe
mydomain.com.  3600 IN A 216.239.32.21
mydomain.com.  3600 IN A 216.239.34.21
mydomain.com.  3600 IN A 216.239.36.21
mydomain.com.  3600 IN A 216.239.38.21
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 Domain Manager display). 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), under "A (Host)".
  • To designate "www.mydomain.com": Enter "www", 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 216.239.32.21
mydomain.com.mydomain.com.  3600 IN A 216.239.34.21
mydomain.com.mydomain.com.  3600 IN A 216.239.36.21
mydomain.com.mydomain.com.  3600 IN A 216.239.38.21
www.mydomain.com. 900 IN CNAME ghs.google.com.

or
mydomain.com.  3600 IN A 216.239.32.21
mydomain.com.  3600 IN A 216.239.34.21
mydomain.com.  3600 IN A 216.239.36.21
mydomain.com.  3600 IN A 216.239.38.21
www.mydomain.com.mydomain.com. 900 IN CNAME ghs.google.com.

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

>> Top

FTP Publishing: Moving Ahead - How It's Done

Many Bloggers, currently publishing by FTP to external servers, need to plan for a somewhat immediate move of their blogs back to Blogger and Google servers.


No matter how you look at it, this is a manual process. This week, an FTP Publishing Migration Tool, stated to be available 2/22, developed to support the immediately required migration, will mitigate some of the tedium and uncertainty that's described below.



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 Custom Domain Registration, And The "Buy A Domain" Wizard

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

Wednesday, November 12, 2008

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

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

Tuesday, November 11, 2008

Refresh Your DNS Cache

Sometimes, when we have a blog published to a Google Custom Domain, which depends very heavily upon DNS configuration for success, we'll make a change to the domain DNS configuration and notice that our readers can see the change, but we can't.
Once again, at 6:23, someone was able to see my blog and leave a comment

Yet, moments after I tried, I was still getting the 404 error. So there seems to be some intermittent activity!


Let's look at the domain DNS configurations. First, current:

mydomain.com. 14400 IN A 216.21.239.197
www.mydomain.com. 14400 IN A 216.21.239.197

Then, new:

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

A TTL of 14400 seconds (4 hours) is a bit extreme. I see mostly 3600 seconds (1 hour), sometimes 900 seconds (15 minutes), in most DNS configurations. If the TTL for your domain is 4 hours, it could be about that long after you make the change, before you start seeing any change. I say "about", because the age of the configuration information, as cached on your computer or server when you make the change, is relevant. If the information is 15 minutes old, then with a TTL of 14400, you'll have to wait another 13500 seconds, or 3 3/4 hours. If the information is 3 hours old, you'll wait merely another hour.

But, you can hasten that, if the cache on your computer is the bottleneck. From a command window, enter
ipconfig /flushdns
If the DNS cache in question is on your computer, it's gone now and the next time that you try for your custom domain, it should come up in its new configuration.

Note 2 Caveats
  • If you have a caching non-authoritative DNS server that your computer retrieves DNS directly from, you'll still have to wait. The "ipconfig" command works only under Microsoft Windows, and only on the computer with the cache. If the cache is upstream from you, you're going to have to remain patient.
  • Whether or not your local DNS cache, and your upstream non-authoritative DNS server gets the updates, you still can't predict the update status of the Google non-authoritative DNS servers.


Knowing your DNS setup is a good idea, when working with custom domains. And allowing for DNS latency at Google is essential.

>> Top

Now You See It, Now You Don't, Now You See It Again?

Last month, we learned that Google Apps DNS server "66.249.81.121" was permanently out of service.
66.249.81.121 is gone forever. Removing that A record will help.


This evening, I was examining one custom domain "solution", which looked a bit dodgy.

mydomain.com. 10800 IN A 66.249.91.121
www.mydomain.com. 10800 IN CNAME ghs.google.com.

Now, we have "66.249.91.121". A quick HTTP trace shows:

Sending request:

GET / HTTP/1.1
Host: mydomain.com

• Finding host IP address...
• Host IP address = 66.249.91.121

Receiving Header:
HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://www.ertmc.ro/(CR)(LF)

Yes, it is alive.

C:\>ping 66.249.91.121

Pinging 66.249.91.121 with 32 bytes of data:

Reply from 66.249.91.121: bytes=32 time=332ms TTL=242
Reply from 66.249.91.121: bytes=32 time=378ms TTL=242
Reply from 66.249.91.121: bytes=32 time=321ms TTL=242
Reply from 66.249.91.121: bytes=32 time=311ms TTL=242

Ping statistics for 66.249.91.121:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 311ms, Maximum = 378ms, Average = 335ms

The dead rise again. But, Halloween was a couple weeks ago.
Cue spooky music.

(Update 11/12): I was just informed by a very authoritative source that "66.249.91.121" is not a replacement for "66.249.81.121", and won't remain available. My recommendation, for an asymmetrical DNS configuration, remains:

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


>> Top

Diagnosing Problems With Custom Domains: Rex Swain's HTTP Viewer

Whenever I answer a problem report which involves a blog published to a Google Custom Domain, I always start my answer with a Dig log. A Dig log tells me what's behind the behaviour of the Custom Domain. Having looked at what's behind the scenes, I look at the front scenes. One very common front scene is (guess what?)
Server Not Found

Error 404
and I'll report to someone
You have the well known
"Server Not Found
Error 404".
and to a select few that will be news.
Great, Chuck, what do I do now?
but to many bloggers
Great, Chuck, tell me something that I don't know.
So, how do you describe the old "404", so you can diagnose it?

For analysing the sequence of events that lead to the "404", and various other browser related events, I use the Rex Swain HTTP Viewer. This is a free (what else?) online service, that produces an online text log (suitable for copying and pasting) of the contents of an HTTP conversation between a web client (such as your computer) and a web server (such as a Blogger server).

The HTTP Viewer isn't complicated to use.
  1. Direct your browser to www.rexswain.com/httpview.html.
  2. Copy and paste the URL of your choice, into the "URL" window.
  3. Select "Text" for "Display Format".
  4. Hit the "Submit" button.


Here's a log from a recently observed "404", a symptom that we all know so well (and wish that we did not):

Rex Swain's HTTP Viewer

http://www.rexswain.com/httpview.html

Parameters:

URL = http://www.mydomain.com
UAG = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 Firefox/2.0.0.17
AEN =
REQ = GET ; VER = 1.1 ; FMT = TXT

Sending request:

GET / HTTP/1.1
Host: www.mydomain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 Firefox/2.0.0.17
Connection: close
• Finding host IP address...
• Host IP address = 66.249.81.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)
Date:·Tue,·11·Nov·2008·20:00:30·GMT(CR)(LF)
X-Content-Type-Options:·nosniff(CR)(LF)
Expires:·Tue,·11·Nov·2008·20:00:30·GMT(CR)(LF)
Cache-Control:·private,·max-age=0(CR)(LF)
Content-Length:·142(CR)(LF)
Content-Type:·text/html(CR)(LF)
Server:·GFE/1.3(CR)(LF)
Connection:·Close(CR)(LF)
(CR)(LF)

End of Header (Length = 253)

• Elapsed time so far: 1 seconds
• Waiting for additional response until connection closes...

Total bytes received = 395

Elapsed time so far: 1 seconds

Content (Length = 142):

<HTML>(LF)
<head>(LF)
<title>404</title>(LF)
</head>(LF)
<body·bgcolor="#ffffff"·text="#000000">(LF)
<h1>Server·Not·Found</h1>(LF)
<h2>Error·404< /h2>(LF)
</body>(LF)
</html>(LF)

Done

Total elapsed time: 1 seconds


And as usual, I'll excerpt the most relevant portions of the display.

Sending request:
GET / HTTP/1.1
Host: www.mydomain.com

• Finding host IP address...
• Host IP address = 66.249.81.121

Receiving Header:

HTTP/1.1·404·Not·Found


That's a simple example - and you can make your own examples, easily enough.

Given the HTTP Viewer, and a good Dig log, we are probably 50% of the way towards understanding any blogger caused problems. Now, Blogger caused problems may be another story.

But this is a start.

>> Top

Blog Slurping Not Working

Recently, we are getting reports from bloggers, anxious to publish their blogs on paper, that Blurb and BookSmart are no longer able to retrieve blog content.
TypePad, WordPress.com, and Blogger are all bugged out on BookSmart. For some reason, these platforms made changes in their APIs, in essence how their code talks to our code, and BookSmart can’t recognize those changes.
and
These problems have been escalated to the dev teams at TypePad, WordPress.com, and Blogger.


It sounds like BookSmart is a typical third party product, with the vendor unwilling to make changes at their end, to support changes made by Blogger. Now they want Blogger (TypePad, WordPress) to support their code, so they can continue to extract data ("slurp"?) using their own code, unchanged.

If BookSmart, a third party product, uses Blogger APIs to retrieve content, and Blogger changes their APIs, Blurb then should update their code which uses the APIs. Almost surely, Blogger's support for Blurb is limited to the APIs which they provide.

For Blurb to use the Blogger APIs, develop a market based upon Blogger (TypePad, WordPress) customers, then neglect to update their code, seems a little short-sided.

Fortunately, alternative solutions are available.

>> Top

Monday, November 10, 2008

The Navbar Is Optional

The question whether the Navbar is a requirement, in all blogs hosted by Blogger / Google ("Blog*Spot and Custom Domain"), has been asked repeatedly, and debated by many bloggers, for years. Today, Blogger has finally provided an authoritative answer.
While we don't recommend or support the removal of the Blogger navbar, there is nothing in our Terms of Service that explicitly mandate its use.

As far as actually doing it, it requires just a simple 5 minute template edit (10 minutes, including backing up the template, twice).

I will, however, point out that, if you publish your blog for people other than you to read, you will probably have happier readers if you leave the navbar in place. As time goes on, and Blogger improves the navbar, you'll find more and more reasons why removing it is just not a good idea.

It's your blog - but it's your readers blogs, too.

>> Top

Wednesday, November 05, 2008

Diagnosing Problems With Custom Domains - Case Study #9

One of the many ways of including one web site (blog) inside another web site (blog) is by using an IFrame. The host web site contains a frame, and the source of the frame is the other web site. And you can do that as well in what looks like a custom domain, but won't give you the same results.

<frameset rows="100%">
<frame title="http://www.mydomain.com" src="http://www.mydomain.com" name="mainframe" frameborder="0" noresize="noresize" scrolling="auto">
<noframes>Sorry, you don"t appear to have frame support.
Go here instead - <a href="http://www.mydomain.com"></a></noframes>
</frameset>

Put that in the template for your web site, and behold - you have the contents of your Blog*Spot blog displayed right there. And if all that you care about is your readers visually able to read the content of the blog, you're done.

<frameset rows="100%">
<frame title="http://myblog.blogspot.com" src="http://myblog.blogspot.com" name="mainframe" frameborder="0" noresize="noresize" scrolling="auto">
<noframes>Sorry, you don"t appear to have frame support.
Go here instead - <a href="http://myblog.blogspot.com"></a></noframes>
</frameset>


Of course, your Host web site won't have the blog content - just a frame. If having the Host web site indexed by the search engines - which is one of the advantages of a custom domain - is of interest to you, forget about using Frames. The search engines won't see anything in the Target web site. And likewise, forget about the readers of the Host web site providing any weight for the Target web site.

All weight goes to the empty Host web site. What a waste.

Another casualty with frames forwarding will be the blog feed. With a "301 Moved Permanently", anybody subscribed to a BlogSpot feed, from a blog published to to a custom domain, gets the feed from the custom domain URL, transparently. If the domain uses frames forwarding, to redirect to the BlogSpot URL, this won't work. A frame visually displays the blog itself, it's not going to display the feed.

Frame forwarding is simply another spurious custom domain solution.

For more discussion on this controversy:
So no, it appears that Frames are not a substitute for a properly setup custom domain.

>> Top

Schizophrenia And Custom Domain URLs

When you setup a Blog*Spot blog, and publish to "myblog.blogspot.com", Blogger automatically defines "www.myblog.blogspot.com" and redirects it for you, to "myblog.blogspot.com". This is a traditional convenience for your readers. When custom domains were first developed, they didn't provide the same thoughtfulness - the ability to (optionally) redirect "www.mydomain.com" to "mydomain.com" (or vice versa) wasn't added, as an option, until much later, and after a lot of pleading by the blogger community.

The great majority of all bloggers consistently select the "Redirect mydomain.com to www.mydomain.com." option, when setting up their custom domain publishing. It's also possible that Blogger has, maybe not intentionally, enabled that option by default, in some (though maybe not all) custom domain scripts.
I am trying to use the custom domains option to publish my blog but I keep getting the 'Another blog is already hosted at this address' error.

Tuesday, November 04, 2008

DNS - The Backbone Of Google Custom Domains

DNS, or the Domain Name System, is an important component in Blogger, and an essential component in a Blogger blog published to a Google Custom Domain. Whenever someone reports a problem with a custom domain published blog, I start my reply with a DNS analysis. Generally, I use an excerpted Dig log, and / or an HTTP trace, to show the problem objectively.

To understand the importance and meaning of the DNS analysis that I provide, you need to know several things

For insight in how DNS works, I'll offer you several external articles, of differing technical depth. As always, I'll alphabetise this list, so examine each one in turn.
And, you are welcome to "Google It", for possibly more discussions.

Now those of you with a plain old Blog*Spot blog are probably thinking
Hey what the heck Chuck, why should I care about this?
because native Blog*Spot blogs use Google DNS. Google provides addressing information for all web pages within the "*.blogger.com", "*.blogspot.com", and "*.google.com" name spaces. If your blog is still published to Blog*Spot, you have no need to read any further.

Blogger / Google does not provide addressing information for any web pages outside the "*.blogger.com", "*.blogspot.com", and "*.google.com" name spaces. They have no legal, moral, or technical justification for providing any such information, so they leave that to the public DNS infrastructure, and simply say
Point an address, in an external DNS server, to our servers, and we will take it from there.
Non BlogSpot URLs, whether they address content starting as a Blogger blog, a WordPress blog, or a Yahoo page, are all maintained in the public DNS infrastructure. Some URLs may even point to a domain that contains all 3, or more.

To setup a custom domain, you (or a third party, maybe a Blogger script like "Buy A Domain For Your Blog") has to setup the DNS configuration for your domain, in the DNS servers provided by your DNS Hosting Service. Separately, you may examine some righteous solutions, and alternately, some spurious solutions, showing the right ways and the wrong ways, respectively. Remember, for best results, pair the DNS entries properly, and avoid forwarding, DNS based or otherwise.

You may, depending upon your need and current availability of Google servers, choose any one of several reliable DNS configurations.

Having setup your DNS, you publish your blog. If you see a well known error
Server Not Found

Error 404
you

>> Top