Caching and TTL

Why this matters: caching is why DNS survives internet-scale query volume, and TTL is the one dial you control. Getting TTL wrong is how a routine IP change turns into hours of users hitting a decommissioned server.

Key takeaway

Caching is the temporary storage of frequently requested resource records. It significantly reduces response latency and network traffic, and it is implemented at multiple levels — browser, operating system, local network, and ISP resolvers.

The cache hierarchy

A lookup checks each layer in turn and stops at the first hit:

Each layer that hits saves everything below it. A browser-cache hit costs approximately nothing; a full walk to the authoritative server costs multiple round trips.

Layer	Scope	Typical lifetime	Effect of a hit
Browser cache	One application	Seconds to minutes	Zero network activity
OS cache	One machine, all applications	Follows TTL, roughly	No packets leave the host
Local / ISP resolver	Many users	Honors TTL	One local round trip; hierarchy untouched
Authoritative server	Global	The source of truth	Full resolution — the slow path

Time-to-live

Every record carries a TTL that dictates how long a resolver may cache it before expiring and refreshing. It is the only control you have over the entire distributed cache, and it is a pure trade-off:

TTL	Cache hit rate	Load on your DNS	Propagation speed	Good for
Very short (30-60 s)	Low	High	Fast — minutes	Failover targets, imminent migrations
Moderate (300 s / 5 min)	Good	Moderate	Reasonable	General-purpose default
Long (24 h)	Very high	Low	Slow — a day or more	Stable records: NS, MX, apex

Short TTL  ->  fresher records, more queries, faster changes
Long TTL   ->  fewer queries, cheaper, but changes take much longer to land

Negative caching

Failures are cached too. When a name does not exist, the negative response (NXDOMAIN) is cached for a period derived from the zone's SOA record.

This is protective — it stops typos and scans from hammering authoritative servers — but it has a sharp edge: create a record for a name someone has already queried unsuccessfully, and they may keep getting "does not exist" until the negative cache expires. Teams hit this constantly when provisioning a new subdomain and testing it a moment too early.

The migration playbook

Here is the situation that makes TTL matter. An organization updates the IP address of its website, but many users still reach the old IP because of caching. How do you minimize disruption?

The answer is a sequence, and the crucial part happens before the change:

Lower the TTL well in advance — say from 24 hours to 60 seconds.
Wait at least the full old TTL. This is the step people skip and it is the one that matters: caches holding the record at the old long TTL will not pick up the new short TTL until they expire. Change the record too early and those resolvers stay on the old address for the full 24 hours.
Make the change. With a 60-second TTL, most resolvers converge within minutes.
Keep the old IP serving — dual-run both addresses so anyone still cached is not broken.
Watch traffic drain from the old address, then decommission it. Expect a long tail from clients that ignore TTL.
Raise the TTL back once the change has settled, to restore cache efficiency.

Key takeaway

Caching is what makes DNS survivable at internet scale; TTL is the price you pay for that in propagation delay. Lower it before you need it, never after — and prefer architectures where the address does not have to change.

Interview signal by level

Level	What a strong answer sounds like
L4	"DNS results are cached, and TTL controls for how long."
L5	Knows the playbook: "lower the TTL ahead of a migration, then change the record so it propagates quickly."
Staff+	Sequences it correctly and avoids it: "lower TTL, then wait out the old TTL before changing anything, dual-run during the drain, and expect a tail from clients that ignore TTL. Better still, CNAME to a load balancer so the address never changes and DNS isn't my deployment mechanism."

Next: why DNS keeps working when parts of it do not.