Cloudflares EDE 33 Making Negative Trust Anchors Visible in DNSSEC Responses

The Silent Bypass Problem in DNSSEC

When a country-code TLD breaks its DNSSEC chain of trust, validating resolvers like Cloudflare's 1.1.1.1 are forced to reject every query under that TLD. The operational fix is well-established: install a Negative Trust Anchor (NTA) as defined in RFC 7646, which tells the resolver to treat the zone as unsigned and bypass validation.

The catch? Until recently, a DNS response served under an NTA looked identical to a fully validated one. Clients, monitoring tools, and applications had no way to distinguish a cryptographically verified answer from one that was served with validation suspended.

This is the gap that Cloudflare's recent work on EDE 33 (근거자료) addresses. When the .al TLD suffered a broken DNSSEC key rollover in July 2026, 1.1.1.1 became the first major resolver to signal NTA presence directly in the DNS response itself.

Why this matters for operators

Before EDE 33, the only disclosure mechanism was out-of-band: a status page, a mailing list post, or a blog entry. That requires the user to go looking. An automated monitoring system querying 1.1.1.1 had no programmatic way to detect that DNSSEC validation had been bypassed for an entire TLD.

How EDE 33 Works in Practice

Extended DNS Error (EDE) codes, defined in RFC 8914, allow resolvers to attach additional context to any response — success or failure. The new EDE 33 code, proposed by Babak Farrokhi at Quad9 with Cloudflare as co-author, signals that a Negative Trust Anchor is active for the queried zone.

Here is a real response captured during the .al incident:

$ kdig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196

Reading the response

• status: NOERROR + valid A record — the domain resolves normally.
• EDE 9 (DNSKEY Missing) — the underlying DNSSEC chain was broken; validation failed.
• EDE 33 (Negative Trust Anchor) — 1.1.1.1 applied an NTA and served the response anyway.

Together, these two EDE codes give clients full visibility: the answer is real, but it was not DNSSEC-validated.

Behavior detail worth noting

1.1.1.1 returns EDE 33 on any response generated while an NTA is active — even for domains that don't use DNSSEC at all. This is intentional: the NTA covers the entire zone, and transparency applies uniformly. It also fixes a prior bug from the .de incident where 1.1.1.1 incorrectly returned EDE 22 (No Reachable Authority) instead of surfacing the underlying DNSSEC error.

Trade-offs and Limitations You Should Know

EDE 33 is a signaling mechanism, not a fix. Understanding its boundaries is critical before you build monitoring on top of it.

Critical caveats

1. The zone is unsigned during NTA. Every .al domain lost DNSSEC protection for the duration — EDE 33 makes this visible, not safe.
2. Client support is required. If your DNS library or stub resolver doesn't parse EDE options, you get the answer without the warning. Audit your stack: dig, kdig, and modern getdns support EDE; many minimal resolvers do not.
3. As of publication, .al remains unsigned. The DS record has not been restored to the root zone by the .al operator. Every .al domain is still without DNSSEC protections.
4. NTA is an aggressive operational response. Cloudflare only applies it when the failure is public, confirmed, and affects every validating resolver equally.

The deeper lesson

TLD-level DNSSEC failures are rare, but when they happen they affect every domain underneath simultaneously. The .de and .al incidents, back-to-back within two months, show that operational tooling for these events is still maturing. EDE 33 is a step toward making resolver behavior auditable rather than merely documented.

Where to Go Next

If you operate DNS infrastructure or build monitoring tooling, here is your action list:

1. Audit your resolver stack for EDE support. Run kdig @1.1.1.1 <domain> +ednsopt=15 against a known-NTA zone and inspect the output.
2. Add EDE parsing to your monitoring. Treat EDE 33 as a distinct alert signal — it means "resolving, but not verified."
3. Follow the Internet-Draft. The proposal is submitted to the IETF DNSOP Working Group and will be discussed at the Vienna meeting (July 18–24). Feedback goes to the DNSOP mailing list.
4. Understand the NTA trade-off before you ask your resolver to apply one. Suspending DNSSEC validation is a real security decision, not a convenience toggle.

Related reading

• How Blockchain is Revolutionizing Agricultural Traceability: A Deep Dive into Tokenized Cotton — a look at how distributed trust models are applied outside of DNS.
• Dynamic Path MTU Discovery: How Cloudflare Eliminates Network Black Holes for Good — another Cloudflare deep dive into silent network failure modes and how to surface them.

DNS transparency is evolving fast. EDE 33 is a small code with a big implication: resolvers no longer get to make silent decisions about your traffic.