How do DNS TTLs and negative caching work, and how do you use them when you change a record?
Show the answer
Say this first
Every record has a TTL in seconds. A resolver that caches it counts the TTL down and serves the cached copy until it reaches zero, then asks again. "No such name" (NXDOMAIN) and "no record of that type" (NODATA) answers are cached too, for the smaller of the SOA record's own TTL and the SOA minimum field (RFC 2308). Before a planned change I lower the TTL at least one old TTL ahead, make the change, then raise it again.
Go deeper
Positive caching
Each resolver counts down on its own. Users behind different resolvers can see different answers for up to one full TTL after a change, and you cannot flush other people's resolvers.
Negative caching
A negative answer carries the zone's SOA in the authority section. With
SOA ... 2026111001 7200 3600 1209600 3600 and an SOA TTL of 3600, a "does not exist" answer is cached
for an hour. The classic trap: someone tests a name before it is created, the resolver caches
NXDOMAIN, and the new record stays invisible to them for up to an hour.
Resolvers also cap TTLs. BIND by default keeps positive answers at most 1 week and negative answers at most 3 hours.
Migration recipe
| When | Action |
|---|---|
| Two days before | Lower the TTL from 86400 to 300. Wait at least 86400 seconds |
| Change window | Change the address. Old answers drain within 5 minutes |
| Day after | Raise the TTL again |
Keep the old server answering, or proxying to the new one, until the old TTL has passed.
Flushing caches you do control
| Where | Command |
|---|---|
| BIND | rndc flushname www.example.com |
| Unbound | unbound-control flush www.example.com |
| Windows DNS server | Clear-DnsServerCache |
| Windows client | ipconfig /flushdns |
| Linux systemd-resolved | resolvectl flush-caches |
They will ask next
Why not put every record on a 60 second TTL?
More queries, more cache misses that add round trips for users, and less resilience: if your authoritative servers go down, records vanish from caches within a minute. Short TTLs are for planned changes and records used for failover.
You lowered the TTL an hour ago. Will the change be fast now?
No. Resolvers that cached the record under the old 86400 TTL keep it for up to a day. The short TTL only applies to copies fetched after you lowered it.
Some clients hit the old address long after every TTL expired. Why?
Applications cache too. Some runtimes and connection pools resolve once at startup and keep long-lived connections open. They need a restart or a connection drain, not DNS work.
Traps
- Lowering the TTL at the same moment as the change.
- Forgetting negative caching when a brand new name "does not exist" for some users.