Everything You Ever Wanted To Know About TTLs

One of the more common questions I get while assisting our new and current customers is about TTLs (Time to Live). Some of you right now are probably wondering the heck a TTL is, why it’s important and why it is one of the least understood parts of DNS. Even if you know what a TTL is, perhaps you would like some best practices.

In either case, here’s your handy guide on everything about TTLs!

So What Is A TTL?

TTL (Time to Live) is a setting for each DNS record that specifies how long a resolver is supposed to cache (or remember) the DNS query before the query expires and a new one needs to be done.

The benefits of caching are pretty obvious: it’s a lot faster to check your local resolver’s cache then having to look up a DNS record that isn’t already cached. This speeds up your Internet experience when visiting a site you go to often (since less time is needed to complete DNS lookups) and also helps lower the load on DNS servers around the world.

What happens when the DNS record changes? This is where the potential downside of caching becomes evident. If a DNS record is cached, then a new lookup is not done until that cache expires. Thus that resolver that has the cached record won’t have any way to find out about the changed record until its cache expires.

When you hear someone mentioning they are waiting for DNS to propagate, they are waiting for cached DNS records to expire at all of the different resolvers that previously looked it up. If you have a 1-day TTL on a record, that means it would take a full day for any change to propagate around the world.

Why should you care about what your TTL is set to?

You want to strike the best balance between having a low TTL (enabling fast changes when needed) and high TTLs (taking advantage of DNS caching). Most DNS providers also bill you based on how many DNS queries you are doing, so that is an additional incentive to strike a good balance on your TTLs. You also don’t want to have to modify the TTL in the future since TTL changes also need propagate out just like any other DNS change. Thus changing a TTL from 1 week to 1 day means it could take a full week before everyone knows it has a 1 day TTL.

For very critical records that can change often or need to change in an emergency, you can set TTLs as low as 30 seconds on DynECT Managed DNS or on Dyn Standard DNS. A good rule of thumb is never have any TTL higher than 1 day as the benefits of DNS caching really diminish after that point and it makes propagation waits extremely long.

Common Record Types

A or AAAA Record – Usually a 1 hour TTL is a good compromise between enabling fast changes while taking advantage of DNS caching while someone is visiting your site. If changes to this record are often or need to happen quickly in an emergency, you can usually set it as low as 30 seconds. For DynECT Managed DNS features such as Active Failover, Load Balancing and GSLB, you can set the TTLs between 30 seconds and 5 minutes. For non-critical records that rarely – if ever – will need to change, you may be able to get away with having a TTL in the 12 hours to 1 day range.

CNAME record – In many cases, a CNAME record will never be modified (ex. pointing www.example.com to example.com’s A record). In those scenarios, a 12 hour to 1 day TTL is a good compromise as the benefits of caching outweigh need for a faster propagation time. If your CNAME record could potentially change (such as if you are using a CDN), you will want to a have a lower TTL.

MX Record – MX records rarely, if ever, change, especially if you are using an email provider with a good track record or you have lots of redundancy when self hosting. You can usually set this to a 12 hour or 1 day TTL. If you want to ensure faster propagation times in the event of an emergency, a 1 to 4 hour TTL is a good compromise.

TXT Records – Most commonly used for SPF or DKIM records. Usually safe to set in the 1 hour to 12 hour range since they rarely change.

In the end, keep in mind that what you set the TTL to is what you are most comfortable with. It is all about striking a reasonable balance between a fast propagation time and taking advantage of DNS caching. Your friendly Dyn Concierge will be glad to assist you if you have any further questions.