Blogger Magic - The Custom Domain Root Redirect

When you setup a custom domain, for a Blogger blog, the DNS addresses are the most important issue.

A close second in importance, to righteous DNS addressing, is redirecting the domain root to the published URL. We see frequent problem reports, in Blogger Help Forum: Get Help with an Issue.

Why does my domain only work, with the "www" in the address?

The domain root provides a backup to the published URL, in many domain setups. If the domain root is not redirected, and DNS for the "www" or other published alias is down, the domain is down.

With the proper DNS addresses in place, redirecting the domain root is a very simple process.

Start from Settings - Basic.

Start from the dashboard Settings - Basic page.

Click on "Edit" in the Publishing "Blog Address" wizard.

With this blog, I have the option to select "Redirect nitecruzr.net to blogging.nitecruzr.net."



You can only redirect the domain root - no virtual hosts.

Generally, you would publish to "www.mydomain.com" - then you would have the option to "Redirect mydomain.com to www.mydomain.com".

Note that you can only redirect the domain root - even if you publish to a virtual host, such as "www.blog.mydomain.com". "blog.mydomain.com" and www.blog.mydomain.com" are separate hosts - and cannot be aliased.

Whatever you have, the option will work best, when you start with righteous DNS addresses.

---

Given righteous DNS addresses, publishing a #Blogger blog to a custom domain will produce a more stable blog, with the domain root redirected to the published URL. As the blog owner, you need to be sure to select the redirect option.

Don't Try To Split The Custom Domain Root URLs

Some blog owners publish both a blog and a website - and combine the two in the domain root / www host address pair.

This technique, while apparently reasonable, will eventually lead to confusion from the blog readers - and / or anguish by the blog owners.

Some readers, using a browser or DNS client that aliases the domain root and "www" host, will find that the website will come up, when the blog is referenced, or vice versa. And some blog owners may find, once more, another case of "Another blog ..." / Key already exists ...", when examining or publishing to the domain.

In neither case will the blog owners or readers be pleased.

We've known, for a while, about browsers and possibly DNS clients, that alias the domain root and the "www" host.

The domain root and "www" host are aliased, in some systems.

The practice of aliasing the domain root and "www" host has been common, with some webmasters, for years. Firefox - and possibly other web browsers and some DNS clients - have used the domain root, and "www" host, to back each other up.

The standard DNS setup for custom domain publishing, as provided by Blogger "Buy a domain", included a set of "A" addresses to define the domain root - and a "CNAME" to define the "www" host - whenever "Buy a domain" was provided as an option for Blogger blogs.

We've seen domain aliasing cause problems, with improperly domain root setup.

I have advised many custom domain blog owners, who have purchased domains directly from a registrar, to add the 4 x "A" records (when not defined - or when improperly defined), when reporting a "404" from the "www" host. Many times, the "404" has been resolved - even with the "www" host already properly defined, in DNS.

If you split your domain between a blog and a website, your readers may suffer.

If a domain is defined with a (non Blogger) website published to the domain root, and a Blogger blog published to the "www" host - and there is a problem accessing the "www" host - some browsers / DNS clients will automatically try accessing the domain root. This will happen, without decision by the computer owner.

If your reader is trying to access the blog (published to the "www" host) - and the browser displays the website (published to the domain root), this will lead to confusion.

It may seem like the domain root and "www" aliases are separately addressed domain components - but this may not, in reality, be true. The sanity of your readers many make this an important issue.

Besides the three supported Blogger configurations, there are an additional three variants, which support a non Blogger website combined with a Blogger blog. For best results, use one of the three identified configurations.

'Good Enough' Never Is, With Custom Domains

This month, we're seeing an interesting collection of problem reports, in Blogger Help Forum: Get Help with an Issue, about custom domain setup.

Why is my blog offline - occasionally?

And

Why do some (just some!) of my readers tell me they can't see my blog?

Investigating the problem, we see that the domain is, indeed online - some of the time.

Investigating the DNS addressing, robustly, we find an all too frequently seen set of name servers:

mydomain.com. 14400 IN A 216.239.32.21
www.mydomain.com. 14400 IN CNAME ghs.google.com.

What we see here is a domain, setup by someone who thought that one server would be 'good enough' to get by.

One server will, sometimes, get by - for a while, and for some people.

What some blog owners fail to realise, though, is that DNS service is never the same, all over the world (or the Internet). People in some places will use one DNS name server - and people in other places will use another.

And similarly, DNS service is never the same, from day to day. Today, you might need the services of one DNS name server, and tomorrow you might need another.

