For about three hours yesterday evening, a slice of Germany's internet quietly fell over. Browsers couldn't reach amazon.de, ebay.de, dhl.de, web.de, Steam, or a clutch of news sites. Servers were fine. Cables were fine. The cause was a paperwork problem at DENIC, the registry that runs the .de top-level domain. It's a useful one to understand if any of your clients sit on a .de.
What actually broke
DENIC published faulty DNSSEC signatures into the .de zone. DNSSEC is the cryptographic seal that tells your browser, "yes, this answer about where amazon.de lives genuinely came from .de, no one's tampered with it." When the seal is broken, modern browsers and resolvers don't shrug it off; they refuse the answer entirely. From a visitor's perspective, the site just doesn't load.
Think of DNSSEC as the bouncer at the door. Most of the time you don't notice it's there. But if the bouncer can't read his own guest list, no one gets in. Not even the people who are definitely on it.
DENIC have apologised and said they'll publish a full post-mortem. The rumour mill is pointing at a key rollover gone wrong, but the official explanation is still on its way.
Who actually noticed
Here's the slightly counter-intuitive bit: only around 3.6% of .de domains have DNSSEC turned on. The other 96.4% sailed through yesterday evening as if nothing had happened.
But the 3.6% who do use it skew toward the names that matter: banks, big retailers, logistics firms, government. Which is exactly why a small percentage caused a big news story.
If you manage a .de site for a client, it's worth knowing whether they're in that 3.6%. We track DNSSEC status as part of our domain registration checks, so you can see at a glance which of your clients are exposed.
What you can actually do about it
Honestly? Not much, in the moment. When a country-code registry has a bad afternoon, every DNSSEC-signed domain underneath it is along for the ride. There's no architectural trick a small site owner can pull to opt out without losing the protection DNSSEC gives you.
But three things are worth doing today:
Don't turn DNSSEC off. It exists because cache-poisoning attacks are a real class of problem. They're the sort of thing that can quietly redirect your client's customers to a fake login page, and a short outage every few years is the lesser-of-two-evils trade you've already implicitly accepted by leaving it on.
Know which clients use it. When the next registry incident happens (and there will be a next one), you want to answer "is my client affected?" in seconds, not in a panic.
Hear about it from your tools, not from your clients. This is the bit we care about. The freelancers and small agencies who use DomainDash tend to look after a handful to a few dozen sites for clients who don't have a dedicated tech team. Yesterday, the difference between a calm Wednesday morning and a frantic one was whether you knew before your client did.
We run checks from multiple locations every minute. A registry-level incident like this one shows up as failed DNS resolution across every checking location at once: a very particular pattern, and a hard one to mistake for anything else. If the alert lands at 21:58, you're already drafting the "we're aware, here's what's going on" message before the client emails you.
Welcome to Updates
This is one of the first posts in a new section we're calling Updates. We'll use it for:
- Incident write-ups like this one, when something interesting breaks on the wider internet and deserves a shared explanation in plain English.
- Product changes worth a few sentences more than a changelog entry.
- The occasional tip for getting more out of DomainDash — or out of checking your sites in general.
No subscribe form, no newsletter pop-up. Just check back, or follow @domaindash_io. And if there's a topic you'd like us to write up, drop us a line.