Summary

  • RFC 8914 adds one or more Extended DNS Error options to a DNS response. Each carries a 16-bit INFO-CODE and optional UTF-8 text, but it remains supplemental diagnostic information: applications must keep processing the base RCODE under its own rules.
  • EDE is not automatically authenticated or end to end. A forwarder may drop an upstream EDE or create a new one, a protected client hop does not make the sender truthful, and multiple codes can describe different observations in one response.
  • Safe automation records the original packet, transport, resolver identity, code order, text bytes, validation trace, cache and policy state, client retry and final outcome. It uses the label to choose an investigation, never as permission to disable DNSSEC or trust a substituted answer.

One failure, two explanations

A payment application asks two enterprise resolvers for the same signed name. Both return SERVFAIL. The first adds EDE 6, DNSSEC Bogus, with text saying that no current signature validated. The second adds EDE 22, No Reachable Authority, after its upstream attempts time out. The application sees a richer answer than the old five-bit RCODE alone could provide. Its recovery controller now wants to act.

If it treats the first label as permission to retry through a non-validating public resolver, it may obtain the very data the validating resolver refused. If it treats the second as proof of a global authoritative outage, it may page the wrong organization or reroute traffic unnecessarily. If a forwarder recreated either option, the apparent speaker may not even be the component that observed the underlying condition.

The improvement is real: the two failures should not enter the same incident queue. The limit is equally real: an explanation is an assertion made at a particular point in the resolution chain. It acquires operational authority only after the organization connects it to independent evidence and a bounded rule.

A supplemental field does not become the verdict

RFC 8914 assigns EDNS option code 15 to Extended DNS Error. The payload starts with a 16-bit INFO-CODE in network byte order. Any remaining bytes are optional UTF-8 EXTRA-TEXT intended for people, not automated parsing. Its length comes from the EDNS option length; a receiver cannot assume null termination.

EDE may accompany SERVFAIL, NXDOMAIN, REFUSED, NOERROR or another RCODE. A sender may include several EDE options, and a receiver must accept them even if it chooses not to act. Some code and RCODE combinations may be odd. The specification deliberately refuses to make the extra field override the base protocol: applications must continue to follow the rules attached to the RCODE.

That division is the protocol's most important governance boundary. An EDE code can say why a resolver reached its result. It cannot silently change a failure into success, mark insecure data secure, or turn a policy rewrite into authoritative data. An incident platform that lets the explanation drive a new protocol conclusion has created authority outside the wire contract.

EDE is also the first thing that should lose space. If the message would exceed the requestor's advertised UDP payload, the server should drop EDE before other data and set TC. Long text is discouraged. Absence therefore proves little: the sender may not implement EDE, may have declined to expose it, a forwarder may have dropped it, or packet sizing may have removed it.

The speaker can change at every forwarder

DNS resolution is rarely one unbroken conversation between application and authoritative server. A stub may speak to a local resolver, which forwards to a security service, which performs recursion or asks another forwarder. RFC 8914 permits a resolver or forwarder to discard received EDE information or construct new EDE options for the client.

When information is passed or recreated, the source should be attributed in EXTRA-TEXT because the client-visible option appears to come from the last sender. That recommendation helps people, but free text is not a cryptographic provenance envelope. Evidence must keep separate fields for the component that observed the error, selected the code, wrote the text and transmitted the final packet.

A TLS, HTTPS or QUIC connection can protect the client-to-resolver hop. It does not prove that the resolver's diagnosis is correct. A malicious authenticated resolver can lie; a well-run resolver can misclassify; an upstream observation can be lost in translation. RFC 8914 calls EDE unauthenticated unless the transaction is protected and still requires the content to remain diagnostic rather than alter DNS processing.

The useful security claim is consequently narrow. Protected transport can bind a message to a peer and prevent some interference on that hop. DNSSEC can authenticate DNS data under its own chain. Neither mechanism turns a resolver's operational explanation into an unquestionable account of cause or responsibility.

A registered number is vocabulary, not certification

RFC 8914 initially defined codes 0 through 24: DNSSEC failure details, stale and cached answers, filtering and prohibition, readiness, authority reachability, network error and invalid data among them. IANA maintains the live registry. The public range 0–49151 uses First Come First Served, while 49152–65535 is Private Use.

By August 2026, the registry extended beyond the original set and cited standards, drafts and implementation references of different maturity. This is the registry working as designed: independent software needs numbers that do not collide. But registration answers only “which numeric label is this?” It does not answer whether the event happened, whether the code was appropriate, whether every implementation agrees on the same operational nuance, or whether a client should automate a consequential response.

