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 A Custom Domain. 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.

>> Top

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 317 posts (as of 2013/11/21) - 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 317 chapters.

---

How To Use This Guide

• Always start properly, with righteous 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 righteous 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 a righteous 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 is already using this address." (or a similar phrasing), in the Settings - Basic - Publishing display.
• 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.
• 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 if it's not too late, read Setting Up A Custom Domain, before you start.

---

>> Top

New Custom Domains Purchased From A Registrar, And Lacking The Transition Period For New Domains

We've known about the Transition period, which has applied to domains purchased through Blogger, for a few years.

Under Transition, domains purchased using "Buy a Domain" were only partially published, immediately after the domain purchase - with the publishing process completed, several days later. The Transition period allowed for the domain, newly setup by "Buy a Domain", to become fully visible on the Internet, before blogs subject to Transition were re published.

The Transition period was originally applied to blogs re published using "Buy a Domain", to delay redirection of the BlogSpot URL to the domain URL, until after a new domain was fully visible, to all Internet DNS servers.

Transition was designed to apply to new domains, purchased using "Buy a Domain", with the hope that domains purchased outside "Buy a Domain" would not need Transition.

When "Buy a Domain" was active, most blogs being published to domains not just purchased using "Buy a Domain" did not require Transition.

• Blogs published to domains, purchased directly from a registrar, would be owned by people with experience setting up domains. People with experience would be able to cope better with the DNS Latency, and inherent instability, involved with new domains.
• Some blogs would be published to mature domains, which would not need Transition at all.

With the ending of the "Buy a Domain" feature, we now have every new domain owner, experienced and not, purchasing domains directly from registrars.

In many cases, Transition is not needed for newly purchased domains, when the owner is not experienced. Inexperienced domain owners make mistakes, when setting up their domains. The domain setup process creates its own limited length "Transition" period, for inexperienced domain owners.

Recently, some domain owners have reported a new symptom, when using the Publishing wizard, to publish their blogs to their newly purchased domains.

This operation failed. Try again later. If the problem persist, please file a post on the help forum.

This new symptom may be replacing the long dreaded "Another blog or Google Site is already using this address.".

Most domain owners, seeing "This operation failed.", have domains with bad DNS addresses. They are generally instructed

You need to correct your DNS addresses.

Those not instructed to correct their DNS addresses should probably be advised

Your DNS addresses are righteous. You now need to wait 24 to 48 hours, for the newly purchased domain to be visible, everywhere on the Internet.

The latter advice will be necessary, simply because the domain was properly setup, immediately - even with the domain not fully visible across the entire Internet.

What happens with gadgets, which need updating, is yet to be observed.

>> Top

Blog Owners Reporting Custom Domain Setup Showing "This operation failed."

This week, we're seeing a few reports, in Blogger Help Forum: Something Is Broken from blog owners, trying to publish their blogs to custom domains.

I'm trying to use the Publishing wizard - and I'm seeing a new error.

This operation failed. Try again later. If the problem persist, please file a post on the help forum.

What has Blogger changed, recently?

It appears that we are now seeing a new phrasing of the well known error

Another blog is already hosted at this address

The majority of the domains showing this error, when checked, have bogus or missing DNS addresses. We see the usual demurrals.

I just got off the phone with the registrar. They say everything is fine on their end.

This is simply more of the same - registrars that still do not understand the importance of using referral, as opposed to forwarding, for custom domain publishing.

Once again, I cannot over emphasise the importance of righteous DNS addresses, when setting up a custom domain. It appears that, contrary to current instructions from Blogger Help, there is still just one working DNS address model, for custom domain publishing.

If you try to publish your blog to a custom domain, and the domain has any DNS addresses defined, the addresses must be righteous. If the defined addresses do not match the one known DNS model, expect now to see a new monolithic error.

This operation failed.

In some cases, it's possible that newly purchased domains, not subject to the Transition period earlier provided by "Buy a Domain", may display this error because of DNS propagation latency. New domain owners, even when they are able to setup a domain properly, may see this error because the new domain is simply not visible to all Internet DNS servers.

>> Top

How To Unmap Google Sites To Solve "Another blog or Google Site is already using this address."

The literal cause of the error "Another blog or Google Site is already using this address." is that the Google Sites service is mapped to the address in question, in the Google domain services mapping database.

Some help articles published on the Internet imply that Sites mappings are the only cause of this error. This misconception creates some of the confusion associated with the error. Sites is not the only service in the services mapping database - but it is the only service with web address mappings.

The Sites service contains both service address, and web address, mappings - and both mappings can cause this problem. This oddity creates complexity, and makes a linear check list impossible, when using Google Apps to clear the error - as well as diagnosing the error, in a typical dialogue in Blogger Help Forum: Something Is Broken.

When the Sites service is suspected as the cause of "Another blog or Google Site is already using this address.", one must check both the Service Address Mapping, and the Web Address Mappings, in the Sites service.

Note that the presence of the mappings is not directly affected by the presence of the service wizards, on the desktop of the Google Apps account which you are using. Neither deleting the Apps account, nor uninstalling a given service wizard from the desktop, will immediately reset the mappings for that service, from the database.

If not present on the desktop, the Sites service must be first installed and activated, using the dashboard "Get more apps and services" link.

The Sites service address mapping, like all other services, can be examined and reset using the CustomURL form in Google Apps, as well as "Change URL" in the "General" tab, in the Sites Settings menu. The web address mappings can only be examined and reset using the "Web Address Mapping" tab, in the Sites Settings menu.

