What is Time to Live (TTL)?

TTL Meaning

Time to Live (TTL) is the amount of time that a record is cached in a resolver when the record is queried. It is measured in seconds and is set within each record in your DNS configuration. In other words, TTL is a setting in the IP packets that tells the DNS resolver the amount of time the cache should exist before requesting a new one. 

Example: If the TTL for a record is set to 86,400 seconds (24 hours), the server will regather the information to display updated details for that particular record in 24 hours.

What is TTL in DNS - Best Settings

One of the most common questions that we get asked is, “What are the best settings for time to live?” Since the answer isn’t always straightforward for all scenarios. We've compiled some best practices to help you determine which setting is most appropriate for your domain. 

‍

Recommended High TTL Values

High TTL values are typically used for records that rarely change, such as MX or TXT records. Longer TTLs reduce resolution times since every time an authoritative nameserver provides an answer to a query, it results in an additional lookup. A high TTL provides faster responses for more static resources by storing the information locally before having to retrieve it again.

TTL Example 

If you have the A record www.example.com pointing to the IP address 2.2.2.2 and a TTL set at 86,400 (24 hours), when Client A queries www.example.com, the IP 2.2.2.2 will be stored in their cache for a full day. Client A will not make another query for www.example.com as their resolver already knows which IP to go to and for how long. If the IP for that A record is changed to 3.3.3.3, Client A will still be going to 2.2.2.2 for the next 23 hours after their initial visit until the TTL counts down to 0. At this point, the record expires and a new query can be made against that FQDN. Then, Client A will be directed to 3.3.3.3. upon their next query.

Note: If you need to make changes when using high TTL values, you will need to lower the TTL and wait until the cache expires before any changes can be made. This will eliminate the need for waiting for record expiration.

Recommended Low TTL Values

Resources that need frequent updates require a low TTL value. A lower cache time is also essential for website and network changes. DNS management services, such as Failover and Load Balancing, require a low TTL to be able to direct end users to the updated IP. In the event of unexpected traffic spikes, the queries cannot be sent to the updated IP until the cache expires, leaving DNS management services ineffective during mission-critical times. A shorter TTL is the remedy for these types of situations.

Note: Low TTLs are recommended for critical records. A good range would be anywhere from 30 seconds to 300 seconds (5 minutes).

If a TTL is set to 30 seconds to accommodate frequent changes to the DNS, the end-user experience is minimally impacted and affords you the most flexibility. While this may sound ideal, if a user is visiting your site frequently in one day, they are querying the www.example.com record every 30 seconds or so, and when you multiply that by however many users, your query count goes up, which can result in higher costs. 

TTL Logic

The rule of thumb for setting up TTL values for non-critical records that might require changes in the near future is to consider a shorter TTL. However, you also don’t want to pay for the higher number of queries that lower TTLs come with, so a TTL as short as 30 seconds, or even half an hour, is not the best resolution. In this case, you would want to use a longer TTL of 1 to 12 hours.

You can adjust your TTL to fit your end-users’ accessibility needs.  

Most Common TTL Use Cases

The following use cases include answers from our Support team to assist you with the best TTL values for your domain.

Scenario: I’m using Failover and need the lowest downtime possible. What TTL should I set?

Answer: If your FQDN's availability is absolutely imperative, Failover is a must but it requires a low TTL to work the way you want it to. Failover cannot bypass TTLs in any way. If you have a TTL of 1800 (seconds) for your failover record and it fails over to the second IP, users will not be directed to the updated IP for up to 30 minutes (until the cache in the resolver expires). With this in mind, you are going to want to set a low TTL and the lower the better. Having said that, many resolvers won't recognize TTLs lower than 30 seconds but you can always make a test record to find out if your resolver allows for TTLs below 30 seconds. 

Scenario: This record does not need Failover but we do make some changes to it.

Answer: If the record in question is not mission-critical but gets updated from time to time, a higher TTL is the way to go. The most common follow-up question is "what about when I need to make a change?" and the answer is to plan for the update. Suppose you have the TTL set for 7200 (2 hrs), once you know you want to make the update, lower the TTL to however long you are comfortable having downtime (30 seconds is the lowest we recommend) and then wait out the TTL—in this case, you would wait two hours. Once two hours have passed, you can change the record and revert back to the initial TTL value.

Understanding Time to Live for DNS Strategy Refinement

The beauty of time to live is being able to completely customize the values to best suit your domain’s needs. Understanding TTL and how to use it effectively will ensure that you are maximizing your DNS strategy.