Social Icons

Pages

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

Friday, 29 November 2013

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
Posted by at No comments:
Labels: , , , , ,

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

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



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


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


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


Domain Ownership Not Verified
  • 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


Domain Addresses Not Properly Chosen


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


Domain Registration Expired


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


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


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


Blog Published Partially, To The Custom Domain URL


Internal Blogger Database Corruption


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


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

Before asking for help, you can help the helpers if you have tried some affinity diagnostics or maybe some differential diagnostics - and if you are aware that not all problems may be exclusively caused by Blogger.
And if it's not too late, read Setting Up A Custom Domain, before you start.

>> Top
Posted by at No comments:
Labels: , , , , ,

Monday, 28 October 2013

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
Posted by at No comments:
Labels: , , , , , ,

Thursday, 20 June 2013

Custom Domains Purchase - "Buy a domain" Lacks The "Check Availability" Option

We're seeing a few reports from confused blog owners, in Blogger Help Forum: Something Is Broken, who want a non BlogSpot URL for their blog.
I have tried to follow the guide, but my page does not say the same as the guide.

Several blog owners, in trying to use "Add a custom domain" to buy a domain, are observing that there is no "Check Availability" sequence.

Right now, the "Add a custom domain" link in the Publishing wizard simply goes straight to the "Advanced settings" option. This conflicts with Blogger supplied instructions.
In Blogger, locate the Publishing area under the Settings tab. Settings to Publishing.

Then, click the link to add a custom domain name, enter the domain name you'd like, and click Check Availability.


Clicking on "Add a custom domain", we are immediately presented with "Advanced settings".

Right now, we're getting very terse advice from Blogger Support.
Blogger still supports custom domain hosting, though no longer offer an option to purchase domains within the product. To purchase a custom domain, please visit a third party registrar such as GoDaddy or eNom.


Until we hear more, I'll suggest use of eNom or GoDaddy, as advised. If you choose GoDaddy, you may be able to use the Blogger / GoDaddy DNS Setup wizard, to approximate the convenience of "Buy a domain". If you can't use the GoDaddy wizard, please note that the normal rules remain in full effect.

>> Top
Posted by at No comments:
Labels: , , , , , , , , ,

Wednesday, 29 May 2013

The Google Apps "bloggeradmin" Password Reset May Be Broken, For Some Domains

We've been seeing reports from some frustrated blog owners, about problems with the limited access Google Apps accounts.
I've reset my password numerous times and it still doesn't work.

Even given the recently provided "bloggeradmin" username, and the standard Google account reset process, some blog owners still cannot access Google Apps to manage their Blogger custom domain published blogs.

We do have one bit of hope. One such problem report, recently forwarded to Google Apps Support, was noted by a Google Apps Engineer with the advice
We identified a recent change which may have affected the password reset flow for some users. We expect it to either be fixed or rolled out shortly.

So, there is some hope for a few unhappy new domain owners. It's possible that this problem has been resolved, with Google Apps now using the new comprehensive Google login screen.

>> Top
Posted by at No comments:
Labels: , , , , , , , ,

Tuesday, 14 May 2013

The Google Apps "bloggeradmin" Password Reset Uses A Standard Google Account Reset

As Google Apps updates their limited function ("bloggeradmin") account setup process, we see reports from confused Blogger blog owners.
After I reset my password, I still get
The username or password you entered is incorrect
when I try to login, later!
and
I reset my password - and it changed my Blogger and GMail account - but I still can't login to Google Apps!!


The Google Apps password reset uses a standard Google account reset process - and is subject to normal account reset behaviour. If you don't reset the right account, you won't be able to login, later.

We've been warning people for years, about the need to use two browsers, to transfer a Blogger blog from one Google (GMail) account to another.

The Google Apps "bloggeradmin" account setup, like the Blogger blog transfer, works best using two browsers. The password reset, for "bloggeradmin@mydomain.com" (as an example, here) involves a Google account reset.
  1. You start the password reset from a Google Apps login screen, for "mydomain.com".
  2. After clicking on the "Can't access your account?" link, you use a standard Google account reset process.

