Best practices: TTL configuration

Time-to-live (or TTL) is is a mechanism that limits the lifespan or lifetime of data in a computer or network—ensuring data is periodically refreshed to represent the latest information. In other words, it is a sort of "expiration date" defined within a DNS record. The TTL serves to tell the recursive server or local resolver how long it should keep the record in its cache. The longer the TTL, the longer the resolver holds that information in its cache. 

For example, let's say example.com has an A record at the apex of the zone that points us to a server. If there is a specified TTL of 3600 seconds (1 hour), a recursive server will store information about the A-record at example.com for one hour. Anyone who uses that same resolver will get the same answer. On the authoritative side, there will be no query to the server until the TTL is reached.

TTLs are an integral part of DNS. They can directly impact on the amount of query volume that is attributable to your authoritative service. In cases where you need to make changes to a record quickly, an excessively long TTL may result in longer-than-expected change in propagation to all users.

Best practices

When setting the TTL, here are some best practices and points of consideration:

• TTLs can directly affect the amount of query volume that is attributable to your authoritative service. There is an inverse relationship between TTL and the number of queries. In the event of needing to quickly change the record, a higher TTL can result in longer than expected change propagation to all recursive servers.

• For records that leverage an advanced traffic management configuration—such as NS1’s Filter Chain—it’s best to keep the TTL as short as possible.* As such, when a change is enacted by the system, users on the other end requesting the name are given the most recent information.

  *Note: Most recursive servers do not understand a TTL shorter than 30 seconds. If you set your TTL to a number lower than 30 seconds, results are likely not to be favorable in the long run.

• For records that rarely change—such as TXT or MX records—it’s best to keep the TTL somewhere between an hour (3600s) and a day (86400s). When there is a need to enact changes impacting these types of records, we recommend reducing the TTL before enacting any changes to ensure that the changes are propagated quickly.

• For help with random label traffic (which logs against your base domain), you can edit the NX TTL value to a higher value, causing resolvers to not re-request that same domain again for longer.  If your active domains do not have answers changed frequently either, it would also help to increase their TTL value as well.

About SOA TTLs

At the top of every DNS zone, in the Start of Authority (SOA) record, there are five TTL values that serve a critical function in the DNS:

• SOA TTL - The interval at which the SOA record itself is refreshed.

• Refresh TTL - The interval at which secondary DNS servers are set to refresh the zone file from the primary server.

• Retry TTL - The rate at which a secondary DNS servers will retry to refresh the 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 the DNS query results in an NXDOMAIN error, because the domain name does not exist (and this is also true for all names under it), or in an EBOT (aka NODATA) response, this is the length of time that the ‘negative’ answer should be cached for.

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.