Bypassed Validation, No Longer Invisible: Cloudflare Ships the New "EDE 33" Error Code

Hi there, it's me, Shii-chan! Today I've got a slightly nerdy but genuinely interesting story about DNS trust.

Cloudflare Blog blog.cloudflare.com

What was announced?

Cloudflare's blog covers a DNSSEC outage that hit .AL (Albania's country-code domain) on July 3rd, and the new mechanism that came out of it. 1.1.1.1 now tells you directly, right in the response, when it's intentionally skipping (bypassing) DNSSEC validation. It does this with a new Extended DNS Error code called EDE 33.

The story so far

DNSSEC builds a chain of trust from the root zone down to individual domain names. The root zone holds a DS (Delegation Signer) record for each TLD, and resolvers validate by checking that the TLD's DNSKEY matches that DS record.

On July 3rd, the Albanian communications regulator that manages .AL performed a DNSSEC key rollover, and it went wrong. Here's the timeline:

• Around 14:15 UTC: .AL published a new DNSKEY and stopped serving the old one, but the DS record in the root zone still pointed to the old key (id=26319). Validation started failing across the board.
• Around 17:00 UTC: The new DNSKEY was removed, but the old one was never restored, leaving the zone with no DNSKEY at all. Validation kept failing.
• Around 19:15 UTC: The DS record itself was removed from the root zone. With no key left to validate against, .AL effectively became an unsigned zone, and resolution finally recovered.

During this window, every validating resolver had no choice but to reject responses for .AL, and Cloudflare's 1.1.1.1 was affected too.

To restore resolution, Cloudflare applied a Negative Trust Anchor (NTA), defined in RFC 7646, treating .AL as an unvalidated zone. Since the failure was public, confirmed, and affecting every validating resolver equally, this was judged an acceptable response.

But there was a catch: a response served under an NTA looked identical to a fully validated one. Clients had no way of knowing that validation had been bypassed.

What changes

That's where the new Extended DNS Error (EDE) code 33 comes in, proposed by Babak Farrokhi of Quad9. It signals directly in the response: "Negative Trust Anchor has been applied for this query (see RFC 7646)."

During the .AL incident, 1.1.1.1 started returning both EDE 9 (DNSKEY Missing, the underlying validation failure) and EDE 33 (Negative Trust Anchor, signaling the bypass). Now, 1.1.1.1 returns EDE 33 on any response generated while an NTA is active, regardless of whether the query itself would have failed DNSSEC validation.

Wrap-up

• A failed DNSSEC key rollover for .AL caused a major resolution outage on July 3rd
• Cloudflare restored resolution using an RFC 7646 Negative Trust Anchor, but until now, that kind of validation bypass was invisible to clients
• The new EDE 33 error code lets 1.1.1.1 clearly signal responses where an NTA was applied

If you're into DNS trust and resolver internals, this is a genuinely fun read!