This month, we're seeing a number of reports that suggest that the Google name server at "216.239.32.21" is not responding for everybody. Now - don't everybody, who has a custom domain published Blogger blog start spitting coffee, and calling their registrar for emergency support.

People who have a properly setup domain should not worry, needlessly.

mydomain.com. 14400 IN A 216.239.32.21
mydomain.com. 14400 IN A 216.239.34.21
mydomain.com. 14400 IN A 216.239.36.21
mydomain.com. 14400 IN A 216.239.38.21
www.mydomain.com. 14400 IN CNAME ghs.google.com.

People with domains that provide a robust set of addresses are in better shape. The odds that all 4 name servers will fail, simultaneously, is near zero. It's much better than those with one name server, that is 'good enough for me' - and that, right now, provides the basis for this post.

Really, folks.

mydomain.com. 14400 IN A 216.239.32.21
www.mydomain.com. 14400 IN CNAME ghs.google.com.

One "A" name server was good enough for you, last month. It's not, now. How many of your readers, since last month, saw

404 Not Found

How about your search reputation. What happens, when your blog is being indexed, and the search engine gets

404 Not Found

Neither your readers, nor the search engines, appreciate

404 Not Found

And both will react, negatively - and you won't like the results.

'Good enough' isn't - for everybody, all of the time. And this affects the reputation of your blog, both with people, and search engines.

Why Are Some Custom Domain Published Blogs Inconsistently Online?

I've been using affinity analysis, and differential analysis, as tools for diagnosing intermittent problems with custom domain published blogs, for several years.

Some people may be using a browser which is more forgiving of DNS problems than others - and people who use the right browser, when accessing a domain with righteous DNS addresses, should expect to generally get more consistent service. But that's only a small part of the story.

DNS is the basis for custom domain publishing - and DNS is used in a number of ways. This creates a number of bases for inconsistencies.

• Inconsistencies From The Browser
• Inconsistencies From Individual DNS servers
• Inconsistencies From Large ISP DNS Servers
• Inconsistencies From The Google Name Servers
• Inconsistencies From WorldWide DNS Services
• Inconsistencies From The WorldWide Internet Infrastructure

The Browser
Some browsers, if they have a problem getting an IP address for the domain root (using the 4 x "A" servers) may automatically use the "www" alias.

If your domain provides only 1 x "A" address, it may be more susceptible to problems, when this aliasing of the domain root and "www" host are in use - since an outage which involves 1 "A" server may be more common than an outage which might involve all 4 x "A" servers simultaneously.

If your domain is not setup with both the domain root and "www" host properly addressed - or if the domain root to "www" host redirect is not enabled, the domain may not perform consistently.

Individual DNS servers
No people (you, or your readers) access the domain registrar's servers directly, to get the address of your domain. You use "local" DNS servers - the DNS severs provided by your ISP (or maybe a custom third party service like like GoogleDNS or OpenDNS). The "local" DNS servers that you use retrieve DNS addresses from the "authoritative" DNS servers provided by the registrar. The registrar servers reference the 4 x "A" / "CNAME" servers, provided by Google, using "referral", to get the address of your blog.

The servers that you use only access the registrars servers periodically, thanks to DNS cache. That's the mysterious TTL, which your domain's authoritative DNS servers specify. If the address for your domain is in cache, on any local DNS server, and cache is not expired (the address was retrieved any time in the previous TTL period) the local DNS server that you use simply issues what it already has.

Since almost every different reader of your blog uses a different "local" DNS server, you're going to see inconsistency in problem reports, from your readers.

Large ISP DNS Servers
If your domain is popular, people accessing your domain from a large ISP - or an ISP that is close to you geographically (if your readers are geographically concentrated) - is more likely to have the DNS addresses, for your domain, in cache. In this case, no retrieval from the registrar's servers will be necessary. The higher the TTL, the greater the chance this will be the case.

The Google Name Servers
If your readers are accessing your domain using the "www" alias, they are using the "ghs.google.com" name server for accessing your blog. The design of "ghs.google.com" means that everybody on the Internet, accessing any Blogger blog published to a custom domain, uses the same DNS addresses, cached locally. This too means that large ISPs - who are more likely to have somebody (if not you) accessing some Blogger blog published to a custom domain - are more likely to have the address for your blog in cache.

Your blog, and your domain, are addressed separately, and require separate DNS servers. This is why a righteously addressed domain uses "CNAME" referral, when mapping your domain to your blog. And this is why you have to purchase (or setup) DNS hosting, when you register your domain.

WorldWide DNS Services
Some of the 4 x "A" and "CNAME" servers, provided by Google, are not completely unique. Many large DNS infrastructures - like those provided by eNom, GoDaddy, and Google - have "unique" IP addresses replicated worldwide, using "Anycast DNS". This feature can sometimes create regionally concentrated outages, with some domains - as we have seen periodically, with eNom.

