Showing posts with label Custom Domains Setup. Show all posts
Showing posts with label Custom Domains Setup. Show all posts

Wednesday, August 30, 2017

What Is The Mysterious Custom Domain "Error 12"?

Both the historically infamous "Another blog ..", and the currently infamous "Error 12", are part of the custom domain publishing process.

Similar to the mysterious "bX" codes being an enhanced version of "We're sorry, but we were unable to complete your request.", "Error 12" (and variants) is an enhanced version of the monolithic "Another blog or Google Site is already using this address.".

"Another blog" (which was generally seen during use of the Blogger Publishing wizard) is complemented by the equally annoying "Not found" (which is generally seen after Publishing is used).

The "Another blog ..." / "Not Found" condition is not desirable - for a working domain.

The condition, in general, appears to be an unavoidable result of the flexible Blogger custom domain design. A Blogger custom domain published blog can be one host in a domain cluster, that can also include a Tumblr blog, a WordPress blog, any number of third party hosted websites - and even an odd feature like a forum.

Blogger custom domain publishing is a powerful feature.

Blogger custom domains can be purchased from (almost) any registrar - and can use DNS provided by (virtually) any DNS host. It's more powerful than competing Internet services. Use of "CNAME" referral, to connect the blog and domain, is innovative, and smart.

Custom domain publishing does some of the domain processing from your computer - instead of solely from Google. Use of your computer, unfortunately, involves computers and networks uncontrolled by Google - and may lead to occasional database corruption, and to "Another blog". Custom domain publishing depends upon DNS - and DNS is an Internet service controlled by neither Google or any blog owner.

"Another blog" and "Not found" are two displays, caused by one problem.

The mysterious "Server Not Found", seen occasionally, is similar to the classic "Another blog ..." error.

In many cases, righteous DNS addressing is present - but broken links, in the Google database, leave the blog displayed as “Not found”. "Another blog" is seen by the blog owner, when publishing - and "Not found" is typically seen by would be blog readers, and search engines, after publishing.

An experienced blog owner would generally prefer the former, to the latter. The owner, when seeing "Another blog", can fix the problems - so prospective readers and search engines can view the blog, without seeing "Not Found".

"Error 12" is the best known, but not the only, "Error".

"Error 12" is the best known "Error" - but not the only one. There appear to actually be several dozen different variants of "Error 12", which refer to problems with the Publishing dashboard wizard. We've seen "Error 32", at least.

32 "Error" codes is nowhere as complex as 36^6 "bX" codes - but it's a start.

An example of the infamous "Error 12", seen long ago.



Earlier, "Error 12" was seen when domain ownership verification was needed, when publishing to newly setup domains. We have, during the past year, seen reports of Publishing problems labeled "Error 13", "Error 14", and "Error 32".

"Error 12", in reality, is not an actual error condition - it is simply a domain, requiring normal ownership verification. Recently, the "Error 12" label was removed from the "domain ownership verification is needed" display - and now, we simply see the label "Third party domain settings".

"Error 13", "Error 14", and "Error 32" appear to also involve domain ownership verification - but with slightly different circumstances. There may also be some "Error" numbers which involve features other than domain ownership verification. And some "bX" codes are caused by bogus DNS addressing, encountered during custom domain publishing - like various "Error" codes.

The "Error 12" seen now, with verification instructions re written - and without the "Error 12" label.



Ownership verification has become both more flexible - and less necessary.

Domains purchased through Google Domains don't need ownership verification, when purchased under the Blogger / Google account as the blog owner. The Google Domains service, originally available only to USA residents, is now (as of August 2018) available in Australia, Brazil, Canada, France, India, Indonesia, Italy, Japan, Mexico, Netherlands, Spain, Thailand, UK, USA, and Vietnam..

Also, Blogger now accepts domain ownership verification using options available through Google Webmaster Tools - the latter now itself known as Search Console. These options offer verification ability to blog owners who can't use simple "CNAME" referral.

