On July 3, 2026, an entire country’s slice of the internet quietly went dark for anyone using a security-conscious DNS resolver. Albania’s communications authority, AKEP, which runs the .al country-code top-level domain, attempted a routine DNSSEC key rollover and got it wrong. The result, as Cloudflare documented, was a chain of broken cryptographic signatures that every strict resolver on the planet was obligated to reject. Albanian government portals, banks, and news sites all became unreachable through resolvers that do their job correctly.
That last part is the uncomfortable truth of DNSSEC: doing the right thing can look identical to an outage. What makes this incident worth more than a footnote is Cloudflare’s response, which introduces a small but overdue piece of transparency into how public resolvers handle these failures.
A signature chain snaps at the top
DNSSEC works by building a chain of trust that starts at the DNS root and runs down to individual names. The root zone publishes a Delegation Signer (DS) record for each signed TLD — essentially a fingerprint of that TLD’s signing key. When a validating resolver looks up an .al domain, it checks that the key served by Albania’s nameservers matches the fingerprint recorded in the root. If the match holds, the answer is trustworthy. If it doesn’t, the specification is blunt: reject the response and return an error rather than risk serving a forged record.
A key rollover is the moment a zone swaps one signing key for another, and it is precisely where this fragile handshake most often breaks. AKEP’s rollover left the published keys and the root’s DS fingerprint out of sync. Every validating resolver — including 1.1.1.1, the public resolver Cloudflare operates — started returning SERVFAIL. Because resolvers cache records until they expire, the damage spread gradually: the failure rate climbed through the day as cached .al entries aged out and clients were forced to revalidate against the broken chain.
This was not a hypothetical edge case. Cloudflare notes that .al ranks #191 on its Radar TLD ranking, and the outage had the potential to hit every .al domain regardless of where it was hosted or which nameservers answered for it. Because the fault sat at the TLD level, no individual site operator could fix their own corner of it.
The blunt instrument: a Negative Trust Anchor
When a whole TLD’s DNSSEC breaks, resolver operators reach for a documented escape hatch called a Negative Trust Anchor, or NTA. Defined in RFC 7646, an NTA tells a resolver to temporarily treat a specific zone as unsigned and skip validation for it. Cloudflare installed one for .al at 17:15 UTC, and the SERVFAIL rate collapsed almost immediately as resolution was restored. It is the same play the company ran just two months earlier when Germany’s .de TLD suffered a similar DNSSEC failure.
An NTA is effective and ugly in equal measure. It brings a broken TLD back online, but it does so by switching off exactly the protection DNSSEC exists to provide. For the duration of the anchor, answers for that zone are no longer cryptographically verified — which means a resolver can no longer distinguish a legitimate response from a spoofed one for those names.
Worse, until now that trade-off was invisible. A client receiving an answer served under an NTA had no way to know, from the response itself, that validation had been bypassed. Cloudflare acknowledges that best practice recommends operators publicly disclose which NTAs they have in place, but that disclosure is out-of-band: a status page only helps someone who already knows to go looking. An application, a monitoring probe, or a wary user querying 1.1.1.1 got a clean-looking answer with no asterisk attached.
Diagram: Cloudflare
The fix: put the warning in the answer
For the .al incident, Cloudflare closed that gap for the first time by attaching an Extended DNS Error to every affected response. Extended DNS Errors are a mechanism from RFC 8914 that let a resolver bundle a machine-readable diagnostic code alongside a normal DNS reply, explaining why it behaved the way it did. The specific code here is EDE 33, which the IANA DNS parameters registry lists as “Negative Trust Anchor.” Its presence in a response now says, in a form software can parse, that this answer was returned only because DNSSEC validation was deliberately suspended.
That turns a silent compromise into an explicit one. A monitoring tool can now alert on EDE 33 instead of assuming everything is fine. A security-sensitive application can decide to treat an unvalidated answer with extra caution — or refuse it outright — rather than trusting it blindly. And an operator debugging a reachability complaint can see the real cause in the response instead of chasing a status page.
None of this repairs the underlying break; only the registry, in this case AKEP, can republish correct keys and restore a working chain of trust. The .al operator was hard to reach during the incident precisely because its own contact addresses lived under the broken .al zone — a circular failure mode that DNSSEC operators know all too well. What the EDE signal changes is honesty: the resolver no longer hides the fact that it stepped around its own safety check.
Why this matters beyond Albania
Two national TLDs breaking their own DNSSEC within two months is not a run of bad luck; it is a reminder that key rollovers remain one of the most failure-prone operations on the internet, and that the cost of a mistake scales to an entire country’s namespace. Resolver operators will keep using Negative Trust Anchors because the alternative — leaving millions of people locked out — is worse. The meaningful shift is that a bypass no longer has to be a secret.
For anyone running infrastructure, the practical takeaway is small but real: start treating EDE codes as signal rather than noise. Logging and acting on Extended DNS Errors turns your resolver from a black box into something that can tell you when it is protecting you and when it has, for good reasons, stopped. That is a modest amount of plumbing for a meaningful gain in trust, and after two TLD-wide outages in a single quarter, it is plumbing worth installing before the next rollover goes wrong.
