Extended DNS Errors: the server says why

$ dig +https @1.1.1.1 +dnssec dnssec-failed.org A

What an EDE is#

An EDE is an EDNS(0) option, option code 15, carried in the OPT record of a response. Inside it are a two-byte INFO-CODE and an optional UTF-8 EXTRA-TEXT string (RFC 8914 section 2). That is the whole format.

It does not change the rcode. SERVFAIL stays SERVFAIL and NOERROR stays NOERROR; the EDE sits beside the rcode and explains it. That matters for the codes that ride a successful answer: EDE 3 (Stale Answer) and EDE 29 (Synthesized) both arrive on a NOERROR you were happy with, and both are telling you the answer did not come from where you assumed.

One response can carry several. A resolver that cached someone else's failure often sends EDE 13 (Cached Error) wrapped around the original validation code, so read every line, not the first one.

EXTRA-TEXT is optional and free-form. When a server sends it you get a sentence; when it does not, you get a bare number and a name. Both are valid.

The code table#

Codes 0 to 24 are defined in RFC 8914 itself. Codes 25 and above were registered afterwards, several of them from drafts and vendor pull requests rather than finished RFCs, so the IANA extended DNS error codes registry is the live list. As of 2026-09-23 it assigns through 35; 36 onward is unassigned.

Gotchas#

Resolvers differ in which code they send for the same break. Cloudflare (1.1.1.1) reports EDE 9 for dnssec-failed.org in the capture above (2026-09-14), and still did over its DoH JSON API on 2026-09-23 at 16:32Z. Quad9 (9.9.9.9), same zone, over DoH from this vantage on 2026-09-23:

$ dig +https @9.9.9.9 +dnssec dnssec-failed.org A
; EDE: 7 (Signature Expired)

EDE 7, no EXTRA-TEXT. Cloudflare stopped at the missing key; Quad9 walked further and hit a dead signature first. An EDE reports the first thing that resolver tripped over, so it is evidence about one validator's path, not a verdict on the zone.

When there is no EDE to read#

The absence of an EDE is not the absence of a cause. These are the reasons a real failure comes back bare:

• The resolver does not send them. EDE is optional. Plenty of ISP and appliance resolvers still answer SERVFAIL and nothing else.
• The query carried no EDNS. No OPT going out, no OPT coming back. dig +noedns proves it in one line, below.
• Your dig is too old to print it. BIND dig began printing the EDE: line at 9.16.4 (#5408). Older builds receive the option and say nothing about it.
• nslookup cannot show it. It has no EDNS display at all. Neither does dig +short, which prints nothing whatsoever on a failure.
• Something on the path answered instead. An intercepting box on port 53 writes its own reply, and its reply has no reason to carry anyone else's EDE. Query over DoH or DoT when you need the resolver's own words (the encrypted transports).
• The tool path has nowhere to put it. A JSON API loses whatever its schema has no field for. Cloudflare's DoH JSON parks the string in Comment, and a client that ignores Comment shows you a bare Status.
• It came from an authoritative server. Most EDEs you meet are minted by a validating recursive resolver, because that is where validation happens. An authoritative server has less to report.

Losing the OPT is the one you can demonstrate on demand. Same resolver, same broken zone, EDNS switched off:

dig +https @1.1.1.1 +noedns dnssec-failed.org A

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20304
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

ADDITIONAL: 0. No OPT record, so no option 15, so no reason. The failure is identical and the explanation is gone.

Reading one from the command line#

dig prints the EDE whenever the response carries the option, with no flag to turn the display on or off: +ede and +noede are rejected as invalid options (verified on DiG 9.20.18). The only relevant switch is +noedns, which removes the OPT from the query and takes the answer's EDE with it. +https sends the query over DoH (RFC 8484) so that nothing on your local port-53 path can answer in Cloudflare's place; it needs BIND dig 9.18 or newer. The capture at the top of this page is exactly that command; drop +https once you trust your own path.

kdig from the Knot utilities prints the same option, quoting the EXTRA-TEXT instead of bracketing it:

kdig +https @1.1.1.1 +dnssec dnssec-failed.org A

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for dnssec-failed.org.'

When the local dig is too old to print the line, ask over DoH JSON and read Comment:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=dnssec-failed.org&type=A'

{"Status":2,"AD":false,
 "Comment":["EDE(9): DNSKEY Missing no SEP matching the DS found for dnssec-failed.org."]}

Status 2 is SERVFAIL. The Comment array is where Cloudflare puts the EDE string, code and name and text run together into one line.

See also#

• What does SERVFAIL mean?: the rcode these codes are explaining, and the five causes told apart one dig at a time
• DNSSEC troubleshooting: what to do once the EDE has named the break, with the triage flow and the operational checklist
• DNSSEC, signed and validated: how the trust chain is built, so EDE 9 and EDE 10 mean something concrete
• The DNSSEC chain, drawn: the same broken zone as a picture, with one verdict line
• The isitdns dig tool: the manual for the site's dig widget, including what it can and cannot see
• dig flags: +dnssec, +cd, +noedns and every other switch used here
• Glossary and RFC index: the one-line definition, and RFC 8914 in the shelf