Treat EDE 33 as resolver diagnostic evidence of a temporary DNSSEC exception—not proof of an attack—and preserve it with the resolver, response code, and DNSSEC flags.
Update — August 12, 2026: EDE 33 is described in an active IETF Internet-Draft. That matters: it is a useful operational signal, but teams should not present a draft allocation as a permanent protocol guarantee or rely on it to change DNS processing automatically.
A DNS answer can succeed and still contain a security-relevant diagnostic. Cloudflare’s 1.1.1.1 resolver returns Extended DNS Error (EDE) 33 when it applies a Negative Trust Anchor (NTA), making a temporary DNSSEC validation exception visible to clients and monitoring tools.
Cloudflare first used the signal during a July failure involving Albania’s `.al` top-level domain. The incident is a reminder that a success-only availability check can miss the reason a name resolved.
What broke in .al
During a DNSSEC key rollover, the `.al` nameservers stopped serving the key referenced by the delegation signer record in the root. Validating resolvers could no longer build a chain of trust and returned errors for domains beneath the TLD.
Cloudflare temporarily installed an NTA, instructing its validating resolver to treat the affected zone as unsigned while the registry corrected the delegation. That restored availability by suspending cryptographic validation for the zone. An NTA is a resolver operator’s local, time-bounded exception; it is not a statement that DNSSEC has been fixed globally.
EDE 33 explains the response; it does not authenticate it
An EDE 33 response says that a covering NTA was in effect when that resolver generated the answer. The IETF draft classifies EDE as diagnostic: a client must not change protocol processing because it is present, and EDE 33 does not alter AD-bit handling. In the `.al` case, Cloudflare also returned EDE 9 to expose the missing-DNSKEY condition beneath the bypass.
The distinction is important for incident response. A successful answer with EDE 33 is evidence of resolution restored under a temporary exception, not evidence of full DNSSEC validation. Conversely, the absence of EDE 33 from another resolver does not prove that its policy matched 1.1.1.1’s.
Collect enough context to investigate
Check whether DNS probes, resolver libraries, and observability pipelines preserve EDNS EDE data. For each unusual result, retain the resolver identity, queried name and type, transport, response code, AD and CD flags, timestamp, and the EDE codes and text. Without that context, an alert cannot distinguish a resolver policy exception from an authoritative-DNS failure.
Alert on a new EDE 33 for a critical domain, but route it as a DNSSEC and resolver-policy investigation rather than automatically calling it an attack. Correlate it with authoritative DNS changes, registry communication, and responses from independent validating resolvers. The EDE draft also cautions that EDE data has no inherent integrity protection, so do not use it as sole security evidence across an untrusted path.
Make rollover monitoring prove the trust chain
For a DNSSEC rollover, monitor the DS and DNSKEY relationship from more than one validating resolver before retiring an old key. Test the new material over the actual delegation path, not only on the authoritative server. A green application health check cannot repair a broken chain of trust above the application domain.
Keep an escalation path for the registry or parent-zone operator and a written policy for any NTA you control: scope, owner, reason, expiration, and removal check. The availability-versus-validation tradeoff may be necessary in an outage, but it should remain visible and short-lived.
This article explains the practical implications of the primary material below. PatchMemo does not publish vendor copy as editorial coverage and does not accept payment for positive coverage.
PatchMemo independently selects and evaluates the topics it covers. Analysis and recommendations are ours; sources are linked so readers can check the underlying claims. We clearly label sponsorships and affiliate relationships, and neither determines coverage or conclusions.
