DENIC hat den betroffenen NSEC3-Hash-Bereich um 20:15 UTC mit einem neuen Schlüssel (Keytag 32911) neu signiert. Google DNS (8.8.8.8), Cloudflare (1.1.1.1) und Quad9 (9.9.9.9) antworten seither alle mit NOERROR. Das Problem ist vollständig behoben.
Früherer Stand: Ein Signing-Run um 20:33 UTC hatte zunächst nur den SOA-RRSIG aktualisiert, nicht aber den fehlerhaften NSEC3-RRSIG (Keytag 33834). Die endgültige Korrektur erfolgte durch einen weiteren gezielten Signing-Run mit Keytag 32911 um 20:15 UTC.
Zusammenfassung des Vorfalls
Am 5. Mai 2026 waren mehrere prominente .de-Domains für Nutzer mit DNSSEC-validierenden Resolvern nicht erreichbar. Betroffen waren unter anderem bahn.de, spiegel.de und blackfort-tec.de – Domains ohne gemeinsamen Betreiber, ohne gemeinsamen Hoster und ohne gemeinsame DNS-Infrastruktur.
Der gemeinsame Nenner: Alle betroffenen Domains lagen im selben NSEC3-Hash-Bereich der .de-Zone. Ein NSEC3-Record dieser Zone wurde mit einer fehlerhaften oder korrumpierten RRSIG-Signatur (Keytag 33834) ausgeliefert. Validierende Resolver stuften daraufhin die gesamte DNSSEC-Vertrauenskette als ungültig ein und antworteten mit SERVFAIL.
Die Beobachtungen sprechen dafür, dass es sich nicht um eine Fehlkonfiguration einzelner Domains handelte, sondern um einen transienten Fehler in der DNSSEC-Signaturinfrastruktur der DENIC – der deutschen ccTLD-Registry für .de.
Beobachtete Symptome: SERVFAIL trotz funktionierender Infrastruktur
Ausgangspunkt war der Browserfehler DNS_PROBE_FINISHED_NXDOMAIN für www.blackfort-tec.de. Eine erste Diagnose mit standardmäßigen DNS-Tools ergab jedoch, dass die Domain selbst vollständig korrekt konfiguriert war: A-Record vorhanden, Nameserver erreichbar, kein Konfigurationsfehler.
Browserfehler DNS_PROBE_FINISHED_NXDOMAIN oder allgemeine Nichterreichbarkeit für einen Teil der Nutzer, obwohl die DNS-Zone korrekt konfiguriert ist und die authoritative Nameserver die Domain einwandfrei auflösen.
Die direkte Abfrage gegen den autoritativen Nameserver (GoDaddy, ns81.domaincontrol.com) lieferte korrekte Antworten. Erst die Abfrage gegen validierende öffentliche Resolver zeigte das eigentliche Problem:
$ dig @8.8.8.8 www.blackfort-tec.de A ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL ; EDE: 6 (DNSSEC Bogus): (RRSIG with malformed signature found for ; a0d5d1p51kijsevll74k523htmq406bk.de/nsec3 (keytag=33834)) $ dig @9.9.9.9 blackfort-tec.de A ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL ; EDE: 6 (DNSSEC Bogus) $ dig @8.8.8.8 +cd blackfort-tec.de A # DNSSEC-Validierung deaktiviert ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; ANSWER SECTION: blackfort-tec.de. 600 IN A 178.104.208.93
Mit dem Flag +cd (Checking Disabled) – also mit deaktivierter DNSSEC-Validierung – war die Domain unmittelbar und korrekt auflösbar. Das Infrastrukturproblem lag damit eindeutig nicht beim Domainbetreiber, sondern in der DNSSEC-Validierungskette.
Technischer Befund: Fehlerhafte RRSIG für NSEC3 in der .de-Zone
Die weiterführende Analyse ergab ein präzises Fehlerbild. Bei einer DNSSEC-Abfrage für blackfort-tec.de liefern die DENIC-Nameserver zur Verneinung eines DS-Records (Delegation Signer) einen NSEC3-Record zurück. Dieser NSEC3-Record ist zwingend mit einem RRSIG signiert – und genau diese Signatur war fehlerhaft:
# DENIC-Nameserver liefert NSEC3 für blackfort-tec.de DS-Abwesenheit
$ dig @f.nic.de +dnssec blackfort-tec.de DS
;; AUTHORITY SECTION:
a0d5d1p51kijsevll74k523htmq406bk.de. 7200 IN NSEC3 1 1 0 - A0D5F6VE... NS SOA RRSIG DNSKEY NSEC3PARAM
a0d5d1p51kijsevll74k523htmq406bk.de. 7200 IN RRSIG NSEC3 8 2 7200 \
20260519191938 20260505174938 33834 de. DZhBfHZt+n/IFEdUgog...
# Google verweigert Validierung dieser Signatur:
; EDE: 6 (DNSSEC Bogus): (RRSIG with malformed signature found for
; a0d5d1p51kijsevll74k523htmq406bk.de/nsec3 (keytag=33834))Die DENIC-Zone-Signing-Infrastruktur hat für den NSEC3-Record im Hash-Bereich rund um blackfort-tec.de eine RRSIG-Signatur mit Keytag 33834 ausgeliefert, die von mehreren unabhängigen DNSSEC-validierenden Resolvern als malformed (fehlerhaft) eingestuft wurde. Die Signatur war formal vorhanden, bestand aber die kryptografische Verifikation nicht.
Bemerkenswert: Weder der DS-Record von blackfort-tec.de bei DENIC noch der DNSKEY bei GoDaddy waren falsch konfiguriert – es existierten gar keine. Die Domain verwendete kein DNSSEC. Das Problem lag ausschließlich in der DENIC-signierten Verneinungsaussage über die Nicht-Existenz dieses DS-Records.
Dasselbe fehlerhafte NSEC3-Signaturmuster trat identisch bei weiteren Domains desselben Hash-Bereichs auf – darunter spiegel.de und bahn.de – was den Bereichsfehler in der .de-Zone-Signierung bestätigt.
Warum nur bestimmte Nutzer betroffen waren
DNSSEC-Validierung ist kein universeller Standard. Ob ein Resolver kryptografische DNS-Signaturen prüft, liegt allein bei dessen Betreiber. Die folgende Tabelle zeigt das Verhalten der wichtigsten öffentlichen Resolver während des Vorfalls:
| Resolver | IP | DNSSEC-Validierung | Ergebnis |
|---|---|---|---|
| Google Public DNS | 8.8.8.8 | Ja (strikt) | SERVFAIL / DNSSEC Bogus |
| Cloudflare | 1.1.1.1 | Ja | SERVFAIL |
| Quad9 | 9.9.9.9 | Ja (strikt) | SERVFAIL / DNSSEC Bogus |
| ISP-Resolver (DE) | variabel | Nein / teilweise | NOERROR – Domain erreichbar |
Nutzer, die Google DNS, Cloudflare oder Quad9 als Resolver einsetzen – typischerweise technikaffine Nutzer, Entwickler, Unternehmen mit explizit konfiguriertem DNS oder moderne Betriebssysteme mit DoH/DoT – konnten die betroffenen Domains nicht erreichen. Nutzer der Standardkonfiguration vieler deutscher ISPs waren nicht betroffen.
Da DNSSEC-validierende Resolver in Deutschland noch eine Minderheit des Gesamttraffics ausmachen, blieben öffentliche Berichte zunächst aus – obwohl großvolumige Domains wie bahn.de oder spiegel.de betroffen waren. Dies erklärt, warum kein breit sichtbarer Incident Report entstand.
Was NSEC3 mit dem Ausfall zu tun hat
Zum Verständnis des Vorfalls ist ein kurzer Blick auf die DNSSEC-Mechanik hilfreich. Wenn ein validierender Resolver für eine Domain einen DS-Record (Delegation Signer) abfragt und dieser nicht existiert, muss die übergeordnete Zone dies kryptografisch beweisen – das ist die Aufgabe von NSEC3 (Next Secure 3).
NSEC3 liefert einen signierten Nachweis, dass im Namensraum der Zone zwischen zwei bekannten Hashes kein weiterer Eintrag existiert. Da NSEC3 mit gehashten Domainnamen arbeitet (SHA-1), deckt ein einziger NSEC3-Record einen definierten Hash-Bereich ab – und damit potenziell mehrere alphabetisch weit entfernte Domains.
Vereinfachter Ablauf der DNSSEC-Validierung
- 1Resolver fragt: „Existiert ein DS-Record für blackfort-tec.de?"
- 2DENIC antwortet: „Nein – hier ist der NSEC3-Beweis dafür, inkl. RRSIG."
- 3Resolver prüft: „Ist die RRSIG-Signatur über den NSEC3-Record gültig?"
- 4Antwort: „Nein, die Signatur ist malformed." → SERVFAIL.
Ein fehlerhafter NSEC3-Record in der übergeordneten Zone wirkt sich damit direkt auf alle Domains aus, die in diesen Hash-Bereich fallen – unabhängig davon, ob diese Domains selbst DNSSEC nutzen oder nicht.
Warum dies kein Fehler der einzelnen Domainbetreiber war
Die betroffenen Domains – bahn.de, spiegel.de, blackfort-tec.de – hatten zum Zeitpunkt des Vorfalls keinerlei DS-Records bei DENIC registriert. Keine der Domains verwendete aktiv DNSSEC. Dennoch waren sie betroffen, weil der DNSSEC-Validierungsprozess bei der Verneinung des DS-Records scheiterte.
Der Befund deutet darauf hin, dass die DENIC-Zone-Signing-Infrastruktur für einen bestimmten NSEC3-Hash-Bereich eine kryptografisch fehlerhafte RRSIG-Signatur ausgeliefert hat. Dieses Fehlerbild ist charakteristisch für einen transienten Fehler beim Zone-Signing-Prozess auf Ebene der TLD-Registry – etwa nach einem Zonen-Update, einer Key-Transition oder einem Fehler in der Signing-Pipeline.
Es existieren zwei grundlegend verschiedene DNSSEC-Fehlerklassen:
- →Fehler beim Domainbetreiber: Abgelaufene RRSIGs, falsch konfigurierte DS-Records, fehlende DNSKEY-Records – behebbar durch den Betreiber selbst.
- →Fehler auf TLD-Ebene (Registry): Fehlerhafte NSEC3-Signaturen in der übergeordneten Zone – nicht behebbar durch den Domainbetreiber, Behebung liegt ausschließlich bei der Registry (hier: DENIC).
Für Domainbetreiber bestand in diesem Fall keine sinnvolle eigene Handlungsoption. Die Meldung an DENIC oder den eigenen Registrar zur Weiterleitung war der einzig zielführende Weg. DENIC hat das Problem mit einem gezielten Signing-Run um 20:15 UTC behoben (Keytag 33834 → 32911). Nach TTL-Ablauf normalisierten sich die Resolver-Antworten vollständig.
Temporäre Workarounds und ihre Risiken
Kurzfristig standen betroffenen Nutzern und Betreibern folgende Optionen zur Verfügung – alle mit relevanten Einschränkungen:
- →Resolver wechseln: Umstieg auf einen nicht-validierenden Resolver (z. B. ISP-Resolver) ermöglicht die Auflösung, schwächt aber den DNSSEC-Schutz vollständig.
- →DNSSEC-Validierung lokal deaktivieren: Technisch möglich, sicherheitstechnisch nicht empfehlenswert.
- →Abwarten: DENIC hat das Problem am 05.05.2026 um 20:15 UTC durch einen gezielten Signing-Run behoben. Nach TTL-Ablauf (7.200 Sekunden) normalisierten sich die Resolver-Antworten automatisch.
⚠ Keiner dieser Workarounds ist als Dauerlösung geeignet. Sie dienen ausschließlich zur kurzfristigen Überbrückung bis zur Registry-seitigen Korrektur.
Für Unternehmen mit öffentlich erreichbaren Diensten ist der Wechsel zu einem nicht-validierenden Resolver insbesondere dann problematisch, wenn dieser Resolver auch für interne Sicherheitsprüfungen, TLS-Zertifikat-Validierung oder DNS-basierte Sicherheitskontrollen eingesetzt wird. DNS-Security darf nicht pauschal deaktiviert werden, um einen temporären Registry-Fehler zu umgehen.
Lessons Learned für Unternehmen
DNSSEC-Monitoring etablieren
Regelmäßige automatisierte Abfragen der eigenen Domains gegen mehrere validierende Resolver (Google, Cloudflare, Quad9) sollten fester Bestandteil des Security Monitorings sein. Alerting bei SERVFAIL oder DNSSEC-Bogus-Antworten ist kein Nice-to-have.
RRSIG-Ablauf überwachen
Abgelaufene DNSSEC-Signaturen sind eine häufige Ursache für DNSSEC-Ausfälle. Monitoring der Ablaufdaten aller relevanten RRSIGs gibt ausreichend Vorlaufzeit für Korrekturen.
Incident-Response-Prozess für DNS-Fehler
Nicht jeder DNS-Ausfall ist auf eigene Infrastruktur zurückzuführen. Der Incident-Response-Prozess sollte explizit den Fall abdecken, dass ein externer Akteur (Registry, Upstream-Resolver) die Ursache ist – inklusive Eskalationspfad zum Registrar.
Diagnosepfad kennen
Bei DNS_PROBE_FINISHED_NXDOMAIN immer zunächst gegen den autoritativen Nameserver testen (+cd-Flag). Erst wenn dieser korrekte Antworten liefert, liegt das Problem upstream. Dann: DNSSEC-Validierung prüfen, Resolver isolieren.
Registrar-Kommunikation vorbereiten
Für DNSSEC-Fehler auf TLD-Ebene ist der Registrar der erste Ansprechpartner. Dieser hat den direkten Kanal zur Registry. Ein dokumentierter Fehlerbefund (dig-Output, betroffene Resolver, Zeitstempel) beschleunigt die Eskalation erheblich.
DNSSEC-Status in SIEM integrieren
DNSSEC-Monitoring gehört in dasselbe SIEM wie Certificate Monitoring und Availability Checks. Nur so sind Korrelationen zwischen DNS-Ausfällen und anderen Sicherheitsereignissen erkennbar.
Fazit: DNSSEC-Monitoring gehört in jedes Security Monitoring
Der hier beschriebene Vorfall illustriert eine wichtige, oft unterschätzte Angriffsfläche moderner Internetinfrastruktur: die DNSSEC-Vertrauenskette. Selbst Domains, die korrekt konfiguriert sind und kein DNSSEC aktiv nutzen, können durch Fehler in der übergeordneten Zone selektiv unerreichbar werden – für genau die Nutzer, die den höchsten Sicherheitsstandard verwenden.
Für Unternehmen bedeutet dies: DNS ist keine Set-and-forget-Infrastruktur. Die Abhängigkeit von einer fehlerfreien DNSSEC-Signaturkette – von der Root-Zone über die TLD-Registry bis zum eigenen Nameserver – erfordert kontinuierliches Monitoring, dokumentierte Incident-Response-Prozesse und klare Eskalationspfade zum Registrar.
Die Tatsache, dass Domains wie bahn.de und spiegel.de ohne öffentlichen Aufschrei betroffen waren, zeigt zudem: DNS-Ausfälle dieser Art passieren lautlos – sichtbar nur für jene, die proaktiv hinschauen.