Wiki · Concept · Last reviewed June 25, 2026

Extended DNS Errors

Extended DNS Errors are RFC 8914's EDNS mechanism for adding more specific failure information to DNS responses without changing the base DNS response code.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, EDNS, EDE, errors, filtering, observability, agents, surveillance

Definition

Extended DNS Errors, usually shortened to EDE, are defined by RFC 8914, Extended DNS Errors, published in October 2020 as an Internet Standards Track RFC. The RFC defines an extensible method for returning additional information about the cause of DNS errors.

EDE was created primarily to make SERVFAIL more informative for DNS and DNSSEC failures, but RFC 8914 allows any DNS response type to contain extended error information. The important boundary is that EDE information does not change the processing of ordinary DNS RCODEs. It adds context; it does not redefine success, refusal, or failure.

Mechanism

RFC 8914 uses Extension Mechanisms for DNS, or EDNS(0), and assigns EDNS option code 15 to the Extended DNS Error option. The option contains a 16-bit INFO-CODE that identifies the reason and a variable-length EXTRA-TEXT field that can carry additional human-readable detail.

The INFO-CODE is an index into the IANA Extended DNS Error Codes registry. RFC 8914 created the registry and supplied the initial code set, including DNSSEC-related reasons such as unsupported DNSKEY algorithm, signature expired, and DNSSEC bogus, operational reasons such as stale answer, cached error, no reachable authority, network error, and invalid data, and policy reasons such as blocked, censored, filtered, and prohibited.

The registry is extensible. RFC 8914 assigns codes 0 through 49151 by First Come First Served registration and reserves 49152 through 65535 for private use. That means resolver and tooling behavior should expect new standard codes over time rather than hard-coding the original list as complete.

Privacy Boundary

EDE is transparency about a response, not privacy by itself. It can help a client distinguish between a DNSSEC validation failure, a stale answer, an upstream network problem, a policy block, and a resolver refusing a client. It can also expose that a resolver or network intermediary is filtering, altering, or refusing a name for policy reasons.

That visibility cuts both ways. A more precise error can help users and auditors detect censorship or misconfiguration, but the EXTRA-TEXT field can also carry operator-supplied detail that applications should treat as untrusted diagnostic text. EDE should not be used as a covert channel for sensitive user, account, or investigation data.

Agent Context

Agent systems need failure reasons because automated plans often turn one DNS failure into many secondary actions. A code assistant might retry a package registry, a crawler might mark a site unavailable, a browser agent might choose a mirror, or a monitoring agent might raise an incident. With only SERVFAIL, those responses can look the same.

EDE gives agent observability a sharper signal. A DNSSEC bogus result, stale answer, censored response, prohibited client, and upstream network error call for different remediation. The governance problem is that an agent should not blindly trust EDE as authority. It should log the resolver, RCODE, EDE code, transport, and policy context, then route decisions through configured policy rather than improvised retry behavior.

Governance Use

A governed resolver deployment should record whether EDE is emitted, forwarded, suppressed, logged, exposed to applications, or shown to users. It should also record which code families trigger alerts, retries, fallback resolvers, security review, or user-facing explanations.

Filtering codes deserve particular care. If a resolver emits blocked, censored, filtered, or prohibited, the organization should document whether the source is malware protection, legal order, enterprise policy, parental control, national filtering, or resolver access control. Without that context, EDE can create a polished explanation for opaque control.

Limits

EDE is not DNSSEC, authentication, consent, anonymity, or proof that the stated reason is true. A malicious or misconfigured server can send misleading extended errors. A client that receives no EDE cannot conclude that no specific reason exists; the sender may not support the option or may choose not to include it.

EDE also does not remove the need for ordinary DNS handling. Applications still need to process RCODEs correctly, validate DNSSEC where configured, respect resolver policy, and avoid leaking sensitive diagnostic text into logs or user interfaces.

Source Discipline

Claims about the EDE option, INFO-CODE, EXTRA-TEXT, EDNS option code 15, relationship to RCODE processing, initial code meanings, and registry ranges should cite RFC 8914. Claims about current registered EDE code names should cite the IANA DNS Parameters registry. Claims about resolver accountability should cite the site's DNS privacy and observability entries rather than treating EDE as a complete governance system.

Spiralist Reading

Spiralism reads EDE as the moment infrastructure starts giving reasons. A bare failure says only that the path closed. An extended error can say whether the closure came from validation, network damage, local policy, or external command.

For agents, that distinction matters. Machines should not treat every closed door as the same event, and they should not accept every sign on the door as truth.

Sources

Return to Wiki