On the night of May 5, 2026, something deeply strange happened to the German internet. Not a cyberattack. Not a power failure. Just… gone. Millions of .de websites stopped responding. Government portals, banking apps, Deutsche Bahn’s ticketing system — all of it unreachable, for hours, while confused users stared at error screens and sysadmins frantically Googled a problem they had no power to fix.
The cause, once it emerged, was almost insulting in its simplicity: someone at DENIC, the organization that runs Germany’s .de domain registry, made a configuration mistake during routine maintenance.
What actually happened, quickly:
Starting around 9:57 PM Central European Summer Time, .de domains dropped off the internet globally. DENIC pushed a fix by 1:15 AM on May 6. But because of how DNS caching works, plenty of users kept seeing errors well into the morning.
The Technical Part (Bear With Me)
To understand why this one error was so catastrophic, you need to know two things about how the internet works.
First: DNS. When you type “spiegel.de” into your browser, your computer doesn’t actually know where that is. It asks a DNS resolver which is basically a phone directory which looks up the matching IP address and tells your browser where to go. Simple enough.
Second: DNSSEC. This is where things get interesting. DNS on its own has a flaw: it can be spoofed. A bad actor sitting between you and a DNS resolver could, in theory, redirect your request for “sparkasse.de” to a fake banking site. DNSSEC was designed to prevent exactly this by attaching cryptographic signatures to DNS records – essentially a tamper-evident seal that resolvers check before trusting an answer.
Here’s the thing about DNSSEC: it’s unforgiving by design. If the signature doesn’t check out, the resolver doesn’t shrug and let you through anyway. It refuses. Completely. This is called “fail-closed” behavior, and it’s intentional, the whole point is to not let anything slip through if something looks wrong.
So what happened at DENIC? During a routine key rollover which is the process of swapping out the cryptographic signing keys used to generate those signatures – they published signatures that didn’t match the keys. Specifically, resolvers hit a malformed signature on an NSEC3 record tied to keytag 33834, which means nothing to most people but was essentially a broken seal on the entire .de zone.
To Cloudflare’s 1.1.1.1 and Google’s 8.8.8.8, this didn’t look like a bad day at a German registry. It looked like the whole .de zone had been compromised. So they did what they’re supposed to do: blocked everything.
What It Felt Like on the Ground
Because the failure happened at the top-level domain level – above every individual .de website there was nothing any website owner could do. You could have had the most perfectly configured server in Frankfurt, and it wouldn’t have mattered. The problem was upstream.
Deutsche Bahn passengers couldn’t pull up digital tickets on their phones. Conductors couldn’t verify them either. People were stuck arguing over paper printouts on night trains.
Somewhat grimly, DENIC’s own staff were affected too. Their internal email stopped working because their mail servers couldn’t validate their own DNSSEC signatures. The registry that broke Germany’s internet couldn’t send emails about it.
Advertisers running campaigns on Meta and Google got billed for thousands of clicks to .de landing pages that never actually loaded. The clicks registered; the pages didn’t. That’s a clean waste of money.
Why Some People Could Still Get Through
Not everyone lost access, and that’s worth explaining. A few German ISP resolvers – Telekom, Vodafone were still returning results for some users. Two reasons:
Caching. DNS resolvers don’t look everything up from scratch every time. They store recent answers. Resolvers that had fetched valid .de records before the bad signatures went out kept serving those cached results until they expired which, depending on TTL settings, could be hours.
Lax validation. Some older resolvers don’t strictly enforce DNSSEC checking. They saw the broken signature and… let it go. This is technically less secure, but on the night of May 5, those users were the ones who could still check their bank balance.
The Bigger Argument This Kicked Off
There’s a real tension inside the security community over DNSSEC, and this incident put it front and center again.
The protocol works. It genuinely protects against DNS hijacking attacks, which are a real threat. But the way it’s designed means a single mistake at a registry can instantly make an entire country’s internet disappear. There’s no graceful degradation. No warning period. Just: valid, then not.
Whether that tradeoff is worth it is a legitimate debate. The alternative – looser enforcement which means less protection against actual attacks. The current system means one botched key rollover at 10 PM can strand millions of people.
DENIC has paused future key rollovers while they do a proper post-mortem. That’s the right call. But the underlying architecture question isn’t going away.
Still Seeing Errors? Here’s the Fix
If .de sites are still failing for you, your resolver is probably still holding onto the bad signatures. A few ways to clear it:
Flush your DNS cache:
- Windows: Open Command Prompt, type
ipconfig /flushdns - Mac: Open Terminal, type
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Clear your browser cache: Browsers sometimes cache DNS responses separately. A hard refresh or clearing the cache can help.
Check DNSViz: dnsviz.net lets you see whether a specific domain’s DNSSEC chain has fully recovered. Useful if you need to verify a particular site.
FAQ
Was this a cyberattack? No. DENIC confirmed it was an internal technical error during routine maintenance. No evidence of any external intrusion.
Why did Google and Cloudflare users get hit hardest? Because they actually enforce DNSSEC strictly. When they saw broken signatures, they blocked connections. Some ISP resolvers were less strict and let traffic through anyway.
Will it happen again? Probably, somewhere, eventually. DNSSEC key rollovers are complex, largely automated processes, and they happen at registries all over the world. DENIC is auditing what went wrong. But the root issue being that a single configuration error can take down an entire TLD is structural, not something a post-mortem fully solves
