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.

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.

Blogger Magic - Reading A Dig Log

Whether you're setting up or troubleshooting a custom domain, knowing how to read a Dig log is a useful skill.

There are hundreds of registrars, serving the Internet community, each with their own dashboard. Blog owners, setting up their domains for their Blogger blogs, must deal with the syntax and terminology used by each different dashboard.

A Dig log lets the blog owner identify the DNS addresses for the domain, using a consistent display.

By identifying the DNS addresses used in a given domain, a blog owner or an experienced forum helper can diagnose many custom domain DNS related problems.

Here is an example of Dig log use, showing an excerpted Dig log, in a typical forum topic. For more detail, see my earlier post, Diagnosing Problems With Custom Domains: Dig.

I have a domain (www.rockchickenz.com) - and want to link my blog (rockchickenz.blogspot.com).

• Start by verifying URLs involved.
• Continue with Dig Web Interface.
• A full screen print of the Dig log.
• The relevant portion of the Dig log, from the screen print.
• The relevant portion of the Dig log, as text.
• The advice provided, to the blog owner.
• Alternate / complementary tools used.

Start by verifying URLs involved.

Whenever possible, make a screen print, and a text copy, of the Blogger dashboard Publishing wizard, at Settings - Basic. Knowing the status of the blog and domain - and the exact URLs involved - can go a long way to diagnosing many custom domain publishing problems.

Continue with a Dig Web Interface log.

The best tool for generating a Dig log is Dig Web Interface. Alternate / complementary tools are listed below.

I use DWI, for this purpose, by preference. DWI lets you:

• Package the URLs in the Dig target, in the reference URL.
• Include multiple target URLs, in one reference URL.
• Both capabilities are very useful, in diagnosing Blogger custom domain publishing problems.

Start from the Dig Web Interface page.

Add the domain root and "www" alias, under "Hostnames or IP addresses:".

I select Type: "A", and Nameservers: "Authoritative", for my actual diagnoses.

Click "Dig".



The Dig Log reference URL, for "rockchickenz.com", generated from DWI. Target URLs are "rockchickenz.com" and "www.rockchickenz.com".

http://www.digwebinterface.com/?hostnames=rockchickenz.com%0D%0Awww.rockchickenz.com&type=A&ns=resolver&useresolver=8.8.4.4&nameservers=

A full screen print of the Dig log.

This is the complete Dig log, resulting from the Dig Log URL (above), and containing the relevant portion (below).

This is the Dig log, for "rockchickenz.com".



The relevant portion of the Dig log, from the screen print.

This is the important portion of the screen print (above), and showing the text (below).

This is the relevant portion of the Dig log, for "rockchickenz.com".



Note the TTL value of "14399" - which is a typical Dig log display for TTL set as "14400" (14400 seconds or 4 hours), in the registrar's zone editor. TTL is a setting which is used to adjust name server performance.

