In an ideal world, the DNS would be like one of those As-Seen-On-TV rotisserie ovens - set it and forget it. However, the Internet is a dynamically changing place and what may be relevant in one moment may not be the next.
To cope with this, the DNS was designed with a mechanism to refresh records and ensure that users were always given the most pertinent answer when they requested it.
What is TTL in DNS - Learning The Basics
Time To Live, or TTL for short, is the sort of expiration date that is put on a DNS record. The TTL serves to tell the recursive server or local resolver how long it should keep said record in its cache. The longer the TTL, the longer the resolver holds that information in its cache. The shorter the TTL, the shorter amount of time the resolver holds that information in its cache.
For example, we’ve got example.com. Example.com has an A-record at the apex of the zone to point us to a server. With a TTL of 3600 seconds, or 1 hour, that means that as a recursive server learns about example.com, it will store that information about the A-record at example.com for one hour. Anyone else who uses that same resolver will get the same answer, and on the authoritative side, there will be no query to the server unless the TTL runs out.
DNS TTL Best Practices
TTLs are nothing to take lightly - they can directly affect the amount of query volume that is attributable to your authoritative service, and in the event of needing to quickly change the record, can result in longer than expected change propagation to all users.
For records that leverage a sort of advanced traffic management scenario, such as NS1’s Filter Chain, it’s best to keep the TTL as short as possible. This way, when a change is enacted by the system, users on the other end requesting the name are given the most recent information. It’s worth noting that most recursive servers do not actually understand a TTL shorter than 30 seconds - while we won’t stop you from going lower than that, the results may not be favorable in the long run.
For records that rarely change, such as TXT or MX records, it’s best to keep those somewhere between an hour (3600s) and a day (86400s). When it does come time to enact changes with regard to these types of records, it may behoove you to change the TTL down to a shorter interval before enacting any changes to ensure that the changes are propagated quickly.
The SOA TTLs
At the top of every DNS zone, in the Start of Authority (SOA), there are five TTL values that serve a higher purpose in the DNS.
SOA TTL - The interval at which the SOA record itself is refreshed.
Refresh TTL - The interval at which secondary servers (secondary DNS) are set to refresh the primary zone file from the primary server.
Retry TTL - The rate at which a secondary server will retry to refresh the primary zone file if the initial refresh failed.
Expiry TTL - If Refresh and Retry fail repeatedly, this is the time period after which the primary should be considered gone and no longer authoritative for the given zone.
NX TTL - In the event that requesting the domain results in a non-existent query (NXDOMAIN), this is the amount of time that is respected by the recursor to return the NXDOMAIN response.
It is recommended to not modify these TTLs unless you have a very specific need to do so, which is often a very rare case.
Continue learning more about time-to-live (TTL), by reading these articles:
- What is the Lowest TTL I Can Getaway With?
- Best Practices TTL Configuration
- Global Load Balancing, Caching and TTLs