Every DNS record you create has a small number attached to it that most people leave at the default: the TTL. Yet the DNS TTL decides how quickly your changes reach visitors, how much traffic your name servers handle, and how painful a server move will be. Choosing it deliberately takes a minute and can save you hours of waiting during an outage or migration.
What TTL means
TTL stands for time to live. It is a value in seconds that tells DNS resolvers how long they may store a copy of a record before they must ask your authoritative name servers again. A record with a TTL of 3600 can be cached for one hour; one with a TTL of 300 for five minutes.
Resolvers are the servers that look up names on behalf of users: the one run by an internet provider, a company's internal DNS server, or public services such as 8.8.8.8 and 1.1.1.1. When a resolver fetches your record, it starts counting down from the TTL. Every user who asks that resolver before the countdown ends gets the cached answer instantly, without the resolver contacting your servers. When it reaches zero, the next request triggers a fresh lookup.
You can watch this happen. Run the same query twice a few seconds apart and the TTL in the answer goes down:
$ dig www.example.com A +noall +answer
www.example.com. 3542 IN A 203.0.113.25
$ dig www.example.com A +noall +answer
www.example.com. 3531 IN A 203.0.113.25Our DNS lookup tool also shows the remaining TTL for each record it returns.
The trade-off: speed of change versus efficiency
| Short TTL (e.g. 300) | Long TTL (e.g. 86400) | |
|---|---|---|
| How fast changes reach users | Minutes | Up to a day |
| Queries to your name servers | More | Fewer |
| Extra lookup delay for visitors | Slightly more often | Rarely |
| Resilience if your DNS provider has an outage | Lower: caches empty quickly | Higher: cached answers keep working |
The last row is often overlooked. If your DNS provider suffers an outage, resolvers that still hold a cached answer keep sending visitors to the right place. With a five-minute TTL, that safety net disappears five minutes into the outage. Long TTLs are not just about saving queries; they also buy you time.
On the other side, a single DNS lookup usually takes only milliseconds, and popular resolvers serve so many users that your record is often already cached. For most small and medium sites the performance difference between a one-hour and a one-day TTL is negligible.
What should you set your DNS TTL to?
There is no single correct number, but these are sensible starting points for records that are not about to change:
- A, AAAA and CNAME for websites: 3600 (one hour) is a good everyday balance. Go to 14400 or more if the server is very stable.
- MX records: 3600 to 86400. Mail servers retry for days if delivery fails, so very short TTLs gain you little.
- TXT records for SPF, DKIM and DMARC: 3600 is fine. You may want them shorter while you are actively tuning a new email setup.
- NS records: usually set by your DNS host or the registry; typically a day or longer.
- Records behind failover or load balancing: 60 to 300, because the whole point is to move traffic quickly when something fails.
Some providers enforce a minimum TTL, and some resolvers apply their own minimum or maximum regardless of what you publish. Treat the TTL as an instruction most of the internet follows, not a guarantee.
Using TTL to plan a change
The single most useful TTL habit is lowering it before a planned change. The timing matters: resolvers that cached your record under the old TTL will keep it for that full period, so the reduction has to be in place for at least one old TTL before you make the real change.
- Two days before: note the current TTL of each record you will change. If it is 86400, lower it to 300 now.
- Wait at least the old TTL (24 hours in this example) so every cache has picked up the short value.
- Make the change. Most resolvers now pick up the new value within about five minutes.
- Verify with a DNS propagation checker that resolvers in different regions return the new value.
- Raise the TTL again to your normal value once you are confident you will not need to roll back.
Keeping the short TTL for a little while after the change has a bonus: if something goes wrong, rolling back is just as fast.
Negative caching: the TTL you did not set
Resolvers also cache the fact that a name does not exist. If someone looked up new.example.com before you created it, they received an NXDOMAIN answer, and that "no such name" result is cached too. How long it is kept is governed by your zone's SOA record (the lower of the SOA's own TTL and its minimum field, as defined in RFC 2308). If a newly created subdomain seems slow to appear for some people, this negative caching is usually why. Avoid testing a new name before you have created its record.
Common TTL mistakes
- Lowering the TTL at the same moment as the change. Caches still hold the old long TTL, so it has no effect on this change.
- Leaving everything at 60 seconds permanently "just in case". You lose the resilience of caching and gain very little.
- Forgetting name server changes. The TTL on the delegation records is set by the domain registry, not by you, so lowering your own records does not speed up a name server switch.
- Assuming TTL controls browsers exactly. Browsers and operating systems keep short caches of their own; flush them when testing.
Key takeaways
- DNS TTL is the number of seconds a resolver may cache a record.
- Short TTLs mean faster changes; long TTLs mean fewer queries and better resilience.
- One hour is a sensible default for most records; use shorter values only where you need agility.
- Lower the TTL at least one full old-TTL period before a planned change, then raise it again afterwards.