When you attempt to login to Google Apps, click on "Can't access your account?". That takes you into the Google Account Reset process.


Provide the full account name of your Apps account.
bloggeradmin@mydomain.com
instead of
myemail@gmail.com

The Google Apps password reset, like blog account transfer, is one more process where you may need to use two different browsers. And, to be safe, clear cache, cookies, and sessions (yes, all 3!) - then restart the second browser, before opening the password reset email.

The password reset will be more likely to be successful, if your Blogger account is based on an active and real email address - this is not a good time to be anonymous.
(Update 2013/11/03): This process should be slightly simplified, with Google Apps now using the new Google comprehensive login screen.


>> Top
Posted by at No comments:
Labels: , , , , , , , , ,

Thursday, 18 April 2013

URL Availability Competition, During "Buy a Domain", Is Similar To "Create a Blog"

Some Blogger blog owners, trying to setup a new blog, discover the hard way that other people are trying to do the same thing.
When I try to use "Create a blog", I keep seeing
This name is not available.
or
Blogger is saying it's available - but as I begin to register, it says that it has already received a request for this name.


Other blog owners discover that the competition between Blogger blog owners, when using "Create a blog", also applies to "Buy a domain". And worse yet, "Buy a domain" involves competition with would be website owners outside Blogger / Google.

Besides the competition with other buyers, there's a problem that the domain purchase process takes time - and during the purchase process, someone else can be purchasing the same domain also.

The longer the purchase process takes you, the greater the possibility that someone else may "steal" the domain from you. You, and the unseen other person, may start the purchase at the same time - but the person who gets the money to their registrar first gets the domain.

Let's use "Create a blog" as a simple example of an address selection process.
  1. You type the blog name, of your choice.
  2. With every character you type, Blogger checks for availability.
  3. Initially, with not enough characters typed, you see bad news.
    Sorry, this blog address is not available.
  4. When you have typed enough characters so you are now requesting a unique name, you see good news.
    This blog address is available.
  5. Since you have, hopefully, already entered a Title and selected a Template, you now hit the "Create blog!" button.
  6. Hoping that you were fast enough, the address which was available half a second previously is available as you hit the button - and the blog name of your preference becomes your new blog name.
  7. If you were not fast enough, someone else might have snuck in front of you. Instead of seeing your new blog, you now see the bad news.
    Sorry, this blog address is not available.

The "Create a blog" wizard is simple.
  1. You see good news.
  2. You hit "Create blog!".
  3. You are done.

Even with a "Create a blog" selection period of 1 second - and if your reflexes are not that good, it could take you longer - you could lose out. What if the selection process was longer - instead of 1 second, say 5 minutes? The "Buy a domain" process is a bit more complicated, than "Create a blog".
  1. You enter an available domain URL.
  2. You hopefully see the good news.
  3. Now, you pay for the purchase.
  4. You enter all of the details, about your bank account.
  5. Google charges your bank a token amount, to verify that you actually entered a valid bank account number.
  6. You hopefully see more good news.
  7. Now, Google passes the purchase to the registrar.
  8. The registrar sends the actual purchase to your bank.
  9. Your bank credits the account of the registrar.
  10. The registrar then registers the domain, in your name.
  11. Google can then setup the addresses in the domain.
  12. Blogger can then publish the blog, to the domain.
  13. And hopefully, the blog is now live (and In Transition) with the domain URL.

The "Buy a domain" wizard is not simple.
  1. You enter an available domain URL.
  2. ...
  3. The registrar registers the domain, in your behalf.
  4. You are done.
Unfortunately, during the amount of time that it takes your bank to pay your registrar, somebody else could be buying the same domain, from another registrar. The longer that it takes your registrar to get paid, the greater the chance that someone else may register the domain, which you have supposedly paid for, before your purchase is complete.

Unfair? Certainly. But, based on the worldwide Internet based domain registry system, it can happen. What's worse, the symptoms of an unsuccessful domain purchase are similar to an attempted purchase restart.

