Just 3.6 percent of .de domains use DNSSEC. On the night of May 5, that tiny slice still added up to hundreds of thousands of sites going dark across Germany.
DENIC, the Frankfurt-based registry that runs the .de top-level domain, started pushing broken cryptographic signatures into the global DNS at 21:57 local time. Within minutes, validating resolvers everywhere from Cloudflare’s 1.1.1.1 to Google’s 8.8.8.8 began rejecting answers for amazon.de, bahn.de, dhl.de, spiegel.de, and roughly every other DNSSEC-signed domain on the German internet. The fix did not land until 01:15 the next morning. DENIC has since apologized, paused all future key rollovers, and admitted the root cause is still under analysis.
The technical detail buried in the post-mortems is the part most outlets skipped. The break was not a random glitch. It was a malformed signature on a single NSEC3 record tied to keytag 33834, the active Zone Signing Key. And the .de zone was, per DENIC’s own published procedure, mid-rotation.
What Actually Broke At 21:57
The story everyone reported is the timeline. The story most missed is the cryptography. DENIC publishes a Zone Signing Key, ZSK for short, that signs every record in the .de zone. Resolvers across the world fetch those signatures and verify them against the published key before serving an answer to your browser. If the math fails, the resolver returns SERVFAIL. No retry. No fallback. The site is just gone.
On Tuesday evening, the math failed. Cloudflare’s incident write-up shows that an RRSIG signature with keytag 33834, applied to an NSEC3 record covering a hash range that included high-traffic domains like spiegel.de and bahn.de, did not validate. The zone data itself was fine. The seal on it was broken.
An independent analyst posting on Hacker News flagged the procedural fingerprint in the first hour. “Per DENIC’s FAQ, the .de Zone Signing Key rotates every 5 weeks via pre-publish, so this smells like a botched rollover,” the commenter wrote in the Hacker News thread on the .de outage. DENIC confirmed three days later that the incident occurred during a routine DNSSEC key rollover.
The fail-closed design is the whole point of DNSSEC. Validators are supposed to refuse a response that does not check out, because the alternative is letting attackers redirect banking traffic with a forged DNS reply. The protocol worked exactly as specified. The problem was that DENIC, not an attacker, served the bad data.
By 20:15 UTC, DENIC had re-signed the affected NSEC3 hash range with a different key, keytag 32911, and the major public resolvers stopped returning errors. But cached failures continued to ripple through smaller resolver fleets for hours after.
The Sites That Vanished, And The Ones That Didn’t
Downdetector’s German index lit up with thousands of complaints aimed at Amazon, DHL, Steam, Web.de, and eBay between 22:00 and midnight. Hetzner, Strato, and Ionos, the three biggest German hosting providers, fielded a wave of support tickets even though their own infrastructure was untouched. The break sat one level above them.
Whether you noticed depended entirely on which DNS resolver your network used. Customers of Deutsche Telekom, Vodafone, and O2 mostly kept browsing because those ISPs’ default resolvers either skipped strict DNSSEC validation or were still serving cached records. Anyone whose phone, router, or VPN had been pointed at 1.1.1.1, 8.8.8.8, or 9.9.9.9, the public resolvers that do enforce validation, hit a wall.
Why A 3.6% Adoption Rate Still Took Down Half The Country
The headline number from ICANN’s TLD reporting is that only 3.6 percent of the roughly 18 million registered .de domains have DNSSEC enabled. That sounds like a containable blast radius. It wasn’t.
Three reasons compounded the damage:
- The signed minority is the high-traffic minority. Banks, government services, large e-commerce sites, and major media outlets are exactly the operators most likely to enable DNSSEC. The 3.6 percent overrepresents the sites people actually visit.
- Validation rates in Europe are climbing. A European Commission JRC analysis of DNSSEC uptake found the EU’s average DNSSEC validation rate hit 49.4 percent in Q3 2025, well above the 35.4 percent global figure. More validating resolvers means more places where a broken signature stops resolution cold.
- Public resolver dominance. Modern browsers, VPN clients, and many corporate networks default to Cloudflare, Google, or Quad9. All three validate strictly. None of them serve a stale answer once the signature breaks unless they have one cached.
Cloudflare’s own telemetry, published in its incident analysis, shows SERVFAIL responses for .de spiking instantly at the moment of failure, then climbing for the next three hours as cached records expired and resolvers went back to DENIC for fresh copies that did not validate.
The EDE Bug That Made Diagnosis Harder
One of the goldmines hidden in Cloudflare’s write-up is a self-disclosed bug in 1.1.1.1 itself. When the resolver hit the broken signature, it should have returned Extended DNS Error code 6, “DNSSEC Bogus,” which would have pointed engineers and developers straight at the cryptographic failure. Instead, it returned EDE 22, “No Reachable Authority.”
That code suggests the upstream DENIC nameservers were unreachable. They were not. They were answering, just with signatures no validator would accept. Engineers across Germany spent the first hour of the outage chasing the wrong problem because their resolver was telling them the wrong story. Cloudflare attributes the mismatch to a propagation bug in how its trust-chain verifier reports DNSSEC errors, and says a fix is being prepared.
This Has Happened Before, And It Will Happen Again
The .de incident lands in a long history of registry-level DNSSEC failures.
- October 2009 – .se (Sweden): The earliest canonical example. Sweden’s registry pushed an unsigned zone, breaking validation for hours.
- December 2011 – .nz (New Zealand): A non-compliant zone configuration triggered failures with BIND-based resolvers.
- February 2012 – .cz and .us: A bug in the Go RSA library broke validation on multiple TLDs simultaneously.
- May 2023 – .nz again: A botched key rollover, documented in detail by InternetNZ’s incident report on the .nz DNSSEC chain failure, took out second-level domains for hours.
- February 2024 – .ru (Russia): A duplicate key tag ID broke validation across the Russian internet.
- May 2026 – .de (Germany): The largest in the sequence by registered domains.
Geoff Huston, Chief Scientist at the Asia-Pacific Network Information Centre and one of the most consistent skeptics of DNSSEC’s deployment trajectory, wrote in his May 2024 ISP Column on calling time on DNSSEC that the protocol “is just not going anywhere. It’s too complex, too fragile and just too slow to use for the majority of services.” Two years later, Germany’s outage reads like an exhibit attached to that argument.
Added security just means more things that can break. The fail-closed model is doing exactly what it was designed to do. The question is whether registries can run the operational discipline the model requires.
That is the harder question DENIC has to answer. Its testing pipeline did not catch the malformed signature before it left the door. The signature was generated, distributed across DENIC’s 16 Anycast service locations, and only flagged when third-party validators outside Germany started rejecting it. Some of those Anycast nodes were still serving the old, valid signature from cache while others served the broken one, which is part of why the impact looked patchy in the first hour. A proper pre-publish testbed should have spotted the failure long before any resolver in the wild saw it.
The registry has paused all further key rollovers until its post-incident analysis is complete. That is sensible, but it is also a cost. The whole point of rotating signing keys frequently is to limit the window an attacker has if a key ever leaks. A frozen rollover schedule is a security trade-off in the opposite direction.
What This Means For Anyone Running A .de Domain
If you operate a .de domain and DNSSEC is not enabled, Tuesday’s outage did not affect your reachability. The 96.4 percent of unsigned domains kept resolving normally. That fact will be quoted by every operator who has ever resisted enabling DNSSEC, and it will not be wrong.
If you have DNSSEC enabled, there is nothing you could have done at the domain level. The break was at the parent zone. Your records were fine. Your registrar was fine. Your nameservers were fine. The signature DENIC published over your zone’s delegation simply did not validate. This is the structural cost of relying on a hierarchy: when the layer above you fails, you fail with it. Some operators are now openly weighing whether the protection DNSSEC offers, mainly against DNS spoofing attacks, is worth a recurring exposure to registry-level errors. Internal infrastructure failures at hosting layers continue to be a steady source of downtime too, as Cloudflare’s recent disclosure of a 2.45 billion request DDoS showed at a different layer of the stack.
Frequently Asked Questions
Was My Website Affected If It Uses A .de Domain?
Only if DNSSEC was enabled on it. About 3.6 percent of the 18 million .de domains are DNSSEC-signed, so 96.4 percent kept resolving as normal. Check your registrar’s control panel under DNSSEC or DS records. If it shows “enabled” or lists a DS record, your visitors using validating resolvers like 1.1.1.1, 8.8.8.8, or 9.9.9.9 saw SERVFAIL errors between 21:57 on May 5 and roughly 02:00 on May 6.
Should I Turn Off DNSSEC On My Domain Now?
No. DNSSEC still protects against DNS spoofing and cache poisoning attacks, which is why banks and government sites use it. The May 5 outage was a registry-side failure you cannot prevent at the domain level. A safer response is to keep DNSSEC on, lower your record TTLs slightly, and verify your registrar offers automated DS record management so any future emergency rotation can happen without manual edits.
Why Did Some Germans Browse Normally While Others Couldn’t?
It came down to which DNS resolver each connection used. Anyone pointed at Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, or Quad9’s 9.9.9.9 hit SERVFAIL because those resolvers strictly enforce DNSSEC validation. ISPs like Deutsche Telekom, Vodafone, and O2 either skipped strict validation or served cached records, so their customers mostly kept browsing. Modern browsers and VPNs often override your ISP’s resolver, which is why the experience was inconsistent even on the same network.
How Long Will It Take For DENIC To Publish A Root Cause?
DENIC said in its May 8 update that the incident happened during a routine DNSSEC key rollover, but the full post-mortem is still pending. Comparable registry incidents like New Zealand’s 2023 .nz outage took about three weeks to produce a detailed write-up. Watch DENIC’s official blog for the technical report. The registry has also paused future key rollovers until that analysis is finished.
Could This Happen To Other TLDs Like .com Or .org?
Yes, and it has. Sweden’s .se broke in 2009. New Zealand’s .nz broke in 2011 and again in 2023. Czech Republic’s .cz and the United States .us both broke in 2012. Russia’s .ru broke in 2024. Verisign, which runs .com and .net, has avoided a public TLD-level DNSSEC outage so far, but the structural risk is identical. Any registry running a key rollover can publish a bad signature, and every domain under that TLD pays.
DENIC’s apology will not be the last one a registry has to issue. The fail-closed design DNSSEC chose in 1997 is the same one that took Germany off the internet on Tuesday night, and it is the same one protecting bahn.de from a hijacker tomorrow morning. The trade is locked in. The question that has stalked DNSSEC for two decades is whether the operational discipline it demands actually scales to the registries running it. Tuesday answered that question for one more TLD.
Leave a Comment