Table of contents of the article:
A TTL (or Time to Live) is a crucial setting in every DNS record that can make the difference in some cases between life and death, yet it's rarely mentioned.
If you are also guilty of using the default TTL for your records, you need to read this.
TTL meaning
The TTL tells the name servers how long DNS information should be cached. Resolution name servers are like DNS exchange intermediaries. When you enter a domain into your browser, you are actually asking your local resolution name server for that domain's IP address.
Time to Live (TTL) is the amount of time a record is cached in a resolver when the record is queried. It is measured in seconds and is set within each record in the DNS configuration. In other words, TTL is a value that tells the DNS resolver how long the cache must persist before requesting a new one.
Example : If the TTL for a record is set to 86.400 seconds (24 hours), the server will collect information to display updated details for that particular record in 24 hours and will not re-query the DNS server before 24 hours have expired.
Why is TTL important?
For base A and CNAME records, you probably won't run into scenarios where TTL times cause problems. However, once you start dynamically changing endpoints such as failover, the TTL becomes very important.
For example, suppose the primary IP address for the domain we're looking for isn't available. This domain has also enabled failover, which will direct users to a backup IP address when the primary is down.
This could be handled in two ways. If the record has a high TTL, users will still be directed to the primary IP address until the resolver cache expires. If the record has a low TTL, it is more likely to point to the correct endpoint first.
But let's take a perhaps more eloquent and easy to understand example.
Let's imagine that you have registered the domain pippo.it on SUPPLIER 1 and you have a separate Web and Mail Hosting service on a server managed by SUPPLIER 2.
Let's imagine now, as happened in March 2021, that the SUPPLIER 2 datacenter catches fire so seriously that it is destroyed.
Let's imagine that you are a shrewd person and that you make automatic backups on an external server that we will call PROVIDER 3.
The backup data is therefore intact and safe.
To restart quickly, most likely you will go to PROVIDER 3 (The one where the backup is) and ask to rent a server where you will go to restore the backup of the files and the database. You will import the webserver configuration, the SSL certificates and you only have to point the DNS records of the domain with the www and without the www towards the IP of the new server on the SUPPLIER 3.
Child's play.
You log into the domain management control panel, move to the DNS zone where the information is stored and find a default record set to 640800.
640800 what? Seconds!
That is a week.
You enter the value of the new IP of the server on SUPPLIER 3 where you have restored the backup and before the world is informed of the new IP it will take up to a week because the nameservers have had as their directive to consider the recovered DNS information good for a week.
Obviously, if a nameserver of a supplier (let's say Google for example) has passed 2 days ago, the time to wait will no longer be a week, but 5 days, but in any case it is legitimate and correct to say that with a TTL of 640800 it is expected a DNS propagation in a week as well as a TTL at 86400 seconds are expected to propagate within 24 hours and so on.
If the value had been, for example, 900 seconds, the site on the new server of PROVIDER 3 would be visible again within a maximum time of 15 minutes.
TTL DNS and better settings
One of the most common questions we are asked is: "What are the best settings for Time To Live ? " As the answer is not always simple for all scenarios. We have compiled some best practices to help you determine which setting is most appropriate for your domain.
High TTL values recommended
High TTL values are typically used for records that change infrequently, such as MX or TXT records. Longer TTLs reduce resolution times because each time an authoritative name server provides an answer to a query, an additional search is obtained. A high TTL provides faster responses for multiple static resources by storing the information locally before having to retrieve it again.
TTL example
If you have the A www.example.com that points to IP address 2.2.2.2 and a TTL set to 86.400 (24 hours), when client A queries www.example.com , IP 2.2.2.2 will be cached in its cache for a whole day. Customer A will not make another query for www.example.com since its 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, Customer A will continue to move to 2.2.2.2 for 23 hours after the initial visit until the TTL reaches 0. At this point, the record expires and a new query can be made on that FQDN. Then, Client A will be directed to 3.3.3.3. to their next question.
Note : If you need to make changes when using high TTL values, you will need to lower the TTL and wait for the cache to expire before you can make changes. This will eliminate the need to wait for the record to expire.
Low TTL values recommended
Resources that require frequent updates require a low TTL value. A shorter cache time is also essential for website and network changes. DNS management services, such as Failover and Load Balancing, require a low TTL in order to direct end users to the updated IP. In the event of unexpected traffic spikes, queries cannot be sent to the updated IP until the cache expires, leaving DNS management services ineffective during critical periods. A shorter TTL is the remedy for this type of situation.
Note : Low TTLs are recommended for critical records. A good range could be between 30 seconds and 300 seconds (5 minutes) .
If a TTL is set to 30 seconds to accommodate frequent DNS changes, the end user experience is minimally impacted and gives you maximum flexibility. While this may seem ideal, if a user frequently visits your site in a day, they query the record www.example.com Every 30 seconds or so, and when you multiply it by the number of users, the query count increases, which can lead to higher costs.
TTL logic
The rule of thumb for setting TTL values for non-critical records that may 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 provided by lower TTLs, so a TTL of just 30 seconds, or even half an hour, isn't the best resolution. In this case, you will want to use a longer TTL from 1 to 12 hours .
You can adjust your TTL to suit the accessibility needs of your end users.
Most common TTL use cases
The following use cases include responses from our support team to help you with the best TTL values for your domain.
Screenwriting : I use failover and need as little downtime as possible. Which TTL should I set?
Response : If the availability of your FQDN is absolutely essential, failover is a must but requires a low TTL to work the way you want. Failover cannot bypass TTLs in any way. If you have a TTL of 1800 (seconds) for your failover record and it fails on the second IP, users will not be routed to the updated IP for up to 30 minutes (until the cache in the resolver expires). With that in mind, you will want to set a low TTL and the lower the better. That said, many resolvers won't recognize TTLs of less than 30 seconds, but you can always take a test record to find out if your resolver allows TTLs of less than 30 seconds.
Screenwriting : This record does not need failover, but we do make some changes.
Response : If the record in question is not mission critical but is updated from time to time, a higher TTL is the way to go. The most common follow-up question is "and when should I make a change?" and the answer is to schedule the update. Let's say you have the TTL set to 7200 (2 hours), once you know you want to upgrade, reduce the TTL for how long you are comfortable with downtime (30 seconds is the minimum we recommend) and then wait for the TTL- in this case, you would wait two hours. After two hours, you can edit the record and restore the initial TTL value.
Understanding the time to live for the refinement of the DNS strategy
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 you are maximizing your DNS strategy.
A rule for happy living with DNS
A simple rule to live peacefully with DNS Time To Live is the one that reads “not too much, not too little. The right". That is to understand that a too high value of the TTL can be absolutely CATASTROPHIC in some conditions in which you need to quickly switch the IP for example to a new server, a new supplier, a new structure (perhaps because you are becoming victims of attacks DDoS for example), and at the same time understand that it can be paranoid to set a TTL at 10 seconds unless we can actually tolerate even a minute of downtime.
Assuming you are not a reality like Top Fortune 500, in which a minute of Down can mean millions of euros in damage, a reasonable and peaceful value for almost all of the population and realities is to set it between a range that goes from 5 to 15 minutes.
With this "rule" you may not make the best choice but you will DEFINITELY not make the worst.
