Albania's Domains Went Dark. Germany's Did in May.

A national domain stopped resolving for over an hour

Albania's .al domain broke this month. For more than an hour, sites across the country stopped resolving: state portals, media outlets and private platforms alike. Citizens could not reach public services, and businesses trading on Albanian domains simply vanished from the internet. AKEP, the country's electronic and postal communications authority, said the problem sat with systems abroad that manage part of the .al infrastructure. The cause was a broken DNSSEC key rollover, the routine cryptographic housekeeping that is supposed to be invisible.

Why it matters. DNSSEC exists to prove that a DNS answer is genuine. When the signatures do not validate, a correctly configured resolver is required to refuse the answer entirely and return an error. That is the standard working exactly as designed. The failure mode of a security control that is doing its job properly is a country going offline.

The fix was to switch the security off

Nobody at the registry could repair the signatures fast enough, so the internet routed around the problem in the only way it can. Cloudflare temporarily disabled DNSSEC validation for .AL on its 1.1.1.1 resolver, and other resolver operators did the same. The mechanism is a negative trust anchor, which tells a resolver to treat a signed zone as though it were unsigned, and it exists precisely for these incidents. Resolution came back. Validation did not.

Cloudflare had put the logic plainly during an identical episode in May: no user resolving one of these names right now would prefer an error over an unvalidated answer. That is almost certainly correct, and it is also the whole problem. The control does not fail closed and it does not fail loudly. It fails open, by industry convention, at the exact moment an attacker would most want it off.

Ten weeks earlier, the same thing happened to .de

On 5 May 2026, at around 19:30 UTC, DENIC published broken DNSSEC signatures for the .de zone. Validating resolvers were obliged to reject them and return errors, and one of the largest top-level domains on the internet started falling over. Failures climbed for three hours as cached records expired. DENIC's own account named the cause: a routine, scheduled key rollover during which signatures that could not be validated were generated and distributed. Resolver operators deployed negative trust anchors within the hour, and 1.1.1.1 had its mitigation in place at 22:17 UTC.

Two national registries, ten weeks apart, both undone by scheduled maintenance rather than by an attacker. This is not a story about Albania, and it was not a story about Germany. It is the same failure arriving twice, which makes it a pattern rather than an accident, and it will arrive a third time.

Now the resolver tells you when it stopped checking

The genuinely new thing came out of this incident. Alongside the workaround, Cloudflare introduced Extended DNS Error 33, a code returned in the response itself that signals DNSSEC validation was bypassed. Until now, a resolver that had quietly dropped validation for a zone looked identical to one that was still checking. You got an answer, the answer worked, and nothing anywhere told you that the cryptographic guarantee behind it had been suspended, possibly for hours, possibly across an entire top-level domain.

What changes. That silence was the real exposure. An operator who lists DNSSEC in a risk register, a security questionnaire or a NIS2 control set has been asserting something they could not actually observe. EDE 33 turns an invisible state into a logged one. It is a small addition to a response packet and it is the first honest signal in this failure mode.

What to do about a key you do not hold

The uncomfortable part is how little of this is yours to fix. Your zone can be signed perfectly and your domain still disappears, because the break was one level up at the registry that runs your country's suffix. NIS2 already treats DNS service providers and TLD registries as entities of high criticality, which is a recognition that this layer is systemic. It does not give you a lever. What you can do is stop assuming this layer is inert: put a monitor on whether your own domain resolves from several public resolvers rather than from your office network, and record what those resolvers report.

The bottom line. Log EDE 33 and alert on it. If your resolver starts reporting that it bypassed validation for your TLD, you are in a window where DNS answers for your domain are unverified, and you should know that while it is happening rather than read about it afterwards. Two countries have now been through this window without being able to see it. The third one will at least have a light on.

Read next: Your Cloud Dependency Is Now a Regulated Risk. Most Companies Cannot Even See Theirs.  |  An 18-Year-Old Cisco Bug Now Has a 3-Day Deadline