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

No Immediate Solution For 1And1 Customers With Unverifiable Custom Domains

Since Blogger restored Custom Domain Publishing last month, with the new domain ownership verification requirement, there have been a few complaints from customers of some registrars who just can't provide the required DNS address record for ownership verification.

My registrar says that I can't have two "CNAME" records in the same subdomain.

and

My registrar's domain manager wizard displays an error saying "Address too long.", when I try to add the "CNAME".

Blog owners contacting the registrar, and asking for help, are generally told

That's Blogger's problem!

---

(Update 2012/11): Blogger Engineering has provided a workaround for this problem, with any uncooperative registrar, such as 1And1 - use of a (free) third party DNS host.

---

What not all blog owners realise is that the new "CNAME" must be just that - there is no substitute here.

Some of the more patient blog owners have made various suggestions, to get us moving towards a solution.

1. Blogger Support needs to work with the problem registrars, and convince them to improve their service.
2. Blogger Support needs to provide an alternate ownership verification procedure - maybe equivalent to the Google Webmaster Tools meta tag verification procedure.
3. Blogger Support needs to clean up their "CNAME" setup instructions, and remove mention of the problem registrars - so future blog owners won't choose these registrars to host their domains.

About 3/4 of the problem reports have come from customers of 1And1. Using that registrar as a starting point, I contacted Blogger Support and suggested the 3 alternatives, outlined above. The Blogger Engineer responding seemed to think that only suggestion #3 - cleanup of the per registrar "CNAME" addition instructions was immediately possible.

It's possible, then, that we will eventually see less problem reports from 1And1 customers - and hopefully others - as Blogger Engineering cleans up their domain setup instructions. The current customers of uncooperative registrars, unfortunately, are unlikely to see relief, for the near future.

This is an unfortunate situation for these 1And1 customers. The best solution for them is to move domain registration to another, more helpful, registrar. Unfortunately, most registrars don't allow domain registration transfers immediately after initial purchase - waiting periods of 30, or even 60 - days are normal. And domain registration fees are not refunded.

This leaves new 1And1 customers, and similar victims, with several options - none of them good. First, publish the blog back to BlogSpot, so the blog can be accessed by existing readers.

• Wait 30 - 60 days, with the domain dead, then transfer domain registration to a more helpful registrar and activate.
• Purchase a second domain, from a more helpful registrar.
• Forget about custom domain publishing.

The latter alternative has motivated several victims to choose a fourth alternative.

• Move their blog hosting to a different service.

None of this can be good for Blogger's reputation.

>> Top

Ownership Verification Is Not A Standard Process

With the recently restored custom domain publishing feature, and the new domain ownership verification requirement, comes various queries from blog owners unable to verify domain ownership, and to publish their blog to their custom domain.

Can I use a "TXT" file, instead of a "CNAME"? My registrar suggests this as an alternative.

and

Why do I need this? My domain was working, just fine, before I had to re publish the blog!

Not all blog owners understand the historical need for verifying domain ownership.

Ownership verification, allowing one to setup a given relationship between various Internet resources, varies according to the need of the application which uses the Internet resources in question. Domain ownership verification, to provide urgently needed custom domain security, is simply one example of ownership verification, in general.

• If you have file / folder control of a web site, you may be able to add a specific named file, to the website. The application in question can check for the presence of the required file (possibly one with a complex name).
• Some applications such as Webmaster Tools can, alternatively, use a meta tag in the blog header, to verify blog ownership. Again, the tag will have a complex name / value.
• To verify domain ownership, Blogger requires you to install a unique "CNAME" as a DNS address into your domain. The "CNAME" will contain two complex values, provided only to the blog / domain owner.

In either case, the complex values provide an encrypted certificate, which is specific to the application and to the blog / website, which is provided only to the owner of the blog / domain / website.

The named file is a simple solution - both to setup and to verify - but using it requires that the blog / website owner have the ability to setup a specific named file, in a specific folder, containing the certificate. Blogger does not provide file / folder control, so that solution is out - for any application which is to be used with Blogger blogs.

Applications (such as Webmaster Tools) which work with Blogger blogs, and similar websites, can use meta tag verification. This requires that the blog owner add a meta tag in the blog header, with a complex tag name / value. The tag name / value contains the certificate in question.

Blogger blogs can use neither a named file, nor meta tags, for domain ownership verification. There is no domain header, where meta tags could be installed - and again, Blogger does not provide file / folder control.

To verify domain ownership, Blogger requires the domain ownership certificate to be installed as a unique "CNAME" DNS address. The complex values in the "Name" and "Destination" values of the "CNAME" contain the encrypted ownership certificate. Since the specific certificate values, for each different domain, are provided to the blog owner (in the "settings instructions" document) - and the "CNAME" can only be installed by the domain owner - when the proper "CNAME" exists, the blog owner and domain owner are certified to be one person.