1. Select the "Web Address Mapping" tab, in the Sites Settings menu.
2. Select all addresses mapped, and click on "Delete Mapping(s)".
3. Click on "Yes" in the "Are you sure" popup.

A Sites service address mapping, like other service address mappings, can sometimes be diagnosed in a simple "302 Moved Temporarily" redirect, in a typical HTTP trace.

Sending request:

GET / HTTP/1.1
Host: www.letthykingdomcome.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0)
 Gecko/20100101 Firefox/18.0
Referer: http://www.rexswain.com/httpview.html
Connection: close

• Finding host IP address...
• Host IP address = 74.125.129.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)
Content-Type:·text/html;·charset=UTF-8(CR)(LF)
Location:·http://sites.google.com/a/letthykingdomcome.com/
 sites/system/app/pages/meta/domainWelcome(CR)(LF)

A Sites web address mapping is not always so easy to diagnose - and may be the reason behind the fact that some HTTP traces end with the blog owner reporting "Another blog or Google Site is already using this address.", and an HTTP trace simply showing the generic 404 Not Found.

Sending request:

GET / HTTP/1.1
Host: www.markhamdesign.co.uk
User-Agent: Mozilla/5.0
 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Referer: http://www.rexswain.com/httpview.html
Connection: close

• Finding host IP address...
• Host IP address = 216.239.32.21
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:
HTTP/1.1·404·Not·Found(CR)(LF)

A Sites "Web Address Mapping" can include an address which is mapped outside Google Apps. This creates a mapping which can't be managed using Google Apps.

If you own a domain and have access to change the CNAME record, you can map any site created in Google Sites outside of Google Apps (for example, sites.google.com/site) to a custom URL

Sending request:

GET / HTTP/1.1
Host: www.medtechpedia.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Referer: http://www.rexswain.com/httpview.html
Connection: close

• Finding host IP address...
• Host IP address = 74.125.129.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)

<body·xmlns="http://www.google.com/ns/jotspot"·id="body"·class="·en············">(LF)
<script·src="//www.gstatic.com/caja/5246m/caja.js">·</script>(LF)
<script·src="http://www.gstatic.com/sites/p/926884/system/js/jot_caja.js">·</script>(LF)
<div·id="sites-page-toolbar"·class="sites-header-divider">(LF)
<div·xmlns="http://www.w3.org/1999/xhtml"·id="sites-status"·class="sites-status"·style="display:none;"><div·id="sites-notice"·class="sites-notice"·role="status"·aria-live="assertive">·</div></div>(LF)
</div>(LF)
<div·id="sites-chrome-everything-scrollbar">(LF)
<div·id="sites-chrome-everything">(LF)
<div·id="sites-chrome-page-wrapper"·style="direction:·ltr">(LF)
<div·id="sites-chrome-page-wrapper-inside">(LF)
<div·xmlns="http://www.w3.org/1999/xhtml"·id="sites-chrome-header-wrapper"·style="">(LF)
<table·id="sites-chrome-header"·class="sites-layout-hbox"·cellspacing="0"·style="">(LF)
<tr·class="sites-header-primary-row"·id="sites-chrome-userheader">(LF)
<td·id="sites-header-title"·class=""><div·class="sites-header-cell-buffer-wrapper"><h2>
  <a·href="http://sites.google.com/site/medtechpedia/"·dir="ltr"·id="sites-chrome-userheader-title">MedTechPedia</a></h2></div></td><td·class="sites-layout-searchbox·"><div·class="sites-header-cell-buffer-wrapper"><form·id="sites-searchbox-form"·action="/system/app/pages/search"><input·type="hidden"·id="sites-searchbox-scope"·name="scope"·value="search-site"·/><input·type="text"·id="jot-ui-searchInput"·name="q"·size="20"·value=""·aria-label="Search·this·site"·autocomplete="off"·/><div·id="sites-searchbox-button-set"·class="goog-inline-block"><div·role="button"·id="sites-searchbox-search-button"·class="goog-inline-block·jfk-button·jfk-button-standard"·tabindex="0">Search·this·site</div></div></form></div></td>(LF)
</tr>(LF)
<tr·class="sites-header-secondary-row"·id="sites-chrome-horizontal-nav">(LF)
<td·colspan="2"·id="sites-chrome-header-horizontal-nav-container">(LF)
<div·class="sites-header-nav"><ul·class="sites-header-nav-container-tabs"><li·class="current"><a·class="sites-navigation-link·current"·href="/home">Home</a></li><li·class="unselected"><a·class="sites-navigation-link·unselected"·href="/introduction-to-medical-technology">Introduction·to·Medical·Technology</a></li></ul><div·style="clear:·both;"></div></div>(LF)
</td>(LF)
</tr>(LF)
</table>·(LF)
</div>·

>> Top

How To Solve "Another blog or Google Site is already using this address."

Of all of the problems that are typically reported, in Blogger Help Forum: Something Is Broken, surely the most frustrating has to be

Another blog or Google Site is already using this address.

One of the reasons for the frustration is that this is not a descriptive error - it's more of a symptom - and this symptom has a number of causes. Since many Blogger blog owners don't understand the principles of problem solving, the solutions for this error may not be obvious.

The monolithic message "Another blog or Google Site is already using this address." is actually a symptom of a number of possible problems.

Some time ago, I identified three categories of problems, which cause the message to be displayed.

