- What really happened—and why it affects everyone
- It wasn't a failure of DNSSEC, but a human error
- Why has DNS been a blind spot for so long?
- What DNSSEC Protects—and What It Doesn't
- The layered model: Why not everyone can control everything
- The real lesson is this: it’s about operational excellence, not skepticism toward the protocol
- What to Do Now
On May 5, 2026, shortly after dinner, millions of German websites simply vanished from the internet. It wasn’t hackers, it wasn’t bombs, and the power wasn’t out either. The cause was a problem with the DNSSEC implementation at DENIC, the custodian of all .de domains. Amazon, DHL, major news portals: Suddenly, they were no longer accessible. For about an hour and a half, the German internet—at least from the perspective of validating resolvers—simply did not exist.
What really happened—and why it affects everyone
The Domain Name System is the internet’s phone book. When “dhl.de” is entered, the device queries a DNS resolver, which returns the corresponding IP address. DNSSEC guarantees that the response is genuine and has not been tampered with. That evening, DENIC published incorrect DNSSEC signatures for the entire .de zone. The result: All resolvers that correctly verified DNSSEC rejected the responses. Errors instead of connections. Silence instead of service.
It wasn’t a failure of DNSSEC, but a human error
In the heated post-incident coverage, this point is often overlooked: DNSSEC did not fail in this case. The standard worked exactly as it was supposed to. However, the signature validation failed due to an error in key management. This is not a bug, but a protective mechanism. The problem was operational in nature: a faulty configuration at the registry level, not a flaw in the standard itself.
This distinction is crucial. Anyone who concludes from this incident that DNSSEC is dangerous has not understood the lesson. On the other hand, anyone who concludes that the DNS infrastructure must be operated with care has understood it correctly.
Why has DNS been a blind spot for so long?
DNS is invisible when it works. No one thinks about the foundation if the house stands. This invisibility has led to DNS being ignored in many security strategies for years—as an “invisible support service” that somehow just works. But this incident makes tangible what security professionals have known for a long time. DNS is not a support function. It is the backbone of all digital accessibility.
Without a functioning DNS, there are no websites, no email routing, no API communication, and no cloud connectivity. It doesn’t matter how well your application is secured if the underlying name resolution breaks down.
What DNSSEC Protects—and What It Doesn’t
DNSSEC protects the integrity of DNS responses. It cryptographically ensures that a response actually originates from the authorized source and has not been tampered with en route. This significantly complicates cache poisoning attacks, in which manipulated entries are injected into the cache of resolvers, as well as man-in-the-middle attacks on name resolution.
What DNSSEC does not protect against: It does not prevent DDoS attacks, does not encrypt traffic, and does not replace other security measures. DNSSEC is a building block—but a fundamental one. Without trustworthy name resolution, subsequent security mechanisms such as DANE (DNS-based Authentication of Named Entities) lack a foundation of trust. DNSSEC is therefore not the end, but the beginning of the security chain.
The layered model: Why not everyone can control everything
This incident reveals a structural truth about the DNS ecosystem that rarely becomes so clear. Authoritative DNS providers like Link11 operate on a different part of the DNS infrastructure than recursive resolvers. This means: What DENIC, as the registry, writes to the .de zone determines what resolvers worldwide see—even before DNSSEC can play a role for downstream operators. Authoritative providers can neither anticipate nor correct faulty signatures at the registry level.
Anyone who takes DNS security seriously must therefore keep the entire ecosystem in mind: registry operators, registrars, DNS providers, resolver operators, and end users. Security does not arise at a single point; rather, it must be built up and monitored throughout the entire resolution process.
The real lesson is this: it’s about operational excellence, not skepticism toward the protocol
After such an incident, the question is not whether DNSSEC should be disabled. Rather, it is about ensuring that changes to critical infrastructure are controlled, tested, and monitored. The BSI has been recommending DNSSEC as a best practice for years—and rightly so. The .de outage does nothing to change that.
DNS security is no longer a purely technical issue. It is an organizational decision that must be made at the executive board level. Digital business models stand or fall on the availability of their services. An outage like this, triggered by a single configuration error in key management at the registry level, shows just how fragile digital availability can be. Especially in critical areas such as key management—a central security element that extends far beyond DNSSEC—particularly thorough testing, seamless monitoring, and clear processes are essential.
What to Do Now
This incident is a call to reevaluate your DNS security strategy—but not to simplify it. Here are three concrete approaches:
First: Don’t just enable DNSSEC; implement and operate it. The difference lies in process maturity: key rotations, monitoring, and incident playbooks are crucial.
Second: Treat DNS traffic as a security signal. Anomalies in DNS traffic, such as unusual query patterns or sudden resolution errors, are early indicators of attacks or misconfigurations.
Third: Know your dependencies. If you know which registry, registrar, and resolver operator are part of your own DNS chain, you can react more quickly if something goes wrong.
If you’d like to learn more about our Secure DNS, our experts are happy to answer all your questions.
You might also like:
