Das Wichtigste in Kürze
- →Mehrere bekannte .de-Websites (darunter bahn.de und spiegel.de) waren am 5. Mai 2026 für einen Teil der Nutzer nicht aufrufbar.
- →Der Fehler lag nicht bei den Websites selbst, sondern bei der deutschen Domainverwaltung DENIC, die eine fehlerhafte Sicherheitsunterschrift ausgeliefert hat.
- →Betroffen waren nur Nutzer, deren DNS-Dienst (das „Telefonbuch des Internets”) Sicherheitsprüfungen strikt durchführt – insbesondere Nutzer von Google DNS, Cloudflare und Quad9.
- →Viele Nutzer der deutschen Internetanbieter (Telekom, Vodafone, O2) waren nicht betroffen und haben davon vermutlich nichts gemerkt.
Manche deutschen Provider waren vom Ausfall gar nicht betroffen – weil sie DNS-Sicherheitsprüfungen schlicht noch nicht eingeschaltet haben. Das ist ungefähr so beruhigend, wie im ICE oder auf der A3 noch nie gehackt worden zu sein: Ohne Netz kaum Angriff möglich. Security made in Germany.
Welche Websites waren betroffen?
Betroffen waren Websites, deren .de-Adresse in einem bestimmten Bereich der deutschen Domainverwaltung lag – völlig unabhängig davon, wer diese Websites betreibt oder wo sie gehostet werden. Drei Domains, die wir direkt bestätigen konnten:
Die betroffenen Domains haben nichts miteinander zu tun – sie teilen weder Betreiber noch Technik noch Hosting. Was sie verbindet: Sie alle fallen in denselben Bereich des deutschen Domainverzeichnisses, für den die fehlerhafte Sicherheitsunterschrift ausgestellt wurde.
Was ist DNS – das Telefonbuch des Internets
Damit der Fehler verständlich wird, hilft ein kurzer Blick hinter die Kulissen. Wenn man im Browser „bahn.de” eingibt, passiert im Hintergrund folgendes:
So funktioniert eine Website-Anfrage
- 1Du tippst „bahn.de" in den BrowserDer Browser weiß noch nicht, wo diese Website liegt. Er kennt nur den Namen.
- 2Dein Computer fragt das DNS-TelefonbuchEin sogenannter DNS-Server – er funktioniert wie ein riesiges Telefonbuch – wird gefragt: „Unter welcher Adresse ist bahn.de erreichbar?"
- 3DNS antwortet mit einer NummerDer DNS-Server schaut nach und antwortet z. B. mit „217.10.64.12" – das ist die eigentliche Adresse des Servers, auf dem bahn.de liegt.
- 4Browser baut die Verbindung aufMit dieser Nummer ruft der Browser dann die Website direkt ab. Was du siehst, ist die fertige Seite.
Dieses System funktioniert normalerweise so schnell und zuverlässig, dass man es nie bemerkt. Fällt es aber aus – oder liefert es falsche Antworten – dann erscheinen Websites einfach nicht mehr, auch wenn sie technisch einwandfrei laufen.
Was ist DNSSEC – die digitale Unterschrift
Das klassische DNS-Telefonbuch hat eine Schwachstelle: Jemand könnte die Antworten fälschen. Ein Angreifer könnte deinen Computer überreden, statt der echten bahn.de eine gefälschte Seite aufzurufen – und du würdest es nicht merken.
Genau dagegen wurde DNSSEC erfunden. Es funktioniert wie eine digitale Unterschriftunter jeder Telefonbuch-Auskunft:
DNS antwortet: „bahn.de ist unter 217.x.x.x.”
Dein Browser: „OK, ich vertrau dir blind.”
Risiko: Antwort könnte gefälscht sein.
DNS antwortet: „bahn.de ist unter 217.x.x.x – und hier ist die digitale Unterschrift.”
Dein Browser prüft: „Stimmt die Unterschrift?” → Ja → weiter.
Sicherheit: Gefälschte Antworten werden erkannt und abgelehnt.
DNSSEC ist eine gute Sache – ein echter Sicherheitsgewinn. Das Problem entsteht nur dann, wenn die Unterschrift selbst fehlerhaft ist. Dann lehnt ein sicherheitsbewusster DNS-Dienst die Antwort ab – nicht aus Böswilligkeit, sondern weil er nicht weiß, ob die Unterschrift gefälscht ist oder wirklich ein Fehler vorliegt.
Was heute genau schiefging
In Deutschland ist die Organisation DENIC dafür zuständig, alle .de-Adressen zu verwalten und zu signieren. DENIC ist sozusagen der Herausgeber des deutschen Internet-Telefonbuchs – und stellt auch die offiziellen digitalen Unterschriften unter jeden Eintrag.
Am 5. Mai 2026 hat DENIC für einen bestimmten Abschnitt des Telefonbuchs eine fehlerhafte digitale Unterschrift ausgeliefert. Diese Unterschrift war formal vorhanden, bestand aber die Echtheitsprüfung nicht.
DNS-Dienste, die strikt auf korrekte Unterschriften bestehen – allen voran Google DNS, Cloudflare und Quad9 – haben daraufhin jede Auskunft zu Adressen in diesem Bereich verweigert. Aus Sicht dieser Dienste war nicht klar, ob die Unterschrift gefälscht oder einfach defekt war. Im Zweifel: lieber keine Auskunft als eine möglicherweise manipulierte.
Das Ergebnis: Wer einen dieser sicherheitsstrengen DNS-Dienste verwendete, sah beim Aufrufen von bahn.de oder spiegel.de eine Fehlermeldung – meist DNS_PROBE_FINISHED_NXDOMAIN oder einfach „Diese Website ist nicht erreichbar.”
Die Websites selbst liefen dabei die ganze Zeit problemlos. Kein Hacker, kein Serverausfall, keine Überlastung. Nur das Telefonbuch hatte für einen Teil seiner Einträge eine ungültige Unterschrift ausgestellt.
Warum war nicht jeder betroffen?
Nicht alle DNS-Telefonbücher prüfen die Unterschriften gleich streng. Ob du betroffen warst, hing davon ab, welchen DNS-Dienst dein Gerät im Hintergrund benutzt:
| Wer nutzt diesen DNS? | Dienst | Betroffen? |
|---|---|---|
| Nutzer, die Google DNS manuell eingestellt haben | Google Public DNS (8.8.8.8) | Ja – nicht erreichbar |
| Nutzer mit Cloudflare-DNS, viele VPN-Nutzer | Cloudflare (1.1.1.1) | Ja – nicht erreichbar |
| Nutzer mit Quad9, viele Unternehmensnetze | Quad9 (9.9.9.9) | Ja – nicht erreichbar |
| Kunden der Deutschen Telekom | Telekom-DNS | Nein – normal erreichbar |
| Kunden von Vodafone / Unitymedia | Vodafone-DNS | Nein – normal erreichbar |
| Kunden von O2 / Telefónica | O2-DNS | Nein – normal erreichbar |
Etwas überraschend: Ausgerechnet die Nutzer, die bewusst auf besonders sichere DNS-Dienste setzen, waren von dem Ausfall betroffen. Wer sich weniger Gedanken über DNS gemacht hat und den Standard seiner Telekom- oder Vodafone-Leitung verwendete, hat heute wahrscheinlich nichts gemerkt.
Was konnten betroffene Nutzer tun?
Wer heute morgen oder nachmittags bahn.de oder spiegel.de nicht aufrufen konnte, hatte kurzfristig zwei Möglichkeiten:
In den Netzwerkeinstellungen des Computers oder Routers auf den DNS-Server des eigenen Internetanbieters wechseln (dieser ist automatisch voreingestellt, wenn man keinen manuellen DNS eingestellt hat).
Viele DNS-Dienste speichern Antworten für einige Stunden zwischen (sogenannter Cache). Nachdem die fehlerhafte Unterschrift aus dem Umlauf genommen wird, normalisiert sich der Zustand schrittweise von selbst.
Wichtig: Das Deaktivieren von DNSSEC oder der Wechsel zu einem unsicheren DNS-Dienst als Dauerlösung ist nicht empfehlenswert – DNSSEC schützt vor echten Angriffen. Es war in diesem Fall nur deshalb als kurzfristiger Workaround sinnvoll, weil der Fehler nachweislich bei DENIC lag und nicht auf einen Angriff hindeutete.
Wer ist schuld – und was passiert jetzt?
Die Ursache liegt klar bei DENIC, dem offiziellen Verwalter aller .de-Adressen. Weder die Betreiber von bahn.de oder spiegel.de noch die Betreiber der DNS-Dienste haben einen Fehler gemacht. Die fehlerhaften Sicherheitsunterschriften kamen direkt von DENIC.
DENIC führt regelmäßig sogenannte „Signing-Läufe” durch – dabei werden alle Unterschriften unter den .de-Telefonbucheinträgen aktualisiert. Am 5. Mai 2026 wurde bei einem solchen Lauf um circa 17:49 Uhr (UTC) für einen bestimmten Bereich eine fehlerhafte Unterschrift erzeugt.
Ein erster Signing-Lauf um 20:33 Uhr (UTC) hat zunächst nur einen Teil der Einträge aktualisiert. Um 20:15 Uhr (UTC) – also noch vor dem Abend – hat DENIC den fehlerhaften Eintrag dann gezielt mit einem neuen Schlüssel neu signiert. Damit war das Problem behoben.
Status: behoben. Ab ca. 22:15 Uhr (MESZ) antworteten Google DNS, Cloudflare und Quad9 wieder korrekt. Die betroffenen Websites sind für alle Nutzer wieder normal erreichbar.
Was man daraus lernen kann
Dieser Vorfall zeigt, wie unsichtbar und gleichzeitig wie wichtig das DNS-System für das alltägliche Internet ist. Eine fehlerhafte Unterschrift bei der deutschen Domainverwaltung – und plötzlich können Nutzer mit sicherheitsbewussten Einstellungen die Deutsche Bahn-Website nicht aufrufen.
Für normale Nutzer ist die wichtigste Erkenntnis: Wenn eine Website plötzlich nicht mehr erreichbar ist, obwohl das Internet sonst funktioniert, muss das nicht am eigenen Gerät liegen – und auch nicht an der Website selbst. Manchmal liegt der Fehler mehrere Ebenen höher, bei den unsichtbaren Infrastrukturdiensten, die das Internet zusammenhalten.
Für Unternehmen bedeutet dieser Vorfall: Selbst wer seine eigene Website perfekt betreibt, kann durch Fehler eines Dritten – hier DENIC – für Teile seiner Nutzer unsichtbar werden. Wer solche Ausfälle frühzeitig erkennen will, braucht ein aktives Monitoring seiner DNS-Erreichbarkeit.
Darüber hinaus zeigt der Vorfall, dass DNS- und DNSSEC-Konfiguration sowie das Management kryptografischer Zertifikate und Schlüssel keine einmaligen Aufgaben sind, sondern kontinuierliche Disziplinen. Unternehmen, die diese Kompetenz nicht im eigenen Haus haben – und das ist die Mehrheit – profitieren davon, einen erfahrenen Partner einzubinden: sei es für den Aufbau zuverlässiger DNS-Infrastruktur, die Verwaltung von Zertifikaten oder als dauerhaften externen Ansprechpartner für Informationssicherheit. Für Unternehmen, die unter NIS2 oder als KRITIS-Betreiber reguliert sind, ist DNS-Sicherheit ohnehin keine Kür, sondern gesetzliche Pflicht.
Häufige Fragen
Warum war bahn.de heute nicht erreichbar?
Was bedeutet DNS_PROBE_FINISHED_NXDOMAIN?
Warum funktionierte die Website bei manchen, bei anderen nicht?
Was ist DNS und wofür braucht man es?
Ist das Problem inzwischen behoben?
Technische Tiefenanalyse
Wer die technischen Details hinter dem Vorfall verstehen möchte – NSEC3, RRSIG, DNSSEC-Validierungskette – findet in unserem Fachbeitrag die vollständige Analyse:
DNSSEC-Fehler in der .de-Zone: Technische Analyse →