1. The URL in question is actually in use, with another blog already published to that domain URL.
2. The DNS addresses are improperly setup, and not pointing to the correct Google servers.
3. There are broken / duplicate pointers, which affect the domain, in the Google internal database.

Check For A Blog Already Published To The Address

If there is a blog already published to the URL, and you control both blogs, make a simple decision - which blog to publish, to the URL in question. If necessary, a second blog can be published to a different host in the domain, and setup a domain cluster. In some cases, a previous domain owner may have published a blog, which you won't control, to the domain.

Check The DNS Address Setup

Having eliminated or solved the possibility of multiple blogs, check and - if necessary - correct the DNS addresses setup for the domain. There are three DNS address models - with one, asymmetrical, being involved with over 99% of the blogs reported with this problem. There is simply no alternative to "CNAME" forwarding, when publishing a blog to a custom domain.

Check For Service Redirections

With the DNS addresses corrected - and DNS propagation latency allowed for - diagnose the problem using a series of HTTP traces. Here, we'll generally see a number of possible redirections.

1. Calendar.
2. Drive and Docs.
3. Email.
4. Sites.
5. Start Page.

If the HTTP traces do not indicate a specific service, you may have an indeterminate case of database corruption.

When dealing with service redirections, start by establishing access to the Google Apps domain administrator desktop. If the domain was purchased in 2013 or later, you'll have use of a basic function Apps account. You'll use two Apps desktop wizards - "Organization & users" and "Settings".

1. Use "Organization & users", to install and activate any service.
2. Use "Settings" to disable mappings, and to uninstall any service.

Named Service Redirection

For a named service redirection:

1. If necessary, install and activate the service.
2. Delete the mappings for the service.
3. Uninstall the service.

Database Corruption Or Unknown Service Redirection

If a specific service is not identified in the HTTP traces, check the "Change URLs for multiple services" display, which is accessible from any "Change URL" service wizard.

1. Select any service, in the "Settings" wizard, and the "Change URL" link for that service.
2. Click on "Change URLs for all domain services".
3. Examine the "Change URLs for multiple services" display, and select the custom mapping, for any service with the default mapping (top) address selected. If any service entry is changed, click "Continue".
4. For each service with mapping which was just changed:
   • If necessary, install and activate the service.
   • Uninstall the service.

Just read about the details, take it one step at a time - and allow time to complete the entire task, carefully.

>> Top

How To Use Google Apps To Solve "Another blog or Google Site is already using this address."

The Google domain services database lets one or more Blogger blogs, and / or various Google services, be packaged as part of a domain - giving your organisation its own virtual web server.

Google Apps is used to manage this virtual web server, as you install and un install various domain services. Sometimes a domain, newly setup in Google after the domain has been purchased from a registrar, will have one or more addresses unexpectedly mapped to various Google services. This will be inconvenient to the blog owner, who may wish to use a given URL for a Blogger blog.

The most common cause of the error "Another blog or Google Site is already using this address." involves unexpected mappings, in the Google domain database.

When your domain has unwanted mappings, you'll need to use the Google Apps domain administrator desktop, and various utilities there, to remove the mappings and reset the services. To start, you'll need access to the Google Apps desktop for the domain administrator. For domains recently purchased using Blogger or Google wizards, you'll have a limited function domain administrator desktop.

You'll use two Apps desktop wizards - "Organization & users" and "Settings".

• Use "Organization & users", to install and activate a service.
• Use "Settings" to disable / remove mappings, and to disable / uninstall a service.

Install And Activate Services

Use "Organization & users" - "Services", to activate the various services.

• To install a service, click on "Dashboard", find "Common tasks" at the bottom left, and click on "Get more apps and services". Click on "Add it now", for the needed service.
• To activate a service, go to "Organization & users" - "Services", and look under "Core Google Services" or "Additional Services", for the service in question - and click on the coloured toggle switch as necessary. Then click on "Save changes".

Remove Mappings

Use the Settings wizard, for the service in question - to add and remove address mappings, and to deactivate services. Each different service, listed in Settings, has a different set of menus, and different options.

We currently know of 5 services which can be mapped to a domain, which may interfere with publication of a Blogger blog to a domain address. Any problem service, currently mapped to the default (top) address, will need to be changed to map to the custom (bottom) address.

1. Calendar.
2. Drive and Docs.
3. Email.
4. Sites.
5. Start Page.

To remove address mappings for Calendar:

1. Click on "Calendar", then the "General" tab, then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. If you change the Calender mapping, remember to uninstall Calender.

To remove address mappings for Drive and Docs:

1. Click on "Drive and Docs", then the "General" tab, then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. If you change the Drive and Docs mapping, remember to uninstall Drive and Docs.

To remove address mappings for Email:

1. Click on "Email", then the "General Settings" tab, then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. If you change the Email mapping, remember to uninstall Email.

To remove address mappings for Sites, some extra effort may be required:

1. Click on "Sites", then the "General" tab, then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. Select the "Web Address Mapping" tab.
4. Select all addresses mapped, and click on "Delete Mapping(s)".
5. Some Sites mappings can only be diagnosed, and reset, outside Google Apps.
6. If you change any Sites mapping, remember to uninstall Sites.

To remove address mappings for Start Page:

1. Click on "Start Page", then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. If you change the Start Page mapping, remember to uninstall Start Page.

The CustomURL Wizard

Besides the multiple Sites mappings (in "Web Address Mapping"), it may be possible to use the "CustomURL" wizard, which will list all active services and current mappings. The CustomURL wizard is accessed from any "Change URL" wizard.

