When Correcting A DNS "CNAME", Maybe Delete Before Adding

Very few registrars allow multiple "CNAME" addresses, for a single DNS host.

When I diagnose DNS address problems, I generally recommend

Add the addresses highlighted in green.
Remove the addresses highlighted in red.

I find that it helps to have the old address visible, while the new address is being composed. This does not always produce the desired result, unfortunately.

Many registrars do not allow multiple "CNAME" addresses, for DNS hosts - and the zone editors reject new address attempts.

When DNS addresses for a Blogger custom domain need to be corrected, I recommend

Add the addresses highlighted in green.
Remove the addresses highlighted in red.

I recommend correction in this order, so the blog owner can view the current (incorrect) addresses, while adding new (correct) addresses. This compensates for various zone editor syntax oddities.

Making corrections in this order - adding correct addresses, then removing incorrect addresses - does not always produce the anticipated results. If the zone editor checks as each individual address change is made, we see the result.

"That name is reserved (already in use)."



Some zone editors check, immediately, when a second "CNAME" is entered, for a given "Host" address. When multiple "CNAME"s are forbidden, and the zone editor checks for multiple "CNAME"s immediately, we have a problem.

Other zone editors check for a correct address complement, when Saving multiple zone editor changes - after all additions and removals are successfully made and verified. These zone editors do not present a challenge - as long as the blog owner removes all incorrect addresses.

When the incorrect addresses are not removed properly, we see the result.

That name is reserved (already in use).

This leads the blog owner to cancel the recommended correction - and we wait, in vain, for the domain to come online.

In a worse case scenario, we can even end up with another case of "Another blog ...".

Right now, though, we can only diagnose the problem, one domain at a time.

---

Some registrars have zone editors which forbid multiple "CNAME"s for specific addresses - and check, one entry at a time, for mistakes. This may cause a problem, with a #Blogger blog owner making custom domain DNS address corrections, when instructed to "Add addresses highlighted in green.", then "Delete addresses highlighted in red."

Custom Domain Publishing, And DNS Latency

The Internet is diverse and large - and the Internet directory system, aka the DNS Infrastructure, supports the diversity and size.

When we setup a new domain, the registrar frequently advises us to wait patiently, before continuing.

Congrats on your new domain! Now, we suggest that you wait 24 - 48 hours for the new domain to propagate, before trying to publish to the domain.

When we update a domain - and add or delete a single DNS address - we won't always get advice about waiting, from the registrar.

Responsible helpers will occasionally provide advice to be patient, in Blogger Help Forum: Get Help with an Issue.

