On July 3, 2026, Albania’s country-code top-level domain, .al, went dark for a large slice of the internet. Government services, banks, and national media — everything hanging off the Albanian ccTLD — became unreachable for anyone whose DNS resolver actually checked cryptographic signatures. The trigger was not a hack or a cable cut. It was a routine security maintenance step, a DNSSEC key rollover, performed incorrectly. Within hours, Cloudflare’s public resolver 1.1.1.1 was returning hard failures for .al names, and the only fix was to temporarily switch off the very security control that caused the outage.
This is a story about how a single mis-timed cryptographic handoff can take down an entire country’s web presence, why the stopgap fix is quietly dangerous, and what changed this time that makes the next incident less invisible.
What a “key rollover” is supposed to do
DNSSEC works by chaining cryptographic signatures from the root of the DNS tree down to every leaf name. Each zone is signed with a Zone Signing Key, and the parent zone publishes a Delegation Signer (DS) record that vouches for the child’s key. When a validating resolver fetches a name, it walks that chain and refuses the answer if any signature doesn’t check out.
A key rollover is the process of swapping old keys for new ones. The safe procedure, standardized in RFC 7344 and RFC 8078, is deliberate and overlapping: you publish the new DS record in the parent zone first, wait for it to propagate, start signing with the new key while keeping the old one valid, then — only after another waiting period — retire the old key. Get the ordering wrong and validators see a signature they cannot tie to a trusted DS record, so they reject the whole answer.
According to Cloudflare’s post-mortem, that is effectively what happened to .al on July 3. The Albanian communications authority AKEP, which operates the ccTLD, attempted the rollover; something in the handoff broke, and validating resolvers began rejecting .al responses en masse Cloudflare blog on the .al DNSSEC incident. .al is not a trivial zone — it sits around #191 in Cloudflare Radar’s TLD rankings and is the online home of Albanian government, banking, and press.
Why some people saw it and others didn’t
The outage was not universal, and that asymmetry is the whole point of the story. Resolvers that do not validate DNSSEC — the majority of consumer routers and many ISP defaults — simply returned the (technically invalid) answers and users kept browsing. Resolvers that do validate, including 1.1.1.1, Google’s 8.8.8.8, and Quad9, treated the broken signatures as proof of tampering and returned SERVFAIL, the DNS equivalent of “I cannot safely answer this.”
So the same website was reachable for one user and dead for another depending entirely on which resolver they happened to use. Cloudflare’s chart of 1.1.1.1 query outcomes shows the SERVFAIL rate climbing through July 3 as cached valid records expired and resolvers were forced to fetch freshly-signed (and freshly-broken) records Cloudflare .al incident chart.
Image: Cloudflare
The fix that trades security for availability
Cloudflare’s emergency remedy was a Negative Trust Anchor (NTA). An NTA tells a validating resolver to stop validating a specific zone — in effect, to pretend .al is unsigned — so that answers flow again even though the signatures are broken. Cloudflare had used the same trick two months earlier when a near-identical incident struck Germany’s .de TLD Cloudflare on the .de DNSSEC incident.
NTAs work, but they are a blunt instrument. While an NTA is active, the resolver can no longer tell a legitimate answer from a forged one for that zone. Worse, the bypass was historically silent: a client receiving a response served under an NTA had no signal in the reply that validation had been suspended. A user or application could not distinguish “this is safe” from “this is unverified because we turned security off to keep you online.”
That is the uncomfortable trade at the heart of DNSSEC operations: when the signatures break, your choice is between a country being unreachable and a country being reachable but unprotected against DNS spoofing.
What is new: the outage became visible
For the .al incident, 1.1.1.1 did something it had not done before. Alongside every affected response, it returned a new Extended DNS Error code (EDE 33) signaling directly that the answer was not DNSSEC-validated because an NTA was in force. Extended DNS Errors are defined in RFC 8914 as a way to attach machine-readable context to DNS failures; Cloudflare’s use of a dedicated code for “validation bypassed by trust anchor” turns an invisible fallback into something a client, monitoring tool, or future browser can actually surface RFC 8914, Extended DNS Errors.
It is a modest change, but it matters. An NTA is still a security downgrade. But at least now the resolver is honest about it in the wire response instead of quietly pretending everything is fine.
How operators avoid being the next .al
The root cause was process, not protocol. DNSSEC itself behaved exactly as designed — it refused to vouch for broken signatures. The failure was in the rollover sequencing. Concrete defenses:
- Automate the handoff with CDS/CDNSKEY. RFC 7344 and RFC 8078 let the child zone publish
CDS/CDNSKEYrecords that signal the parent to update its DS record, removing the manual copy-paste step where most rollovers go wrong RFC 7344, Child-Parent Synchronization. - Overlap keys. Keep the old key signing while the new DS propagates, and only retire the old key after a second waiting window sized to your zone’s TTLs.
- Validate from the outside. Monitor your own zones from a validating resolver (1.1.1.1, 8.8.8.8, Quad9) so you learn about a broken chain from the user’s perspective, not from complaint tickets.
- Treat the NTA as a last resort. It restores availability at the cost of authenticity. Use it to stop the bleeding, then fix the signatures and remove it.
Honest limitations
An NTA is a band-aid, not a cure, and Cloudflare is candid that it trades safety for reachability. The durable fix is disciplined, automated rollover procedure — which is exactly what went missing at AKEP. And while EDE 33 makes the bypass visible at the protocol level, most end-user browsers do not yet surface Extended DNS Errors to a person staring at a failed page load, so the visibility benefit today mostly accrues to operators and monitoring systems rather than everyday users.
The .al and .de incidents two months apart are a reminder that DNSSEC’s security is only as good as the operational discipline behind it. The protocol protects you when it is correct, and it protects you less when someone, trying to maintain it, gets the order wrong.
