DENIC-Ausfall vom 5. Mai 2026 — Wenn eine fehlerhafte Signatur das halbe deutsche Netz lahmlegt

Am Abend des 5. Mai 2026 waren tausende Websites mit .de-Endung über Stunden nicht erreichbar — unabhängig davon, welchen Internetanbieter, welches Endgerät oder welchen Browser Nutzer verwendeten. Auch viele Apps, die im Hintergrund auf .de-Adressen zugreifen, funktionierten nicht oder nur sporadisch. Ursache war kein Hackerangriff und kein Stromausfall, sondern ein technischer Konfigurationsfehler bei der DENIC, jener gemeinnützigen Genossenschaft, die das deutsche Domain-Verzeichnis betreibt. Konkret war eine einzelne kryptografische Signatur fehlerhaft — und damit fielen auf einen Schlag alle deutschen Domains aus der "Vertrauenskette", die das moderne Internet vor manipulierten Adresseinträgen schützt.

Technisch gesprochen: Gegen 21:50 Uhr MESZ begannen plattformübergreifend Reklamationen aus deutschen Netzen einzulaufen — .de-Domains lieferten überhaupt keine validierte Antwort mehr. Wer einen DNSSEC-validierenden Resolver einsetzte — also nahezu jeder größere ISP, jeder öffentliche Resolver wie 1.1.1.1 oder 8.8.8.8 und jeder unternehmensseitige Unbound oder Knot Resolver mit aktivierter Validierung — sah SERVFAIL für nahezu jede .de-Anfrage. Die DENIC bestätigte den Vorfall um 22:55 Uhr im offiziellen Status-Portal als "Partial Service Disruption". Betroffen war damit nicht eine einzelne Domain, eine einzelne Region oder ein einzelner Provider, sondern die gesamte deutsche Top-Level-Domain.

Der Vorfall ist aus zwei Gründen lehrreich. Erstens illustriert er, wie eng die Erreichbarkeit deutscher Webauftritte, E-Mail-Server und Apps an die kryptografische Integrität einer einzigen Zone gekoppelt ist. Zweitens zeigt er, dass DNSSEC zwar Manipulationen wirksam verhindert — gleichzeitig aber jeder Konfigurationsfehler in der Vertrauenskette das Risiko eines flächendeckenden Ausfalls birgt. Beide Aspekte gehören in jede Resilienzbetrachtung von Unternehmen, die auf .de setzen.

Was ist passiert? Eine fehlerhafte Signatur in der .de-Zone

Eine offizielle technische Postmortem-Analyse der DENIC liegt zum Zeitpunkt dieses Artikels nicht vor. Wir haben deshalb die .de-Zone am Tag nach dem Vorfall direkt mit dig gegen mehrere validierende Resolver abgefragt und die Schlüsselmaterialien gegeneinander geprüft. Aus den so erhobenen Daten lässt sich das Schadensbild rekonstruieren: Eine RRSIG-Signatur über einen Record der .de-Zone validierte nicht gegen den publizierten DNSKEY des Zone Signing Keys mit Keytag 33834. Da die DENIC NSEC3 zur Authentifizierung der Nichtexistenz von Subzonen einsetzt, wirkt sich eine fehlerhafte NSEC3-Signatur nicht nur auf eine einzelne Domain aus, sondern auf den Existenzbeweis der gesamten Zone — und damit auf praktisch jede Auflösungsanfrage. Die zugrunde liegenden Zonendaten waren intakt; das Problem lag ausschließlich auf der Signaturebene.

Was wir selbst messen konnten

Wir haben die DNSKEYs, RRSIGs und das Validierungsverhalten verschiedener Resolver direkt abgefragt und vergleichbar gemacht. Die folgenden Befunde sind alle direkt aus der Live-Zone nachstellbar — die zugehörigen dig-Kommandos und die Keytag-Berechnung stehen im Anhang am Ende des Artikels.

