DNS Caching & TTL

TTL mechanics, negative caching, NXDOMAIN propagation, stale-while-revalidate, cache poisoning attacks, and resolver hierarchies.

Overview

Overview DNS caching is fundamental to the scalability of the internet. Without caching, every DNS query would traverse from the client to the root nameservers, through TLD nameservers, to the authoritative nameservers for every single request. Caching allows resolvers to store and reuse responses for the duration specified by the Time-To-Live (TTL) value in each DNS record, dramatically reducing query volume to authoritative servers and decreasing resolution latency for clients.

The TTL field in a DNS resource record specifies how long, in seconds, the record may be cached by resolvers. When an authoritative nameserver returns a record, it includes the TTL; each resolver that caches the response decrements the TTL as time passes and re-queries the authoritative server when it reaches zero. A record with TTL 300 cached by a resolver five minutes ago has TTL 0 — the resolver must re-query before serving the record to the next client.

The resolver hierarchy has several layers. Clients first check their local DNS cache (maintained by the OS resolver), then query a stub resolver (typically the router or DHCP-provided nameserver), which queries a recursive resolver (often the ISP's resolver or a public resolver like 8.8.8.8). The recursive resolver caches responses and serves them to multiple clients, making its cache the most impactful layer for TTL decisions.

Negative caching handles NXDOMAIN (non-existent domain) responses. RFC 2308 standardizes that NXDOMAIN responses should be cached for the duration specified in the SOA record's minimum field or the SOA TTL, whichever is smaller. This prevents resolvers from hammering authoritative servers with repeated queries for domains that do not exist.

Cache poisoning is the most serious security threat to DNS caching. An attacker who can inject a fraudulent DNS response into a resolver's cache can redirect traffic for any domain the resolver serves. The Kaminsky attack in 2008 showed how an attacker could poison the cache of any resolver by racing to inject a forged response before the legitimate one arrived. DNSSEC provides cryptographic protection against cache poisoning; source port randomization and 0x20 encoding are mitigations for non-DNSSEC resolvers.

Key concepts

TTL (Time-To-Live): A 32-bit integer in each DNS resource record specifying the maximum number of seconds the record may be cached by resolvers. When an authoritative server returns a record with TTL 300, a recursive resolver caches it for up to 300 seconds. The resolver decrements the TTL in real time and returns the remaining TTL to clients who query it. Clients see the TTL decrement as records age in the resolver's cache. Once TTL reaches 0, the resolver must query the authoritative server again. Setting TTL low (30-60s) enables fast propagation of record changes; high TTL (3600-86400s) reduces authoritative server query volume.
Negative Caching (NXDOMAIN): RFC 2308 defines how NXDOMAIN responses are cached. When an authoritative server returns NXDOMAIN, it includes the SOA record for the zone. Resolvers cache the NXDOMAIN for min(SOA minimum field, SOA TTL) seconds. During this period, the resolver returns NXDOMAIN to clients without re-querying the authoritative server. Negative caching is why a newly created DNS record takes time to become accessible — resolvers that previously received NXDOMAIN for that name will not re-query until the negative cache entry expires.
Resolver Hierarchy: DNS resolution passes through multiple caching layers. The OS resolver maintains a small local cache (Windows DNS Client, nscd on Linux, mDNSResponder on macOS). The stub resolver forwards to a recursive resolver (configured via DHCP or /etc/resolv.conf). The recursive resolver (ISP, corporate DNS, or public resolvers like 8.8.8.8 or 1.1.1.1) caches responses and serves many clients. Because recursive resolvers serve many clients, their cache is the most impactful — a record served from a popular recursive resolver cache effectively bypasses the authoritative server entirely.
Cache Poisoning: An attack where a malicious party injects a fraudulent DNS record into a resolver's cache. The classic method exploits the fact that DNS queries use predictable transaction IDs and source ports. An attacker floods the resolver with forged responses; if one arrives before the legitimate response and matches the transaction ID, the forged record is cached and served to all clients. The Kaminsky attack (2008) demonstrated this at scale. Mitigations: DNSSEC (cryptographic authentication), random source port selection (now standard), 0x20 encoding (randomize case in queries and verify case matches in responses), and Response Rate Limiting.
Stale-While-Revalidate: An extension to caching behavior (RFC 8767) where a resolver serves a stale (expired TTL) record to the client immediately while simultaneously fetching a fresh copy from the authoritative server in the background. This eliminates the latency spike that occurs when a cached record expires and the client must wait for the authoritative query to complete (typically 10-100ms). The risk is that clients receive an outdated record for one request after the TTL expires. Unbound, BIND 9.12+, and Knot Resolver support stale-while-revalidate.
Minimum TTL Floor: Many DNS resolvers enforce a minimum TTL floor regardless of what the authoritative server specifies. Cloudflare's resolver enforces a 1-second minimum; Google's 8.8.8.8 enforces a minimum of approximately 30 seconds for practical purposes. AWS Route 53 alias records inherit the TTL of the target resource. This means setting TTL to 0 or 1 on your authoritative records does not guarantee that resolvers will re-query on every request — most public resolvers will cache for at least 30 seconds, limiting how fast DNS-based failover can propagate.

When to use it

Planning DNS record TTL values for a deployment that requires fast failover vs one that prioritizes caching efficiency.
Debugging why DNS changes are not propagating to all clients despite being updated on the authoritative nameserver.
Investigating elevated DNS query rates on authoritative nameservers and determining whether resolver-side caching is working correctly.
Understanding the blast radius of a DNS cache poisoning attack and evaluating mitigations.
Implementing stale-while-revalidate behavior in application-level DNS caching to reduce resolution latency on the hot path.

Interview questions

You update a DNS A record on Route 53 but some users still see the old IP an hour later. Walk me through all the caching layers that could explain this.
Explain the Kaminsky DNS cache poisoning attack and what mitigations are in place today.
How does negative caching work, and how does it affect new service deployments?

DNS Caching & TTL

Overview

Key concepts

When to use it

Interview questions

More Networking topics