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

---

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.

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

Custom Domain Publishing And Private Blogs

We see an occasional report in Blogger Help Forum: Get Help with an Issue, about custom domain publishing.

My readers can't view the blog - they get a redirection count error!

DNS analysis shows a properly setup domain. When we try to examine the blog, we see a private blog notice - or we are required to login.

But why a private blog, using a custom domain?

The purpose of publishing to a custom domain is to increase readership - by making a blog more visible, using a non BlogSpot URL.

A private blog has limited readership, based on permissions provided by the owner. The need to make a blog private conflicts with the need to increase reader population.

Besides the functional conflict, there's a second problem with combining a custom domain published blog, and access by invitation. Both the custom domain redirection, and the private blog redirection involve interstitial code.

This is a private blog. Combine this, and a custom domain redirection - and you get trouble.



A potential blog reader, when accessing the blog by the BlogSpot URL, will redirect to the domain URL - and then to the access checking interstitial. Some browsers will interpret this as a possible security issue, and cite

Too many redirections!

In other cases, the two redirections may lead to a redirect loop - and the reader will see a white screen of death.

What ever the result - "Too many redirections", or a redirect loop, the potential reader will never see the blog.

If you want to publish a blog, and limit reader access by invitation, you're better off publishing to BlogSpot. If you want to use a non BlogSpot URL, a public blog makes sense.

---

You are allowed to publish a #Blogger blog with a designated reader population - and you're allowed to publish a blog to a non BlogSPot URL.

You can publish a private blog to a custom domain, if you wish - but this is not recommended. Learn why combining limited access with a non BlogSpot URL is not a good idea.

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

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

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

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

and

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

and

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

and

The registrar tells me everything is OK!

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

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

The registrar tells me everything is OK!

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

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

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

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

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

The righteous address setup.

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

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

One possibly righteous address setup.

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

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

Some spurious address setups.

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

Error when adding domain

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

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

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

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

Mobile Redirection Failure

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

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

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

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

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

Can't publish my blog

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

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

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

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

The bottom line.

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

---

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

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

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

Stats And "Don't track", And Custom Domains

Blog owners have been trying to block tracking their own Stats pageviews, for a few years.

This option has long been unusable, for blogs published to custom domains. Recently, Blogger Engineering updated the option - and the dashboard page with the link.

The new Stats option to "Manage tracking your own pageviews" is an improvement, over the old dashboard page.

The new Stats option page is run as part of the blog - not the Blogger dashboard - so it does not require third party cookie access. Unfortunately, this provides no obvious help, to people who publish their blogs to custom domains.

To see the problem, start from the Stats dashboard page.

Click on "Manage tracking your own pageviews".

And, you get "This site can’t be reached" or a similar error.



Custom domain published blogs do not support HTTPS access - even from the Blogger dashboard.

So, change "https:" to "http:", in the address window.



If you manually remove the "s", you can access the "Would you like to have your pageviews counted when you visit this blog?" wizard.

http://blogging.nitecruzr.net/b/statsCookieManage

You can't access the "Manage tracking your own pageviews" for a custom domain published blog, by simply clicking on the dashboard link.

This suggests an interesting detail. Now that "Manage tracking your own pageviews" runs under the blog URL, it will be subject to script filtering - for "blogspot.com", any applicable country local domains, and / or a custom domain URL.

You may need to correct your browser script filter, to make "Don't track" work, now.

---

Owners of custom domain published #Blogger blogs have been wanting to block Stats from counting their own pageviews, for a few years. This option is now available - but not in an obvious way.

Custom Domain Publishing, And Alias Blocking

Some blog owners setup their new custom domain, check all settings carefully (and correctly) - then find that it does not work.

We see the confusion, in Blogger Help Forum: Get Help with an Issue.

The addresses were right - and all the DNS servers updated correctly. But when I open the website, it does not open. It continuously reloads for 5 minutes and after 5 minutes it shows an error.

It's frustrating, when everything is setup properly - but still no results.

It's also frustrating, when you forget about unsupported tweaks that you made, to the blog - then have to ask for help.