Befund 1 — Aktuell sind zwei ZSKs gleichzeitig publiziert. Das DNSKEY-RRset von .de enthält drei Schlüssel: einen KSK mit Keytag 26755 (Flags 257, RSA/SHA-256) sowie zwei ZSKs mit Keytags 32911 und 33834 (beide Flags 256, RSA/SHA-256). Die Keytags haben wir aus dem Wire-Format der Schlüssel nach RFC 4034 Anhang B selbst berechnet. Das gleichzeitige Vorhandensein zweier ZSKs ist genau der Pre-Publish-Zustand, in dem sich ein regulärer ZSK-Rollover befindet — kein Schlüssel ist vorzeitig entfernt worden.

Befund 2 — 33834 ist der aktuell signierende Schlüssel, mit Inception mitten im Ausfallfenster. Die aktive RRSIG über die SOA der .de-Zone trägt Keytag 33834 mit Inception 20260505202344 und Expiry 20260519215344. Übersetzt: Die aktuell ausgelieferte Signatur wurde am 5. Mai 2026 um 22:23 MESZ erzeugt — also etwa eine halbe Stunde nach Beginn der ersten Ausfallmeldungen und ungefähr zur Zeit der DENIC-Statusmeldung. Das spricht für eine Recovery-Signatur: derselbe Keytag, aber mit korrektem Schlüsselmaterial neu signiert.

Befund 3 — Der KSK passt unverändert zum DS-Record in der Root. Der DS-Record für .de in der Root-Zone verweist auf Keytag 26755 (Algorithmus 8, Digest-Typ SHA-256). Dieser Wert stimmt mit dem aktuell publizierten KSK überein. Die Ursache lag also nicht auf KSK-Ebene und nicht auf Root-Ebene — sondern ausschließlich beim ZSK 33834.

Befund 4 — Die Auswirkungen sind nicht überall vollständig zurückgegangen. Eine Stichprobenmessung über vier öffentliche Resolver am 6. Mai 2026 zeigt ein gemischtes Bild:

Quad9 lieferte uns auch noch am Folgetag SERVFAIL für die positive SOA-Anfrage — vermutlich wegen gecachter negativer Validierungsergebnisse, die erst mit Ablauf der Negative-Caching-TTL geräumt werden.

Befund 5 — Der kaputte NSEC3-Record war der Apex-Beweis der Zone. Die NXDOMAIN-Antwort für einen nicht-existenten Namen unterhalb von .de enthält in der Authority-Section drei NSEC3-Records, die den Existenznachweis liefern. Einer davon hat den Owner-Hash a0d5d1p51kijsevll74k523htmq406bk und deckt mit den Bittypen NS SOA RRSIG DNSKEY NSEC3PARAM exakt die Records des Zonen-Apex ab. Genau dieser Hash taucht in den von externen Beobachtern publizierten Resolver-Logs als der mit fehlerhafter Signatur auf.

Wir haben den NSEC3-Hash mehrerer Domains mit den NSEC3PARAM der .de-Zone (SHA-1, ohne Salt, 0 Iterationen) selbst berechnet:

Keiner der populären, in den Berichten genannten Domain-Hashes liegt im fehlerhaften Bereich. Der Owner-Hash des kaputten NSEC3 ist exakt der Hash des Apex-Namens de. Das bedeutet: Es war kein zufälliger Hash-Bucket betroffen, der bahn.de oder spiegel.de zufällig gemeinsam enthalten hätte — sondern der NSEC3-Record, der den Existenznachweis für die Apex-Records der Zone selbst liefert.

Diese Unterscheidung ist erklärungstragend. Validierende Resolver verifizieren bei jeder .de-Auflösung als Teil der DNSSEC-Kette die Apex-Records der Zone (NS, SOA, DNSKEY) mit; eine kaputte NSEC3-Signatur über genau diesen Bereich legt die Validierung für die gesamte Zone lahm — unabhängig davon, welche Subdomain konkret abgefragt wird. Dass in den Berichten ausgerechnet bahn.de und spiegel.de namentlich auftauchen, ist also keine Folge eines geteilten Hash-Buckets, sondern Selektionsbias: Es waren prominente, viel-getestete Beispieldomains.

Was die Daten zur Ursache nahelegen — und was nicht

