DNS
What does DNS TTL control?
Short answer
TTL is the time, in seconds, that a resolver may cache a DNS answer before asking again. A lower TTL makes changes visible sooner but causes more queries. It does not force every resolver to refresh at once.
What changes the answer
- Value set before a planned change
- Resolver behaviour can differ
- Cached "not found" answers
What the number means
Every DNS record carries a time to live, or TTL, measured in seconds. It tells resolvers how long they may keep the answer in cache. A record with a TTL of 3600 can be reused for up to an hour before the resolver should ask the authoritative server again. RFC 1035 defines the TTL field as part of the record format.
It is caching, not propagation
DNS changes do not spread outward like a broadcast. After you edit a record, resolvers that cached the previous answer keep serving it until its TTL runs out, while resolvers that had nothing cached see the new answer immediately. That is why one network may show the new server and another the old one.
How to use it in a move
- Some days before a planned change, lower the TTL on the records you will change.
- Wait at least as long as the old TTL, so caches that hold the long-lived answer expire.
- Make the change and verify it.
- Raise the TTL again once things are stable, to reduce query volume.
Very low TTLs everywhere are not necessary. They add query load and give little benefit when you are not changing anything.
Limits to remember
Resolvers are separate software run by different operators, and some apply their own minimum or maximum limits. Do not promise a precise switchover time. Resolvers can also cache a response saying a name does not exist, which is why a record you just created can seem missing for a while.
Check what you are seeing
When results differ between networks, query the authoritative nameserver directly and compare the TTL it reports with what a public resolver returns. The troubleshooting checklist includes DNS observations you can record.
An example
Imagine a record with a TTL of 3600 seconds that you change at noon. A resolver that cached the old answer at 11:50 may keep serving it until about 12:50, while a resolver with nothing cached sees the new value immediately. Both behave correctly, which is why a check from one network is not enough to call a change complete.