1. Click on "Change URLs for all domain services".
2. Examine the "Change URLs for multiple services" display, and disable any references to the default mapping. Select the custom mapping (bottom) address, for any service with the default mapping (top) address selected. If any service entry was changed, click "Continue".
3. For each service with mapping which was changed:
   • If necessary, install and activate the service.
   • Uninstall the service.

Disable / Uninstall Services After Changing Mapping

If you did change or delete any mappings, whether using CustomURL ("Change URLs for multiple services") or an individual service wizard ("Change URL" / "Web Address Mapping"), the final step is to disable or uninstall each service for which you changed or deleted mappings. If you do intend to use any named service, re install it later - after you get your custom domain working.

To uninstall Calendar, click on "Calendar", then the "General" tab. Click on "Uninstall Calendar", next to "Uninstall service".

To uninstall Drive and Docs, click on "Drive and Docs", then the "General" tab. Click on "Uninstall Drive and Docs", next to "Uninstall service".

To uninstall Email, click on "Email", then the "General Settings" tab. Click on "Uninstall Email", next to "Uninstall service".

To uninstall Sites, click on "Sites", then the "General" tab. Click on "Uninstall Sites", next to "Uninstall service".

To disable Start Page, click on "Start Page", then on "Disable Start Page", next to "Disable service".

>> Top

When You Publish Your Blog To A Custom Domain, Almost Always Publish To The "www" Alias

Of all of the known problems with Blogger, in general - and of the known problems with Blogger / Google Custom Domain Publishing, specifically - surely the most frustrating single problem starts with the well known monolithic error

Another blog or Google Site is already using this address.

The most frequently seen solution to this problem, contrary to the opinions expressed in some blogs and websites, starts with correction of the domain DNS addresses. But even after careful DNS address correction, some blog owners still report the well known "Another blog ..." error.

Maybe 99.99% of the custom domain published blogs use what I call an asymmetrical DNS address configuration.

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

Note the restriction with the asymmetrical configuration, sometimes overlooked.

With an asymmetrical configuration, you may not publish to the domain root. Your only valid choice is to publish to "www.mydomain.com", and select "Redirect mydomain.com to www.mydomain.com". If you publish to "mydomain.com", you will eventually see

Blogs may not be hosted at naked domains.

or maybe a well known monolithic error

Another blog or Google Site is already using this address.

The conclusion is simple. Unless you intentionally created a symmetrical or non root virtual host address configuration, always publish to the "www" alias.

>> Top

Google Apps Ends Availability Of Their Free Edition

Last week, Google dropped a bombshell on many small client developers.

Starting on December 6, 2012, Google will no longer offer new accounts for the free edition of Google Apps. Google Apps free edition is sometimes referred to as "Standard Edition."

This announcement will bring changes to Blogger, and to custom domain publishing. Many owners of Blogger blogs published using the Google Custom Domain feature have learned to use various Google Apps wizards, to setup and to maintain their domains.

Blogger blog owners have learned (some unwillingly) to use Google Apps for various tasks.

1. Access the registrar's Domain Manager wizard, after using "Buy a domain".
2. Deactivate service redirects, such as the Sites service.
3. Maintain domain "auto renew" settings.
4. Reset the ever painful "Another blog ..." symptom of database corruption.
5. Set the option to "Redirect mydomain.com to www.mydomain.com".
6. Setup email delivery for the domain.

Each of these tasks will have to be performed in different ways, for blog owners who purchased their domains after last week. Previously setup Apps accounts, for the immediate future, are safe.

If you already have the free edition, you can continue to use it for free. This change has no impact on existing users of the free edition.

So far, we've seen some new domain owners use the Trial version of Google Apps, to recycle domain settings, when dealing with "Another blog ...". We hope that this technique will allow temporary access to the domain root redirect, and to service redirect, settings also. We are also seeing a limited functionality free version, which requires some effort to setup, in some cases.

I'm still wondering where Google will hand out Registrar login instructions, and let us maintain domain renewal settings. The popular option to have custom email addresses, based on the domain URL, is most likely gone.

I'll update this article, as details are provided.

>> Top

Using The Google Apps Domain Root Redirect Setting

Recently, Google Apps added a setting to the domain administrator desktop GUI, which controls the redirect of the domain root (aka "naked domain"). We initially observed this setting, as an option in working around the problem of setting the domain root redirect, in the Blogger Publishing "Advanced Settings" wizard. It's also possible that this setting should be used in recycling the domain settings, when faced with the "dreaded "Another blog ..." error.

Use of the Google Apps Domain Redirect setting is not complicated. It starts with setup of the domain administrator account. For any newly purchased domain - as well as for domains purchased directly from a registrar, it's a fairly simple matter to setup a Google Apps domain administrator account - then to set (or reset) the redirect.

Having logged in to your new Google Apps account, as the domain administrator, you simply click on "Domain settings", then "Domain names". Under the Status column for your domain, you'll find the link to "Change redirect". Hoping that you have a standard asymmetrical DNS configuration for the domain, already setup, you can ignore the warning

To enable this redirect, you must change the A record with your domain host.

and simply click on "Redirect your naked domain" (for a new domain), or "Change redirect" (for an existing domain).

This is a new domain, with the domain root not yet redirected.
This is an existing domain, with the domain root redirected to "www.nitecruzr-test.net".
If the domain DNS addresses are not setup with both the source and target of the redirect (the "naked domain" and alias) pointing directly to the proper Google servers, as in either the symmetrical or asymmetrical DNS address configuration, the redirect setting is useless. The redirect only works within Google servers. This is another scenario where DNS addresses which use forwarding will not work.


The "Change how your naked domain is redirected" display simply lets you designate the "www" (or any alternate) alias as the target for the naked domain redirect.

Designate a web address to direct your users to when they access your naked domain.

Entering the target (defaulting, simply, to "www"), then hitting "Save changes", you are done with this procedure. Now, the domain root should redirect to the alias of your choice.

If you are recycling the domain settings, you'll want to change the redirect setting to something other than "www" - let us say "test" - then change back to "www".

1. Set the redirect to "test", and hit "Save changes".
2. Set the redirect to "www", and hit "Save changes".
3. You're done with this exercise.

If you are clearing the setting, so you can continue with the Blogger Publishing process, you may shorten the exercise a bit.

1. Set the redirect to "test", and hit "Save changes".
2. You're done with this exercise.

In either case, you now continue with the main task at hand, if necessary.

>> Top

Observe DNS Address Entry Conventions, When Setting Up Your Custom Domain

One of the more frustrating steps involved in setting up a custom domain comes with entry of the DNS addresses, into the domain host or registrar's Domain Manager wizard.

Whether you are setting up a new domain, just purchased directly from a registrar - or re publishing an existing domain, purchased using "Buy a domain" - the addition of the proper DNS addresses is essential to successful custom domain publishing.

Sometimes, you just can't get the domain manager wizard to accept what you are provided by "settings instructions". Other times, you enter the proper values, your Zone Update is accepted by the domain manager wizard - and the Blogger Publishing wizard rejects your attempts.

Even after repeated attempts to publish your blog to the domain, you can get another "Another blog ..." error - maybe an "Error 12" or variant.

This may be in spite of the fact that you are retrieving a new "Name" / "Destination" periodically from "settings instructions", and dutifully adding or updating the domain ownership verification "CNAME" Alternately, you may just be adding the base DNS "A" or "CNAME" addresses.

Every blog owner needs to realise that the Domain Manager wizards have conventions for entry of both the "Name" ("Label" / "Host"), and the "Destination" ("Target" / "Points To") values in the DNS address records ("Zone Entry"). The conventions used will vary, from Domain Manager to Domain Manager - and the differing conventions will affect the success of your domain publishing attempts.

In some cases, the Domain Manager will immediately reject your entry, if you mis enter the value. In other cases, the entry will be accepted - but Blogger will reject your attempts to publish. Either scenario can be caused by misentry of either the "Name" or "Destination" value, and your overlooking the differences between "absolute" vs "relative" addresses.

This problem is observed by some as the mysterious "period" / "full stop".

• If you omit the period, and it is required, the Zone Update may take place - but the Blogger Publishing wizard will overlook or reject the resulting DNS address.
• If you add the period, and it is not allowed, the Zone Update will reject your attempt.

This can happen for either the "Name" or "Destination" value.

Here, I will note that this problem is one which neither Blogger nor Google can resolve. Whether you purchased the domain using "Buy a domain" - or directly from the registrar - if you must use the Domain Manager wizard provided by the DNS Host / Registrar, your understanding of the conventions observed by that Domain Manager are your responsibility. There are conventions for the "Name" and for the "Destination" values - and you have to find out, and follow, each.

For a domain of "mydomain.com", you will probably enter the published address - "www.mydomain.com" - as "www". This says that the "Name" value is "relative" to the domain URL. You can't enter the domain root, "mydomain.com", as "mydomain.com" - as this would give you a DNS address of "mydomain.com.mydomain.com" - and yet another "Another blog ..." error. You will probably need to enter the domain root as "@" or a similar special character. This, too, is your responsibility to verify.

If you are asking for help in Blogger Help Forum: Something Is Broken, and I am advising you, I'll be asking you for three essential values.

1. The BlogSpot URL.
2. The domain URL.
3. The "Name" value provided by the "settings instructions" document.

None of these values are optional - and strict attention to accuracy, in your reply, is essential.

>> Top

Blog Owners Seeing bX-afpmyd When Trying To Un Delete Custom Domain Published Blogs

We're seeing a few reports this week, from blog owners who recently deleted their custom domain published blogs - who now lament their decision - and who are unable to un delete the blogs.

I can't "undelete" my blog, that used to be published as a custom domain URL. I received the following error code: bX-afpmyd.

This problem, like others, appears to have started when custom domain publishing was restored, last week.

Blogs deleted when a custom domain URL is in use have always been a challenge. Similar to the abandoned custom domains problem, they have resulted in yet another cause for the well known custom domain problem

Another blog ....

Now that Blogger is requiring verification of domain ownership, by adding ownership certification using a new "CNAME", it's likely that either lack of the new "CNAME", or broken blog / domain pointers, are going to be a problem when un deleting blogs formerly published to custom domains.

If you are unable to un delete your previously deleted custom domain published blog - and you are otherwise able to restore the blog in question - you, like other blog owners trying to make changes to their custom domain published blog, will need to use the Publishing wizard, and the "settings instructions", and add a unique domain ownership certificate to your non BlogSpot domain. Then, if able to un delete the blog, you'll need to re publish the blog to the domain.

>> Top

The Old "Another blog ..." Problem - The Domain Settings In Google Apps

The use of Google Apps, for resetting the domain settings, frequently requires much repetition - yet seldom produces consistent results. Some blog owners are able to disable a single service to get their domain working, others must recycle the service settings repeatedly - and still others must spend time anxiously recycling one service after another, then looking for more, unnamed services to recycle.