Eine endgültige Aussage zur Ursache ist ohne Postmortem der DENIC seriös nicht möglich. Die Beobachtungsdaten engen das Feld jedoch ein. Verträglich mit den gemessenen Werten ist insbesondere folgendes Szenario: Eine RRSIG über den Apex-NSEC3 wurde kurzzeitig mit Schlüsselmaterial signiert, das nicht exakt zum publizierten DNSKEY-Material passte (etwa nach einem Hardware- oder HSM-Wechsel) — und führte dazu, dass jede DNSSEC-Validierung die .de-Zone als ungültig einstufte. Die schrittweise Sanierung erfolgte über mehrere Re-Signing-Operationen mit beiden publizierten ZSKs: Eine korrigierte RRSIG der NSEC3-Chain wurde mit ZSK 32911 erzeugt (Inception 22:15 MESZ am Apex-NSEC3), kurz darauf eine neue SOA-RRSIG mit ZSK 33834 (Inception 22:23 MESZ). Die anhaltende Phase, in der Quad9 weiterhin SERVFAIL lieferte, lässt sich durch gecachte negative Validierungsergebnisse erklären, die erst mit Ablauf der Negative-Caching-TTL geräumt wurden.

Was die Daten ausschließen, ist ein klassischer Schlüssel-Lebenszyklusfehler im Sinne von "der alte ZSK wurde entfernt, bevor der neue verfügbar war". Beide ZSKs sind aktuell publiziert; der DS in der Root passt zum KSK; die Recovery erfolgte ohne Rotation des KSK oder Neueintrag in der Root. Die Ursache liegt damit eher in den Operations-Details der Signer-Infrastruktur — beim Erzeugen oder Veröffentlichen einer einzelnen Signatur — als im Lebenszyklus der Schlüssel.

Warum brach damit das halbe deutsche Netz zusammen?

Zum Verständnis des Schadensbildes hilft ein kurzer Blick auf die Funktionsweise der DNSSEC-Vertrauenskette. Wenn ein validierender Resolver beispiel.de auflösen will, fragt er — vereinfacht — die Root-Zone nach den Nameservern und dem DS-Record für .de, prüft mit dem Schlüssel der Root, dass diese Antwort signiert ist, kontaktiert anschließend die .de-Nameserver, prüft dort den DNSKEY-RRset gegen den DS-Record aus der Root und validiert schließlich die eigentliche Antwort gegen den ZSK aus der .de-Zone. Bricht die Signaturkette an einer einzigen Stelle, schlägt die gesamte Validierung fehl — und die Antwort wird verworfen. Aus Sicht der Anwendung verhält sich das wie ein totaler DNS-Ausfall.

Das ist kein Bug von DNSSEC, sondern Designziel: Eine kryptografisch nicht verifizierbare Antwort soll explizit nicht ausgeliefert werden, damit Angreifer keine gefälschten Signaturen einschmuggeln können. Der Preis dieser Sicherheitsgarantie ist, dass eine Fehlkonfiguration in einer Zone die gesamte abhängige Infrastruktur lahmlegt. Das Gegenmodell — Validierungsfehler einfach durchzuwinken — würde die Schutzwirkung gegen DNS-Spoofing und Cache-Poisoning vollständig aushebeln.

Hinzu kommt eine zweite Eigenschaft: .de ist eine der größten TLDs weltweit, und nahezu jeder deutsche ISP betreibt validierende Resolver. Ein einzelnes fehlerhaftes Signaturpaar in der TLD-Zone schlägt damit unmittelbar auf Millionen Endkunden durch.

Wer war betroffen — und wer nicht?

Die Auswirkungen waren nicht gleich verteilt. Aus den Beobachtungen lassen sich grob drei Gruppen unterscheiden:

Die Anycast-Architektur der .de-Nameserver führte dazu, dass einzelne Anfragen sporadisch doch erfolgreich waren, weil bestimmte Server-Instanzen noch eine zuvor gültige Signatur ausspielten. Das Bild aus Anwendersicht war daher inkonsistent: Eine Domain ließ sich beim ersten Versuch nicht öffnen, beim zehnten plötzlich doch — ein klassisches Diagnose-Albtraum-Szenario.