Originally, addition of a new "CNAME" was necessary, for each use of Publishing - with a new BlogSpot URL involved. After Blogger tuned the verification process, we noted that the second "CNAME" is only required for a new, unverified domain - and not always that, either.

With the "Error 12" designation retired, the other Publishing "Error" labels reference actual error conditions - and may offer more diagnostic ability than the monolithic "Another blog".

For people fortunate to be able to use Google Domains, purchase and setup of a non BlogSpot address is slowly becoming a project more doable by blog owners, instead of by tech experts. And the "Error 12" variants will make diagnosis of common publishing errors more possible.


When Blogger added domain ownership verification to the custom domain publishing process in 2012, blog owners started seeing the mysterious "Error 12", suggesting that ownership verification was required. We've seen various other "Error" codes in the past 5 years, - some also referencing ownership verification, and others referencing other publishing problems.

It appears that the various "Error" codes are used to identify problems encountered in the Publishing wizard, similar to how the bX codes are used to identify problems in Blogger, in general.

https://productforums.google.com/d/topic/blogger/3Rb3E08zHKk/discussion

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

Wednesday, November 16, 2016

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:

And, try these DNS Propagation Checkers, for experimentation.



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.

Tuesday, August 30, 2016

Troubleshooting Your Custom Domain Problems

Of the many accessories and features in Blogger, Custom Domain Publishing is possibly the most problematic.

Looking at the Labels index in this blog, I see the Custom Domains label on 363 posts (as of 2015/06/15) - which makes it one of the most heavily labeled single topics here. There are several challenges with diagnosing and resolving a custom domain problem.
  • It has various different causes.
  • It leads to many different symptoms, which can easily be confused for other problems.
  • Its symptoms can be chronic or intermittent- and may be immediate, or may take months to exhibit themselves.
  • It may require resolution by any blog guest, by the blog owner, by Blogger Support, and / or by a third party such as the domain registrar.


As you read this article, click on some of the many links in the text, and read the linked articles.

Please think of this article as the first chapter in a very large book - right now, a book with 363 chapters.

How To Use This Guide

These are the known custom domain publishing diagnoses. Here's a brief, one line summary of the problems, which are discussed, in some detail, farther below. Click on any one, if it looks promising, to jump to the detail discussion.



Domain Purchase Unsuccessful
  • The domain will not be setup. The blog may, or may not, be published to the domain.
  • This will follow use of "Buy a domain".
  • The primary symptoms will vary. We see both "404 Not Found", and "Another blog is already hosted at this address", fairly common for this problem.
  • This will be an issue for newly purchased domains.
  • It will be diagnosed by use of the WhoIs log showing "xxxxxxx.xxx appears to be available", and verified by examination of the Google Checkout logs, and bank account ledger entries.
  • The blog owner generally has to correct a problem with his bank account, then repeat the purchase of the domain.


Only Name Registration Purchased, No DNS Hosting
  • The domain will not be setup, nor the blog published to the domain.
  • This will follow domain registration, purchased from a third party registrar.
  • The primary symptom will be the query "What are the DNS servers for Google?", "I need 2 IP addresses for my domain!", or "I can only change NameServer1, NameServer2 in my domain setup!".
  • This will be an issue for newly purchased domains.
  • It will be diagnosed by the stated symptom, with the blogger confirming the diagnosis by checking the registrar's invoice to see what services were paid for.
  • The blogger will have to arrange for DNS hosting - free or paid - but choose the right DNS hosting service. A free third party DNS hosting service may be useful, in this case.


Domain Addresses Not Defined
  • The blog will not be successfully published to the domain.
  • This will follow domain registration using "Buy a domain".
  • The primary symptom will be "Another blog is already hosted at this address", in the Settings - Basic - Publishing display.
  • This will occur for new custom domains.
  • It will be diagnosed using an excerpted Dig log, for both domain URLs.
  • Here, the blogger will be advised to contact Google Apps Support, for any domain purchase issues.


