What Is This New "CNAME", Anyway?

Ever since Blogger finally restored the custom domain publishing feature, blog owners have been asking about the addition to the domain setup process - the new "CNAME".

Do I really need this? My old blogs don't have it, and they are fine.

and

My registrar won't let me add a second "CNAME" - they allow one "CNAME" / domain (my "www").

and

My registrar won't allow long addresses, such as what you have for "Destination" / "Target" / "Points To".

And we are learning that this requirement is going to be a problem for blog owners using some registrars, who can't provide this "CNAME" in their customers domains.

In technical terms, the new "CNAME" is an ownership certificate, provided in a one way encryption.

If you have WiFi in your home (likely) - and are using encryption (hopefully), you have a similar one way encrypted certificate - the WPA / WPA2 key / passphrase. For an allegorical (easy to read) discussion about certificate encryption, see Designing an Authentication System.

Only the blog / domain owner know the values and can install the certificate.

Only you, the blog owner (and anybody who you trust, on your behalf), are able to install the certificate for your domain, into your domain DNS addresses. Only you have access to both

• The Blogger dashboard Publishing wizard.
• The zone editor wizard provided by the registrar.

This helps Blogger help you keep your domain under your control - as long as you pay the yearly registration fee for your domain.

The certificate contains 3 unique values.

The domain ownership certificate has 3 keys.

1. A private key, which Blogger appears to change regularly (some say daily) - and one which they control.
2. The BlogSpot URL.
3. The domain URL (entered in "Advanced settings").

It has two significant values.

1. "Name" / "Label" / "Host". This is now known as the "short token".
2. "Destination" / "Target" / "Points To". This is now known as the "long token".

Note the three labels used to identify each "value" - which reflect the diversity of the registrars which may provide DNS hosting for our domains (when they are able to fulfill our specific needs). When you look at the Domain Manager wizard for your domain, you may see any of the three (possibly, others) used - as there is no authoritative label for these two DNS address components.

Compare the two "CNAME"s, in structure and value.

Let's look at the two "CNAME"s, together, so you can compare the similar structure. Note the need to get the syntax, which can vary by registrar, absolutely correct.

This is the first "CNAME" - the "www" alias DNS address. This "CNAME" is identical for all Blogger blogs, using the asymmetrical DNS address convention.

1. "Name" / "Label" / "Host". www
2. "Destination" / "Target" / "Points To". ghs.google.com

This is the second "CNAME" - the domain ownership certificate. This "CNAME" will vary, for each different domain. Here we see the original example (which has since changed).

1. The "short token". vptre6sub6jm
2. The "long token". gv-g47p6dir6kfenz.dv.googlehosted.com

See the final period, at the end of the "Destination" / "Target" / "Points To" address, below? It's not in the example, above. Be very careful here, some registrar's will automatically insert the "." for you - and if you insert it also, you'll have a problem. Other registrars will need you to add it - and if omitted, you'll have a problem. Regardless, its presence, in the final product, is essential.

gv-g47p6dir6kfenz.dv.googlehosted.com.

You can verify specific certificate values.

If you know the value for the short token, you can Dig and extract the long token - when the second "CNAME" is properly setup.

Once you provide the above examples to the Domain Manager, the following two DNS addresses are generated and added to the domain server. The "3600" represents the TTL, a setting provided by the registrar. The "IN" is part of the Dig log extract syntax.

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

and

vptre6sub6jm.mydomain.com. 3600 IN CNAME gv-g47p6dir6kfenz.dv.googlehosted.com.

Both "CNAME"s point to specific Google servers. The second "CNAME" is only slightly obscure. Both "CNAME"s are essential (when required - but only when required).

1. The first lets you, and your readers, view your blog.
2. The second lets Google verify that you own the domain, and you should be allowed to publish your blog to the domain URL.

Nobody but you, the blog owner, will ever know the values of the tokens. Nobody but you, the domain owner, can install that "CNAME" into the domain DNS addresses. If DNS resolution of the short token address points back to the right Google server, then you, the owner of the blog, and the owner of the domain are verified as the same person. And the ownership certificate is "decrypted", using DNS name resolution.

• Short token. vptre6sub6jm
• Long token. gv-g47p6dir6kfenz.dv.googlehosted.com

Some certificate values are temporary.

Since the private Blogger key changes regularly, if anybody learns what tokens you used, in the short 3 step domain verification process, the values will have likely changed, and their time will have been wasted. Your blog and domain remain your blog and domain.

So, do the necessary. Blogger provides instructions, specific for 7 known registrars - and a general purpose instruction for others, in Google Help: Create a CNAME record for my custom domain. If their instructions conflict too much with your reality, try setting up third party DNS hosting.

1. Get the short token and long token values, for your unique blog / domain.
2. Add the new "CNAME" to your domain.
3. Publish the blog to the domain URL.

That's it (subject to observed timing issues). You are now done with the domain ownership verification process, and with these encrypted values. Start planning the migration - this will happen faster than you think. And it is your responsibility, to get this done.