Whenever changing the URL, check for - and remove - any redirecting scripts.

Before you publish a blog to a new URL, you need to check the template, for any redirecting scripts, that you may have previously installed.

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

Scripts which redirect - or block redirecting, when the blog is published to BlogSpot - will not work for you, when you publish to a non BlogSpot URL.

You will need to connect URLs, when possible - without scripts interfering.

Any time you change the URL of the blog, you're going to need some ability to link from the old URL to the new URL. Before you change the URL - either BlogSpot to BlogSpot, or BlogSpot to custom domain - check the template, for redirecting scripts.

Any redirecting scripts, that might have helped you with the blog originally published, will be a problem, when you change the URL. Remove any scripts, before changing the URL.

Better yet, don't add redirecting scripts. If you got this far, without having the blog classified as a malware host, consider yourself lucky.

---

Some blog owners install mysterious scripts, to "protect" against unwanted Blogger features - and forget about their unwise tweaks. When they change the URL of the blog - and the blog, under the new URL reacts to the previously installed tweaks - they are clueless.

If you make unsupported tweaks to your blog, only you can correct problems that arise, later.

The Domain Root ("Naked Domain") May Not Be Optional

One of the most consistently seen complaints, in Blogger Help Forum: Something Is Broken, involves blog owners who can't get their blogs working, using custom domain publishing.

Thanks to undertrained tech support staff, a common feature at too many registrars, the most common cause of custom domain problems involves failure to use "CNAME" referral - or "CNAME" referral targeting the wrong destination. Both use of forwarding, and "CNAME" referral to the domain root, is seen too often.

www.mydomain.com.  1800  IN  A  64.202.189.170

or maybe

www.mydomain.com.  1800  IN  CNAME  mydomain.com

Please, don't use either of the above address models!

Unfortunately, even with the blog properly published to the "www" alias - and with the "www" alias using "CNAME" referral, targeting "ghs.google.com" - we still see problems. With neither of the above mistakes made.

The most essential requirement, for a stable custom domain, is "CNAME" referral, targeting "ghs.google.com".

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

or alternately,for Google Domains and similar setups,

www.mydomain.com.  3600  IN  CNAME  ghs.googlehosted.com.

or possibly

www.mydomain.com.  3600  IN  CNAME  www.mydomain.com.ghs.googlehosted.com.

Please, use this address model! This is where a properly addressed domain starts.

Properly setup DNS addresses won't avoid all DNS related problems.

Some domains have properly setup DNS addresses - but still have problems. DNS is a complex - and essential Internet service. Even with DNS addresses properly setup, all DNS servers, worldwide, won't be constantly operational.

Here's one exercise, using my domain, as an example. Click on each of the following URLs, one by one - and examine the map.

https://www.whatsmydns.net/#A/nitecruzr.net
https://www.whatsmydns.net/#A/www.nitecruzr.net
https://www.whatsmydns.net/#CNAME/www.nitecruzr.net

You'll hopefully see a lot of green check marks - and you'll probably see one or two red "X" marks too. Those red "X" marks represent a DNS server, somewhere, returning "404 Not Found" for my domain. Your domain will return similar (probably not identical) results, at any time.

If your domain is properly setup, your potential readers, hopefully near one of the green check marks, should be able to read your blog. The red "X" marks, unfortunately, are a normal part of Internet life.

We may see obvious problems, when looking at the domain root. Mistakes setting up both the domain root, and the "www" host, are well known. But why do mistakes with the domain root seem to affect us, when we access the "www" host?

Some browsers automatically use the domain root and "www" alias, equally.

If Firefox is involved, an improperly setup domain root can be involved in problems. We've known, for many years, that Firefox aliases the domain root and the "www" host. If the "www" host has a problem, Firefox will attempt use of the domain root. When there's a problem with the "www" host, if the domain root is improperly setup, the blog will be offline.

Whenever any problem is reported with a blog published to a custom domain, I routinely check both the domain root and "www" host - even when the blog owner explicitly reports using Chrome, Internet Explorer, or Safari - and even when the blog owner reports publishing to the "www" host.

