October 7, 2021

What is DNS Time To Live (TTL)?

How to correctly choose the right DNS TTL value in this modern age.

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.

Fire Datacenter OVH
Fire of the OVH Datacenter in France with consequent irretrievable loss of millions of websites.

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 and a TTL set to 86.400 (24 hours), when client A queries www.example.com , IP 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, Customer A will continue to move to 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 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.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.


Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.


Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

Back to top