The unfortunate problem with "CNAME" based domain ownership verification is that not all registrars can provide the required "CNAME"s, and can provide "CNAME"s with long "Name" or "Destination" values. This does not mean that the Blogger solution, for domain ownership verification, is faulty.

It's possible that Blogger Engineering has considered a second option for domain ownership verification, which will be added when - or after - the "Buy a domain" wizard is updated to support automatic domain ownership verification. It's also possible that blog owners, who use specific registrars which are unable to provide the required "CNAME", will be forced to abandon their current registrar.

Whatever the case, it's likely that the "CNAME" based domain ownership certificate was the best possible solution, to solve the urgent security problem, and allow custom domain publishing to be restored last week.

>> Top

eNom: Fix Your DNS Servers!

For over 2 months, we've been seeing reports from blog owners who published their blogs to custom domains, with domain DNS hosted by eNom, in Blogger Help Forum: Something Is Broken.

I bought my domain name through Blogger,last week. It is being hosted by eNom. Ever since I bought it some of my followers, and sometimes myself, can't access my site. There is either a DNS search or a "Ooops, Google Chrome can't find..."

I tried contacting eNom, and they said they can see my site and that all of my settings are correct. They say it must be Google's problem.

The keyword here is "sometimes".

Ever since I bought it some of my followers, and sometimes myself, can't access my site.

A simple Dig, for the domain in question, will frequently show normal results. The usual DNS configuration, for a domain purchased using "Buy a domain", will be asymmetrical aka "Google Apps".

enomhosteddomain.com. 1800 IN A 216.239.32.21
enomhosteddomain.com. 1800 IN A 216.239.34.21
enomhosteddomain.com. 1800 IN A 216.239.36.21
enomhosteddomain.com. 1800 IN A 216.239.38.21
www.enomhosteddomain.com. 1800 IN CNAME ghs.google.com.

The problem, which not so many people appreciate, is that eNom uses multiple DNS servers, possibly geographically separated. This is normal DNS hosting technique, and guarantees redundancy if one data center goes offline.

However, for redundancy to work, all DNS servers have to be kept consistently synchronised. If we examine the 5 eNom DNS servers individually, we will frequently see discrepancies.

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

enomhosteddomain.com. 1800 IN A 216.239.32.21
enomhosteddomain.com. 1800 IN A 216.239.34.21
enomhosteddomain.com. 1800 IN A 216.239.36.21
enomhosteddomain.com. 1800 IN A 216.239.38.21
enomhosteddomain.com. 3600 IN NS dns1.name-services.com.
enomhosteddomain.com. 3600 IN NS dns2.name-services.com.
enomhosteddomain.com. 3600 IN NS dns3.name-services.com.
enomhosteddomain.com. 3600 IN NS dns4.name-services.com.
enomhosteddomain.com. 3600 IN NS dns5.name-services.com.

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

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

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

com.   3601 IN SOA dns1.name-services.com. info.name-services.com. 2010 10001 1801 604801 181

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

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

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

enomhosteddomain.com. 1800 IN A 216.239.32.21
enomhosteddomain.com. 1800 IN A 216.239.34.21
enomhosteddomain.com. 1800 IN A 216.239.36.21
enomhosteddomain.com. 1800 IN A 216.239.38.21
enomhosteddomain.com. 3600 IN NS dns1.name-services.com.
enomhosteddomain.com. 3600 IN NS dns2.name-services.com.
enomhosteddomain.com. 3600 IN NS dns3.name-services.com.
enomhosteddomain.com. 3600 IN NS dns4.name-services.com.
enomhosteddomain.com. 3600 IN NS dns5.name-services.com.


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

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

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

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

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

com.   3601 IN SOA dns1.name-services.com. info.name-services.com. 2010 10001 1801 604801 181

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

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

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

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

This is one of the more subtle discrepancies, which I have observed, in the past couple months - only DNS Server #3 is out of synch, in this case. But that's enough, to make the domain unreliable.

The problem is intermittent. All of a sudden my site loads, but 10 minutes ago it didn't.

That's one eNom customer, out of over a dozen, which I have documented. And that's one eNom customer, who should be complaining, to someone above eNom Customer Service.

eNom: fix your servers!

---

(Update 2012/07/03): Suspicion that the problem is related to Anycast DNS led me to a bud, who is a fellow TC, and a network expert in India, and who provided an intriguing blog post, neatly diagnosing the underlying problem. It appears that eNom server monitoring policies may be a bit superficial.

---

---

Use these links, for convenient reference:

• Discrepancy suspected.
• Discrepancy confirmed.

---

>> Top