And that leaves you with the uncertainty, when you post in Blogger Help Forum: Something Is Broken.
Blogger is saying it's available - but as I begin to register, it says that it has already received a request for this name.
And sometimes, after you wait the legendary 2 to 3 days, you find that someone else bought the domain, while you were waiting.

>> Top
Posted by at No comments:
Labels: , , , , , , ,

Tuesday, 26 March 2013

When You Setup A Custom Domain, Please Know And Observe Your Limits Of Expertise

Too many blog owners, when they setup a custom domain for their blog, do not consider the details.

We see signs of the problem, too often, in Blogger Help Forum: Something Is Broken.
Can someone give me step by step instructions for setting up a custom domain with xxxxxxx registrar? I contacted xxxxxxx customer service - and they told me a lot of things I didn't understand! Would it be easier just to transfer the domain to GoDaddy?

The short answer here would be
Yes, it would be easier just to transfer the domain to GoDaddy.
Unfortunately, that answer is not completely correct - and the correction may leave you with a broken domain.

Too many blog owners, eager to setup a non BlogSpot URL for their blog, do not consider the details involved, when they bypass "Buy a domain".

Part of the blame, for this problem, has to fall onto Blogger's head. People using "Buy a domain", for their first domain purchase, see the domain purchase as such a simple process. They never become aware of the complexities involved in a domain purchase, until they setup their second domain, and decide to "roll their own".

Let's look at the levels of experience needed.
  • Beginner: Use "Buy a domain".
  • Intermediate: Use the Google Apps or Google Wallet wizard - or alternately, buy a domain from one of the 8 identified registrars.
  • Advanced: Buy a domain, directly, from any of the thousands of registrars, worldwide.

As of 2013 June, "Buy a domain" is not offered, as part of "Add a custom domain". This will leave everybody with one option - "Advanced".
Beginner blog owners are strongly advised to use "Buy a domain". Choose an available domain, provide payment details, and your domain is setup. Wait until Transition expires, and get to work referring your readers, search engines, and other Internet services, to your new, non BlogSpot URL.

Intermediate blog owners, able to understand simple instructions, should be able to use the wizards provided by Google Apps or Google Wallet. Alternately, Blogger provides reasonably complete and simple instructions for setting up a domain with the 8 most popular registrars.

Advanced blog owners are free to choose any registrar, of the thousands out there. But beware! You are on your own, when you do this.
So choose your registrar according to your needs - and according to your skill level. Don't start a custom domain project, before verifying that your experience is complete. Make the right choice, before you sign on the dotted line.

>> Top
Posted by at No comments:
Labels: , , , ,

Friday, 1 March 2013

eNom Hosted Custom Domains Again Showing Intermittent Connectivity Issues

This week, we have a few reports in Blogger Help Forum: Something Is Broken, about active and mature domains, suddenly stopped working.
I have used my domain with no problems, since last year. Today, it suddenly stopped working, and the browser reports
Oops! Google Chrome could not find www.mydomain.com.
I asked my friends about my domain - and they tell me that my blog is inaccessible to them, also. I didn't change any settings - and it was fine, until last night.

As we reported last year, the Google partner registrar eNom occasionally has a problem with their DNS server complement. Right now, one of their DNS servers appears consistently bad.

Using a comprehensive Dig tool, we can observe a given domain, and compare the DNS addresses being served by all authoritative name servers for a given domain, in a single transaction.

Here's a hypothetical example, of what we're seeing right now, for several eNom hosted domains. 

mycustomdomain.com@dns1.name-services.com.:

mycustomdomain.com.  1800 IN A 216.239.36.21
mycustomdomain.com.  1800 IN A 216.239.34.21
mycustomdomain.com.  1800 IN A 216.239.38.21
mycustomdomain.com.  1800 IN A 216.239.32.21

mycustomdomain.com@dns2.name-services.com.:

mycustomdomain.com.  1800 IN A 216.239.36.21
mycustomdomain.com.  1800 IN A 216.239.34.21
mycustomdomain.com.  1800 IN A 216.239.32.21
mycustomdomain.com.  1800 IN A 216.239.38.21

mycustomdomain.com@dns3.name-services.com.:

mycustomdomain.com.  1800 IN A 216.239.36.21
mycustomdomain.com.  1800 IN A 216.239.32.21
mycustomdomain.com.  1800 IN A 216.239.34.21
mycustomdomain.com.  1800 IN A 216.239.38.21

mycustomdomain.com@dns4.name-services.com.:

mycustomdomain.com.  1800 IN A 216.239.36.21
mycustomdomain.com.  1800 IN A 216.239.34.21
mycustomdomain.com.  1800 IN A 216.239.32.21
mycustomdomain.com.  1800 IN A 216.239.38.21

mycustomdomain.com@dns5.name-services.com.:

org.   3601 IN
 SOA dns1.name-services.com. info.name-services.com. 2010 10800 3600 604800 3600


www.mycustomdomain.com@dns1.name-services.com.:

www.mycustomdomain.com.  1800 IN CNAME ghs.google.com.

www.mycustomdomain.com@dns2.name-services.com.:

www.mycustomdomain.com.  1800 IN CNAME ghs.google.com.

www.mycustomdomain.com@dns3.name-services.com.:

www.mycustomdomain.com.  1800 IN CNAME ghs.google.com.

www.mycustomdomain.com@dns4.name-services.com.:

www.mycustomdomain.com.  1800 IN CNAME ghs.google.com.

www.mycustomdomain.com@dns5.name-services.com.:

org.   3601 IN
 SOA dns1.name-services.com. info.name-services.com. 2010 10800 3600 604800 3600
Right now, it appears that server "dns5" is consistently broken.

It's possible that this problem will affect more eNom customers, as the day progresses, cached DNS addresses expire, and readers of various eNom hosted domains request DNS addresses. I hope that eNom Customer Service can react to this problem more promptly than they have reacted to the immediately previous problem.

>> Top
Posted by at No comments:
Labels: , , , , , , ,

Saturday, 23 February 2013

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
Posted by at No comments:
Labels: , , , , , , , ,

Sunday, 17 February 2013

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
Posted by at No comments:
Labels: , , , , , , ,

Saturday, 16 February 2013

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
Posted by at No comments:
Labels: , , , , , , ,

Monday, 11 February 2013

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
Posted by at No comments:
Labels: , , , , ,

Sunday, 27 January 2013

Blogger Magic - Republishing A Custom Domain Published Blog

Sometimes, when you have a Blogger blog, published to a non BlogSpot URL, you may need to repeat the publishing process.

Maybe, you want to change the BlogSpot or domain URL - or maybe the previous publishing did not complete, properly. If the blog is currently published to a non BlogSpot URL, you can't just publish it, again. You have to start by publishing the blog back to a BlogSpot URL, before you can again publish the blog to a non BlogSpot URL.

Given the right planning, and understanding of the tasks involved, you can do all of this in 5 minutes - less time than it will probably take you to read these instructions.

The republishing process is not complicated.
  1. Publish the blog back to BlogSpot.
  2. If necessary, make any necessary changes in BlogSpot.
  3. Publish the blog to a domain URL.
  4. If necessary, enable the domain root redirect setting.

To publish the blog back to BlogSpot, you'll use the Blogger dashboard Publishing wizard, at Settings - Basic.
  • Look at the Publishing display.
  • If the blog is published to a custom domain, click on the "X".
  • If the "X" is not visible, you'll need to know where it should be - and you can click where it should be visible.
  • If the blog is currently published to a BlogSpot URL, you may skip this step.
  • If the final objective was to return the blog to BlogSpot, you are now done.

While the blog is (temporarily) published to BlogSpot, make any necessary changes. Maybe, change the BlogSpot URL.

To publish this blog (or another Blogger blog that you own) to a domain URL:
Use the available and working redirect setting, to enable the domain root redirect, if necessary.

When you publish to a domain URL, you may have to add domain ownership verification. In this case, you'll need access to the Zone Editor wizard, provided by the registrar. If you originally used "Buy a domain" to purchase the domain, you'll need access to Google Apps, to access the registrar login instructions.

