Summary

  • RFC 8767 allows a recursive resolver to return expired cached data after a good-faith authoritative refresh fails, but that is a resolver-local continuity exception—not proof that the publisher still considers the data current.
  • A defensible exception keeps separate clocks and verdicts for the original TTL, maximum stale age, returned response TTL, DNSSEC signature validity, refresh failure, resolver cohort and actual endpoint safety.

An operator detects that a service address has been compromised and withdraws it from DNS. The record's published TTL runs out. At almost the same moment, the authoritative path becomes unreachable. A recursive resolver still has the old answer in memory. Instead of returning an error, it sends the address again with a new short TTL.

The service has remained reachable. So has the address the publisher meant to retire.

This is an illustrative case, not a reported incident and not an argument against DNS resilience. It shows the authority boundary created by RFC 8767. Serve Stale lets a resolver prefer an expired answer to present failure when authoritative refresh does not succeed. That can be an excellent continuity decision. It is not a continuation of the zone publisher's claim that the data is current.

The distinction matters because DNS carries more than harmless service hints. An old A or AAAA record can point to infrastructure that has changed hands. An old TLSA record can hold back a key transition. An old DS or denial record can preserve a security state the parent or child has already changed. Availability and freshness are not two names for the same outcome.

TTL expiry opens an exception; it does not erase the clock

The traditional meaning of TTL is simple enough to say and easy to flatten: a cache may reuse a resource record for a specified number of seconds. RFC 8767 refines that meaning. When the TTL expires, the source must normally be consulted again. If authoritative refresh is impossible, the resolver may use retained data as though it were unexpired under the Serve Stale rules.

That wording does not make the original TTL longer. The publisher's ordinary freshness horizon still ended at the calculated expiry time. What follows is a different grant made by a different actor: the recursive resolver applies a local availability policy to data it accepted earlier.

The resolver therefore needs two separate retention controls. A maximum cache TTL can clamp an unusually large TTL received from the network. RFC 8767 recommends an ordinary cap on the order of days to weeks, with seven days as a suggested value. The maximum stale timer begins from a different boundary. It limits how long expired records remain eligible after their original cache lifetime has ended. The document discusses a configurable window and notes that one to three days can cover many outages. It does not impose one universal stale period.

An audit that stores only “TTL 30” cannot reconstruct this decision. The 30 may be the small TTL attached to the stale response, not the publisher's original TTL or the record's age. Evidence needs the cache insertion time, original TTL, calculated expiry, current stale age, configured maximum-stale deadline and the TTL placed on the client response.

Four timers answer four different questions

RFC 8767 deliberately avoids prescribing one formal algorithm. Its example describes four timers because the operational questions are different.

The client response timer asks how long the resolver should keep a client waiting before preferring a stale answer. The example recommends 1.8 seconds, slightly below a common two-second client timeout. The query resolution timer asks how long the resolver should continue the broader iterative lookup; the document describes a common range of 10 to 30 seconds. The failure recheck timer limits how often an already failing lookup is retried, with 30 seconds as a recommended interval in the example. The maximum stale timer asks how old retained data may become before it is no longer eligible at all.

Combining those controls into one “serve stale timeout” destroys the reason for each. A short client timer can preserve responsiveness but may prefer old data when an authority is merely slow. A long failure recheck can suppress unnecessary traffic during an outage but delay recognition of recovery. A long maximum-stale window can bridge a serious incident but also retain abandoned state and consume cache memory.

The implementation should make a good-faith recent effort to refresh. It should not turn every cache hit into stale-while-revalidate simply because an expired copy is convenient. When it returns a stale answer at the client-response boundary, the broader resolution attempt should continue until its own timer ends. A stale response is therefore one event inside an unfinished recovery process, not the end of the resolver's responsibility.

A failed refresh must be described, not assumed

Not every disappointing upstream response means the same thing. RFC 8767 says that an authoritative NOERROR or NXDOMAIN response with the AA bit set refreshes the data. Those answers make assertions about the name or its associated data. Other response codes normally represent a failure to refresh and leave the prior cache state intact.

That creates an uncomfortable but necessary boundary. If a name previously existed and the publisher deliberately removes it, authoritative NXDOMAIN must be able to supersede the cached positive answer. The resolver cannot generally distinguish a legitimate removal from an erroneous one and keep the old answer merely because continuity feels safer.

Timeout, network unreachable, SERVFAIL, REFUSED, malformed response, DNSSEC failure and lame delegation should not be compressed into “authority down.” They support different diagnoses and different recovery owners. RFC 2308 also limits how long a resolver may remember server-failure or dead-server indications. A stale decision record should therefore preserve every authoritative endpoint attempted, transport outcome, timestamp, RCODE, AA state, validation result and delegation-refresh step.

The query context belongs with that record. A request without Recursion Desired does not have the same contract as an ordinary recursive query. CD and DO state affect how DNSSEC evidence is handled. Positive, NODATA and NXDOMAIN cache entries have different consequences. The cache key, resolver instance and policy version matter because two resolvers can receive the same client question and make different defensible decisions from different histories.

The stale response receives a TTL, not absolution

When a resolver sends expired records, RFC 8767 requires the TTL placed in the response to be greater than zero and recommends 30 seconds. Zero-TTL responses have caused interoperability trouble, while very short values can trigger repeated queries and amplify load during an outage. The small positive TTL gives downstream caches a bounded pause.

It does not reset the original record's age to zero. If one forwarding resolver receives the stale answer from another, an incident review must not mistake the newly visible 30 seconds for proof that the authority refreshed the record. The downstream response needs provenance: which recursive resolver supplied it, whether that resolver identified stale use, how old its retained data was and when it last attempted the authorities.

Extended DNS Errors can help. RFC 8914 assigns code 3 to Stale Answer and code 19 to Stale NXDOMAIN Answer. Code 22 can describe No Reachable Authority. An EDE can accompany NOERROR as well as failure RCODEs and can provide useful context to clients and logs.

But EDE is supplemental. It does not change how the RCODE is processed. A forwarder may omit, replace or fail to pass it. Its extra text is intended for humans rather than automated policy, and the option is unauthenticated unless the transaction or channel supplies separate protection. “EDE 3 observed” is evidence that the sending resolver described its answer as stale. It is not cryptographic proof of that resolver's cache history or refresh attempts.

DNSSEC has its own clock

A signed RRset may have validated when it entered the cache and still be unusable under current validation rules later. RRSIG inception and expiration are independent of the RRset's TTL and of the resolver's maximum-stale window. Serve Stale raises the chance that a retained signature has crossed its validity boundary.

The AD bit must reflect current authenticated-data semantics, not nostalgia for an earlier successful validation. A record that was secure yesterday does not acquire a new signature because the resolver would rather avoid an outage today. The evidence chain should retain the RRSIG times, validation instant, trust-anchor state, CD/DO context and exact policy applied when the stale response was sent.

Negative data deserves special care. A stale NXDOMAIN can keep a newly added name invisible. Retained NSEC or NSEC3 evidence can postpone use of a newly published DS or TLSA record. Aggressive DNSSEC caching under RFC 8198 is related but distinct: it synthesizes negative or wildcard answers from eligible validated denial material during its cache lifetime. Serve Stale adds the separate question of whether expired material may continue to be used after refresh failure.

The security decision cannot be reduced to “signed versus unsigned.” A correctly signed old address can still point to an endpoint the publisher no longer controls. Cryptographic authenticity says who signed the RRset and whether the signature validates. It does not say the endpoint is currently safe or that the publisher would still serve the answer if reachable.

Sources