Published: 12.10.2026
TTL, or time to live, is a number in every DNS record that tells resolvers how long they may keep an answer. It sets the trade-off between fast changes and fewer lookups. This article explains how to choose TTL values, how to plan a migration around them and what simple failover ideas look like. It also explains what DNS alone cannot guarantee.
Reading the TTL
The TTL is written in seconds. A value of 300 means five minutes, 3600 means one hour and 86400 means one day. Each record in a zone can have its own TTL, so a website record and a mail record may differ. A low TTL lets changes spread quickly, but causes more queries to your name servers. A high TTL reduces queries and makes changes slower to reach visitors.
Choosing values
- Stable records that rarely change, such as mail records, can use a longer TTL.
- Records you may need to change during a migration can use a shorter TTL during the planned period.
- Very short TTL values on every record increase the query load and make small mistakes more visible.
- Write down the TTL of each record, so that the migration plan is accurate.
Planning a migration with TTL
- Choose the change date and the new server, and test the new server first through a hosts file entry on your own computer.
- About one full old TTL before the change, lower the TTL of the records you will change.
- Wait until the old, longer TTL has expired everywhere, then make the change.
- Keep the old server running for at least the old TTL, so that caches still holding the old answers reach a working site.
- After the change is stable, raise the TTL back to a normal value.
Simple failover ideas
Failover means sending traffic to a backup when the main server fails. The simplest form is a name with two addresses in its records, but without health checks the DNS answer keeps including the failed address. A more reliable approach needs a service that checks the server and changes the answer when it fails. Check whether your DNS plan offers such checks, because not every DNS plan includes them. Other practical ideas include:
- A standby server with the same content, ready to take over after a planned DNS change.
- A low TTL on the website record during planned maintenance only.
- A simple status page for visitors, so that short outages are explained.
- Application-level failover, such as a load balancer that you configure and operate yourself.
What DNS alone cannot guarantee
DNS only tells clients where to go. It cannot make every resolver follow your TTL, make every client reconnect quickly or move open connections to a new address. Browsers keep connections, applications cache addresses and some networks ignore short TTL values. Failover also depends on the application, on how data is synchronised between servers and on how long it takes to detect a failure. A standby server with old data may show outdated content, so plan the data copy as carefully as the DNS change.
Frequently asked questions
Which TTL should I use? A moderate value suits stable records, and a shorter one is worth using only around planned changes. Base the choice on how often you expect to change each record.
Does a low TTL protect against attacks? No. It only affects how quickly answers change. Protection against attacks needs separate measures.
Can DNS switch visitors automatically when a server fails? Only with a mechanism that checks the server and updates the answer. Plain DNS records do not check the health of a server by themselves.
