Custom Domain Redirection, And "A" Referral Servers

One of the advantages of custom domain publishing, and the domain root to published URL redirection, used to be transparent redirection of the URLs.

As Blogger blog owners become more sophisticated with their blogs, and custom home pages (aka "landing pages"), become more popular, we have blog owners with concerns with home page access and the root redirection. We are also seeing concern with direct access to specific posts - with posts advertised, using the domain root URL.

In some cases, redirection only shows the reader the blog home page when the casual reader first sees the blog - even with a specific post being linked in the advertised URL.

With this blog, which is the redirect target of my domain, nitecruzr.net, this post "Custom Domain Redirection, And "A" Referral Servers" has a URL of "http://blogging.nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Since "blogging.nitecruzr.net" is the redirect target of the root redirect for "nitecruzr.net", this post "Custom Domain Redirection, And "A" Referral Servers" should have an alternate URL of "http://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Click on the 4 links, in the 2 paragraphs immediately above, and compare the results - if you don't yet see the seriousness here. Please. It's not a cosmetic detail.

This post "Custom Domain Redirection, And "A" Referral Servers", advertised as "http://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html", redirects to "http://nitecruzr.net/".

This post "Custom Domain Redirection, And "A" Referral Servers", advertised as "https://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html", redirects to "https://nitecruzr.net/".

Note that this blog does not yet use "HTTPS Redirect", so if you click on a link to "Custom Domain Redirection, And "A" Referral Servers" you will see "http://blogging.nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Here's an example of the problem.

Here's a an example of this problem - diagnosed using a previous post blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html

A normal redirect - to "blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html"

http://blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Expires: Mon, 23 Apr 2018 03:25:09 GMT
Date: Mon, 23 Apr 2018 03:25:09 GMT
Cache-Control: private, max-age=0
Last-Modified: Mon, 23 Apr 2018 03:23:01 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Server: GSE
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked

A normal redirect - to the specific post, using HTTPS.



A broken redirect - to "blogging.nitecruzr.net"

http://nitecruzr.net/2016/08/delete-permanently-means-delete.html

HTTP/1.1 301 Moved Permanently
Location: http://blogging.nitecruzr.net
Date: Mon, 23 Apr 2018 03:23:18 GMT
Content-Type: text/html; charset=UTF-8
Server: ghs
Content-Length: 226
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

http://blogging.nitecruzr.net

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Expires: Mon, 23 Apr 2018 03:23:19 GMT
Date: Mon, 23 Apr 2018 03:23:19 GMT
Cache-Control: private, max-age=0
Last-Modified: Mon, 23 Apr 2018 03:23:01 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Server: GSE
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked

A broken redirect - to the blog home page, using HTTPS.



Unfortunately, some blog owners are observing that redirection of a specific root URL - maybe a custom landing page, or a specific post advertised using the root URL - appears to lead only to the home page of the published blog.

This is a problem with domain / website design, in general - and with Blogger custom domain design, in particular.

The domain root to published URL (for most blogs, the "www" host) appears to use a version of frame forwarding, with some blogs being reported.

I never recommend using Frame Forwarding, in the custom domain DNS setup.

One of the disadvantages of frame forwarding is that redirects using frame forwarding drop the post URL.

We've been seeing this problem reported, for several years.

The problem, rarely - but not never - reported, started several years ago. This was before HTTPS for BlogSpot - and even farther before HTTPS for custom domains - was rolled out.

This was shortly after we started observing other problems involved, in the deployment of HTTPS.

The first HTTPS issue was reported in 2014. HTTPS for BlogSpot was rolled out in 2015.

I'm betting we first saw reports of the post URL being lost, in the ""http://xxxxxxx.whatever.com/whatever.html" -> ... -> "https://www.whatever.com"" was maybe 2 years ago. During deployment of HTTPS.

My guess is that Blogger Engineers upgraded the domain root servers ("A" address) redirection code, to support HTTPS - and made a business decision to use frame forwarding.

From what I've seen of Blogger Engineering in general - and custom domain design in particular - I am convinced that if they decided that frame forwarding is necessary, it's necessary. Until they can correct the problem, that is. My advice to every domain owner to not use registrar supplied frame forwarding in the domain DNS, notwithstanding.

I can only hope that we will see this problem corrected, this decade. Remain optimistic - and report the problem, when it can be identified.