Unless you are experienced with DNS setup (and probably don't need to read this advice), you should use the default TTL provided by the registrar, for your domain. Your registrar wants to provide a stable domain for you - and the TTL value affects domain stability.

The relevant portion of the Dig log, as text.

These are the important details from the screen print (above), with colour highlights corresponding to domain specific details (below).

rockchickenz.com@8.8.4.4 (Default):
rockchickenz.com. 14399 IN A 78.137.164.51

www.rockchickenz.com@8.8.4.4 (Default):
www.rockchickenz.com. 14399 IN CNAME ghs.google.com.
ghs.google.com.  21392 IN CNAME ghs.l.google.com.
ghs.l.google.com. 92 IN A 64.233.183.121

The latter is typically seen, with a blog owner having received bogus advice - and reporting an inconsistently accessible blog.

The advice provided, to the blog owner.

The typical advice, provided to the blog owner, would include domain specific details - accompanied by a link to Setting Up DNS Addresses For Custom Domains.

First, generic advice:

Remove the addresses highlighted in red - and add the addresses highlighted in green - and keep the addresses highlighted in yellow.

Then, specific advice:

This is what you have:

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

This is what you need:

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

The advice references a typical ASymmetrical DNS custom domain setup - the address set used in 99% of all custom domain setups. Note here, the specified TTL of "14400" (4 hours).

Using the above advice, the blog owner can then, if necessary, research the syntax used by the registrar's dashboard (aka "zone editor") - and make the necessary changes.

Alternate / complementary tools used.

Alternate tools, which can be used to generate a Dig log, are the Kloth.Net Dig DNS Lookup, and the Who.Is DNS display. Neither alternate is as compact and complete - but they can be used to verify results.

Complementary tools include the Global DNS Propagation Checker, the intoDNS domain DNS health checker, the Rex Swain HTTP Viewer, and the Whois Lookup.

In some cases, my 12 link affinity / differential connectivity test may be useful.

For more information.

See WikiPedia: dig (command).

---

One of the most useful tools, for diagnosing #Blogger custom domain problems, is a Dig Log. Learning how to read a Dig Log is a useful skill, for any blog owner wishing to publish a blog to a custom domain.

A Domain Root, With Blogger And Non Blogger Hosts

Some blog owners publish a domain, and try to combine a Blogger blog, and a non Blogger website, in the domain root.

They publish one host to the domain root - and the other to the "www" alias.

This combination may be supported by the non Blogger host - but Blogger blog reliability will suffer. And the readers may become confused, when they click to view the blog, and get the website - or vice versa.

There is a special relationship between the domain root and "www" alias. Blogger takes advantage of this relationship, to provide improved reliability for a blog, when published to a custom domain.

Ignoring the special relationship, and splitting the domain root and "www" alias, leads to confusion - and decreased blog reliability.

Please don't publish two different hosts into the domain root / "www" pair.

Please, don't combine a Blogger blog and a non Blogger website, in the domain root / "www" alias duality.

There are 3 mutually exclusive configurations, for combining a Blogger blog and a non Blogger website in a domain, which will produce a reliable blog. Your readers will be happier - and the search engines will index the blog better - if you stick to one of the 3 supported configurations.

Taking the 3 supported Blogger configurations, we can add a properly published non Blogger website - and produce 3 more possible variants.

1. Non Blogger website published to the "site" alias.
2. Non Blogger website published to the domain root.
3. Non Blogger website published to the "www" alias.

Non Blogger website published to the "site" alias.

Here, the blog is published to the "www" alias, with the domain root redirected to the "www" alias - and the website is published to an additional virtual host, such as "site". This is a variant of the Blogger asymmetrical DNS configuration.

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.
site.mydomain.com 3600 IN A 162.210.101.54

Non Blogger website published to the domain root.

Here, the blog is published to the "blog" alias - and the website is published to the domain root. The website may or may not support redirection of the "www" alias to the domain root. This is a variant of the Blogger additional virtual host DNS configuration.

mydomain.com. 3600 IN A 162.210.101.54
www.mydomain.com 3600 IN A 162.210.101.54
blog.mydomain.com 3600 IN CNAME ghs.google.com.

Non Blogger website published to the "www" alias.

Here, the blog is published to the "blog" alias - and the website is published to the "www" alias. The website may or may not support redirection of the domain root to the "www" alias. This is a variant of the Blogger additional virtual host DNS configuration.

mydomain.com 3600 IN A 162.210.101.54
www.mydomain.com 3600 IN A 162.210.101.54
blog.mydomain.com 3600 IN CNAME ghs.google.com.

Your blog will be more reliably online - and your readers will be happier. And happier readers leads to better search engine indexing - and to more readers.

---

#Blogger blogs published to custom domains use both the domain root / "www" alias, for reliable connectivity. Trying to publish a blog, and a non Blogger website, to the domain root / "www" alias, leads to confusion - and decreased reliability for the blog.

CloudFlare, Custom Domain Publishing, And HTTPS

A few blog owners, who publish blogs published to custom domains, are becoming impatient, waiting for Blogger Engineering to finish the Blogger upgrade to support HTTPS / SSL.

If I get a domain through Google Domains, will I be able to get HTTPS?

Unfortunately, no. HTTPS / SSL is simply not available, to blogs published to custom domains.

HTTPS is not available, for non BlogSpot published blogs.

Whether registered by eNom, GoDaddy, or Google Domains, it simply is not possible to publish a non BlogSpot URL as a supported custom domain, and make HTTPS / SSL available. CloudFlare, a supposed alternative, does not produce a supported custom domain.

A proxied CloudFlare domain looks like malicious redirection.

In some cases, a CloudFlare DNS "solution" tried by some blog owners, will look like dangerous / malicious redirection. Some blogs will show up as "Deceptive sites", aka "phishing".

Some blogs using CloudFlare, for custom domain publishing, will be classified as "Deceptive" sites.



Others will produce alarming warnings about malware.

"This blog is not hosted by Blogger and has not been checked for spam, viruses and other forms of malware."

Click on "Details".



Look at the warning.

Phishing sites pretend to be other websites to trick you.

And there is the typical Dig log, with a redirecting proxy service, like CloudFlare.

kireisubs.id. 300 IN A 104.27.133.198
www.kireisubs.id. 300 IN A 104.27.133.198

or

topmovies21.biz. 300 IN A 104.28.0.106
www.topmovies21.biz. 300 IN A 104.28.0.106

This is the basis for malware / phishing classification.

Any observed malware warning is generally a false positive - most custom domain published blogs do not contain malware. Even so, it's not likely that the "Deceptive site" classification will be easily corrected - or the malware warning interstitial display removed.

And this is one more blog owner, who must next be provided instruction to correct the DNS addresses.

Having corrected as instructed, DNS addresses will be asymmetrical, and righteous.

kireisubs.id. 86400 IN A 216.239.32.21
kireisubs.id. 86400 IN A 216.239.34.21
kireisubs.id. 86400 IN A 216.239.36.21
kireisubs.id. 86400 IN A 216.239.38.21
www.kireisubs.id. 86400 IN CNAME ghs.google.com.

With DNS corrected, Google shows "Not dangerous" - but the warning still displays.

"Not dangerous".

Note "CloudFlare" is still seen as the host.

You can report an error, to SafeBrowsing.



False classification now requires time consuming site review.

Use "Report Incorrect Phishing Warning", if you believe the site is safe.

Finally, get the site reviewed, from the Security Issues page in Security Console (Webmaster Tools) - Security Issues.

And while the blog remains offline, search reputation - and the owner - will suffer.

---

Some #Blogger blog owners want to provide blogs published to custom domains - and offer HTTPS connectivity. Since Blogger cannot provide custom domains with HTTPS right now, the blog owners are using CloudFlare, which provides an HTTPS proxy.

Unfortunately, a CloudFlare proxy looks like malicious redirection - and blogs using CloudFlare are being labeled as "Deceptive" sites.

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

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

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

Custom Domain Publishing, And World Culture

People who speak (read / write) languages, that do not use Roman character sets, need to publish in their native language - and the Internet now supports that need.

Some registrars will register domains which use non Roman character sets, in the URL. Not all Internet services will accept non Roman characters, however.

My favourite online DNS diagnostic services, DigWebInterface, and intoDNS, and Rex Swain's HTTP Viewer, only use ASCII. One cannot use non ASCII ("non Roman") characters, with either service.

"بحث-سناب.com", as converted, shows an example of an Internationalized domain name.

To use DigWebInterface to retrieve DNS addresses, and intoDNS to check the domain setup, we have to convert the native URL to Ascii.

I use three reliable online services, which will convert URLs to ASCII.

• DomainTools
• WhoIs - Identity for everyone
• Who.is - Powered by Name.com

Converting "بحث-سناب.com" to ASCII involves use of one of the latter services.

DomainTools

WhoIs - Identity for everyone

Who.is - Powered by Name.com



Using the 3 tools, we see that "بحث-سناب.com" == "xn----zmcbcml8b0j.com", "XN----ZMCBCML8B0J.COM", and "xn----zmcbcml8b0j.com", respectively. Look carefully, in the body of the display for each service, for the IDN equivalent.

We can then use "xn----zmcbcml8b0j.com", with DigWebInterface, and intoDNS - and get the necessary diagnostics.

And using the latter tools, we see a properly setup domain - which is now being used for a properly published Blogger blog, verified in Rex Swain.

DigWebInterface

intoDNS

Rex Swain's HTTP Viewer



And when assistance is requested, in Blogger Help Forum: Get Help with an Issue, we can use these tools with non Roman character URLs.

There may be limitations, though.

Here is a blog published to "www.राजभाषाअनुभाग.भारत" - aka "www.xn--l1b0bn3cxacq2d2ccbd1b.xn--h2brj9c".

The IDN concept has now led to another domain name concept - "emoji" domains.

Some people have taken the ability to setup a domain, using non Roman characters, to another level. How about a domain name, which includes a smiley face?

This is a limited use feature. Maybe, the limit will save us?

The availability of emoji domains is limited. As of August 2017, there are eight top-level domains for which registration is possible, all of which are ccTLDs: .ai, .cf, .ga, .gq, .ml, .tk, .to, and .ws.

This is intriguing - but is it useful?



If people don't know how to "type" it, how will new readers access the blog? Will search engines index it? Does the Blogger "Create a blog" wizard actually support it?

The jury is still out, here. ".whatever" vanity TLDs started this trend. I'm not sure where this will go, with TLD "emoji" domains.

Houston, we may have a problem with TLDs that are IDN encoded.

For a TLD that is in English ("بحث-سناب.com"), both of these work:

http://www.digwebinterface.com/?hostnames=xn----zmcbcml8b0j.com%0D%0Awww.xn----zmcbcml8b0j.com&type=A&useresolver=8.8.4.4&ns=auth&nameservers=

https://intodns.com/xn----zmcbcml8b0j.com

For a TLD that is IDN encoded (राजभाषाअनुभाग.भारत"), we have mixed success.

This works:

http://www.digwebinterface.com/?hostnames=xn--l1b0bn3cxacq2d2ccbd1b.xn--h2brj9c%0D%0Awww.xn--l1b0bn3cxacq2d2ccbd1b.xn--h2brj9c&type=A&useresolver=8.8.4.4&ns=auth&nameservers=

This does not work:

https://intodns.com/check/?domain=%E0%A4%B0%E0%A4%BE%E0%A4%9C%E0%A4%AD%E0%A4%BE%E0%A4%B7%E0%A4%BE%E0%A4%85%E0%A4%A8%E0%A5%81%E0%A4%AD%E0%A4%BE%E0%A4%97.%E0%A4%AD%E0%A4%BE%E0%A4%B0%E0%A4%A4

---

The Internet now supports use of non ASCII characters, in URLs. In order to publish #Blogger blogs to Internationalised Domain Names, we need to convert native URLs to ASCII - using any one of three identified online DNS services.


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

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

Domain Ownership Verification May Not Be Required

Not all blog owners, publishing a blog to a custom domain, will be required to verify domain ownership.

Originally, this was not the case. When ownership verification was added to custom domain publishing, in 2012, every use of the Publishing wizard - even for domains previously purchased using "Buy a domain" - would require a new "CNAME".

Since many registrars limit the number of address entries / domain, the new "CNAME" meant half the maximum number of hosts / domain. Of course, most blog owners patience ran out long before the magical maximum - but there was always that spectre hanging over every custom domain.

Recently, the domain ownership verification requirements changed.

Now, instead of requiring ownership verification for each host, only publishing to the domain root generates the apocryphal "Error 12" and variants. Some blog owners, publishing to non root hosts, or trying to publish with spurious addresses, find their domains published without even the hint of verification.

Successful domain publishing requires you to add righteous base DNS addresses, and get the domain working.

• If you correct the base DNS addresses, and the domain works without the second "CNAME" added to the domain, the second "CNAME" is not required.
• If you correct the base DNS addresses, and the second "CNAME" is required, instructions for adding the second "CNAME" will be provided - when you publish to the domain.
• If you don't correct the base DNS addresses, the domain is not going to work - even with the second "CNAME" added to the domain.

Start by setting up a new domain with righteous base DNS addresses, then Publish to the proper address.

If you get the base addresses right, you may be given instructions for the second "CNAME". If so, you return to the zone editor, add the second "CNAME" using the instructions, and repeat the Publishing wizard. If the Publishing wizard indicates success

mycustomdomainblog.blogspot.com redirects to www.mydomain.com

you are almost done.

Use a text proxy and verify that the domain is now operational. If the text proxy shows a problem, check your base DNS addresses - and correct if necessary. Allow for proper DNS latency - and check domain operation again.

For best results, make sure that the domain root redirects properly, to the "www" alias.

If any doubt or confusion, start a new topic in Blogger Help Forum: Get Help with an Issue, and request assistance. Let us help you, before you try using a spuriously setup domain, and maybe avoid the old corrupt domain.

Key already exists for www.mydomain.com

Why subject yourself to needless pain and suffering? Don't worry, needlessly, if you don't get the well known "Error 12" when you hit "Save", and see

mycustomdomainblog.blogspot.com redirects to www.mydomain.com

Verify operation of the domain, maybe using an HTTP trace - and start getting the domain indexed by the search engines.

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.

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.

'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