Serving Stale Data to Improve DNS Resiliency
updates
Extracted elements (23)
A proposed EDNS option to signal stale data usage was rejected as providing too little perceived value relative to implementation burden. An opt-in EDNS option was also rejected because serve-stale is intended to improve DNS resiliency universally without requiring client participation.
Only NoError and NXDomain with the AA bit set invalidate previously cached data because other RCODEs make no authoritative assertion about the queried name or its associated data, consistent with existing resolver behavior where failed prefetch lookups do not invalidate cache state.
Stale data is served only after a good-faith refresh attempt has failed, not speculatively before attempting resolution. If stale data were always returned immediately, resolvers would frequently send data they could have refreshed, undermining the intent of TTL as a freshness signal.
Stale nameserver glue addresses are explicitly in scope for serve-stale. If a top-level domain's nameservers are taken offline (e.g., by a DDoS), resolvers with expired glue for subdomains can still resolve names within those subdomains — providing meaningful resiliency even for names not previously cached.
The recommended stale TTL of 30 seconds sidesteps historical implementation problems with 0-second TTLs and avoids congestive collapse from clients rapidly re-querying on very short TTLs, while also rate-limiting forwarding resolvers that honor the TTL.
TTL values with the high-order bit set are now treated as positive integers and then clamped, rather than as zero per RFC 2181. The rationale is engineering simplicity: no operator has a rational purpose for TTLs above 2^25 seconds, no such TTLs were found in DNS-OARC Day-in-the-Life samples, and treating them as zero was needlessly disruptive compared to clamping.
CNAME and DNAME records co-existing with other record types at the same owner name in an expired cache can cause incorrect stale answers. For example, if a name transitions from an A record to a CNAME and both expire while authorities are unreachable, a resolver that did not evict the A record upon caching the CNAME may return the stale A instead of the newer CNAME.
The serve-stale processing is a strictly local resolver operation; no consistent variables between deployments are required for interoperability. Client-facing behavior (stale TTL set to a positive value) is the only on-wire observable change.
Answers from authoritative servers with a DNS response code of either 0 (NoError) or 3 (NXDomain) and the AA bit set MUST be considered to have refreshed the data at the resolver. All other response codes SHOULD be treated as a failure to refresh, leaving prior cached state intact.
Implementers MAY decide to return stale answers when authoritative servers respond with ServFail or similar error RCODEs, treating those errors as equivalent to an authoritative response being unavailable.
Implementers MAY treat all authoritative servers returning Refused as preempting the use of stale data, since Refused may signal an explicit zone takedown, though it is also overloaded to mean transient configuration failures.
The failure recheck timer — limiting how frequently a failed lookup is retried against authoritative servers — should be no more than 5 minutes per RFC 2308 Section 7, to prevent stale answers persisting unnecessarily once authorities recover.
The TTL definition in RFC 1035 Sections 3.2.1 and 4.1.3 is amended so that if data cannot be authoritatively refreshed when the TTL expires, the record MAY be used as though it is unexpired. This formally permits stale data usage by recursive resolvers.
TTL values SHOULD be capped on the order of days to weeks, with a recommended cap of 604,800 seconds (7 days). This replaces the effectively unbounded 31-bit cap suggested by RFC 2181.
When returning a response containing stale records, a recursive resolver MUST set the TTL of each expired record in the message to a value greater than 0, with a RECOMMENDED value of 30 seconds.
Zero-second TTL records continue to be prohibited from caching and are explicitly unusable even for stale fallback; this prohibition is not relaxed by the serve-stale mechanism.
This document does not add any practical new privacy issues beyond those already present in the DNS.
The maximum stale timer governs cache management independently of the query resolution process. It defines how long after expiry a record is retained in the cache; the suggested value is 1 to 3 days, distinct from the 7-day maximum cache TTL clamp applied to authoritative answers.
The serve-stale mechanism is governed by four timers: (1) client response timer (recommended 1.8 s) — caps time before sending a response; (2) query resolution timer (typically 10–30 s) — caps total iterative resolution effort; (3) failure recheck timer (recommended 30 s) — limits retry frequency against failed authorities; (4) maximum stale timer (suggested 1–3 days) — caps how long expired records are retained in cache.
Attackers could combine serve-stale with a DDoS attack on authoritative servers to intentionally extend the lifetime of malicious or stale DNS records in resolver caches. The document acknowledges this risk but notes that attackers with this capacity could cause greater harm through other means.
Serve-stale potentially enlarges the window in which stale hostnames pointing to addresses no longer controlled by the legitimate owner can be exploited to fraudulently obtain domain-validated certificates (as demonstrated in the CloudStrife research). Mitigations include certificate authorities performing full DNS root-anchored lookups or using non-stale-serving resolvers.
Using stale data increases the likelihood of DNSSEC validation failures because signatures may be returned outside their validity period. Stale negative records (cached NSEC/NSEC3) can delay use of newly published TLSA or DS RRs. These failures only occur when authoritative servers are unreachable — the same condition that triggers serve-stale — so no new failure mode is introduced.
On receiving a query, the resolver checks for unexpired cache entries; if none and Recursion Desired is unset, it returns immediately without consulting stale data. Otherwise it starts the client response timer and attempts iterative resolution; if the client response timer fires before resolution completes, it falls back to stale cache data (if available) and sends a response with TTL > 0, continuing resolution in the background until the query resolution timer expires.