---

It appears that some of the #Blogger custom domain "A" address name servers are using "Frame Forwarding", instead of "Referral", to redirect the domain root to the published URL. Frame forwarding strips away the post address portion of the URL - leaving only the domain root.

Some blog owners use the domain root to advertise their blog posts - and are seeing only the blog home page, instead of the individual posts, when linking to the posts.

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

https://productforums.google.com/d/topic/blogger/pePwPhr_H-Y/discussion

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

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

HTTPS Availability For All All Blogger Blogs

After years of waiting, this blog is now readable, using HTTPS.

This blog, and others published using properly setup custom domains, now provides optional HTTPS connectivity - joining BlogSpot published blogs.

I looked at the Settings - Basic page of my Blogger dashboard, a couple hours ago.

Previously, I might see the HTTPS options "Availability" and "Redirect" when accessing my Draft Blogger dashboard. Now, both are there, in Production Blogger.

If you publish a blog, using a custom domain URL, you should see the new option too. It took 5 minutes, with my blog, to activate "HTTPS Availability".

RBS is now secure!



A couple hours ago, "HTTPS Availability" was offered, on my Blogger dashboard.

There are two options - HTTPS Availability, and HTTPS Redirect.

• HTTPS Availability lets your readers access your blog, using HTTP or HTTPS, as they choose. HTTPS Availability is now an option, for all blogs.
• HTTPS Redirect automatically requires all readers use HTTPS, to access your blog. HTTPS Redirect is an option, with HTTPS Availability enabled.

HTTPS Availability is now an option!



"HTTPS Availability" lets your readers, who use only HTTPS, connect to your blog. It's the first step in upgrading the web.

So, it's selected - and now we wait.



When you enable "HTTPS Availability" for a custom domain published blog, Google will setup an SSL certificate for the domain - free of charge. Just enable the option, and wait a few seconds - and your domain will be secure, with certificate.

Less than 5 minutes later, and I see the display updated.



"HTTPS Redirect" is now available, for this blog. "HTTPS Redirect" automatically requires all of your readers to use HTTPS, when reading your blog. It's the second step in upgrading the web.

So "HTTPS Availability" is now a reality. Common sense - and Blogger advice - tells me to take things slowly. I'll still allow HTTP connectivity, for readers who can't use HTTPS.

I next need to setup Search Console entries for this blog, using HTTPS.

For best results, the domain needs to be properly setup. Both the BlogSpot to domain redirection, and the domain root ("naked domain") to published URL redirection, can be complicated, with HTTPS offered for an improperly setup domain.

Also, remove any other custom installed redirecting code. Both code blocking local country redirection, and code blocking (or enabling) HTTPS redirection, will interfere with the HTTPS Redirect option.

And check your non Blogger accessories and features carefully. Blogger is not the last Internet service to provide this upgrade - and your blog will provide the best experience, for your readers, if all accessories and features also support HTTPS.

Test the blog and domain, in the many URLs.

With the blog published to the domain, and offering HTTPS connectivity, you'll have 6 URLs - all pointing to the blog. Make sure that all 6 work properly.

Right now, my test blog does provide HTTPS connectivity / redirect - though this blog does not, since I don't want broken links to third party services. Using my test blog, I have 6 URLs to check. Note that this blog is published as "blogging.nitecruzr.net" - not "techdict.nitecruzr.net", or "www.nitecruzr.net".

1. http://myspaceandmore.blogspot.com
2. http://nitecruzr.net
3. http://techdict.nitecruzr.net
4. https://myspaceandmore.blogspot.com
5. https://nitecruzr.net
6. https://techdict.nitecruzr.net

Your readers will be happiest, if all 6 URLs work - and all redirect to your blog. Again, your domain will probably use "www", in place of "blogging" or "techdict", in #3 and #6.

Be prepared to re publish the blog, for best results.

If you were using "HTTPS Redirect" for the BlogSpot URL, #2 and / or #5 many be "404". You may need to re publish the blog, and remove the BlogSpot "HTTP" to "HTTPS" redirect. The domain root redirect, and "HTTPS Redirect" for the domain, may conflict.

Activate "HTTPS Redirect" for the domain, with the BlogSpot URL having "HTTPS Redirect" enabled - and you may see this.



