Key Facts
- →Several well-known .de websites (including bahn.de and spiegel.de) were inaccessible for some users on May 5, 2026.
- →The fault was not with the websites themselves but with DENIC — the German domain authority — which delivered a malformed security signature.
- →Only users whose DNS service strictly checks security signatures were affected: primarily users of Google DNS, Cloudflare and Quad9.
- →Most customers of German ISPs (Telekom, Vodafone, O2) were not affected and likely noticed nothing.
Some German providers were completely unaffected by the outage — simply because they have not yet switched on DNS security checks. That is roughly as reassuring as never having been hacked on a train or motorway with no signal: No signal, no hackers. Security made in Germany.
Which Websites Were Affected?
Affected were websites whose .de address fell within a specific range of the German domain directory — completely independent of who operates those sites or where they are hosted. Three domains we confirmed directly:
The affected domains have nothing in common — no shared operator, no shared technology, no shared hosting. What connects them: they all fall into the same section of the German domain directory for which the malformed security signature was issued.
What Is DNS — The Internet's Phone Book
To understand the fault, a quick look behind the scenes helps. When you type “bahn.de” into a browser, this happens in the background:
How a Website Request Works
- 1You type "bahn.de" into your browserThe browser does not yet know where this website is located. It only knows the name.
- 2Your computer asks the DNS phone bookA DNS server — which works like a giant phone book — is asked: "What address is bahn.de located at?"
- 3DNS responds with a numberThe DNS server looks it up and replies e.g. with "217.10.64.12" — the actual address of the server hosting bahn.de.
- 4Browser establishes the connectionUsing that number, the browser fetches the website directly. What you see is the finished page.
What Is DNSSEC — The Digital Signature
The classic DNS phone book has a vulnerability: someone could forge the answers. An attacker could trick your computer into loading a fake bahn.de instead of the real one — and you would never know.
That is exactly what DNSSEC was invented to prevent. It works like a digital signature on every phone book entry:
DNS replies: “bahn.de is at 217.x.x.x.”
Your browser: “OK, I trust you blindly.”
Risk: the reply could be forged.
DNS replies: “bahn.de is at 217.x.x.x — and here is the digital signature.”
Your browser checks: “Is the signature valid?” → Yes → proceed.
Security: forged replies are detected and rejected.
DNSSEC is a genuine security improvement. The problem only arises when the signature itself is faulty. A security-conscious DNS service then rejects the answer — not out of malice, but because it cannot distinguish between a forged signature and a broken one.
What Exactly Went Wrong Today
In Germany, the organisation DENIC is responsible for managing and signing all .de addresses. DENIC is essentially the publisher of the German internet phone book — and issues the official digital signatures on every entry.
On May 5, 2026, DENIC delivered a malformed digital signature for a specific section of the phone book. The signature was formally present but did not pass the authenticity check.
DNS services that strictly require valid signatures — foremost Google DNS, Cloudflare and Quad9 — refused to answer any queries for addresses in that range. From their perspective, it was impossible to tell whether the signature was forged or simply broken. When in doubt: no answer is safer than a potentially manipulated one.
The result: anyone using one of these security-strict DNS services saw an error when opening bahn.de or spiegel.de — typically DNS_PROBE_FINISHED_NXDOMAIN or simply “This site can't be reached.”
The websites themselves ran perfectly throughout. No hacker, no server failure, no overload. Just the phone book — for one section of its entries — had been given an invalid signature.
Why Was Not Everyone Affected?
Not all DNS phone books check signatures equally strictly. Whether you were affected depended on which DNS service your device was using in the background:
| Who uses this DNS? | Service | Affected? |
|---|---|---|
| Users who manually set Google DNS | Google Public DNS (8.8.8.8) | Yes — unreachable |
| Users with Cloudflare DNS, many VPN users | Cloudflare (1.1.1.1) | Yes — unreachable |
| Users with Quad9, many corporate networks | Quad9 (9.9.9.9) | Yes — unreachable |
| Deutsche Telekom customers | Telekom DNS | No — working normally |
| Vodafone / Unitymedia customers | Vodafone DNS | No — working normally |
| O2 / Telefónica customers | O2 DNS | No — working normally |
Somewhat counterintuitively: the users who had deliberately chosen the most security-conscious DNS services were the ones hit by the outage. Anyone who had not thought much about DNS and was using their ISP's default setting probably noticed nothing at all today.
What Could Affected Users Do?
In the network settings of your computer or router, switch to your ISP's default DNS server (automatically set if you have not manually configured one). This restores access while the outage persists.
Many DNS services cache answers for several hours. As resolvers pick up previously cached correct responses, access gradually normalises. A permanent fix requires DENIC to specifically re-sign the affected record.
Important: Disabling DNSSEC or permanently switching to a less secure DNS service is not recommended — DNSSEC protects against real attacks. Switching was only sensible as a short-term workaround here because the fault was demonstrably on DENIC's side and not indicative of an attack.
Who Is Responsible — and What Happens Next?
Responsibility lies clearly with DENIC. Neither the operators of bahn.de or spiegel.de nor the DNS service operators made any error. The malformed security signatures came directly from DENIC.
A first signing run at 20:33 UTC only updated some records. At 20:15 UTC DENIC delivered a targeted re-signing of the affected NSEC3 record using a new key. With that, the problem was fully resolved.
Status: resolved. From approximately 22:15 CEST, Google DNS, Cloudflare and Quad9 all responded correctly again. The affected websites are fully reachable for all users.
Beyond monitoring, the incident illustrates that DNS and DNSSEC configuration, as well as the ongoing management of cryptographic certificates and keys, are not one-time tasks but continuous disciplines. Organisations that lack this expertise in-house benefit from an experienced partner: whether for building reliable DNS infrastructure, managing certificates, or serving as a permanent external point of contact for information security. For organisations regulated under NIS2 or operating critical infrastructure, DNS security is not optional — it is a legal obligation.
Frequently Asked Questions
Why was bahn.de unavailable today?
What does DNS_PROBE_FINISHED_NXDOMAIN mean?
Why did it work for some people but not others?
What is DNS and why do we need it?
Has the problem been fixed?
Technical Deep-Dive
For those who want to understand the technical details — NSEC3, RRSIG, DNSSEC validation chain — our technical article has the full analysis:
DNSSEC Failure in the .de Zone: Technical Analysis →