Summary

  • RFC 8767 permits a recursive resolver to return eligible expired DNS data when authoritative refresh fails; a zero-second TTL remains ineligible, and successful authoritative NoError or NXDomain responses replace the stale state.
  • The mechanism improves continuity, but it moves a conditional freshness decision from the zone operator's TTL to resolver-owned timers, cache policy and failure classification.
  • Stale Answer diagnostics can expose the decision, but they do not authenticate the old data or authorize it; leadership still has to set risk classes, limits and an exit trigger.

Analysis

Imagine that a service has moved from one address to another. Its old DNS record expires on schedule, but the resolver cannot reach any authoritative server to learn the new value. One choice returns an error. The other returns the expired address. If the old service still works, stale data can turn an authoritative outage into an event most users never notice. If the old address has been reassigned, withdrawn or placed behind different controls, the same choice can prolong a state the zone operator intended to end.

That is the power hidden inside a cache timer. Traditional DNS descriptions treated the TTL as the period after which a cached resource record should be discarded and its source consulted again. RFC 2181 clarified that TTL is a maximum, not a promise that data will remain cached for the whole period. The authority publishes the value, and the resolver normally treats expiry as the point at which reuse stops.

RFC 8767 changes that boundary for an exceptional condition. When data cannot be authoritatively refreshed after its TTL expires, a recursive resolver may use it as though it were unexpired. The change is deliberately conditional: expired data is not supposed to become the default first answer followed by a lazy refresh. The resolver should have made a recent good-faith effort to obtain current data, and it should continue the resolution attempt after replying with stale data.

Zero means zero. A record received with a zero-second TTL may be used only for the transaction in progress and cannot later become stale fallback. When a resolver does return expired records, it must place a positive TTL on them; RFC 8767 recommends 30 seconds. The short value avoids software problems associated with a zero TTL and limits how quickly downstream caches ask again.

The standard separates four clocks because they govern different rights. The client response timer limits how long a user waits before the resolver considers stale data; the example recommends about 1.8 seconds. The query resolution timer limits the resolver's total work trying to obtain a current answer. The failure recheck timer controls how soon failing authorities are tested again. The maximum stale timer controls how long expired data is retained as a candidate at all, with one to three days suggested as an operational range.

There is no mandatory universal setting. RFC 8767 says serve-stale is a local operation and does not require identical variables between deployments. That flexibility makes the feature deployable, but it also means that two correct resolvers can make different availability and freshness decisions for the same name at the same moment.

The refresh result matters as much as the timer. An authoritative NoError or NXDomain response with the Authoritative Answer bit set refreshes the data and replaces the older state. Other response codes normally do not assert what now exists at the name, so they should be treated as failures to refresh and leave the previous cache state intact. A SERVFAIL is therefore not evidence that an old address remains correct; it is evidence that the resolver has not obtained a useful current answer.

Failure caching is related but different. RFC 9520 requires resolvers to cache resolution failures for at least one second and no longer than five minutes, so matching client queries do not create repeated upstream traffic while the failure entry is alive. That cache records unsuccessful resolution work. Serve-stale uses an expired answer record. One suppresses a retry storm; the other gives the client old data instead of the failure. Conflating them would hide both the source of continuity and the length of the freshness exception.

RFC 8914 gives capable resolvers and clients a diagnostic vocabulary. Extended DNS Error code 3 identifies a Stale Answer, and code 19 identifies a Stale NXDOMAIN Answer. The signal is useful for telemetry, but its authority is limited. EDE is unauthenticated unless the transaction is protected, and the standard says diagnostic content must not alter DNS protocol processing. A label saying “stale” explains what the resolver did; it does not prove that the data is safe or that a client consented to the policy.

The cost is not symmetrical across records. An old address may preserve an unchanged service. An old CNAME may preserve a dependency that was deliberately removed. RFC 8767 warns that expired signatures can produce DNSSEC validation failures and that stale NSEC or NSEC3 records may delay newly published TLSA or DS records. It also notes that an attacker able to disrupt authoritative reachability could try to keep old cached information alive for longer.

Those are protocol risks, not evidence that a named operator has suffered them. The source set does not establish adoption, configuration, outage reduction or harm for any particular resolver fleet. It establishes the decision surface: what may be retained, which refresh result ends the exception, which timers allocate the risk, and which diagnostics can reveal the choice.

Sources