You will have 3 redirects, with HTTPS Redirect added.

1. The BlogSpot to domain redirect.
2. The domain root to published URL redirect.
3. The "HTTP" to "HTTPS" redirect.

All 3 redirects need to be addd in proper sequence - if you want the BlogSpot URLs, the domain root, and the published domain URL to all redirect to the blog.

With both the BlogSpot redirect, the domain root redirect, and the HTTPS redirect enabled, you may see an error when addressing the domain root. In that case, you'll have to re publish the blog to the domain.

1. Login to production Blogger ("www.blogger.com").
2. Publish the blog back to BlogSpot, by clicking on the "X".
3. Disable “HTTPS”, if necessary.
4. Re publish the blog to the "www" domain host.
5. Select the domain root redirect.

Be careful when editing the pages / posts / template.

One of the reasons why HTTPS took so long to be available with Blogger - and contrarily, why the entire web did not upgrade over night - is that other blogs and websites have not yet upgraded.

If your blog is to provide useful HTTPS connectivity, any accessories and features, that you depend on, must also offer HTTPS connectivity. If a non HTTPS link is present, your readers will see scary advice about "mixed content", and "unsafe" web pages.

Blogger provides "mixed content" warnings, in page / post / template editor, when appropriate - but read their warning very very carefully. Before you change a link from HTTP to HTTPS, you have to verify that the accessory linked will provide HTTPS connectivity.

The "Fix" option in the page / post / template editor "mixed content" warning will break accessories that don't yet provide HTTPS connectivity. Don't change links from HTTP to HTTPS, without verifying that they will support the change.

Understand the details, to ensure an effective migration.

If you can deal with the details, you'll have a secure domain - and you can now offer your readers SSL connectivity, to your custom domain published blog, using all 6 links above.

---

HTTPS Availability is now an option for all #Blogger blogs. I'll continue to offer HTTP, for readers who can't use HTTPS - but those who require HTTPS can now use it, to access this blog - and other custom domain published blogs.

HTTPS Availability For Custom Domain Published Blogs

After many years of waiting, people who publish blogs using custom domains can provide HTTPS connectivity, to their readers.

Right now, HTTPS Availability / Redirect can be enabled, for custom domain published blogs, using Draft Blogger.

Since Draft Blogger is used by Blogger for beta testing new features and problem fixes, you will do best using it selectively.

Use Draft Blogger only to enable HTTPS Availability / Redirect.

In this case, you use draft Blogger only for enabling HTTPS for your custom domain URL. This is a good time to use a second browser - either a different browser on this computer, any preferred browser on another computer, or this browser with an Incognito / Private window.

Start by logging into Draft Blogger - using a second browser.

The Settings - Basic dashboard page, in Draft Blogger, now has a new option.

Select "Yes" for "HTTPS Availabiity" - and wait while the domain is setup with SSL.



With "HTTPS Availability" enabled, Blogger has to obtain an SSL Certificate for your domain. This is not a casual formality. With many domain registrations, you might pay extra for a certificate.

Once "HTTPS Availability" is activated, you'll have the "HTTPS Redirect" option.

Allow half an hour after enabling "HTTPS Availability", then refresh the display. You should have "HTTPS Redirect" available - and if you wish, you can enable it.

Success!



Blogger is not the last Internet service to provide "HTTPS" connectivity.

If you enable "HTTPS Availability", and later "HTTPS Redirect", you'll probably have accessories and services that don't support HTTPS.

Be selective when you use Page / Post / Template Editor, and see suggestions to "Fix" all links that continue to reference "HTTP" connectivity. If you routinely select "Fix" you will end up with broken links, for accessories and services that have not been upgraded.

If you can deal with the details though, you'll have a secure domain - and you can now offer your readers SSL connectivity, to your custom domain published blog.

---

If your #Blogger custom domain is setup properly, you can now offer HTTPS connectivity for your custom domain published blog.

You should consider the redirects, and the different URLs involved, carefully.

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

https://productforums.google.com/d/msg/blogger/B5tBKvv1FoE/n2Zv61G6CAAJ

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

---

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

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

When I diagnose DNS address problems, I generally recommend

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

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

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

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

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

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

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

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



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

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

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

That name is reserved (already in use).

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

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

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

---

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

Custom Domain Publishing, And DNS Latency

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

Understand the different latency numbers.

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

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

