Extended DNS Errors
Extracted elements (24)
EDE deliberately does not change RCODE processing — it is purely supplemental diagnostic information. This preserves backward compatibility: receivers that do not understand EDE continue to process RCODEs normally.
EDE was created because DNS error signals are very limited: SERVFAIL is overloaded to signal many error types, causing stub resolvers that receive a DNSSEC validation failure to silently retry with a non-validating resolver, bypassing DNSSEC protections entirely (~11% of clients exhibit this behavior).
Some EDE code and RCODE combinations may appear nonsensical (e.g., resolver-specific EDE codes received from authoritative servers); systems MUST NOT assume any particular combination is meaningful and MUST be able to accept EDE in all messages including NOERROR.
Whether or how a resolver or forwarder passes EDE information to its original client is implementation dependent; implementations MAY choose not to forward EDE or MAY create new EDE options conveying equivalent information.
EDE content MUST NOT alter DNS protocol processing. Applications MUST continue to follow requirements from applicable specifications on how to process RCODEs no matter what EDE values are also received.
Receivers MUST be able to accept EDE codes and EXTRA-TEXT in all messages, including those with a NOERROR RCODE, and MUST be able to accept multiple EDE options in a DNS message.
Systems interpreting extended error codes MUST NOT assume that a combination of EDE code and RCODE will make sense, since some combinations may be nonsensical.
The EXTRA-TEXT field length MUST be derived from the OPTION-LENGTH field; EDE text may be null terminated but MUST NOT be assumed to be.
When a response grows beyond the requestor's UDP payload size, servers SHOULD truncate messages by dropping EDE options before dropping other data from packets, and implementations SHOULD set the truncation bit when doing so.
Care should be taken not to include private information in the EXTRA-TEXT field that an observer would not otherwise have access to, such as account numbers. The EXTRA-TEXT field is intended for human consumption and may be visible in transit.
EDE code 0 (Other) is used when the error does not match known extended error codes; implementations SHOULD include EXTRA-TEXT to augment this code.
EDE code 20 (Not Authoritative): an authoritative server receiving a query with RD bit clear, or a resolver receiving a query with RD bit clear, SHOULD include this EDE code in the REFUSED response.
EDE code 3 (Stale Answer) indicates the resolver answered with previously cached data due to inability to resolve within time limits; EDE code 19 (Stale NXDOMAIN Answer) covers the same scenario for NXDOMAIN responses.
EDE code 4 (Forged Answer) is used when an answer was forged for policy reasons (e.g., malware filtering) but an answer is still provided; Blocked/Censored/Filtered codes are used when failure codes are returned instead.
EDE codes 1 and 2 signal DNSSEC validation failures due to unsupported DNSKEY algorithm or unsupported DS Digest Type respectively, allowing stubs to distinguish algorithm support gaps from other SERVFAIL causes.
EDE codes 15 (Blocked), 16 (Censored), and 17 (Filtered) distinguish operator-imposed blocks from externally-required censorship and client-requested filtering, all returning non-NOERROR responses.
EDE codes 6, 7, 8, 9, 10, 11, and 12 cover specific DNSSEC validation failure subcategories: Bogus, Signature Expired, Signature Not Yet Valid, DNSKEY Missing, RRSIGs Missing, No Zone Key Bit Set, and NSEC Missing.
The EDE option is carried as an EDNS0 option (RFC 6891) and can be included in any DNS response (SERVFAIL, NXDOMAIN, REFUSED, NOERROR, etc.) to a query that includes an OPT pseudo-RR. Senders MAY include more than one EDE option per message.
When a resolver or forwarder passes along EDE information to its original client, the source of the error SHOULD be attributed in the EXTRA-TEXT field, since the EDNS0 option will appear to have come from the forwarding resolver.
IANA assigned EDNS0 option code 15 to 'Extended DNS Error' in the 'DNS EDNS0 Option Codes (OPT)' registry.
IANA created the 'Extended DNS Error Codes' registry with INFO-CODEs 0–49151 assigned via First Come First Served and 49152–65535 reserved for Private Use. Initial codes 0–24 are defined by this document.
EDE information is unauthenticated unless secured via TSIG, SIG(0), DNS-over-DTLS, or DoH. An attacker could insert false extended error responses; therefore EDE content must be treated only as diagnostic information and MUST NOT alter DNS protocol processing.
EDE potentially leaks additional information via DNS resolution. For example, EDE code 18 (Prohibited) may reveal that a queried name is on a blocklist, exposing policy details to observers.
The EDE EDNS0 option has four fields: OPTION-CODE (2 octets, value 15), OPTION-LENGTH (2 octets, length of payload after OPTION-LENGTH), INFO-CODE (16 bits, network MSB byte order, indexes the Extended DNS Errors registry), and EXTRA-TEXT (variable-length UTF-8 encoded text, may be zero-length).