DNS records store pertinent information about a domain, such as IP addresses, hostnames, and ownership details, but there is one value in a record that dictates how long certain information is valid: Time to Live (TTL). This resource provides a breakdown of what TTL is all about.
Time to Live (TTL) is like an expiration date for DNS records. A TTL value is measured in seconds and is what resolvers use to determine how long to cache a DNS record before discarding or refreshing it. This setting plays a significant role in DNS as it can affect query volume and propagation speed.
Recommended TTL Values
The ideal value for TTL depends on record type and how often changes are expected to be made to the record. The higher the TTL, the longer a record will be stored in cache. This helps speed up the query resolution time, but can be problematic for domains that require frequent DNS changes.
For records that seldom change, higher TTL values are typically best practice. For instance, TTL settings between 3,600 and 86,400 seconds are commonly used for MX and TXT records. On the flip side, domains with mission-critical services, have records that are updated frequently, or that use DNS load balancing configurations like failover would need lower TTL values, generally between 30 and 300 seconds.
Tip: The shortest (safest) TTL value allowed for DNS records is 30 seconds. While it’s technically possible to set values lower than that, many resolvers won’t recognize shorter durations. If you want a TTL for a record less than 30 seconds, be sure to do a test record first.
When trying to determine the Time to Live for your records, keep in mind that whatever value you set is how long it will take before the record reflects any updates across all servers on the web. For example, if you have an A record set to 86,400 (24 hours) and you change the IP or update your configuration of this record, it will be a full day before everyone is served the new content.
Did you know?: Some internet service providers (ISPs) only update their records every few days and ignore TTL values. Most people will be returned the refreshed content, but there might be some users who are still served content based on the old record.
Now that I’ve covered what TTL is and what it does, now let’s take a look at an example of what it looks like in a record.
A (host) Points to (IPv4 address) TTL
@ (root) 192.0.2.255 30
A (host) Record Type Priority Value TTL
@ MX 10 email@example.com 86400
In the above scenario, resolvers would discard the record after 30 seconds and request new information when another query is received. The MX record, on the other hand, would only reflect changes after a full 24 hours have passed.
Tip: If you need to make a change for a record that typically uses high TTL values, you can lower the TTL first, wait for the cache to expire, and then make your changes.
While you can’t predict the future, it’s always best to consider what conditions may warrant a change to your DNS records. An easy way to do this is by lowering TTL values. That said, you don’t want every record to be set too low, as this can cause an increase in queries, and subsequently, result in higher costs for your organization. A good balance would be to set any non-critical or seldom changing records to fall between 1 and 12 hours and use lower values for load-balancing configurations or mission-critical records that require frequent changes.
Understanding Time to Live
Time to Live is a crucial part of DNS. It determines the length of time records should be stored in cache and affords businesses the flexibility to plan DNS updates strategically and seamlessly. Understanding which records require higher or lower values and how resolvers store records in cache will help ensure your end users receive the most up-to-date content and have an optimal experience when interacting with your domain.