After you correct the addresses, please wait 8 hours (2 x "14400" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.

This advice is generally given, for domains that use a 4 hour ("14400" second) or greater Time To Live or TTL.

Many registrars use a 1 ("3600") or 2 ("7200") hour TTL, for individual domain DNS addresses. Domains with 2 hour or less TTL generally do not require latency advice, because most forum topics take more than 2 - 4 hours to complete.

Adding a domain - and updating a domain - involve different latency.

The difference between "new domain" and "domain update" advice - and irregular presence of either - causes confusion.

Some advice about domain updates involves unnecessary waiting. In other cases, new domain owners jump right in, and try using their new domains, immediately - and regret later.

Moving too quickly, with Blogger custom domain publishing, can lead to Google database corruption. Fear of the apocryphal "Another blog ..." error - and similar Blogger access disruptions - leads many technical helpers to routinely advise unnecessary waiting periods.

People who make changes, and see their changes work immediately, cause similar confusion. Somebody who is advised to wait 2 to 4 hours, before publishing the blog to the domain - and who observe that the domain, perversely, is immediately operational - may misunderstand.

Remember that everybody who wants to read a blog won't have the same DNS service. Differences between one reader (or search engine), and another, will cause various confusions.

Waiting too long wastes time - but not waiting long enough can cause worse problems. For best results, there will be unnecessary waiting, sometimes.

Just be aware of the different latency periods - and try to provide relevant advice.

• Domain addition latency can be 24 to 48 hours ("86400" to "172800" seconds).
• Domain update latency can be 10 minutes, to 48 hours ("600" to "172800" seconds).

Domain addition latency can be 24 to 48 hours ("86400" to "172800" seconds).

Domain addition latency results from the different name servers - and server owners and update policies - all over the Internet. Any given name server updates their local domain master database periodically, by retrieving the zone file from the various master name servers.

If the domain master database on a given server is updated daily - and if your domain was setup 1 minute after the daily update, your domain will not be added to that server until the next daily update.

Now consider that there are thousands of name servers, owned by hundreds of registrars, ISPs, and other Internet services. All local name servers are updated on a schedule considered appropriate, by the owner of each service.

For best results, your domain needs to be indexed on any name server that might be used by any one of your readers - or any one of the search engines that provide necessary search results, for any one of your would be readers. Do you see the possibilities for confusion, for any new domain?

This justifies waiting "24 to 48 hours", so your new domain will be visible to everybody, at the same time. This strategy hopefully will prevent possible Google database corruption.

Domain update latency can be 10 minutes, to 48 hours ("600" to "172800" seconds).

Update of individual DNS addresses will generally be more prompt - and can be researched, using a Dig log or similar display. The TTL latency for any given DNS address - unlike the domain master updates - can be easily adjusted, and determined.

As an example, here is the DNS address which controls visibility of this blog, as shown in a Dig log.

See the "3600" for "blogging.nitecruzr.net"?



See the "3600" for "blogging.nitecruzr.net"? That tells us that "blogging.nitecruzr.net" updates on a 1 hour (3600 second) basis.

All things being equal, and every name server on the Internet properly updating, if I was to correct addressing for "blogging.nitecruzr.net", every name server would be issuing the updated Blogger addresses within 3600 seconds - and the average latency would be 1/2 hour. To increase reliability when advising address correction, I would advise

After you correct the addresses, please wait 2 hours (2 x "3600" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.

Since most Blogger forum discussions about DNS addressing take place over hours or days, a 1 hour latency is generally inconsequential. Keeping it simple, I don't bother with a 1 to 2 hour latency, when providing address correction / update advice.

A 4 hour or greater latency, on the other hand, I generally mention in my advice.

After you correct the addresses, please wait 8 hours (2 x "14400" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.

When adding a DNS address, as part of address correction, latency will be close to 0 seconds. If you need to retrieve an address for a new host, just defined by the blog owner, you'll either get it immediately from cache on the local name server, or from the local server requesting an immediate update from the domain master server.

Deletions and updates, which reference out of date / redundant addresses, are subject to address latency.

Understand the different latency numbers.

Additions are only relevant for NEW domains - and they lead to the "24 to 48 hour" advice, as the latency involves the Internet infrastructure in general. Address corrections are relevant for UPDATED domains, such as DNS address corrections - and latency is involved on an individual address basis.

By being more selective when we advise waiting "24 to 48 hours", we can provide more consistent and vigourous testing advice - and encourage more effective domain additions and updates. And this will be better for custom domain publishing, in general.

Need More Detail?

For more discussion, you can read:

• Ezine: DNS Propagation Explained - or Why You Have to Wait the 72 Hours
• InterMedia: What is DNS propagation?
• WebHosting: What is DNS propagation and why does it take so long?
• WikiPedia: Domain Name System

And, try these DNS Propagation Checkers, for experimentation.

• dnschecker.org
• preshweb.co.uk
• whatsmydns.net

---

Not every Blogger blog owner understands the cause, and the effects, of DNS latency - or the detail that there are multiple latency figures, which affect custom domain publishing in various ways.

To better plan a custom domain update, it is good to understand the different causes of latency.

The Mysterious "Destination" / "Points To" Label

Some blog owners buy domains, for publishing a Blogger blog, and ask about how to address the domain.

What address do I use for "Points to"?

Other owners may ask a similar question, referencing "Destination" or maybe "Target".

There is no real difference, between all 3 labels. "Destination", "Target", and "Points to" all refer to the same DNS address value.

To compound the confusion, 4 different addresses are required, when addressing a Blogger custom domain root.

Defining the DNS servers used by the domain root ("naked domain") requires 4 address records - and the labels used, in the zone editor, will vary from registrar to registrar.

We know of 3 different labels, used by Blogger custom domain instructions.

The referential Blogger document How do I use a custom domain name for my blog? uses 3 labels to identify the 4 name servers, which are provided by Google. Blogger uses the triplet label "Destination, Target, or Points to" as their example.

Note that not all registrars use "Name, Label, or Host" and "Destination, Target, or Points to" - because not all registrar zone editors display addresses in a neat column based display.

Google provides 4 name servers, to give us multiple redundancy.

Google provides four mutually redundant individual servers, each responding to a specific IP address - for custom domain clients to address the domain root, in a round robin sequence.

There are 4 name servers provided by Blogger, to address a custom domain root.



Each domain root name server entry uses 2 important label values ("Name, Label, or Host" - and "Destination, Target, or Points to") - with a zone editor that displays addresses in columns.

Each label may have 1 of 3 values, depending upon the zone editor provided by the registrar.

Here is the Dig Log, for the domain root. Look at the 2, 4, 6, and 8, in the 4 address entries.

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

In the GoDaddy zone editor, you'll see these entries depicted as

  Host   Points to           TTL
  @      216.239.32.21    1 Hour
  @      216.239.34.21    1 Hour
  @      216.239.36.21    1 Hour
  @      216.239.38.21    1 Hour

The GoDaddy zone editor uses the labels "Host" and "Points to".

Similar labels ("Name", "Label" and "Destination", "Target") are used by various other registrars, in their own zone editor.

A Zone Editor display, showing the base DNS addresses, for GoDaddy.

Here is the display, used by GoDaddy, for "nitecruzr.co.uk".

Here is the zone editor display, as provided by GoDaddy.
Do you see the 4 address records, beneath "Points to"?



The labels in the address records differ, from registrar to registrar. The "Name, Label, or Host" address values (here, shown as "@") will differ, from registrar to registrar - but the "Destination, Target, or Points to" address values will not differ. A properly addressed domain will have the same 4 "Destination, Target, or Points to" address values, as every other properly addressed domain.

mydomain.com. 3600 IN A 216.239.3n.21

Each address will have one of four values for n: 2, 4, 6, or 8.

Complementing "Destination, Target, or Points to", we have another label set.

Complementing the 3 "Destination, Target, or Points to" label address values, for addressing the 4 name servers provided by Google, we have a similar set of 3 "Name, Label, or Host" label address values.

Addressing "Name, Label, or Host" is somewhat simpler - as all 4 entries are identical to each other, for any domain root address entry.

The Blogger instructions, like the GoDaddy zone editor, use "@", when addressing the domain root. The zone editor value used, however, may differ from registrar to registrar.

Any blog owner, wishing to have a working custom domain, needs to understand how to setup a domain for the registrar involved.

The end result.

Both the "Name, Label, or Host" - and the "Destination, Target, or Points to" - label triplets are only examples. Other unidentified registrars may use other labels.

Some registrars - such as 1and1 in their instructions 1&1 Help Center - Enter a CNAME for Your Subdomain - do not use a column based display. Neither "Name, Label, or Host" or "Destination, Target, or Points to" is part of the 1and1 instructions.

Considering the Blogger instructions, and the terminology required, Blogger Help Forum: Get Help with an Issue will not soon run out of blog owners, requesting assistance for making their custom domains work.

---

Some #Blogger blog owners, in the process of setting up their blogs using custom domain publishing, find that labels "Name", "Label", or "Host" - and "Destination", "Points to", or "Target" - are only examples, in the Blogger Help document.

There is no attempt at standardisation, used by the thousands of different Internet registrars, in their dashboards (aka "zone editors").




https://productforums.google.com/forum/#!category-topic/blogger/kMDo0O1xtDM

Custom Domain Setup, And The Blogger Instructions

Custom domain setups continue to confuse blog owners - and lead sometimes to frustration, expressed in Blogger Help Forum: Get Help with an Issue.

When I am trying to set up a custom domain for my new blog, I'm not getting the 2nd CNAME Record, but the settings get saved.

In some cases, the domain may be operational - and other times, the domain will be broken, and no corrective instruction is provided.

The details in the instructions, Blogger Help: How do I use a custom domain name for my blog?, are misleading - and have resulted in broken domains.

The Blogger instructions are confusing.

5. Go to your domain registrar's website and locate the DNS (Domain Name System) settings in the control panel.

Not a lot of details, there.

10. Before you move onto the final step, wait about an hour for your DNS settings to activate. If you attempt the final step before your settings are activated, we'll let you know with a warning message.

All registrars don't use "3600" second TTL.



That's 2 examples of possible problems.

Publishing a blog to a custom domain is so much easier - and produces more reliable results - if you follow basic principles.

• Learn to use your registrar's zone editor.
• Learn to read a Dig log.
• Setup the DNS addresses, for your domain.
• If necessary, add domain ownership verification.

Learn to use your registrar's zone editor.

The registrar dashboard / zone editor is the portion of the registrar's website, that is created to let you, the domain owner, setup your own domain.

The zone editor is unique, for every different registrar - just as every website is different. One of the signs of uniqueness is hinted, by Blogger.

Each CNAME is composed of two parts - Name, Label or Host and Destination, Target or Points to.

These two (only two) terms here refer to the most essential details, in the zone editor, that make your domain operational. The two details have no consistent names - so we use examples.

The first CNAME is the same for everyone, Name being "www" and Destination "ghs.google.com."

That one sentence is the most essential, for all domains. It looks so simple - but it's so easy to get it wrong. Not every blog owner will see "Name" and "Destination" in the zone editor display. This leads to many imaginative - and wrong - alternatives.

Each registrar labels their zone editor, as they see fit. I've seen other terms used, in addition to the 6 implied. Both "Name, Label or Host" and "Destination, Target or Points to" are merely three examples, for each of these two essential elements.

These details are only hinted, by the Blogger instructions.

5. Go to your domain registrar's website and locate the DNS (Domain Name System) settings in the control panel.
6. Now it's time to enter the CNAMEs. Where it says Name, Label or Host simply enter "www" and list ghs.google.com as the Destination, Target or Points to.

Learning how to look, in the zone editor, is much more reliable than being told what to look for.

Learn to read a Dig log.

Compared to the confusion behind the registrar's zone editor, a Dig log is simplicity.

There are three basic DNS configurations, which produce a reliable domain for publishing a Blogger blog. 99.99% of all blog owners will use only one of the three.

ourdomain.com. 3600 IN A 216.239.32.21
ourdomain.com. 3600 IN A 216.239.34.21
ourdomain.com. 3600 IN A 216.239.36.21
ourdomain.com. 3600 IN A 216.239.38.21
www.ourdomain.com. 3600 IN CNAME ghs.google.com.

This is the asymmetrical DNS address configuration. Excepting one known variation, the asymmetrical configuration - with no options - is most reliable.

Setup the DNS addresses, for your domain.

As long as you have access to the zone editor, and understand the above issues - "Learn to use your registrar's zone editor" and "Learn to read a Dig log" - the rest will fall into place.

Unfortunately, not everybody has zone editor access. Similar to Blogger dashboard access, registrar dashboard access is not always a done deal.

Even having zone editor access, the Blogger instructions can mislead.

8. Optional: You can also enter A-records, which links your naked domain (example.com) to an actual site (www.example.com). If you skip this step, visitors who leave off the "www" will see an error page.
9. Optional continued: After completing Step 8, enter your domain name in the format example.com, and list the I.P. addresses shown below in the "A" section. You'll need to create four separate A-records which point to four different Google IPs.

Many problems, reported in the forums, indicate that using the domain root properly is (should be indicated as) a necessity.

• Always setup the domain root, to redirect to the published URL.
• Always specify all 4 Google servers, as redirection targets.
• Never include any non Google server, as a redirection target.
• Don't forget to enable the domain root redirect.

Once again, the domain root, configured properly, should not be suggested as an option.

10. Before you move onto the final step, wait about an hour for your DNS settings to activate. If you attempt the final step before your settings are activated, we'll let you know with a warning message.

All registrars don't use one hour TTL.

Be careful of the TTL setting. Unless you know better, stick with the registrar's TTL setting - and try to understand the effects of TTL latency.

If necessary, add domain ownership verification.

Returning to the Blogger instructions, we see

The second CNAME is particular to your blog and your Google Account, and is therefore different for each person.

Not every blog owner will see the second CNAME - whether or not the domain is properly setup.

The Blogger dashboard Publishing wizard only displays the "Error 12", and the second CNAME, under specific conditions. In some cases, the blog will be published to the domain - and the second CNAME will not be provided.

You may not see the instructions for the second "CNAME", until your base addresses are right. If you need the second "CNAME", the "Error 12" display will provide details - when the base addresses redirect properly. If the blog publishes, a second "CNAME" is not necessary.

That is my suggestion. Get the addresses right, before you start - then publish to the domain URL.

If the blog publishes to the domain, and the addresses are wrong, the domain will be broken - or unreliable.

The bottom line.

It's good to have instructions, they suggest the need for proper domain setup technique. Just don't be surprised if following them blindly gives you a broken domain - and an offline blog.

If you are lucky, the blog will appear offline immediately after using the Publishing wizard - and you will know that there is a problem to be fixed. Other times, you (or some readers) might not realise a problem until months or years later.

In the latter case, we'll see you, one day, in Blogger Help Forum: Get Help with an Issue.

I published my blog to my private domain, last month - and the blog pageviews have been in the crapper, ever since!

---

The instructions supplied by #Blogger, for setting up a custom domain published blog, can be misleading. Blindly observed, they can lead to an immediately offline blog - or to a blog that is online for some, and intermittently offline for others.

https://productforums.google.com/forum/#!category-topic/blogger/Jv0fT5cws3U

Don't Always Blame Blogger, With Your Blog Down!

Some of my favourite problem reports, in Blogger Help Forum: Get Help with an Issue, are about inconsistent blog online status.

It was fine yesterday. Why is it down, now?

and

I see the blog, just fine! Why are some of my readers complaining?

and

I can access it, using my phone! Why is Blogger down, on my home computer?

and

The registrar tells me everything is OK!

Whenever I see the latter report, I know exactly where to start.

Particularly when I see the latter symptom, I know exactly where to start.

The registrar tells me everything is OK!

The "registrar says" is a frequent indicator of the problem. I'm not naming names, but the initial "G" (and not "Google") is very frequently involved, in this case.

So, I start with a Dig log, for the domain. And 99% of the time, that's all that is needed.

Bogus DNS addresses are a very commonly seen diagnosis, in so many of these cases. For 99.99% of the blogs, published to a custom domain, there is simply no effective substitute for the "Asymmetrical DNS" setup, provided long ago.

• Maybe the blog will be up for you, and some would be readers - but others will be seeing the "404".
• Maybe it was fine, yesterday - and today it is suggesting spam and viruses.
• It will only work, for some people, some of the time. That is the only constant.

So you call the registrar - and they tell you that it has to be Blogger, because they have no problem accessing it. But the registrar is part of the problem.

The righteous address setup.

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

The domain root uses 4 x "A" addresses, accessed in a round robin sequence. And the published URL uses a single "CNAME", resolved using a complex name server array. With both domain root and "www" alias properly addressed, your blog has much better chance of being consistently and reliably accessed.

One possibly righteous address setup.

One Blogger Engineer recommended a modified version of the asymmetrical DNS setup, to be used by 1&1 customers. Only time will tell if this setup is reliable. I have seen several 1&1 customers, this year, suggesting that this is not long term reliable.

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

Some spurious address setups.

Spurious address setups are unlimited, in variety. Here are a random 3 examples, from recent forum history.

Error when adding domain

https://productforums.google.com/d/topic/blogger/WvW2yZaS-FI/discussion

When i am trying to adding the domain it shows the error
Whoops, that's an error! (bX-6g9yx1)

socialsfriend.com. 600 IN A 184.168.221.33
www.socialsfriend.com. 3600 IN CNAME socialsfriend.com.

Blogger appears to be detecting this setup as a problem - and throws a bX code, to indicate a problem.

Mobile Redirection Failure

https://productforums.google.com/d/topic/blogger/rAJgN8pYdPw/discussion

When I am on mobile on google chrome (only browser I tested).

chartlearning.com does not redirect to www.chartlearning.com on mobile.

chartlearning.com. 600 IN A 50.63.202.10
www.chartlearning.com. 3600 IN CNAME ghs.google.com.

This blog is online - and visible, using broadband - but no domain root redirection, for mobile browsing. "50.63.202.10" is not a Blogger / Google name server, and won't provide reliable redirection.

Can't publish my blog

https://productforums.google.com/d/topic/blogger/ibGqKLWXhO8/discussion

When I entered the "eac-leadership-consulting.com" domain in 3rd-party domain settings, I did not receive an error. I did not see the 2 CNAME records.

eac-leadership-consulting.com. 600 IN A 50.63.202.50
www.eac-leadership-consulting.com. 3600 IN CNAME eac-leadership-consulting.com.

This blog published - but ownership verification did not provide the required second "CNAME".

The bottom line.

There simply is no substitute for righteous DNS addressing, for custom domain publishing. Publishing to a custom domain is not a productive activity, if you cannot follow instructions.

---

The ability to publish a #Blogger blog to a non BlogSpot URL has been provided, for almost 10 years. Some blog owners still cannot setup the domains properly - and remain oblivious, when a problem arises.

Learn why there is one effective DNS address setup, for custom domain publishing.

If you want a reliable custom domain, this is the address choice.

The DNS TTL Setting Is Chosen By The Registrar

Some blog owners, publishing their blog to a custom domain, wonder about the mysterious TTL setting for the domain.

What is "3600"? Why do I see "7200" in my Dig log?

and

Why do I have to wait 8 hours, after changing my DNS addresses?

DNS latency (aka "TTL") is not understood, by many blog owners. A mistake in setting TTL can cause anger and frustration.

"Time To Live" aka "TTL" is a registrar individual setting, that is used for providing proper performance from the registrars name servers and network.

There are multiple TTL settings - and each can have a different effect on your domain.

TTL controls caching of the DNS addresses, used to access your domain.

TTL indicates how long a DNS address will remain in cache, on a computer, before that computer requests an updated value. It's an essential (but obscure) component, in setting up a custom domain.

Since you're reading this blog, your computer has the address of this blog in cache - and won't be requesting an update, until "TTL" for "blogging.nitecruzr.net" expires. GoDaddy, the registrar for "nitecruzr.net", uses "3600" seconds, or 1 hour TTL.

Your computer probably uses the nameservers provided by your ISP - and your ISPs nameservers get updates from the nameservers provided by GoDaddy. Changes to "nitecruzr.net" go from Google, to GoDaddy, to your ISP, to your computer - and TTL applies to each DNS cache.

A typical Dig log, for a domain with a low TTL value.

Look at a Dig log extract, for "nitecruzr.net".

http://www.digwebinterface.com/?hostnames=nitecruzr.net%0D%0Ablogging.nitecruzr.net&type=A&useresolver=8.8.4.4&ns=auth&nameservers=

nitecruzr.net. 3600 IN A 216.239.32.21
nitecruzr.net. 3600 IN A 216.239.34.21
nitecruzr.net. 3600 IN A 216.239.36.21
nitecruzr.net. 3600 IN A 216.239.38.21
blogging.nitecruzr.net. 3600 IN CNAME ghs.google.com.

You set the TTL, for each individual DNS address, when you setup your domain. The registrar provides a recommended TTL - but most registrars let you select a different setting, within a given range.

A lower TTL ("600" seconds or 10 minutes) provides faster refresh after a change is made - but puts more load on the registrars name servers, and requires a more responsive network.

A higher TTL ("7200" or 2 hours) provides slower refresh - and puts less load on the registrars name servers. And when a change is made, by Google, a higher TTL can cause problems.

If you don't understand DNS, you will be better off not changing from the registrar recommended setting. Some registrars won't even have a TTL setting, in their zone editor - and others may hide it, behind an "Advanced" menu or similar.

If you generate a Dig log for your domain, you'll see the TTL settings for your addresses.

A typical Dig log, for a domain with a high TTL value.

Look at a Dig log, for "rockchickenz.com".

Here, the current DNS addresses (correction pending).

Here, we see a TTL of "14400" (displayed as "14399") - or 4 hours.

rockchickenz.com. 14399 IN A 78.137.164.51
www.rockchickenz.com. 14399 IN CNAME ghs.google.com.

For best results, we suggest that you wait 2 x TTL, after making DNS changes.

I recommend waiting 2 x "TTL", after making any DNS changes, before acting from those changes. Having diagnosed the painful "Another blog ..." domain database corruption, too many times, I suggest this whenever possible.

After you correct the addresses, please wait 8 full hours (2 x "14400" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.

In many cases, TTL will be "3600" or "1 hour" - and with a typical forum diagnostic session taking several hours between posts, a one or two hour TTL is transparent to the forum discussion.

With domains using 4 hour TTL, suggesting that the blog owner wait 8 full hours after making the change, before re publishing the blog to the domain, makes sense. And a 2 full days, for "86400" seconds, makes even more sense.

And getting a righteous DNS address complement verified - before re publishing - makes the most sense.

---

DNS TTL latency, which affects accessibility of every #Blogger custom domain published blog, is not understood by many blog owners. To provide a stable domain - and a more visible blog after it's published to a custom domain - every blog owner should understand this obscure detail.

Add Your Blogger Blog To An Existing Domain

We periodically get queries from anxious blog owners, in Blogger Help Forum: Learn More About Blogger.

Can I use an existing domain, that I own for my website, to publish my Blogger blog?

The ability to use an existing domain, for publishing a Blogger blog, is one of the neatest features of Blogger custom domain publishing. It's also one of the least obvious options.

Publishing a Blogger blog, into an existing domain, is easy.

1. Add a DNS address, for the new URL, to the domain.
2. Publish the blog, to the new URL.
3. Manage the traffic, as part of any newly published custom domain blog.
4. The blog content is hosted by Blogger / Google.
5. The blog address is hosted by your DNS host / registrar.

The new domain URL will be most successful, if you understand the limitations.

DNS Addressing
Hoping that the "blog" domain URL is available, you would add a "CNAME" to the domain.

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

That is the DNS address entry for the URL "blog.mydomain.com", which will point to "ghs.google.com.". This example uses an extracted Dig log to describe the required DNS address.

That is how you add a virtual domain host, for your blog. There will be a few limitations.

• You probably won't be able to publish to the domain root, or to the "www" host. Those addresses are generally used by the website.
• If either the domain root or "www" host is used by the website, do not try to address the other.
• If the DNS host does not permit "CNAME" referral, you won't be able to create a virtual host - and you won't be able to publish your blog to the domain.

Like the normal task of setting up a custom domain, setting up an additional host in an existing domain is exceedingly simple - if you understand the rigid simplicity. Just add one host, using "CNAME" referral. For best results, do not attempt innovative addressing techniques, such as publishing to the domain root or "www" host, if either is already being used.

Since you're adding a host to an existing domain, you may not get instructions to add a second "CNAME" - even if Blogger instructions imply that you will. If you don't get instructions, you don't need a second "CNAME".

Don't try to use an alias pair - the option to refer an alias to the published URL only works, consistently, for the domain root / "www" pair. Just add a single new host, using "CNAME" referral to "ghs.google.com".

Please note the format of "ghs.google.com." The "." after "ghs.google.com" is not decorative. Be aware of how you would enter "ghs.google.com,", properly, using the zone editor provided by your DNS host / registrar.

Blog Publishing
Having added the correct virtual host DNS address to the domain, publish your blog.

Traffic Management
Get to work and manage the migration of blog traffic. For best results, combine the blog and website.

Blog Hosting
The blog content continues to be hosted by Blogger / Google - with the existing address continuing to work, and with the content unchanged. The new blog address is hosted by the DNS host or registrar.

Google Domains Is Not Yet Available, Worldwide

Some would be domain owners are reporting the sad truth about Google Domains.

I tried to use a Google Domains invitation, and got a refusal.

We're sorry. You appear to be in a country where Google Domains is not yet available. You may search for domains, but you will not be able to purchase a domain unless you have a U.S. billing address. Learn more

Get notified when Google Domains is available in your country.

So thanks anyway!

Google Domains is currently a beta product - and as of December 2017, it is available in 14 countries.

This is a normal strategy, used by Google - beta products are typically deployed on a country by country basis.

Google Domains offers distinct advantages, over "Buy a domain" and registrar direct domain purchases.

• They will control the purchase - and offer a more stable bank payment process.
• They will control the DNS infrastructure - and offer a more stable setup process, and ongoing blog access.
• They provide excellent real time support, 7 x 24 basis.

Google Domains are available in a few countries - with more being added, periodically.



As of March 2018, Google Domains may be available in 15 countries - Australia, Brazil, Canada, France, India, Indonesia, Italy, Japan, Mexico, Netherlands, Spain, Thailand, UK, USA, and Vietnam. If you live in any of the other 180+ countries, you have to use GoDaddy - or another third party registrar.

Deploying a bank payment network, and a DNS infrastructure (to name two details), on a world wide basis, won't happen immediately.

It's all too easy to overlook the international issues, when dealing with Blogger and Google. My apology to those of you who were unduly excited, for nothing.

Have patience, your time will come.

Google Domains DNS Addresses Setup

After too many years of Blogger blog owners struggling with setting up their custom domains, Google is now selling domains - though right now, in a select number of countries.

Having ended "Buy a domain", and its problems - and now dealing with blog owners setting up domains purchased through numerous registrars, and those problems - Blogger / Google has cleaned up the domain purchase and setup process.

This year, we see Google Domains - where Google actually registers domains, and can control the DNS hosting. And, they have developed a clean and lean dashboard / zone editor, for maintaining their domains.

I setup a Google Domain, several months ago.

Adding DNS addresses to a recently purchased Google Domain is quite simple. Start by logging in to Google Domains.

Once you login, you have the Google Domains dashboard Home page. Find your domain, in the list - and select the "DNS" icon,for your domain.

That gives you the "DNS" dashboard, for your domain. This is also known as the "Zone Editor", in some instructions. Scroll to the bottom of the "DNS" dashboard, and "Custom resource records".

There are the 4 x "A" + "CNAME" entries. You will have a different domain - but your address entries will be otherwise similar to what you see (with either "ghs.google.com.", or "ghs.googlehosted.com.").


Add the first address entry. Paste "216.239.32.21" into the box labeled "IPv4 address", and hit "Add".

Add 3 more addresses - "216.239.34.21", "216.239.36.21", "216.239.38.21" - in the same way. Then, change "@" to "www", select "CNAME" in place of "A" in the pull down menu, enter either "ghs.google.com.", or "ghs.googlehosted.com." into the address box, and hit "Add" for a 5th time.

Checkout the zone editor, for your domain. It should be similar to what you see, above. This is the well known "asymmetrical" DNS configuration, provided by "Buy a domain", not so long ago.

I don't think manual DNS address setup could be much simpler.

With the new domain properly addressed, wait 24 to 48 hours hours for the domain to propagate, then go to the Settings - Basic page of the Blogger dashboard.

Select "Setup a Google Domains URL for your blog", and follow instructions.



Use the "Setup a Google Domains URL for your blog" link in the Publishing wizard, in Settings - Basic to connect the blog to the domain.

Then get to work, publishing more content in your newly addressed blog.

Custom Domain Purchase, And Zone Editor Access

We periodically see signs of naivete, in Blogger Help Forum: Get Help with an Issue, about registrar dashboard access.

How do I add addresses to my domain?

or

How do I move my domain, to Square Space (Tumblr, WordPress)?

or

How do I terminate my automatic yearly domain registration?

Too many blog owners treat their registrar accounts as other blog owners treat their Blogger accounts.

When it becomes time to access the registrar's dashboard (or zone editor) too many blog owners are unprepared. Having not bothered to access the zone editor previously, they have no idea how to start - and since they now have a real need to change registration options, change DNS, migrate the domain, ... they panic. And after panicking, they blame Blogger for not telling them, long ago, to setup and maintain the registrar dashboard access account.

In some cases, neither Blogger or Google had anything to do with a domain purchase. Identifying domains purchased directly from a registrar, some time in the past, can be the first challenge, when dealing with a panicked domain owner.

There are 3 different ways that a domain may have been purchased.

1. Directly from a registrar.
2. From a registrar through Blogger / Google, using "Buy a domain ..." (Blogger) or a Google equivalent.
3. From Google, using Google Domains.

Registrar direct purchase
The process of buying a domain directly from a registrar - with registrar provided dashboard / zone editor access - is the method most used currently. It is also the method which presents us with the most challenge.

• All registrars do not provide the right options / services, for hosting a Blogger custom domain.
• Some registrars have helpful tech staff, who provide bogus advice, and ignore Blogger instruction.
• When help with correcting a bogus setup is needed, we cannot provide as complete advice, because we are not familiar with all registrar dashboards.

One of the benefits of custom domain publishing is that a Blogger custom domain is capable of working with almost every registrar in the world - and this becomes its biggest weakness.

If this will be your first domain, I recommend Google Domains - if you live in the USA. Registrar direct is a good choice, for experienced domain owners - but not for novices.

Theoretically, a Blogger custom domain is capable of working with any non Google website, in a domain cluster. Not all Google competitor services are this versatile; some services require the use of specific registrars or name servers.

Universal registrar compatibility is an advantage for Blogger - and a disadvantage too. That aside, when it comes time to renew or migrate a domain, purchased directly from a registrar, the blog owner has only to contact the registrar directly. Neither Blogger Help, Blogger, or Google is involved with registrar direct purchases.

Buy a domain
The most popular purchase method, which is no longer available. is "Buy a domain for your blog" (aka "Buy a domain") - or a Google equivalent, used by some blog owners. "Buy a domain" was a popular Blogger dashboard option, for several years. It offered an attractive package price of $10 USD for the domain, with several options that would be extra cost when buying registrar direct.

Besides the popular purchase price, "Buy a domain" provided automatic setup of the 4 x "A" + "CNAME" configuration, aka "asymmetrical" DNS configuration - with registrar dashboard / zone editor not involved. When it worked properly, domains purchased were turnkey operations. You could buy a domain now, have the blog online in 15 minutes, and have the search engines start indexing in 2 - 3 days.

"Buy a domain" did have several drawbacks, though.

• The online purchase process required two parallel processes - bank payment and DNS configuration. The two processes did not always work together.
• The purchase could be made from a limited number of countries, because the electronic international banking process did not support all countries.
• Registrar access, for "Buy a domain" purchases, was provided through the Control Panel / Google Apps dashboard. Setting up Control Panel access, using the Google Admin login, and the Google Apps domain account, was not a simple task.

Google Domains
Now, we have a third purchase method - Google Domains. A Google Domains purchase only involves the domain registration, with DNS setup done by the blog owner, using a clean and lean dashboard / zone editor. This makes the electronic banking more reliable, both domestically and internationally. Instead of using Control Panel / Google Apps, Google Domains uses the standard Google "One account" login, and the Google account that most blog owners will use for Blogger / GMail / YouTube etc.

Google Domains is a vast improvement over both registrar direct and "Buy a domain" purchases, even though it requires DNS setup by the blog owner - though right now, for USA residents only. The Google Domains dashboard / zone editor is easier to use than either of the dashboards provided by eNom and GoDaddy, the "Buy a domain" registrars. And both the flaky eNom DNS service, and the bogus GoDaddy DNS setup advice, will become things of the past.

With Google Domains using a standard Google "One account" login, neither the registrar login, nor Google Control Panel / Google Apps, will be involved to access the Google Domains dashboard / zone editor.

Using A Custom Domain Outside Blogger

From time to time, we see questions about using a Blogger / Google custom domain, with publishing services outside Blogger / Google.

Some Blogger blog owners want to combine their Blogger blogs, with non Blogger blogs and websites - and others want simply to move their blogging activity to non Blogger services. And a few think ahead, and wonder how adding or moving to another service will affect the ability of their existing readers to find their blog, and / or their ability to get new readers.

As with using a Blogger blog with an existing non Google domain, this is not a simple project - and to do this properly will require research - and well informed decisions. Some assistance can be provided by Blogger or in Blogger Help Forum: Learn More About Blogger - and other portions of the project will require advice or instruction from the support groups for the new service.

Start by deciding how the domain is to be used, with the new website.

Consider The Options

There are several ways to add / substitute a non Blogger blog / website, in a domain purchased for use with a Blogger blog.

1. Transfer domain registration, to the registrar, as required by the new hosting service.
2. Update DNS for the domain, to use name servers, as required by the new hosting service.
3. Update DNS for the domain, to use only addresses pointing to the new hosting service.
4. Update DNS for the domain, to use additional addresses pointing to the new hosting service.

Which of these options, that you are able to use, will depend upon requirements of the new hosting service.

WordPress provides detailed instructions, in WordPress Support: Coming from Blogger?. Not all hosting services will be so helpful, however.

Retain / Transfer Existing Traffic

Options #1 - #3 will require you to start a new URL, published by the new hosting service. Blogger will not permit blogs to be used as gateways. You'll have to get your new blog / website indexed, from the bottom up - with no automatic traffic from your Blogger blog.

Any followers or readers, that are associated with your Blogger blog, will have to be redirected to your new blog / website using visual instructions - or at best a clickable link, in a stub blog. You may be able to redirect subscribers - if the new host offers a compatible newsfeed.

You probably won't be able to publish your stub Blogger blog to the domain, though - so chances are, any of these options will leave you starting over - with no instructions to your existing followers and readers, excepting what you provide before moving the domain.

Option #4 will require you to add an additional host, in the domain with your existing Blogger blog. If your new hosting service supports, you may be able to make your Blogger blog and new blog / website equal members of a domain based cluster.

For a domain cluster to be really effective, you will need to maintain both the existing Blogger blog, and the new non Blogger website as separate entities - and have unique content, regularly updated for each.

Access The Current Registrar Dashboard

Whether you transfer domain hosting, or update the domain, you will need access to the current registrar's dashboard.

• For domains purchased using Blogger / Google "Buy a domain ..." or similar services, access to the registrar's dashboard will require access to the Google Apps / Control Panel utility.
• For domains purchased directly from the registrar, access to the registrar's dashboard will require an account / password that (hopefully) was setup when the domain was purchased.

You will need access to the registrar's dashboard to obtain the EPP code, required by Option #1 - or to make changes to the domain, required by Options #2 - #4.

You May Need Google Apps Access

Most projects - but not all - which involve custom domains require Google Apps access - and establishing Google Apps access is the most common concern, when access to the registrar's dashboard is needed.

1. Get access to Google Apps.
2. That will give you access to the registrar's dashboard.
3. Retrieve the EPP code, or update the DNS addresses per instructions of the additional / new blogging host service - depending upon which Option you are taking.

In some cases, and if you are considering multiple non Google services, choice of what new service you go with may start with identifying migration / setup options provided by each different service.

Regain Followers, Readers, Subcribers, Search Engine Reputation - And Traffic

A domain moved to use outside Blogger will be similar to a new blog / website - with some characteristics of a renamed Blogger blog, and / or a newly published custom domain blog. Just as all Blogger blogs are unique, so will be any domain migration.

You may consider moving existing blog content, to the new service. This will require planning, and testing.

Both the actual movement of the content - and preventing Blogger spam classification, if you move the content - will be important.

You need to understand all of these issues, to regain traffic sources. Blog / website traffic is a complex subject.

Respect Your Existing Audience

If the question of existing / new followers, subscribers, and readers, and search engine reputation, resulting from the move, is a serious issue with you, you may want to plan your move from Blogger with great care.

You won't be able to blatantly redirect your existing readers to your new website - you will need a carefully planned dual website publishing strategy.

Start With The Support Group For The Chosen Service

If you are going to host a blog or website outside Blogger / Google, you must start with instructions from the support group for the new blog / website. DNS is a key issue, in any domain migration - whether BlogSpot to non BlogSpot, or non BlogSpot to non Google.

---

Occasionally, a #Blogger blog owner decides to move their blog to a non Google website. Starting with advice in Blogger Help Forum, the owner learns that many necessary decisions, related to a hosting change, require support from the new website host.

Not every blog owner realises why setting up and publishing a Blogger blog is so simple, until they have to make decisions about hosting outside Google.

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.

The Google Apps "Advanced DNS settings" Wizard Does Not Provide A Link To The Registrar

We're seeing reports from some blog owners, who purchased custom domains through Blogger / Google, who are unable to access the registrars zone editor through Google Apps.

Owners of blogs published to custom domains, where the domains were purchased through "Buy a domain", need to use the registrars zone editor to maintain their domains. In the past, the zone editor could be accessed from a link in the "Advanced DNS settings" wizard in the "Admin console" / Google Apps dashboard.

The "Advanced DNS settings" wizard provides important tokens, to let the owner of a domain, purchased through Blogger / Google, interact with the registrar. Besides the tokens, there is a link, captioned "Sign in to DNS console", which should lead directly to the sign in screen provided by either eNom or GoDaddy.

Right now, the "Sign in to DNS console" link leads back to the "Admin console" dashboard. This does not help the domain owner.

Having discussed this issue with a Google Apps Top Contributor, it appears that the only way to login, right now, is using the correct registrar login screen. The link must be properly selected, according to the registrar who hosts the domain.

• eNom
• GoDaddy

These two links, properly selected, should permit owners of domains, purchased using "Buy a domain", to access the zone editor of the respective registrar.

The domain owner will still have to access the "Advanced DNS settings" wizard, to retrieve the "Sign-in name" and "Password" tokens, which are unique to each domain. The tokens, once retrieved, will be used on the appropriate eNom / GoDaddy login screen, as linked above.

>> Top

eNom Hosted Custom Domains Showing Intermittent Connectivity Issues

We are seeing reports from owners of several Blogger blogs, published to custom domains, of intermittent connectivity problems, reported in Blogger Help Forum: Something Is Broken.

Recently, I have been unable to load my custom domain blog www.mydomain.com. My browsers (whether Chrome, Firefox, Safari, etc.) all tell me they are "unable to find the server". Various online utilities report problems also. I am able to get to Blogger and my dashboard for the blog, but nothing will load the page. All other services on my computer appear to be working normally.

The problem appears to be somewhat intermittent and varying across different ISPs, and various online utilities which I use.

The domains being reported all appear to be registered with eNom - and at first glance, domain registration appears normal. We have to do some detailed investigation to identify a consistent detail, which appears to be common to all individually reported domains.

At first glance, the typical eNom registered domain - even those with this reported problem - appears to be normal.

REGISTRY WHOIS FOR mydomain.com

Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
Status: clientTransferProhibited

Expiration Date: 2013-04-10
Creation Date: 2012-04-10
Last Update Date: 2012-04-10

Name Servers:
    dns1.name-services.com
    dns2.name-services.com
    dns3.name-services.com
    dns4.name-services.com
    dns5.name-services.com

The clue to this problem is seen in the last sentence, in the above example.

The problem appears to be somewhat intermittent and varying across different ISPs, and various online utilities which I use.

eNom uses 5 DNS servers. We can check the output from each of the 5 servers, using the Kloth online Dig utility, and specifying each server, in turn.

• Domain: mydomain.com
• Server: dns1.name-services.com
• Query: A (IPv4 address)

and repeat for dns2.name-services.com etc.

Running a Dig against each of the 5 servers, we can see a consistency problem. Here is a copy of the 5 Dig logs, concatenated.

-----------------------------------------------------------------------
     
dns1.name-services.com Dig Log

 ; <<>> DiG 9.3.2 <<>> @dns1.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43536
 ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; ANSWER SECTION:
 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
 
 ;; AUTHORITY SECTION:
 mydomain.com. 3600 IN NS dns1.name-services.com.
 mydomain.com. 3600 IN NS dns2.name-services.com.
 mydomain.com. 3600 IN NS dns3.name-services.com.
 mydomain.com. 3600 IN NS dns4.name-services.com.
 mydomain.com. 3600 IN NS dns5.name-services.com.
 
 ;; ADDITIONAL SECTION:
 dns1.name-services.com. 3600 IN A 98.124.192.1
 dns2.name-services.com. 3600 IN A 98.124.197.1
 dns3.name-services.com. 3600 IN A 98.124.193.1
 dns4.name-services.com. 3600 IN A 98.124.194.1
 dns5.name-services.com. 3600 IN A 98.124.196.1

-----------------------------------------------------------------------
     
dns2.name-services.com Dig Log
    
 ; <<>> DiG 9.3.2 <<>> @dns2.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51481
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; ANSWER SECTION:
 mydomain.com. 1800 IN A 216.239.36.21
 mydomain.com. 1800 IN A 216.239.32.21
 mydomain.com. 1800 IN A 216.239.38.21
 mydomain.com. 1800 IN A 216.239.34.21

-----------------------------------------------------------------------
     
dns3.name-services.com Dig Log

 ; <<>> DiG 9.3.2 <<>> @dns3.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9542
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; AUTHORITY SECTION:
 com.   3601 IN SOA dns1.name-services.com. info.name-services.com. 2010 10001 1801 604801 181

-----------------------------------------------------------------------
     
dns4.name-services.com Dig Log
 

 ; <<>> DiG 9.3.2 <<>> @dns4.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2101
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; AUTHORITY SECTION:
 com.   3601 IN SOA dns1.name-services.com. info.name-services.com. 2010 10001 1801 604801 181

-----------------------------------------------------------------------
     
dns5.name-services.com Dig Log
 
 ; <<>> DiG 9.3.2 <<>> @dns5.name-services.com mydomain.com A
 ; (1 server found)
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13658
 ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5
 
 ;; QUESTION SECTION:
 ;mydomain.com.  IN A
 
 ;; ANSWER SECTION:
 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
 
 ;; AUTHORITY SECTION:
 mydomain.com. 3600 IN NS dns1.name-services.com.
 mydomain.com. 3600 IN NS dns2.name-services.com.
 mydomain.com. 3600 IN NS dns3.name-services.com.
 mydomain.com. 3600 IN NS dns4.name-services.com.
 mydomain.com. 3600 IN NS dns5.name-services.com.
 
 ;; ADDITIONAL SECTION:
 dns1.name-services.com. 3600 IN A 98.124.192.1
 dns2.name-services.com. 3600 IN A 98.124.197.1
 dns3.name-services.com. 3600 IN A 98.124.193.1
 dns4.name-services.com. 3600 IN A 98.124.194.1
 dns5.name-services.com. 3600 IN A 98.124.196.1

-----------------------------------------------------------------------

Examine the Dig logs from "dns3.name-services.com." and "dns3.name-services.com.". See the answer from those servers, which returns only an "SOA" for the ".com" Top Level Domain? This is consistent of a domain, improperly setup by the registrar. In the cases reported in Blogger Help Forum: Something Is Broken, my reply is simple.

In your case, servers #3 and #4 do not appear to properly recognise your domain. Any online service, asking either server #3 or #4 for your domain addresses, will probably have problems. This may explain your inconsistent access problem. As the registered domain owner, you need to contact eNom Customer Support. Show them the Dig logs from the 5 servers, and ask them why servers #3 and #4 seem to have a problem serving your DNS addresses.

The problem appears to involve domains setup on 4/9/2012 - 4/10/2012. Hopefully, enough domain owners will report their problems to eNom Customer Support, so this problem can be investigated and resolved.

---

(Update 6/18): With a small but very intense BloggerFire which involves eNom hosted domains and apparent domain hijackings, we now have a useful diagnostic tool, to analyse DNS inconsistencies like this.

---

>> Top

Confusion Over Domains Purchased From Registrars

Blogger / Google offers the optional ability to publish a Blogger blog to any available non BlogSpot URL, aka "Custom Domain Publishing".

The process of setting up a custom domain is so simple - when we use the "Buy a domain" wizard. As simple as "Buy a domain" is, it involves details that are unbelievably complex - and too many blog owners, avoiding use of "Buy a domain", will find out about these details the hard way.

One important detail about custom domain publishing involves the level of service, as purchased from the registrar. There are three basic levels of service, offered by many registrars.

1. Name registration, only.
2. DNS hosting / Name registration.
3. Content hosting / DNS hosting / Name registration.

Choose the wrong service level, and you'll waste either time - or money. And, we all know that "time is money".

Too many blog owners, anxious to setup and show off their new, non BlogSpot URL, make the wrong choice of service.

Blog owners, unsure how to purchase their domain, become more forum noise.

They end up in Blogger Help Forum: Something Is Broken, anxiously asking

What are the nameservers used for Blogger?

or

How do I publish my blog, using the registrar's Site Builder wizard?

The mistake of purchasing the wrong service is always a possibility, when buying directly from a registrar.

Please, only purchase "DNS Hosting" - not "Name Registration"!

Since custom domain publishing was first offered as an option, I've been advising people to

Please, check the invoice or receipt from the registrar. If you purchased "Name Registration", instead of "DNS Hosting", you need to go back immediately, and upgrade your service.

GoDaddy, for instance, offers "Bring your own DNS", where they register the domain on your behalf, and you provide the nameservers. If you understand DNS, you are entitled to try this option - just please don't publish your blog and try to advertise it in Blogger Help Forum: Something Is Broken as a solution.

GoDaddy "Bring your own DNS" is not an acceptable choice.

"Bring your own DNS" is simply not an advisable option, for 99.99% of all Blogger blog owners - and we do not need people suggesting it, as an immediate choice.

The sad thing is that Blogger, in even their current tutorial (which is, itself, subject to change), makes no canonical distinction between the three levels of service that the various registrars may offer. Long ago, they simply advised

... you only need to get the domain name; you don't have to pay extra for hosting service.

With that history, is it any wonder that we should expect to occasionally see the confusion

What are the primary and secondary DNS servers?

And having purchased "DNS Hosting", the blog owner must then setup the DNS addressing.