DNS TTL Explained: What It Is and When to Change It
TTL tells resolvers how long to cache a DNS answer. Learn sensible values, why lowering it before a move helps, and why changes can still seem slow.
Every DNS record has a number called TTL, which stands for time to live. It is easy to ignore until the day you change a website's address or switch email providers and wonder why some people still see the old version. TTL is the setting that explains much of that behaviour, and it is under your control.
What TTL actually means
TTL is a value in seconds that tells resolvers how long they may keep a copy of the answer before asking again. If a record has a TTL of 3600, a resolver that fetched it at 10:00 may keep serving the same answer until 11:00. After that, it must check with the authoritative server.
The TTL does not control how fast your DNS host publishes a change. Your name servers show the new value immediately. It controls how long other people's caches may keep showing the old one.
Why caching exists
Without caching, every page view would trigger lookups through the whole DNS chain. Caching makes browsing faster, reduces load on name servers and keeps the system reliable. A longer TTL means fewer lookups and slightly quicker access for repeat visitors. A shorter TTL means more lookups but faster changes.
Common values
| TTL (seconds) | Equivalent | Typical use |
|---|---|---|
| 60 to 300 | 1 to 5 minutes | Before and during a migration, or for records that change often |
| 1800 | 30 minutes | A balance for sites that change occasionally |
| 3600 | 1 hour | A widespread default for general records |
| 14400 to 86400 | 4 to 24 hours | Stable records such as MX or NS that rarely change |
There is no single correct value. The right choice depends on how often the record changes and how costly a delay would be.
How to use TTL in a migration
- Plan ahead. At least as long as your current TTL before the move, lower the TTL on the records you will change. If it is currently 86400, lower it at least a day beforehand, since caches already hold the old value.
- Make the change at the quiet time you have chosen, for example the A record for the website or the MX records for email.
- Check from multiple places that the new answer is being served.
- Raise the TTL back to a normal value once everything is stable, to restore the caching benefit.
The most common mistake is lowering the TTL at the moment of the change. That does nothing for caches that already stored the old long value.
Which records to lower
- The
AandAAAArecords for the domain and forwww, when moving a website. - The
MXrecords, when moving email. - Any
CNAMEthat points to the old service. - TXT records for SPF only if you are changing senders, though these matter less for timing.
Name server (NS) changes work differently. They are controlled by the registry for the top-level domain, and their effective lifetime often follows the registry's own settings, not your zone TTL. Plan for those to take longer.
Why a change can still look slow
- Negative caching. If a resolver recently looked up a name that did not exist, it may remember "no such name" for a while. Creating a new record does not clear that straight away.
- Browser and operating system caches. They have their own short-term DNS caches. Restarting the browser or flushing the system cache may help.
- Resolvers that ignore small TTLs. Some enforce a minimum. Do not rely on a TTL of a few seconds being honoured everywhere.
- Applications that cache. Some software resolves a name once at start-up and keeps using the address until restarted.
Is a very short TTL always better?
No. Very low TTLs increase the number of lookups, which can slightly slow repeat visits and puts more load on your DNS provider. If your DNS provider is unreachable, long TTLs also keep your site resolving for cached users for longer. For stable sites, an hour or more is perfectly reasonable.
Checking the TTL
Run dig example.com A and look at the number in the answer section. When you query a caching resolver repeatedly, that number counts down, which shows you how long that resolver will keep the cached answer. Querying the authoritative server directly shows the full configured value.
A short checklist
- Note the current TTLs of the records you will change.
- Lower them early enough.
- Switch.
- Verify.
- Raise them again.
TTL and failover
Some setups use DNS to move traffic to a backup server when the main one fails. In that design a short TTL makes sense on the relevant record, because the switch must reach users quickly. For ordinary small business sites that kind of automated failover is rare, and a moderate TTL is the better default. Choose based on how you actually run the site, not on what sounds most advanced.
TTL planning with Zebra Hosting
When Zebra Hosting's team handles a migration for you, they can advise which records to lower and when, and support is available in 17 languages. Read how it works on our migration page, or browse the knowledge base for DNS guides.