Some blog owners look for shortcuts in the recommended process - such as deleting the Apps account, which simply wastes time. Unfortunately, very few shortcuts, when identified, are consistently effective for other blog owners later. This lack of consistency leads to various comments mentioning lack of useful advice, in the forum discussions.

There are basically 4 levels of complexity involved, in the process of resolving "Another blog ...".

• Disable one named service.
• Recycle one named service.
• Disable multiple services, one by one.
• Recycle multiple services, one by one.

When the blog owner is able to describe a Sites page display - or we can use an HTTP trace to identify a Sites redirect, we can with some confidence advise the owner to simply disable the Sites service. If simply disabling Sites (or whatever named service - AdServices, Start Page, what have you) is not effective, we then advise recycle the settings, against the named service.

The most basic domain problem report starts with a simple

I keep seeing

Another blog or Google Site is already using this address.

when I try to publish my blog.

Problem reports submitted with this lack of detail, on the other hand, will, most likely, require the owner to recycle multiple service, one by one.

Besides the confusion resulting from the multiple levels of complexity, not all blog owners setup a Google Apps desktop account to administer the domain - even when they purchased the domain using "Buy a domain", and got the "Welcome to Google Apps" email upon purchasing. A blog owner who used "Buy a domain", and neglected to setup the provided Apps account, will be unable to use Apps - and will be unable to access the eNom or GoDaddy Domain Manager, when necessary.

When the domain is purchased directly from a registrar, the blog owner is still less likely to proactively setup the Google Apps account. Fortunately, with the domain purchased directly from the registrar, and having just setup the DNS addresses to publish the blog to the domain, the blog owner will have immediate access to the registrar's Domain Manager wizard.

Another source of frustration, involving the service recycling, is that recycling may require first repairing bogus DNS addresses. Having learned the process of correcting improper DNS addresses, the blog owner must next learn the intricacies of setting up the Apps account, then of recycling multiple service settings, repeatedly.

The solution, recommended by Blogger Support, is to submit a reset request using the "Custom Domain Reset" form. This is not a universally effective solution, unfortunately.

• Like many services provided by Blogger Support, there is no set schedule for actioning Domain Reset requests.
• We are never sure what direct feedback will be provided, to the blog owner, upon completion of a reset request.
• We have been advised by Blogger Support that not all instances of "Another blog" will be consistently resolved by use of the reset request form.

Considering all of these concerns, it's understandable that many blog owners become frustrated, and are occasionally observed stating their intention to return their blogs to BlogSpot hosting.

>> Top

The Old "Another blog ..." Problem - Will It Ever Be Fixed?

The ability to publish a Blogger blog to a non BlogSpot URL - also known as "Custom Domain Publishing" - has been a Blogger option for over 5 years. We have, similarly, observed the problem which is collectively described as "Another blog ..." for almost that long.

Every week, we see the signs of frustration in Blogger Help Forum: Something Is Broken.

Why does Blogger never fix the "Another blog" problem?

or

Why can I never get a straight answer here, about my inability to make my custom domain work?

Both of these questions ignore the reality - that "Another blog ..." is actually a symptom, with many different causes.

One of the challenges of dealing with "Another blog" starts with the different problems which cause this symptom - and with the different parties involved in the problems.

The most common cause of the symptom, originally - which contradicted the wording of the message - came from the domain DNS addresses being improperly setup by the blog owner. There are many ways to break the DNS addressing.

With domains purchased through the Blogger / Google "Buy a domain" wizard, a problem with the purchase process can cause incorrect / missing DNS. Trying to use an unsuitable bank account will cause payment refused by the bank.

With the domain properly purchased and setup, and pointing to the proper Google servers, the various mappings within the Google database, which connect the various services to non Google domain URLs, can cause problems. Services like AdService, Google Sites, and Start Page, like Blogger, can be mapped to a non Google domain. An existing database pointer to any such service, for the domain, will cause the Blogger Publishing wizard to report "Another blog ...".

A recently observed variation on the existing database pointer involves the domain, previously used by another Blogger blog owner, who simply stopped paying for the domain registration. The domain expired (which is how the domain was just re published) - but existing Blogger / Google mappings remain.

The causes of the first two problems (DNS addressing errors, and domain registration payment) are completely the responsibility of the blog / domain owner.

In some cases, the latter two problems (AdServices / Sites / Start Page / previously published Blogger blog) can be reset by submitting a "Magical" Custom Domain Reset request. In other cases, the new domain owner ends up recycling domain settings, using Google Apps.

Both the Custom Domain Reset request, and the Google Apps based domain settings recycling process, can cause problems. We were, long ago, advised by Blogger Support that not all mappings can be cleared by use of the form. And the complexity and lack of structure in the recycling process, can motivate some blog owners to try other, inappropriate solutions.

The bottom line is that the "Another blog" "problem" - even with carefully documented workarounds - will never be completely understood, let alone eliminated. Some magicians will suggest unilateral solutions, which will satisfy specific blog owners - but a universal solution is highly unlikely.

>> Top

You Cannot Buy A Domain From Blogger

One of the odder examples of naivete, seen occasionally in Blogger Help Forum: How Do I?, involves the custom domain purchase.

How do I buy a domain from Blogger?

or alternately

How do I have Google host my domain?

The immediate answer, properly stated, is simple.

You cannot buy a domain from Blogger. Neither Blogger, nor Google, is a registrar.

