������

A TTL (or Time to Live) is a crucial setting in every DNS record… and yet, it is rarely talked about.

If you are guilty of using the default TTL for your records, you need to read this.

How do TTL’s work?
[ If you already know, just skip ahead! ]

The TTL tells resolving name servers how long DNS information should be cached (like cash). Resolving name servers are like the middlemen of the DNS exchange. When you enter a domain into your browser, you are actually asking your local resolving name server for the IP address of that domain.

If someone has recently made the same request, the information will likely be stored in the resolving name server’s cache. If it isn’t, then the resolving name server will ask the name server authoritative for that domain –usually the DNS provider.

Once the record pointing the domain to the corresponding IP address has been found, that information is stored on the resolving name server. This speeds up the resolution time for the next time the domain is queried at that resolver.

Why do TTL’s matter?

For basic A and CNAME records, you likely won’t run into scenarios where TTL times cause issues. However, once you start dynamically changing endpoints like Failover, TTL’s become very important.

For example, let’s say the primary IP address for the domain we are looking for is unavailable. This domain also has Failover enabled, which would point users to a backup IP address when the primary is down.

This could be handled two ways. If the record has a high TTL, users will still be pointed to the primary IP address until the resolver’s cache expires. If the record has a low TTL, they have a higher chance of being pointed to the correct endpoint sooner.

When to keep TTL’s short

#1

If you have any sort of rule applied to a record that dynamically updates the endpoint, like Failover or Load Balancing, you would want a short TTL.

Every time you go to modify a TTL ask yourself,

“How long am I comfortable with users going to an unavailable endpoint before the cache refreshes?”

Kind of scary to think about.

#2

For any critical records, you should always keep the TTL low. A good range would be anywhere from 30 seconds to 5 minutes.

#3

If you are making any record changes, you want to make the TTL as low as possible. Any changes you do make will not propagate until the TTL expires.

One thing to keep in mind, the lowest TTL in DNS Made Easy is 30 seconds. That’s because resolving name servers will usually only pay attention to TTL’s that are 30 seconds or highers.

#4

You also want a low TTL if you have any advanced settings like GeoDNS rules applied. This applies more to our new product, , which allows you to create rules that change what endpoints are returned based on a user’s location.

#5

Here is where we hit a gray area. If you have any non-critical records but know you may want to make changes to them in the near future, you may want to have a short TTL. You also don’t want to pay for the higher number of queries that lower TTL’s come with, so wouldn’t want it to be as short as 30 seconds or even half an hour.In this case, you would want to use a longer TTL of 1 to 12 hours.

When to use a long TTL

Cost is becoming a big factor with TTL’s. Think about it, the shorter the TTL then the more often the authoritative name servers will have to answer queries, and your monthly bill goes up.

Longer TTL’s also cut resolution times. Every time a query has to ask an authoritative name server, it adds an additional lookup, which could add precious milliseconds.

#1

Here are the top records that should have longer TTL’s:

• MX record (points to your mail server)
• DKIM and SPF (usually configured with MX records)
• TXT record

#2

Records that point to your web server or CDN, A and CNAME records respectively, will typically have a longer TTL since they are rarely changed. For these, you would want to set a TTL of 12 hours to 1 day.

Keep in mind, you will need to lower the TTL and wait until caches expire (usually around a day) before making any changes.

Did we miss anything? Lets us know .