Welche Dienste konkret ausgefallen sind, hängt nicht nur von der Domain selbst ab, sondern auch davon, ob nachgelagerte Dienste — Authentifizierungs-APIs, CDN-Hostnamen, OCSP-Responder — auf .de zeigen. Apps wie die Deutsche Bahn-Anwendung wurden in den Berichten ausdrücklich genannt; in der Praxis dürften aber praktisch alle Anwendungen mit .de-Backends betroffen gewesen sein, sobald deren Cache abgelaufen war.

Was Unternehmen sofort prüfen sollten

Auch wenn der Ausfall auf TLD-Ebene auftrat und damit außerhalb des Einflussbereichs einzelner Unternehmen liegt, lassen sich aus dem Vorfall mehrere konkrete Maßnahmen für die eigene Infrastruktur ableiten. Sie betreffen drei Bereiche: die Zustandsdiagnose der eigenen Domains, die Resilienz der eingesetzten Resolver und die Vorbereitung auf vergleichbare Vorfälle in der Zukunft.

1. Eigene Domains technisch verifizieren

Auch wenn der Auslöser auf der TLD-Ebene lag, sollten Unternehmen den Anlass nutzen, um die eigene DNSSEC-Konfiguration zu verifizieren. In der Praxis finden wir bei Assessments regelmäßig Fehlkonfigurationen, die im Normalbetrieb nicht auffallen, im Krisenfall aber das Schadensbild verschärfen: abgelaufene Signaturen kurz vor TTL-Ende, fehlende DS-Records nach Registrar-Wechseln oder verwaiste DNSKEY-RRsets nach unvollständigen Rollovern. Mit dem DNSSEC-Check lässt sich die vollständige Vertrauenskette für eine Domain in wenigen Sekunden prüfen — von den DS-Records über den DNSKEY-RRset bis zu den RRSIG-Signaturen. Ergänzend empfiehlt sich der DNS-Lookup, um sicherzustellen, dass A-, AAAA-, MX- und TXT-Records einheitlich aufgelöst werden.

2. Resolver-Strategie überdenken

Viele Unternehmen betreiben einen einzelnen internen Resolver oder verlassen sich auf den ISP-Resolver. Beides ist im Normalbetrieb akzeptabel, im Vorfall vom 5. Mai 2026 aber problematisch: Wer ausschließlich validierende Resolver einsetzt, hat kein Fallback-Profil für TLD-weite Signaturfehler. Wer ausschließlich nicht-validierende Resolver einsetzt, ist gegenüber DNS-Spoofing schutzlos. Die robuste Antwort liegt in der Mitte: validierende Resolver als Standard, ergänzt um dokumentierte Notfallprozeduren, in denen die Validierung im Ausnahmefall gezielt für eine einzelne TLD ausgesetzt werden kann (in Unbound etwa über domain-insecure: "de"). Diese Prozedur muss vorab dokumentiert, getestet und freigegeben sein — sie im Krisenfall improvisiert anzuwenden, ist erfahrungsgemäß riskant und führt zu Folgefehlern.

Ein zweiter Hebel ist die Diversifizierung: Der Einsatz mehrerer unabhängiger Forwarder (etwa zwei interne Resolver mit unterschiedlichen Forward-Zielen) reduziert das Risiko, dass ein einzelner Konfigurationsfehler im eigenen Haus zum vollständigen Auflösungsausfall führt. Auf Anwendungsseite gehören großzügig gewählte TTLs für unkritische Records dazu, damit warme Caches einen externen Vorfall überbrücken können.

3. Monitoring und Incident-Kommunikation

Der Vorfall war nicht durch klassische Verfügbarkeitsmonitore aus Office-Netzen sichtbar — die nutzen typischerweise denselben Resolver wie die Anwendungen, die sie überwachen sollen. Aussagekräftig sind nur Probes, die aus mehreren unabhängigen Netzen heraus prüfen und sowohl validierende als auch nicht-validierende Auflösungen vergleichen. Eine Diskrepanz zwischen den beiden Pfaden ist genau das Signal, das auf einen DNSSEC-spezifischen Vorfall hindeutet — und nicht auf einen generischen Netzwerkausfall. Wer dieses Signal hat, kann in der internen Kommunikation deutlich präziser reagieren und ungenaue Aussagen wie "das Internet ist kaputt" vermeiden.