Other than the domain ownership verification, the republishing process is just a matter of 1 - 2 - 3 (maybe - 4). Having done this, be aware of the possible search engine relationship issues.

>> Top
Posted by at No comments:
Labels: , , , , , ,

Saturday, 8 December 2012

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
Posted by at No comments:
Labels: , , , , , , , , , , ,

Tuesday, 27 November 2012

To Republish A Custom Domain, You Do Have To Add A Second "CNAME"

One of the challenges of using Blogger involves following the instructions.

Blogger / Google personnel provide Help instructions which are not always updated - sometimes they simply write a new Help instructions document, leaving the old Help instructions in place.

The policy of leaving old Help instructions in place - and sometimes conflicting with new displays and procedures - occasionally causes confusion. One scenario where this causes a problem is in publishing or re publishing a blog to a custom domain.
I've seen instructions that when you buy a domain from Blogger / Google, using "Buy a domain", you won't need to create a CNAME record.

One of the advantages of using "Buy a domain" is the ease of setup. If you use "Buy a domain", you don't have to bother with any of the details. This is generally - but not always - true.

Sometimes, even using the "Buy a domain" wizard can later present a problem.

One of the known problems with "Buy a domain" results in a partially setup domain - and with a partially setup domain, you may have to re publish the blog to the domain, to get the new domain to work completely.

To re publish the blog, you have to verify your ownership of the domain - even if you previously used "Buy a domain". And the additional step of adding a second "CNAME" overrides the old Blogger Help instruction
If you bought your domain name from Blogger, you won't need to create a CNAME record.
When you are instructed to re publish the blog using "Advanced settings", that 's what you must do. And, when "Advanced settings" contains instruction to add a second "CNAME", then please - add a second "CNAME".

>> Top
Posted by at No comments:
Labels: , , , , , ,

Monday, 19 November 2012

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
Posted by at No comments:
Labels: , , , , , , ,

Sunday, 18 November 2012

Blog Owners Seeing "Error 14" Or Similar Symptom, When Attempting To Publish To A Custom Domain URL

We're seeing a small but steady flood of reports, in Blogger Help Forum: Something Is Broken, from blog owners attempting to publish their blogs using a custom domain URL.
I am not able to redirect my blog from blogspot to my own domain! Blogger is giving me the error
We have not been able to verify your authority to this domain. Error 14.

This specific problem has been observed numerous times in the past, ever since Blogger added the domain ownership verification process to the custom domain publishing feature. Problem reports require careful diagnosis, involving examination of the basic DNS addresses setup with the registrar, to verify the "Error 14" as the primary problem.

Because careful diagnosis is required, for each case reported, we're not adding a Rollup Discussion in the forum. Instead, we request that each blog owner, observing this problem, post her / his problem report in a topic started for that purpose, by himself / herself only. This will allow us to inventory this problem properly, and assist Blogger Engineering in isolating and fixing this problem promptly, so the blog owners can get on with the after publishing process.

Reports of this problem appear to have started in volume late Saturday, 11/17, Pacific time - though some reports, examined in detail, mention the problem initially observed several days ago. The initial volume of the problem appeared to come from SouthEast Asia - but as additional reports were posted, we see Europe and the Americas apparently represented.

Blogger Engineering is now aware of the problem, and will investigate. We'll continue to monitor the forum topics, and to post an initial advisory FAQ, as a response to the reports observed - when reports contain clear evidence of the "Error 14" being a primary symptom. Please monitor that FAQ, and this post, for any ongoing updates.

>> Top
Posted by at No comments:
Labels: , , , , , ,

Thursday, 15 November 2012

The Free Domain Registration Service "co.cc" Appears To Be Down

Some Blogger blog owners, trying to save a few dollars while publishing their blogs to a non BlogSpot URL, have used the free service "co.cc" for registering their domains.

As "co.cc" increased its base of "customers", their reputation for providing free registration grew - and they became popular with scammers and spammers.

Last year, Google, weary of the overall poor search engine reputation of co.cc customers, de indexed all websites registered by co.cc. This week, co.cc apparently stopped serving DNS information for its "customer domains".