Need More Detail?

For more discussion, you can read:

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

And, try these DNS Propagation Checkers, for experimentation.

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

---

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

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

Custom Domains And HTTPS Redirection Code

As most of us know, Blogger HTTPS support does not include custom domain publishing.

The advantages offered by HTTPS access are widely advertised - and have led to envy between blog owners who publish to custom domains, and native BlogSpot blog owners proudly advertising their new HTTPS connectivity.

Long ago, we saw possibly malicious code which helps our readers avoid using country code aliases, to read our blogs from an aliased country. Recently, there was dodgy code which blocked HTTPS mode, to read a customised blog.

Now, we have custom code to force HTTPS access, for BlogSpot published blogs.

Along with providing code to help blog owners avoid country local domain aliasing, some marginally helpful hackers are providing code to help blog owners force reader access to HTTPS.

Some blog owners always wanted HTTPS to be used, to access their blog.

Some blog owners wanted their readers always using HTTPS to access their blogs, before forced HTTPS access became an option. They Googled, and found, semi helpful hackers who provide clever code to force the "HTTP --> HTTPS" redirection.

<script type='text/javascript'>
$(document).ready(function() { 
  $("a[href^='http://']").each( 
    function(){ 
      if(this.href.indexOf(location.hostname) == -1) { 
        $(this).attr('target', '_blank'); 
      } 
    } 
  );
  $("a[href^='https://']").each
    function(){ 
      if(this.href.indexOf(location.hostname) == -1) { 
        $(this).attr('target', '_blank'); 
      } 
    } 
  );
});
</script>

This is clever code - when only BlogSpot access is involved. When you add BlogSpot to custom domain redirection, it becomes another "404".



Adding this clever code is an excellent solution - until the blog owner forgets about it, and later upgrades to a non BlogSpot custom domain.

With a custom domain published blog, the redirection becomes a problem.

The added code contains no exception to permit custom domain published blogs to remain in HTTP mode. When accessing an otherwise properly setup custom domain published blog, from a reader using the "blogspot.com" URL, this prevents the BlogSpot to domain redirect from operating.

BlogSpot URLs, which should redirect to the HTTP published custom domain URL, instead redirect to a non existent HTTPS URL - and result in another "404". As the custom domain URL becomes more commonly used for a recently published blog, confusion increases when the rarer BlogSpot URL reference is encountered.

My blog has been using the domain URL for months, why is this happening now?

The problem involves dual redirection - to "https:" mode, and to the custom domain.

After painful problem diagnosis, we find the clever redirection code buried in template HTML - and we see that the blog reader is starting from the BlogSpot URL, and using the BlogSpot to domain redirection, to access the blog.

With blog access redirected to "https:" mode, then subsequently to the custom domain URL, the readers sees a "404" - because the custom domain URL is not available as "https:" content.

This problem will become increasingly rarer - but not extinct.

As self caused custom domain victims become rarer, this way of breaking ones own blog will become more obscure - and it's likely that some cases will go, unsolved. This will be similar to the problem of un migrated classic templates, which has increasingly less experienced support.

If you must install unsupported template tweaks into your template - consider the long term effects. Learn to recognise a problem that you have caused, to your own blog.

Not every helper will realise that you have added custom redirection code - and when looking at the problem code, when a problem is reported, will recognise it for what it is. Your problem may remain your problem - at least, until Blogger Engineering completes Blogger SSL integration (may this happen soon).

---

Some blog owners have added clever HTTP to HTTPS redirection code, acquired from helpful third party providers, installed in the template. When later publishing a blog to a custom domain, this code will prevent proper blog access - and as installed, may not be easily recognised.

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

Troubleshooting Custom Domain Issues

If you are trying to make your custom domain published blog work, see my guide Troubleshooting Your Custom Domain Problems.

If you want to know how to setup a custom domain properly, from the beginning - and avoid the need for Troubleshooting - read Setting Up DNS Addresses For Custom Domains. Avoid the most basic mistakes made - read The Simplicity Of A Custom Domain Setup.

If you just setup your custom domain - and want to minimise the effects of the URL change upon your search engine relationships - read Managing The Migration.

If you're just browsing, then read on - but get a good cup of coffee first. And welcome, to Nitecruzr Dot Net.

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

