DNS monitoring should capture Extended DNS Errors, because a successful answer may now explicitly say that DNSSEC validation was bypassed.
A DNS answer can succeed and still carry a security warning. Cloudflare’s 1.1.1.1 resolver has started returning Extended DNS Error code 33 when it applies a Negative Trust Anchor, making a temporary DNSSEC bypass visible to clients and monitoring tools.
Cloudflare first used the signal during a July 3 failure involving Albania’s `.al` top-level domain. The incident shows why availability checks that record only success or failure miss important context.
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 a Negative Trust Anchor, instructing 1.1.1.1 to treat the affected zone as unsigned so names would resolve while the registry corrected the delegation. That restored availability by suspending cryptographic validation for the zone.
EDE 33 makes the compromise visible
Before this change, a response served under a Negative Trust Anchor looked like an ordinary successful answer. EDE 33 now states that an NTA was applied. During the incident, Cloudflare also returned EDE 9 to describe the missing DNSKEY condition underneath the bypass.
The result lets an operator distinguish three states: fully validated resolution, resolution restored under a temporary exception, and complete resolution failure.
What infrastructure teams should change
Check whether DNS probes, resolvers, and observability pipelines preserve EDNS Extended DNS Error data. Alert on a new NTA signal for critical domains, but do not automatically treat it as an attack; correlate it with resolver status, authoritative DNS changes, and registry communication.
For your own DNSSEC rollovers, monitor the DS and DNSKEY relationship from multiple validating resolvers before retiring an old key. The `.al` incident was a coordination failure at a trust boundary, not a failure that an application server could repair.
PatchMemo independently selects and evaluates the topics it covers. We clearly label sponsorships and affiliate relationships.
