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.  1800  IN  A
or maybe  1800  IN  CNAME
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 "" - we still see problems. With neither of the above mistakes made.

The most essential requirement, for a stable custom domain, is "CNAME" referral, targeting "".  3600  IN  CNAME
or alternately,for Google Domains and similar setups,  3600  IN  CNAME
or possibly  3600  IN  CNAME
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.
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.