• Always start properly, with properly setup DNS addresses.
• Verify DNS addresses, using Dig. If any doubt about Dig results, compare logs from multiple Dig utilities, including a Dig against the authoritative domain server. Possibly 90% of all custom domain problems are caused, directly or indirectly, by spurious DNS addresses.
  
• If examination of multiple Dig logs shows properly setup DNS addresses, look at HTTP traces against the BlogSpot and domain URLs.
  
• If neither Dig nor HTTP traces provide a definitive diagnosis, consider that you have internal database corruption.
• As you diagnose your DNS setup, only look at "A" and "CNAME" records.
• As you diagnose and / or fix the problem, do not delete the Google Apps administrative desktop account.

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
• Only Name Registration Purchased, No DNS Hosting
• Domain Addresses Not Defined
• Domain Ownership Not Verified
• Non Google DNS server Part Of Configuration
• Domain Addresses Not Properly Chosen
• Domain Previously Registered, And Used In Blogger
• Domain Registration Expired
• Blog Published To Domain, Using Mixed Case URL
• Blog Published To Domain Root, With Asymmetrical DNS
• Domain Redirected To Google Ad Services, Sites, or Start Page URL
• Domain Published, Partially
• Internal Blogger Database Corruption
• The Blog And Domain Are In Transition
• All Issues May Not Be Discussed Here

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

• The blog will not be successfully published to the domain.
• The primary symptom will be an "Error 12" or variant (we have observed "Error 12", "Error 13", "Error 14", and "Error 32", in reported various forum topics), when using the the Settings - Basic - Publishing wizard.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• This will occur for new custom domains - as well as for mature domain being re published.
• This will be diagnosed using an excerpted Dig log, for both domain URLs. Base DNS addresses should also be verified, to ensure addresses are properly setup.
• The blog owner will be advised to add or verify presence of the proper domain ownership verification "CNAME". This may involve adding an updated "CNAME", and / or carefully examining the format of the "CNAME", as entered in the "Zone Edit" registrar display. Some blog owners may need to use a free third party DNS hosting service, to allow for registrars who cannot support the necessary "CNAME".

Non Google DNS server Part Of Configuration

• The blog may, or may not, be successfully published to the domain.
• This will follow domain registration, purchased from a third party registrar.
• The primary symptom may be "Another blog is already hosted at this address" (for new custom domains, in the Settings - Basic - Publishing display), or conversely "404 Not Found" (for long existing custom domains, when viewing the blog). The symptoms will be observed intermittently, when the non Google server is referenced.
• Possible secondary symptoms:
  • Blog feeds, intermittently not redirected from the native BlogSpot URL.
  • Commenting problems.
• It will be diagnosed using an excerpted Dig log, for the domain root.
• It is typically resolved by a 4 step process. For best results, follow this procedure religiously.
  1. Publish the blog back to BlogSpot.
  2. Correct the DNS addresses.
  3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
  4. Republish to the domain URL.

Domain Addresses Not Properly Chosen

• The blog may, or may not, be successfully published to the domain.
• This will follow domain registration, purchased from a third party registrar.
• The primary symptom may be "Another blog is already hosted at this address" (for new custom domains, in the Settings - Basic - Publishing display), or conversely "404 Not Found" (for long existing custom domains, when viewing the blog).
• Possible secondary symptoms:
  • Blog feeds, unreliably redirected from the native BlogSpot URL.
  • Commenting problems.
• It will be diagnosed using an excerpted Dig log, for both domain URLs.
• It is typically resolved by a 4 step process. For best results, follow this procedure religiously.
  1. Publish the blog back to BlogSpot.
  2. Correct the DNS addresses.
  3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
  4. Republish to the domain URL.

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

• The blog was successfully published to the domain, at one time.
• This may follow domain registration, long ago purchased from a third party registrar, or using "Buy a domain".
• The primary symptom may be unexpected content, displayed by the blog. The nature of the unexpected content will vary.
  1. In most cases, and when the blog owner is lucky, the domain will be dead, or maybe display a page of ads or an "Offsite Warning" interstitial display.
  2. In rare cases, and when the blog owner is not lucky, the blog will display contents of another blog, another website, or an "Offsite Warning" interstitial display.
