Summary

  • RFC 8767 permits a resolver to retain and sometimes return expired DNS data, but only as a bounded fallback after a good-faith refresh cannot obtain usable authoritative data.
  • Original TTL, maximum stale lifetime, client wait budget, returned stale TTL, DNSSEC signature validity, diagnostic signal and retry cadence are different clocks and claims.
  • David C. Lawrence's co-authorship records a contribution to a collective IETF mechanism. It does not make him, the resolver or the stale copy authoritative over the source data.

The cached answer has just crossed zero. A client is waiting. The authoritative servers do not produce a usable reply before the resolver's patience runs out. Three statements can now all be true: the answer is expired, it may still be better than an outage, and it has not become fresh again.

That third statement is the hard one. Continuity mechanisms tend to inherit the language of the service they preserve. A reply arrives, so a dashboard says DNS succeeded. The name resolves, so an application proceeds. Unless the resolver leaves a precise receipt, the exceptional use of an old copy can disappear inside an ordinary success count.

RFC 8767, written by David C. Lawrence, Warren Kumari and Puneet Sood and published as a Proposed Standard in March 2020, gives stale DNS data a bounded operational state. It does not repeal TTL. It separates the authority of the zone from the temporary ability of a recursive resolver to keep an application moving when the source path is unavailable.

Expiration does not mean the bytes vanished

RFC 1035 defines TTL as the interval for which a resource record may be cached before the source should be consulted again. RFC 2181 sharpens the resolver's duty: TTL limits cache use and a resolver must not act as though data remains current after that limit.

Implementations do not have to erase the bytes at the instant the timer reaches zero. They can retain an expired RRset internally for diagnostics or exceptional recovery. But storage and answer permission are different states. A record sitting in memory is not yet a record the resolver may return.

RFC 8767 turns that distinction into a controlled fallback. The resolver may keep expired data and use it when it cannot refresh from the authoritative source. The mechanism is valuable precisely because many authoritative failures are shorter than the operational usefulness of the last known answer. A transient routing problem, unreachable server set or local timeout need not immediately become a user-visible failure.

The exception has a boundary that is easy to miss: data originally received with TTL zero cannot enter the fallback. The publisher explicitly said not to reuse it from cache. A resolver cannot manufacture a stale lifetime for a value that was never cacheable.

The first operational receipt therefore begins before the incident: RRset, class and type, original response source, received TTL, insertion time, ordinary expiry and validation state. Without those fields, “we served the previous answer” does not prove which answer, how old it was or whether it had ever been eligible for reuse.

The authoritative path gets the first attempt

Serve-stale is not a licence to prefer a nearby old copy over a reachable source. RFC 8767 requires a good-faith recent effort to refresh. A resolver can query the authoritative path, wait for its configured client-response budget, and use stale data after the attempt fails or times out. If a recent attempt has already established the upstream failure, a following query may consult stale data immediately rather than repeat the same delay for every client.

This sequencing protects the zone owner's ability to change an answer. If a resolver returned stale data first whenever it was convenient, an emergency address change, certificate-related DNS change or service withdrawal could remain invisible even while the authoritative service was healthy. Continuity would become unaccountable substitution.

“Good faith” needs an observable definition. The record should name the upstream targets attempted, transport, start and stop time, response or failure class, retry policy and any recent-failure state reused for the decision. Timeout, SERVFAIL, network unreachability, validation failure and an authoritative negative answer are not interchangeable.

The distinction also prevents a successful stale response from being mistaken for recovery. The client received something, but the resolver has not repaired the source path. RFC 8767 requires it to keep attempting refresh. Recovery occurs only when usable authoritative data is obtained, assessed and installed as current cache state.

One answer carries several clocks

The most dangerous simplification is to speak of “the stale TTL” as though one timer controls the whole mechanism. At least six clocks matter.

The original TTL came from the authoritative data and defines ordinary freshness. RFC 8767 also discusses a cap on the received TTL used when calculating retention, suggesting seven days so an unusually large original value cannot create an unlimited stale horizon.

The maximum stale lifetime is a separate resolver policy. The RFC says it should be configurable and suggests a value on the order of one to three days. Reaching that boundary removes the answer from stale eligibility even if the bytes remain stored.

The client wait budget decides how long the resolver gives the refresh attempt before answering from the fallback. It may be measured in seconds, not days. A shorter budget improves application responsiveness but increases the chance that a slow source response loses the race.

The returned stale TTL tells the downstream client how long it may reuse this exceptional reply. RFC 8767 requires a positive value and recommends 30 seconds. That value does not reset the record's authoritative age. It limits the next cache's reuse of the fallback.

DNSSEC signatures carry their own inception and expiration times. An RRset may have passed its ordinary TTL while its signature remains temporally valid, or the signature may expire while the resolver's stale-retention window remains open. Cache policy cannot extend cryptographic time.

Finally, refresh retry has a cadence. The resolver must continue asking for current data without turning a source failure into an abusive query storm. Backoff and failure memory influence both recovery time and upstream load.

A useful record does not compress these into one duration. It preserves original expiry, stale-eligibility deadline, client decision time, reply TTL, signature interval and next refresh attempt separately.

DNSSEC can authenticate an old answer without making it current

RFC 4035 requires validating resolvers to check the DNSSEC chain and the signature validity interval. That produces a security assessment, not a freshness certificate. A stale RRset can still validate cryptographically if its signatures remain valid and the chain is available. It can also become Bogus or otherwise unusable as signatures expire or the supporting chain changes.