DNSSEC ist trotzdem die richtige Entscheidung

Der Vorfall wird in den kommenden Tagen zu der Diskussion führen, ob DNSSEC seinen Aufwand wert ist. Die ehrliche Antwort lautet: ja, ohne Einschränkung. Die Risiken, gegen die DNSSEC schützt — manipulierte DNS-Antworten in offenen WLANs, Cache-Poisoning auf Resolver-Ebene, Man-in-the-Middle-Angriffe gegen E-Mail-Authentifizierung und DANE-gestützte TLS-Validierung — sind real und tagtäglich beobachtbar. Ohne DNSSEC sind die DNS-Records, in denen SPF, DKIM und DMARC ihre Konfiguration ablegen, manipulationsanfällig.

Die richtige Lehre aus dem 5. Mai 2026 ist nicht, DNSSEC abzuschalten, sondern die Operationalisierung der Schlüsselrotation auf allen Ebenen ernst zu nehmen: bei der TLD-Registry, beim DNS-Provider und in der eigenen Zone. Automatisierte Rollover-Verfahren, mehrstufige Pre-Publish- und Double-Signature-Modelle sowie strenge Test- und Freigabeprozesse sind in der Praxis die wirksamsten Hebel gegen genau diese Fehlerklasse.

Regulatorische Einordnung

Unter der NIS2-Richtlinie sind DNS-Dienste größenunabhängig als wesentliche Dienste klassifiziert. Für Unternehmen, die selbst DNS-Dienste betreiben oder anbieten, bedeutet das eine Pflicht zu angemessenen Sicherheits- und Verfügbarkeitsmaßnahmen sowie zu Vorfallsmeldungen. Auch wenn der Vorfall vom 5. Mai 2026 die DENIC selbst betrifft und nicht einzelne nachgelagerte Betreiber, lohnt der Anlass, die eigene DNS-Infrastruktur unter NIS2-Gesichtspunkten zu reviewen: Verfügbarkeitsanforderungen, Schlüsselrotation, Notfallprozeduren und Meldepflichten gehören in jedes ISMS, das DNS als kritische Komponente abdeckt. Das BSI empfiehlt darüber hinaus DNSSEC seit langem ausdrücklich für alle geschäftlich genutzten Domains — eine Empfehlung, an der dieser Vorfall nichts ändert.

Was bleibt

Der Ausfall vom 5. Mai 2026 ist nicht der erste seiner Art und wird nicht der letzte sein. Schwedens .se hatte 2009 einen vergleichbaren Vorfall, der NL-Anycast-Verbund 2017 ebenfalls. Jeder dieser Vorfälle zeigte: Die Sicherheitsgarantien von DNSSEC und die operative Disziplin, die für ihren störungsfreien Betrieb nötig ist, gehören zusammen. Wer das Eine will, muss das Andere mitliefern.

Für deutsche Unternehmen lautet die kurzfristige Konsequenz, die eigene Resolver-Architektur, die TTL-Strategie der Kerndomains und die Notfallprozeduren auf den Prüfstand zu stellen. Für die deutsche Internetinfrastruktur insgesamt bleibt die Erwartung, dass die DENIC eine vollständige technische Postmortem-Analyse veröffentlicht und die operativen Konsequenzen — etwa beim ZSK-Rollover-Verfahren — transparent macht.

Anhang: Reproduzierbare Befunde

Alle in „Was wir selbst messen konnten" zitierten Werte stammen aus den folgenden Abfragen. Ausführung mit BIND 9 dig von einem Standort innerhalb Deutschlands, Stand 6. Mai 2026.

Aktive DNSKEYs der .de-Zone

dig @1.1.1.1 de DNSKEY +noall +answer

Liefert ein DNSKEY-RRset mit drei Records: zwei ZSKs (Flags 256) und ein KSK (Flags 257), alle Algorithmus 8 (RSA/SHA-256). Aus den Public-Key-Bytes nach RFC 4034 Anhang B berechnen sich die Keytags 32911 und 33834 (ZSK) sowie 26755 (KSK).

DS-Record in der Root

dig @1.1.1.1 de DS +short
# 26755 8 2 F341357809A5954311CCB82ADE114C6C1D724A75C0395137AA3978035425E78D