The full answer, however, is a bit more complex.

Blogger / Google provides the "Buy a domain for your blog" wizard, which simplifies the purchase and setup of non BlogSpot URLs, for our Blogger blogs - when we are able to make certain concessions in the purchase process. The "Buy a domain" wizard is simple, with some subtle restrictions.

• The "Buy a domain" wizard should not be interrupted, as it cannot be restarted.
• A major bank issued credit card, in working order, is required.
• Only specific generic Top Level domains are offered.
  • .biz
  • .com
  • .info
  • .net
  • .org
  No country Top Level domains are offered.
• The "Buy a domain" wizard uses partner registrars eNom and GoDaddy, selectable at purchase.
• If you already have an account with eNom or GoDaddy, you will end up with a second account. There is no opportunity to purchase using an existing account.
• "Buy a domain", when used, produces one and only one of the three standard domain models.

If you are able to live with the restrictions - and you are the one asking the original question

How do I buy a domain from Blogger?

chances are that you, Blogger / Google, and your readers will all be better off with you using "Buy a domain". Just please, plan the blog migration, before starting.

>> Top

Custom Domain Diagnoses - Identify DNS Address Inconsistencies

One of the more intriguing causes of intermittent custom domain problems starts with inconsistent DNS server configuration. Recently, eNom, one of the "partners" in "Buy a domain", has been serving inconsistent DNS configurations, from time to time - including one very blatant episode the afternoon of 6/18/2012, which was reported by several dozen angry blog owners.

Detecting, and diagnosing, the inconsistencies is typically a complicated process.

1. Identify the domain authority servers, typically using a Who Is lookup.
2. Dig each domain address (typically "naked domain" and "www" aliases), from each of the identified domain authority servers.
3. Extract and aggregate each Dig log.
4. Compare aggregated Dig snippets.

This was not a task for the faint of heart, or tech challenged, blog owner.

Recently, I was given a handy tool which does all of this, in one quick GUI transaction.

The Dig Web Interface, yet another free online tool, provides us the ability to diagnose inconsistent DNS servers - such as the problem eNom seems to have, in a 30 second transaction.

1. Provide the "naked domain" and "www" aliases.
2. Select "A" for "Type" ("A" / "CNAME" / "NS" lookups).
3. Select "Authoritative" for "Nameservers".
4. Hit "Dig".

Finally, just copy the log produced, for examination.

It's not a fancy tool, but it does the job - very well. Here, we see the log for this domain, "nitecruzr.net".

nitecruzr.net@ns11.domaincontrol.com.:
nitecruzr.net.  3600 IN A 216.239.36.21
nitecruzr.net.  3600 IN A 216.239.32.21
nitecruzr.net.  3600 IN A 216.239.34.21
nitecruzr.net.  3600 IN A 216.239.38.21
nitecruzr.net.  3600 IN NS ns54.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns53.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns12.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns11.domaincontrol.com.


nitecruzr.net@ns12.domaincontrol.com.:
nitecruzr.net.  3600 IN A 216.239.36.21
nitecruzr.net.  3600 IN A 216.239.32.21
nitecruzr.net.  3600 IN A 216.239.34.21
nitecruzr.net.  3600 IN A 216.239.38.21
nitecruzr.net.  3600 IN NS ns54.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns53.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns12.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns11.domaincontrol.com.


nitecruzr.net@ns53.domaincontrol.com.:
nitecruzr.net.  3600 IN A 216.239.36.21
nitecruzr.net.  3600 IN A 216.239.34.21
nitecruzr.net.  3600 IN A 216.239.38.21
nitecruzr.net.  3600 IN A 216.239.32.21
nitecruzr.net.  3600 IN NS ns54.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns53.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns12.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns11.domaincontrol.com.


nitecruzr.net@ns54.domaincontrol.com.:
nitecruzr.net.  3600 IN A 216.239.36.21
nitecruzr.net.  3600 IN A 216.239.34.21
nitecruzr.net.  3600 IN A 216.239.38.21
nitecruzr.net.  3600 IN A 216.239.32.21
nitecruzr.net.  3600 IN NS ns54.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns53.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns12.domaincontrol.com.
nitecruzr.net.  3600 IN NS ns11.domaincontrol.com.


www.nitecruzr.net@ns11.domaincontrol.com.:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.


www.nitecruzr.net@ns12.domaincontrol.com.:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.


www.nitecruzr.net@ns53.domaincontrol.com.:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.


www.nitecruzr.net@ns54.domaincontrol.com.:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.

The log is not complicated, to parse. For each URL, each authority server is identified, and Dug. In the case of this domain, hosted on GoDaddy, we see each URL, Dug from each of 4 authority servers, one by one.

If a DNS inconsistency existed, the above log would show the differing DNS addresses - such as eNom hosted domains show, from time to time. Given this tool, it may be easier to look for DNS inconsistencies, when problems with custom domains are reported, in Blogger Help Forum: Something Is Broken.

>> Top

When Using "Buy a domain", Prevent Interruptions

One of the saddest problems reports, seen in Blogger Help Forum: Something Is Broken, and mentioning the custom domain purchase process, starts with

I had a problem with my credit card, and had to get my bank to allow my purchase. But now, I see

We found an existing order for this domain. Please contact support.

or maybe

I had to answer the phone after I started my purchase, and now the domain that I wanted isn't available. How do I get the domain that should be mine?

These problem reports are from people who did not understand how simple the domain purchase process is.