99% of the time, when the blog owner is able and willing to fix discovered problems with DNS addresses for the domain root, the problem at hand will be solved. That is when we see the benefit of having the domain root and the "www" host aliased, and backing up each other.

Why do we see problems with the domain root, with the "www" alias involved?

Why does a problem with the domain root seem to affect use of the "www" host, for multiple browsers - not just for Firefox? Pick one.

• Other browsers - not just Firefox - alias the domain root and "www" host.
• Some operating systems alias the domain root and "www" host.
• Some DNS servers alias the domain root and "www" host.

Whatever the case, I suggest that DNS addressing of the domain root should not be treated as an option, when setting up a custom domain. If you want a stable custom domain, there are but 3 DNS models, that you can use reliably - instructions provided by Blogger not withstanding.

Having setup either the "Symmetrical" or "Asymmetrical" DNS models, always remember to select the "optional" domain root redirect.

There Are No Shortcuts Or Workarounds To A Stable Custom Domain

Some Blogger blog owners treat custom domain publishing, as drivers in Miami USA treat the suburban streets.

Have you ever been to Miami, Florida, USA?

Many of the suburban streets there are long, straight, and intersect at 90 degree angles. And as you get into the outer suburbs, with housing developments which (this year) may be right next to the Everglades - there will be almost no traffic, much of the day.

The major streets intersect with stop signs or traffic lights. Many of the natives blow the stop signs, run the red lights, and speed with almost reckless abandon. And auto collisions are frequent - and lawyers and police are very busy.

I car pooled with a co worker for a while, until I noticed that he drove like a native.

His justification?

My brother does this all of the time - and he never gets into an accident - and has never been stopped by the police!

One day, after work, we were getting home - and as we approached the final traffic light, the light cycled green. There was no other traffic in front, or behind.

Instead of cruising through the intersection, my bud jammed on the brakes, and came to a screeching halt. As soon as I untangled my forehead from the dashboard, I started screaming at him. His reply?

My brother lives down that street!

In Blogger Help Forum: Something Is Broken, we deal with the reckless abandon of some blog owners, setting up their custom domains.

There is much confusion, and bad advice, provided by blog owners who want to publish their blogs to custom domains - but find the official instructions to be either confining or confusing.

For every need, you will find bad advice.

• Can't buy a domain? No problem, get a free domain.
• Can't figure out the supported DNS configuration? No problem! Get the registrar to setup forwarding!!
• Can't wait for HTTPS connectivity provided by Blogger? Use proxied SSL from CloudFlare!!!
• Want to publish to the domain root ("naked" domain)? No problem! There's a great kludge for that, too!!!

There's a workaround, for every need - but how many are effective, long term?

And here in Blogger Help Forum: Something Is Broken, we see the results.

• Poor search engine activity.
• Spurious malware / spam classification.
• The old "Another blog ..." / "Key already exists ...".

And all of these symptoms - and the frustrating secondary results - can be avoided.

If you want to setup your domain, properly - and you find the official instructions to be confining or confusing - see my tutorial here - and more recently, here.

You may, alternately, read my forum FAQ, here - or the official Blogger Help FAQ, here.

Many problems can be avoided - if you only believe. There is but one configuration, for each publishing need - if you want to avoid the problems - though some folks may be more optimistic.

• Poor search engine activity.
• Spurious malware / spam classification.
• The old "Another blog ..." / "Key already exists ...".

Or, we'll see you, in Blogger Help Forum: Something Is Broken - whether immediately, or years later.

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

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

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

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

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

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

• eNom
• GoDaddy

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

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

>> Top

eNom Hosted Custom Domains Showing Intermittent Connectivity Issues

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

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

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

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

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

REGISTRY WHOIS FOR mydomain.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

---

>> Top

Google Friend Connect Accessory Stopped Working For Some Custom Domain Published Blogs

We are observing owners of a few Blogger blogs reporting that the popular Google Friend Connect accessory, as suggested last year, recently stopped working, on their blogs.

I have a Blogger blog but I'm using a custom domain (not purchased through Blogger though) - and my Google Friend Connect is gone now, just like they announced it, concerning the other non-Blogger blogs.

