On July 3, 2026, anyone whose DNS resolver checked cryptographic signatures suddenly couldn’t reach .al domains. Albania’s country-code top-level domain didn’t go down in the usual sense — no server crashed, no cable was cut. The registry simply botched a routine DNSSEC key rollover, and the very security mechanism meant to protect DNS quietly took the whole namespace offline for cautious resolvers. The episode is a clean case study in why DNSSEC is both essential and operationally fragile.
What DNSSEC is supposed to guarantee
Normal DNS answers are unsigned: a resolver asks for example.al and trusts whatever authoritative server replies. DNSSEC changes that by publishing cryptographic records — DNSKEY for public keys, RRSIG for signatures, and a DS record at the parent that ties a zone’s key into the chain of trust rooted at the DNS root. A validating resolver walks that chain and, if a signature doesn’t verify, is required by the specification to reject the answer and return an error rather than a possibly spoofed one.
That property is the entire point. It means an attacker who poisons a cache or hijacks a nameserver can’t forge a valid signed answer. The cost is strictness: when the chain breaks for any reason, resolution fails hard instead of degrading gracefully.
What actually broke on July 3
The Albanian communications authority, AKEP, operates the .al TLD. On July 3 it attempted a DNSSEC key rollover — the periodic process of swapping the signing keys that every zone must eventually do. Something in that rollover went wrong, and the signatures being served no longer validated. Per Cloudflare’s incident write-up, any validating resolver receiving those signatures was obligated by the DNSSEC spec to reject them and return SERVFAIL to clients. Because Cloudflare’s public resolver 1.1.1.1 validates by default, every .al lookup it served during the window failed — and 1.1.1.1 isn’t unusual here, it’s just the one that published the graph.
The blog’s chart tells the story plainly: the SERVFAIL rate for .al queries on 1.1.1.1 climbs sharply as cached validations expired and fresh, broken signatures were fetched. For users on validating resolvers, sites like google.al simply stopped resolving.
The silent workaround: Negative Trust Anchors
There is a documented escape hatch. RFC 7646 defines the Negative Trust Anchor (NTA), a configuration a recursive operator can install to temporarily stop validating a specific zone. Cloudflare had already used it two months earlier when a similar rollover failure struck Germany’s .de TLD: it installed an NTA for .de to keep domains reachable while the registry fixed its keys, and it did the same for .al.
NTAs work — domains resolve again — but they work silently. A client that receives a response served under an NTA has no way, from the response alone, to tell that DNSSEC validation was bypassed. It cannot distinguish a legitimate answer from a spoofed one. For the .al incident specifically, Cloudflare noted that 1.1.1.1 addressed that gap for the first time by attaching a new Extended DNS Error code to every affected response, signaling that the answer was not DNSSEC-validated because an NTA was in force.
Making the bypass visible: Extended DNS Errors
Extended DNS Errors, specified in RFC 8914, let a resolver attach extra context to any DNS response — error or not. The mechanism had been proposed for exactly this situation: Babak Farrokhi at Quad9 drafted a signal for the presence of a Negative Trust Anchor. In the .al responses, Cloudflare now returns two EDE codes alongside an otherwise normal answer. A dig against 1.1.1.1 for google.al returns a valid NOERROR with a real IP — but with EDE 9 (DNSKEY Missing) surfacing the underlying failure (“no SEP matching the DS found for al”) and EDE 33 (Negative Trust Anchor) stating that “a Negative Trust Anchor has been applied for this query (see RFC 7646).”
The two codes together give full visibility: the answer is real, but it was not DNSSEC-validated. EDE 33 is the Negative Trust Anchor signal, and the message points operators straight to RFC 7646.
Image: Cloudflare incident report on the .al DNSSEC rollover (blog.cloudflare.com).
Where .al stands now
As of the report’s publication, .al remained unsigned: AKEP had not restored the DS record to the root zone. Without that DS record, no .al domain can use DNSSEC protections at all. The immediate outage was patched with an NTA, but the Security posture of the entire Albanian namespace was — and at publish time still is — reduced to nothing. Restoring it means a correctly executed rollover and a republished DS, after which the NTA can be withdrawn.
What operators and users should take away
For registry and DNSSEC operators, the lesson is unglamorous: rollovers are the highest-risk operation you run, and they deserve rehearsal, staggered key states, and monitoring of validation failure rates — not a single untested swap. A botched rollover doesn’t just affect one site; it can dark an entire country-code TLD for every validating resolver on the planet.
For everyone else, the practical takeaways are narrower but useful. Prefer resolvers that surface EDE codes, because when a bypass like an NTA is active you want to know rather than silently trust. And treat “it resolves” and “it’s DNSSEC-validated” as two different statements — after an incident like .al, the first can be true while the second is deliberately false.
Sources
– Cloudflare Blog — “A broken DNSSEC rollover took down .al” (incident report, July 14, 2026)
– RFC 8914 — Extended DNS Errors (EDE)
– RFC 7646 — Negative Trust Anchors in DNSSEC