1. Select an available domain.
2. Provide registration and payment information.

That simplicity is based on a monolithic restriction.

The purchase process does not allow for interruption.

It is to your advantage, when purchasing your domain, to complete the purchase, quickly.

The domain purchase process is similar to the blog setup process, as you choose an available blog name. When you identify an available and useful URL (or domain name), you need to select (or pay for) that URL (domain name) immediately. As you purchase the domain name of your dreams, remember that there are, at any time, up to 3 groups of people looking for a domain.

1. You.
2. Other Blogger blog owners, looking to buy a domain for their Blogger blog.
3. People outside Blogger / Google, looking to setup a website.

Unfortunately, only one of you can have the domain name of your dreams.

Look again, how simple "Buy a domain" is.

1. Select an available domain.
2. Provide payment information.
3. Done. Get to work, planning the migration process.

The longer you take, between starting Step #1 and completing Step #2, the greater the chance that you may see

Sorry, this domain is not available.

as you complete Step #2.

In some cases, and when you specifically see

We found an existing order for this domain. Please contact support.

we can offer you an alternative.

1. Clear cache, cookies, and sessions (all 3!), restart the browser, and try again.
2. Wait 48 to 72 hours, and try again.

This alternative allows you to "try again". It does not guarantee that the domain that you chose will still be waiting for you, when you try again. A popular domain name, based on some major cultural news event, may be gone in a matter of minutes. Wait 48 to 72 hours - and your guess is as good as mine.

Maybe, we should rewrite the purchase process.

1. Prepare.
   • Call your bank, and get your credit card cleared for the purchase.
   • Get a cup of coffee.
   • Unplug the phone.
   • Close the door of your office.
2. Select an available domain.
3. Provide payment information.
4. Done. Plug the phone back in, and rinse out the coffee cup.

Take 15 minutes out of your busy schedule, and get the purchase done. Then, return to normal life.

>> Top

Research Custom Domain Problems From The Beginning Of The Purchase

Sometimes, researching a problem, with a custom domain published blog, involves a Who Is lookup, to determine key domain details - like DNS server namess, purchase date, registrar name, and others. Starting with the properly spelled domain name is essential, to getting a useful Who Is lookup. In cases where the blog / domain owner can't spell the domain name consistently, you can start even more basically.

To determine the details about a domain purchase, when you have any doubt, ask for a copy of the invoice or receipt. If the transaction was conducted electronically, copy and paste of the key information is most useful. If the transaction involved a paper trail, have the receipt scanned, and a picture posted somewhere that you can view.

The invoice or receipt, for any domain purchase, will help identify - and confirm or deny - key details.

• Correct domain name - spelling.
• Purchase date.
• Name of registrar.

All of these details are useful, in researching a problem with a custom domain published blog.

Starting with the domain name, verified from the invoice or receipt, you can use any of several similar Who Is lookup tools.

• DomainTools.
• MXToolbox.
• Name ("who.is").
• Network-Tools.

Having multiple complementary tools can be useful, many times - both as backup (in case one is offline, for some reason) - and to confirm or deny unexpected results.

>> Top

Buying A Custom Domain Requires A Working Bank Issued Credit Card

As Blogger in general, and custom domain publishing in particular, becomes more popular in Asia and Africa, we are seeing more problems with the Blogger / Google domain purchase process. The basic problem, in Blogger Help Forum: Something Is Broken, will be expressed so simply.

My blog is showing an off-site redirect.

You're about to be redirected.

The blog that used to be here is now at http://www.mydomain.com.
Do you wish to be redirected?

What do I do now?

Some time ago, this report would have been diagnosed as spurious DNS addresses - and we would point out the necessities of proper custom domain DNS addressing, when setting up the domain yourself. Nowadays, an increasingly common diagnosis, for this problem, is an unsuccessfully purchased domain, using the Blogger / Google "Buy a domain" or Google Apps purchase process.

Some blog owners, preparing to purchase their domain, confuse the required bank issued credit card with an alternative - the bank issued debit card. When purchasing products in stores, a "debit card" looks and works the same as a "credit card". Apparently, not every "debit card" may work the same, with the Blogger / Google Apps "Buy a domain" process. It appears that in some countries, notably in Africa and Asia, debit cards are becoming a popular alternative to credit cards.

In some cases, the blog owner will check with his bank, and will find a token charge of $1 (or the local currency equivalent minimum purchase amount) posted to the account - but the $10 (or local currency equivalent) charge will not be found. Possibly, Google Checkout will show the notation

Payment declined : No reason provided

The "Buy a domain" process will appear to work, and the Blogger blog "mybloggerblog.blogspot.com" will be re published - in Transition - as "www.mydomain.com". The blog owner will find out later - after Transition expires and the republishing is completed - that the BlogSpot URL now shows an "off site redirect", because the domain was never registered.

The blog owner may receive email mentioning a problem.

Your service might be suspended.

Please pay your amount due, $10.00.
You have no valid forms of payment available for automatic charging.
Your bank or credit institution has declined an automatic payment with your Visa ...XXXX and provided the following reason: No reason provided. This form of payment can't be used. Please contact your bank for more information, then click the "Re-enable form of payment" link.

Apparently, bank issued credit cards work differently from debit cards, in the "Buy a domain" process. The bottom line is that, with the "Buy a domain" process mentioning "credit card", you will need to provide just that - and a "debit card" may not provide a reliable alternative. The reference Google Checkout: Troubleshooting Payments may provide insight here.

>> Top