From a brief check of several blogs reporting this change, it appears that blogs published to non BlogSpot URLs, using custom domain publishing with incorrect DNS setups, are being treated as non Blogger blogs. The Following / Google Friend Connect accessory, on those blogs, is now stopped.

Last year, we were informed that Google was going to stop providing the immensely popular Following / Google Friend Connect gadget for websites outside Blogger. It appears that the referenced change is now in effect - and Google Friend Connect is no longer a non Blogger accessory.

Since Blogger blogs can be published to BlogSpot URLs (using native settings) - or to any available non BlogSpot URL (using custom domain publishing), it's not a simple process to identify a Blogger blog. It appears that Blogger blogs published to non BlogSpot URLs, using custom domain publishing, are being treated as non Blogger blogs - when the domain DNS addresses redirect incorrectly.

For some Blogger blog owners, who have been using (marginally) incorrect DNS addressing for their custom domain published blogs, and whose Following / Google Friend Connect gadgets have stopped working, the task is simple.

1. Correct the DNS addresses.
2. Re publish the blog.

The detail, that not all blog owners will find this an immediately convenient project, is unfortunate.

>> Top

Custom Domains Redirecting To Google Sites

Similar to a redirection to the Google Apps Start Page service, some custom domains will be found to be directed to Google Sites. Again, we'll see an apparently normal (asymmetrical) DNS address configuration.

mydomain.net.            3600    IN      A       216.239.32.21
mydomain.net.            3600    IN      A       216.239.34.21
mydomain.net.            3600    IN      A       216.239.36.21
mydomain.net.            3600    IN      A       216.239.38.21
www.mydomain.net.      3600    IN      CNAME   ghs.google.com.
---
ghs.google.com.         282206  IN      CNAME   ghs.l.google.com.
ghs.l.google.com.       300     IN      A       74.125.43.121 

The diagnosis, again, will be made using an (abbreviated) HTTP trace.

Sending request:

GET / HTTP/1.1
Host: mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://www.mydomain.net(CR)(LF)

Sending request:

GET / HTTP/1.1
Host: www.mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://sites.google.com/a/mydomain.com/sites/system/app/pages/meta/domainWelcome(CR)(LF)

Unlike the generically known "Server Not Found Error 404" symptom, this one won't be solved by merely publishing back to Blog*Spot, then re publishing to the custom domain.

What we see here is that Sites, similar to Start Page, is apparently enabled, and published to "www.mydomain.net". In this case, you're going to first have to disable Sites. If you don't, you're going to see another old friend

Another blog is already hosted at this address.

After doing that, then you can publish back to Blog*Spot, then re publish to the custom domain.

A second variation on this redirect may not start with an explicit "Server Not Found Error 404", and the HTTP trace will be slightly different. You will probably see "Another blog is already hosted at this address." in the usual places.

Sending request:

GET / HTTP/1.1
Host: mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Connection: close

• Finding host IP address...
• Host IP address = 216.239.34.21
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://www.mydomain.net(CR)(LF)

Sending request:

GET / HTTP/1.1
Host: www.mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·200·OK(CR)(LF)

(Here is a short excerpt of the rest of the trace -
you have to look carefully for these clues)

<body·xmlns="http://www.google.com/ns/jotspot"·id="body"·class="·en">(LF)
<div·id="sites-page-toolbar">(LF)
<div·id="sites-status"·class="sites-status"·style="display:none;">(LF)
<div·id="sites-notice"·class="sites-notice">·</div>(LF)
</div>(LF)
</div>(LF)
<div·id="sites-chrome-everything"·style="direction:·ltr">(LF)
<div·id="sites-chrome-page-wrapper">(LF)
<div·id="sites-chrome-page-wrapper-inside">(LF)
<div·xmlns="http://www.w3.org/1999/xhtml"·id="sites-chrome-header-wrapper">(LF)

As shown immediately above, we have Google Sites involved, though less obviously. Resolution of this scenario, too, seems to involve disabling Sites. After doing that, you will likewise need to publish back to Blog*Spot, then re publish to the custom domain.

>> Top