The DNS TTL Setting Is Chosen By The Registrar

Some blog owners, publishing their blog to a custom domain, wonder about the mysterious TTL setting for the domain.
What is "3600"? Why do I see "7200" in my Dig log?
Why do I have to wait 8 hours, after changing my DNS addresses?
DNS latency (aka "TTL") is not understood, by many blog owners. A mistake in setting TTL can cause anger and frustration.

"Time To Live" aka "TTL" is a registrar individual setting, that is used for providing proper performance from the registrars name servers and network.

There are multiple TTL settings - and each can have a different effect on your domain.

TTL controls caching of the DNS addresses, used to access your domain.

TTL indicates how long a DNS address will remain in cache, on a computer, before that computer requests an updated value. It's an essential (but obscure) component, in setting up a custom domain.

Since you're reading this blog, your computer has the address of this blog in cache - and won't be requesting an update, until "TTL" for "" expires. GoDaddy, the registrar for "", uses "3600" seconds, or 1 hour TTL.

Your computer probably uses the nameservers provided by your ISP - and your ISPs nameservers get updates from the nameservers provided by GoDaddy. Changes to "" go from Google, to GoDaddy, to your ISP, to your computer - and TTL applies to each DNS cache.

A typical Dig log, for a domain with a low TTL value.

Look at a Dig log extract, for "". 3600 IN A 3600 IN A 3600 IN A 3600 IN A 3600 IN CNAME

You set the TTL, for each individual DNS address, when you setup your domain. The registrar provides a recommended TTL - but most registrars let you select a different setting, within a given range.

A lower TTL ("600" seconds or 10 minutes) provides faster refresh after a change is made - but puts more load on the registrars name servers, and requires a more responsive network.

A higher TTL ("7200" or 2 hours) provides slower refresh - and puts less load on the registrars name servers. And when a change is made, by Google, a higher TTL can cause problems.

If you don't understand DNS, you will be better off not changing from the registrar recommended setting. Some registrars won't even have a TTL setting, in their zone editor - and others may hide it, behind an "Advanced" menu or similar.

If you generate a Dig log for your domain, you'll see the TTL settings for your addresses.

A typical Dig log, for a domain with a high TTL value.

Look at a Dig log, for "".

Here, the current DNS addresses (correction pending).

Here, we see a TTL of "14400" (displayed as "14399") - or 4 hours. 14399 IN A 14399 IN CNAME

For best results, we suggest that you wait 2 x TTL, after making DNS changes.

I recommend waiting 2 x "TTL", after making any DNS changes, before acting from those changes. Having diagnosed the painful "Another blog ..." domain database corruption, too many times, I suggest this whenever possible.

After you correct the addresses, please wait 8 full hours (2 x "14400" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.

In many cases, TTL will be "3600" or "1 hour" - and with a typical forum diagnostic session taking several hours between posts, a one or two hour TTL is transparent to the forum discussion.

With domains using 4 hour TTL, suggesting that the blog owner wait 8 full hours after making the change, before re publishing the blog to the domain, makes sense. And a 2 full days, for "86400" seconds, makes even more sense.

And getting a righteous DNS address complement verified - before re publishing - makes the most sense.

DNS TTL latency, which affects accessibility of every #Blogger custom domain published blog, is not understood by many blog owners. To provide a stable domain - and a more visible blog after it's published to a custom domain - every blog owner should understand this obscure detail.