Strictly speaking, "co.cc" was not a registrar - and the blogs and websites published by its customers were not using registered domains.

The "Top Level domain co.cc" - which by its name implied an Internet service operating from the Cocos (Keeling) Islands - was in fact the domain "co", operating out of Korea, and registered in the Cocos (Keeling) Islands. All "domains" given out by "co.cc" were in fact sub domains to the domain co.cc - and this is where the problem started.

All blogs and websites, published to a "co.cc" subdomain, were aggregated by the search engines as the "co.cc" domain. As the number of co.cc registered scammy and spammy websites increased, their search engine reputation dropped. Non spammy blogs and websites either went out of business, or were transferred to legally registered domains, because of the low reputation and lower search engine originated traffic.

Finally, the owners of co.cc - supposedly "JONG SUNG, KIM" of "GOYANG,GYEOUNGGI" - realised that their run was over, and that they could no longer hide their scams and spams behind legitimate blogs and websites. Apparently, they have now shut their doors.

The old adage comes to mind.
You don't get something for nothing.


If you registered your custom domain using co.cc - and your blog is now offline - you're going to have to publish the blog back to BlogSpot, to get it online again. If you want to use a domain URL, you have to repeat the custom domain setup process - starting with a new, properly paid for, domain URL.

>> Top
Posted by at No comments:
Labels: , , , , , , , ,

Saturday, 3 November 2012

Use Third Party DNS Servers, For Domains Registered By 1And1, And Similar Registrars

Not all registrars are able to support the new Blogger domain ownership verification requirement.

Some registrars won't allow a second "CNAME" in the same subdomain - and others can't handle the excessively long target address. Ever since Blogger added domain ownership verification, we've been seeing complaints from some blog owners, who have purchased domains directly from registrars who can't provide the required DNS addresses on their servers.

Even though not all registrars have DNS servers that will provide the right DNS address entries, most registrars will allow us to use third party DNS servers. The use of publicly available DNS servers, which can provide the required DNS addresses, will eliminate the need to transfer domain registration - when the registrar is unable to provide the right DNS addresses, using their own servers.

If you're trying to setup your domain, purchased from 1And1 or a similar registrar, you need only to setup a suitable third party DNS server.

Use of a third party DNS host will also help victims of the eNom DNS Infrastructure problem - and those who purchased Name Registration, directly from the registrar.

Marc Ridey, of Blogger Engineering, provides How to setup your Blogger blog with a custom domain from 1and1.com, and adds three simple steps to the normal third party registrar domain setup process.
  1. Setup a (free) ClouDNS account.
  2. Setup your normal DNS addresses (including the required domain ownership verification "CNAME") in ClouDNS, using the ClouDNS Domain Manager wizard.
  3. Setup your domain, using your registrar's domain manager wizard, pointing to the ClouDNS DNS servers.

When you update DNS addresses, such as adding additional hosts, and ownership verification, you use the ClouDNS Domain Manager wizard.

If you are using your third party registrar because you have non Blogger services (a web site, email, files, or other service) hosted by the registrar, please note the warning by Marc!
Warning: If you are using 1and1 hosting services to display a website as well as a Blogger blog, these instructions will disable the website. Please post a comment with your website address and I'll check how these instructions must be updated. If you're using eMail, remember to complete the optional eMail step.

Note that ClouDNS, when setup, may offer the option to redirect the domain root (aka "naked domain") to the "www" alias (or whatever DNS address you may setup). For best results, ignore that option, and use the Blogger or Google Apps redirect. There are still only three acceptable DNS models - use of ClouDNS, or any similar third party DNS host, will not change that.

This may not be an ideal solution for the problem - it introduces a bit of complexity into the domain setup process - but it will allow owners of newly purchased domains from 1And1, Network Solutions, and others to get their domains verified, and get their blogs online again. And, since this starts with blog owners who elected to purchase their domain directly from a registrar - and setup the domain themselves - maybe it's not too much, technically.

>> Top
Posted by at No comments:
Labels: , , , , , , , , , ,
Subscribe to: Posts (Atom)