After .AL went dark, 1.1.1.1 now admits when it has switched DNSSEC off
Published July 15, 2026 · DNS Benchmark Pro Editorial · Reading time: 3 minutes
In short — A botched key rollover took Albania's .AL TLD offline on 3 July. Cloudflare's fix — a Negative Trust Anchor — has always been invisible to users. This time 1.1.1.1 returned a brand new error code saying so.
On 3 July 2026, AKEP, the Albanian communications authority that runs the .AL country-code TLD, attempted a DNSSEC key rollover and got it wrong. At roughly 14:15 UTC it published a new DNSKEY and stopped serving the old one — while the DS record up in the root zone still pointed at the old key. The chain of trust snapped. Every validating resolver on the internet was then obliged, by specification, to reject every .AL response.
That is the entire TLD: Albanian government services, banks and media, all unreachable at once, regardless of who hosted them. It got worse before it got better. Around 17:00 UTC the operator removed the new DNSKEY without restoring the old one, leaving the zone with no DNSKEY records at all. Resolution was only restored at roughly 19:15 UTC, when the DS record was pulled from the root — at which point .AL was simply unsigned, and remains so.
The blunt instrument: Negative Trust Anchors
Cloudflare's response was the standard one, defined in RFC 7646: install a Negative Trust Anchor. An NTA tells a resolver to treat a specific zone as unsigned and skip validation entirely. 1.1.1.1 had the NTA rolled out to all users by 17:15 UTC, about three hours after the chain broke, and .AL names started resolving again.
Cloudflare had done exactly the same thing two months earlier for .DE, when DENIC published broken signatures for Germany's TLD on 5 May.
The trade-off is real and worth stating plainly: for the duration of an NTA, that zone's domains have no DNSSEC protection at all. They are as spoofable as they were in 2009. Operators accept that because the alternative — an entire country's namespace returning SERVFAIL — is worse.
What was new this time
Until now, a response served under an NTA looked byte-for-byte identical to a fully validated one. Your resolver had quietly stopped checking signatures and there was no way to tell from the answer. RFC 7646 asks operators to disclose active NTAs publicly, but a status page is out-of-band — an application or a monitoring tool has no way to consume it.
During the .AL incident, 1.1.1.1 closed that gap for the first time by returning a new Extended DNS Error code alongside every affected response:
$ kdig @1.1.1.1 google.al
;; 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
Two codes, doing two jobs. EDE 9 surfaces the underlying DNSSEC failure. EDE 33 — the new one — says the resolver applied an NTA and served the answer anyway. Together they tell a client exactly what it is holding: a real answer that was not cryptographically verified.
EDE 33 comes from an Internet-Draft originally proposed by Babak Farrokhi at Quad9, with Cloudflare joining as co-authors. IANA has assigned the code point, the Knot project's kdig already recognises it by name, and a pull request for Unbound is under review. The draft went to the IETF DNSOP working group at the Vienna meeting in late July.
Why it matters if you are choosing a resolver
TLD-level DNSSEC failures are rare, but two in three months is not nothing, and when they happen they take out every domain underneath simultaneously. The distinguishing factor between resolvers is not whether they can avoid these incidents — nobody can — but how fast they detect them, and whether they are honest about the compromise they made on your behalf.
Being told that validation was bypassed is a small thing that turns out to matter. It is the difference between a monitoring system that stays green through a security downgrade and one that raises its hand.
Source: Cloudflare Blog, "A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassed" (14 July 2026).
Published by Genext Information Systems · July 15, 2026. DNS Benchmark Pro is an independent tool and is not affiliated with any vendor or organisation named in this article. This report summarises publicly available disclosures and is provided for informational purposes.