Private Use adds another boundary. A code may have coherent meaning inside one controlled fleet and be opaque outside it. Collectors must retain the emitting resolver, software version and registry snapshot rather than flatten every numeric value into a timeless global category.

RFC 9606 makes capability visible through the RESINFO record. Its optional exterr key can list codes a resolver says it may return. A client can refresh information when observed behavior and the advertised list disagree. Persistent mismatch makes the capability statement inaccurate. Even an encrypted resolver can publish a false capability claim, so selection remains local policy supported by authentication, validation and reputation—not registry presence alone.

Transparency can create a dangerous fallback

The motivating case for EDE is DNSSEC. A stub that receives only SERVFAIL may ask another resolver. If the second resolver does not validate, the user can receive data the first resolver rejected as bogus. A precise error can stop that blind fallback and direct repair to an expired signature, missing DNSKEY or unsupported algorithm.

The same precision can be misused. An automation may decide that DNSSEC Bogus means validation is the problem and temporarily turn it off. That is exactly the wrong inference: validation may be the control preventing a forged answer from becoming usable. The correct action is to preserve the failure, verify the validation trace, compare independent validating resolvers, inspect the relevant DS, DNSKEY, RRSIG, NSEC or clock evidence, and only then repair the zone or local trust state.

Policy codes require similar discipline. BIND can attach selected EDE labels to responses modified by a Response Policy Zone. The code can truthfully describe a local filtering act without saying that the authoritative owner produced the answer or that the policy is legally or technically correct. Blocked, Censored, Filtered, Prohibited and Forged Answer are not interchangeable moral verdicts. They are operational statements whose policy owner, rule version, trigger and result must be retained.

Unbound exposes separate controls for EDE, serving expired data with Stale Answer and DNS Error Reporting. PowerDNS documents general extended resolution errors and a diagnostic-only Negative Trust Anchor code that does not itself change validation or the AD bit. These implementation differences show why “supports EDE” is not an adequate control inventory.

Free text has less authority than the code

EXTRA-TEXT is deliberately for human consumption. It may contain no text, and operators are warned not to include private information such as account numbers. A policy error can reveal that a domain appears on a blocklist. A descriptive validator message can expose internal software, clock or trust configuration. Forwarding can repeat the disclosure beyond the place where it was created.

A console must therefore escape text, cap its bytes and lines, preserve the raw form under restricted access, and never execute embedded markup, links, shell-like fragments or structured-looking instructions. Localization belongs in the trusted UI around the code, not in an assumption that arbitrary upstream text is safe or written in the reader's language.

Logging policy should separate a stable numeric field from free text. The code supports aggregation; the text supports bounded diagnosis. Neither belongs in public telemetry by default when the query name or policy rationale is sensitive.

Reporting the error creates another control loop

RFC 9567 builds an optional feedback path on EDE. An authoritative server can advertise a Report-Channel. A validating resolver can encode the failed QTYPE, QNAME and EDE code into a new DNS query to a monitoring agent. The mechanism can reveal expired signatures or other failures to the operator that can repair them.

This is not a free escalation channel. Resolving the report can itself fail and generate another report, so implementations must cap depth or expense. Reporting is not mutually authenticated by the mechanism. TCP or DNS Cookies can raise confidence in source reachability, while QNAME minimisation reduces disclosure; none identifies the legal or organizational principal behind the resolver.

The monitoring agent should treat a report as evidence of one resolver's observation. It correlates the report with its own zone versions, signing logs, authoritative nodes and external probes. Automation may open an incident or collect proof. It should not rotate keys, publish a zone or blame an upstream solely because a specially shaped query arrived.

A thin common language, local consequence

EDE fits Heng Lu's Minimum Initial Specification when read narrowly. The common layer defines option 15, field lengths, a registry index and the invariant that base RCODE processing remains intact. It does not define one global incident policy, user message, filtering legitimacy or fallback decision.

Localized Future Decision belongs to the participants running code. A resolver decides which observations it can label; a forwarder decides whether to preserve or restate them; a client decides whether to display a diagnosis; an operator decides which additional evidence is required before action. Those choices can vary without corrupting the wire vocabulary.

Voluntary Adoption is measured at the packet and behavior boundary. Registry entries and RFC publication are symbolic coordination. Emitting the correct bytes is protocol state. Preserving source attribution and showing a safe local message is implementation. Refusing insecure fallback and repairing the actual failure are consequence.

Running-Code Primacy asks the organization to prove the chain. The packet carried code X from peer Y over transport Z; resolver logs show observation A; independent validation confirms cause B; policy C permitted action D; later packets show recovery E. Without that chain, the dashboard has a label, not authority.

Sources