Der DS verweist auf Keytag 26755 — identisch mit dem aktuell publizierten KSK.

RRSIG über die SOA

dig @1.1.1.1 de SOA +dnssec +noall +answer | awk '$4=="RRSIG"'
# de. 7200 IN RRSIG SOA 8 1 7200 20260519215344 20260505202344 33834 de. ...

Inception 20260505202344 → 5. Mai 2026, 22:23:44 MESZ. Keytag des signierenden Schlüssels: 33834.

Validierungsverhalten verschiedener Resolver

for r in 1.1.1.1 8.8.8.8 9.9.9.9 8.26.56.26; do
  echo "$r:"
  dig @$r de SOA +dnssec +noall +comments | grep -E "^;; flags|^;; ->>HEADER"
done

flags: ... ad zeigt erfolgreiche DNSSEC-Validierung. status: SERVFAIL oder fehlendes ad-Flag zeigt ein Problem auf dem Pfad.

NSEC3-Authority-Section bei NXDOMAIN

dig @1.1.1.1 nichtexistent-test-itantix-99999.de A +dnssec +noall +authority

Eine korrekt funktionierende .de-Zone liefert hier NXDOMAIN mit ad-Flag und drei NSEC3-Records in der Authority-Section. Einer dieser NSEC3 hat als Owner-Name den Hash des Zonen-Apex (a0d5d1p51kijsevll74k523htmq406bk.de) und beweist mit Bittypen NS SOA RRSIG DNSKEY NSEC3PARAM die Existenz der Apex-Records.

NSEC3-Hash-Berechnung nach RFC 5155

Mit den NSEC3PARAM 1 0 0 - (SHA-1, kein Salt, 0 Iterationen) lässt sich der Hash beliebiger Namen reproduzieren — und damit prüfen, in welchen NSEC3-Bucket eine Domain fällt:

import hashlib
 
def nsec3_hash(name, salt_hex="", iterations=0):
    wire = b""
    for label in name.lower().split("."):
        if label:
            wire += bytes([len(label)]) + label.encode("ascii")
    wire += b"\x00"
    salt = bytes.fromhex(salt_hex) if salt_hex else b""
    h = hashlib.sha1(wire + salt).digest()
    for _ in range(iterations):
        h = hashlib.sha1(h + salt).digest()
    alphabet = "0123456789abcdefghijklmnopqrstuv"
    bits = "".join(format(b, "08b") for b in h)
    return "".join(
        alphabet[int(bits[i:i+5].ljust(5, "0"), 2)]
        for i in range(0, len(bits), 5)
    )
 
print(nsec3_hash("de"))     # → a0d5d1p51kijsevll74k523htmq406bk (Apex-Hash)
print(nsec3_hash("bahn.de")) # → k60c88lfljtm2elkhernvm7kqruocbn5

Keytag-Berechnung nach RFC 4034 Anhang B

Aus dem DNSKEY-Wire-Format ergibt sich der Keytag durch eine 16-Bit-Summe der Rdata-Bytes — minimaler Python-Code:

import base64, struct
 
def keytag(flags, proto, algo, pubkey_b64):
    rdata = struct.pack("!HBB", flags, proto, algo) + base64.b64decode(pubkey_b64)
    ac = 0
    for i, b in enumerate(rdata):
        ac += b if i % 2 else b << 8
    ac += (ac >> 16) & 0xFFFF
    return ac & 0xFFFF

Für die drei .de-DNSKEYs ergibt das ZSK 32911, ZSK 33834 und KSK 26755 — passend zu den Keytags, die in den RRSIG-Records und im Root-DS auftauchen.

Was wir für Sie tun können

Schwachstellen finden, bevor sie zum Vorfall werden. Unsere IT-Schwachstellenprüfung bewertet Ihre extern erreichbare Infrastruktur ganzheitlich — DNS und DNSSEC sind dabei ein Baustein neben Webapplikationen, Mailservern, VPN-Gateways und APIs. Sie erhalten einen priorisierten Bericht mit klaren Handlungsempfehlungen statt einer Liste von Einzelfunden. Unverbindlich Kontakt aufnehmen.