Summary

  • DNS's ordinary response codes compress many unlike failures into the same outcome. RFC 8914 placed a registered INFO-CODE and optional human EXTRA-TEXT in EDNS option 15 so a server could describe the cause without replacing the RCODE.
  • EDE can accompany SERVFAIL, NXDOMAIN, REFUSED or even NOERROR, and several EDE options may coexist. Applications must still process the ordinary RCODE according to its own specification; diagnostics cannot promote stale, forged or unauthenticated context into protocol authority.
  • The new visibility creates its own custody problem. Forwarders decide whether to relay or recreate an explanation, oversized replies discard EDE before essential data, free text can leak policy or account information, and an attacker can forge an unprotected diagnosis.

At 02:13, an operator sees a failed name lookup. The recursive resolver logged SERVFAIL. She checks the zone's authoritative servers, network paths and DNSSEC signatures because the five-bit operational question—repair transport or repair signed data—has been compressed into one result.

At 02:16, another name produces the same code. This time every authority answers, but a signature has expired. Retrying a different validating resolver should produce the same refusal. Retrying a resolver that does not validate may return an address, but that apparent recovery has crossed a security boundary rather than repaired the zone.

The two packets agree about the result: no usable answer is being returned. They disagree about the cause, the safe next test and the institution able to fix it. Classic DNS had space for the result but little room for that distinction.

A small result field carried too many histories

RFC 1035 defined the familiar response header. Its RCODE values describe broad outcomes such as no error, format error, server failure, nonexistent domain, unsupported operation and refusal. That compact grammar is valuable because every resolver can make the same first decision without knowing the server's internal architecture.

Compression also erases evidence. A server can fail because it is still loading a zone, because every authoritative destination is unreachable, because cached failure state remains active, because a DNSSEC proof is incomplete or because a policy forbids the answer. SERVFAIL does not encode those causal branches. REFUSED likewise does not say whether the server lacks authority, rejects this client or applies a filtering rule.

Applications filled the gap with guesses. A stub could ask its next configured resolver after a validation-related SERVFAIL. If that next resolver did not validate DNSSEC, the application might receive data the first resolver had correctly rejected. Reachability improved only because the client discarded the security evidence it could not see.

The defect was not that RCODE was wrong. SERVFAIL remained the correct interoperable outcome. The missing layer was an explanation that could guide diagnosis without changing the meaning of the result.

EDNS supplied a side channel, not a new answer

RFC 6891 had already created the OPT pseudo-record and a registry of options. OPT is carried in DNS messages but is not ordinary zone data. It provides a bounded extension surface for capabilities and metadata without making every older field grow.

Published in 2020, RFC 8914 assigned EDNS option 15 to Extended DNS Error. The option's payload begins with a 16-bit INFO-CODE. Any remaining octets form optional UTF-8 EXTRA-TEXT.

The split is deliberate. The numeric code indexes a registry and can support stable classification. The free text can say that a particular key expired or name the upstream source of a failure, but it is intended for human consumption. A program must not parse a sentence as if it were a second protocol.

The option can appear with SERVFAIL, NXDOMAIN, REFUSED, NOERROR and other response codes when the query carried an OPT record. More than one EDE may appear in one reply. A receiver must be able to accept them, yet it need not act on them all.

Most importantly, EDE does not alter RCODE processing. An application receiving NOERROR plus Stale Answer still has an answer whose expiry history matters. A client receiving SERVFAIL plus DNSSEC Bogus still has a failure. The explanation narrows the investigation; it does not reopen the result.

One code separated validation failure from uncertainty

The DNSSEC codes show why precision mattered. RFC 4035 distinguishes Bogus from Indeterminate. Bogus data is data for which a trust chain should be constructible but cannot be validated. The cause might be attack, configuration error or corruption. Indeterminate data is different: the resolver cannot determine whether signing should apply because it cannot obtain the necessary DNSSEC records.

RFC 8914 gave those states separate diagnostic numbers. It also supplied codes for unsupported DNSKEY algorithms, unsupported DS digest types, expired signatures, signatures not yet valid, missing DNSKEY or RRSIG records, an unset zone-key bit and missing NSEC evidence.

That vocabulary does not prove blame. DNSSEC Bogus is not a verdict that an attacker owns the zone. It says which validation state the resolver reached. The remedy may belong to a zone operator, a registrar, a parent zone, a clock source, a software implementation or a path that lost required records.

The difference changes safe recovery. Another validating resolver can test whether the condition is local. A non-validating answer cannot disprove the failure; it merely declines the same proof requirement. EDE makes that choice visible enough for a client or operator to avoid treating weaker verification as successful repair.