RFC 8767 warns that validation failures become more likely as stale data ages. It also identifies an adversarial scenario: an attacker who can keep the authoritative service unavailable may prolong the life of an older answer. That does not require forging a signature. It exploits the difference between “signed by the owner at some earlier time” and “still the owner's intended current state.”

The risk becomes acute when a consumer uses DNS to authorise an irreversible act. The RFC specifically cautions certification authorities against relying on stale resolvers for DNS-based validation. A continuity choice that is reasonable for reaching a news site may be inappropriate when issuing a certificate from a challenge whose owner tried to revoke or change the answer.

Negative answers deserve equal care. A stale positive answer can keep traffic pointed at an old service. A stale NXDOMAIN can keep a newly created name invisible. RFC 8914 gives the latter its own diagnostic code, Stale NXDOMAIN Answer, because absence is also a claim whose age matters.

The resolver receipt should therefore include Secure, Insecure, Bogus or Indeterminate handling as appropriate, signature times, negative-answer proof state and the consumer class if policy differs by use. “DNSSEC passed” must not erase “the data was expired.”

The signal is a witness, not a cure

RFC 8914, also co-authored by Lawrence, defines Extended DNS Errors. Code 3 identifies a Stale Answer; code 19 identifies a Stale NXDOMAIN Answer. A capable client, intermediary or operator can use that channel to distinguish an exceptional continuity reply from ordinary current data.

EDE does not change the DNS RCODE by itself. It does not authenticate the RRset, prove why the authoritative path failed, extend a signature or guarantee that the application saw the signal. Many clients will still consume only the ordinary answer fields.

That limitation makes EDE useful evidence rather than absolution. A resolver can count stale responses by reason and age, and an instrumented client can decide whether a particular operation should proceed. But the resolver must retain its own decision record even if no downstream software understands the option.

An incident report should join the EDE code to the refresh attempt and cache object that produced it. A raw count of code 3 events cannot show whether the resolver made a good-faith refresh, stayed inside the configured maximum, returned a short TTL or later recovered.

Running code reveals policy choices the RFC leaves local

RFC 8767 describes an early patch for BIND 9.7.0, production use reported by Akamai from 2011, and later support in BIND 9.12 and newer, Unbound and Knot Resolver. That history matters because the mechanism grew from operational experience, not only an abstract availability argument.

It does not prove uniform behavior. Current Unbound documentation says RFC 8767 operation is enabled by default from version 1.23.0. It describes using an expired answer after a client has waited 1.8 seconds or instead of returning SERVFAIL, a one-day default maximum stale lifetime, a 30-second reply TTL and continued resolution attempts.

Those values are a current implementation profile. They are not an IETF mandate and do not describe every Unbound deployment, other software or earlier versions. Operators can change them. Product upgrades can change defaults. A feature name cannot prove the active runtime choice.

This is where running-code primacy becomes practical. A control review should capture software and version, effective settings, per-query state transition and resulting wire answer. It should test a healthy authoritative path, a timeout, SERVFAIL, validation failure, recovery before the stale deadline, recovery after it and a TTL-zero record. Documentation describes possible behavior; the trace shows which behavior occurred.

Lawrence's role is contribution, not delegated authority

The IETF Datatracker records David C. Lawrence under the handle “tale” and lists RFCs 3425, 7871, 8767 and 8914. Its current record also lists him as an Adaptive DNS Discovery working-group chair, the IETF liaison to the ICANN Board and a reviewer in DNS- and Internet-related directorates.

ICANN's current Board page identifies David Lawrence as the IETF's non-voting liaison from 14 November 2024. Its biography traces work through RPI and Usenet, UUNET, ISC's BIND rewrite, Nominum, thirteen years at Akamai, selection as a DNSSEC Root Key Trusted Community Representative in 2010, past DNS-OARC Board service and current CVFiber Board service.

These records locate long participation in DNS implementation, standards and institutional liaison. They are time-bounded and do not make Lawrence the sole inventor of serve-stale. RFC 8767 has three authors and reflects wider implementer experience and IETF consensus. His liaison role does not give him a vote on the ICANN Board or control over an operator's resolver settings.

The same authority discipline applies to the cached answer. A useful copy can perform a temporary function without becoming the source. A named contributor can help define a collective mechanism without becoming its operator.

Build a stale-answer receipt that can prove recovery

The minimum joined record begins with the cache object: owner name, type, class, original response source, original TTL, insertion and expiry times, response data hash and DNSSEC state. It then records the recent refresh attempt: target servers, transport, timing, response or failure classification and whether a prior failure justified immediate fallback.

Next come the decision fields: configured maximum stale lifetime, calculated eligibility deadline, age at answer, client wait budget, returned TTL, EDE code and policy exception. A separate refresh record shows the next attempt and backoff.

The closing receipt is authoritative recovery: first usable fresh response, validation result, new data hash, time installed, stale entries retired and application-visible outcome. If the new authoritative answer differs, the record must preserve the transition rather than silently overwrite the evidence that clients received the old value.

This is the ledger-versus-gatekeeper distinction in a cache. The resolver can keep the service available without claiming ownership of the name. The control succeeds when provenance, age and source recovery remain visible. It fails when an old answer becomes an unexplained permanent substitute simply because clients continued to receive replies.

The durable rule is not “expired means useless” or “availability wins.” It is narrower: an expired answer may carry continuity only while every boundary that keeps it subordinate to authority remains provable.

Sources