The WorldWide Internet Infrastructure
The combinations of browser used, domain popularity, ISP size (customer population), and regional outages, will always cause discrepancies between domains, and people in different locations and using different ISPs. What you (one person) see, where you are, may be completely different from what one of your readers (or my readers) sees, when using a different ISP, in another country, and a different browser.

Thanks to the transient nature of IP networking, you may "test" or observe problems over minutes or hours - but many DNS problems can appear and disappear in seconds. That''s in spite of what you would expect from cache / TTL latency.

All of these seemingly insignificant details, when fully understood, may help to explain why I continually insist on using righteous DNS addresses, whenever a custom domain publishing problem is encountered. Righteous addresses won't necessarily solve all of the above problems - but it may eliminate some of the inconsistencies, and make it possible that we could, eventually, diagnose the problem.

>> Top

The Domain Root ("Naked Domain") May Not Be Optional

One of the most consistently seen complaints, in Blogger Help Forum: Something Is Broken, involves blog owners who can't get their blogs working, using custom domain publishing.

Thanks to undertrained tech support staff, a common feature at too many registrars, the most common cause of custom domain problems involves failure to use "CNAME" referral - or "CNAME" referral targeting the wrong destination. Both use of forwarding, and "CNAME" referral to the domain root, is seen too often.

www.mydomain.com.  1800  IN  A  64.202.189.170

or maybe

www.mydomain.com.  1800  IN  CNAME  mydomain.com

Please, don't use either of the above address models!

Unfortunately, even with the blog properly published to the "www" alias - and with the "www" alias using "CNAME" referral, targeting "ghs.google.com" - we still see problems. With neither of the above mistakes made.

The most essential requirement, for a stable custom domain, is "CNAME" referral, targeting "ghs.google.com".

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

or alternately,for Google Domains and similar setups,

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

or possibly

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

Please, use this address model! This is where a properly addressed domain starts.

Properly setup DNS addresses won't avoid all DNS related problems.

Some domains have properly setup DNS addresses - but still have problems. DNS is a complex - and essential Internet service. Even with DNS addresses properly setup, all DNS servers, worldwide, won't be constantly operational.

Here's one exercise, using my domain, as an example. Click on each of the following URLs, one by one - and examine the map.

https://www.whatsmydns.net/#A/nitecruzr.net
https://www.whatsmydns.net/#A/www.nitecruzr.net
https://www.whatsmydns.net/#CNAME/www.nitecruzr.net

You'll hopefully see a lot of green check marks - and you'll probably see one or two red "X" marks too. Those red "X" marks represent a DNS server, somewhere, returning "404 Not Found" for my domain. Your domain will return similar (probably not identical) results, at any time.

If your domain is properly setup, your potential readers, hopefully near one of the green check marks, should be able to read your blog. The red "X" marks, unfortunately, are a normal part of Internet life.

We may see obvious problems, when looking at the domain root. Mistakes setting up both the domain root, and the "www" host, are well known. But why do mistakes with the domain root seem to affect us, when we access the "www" host?

Some browsers automatically use the domain root and "www" alias, equally.

If Firefox is involved, an improperly setup domain root can be involved in problems. We've known, for many years, that Firefox aliases the domain root and the "www" host. If the "www" host has a problem, Firefox will attempt use of the domain root. When there's a problem with the "www" host, if the domain root is improperly setup, the blog will be offline.

Whenever any problem is reported with a blog published to a custom domain, I routinely check both the domain root and "www" host - even when the blog owner explicitly reports using Chrome, Internet Explorer, or Safari - and even when the blog owner reports publishing to the "www" host.

99% of the time, when the blog owner is able and willing to fix discovered problems with DNS addresses for the domain root, the problem at hand will be solved. That is when we see the benefit of having the domain root and the "www" host aliased, and backing up each other.

Why do we see problems with the domain root, with the "www" alias involved?

Why does a problem with the domain root seem to affect use of the "www" host, for multiple browsers - not just for Firefox? Pick one.

• Other browsers - not just Firefox - alias the domain root and "www" host.
• Some operating systems alias the domain root and "www" host.
• Some DNS servers alias the domain root and "www" host.

Whatever the case, I suggest that DNS addressing of the domain root should not be treated as an option, when setting up a custom domain. If you want a stable custom domain, there are but 3 DNS models, that you can use reliably - instructions provided by Blogger not withstanding.

Having setup either the "Symmetrical" or "Asymmetrical" DNS models, always remember to select the "optional" domain root redirect.