Success could carry a warning about time

EDE was designed for more than failed responses. A recursive resolver may be unable to refresh data before its normal expiry yet decide that an older cached answer is preferable to no answer. RFC 8767 bounds that resilience mechanism. EDE code 3 labels a stale positive answer, while code 19 labels stale NXDOMAIN.

The ordinary result can therefore be NOERROR and still carry a warning. That is not a contradiction. RCODE describes the current response class; EDE describes the provenance or condition under which it was produced. The record did not become fresh merely because the resolver chose continuity.

The same separation applies to code 4, Forged Answer. RFC 8914 uses it when policy caused an answer to be altered and an answer is still returned. If policy instead prevents an answer, different codes describe who imposed the boundary: Blocked for the resolver operator's internal security policy, Censored for an external requirement and Filtered for filtering requested by the client.

These labels are diagnostic assertions made by the responding system. They can illuminate institutional control, but they do not authenticate a court order, prove a threat classification or establish that every intermediary used the terms correctly.

A cached failure acquired provenance

Answers are not the only DNS state that can be cached. Resolution failures can be retained briefly so that every new client does not force the resolver to repeat an expensive chain of unsuccessful work. RFC 9520 makes failure caching explicit and bounded.

EDE code 13, Cached Error, tells the client that the returned SERVFAIL came from such cached state. It does not turn that failure into authoritative zone data. It tells the operator that immediate repetition at the same resolver may exercise the cache rather than the failing upstream path.

This is a subtle but useful distinction. A fresh failure and a cached failure may carry identical RCODEs, yet only one necessarily represents a new resolution attempt. Observability without that provenance can make a retry storm look like repeated independent evidence.

Forwarding made the speaker ambiguous

A stub resolver often talks to a local recursive resolver, which may forward to another resolver before contacting authority. An EDE observed at the edge can therefore have several possible authors.

RFC 8914 leaves forwarding policy local. A resolver may suppress received EDE, pass it onward or construct a new option conveying the information. If it forwards the meaning, it should identify the source in EXTRA-TEXT, because the client otherwise sees the option as if its immediate resolver had originated it.

The explanation thus has a custody chain weaker than the DNS answer's familiar sections. A numeric code can survive while its source becomes ambiguous. Free text can restore attribution, but free text is neither machine grammar nor automatically authenticated.

Several EDE options can preserve layered causes: an upstream validation defect, a cached local failure and a downstream policy decision need not be collapsed into one number. The receiver must still decide which layer it trusts and which actor can repair it.

Supplemental evidence is first to leave a crowded packet

DNS still has size limits. An EDE with a long human explanation can push a UDP response past the payload size the requester advertised. RFC 8914 tells servers to drop EDE options before dropping other response data and to set the truncation bit when doing so.

That priority expresses the contract exactly. The diagnostic is useful, but the answer and its proof remain more important. A missing EDE after truncation is not evidence that the server lacked a diagnosis. Long prose can destroy the very visibility it was meant to provide by forcing fallback to TCP or disappearing at the size boundary.

Operators therefore need concise codes, bounded text and logs that record whether an EDE was generated, forwarded, replaced or omitted. Packet capture alone may observe the final absence but not the earlier decision.

The explanation was not authenticated by being specific

Specific language feels authoritative. A reply saying “signature expired” or “blocked under external requirement” can appear more trustworthy than an opaque failure. The wire does not grant that trust.

RFC 8914 warns that EDE is unauthenticated unless the DNS transaction is protected by an authentication or secure transport mechanism. An on-path attacker or malicious resolver capable of forging an EDE may also be able to forge an RCODE or ordinary answer. EDE must remain diagnostic and must not change DNS protocol processing.

The text also creates privacy risk. It can expose an account number, an internal upstream, a blocklist decision or the existence of a policy the client could not otherwise observe. More explanation is not automatically more accountability. The useful record says enough to select the next test and responsible control surface without disclosing unrelated private state.

The IANA DNS Parameters registry records option 15 and the evolving INFO-CODE assignments. It proves that identifiers and references are coordinated. It does not prove that resolvers emit them, forward them faithfully, protect their transport, show them to users or classify failures correctly.

Extended DNS Errors solved a narrow historical problem with unusual discipline. DNS needed more expressive failure evidence, but a convenient explanation could not be allowed to become a second answer. The RCODE kept authority over processing. The EDE carried context. Their separation made failure easier to repair without making diagnostic confidence stronger than the channel that delivered it.