Skip to content

CONCEPT Cited by 1 source

Extended DNS Errors

Definition

Extended DNS Errors (EDE), defined in RFC 8914, is a supplementary error channel for DNS responses. When a resolver returns a failure (typically SERVFAIL), it can attach an EDE code that gives the client a structured, machine-readable reason for the failure — distinct from the opaque RCODE.

The canonical framing:

  • RCODE (the primary error channel) is 4 bits, low-cardinality (NOERROR, NXDOMAIN, SERVFAIL, REFUSED, etc.), and historically cannot distinguish "DNSSEC validation failed" from "authoritative server unreachable" from "internal resolver bug".
  • EDE (the supplementary error channel) is a 16-bit INFO-CODE + optional EXTRA-TEXT string, high-cardinality, designed exactly to disambiguate RCODE opacity.

Canonical EDE codes

A partial list relevant to DNSSEC incidents:

INFO-CODE Meaning
0 Other
1 Unsupported DNSKEY Algorithm
2 Unsupported DS Digest Type
3 Stale Answer
4 Forged Answer
6 DNSSEC Bogus
7 Signature Expired
8 Signature Not Yet Valid
9 DNSKEY Missing
10 RRSIGs Missing
11 No Zone Key Bit Set
12 NSEC Missing
13 Cached Error
14 Not Ready
15 Blocked
16 Censored
17 Filtered
18 Prohibited
19 Stale NXDOMAIN Answer
20 Not Authoritative
21 Not Supported
22 No Reachable Authority

The EXTRA-TEXT field can carry human-readable diagnostic information:

EDE: 6 (DNSSEC Bogus): RRSIG with malformed signature found for
example.de/nsec3 (keytag=33834)

This tells the operator exactly which RRSIG broke and on which record type, without requiring packet captures or resolver-internal log access.

EDE 6 vs EDE 22 during the 2026-05-05 .de break

The 2026-05-06 Cloudflare DNSSEC .de outage post surfaces a self-disclosed bug in 1.1.1.1's EDE propagation:

"Some resolvers returned EDE 6 (DNSSEC Bogus) with a descriptive message pointing directly at the broken signature. This is the correct behavior: 'EDE: 6 (DNSSEC Bogus): RRSIG with malformed signature found for example.de/nsec3 (keytag=33834)'"

"1.1.1.1, on the other hand, returned EDE 22 (No Reachable Authority), which on the surface suggests a connectivity problem with the upstream nameservers rather than a DNSSEC validation failure."

The difference matters operationally: a troubleshooter seeing EDE 22 checks upstream nameserver connectivity (wrong direction); a troubleshooter seeing EDE 6 immediately knows it's a DNSSEC issue and that the RCODE-level SERVFAIL is being correctly produced by a working validator detecting upstream-signed data that cannot be verified.

Root cause of the wrong EDE

Cloudflare disclosed the propagation bug:

"The cause is a bug in how we propagate DNSSEC EDE codes up from our trust chain verifier. When the verifier detects a bogus signature it creates the DNSSEC Bogus EDE code, but this is never inserted into the response. Instead, the outer layer of the resolver sees a problem with recursive resolution with no error code and falls back to reporting 'No Reachable Authority.' This obscures the underlying DNSSEC cause."

Commitment to fix disclosed in the same post:

"We're aware that this isn't helpful for 1.1.1.1 users and will be fixing our responses to surface the DNSSEC errors."

Why EDE matters — redundant error signalling

See concepts/redundant-error-signalling for the general framing. When the primary error channel (RCODE) is opaque, the supplementary channel (EDE) becomes load-bearing. But the supplementary channel is only useful if it actually carries the right signal — a propagation bug that rewrites EDE 6 into EDE 22 undoes the entire rationale for having the supplementary channel in the first place.

The failure mode generalises beyond DNS:

  • HTTP status codes + problem details (RFC 7807) — status says 400, problem-details says why.
  • gRPC status codes + error messages — NOT_FOUND + "user alias=xyz not in directory".
  • Syscall errno + supplementary struct — EAGAIN + epoll context.

Every layered-error-channel design has the same property: the supplementary channel must be threaded end-to-end. An internal component that correctly identifies the sub-class must propagate it; a shim or outer layer that drops it (or rewrites it to a generic fallback) defeats the design.

EDE as a self-disclosure surface

The 2026-05-05 incident made a latent EDE-propagation bug visible at production altitude. The bug had presumably been present for a long time; it only became operationally interesting when a TLD-wide DNSSEC break generated enough SERVFAILs that external users noticed the wrong EDE code.

This is canonical for error-channel bugs: they stay hidden until an event generates enough volume of the error class to make the mislabelling visible. Incident post-mortems are a natural forcing function for error-channel hygiene audits.

Seen in

Last updated · 451 distilled / 1,324 read