Domain Ownership Not Verified


Non Google DNS server Part Of Configuration


Domain Addresses Not Properly Chosen


Domain Previously Registered, And Used In Blogger
  • A Blogger blog was successfully published to the domain, at one time - by a different person. It is now not successfully published.
  • This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
  • The primary symptom will be "Another blog ...", when attempting to publish / re publish the blog to the domain.
  • It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs.
  • It will be resolved using the Custom Domain Reset form - and much patience by the current domain owner.


Domain Registration Expired


Blog Published To Domain, Using Mixed Case URL
  • The blog will be successfully published to the domain, but will not be visible from either BlogSpot or domain URLs.
  • This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
  • The primary symptom will be a "404 Not Found", when attempting to view the blog using either the BlogSpot or domain URLs.
  • This will, typically, occur for new custom domains, immediately after the end of the 3 Day Transition Period.
  • It will be diagnosed using a RexSwain HTTP Trace set, starting from the BlogSpot URL.
  • It is typically resolved by publishing the blog back to BlogSpot, then re publishing to the correct URL, using all lower case letters.


Blog Published To Domain Root, But Asymmetrical DNS Used
  • The blog will not be successfully published to the domain.
  • This may follow domain registration, purchased from a third party registrar, or using "Buy a domain" - though "Buy a domain" will be far more commonly seen.
  • The primary symptom will be a "404 Not Found", when attempting to view the blog using either the BlogSpot or domain URLs - or the warning "Blogs may not be hosted at naked domains." or "Another blog or Google Site is already using this address.", when trying to publish or re publish the blog to the domain.
  • This will, typically, occur for new custom domains.
  • It will be diagnosed using a RexSwain HTTP Trace set, starting from the BlogSpot URL, and confirmed with a screen print of the Publishing wizard display, taken as the blog owner sees the error message in question.
  • It is typically resolved by publishing to the "www" alias.


Domain Redirected To Google Ad Services, Sites, or Start Page URL


Blog Published Partially, To The Custom Domain URL


Internal Blogger Database Corruption


The Blog And Domain Are In Transition
  • The domain will be setup - but will not redirect. The blog will be published to the domain URL.
  • This will follow use of "Buy a domain".
  • The primary symptom will be seen only by the owner (when properly logged in to Blogger). When clicking on the "View Blog" dashboard button / link, the owner will see an "In Transition" display.
  • This will be a temporary issue, for newly purchased domains, successful purchased.
  • It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs.
  • It will go away, when Transition expires, 72 to 96 hours after successful domain purchase and registration. The blog, and the domain, will then redirect properly.
  • While you wait for Transition to expire, spend time reading what you will want to do, when Transition is complete.


All Issues May Not Be Yet Discussed Here
You could, occasionally, have a problem which is not diagnosed in this Guide - and in that case, please ask for help, politely, in Blogger Help Forum: Something Is Broken.

Before asking for help, you can help the helpers if you have tried some affinity diagnostics or maybe some differential diagnostics - and if you are aware that not all problems may be exclusively caused by Blogger. And have some idea how many possibilities exist, for problems.
And if it's not too late, read Blogger Magic - How To Setup A Custom Domain, and Setting Up DNS Addresses For Custom Domains, before you start.

Friday, August 12, 2016

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

Sunday, June 5, 2016

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.

  1. Go to your domain registrar's website and locate the DNS (Domain Name System) settings in the control panel.
  2. 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.

  1. 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.
  2. 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.


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

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

Wednesday, May 4, 2016

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.

Friday, April 15, 2016

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.

Thursday, January 15, 2015

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.

Sunday, January 11, 2015

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.

Wednesday, January 7, 2015

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.
Subscribe to: Posts (Atom)

Navigate» Become author for this Blog

About

Site Links

Popular Posts

Join the Team

Copyrights @ IElm0D - Blogger Templates Designed by Templateism | Templatelib

  • (91) 5544 654942
  • support@templateism.com
  • Templateism