• It will be diagnosed using a WhoIs log, which shows expiry and last update dates, for the domain.
• There are two possible resolutions (see two primary symptoms, above, for possible variants).
  1. With the blog owner being lucky, it is in the control of the registrar. After domain registration is renewed, the problem is resolved by the 4 step process. For best results, follow this procedure religiously.
     1. Publish the blog back to BlogSpot.
     2. If necessary (and possible), contact the registrar, and renew the registration. Then, correct the DNS addresses.
     3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
     4. Republish to the domain URL.
  2. If the blog owner was not lucky, the domain may now be in the hand of an unknown party. This will be a subject for another article.

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

• 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".
• The primary symptom will be "Another blog is already hosted at this address", in the Settings - Basic - Publishing display.
• This will typically occur for new custom domains.
• It will be diagnosed using a RexSwain HTTP Trace, starting from either domain URL.
• It is typically resolved by deactivating or resetting the Ad Services, Sites, or Start Page service, using Google Apps.

Blog Published Partially, To The Custom Domain URL

• The blog will appear successfully published to the domain.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "404 Not Found", when viewing the blog using one of the domain URLs - and the blog will still be published to the BlogSpot URL.
• It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs. If each of the above diagnoses are eliminated, one by one, and "404 Not Found" is still observed, internal database corruption is the only remaining possibility.
• It is typically resolved by re publishing the blog to the domain. This symptom may mask a Service Redirect, or Internal Database Corruption.
• As you diagnose the problem, re publish the blog to the domain, and / or recycle the domain settings, please do not delete the Apps desktop account.

Internal Blogger Database Corruption

• 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".
• The primary symptom will be "Another blog or Google Site ..." / "Key already exists ..." / "code CONFLICT" (or a similar phrasing), in the Settings - Basic - Publishing display, when attempting to publish or re publish a blog to the domain.
• It will be diagnosed using an excerpted Dig log, for both domain URLs. If the above diagnoses are all eliminated, one by one, and "Another blog ..." is still observed, database corruption is the only remaining possibility.
• It is typically resolved by recycling the domain settings in Google Apps, and / or use of the Custom Domain Reset form. The latter symptom, "code CONFLICT", is unique to domains purchased using Google Domains - and can be resolved by use of their domain dashboard.
• As you diagnose the problem and / or recycle the domain settings, please do not delete the Apps desktop account.

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.

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 Migration, And Redirection Blocking

We see occasional frustration, in Blogger Help Forum: Get Help with an Issue, involving broken or unreliable custom domains.

I setup the Custom Domain properly, following the Google directions.

For some of my readers, my custom domain is not opening. I can see it is going in an infinite loop in the browser - and after a long time, it's throwing errors. My domain is setup, properly. Why do I have to deal with this?

And we will investigate - and in many cases, we find the domain is setup properly.

Some custom domain published blogs have problems, which have nothing to do with the domain setup.

Some custom domain problems involve custom code, added to the template, long ago.

Not everybody is in favour of the ongoing Blogger efforts to convince blog owners to force their readers to use HTTPS / SSL, in blog access.

A number of hackers are making their websites popular, by providing code that lets blogs block forced HTTPS access - just as they provided code that blocked local country domain redirection. Some blog owners add this dodgy code, to their blogs.

This hacking lets blog owners publish their blogs, and use accessories and gadgets that only support HTTP access. Unfortunately, with third party code, you get what you get.

Some third party code, which blocks HTTPS blog access, works OK - for a while.

When a blog is published to a custom domain, redirection to "blogspot.com" causes a redirect loop - or a security check.

<script type='text/javascript'>
var blog = document.location.href.toLowerCase();
if (!blog.match(/\.blogspot\.com/)) {
  blog = blog.replace(/\.blogspot\..*?\//, ".blogspot.com/ncr/");
  window.location.replace(blog);
  }
</script>

This is clever code, seen some time ago when used to block country local domain redirection. Then, as now, some blogs might be deleted or locked as malware hosts - or the blogs would become intermittently inaccessible.

Is the unreliability appropriate? You can add what code you like, to your blog. Eventually, what you add may cause you problems.

---

Some #Blogger blog owners add clever code, to block HTTPS Redirection, to their blogs. This is the same hacker provided code, used long ago to block local country domain redirection.

Like country domain redirection, the code added may work fine, for a while. Eventually, the blog will be deleted / locked for malware hosting - or will start throwing 404 errors and similar confusion.

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