Wie ein Schlüsselwechsel die .de-Zone für drei Stunden ungültig machte

Problem

Am 5. Mai 2026 ab etwa 21:57 Uhr lieferten die autoritativen Nameserver (die für eine Domain-Zone offiziell zuständigen DNS-Server) der .de-Zone Antworten aus, deren DNSSEC-Signaturen (kryptografische Echtheitssiegel für DNS-Antworten) sich nicht mehr gegen den dort veröffentlichten Zone-Signing-Key validieren ließen. DNS-Server, die den DNSSEC-Schutz aktiv haben (die meisten großen Provider und alle sicherheitsbewussten On-Premise-Resolver), verwarfen die Antworten als "Ungültig" und weigerten sich, .de-Domains funktional aufzulösen. Der Effekt: Webseiten, App-Backends und VPN-Gateways unter .de-Namen wirkten für die betroffenen Nutzer schlicht nicht erreichbar. Wiederhergestellt wurde der Normalbetrieb gegen 01:15 Uhr am 6. Mai durch eine Rückabwicklung der neuen Schlüssel-Generation auf den vorhergehenden Stand. Der Schaden wäre weitaus größer gewesen, wenn dies tagsüber passiert wäre.

Für wen ist das? Für Domain- und DNS-Verantwortliche, die DNSSEC-Risiken verstehen wollen.

Kurze Antwort

Eine routinemäßige Rotation (turnusgemäßer Wechsel) des Zone-Signing-Keys in der .de-Zone erzeugte ungültige Signaturen, prominent für den SOA-Record am Apex (siehe unten). Validierende Resolver mussten die Antworten verwerfen; das ist die korrekte und gewollte Reaktion von DNSSEC.

• Ursache: ein misslungener Schlüsselwechsel, kein Angriff.
• Symptom: .de-Domains waren für DNSSEC-prüfende Resolver vorübergehend nicht auflösbar.
• Reaktion der Resolver: korrekt - eine fehlerhafte Signatur ist von einer manipulierten nicht zu unterscheiden.
• Behebung: keine eigentliche Reparatur, sondern eine vollständige Rückabwicklung auf den vorherigen Zustand.
• Folge: DENIC (die Registry, die die .de-Zone betreibt) hat weitere geplante Schlüsselwechsel bis zur Klärung der Ursache ausgesetzt.

Tiefgang

Warum eine ungültige SOA-Signatur die ganze Zone abschaltet

Eine DNS-Antwort enthält nicht nur den eigentlichen Datensatz (etwa A oder AAAA, die Records für IPv4- bzw. IPv6-Adressen), sondern auch die zugehörige Signatur RRSIG (das DNSSEC-Echtheitssiegel eines Datensatzes). Validierende Resolver prüfen, ob diese RRSIG mit einem der für die Zone autorisierten DNSKEYs (den veröffentlichten öffentlichen Schlüsseln der Zone) kryptografisch übereinstimmt. Stimmt sie nicht, wird die gesamte Antwort gemäß RFC 4035, Abschnitt 5 (RFC = offizielles Internet-Standarddokument) als bogus (= "falsch") markiert und verworfen.

Ein weiterer Eintrag, der SOA-Record (Start of Authority, der Verwaltungs-Stammeintrag einer Zone) ist dabei besonders heikel. Er liegt am Apex (= der Spitze, dem Wurzelpunkt) der DNS-Zone und wird in nahezu jeder negativen Antwort (NXDOMAIN = Name existiert nicht, NODATA = Name existiert, aber ohne den gefragten Eintrag) als Beweis für die Autorität mitgeschickt; das technische Verfahren dazu beschreibt RFC 4034, Abschnitt 6. Geht die SOA-Signatur kaputt, fallen damit nicht nur Existenz-Antworten der Apex-Zone auseinander, sondern jede Antwort, die zur Vollständigkeit den SOA mitführt. Praktisch heißt das: keine .de-Auflösung mehr, egal welcher Subdomain.

Anatomie eines ZSK-Rollovers

RFC 6781 beschreibt zwei sichere Verfahren für den Wechsel eines Zone-Signing-Keys (ZSK, der Schlüssel, mit dem die einzelnen Einträge einer Zone signiert werden): pre-publish (der neue Key wird zuerst per DNSKEY-Set veröffentlicht und erst nach Ablauf der DNSKEY-TTLs (der Cache-Gültigkeitsdauern) zum Signieren genutzt) und double-signature (alle Records werden eine Zeit lang mit beiden Keys parallel signiert). Beide Wege haben gemein, dass das öffentliche Schlüsselmaterial bereits aktiv von der Welt genutzt wird, bevor erstmals damit signiert wird.

In so einem Moment hängt alles an drei Schichten: dem privaten Schlüsselmaterial, dem Signier-Code und der Verteilung der frisch signierten Zone an alle autoritativen Nameserver. Welche der drei Schichten die ungültigen Signaturen produziert hat, hat DENIC bislang nicht öffentlich gemacht. Sicher ist nur das Symptom: die im DNSKEY-Set veröffentlichten Public-Key-Daten und die Signaturen, die in dieser Nacht zur Auslieferung kamen, passten kryptografisch nicht zueinander.

Warum die DNS-Server "richtig" gehandelt haben

Das verwirrt im ersten Moment, ist aber genau der Sinn der Übung. DNSSEC ist dazu gebaut, Authentizität zu garantieren, beschrieben in RFC 4033, Abschnitt 5. Ein Resolver, der bogus-Antworten brav weiterreichen würde, könnte damit den gesamten Schutzmechanismus aushebeln, denn ein echter Angreifer, der Zonen-Inhalte manipuliert, würde dieselbe Symptomatik erzeugen wie der jetzige Fall eines missglückten Rollovers. Der Resolver kann beides nicht unterscheiden und soll und muss deshalb auf Sicherheit setzen.

Als klar war, dass es sich hier um ein systematisches Problem (und nicht um einen Angriff) handelte, haben manche Resolver-Betreiber kurzzeitig die DNSSEC-Validierung abgeschaltet, um .de wieder erreichbar zu machen. Das funktioniert, schaltet aber für die Dauer der Maßnahme die Authentizitätsprüfung für alle Zonen ab, nicht nur für die fehlerhafte. Es ist ein Notfall-Werkzeug, kein Reparatur-Werkzeug, und gehörte direkt nach der Wiederherstellung wieder eingeschaltet.

Der Rollback und der Cache-Schwanz

Der Rückbau setzt das DNSKEY-Set wieder auf den Stand vor dem fehlerhaften Wechsel, womit die alten, weiterhin gültig signierten Records konsistent zum publizierten Schlüsselmaterial werden. Bis sich diese Information durch die Caches der Welt zieht, vergeht eine Weile, weil RRSIGs eigene TTLs (Cache-Gültigkeitsdauern) haben und ein Resolver die als bogus erkannte Antwort kurzzeitig negativ cachen kann (Details in RFC 8767 zur Behandlung von stale data, also abgelaufenen Daten). Daher waren auch nach der formellen Behebung noch eine Weile Reststörungen sichtbar.

Abgelehnte Alternativen

"DNSSEC abschalten und das Problem ignorieren." Verlockend nach so einem Vorfall, aber falsch. Die Alternative zu DNSSEC ist nicht ein ausfallsicheres DNS, sondern ein DNS, in dem niemand merkt, wenn jemand einen Angriff fährt und Domains auf die eigenen (manipulierten!) Server umbiegt. Die einzig sinnvolle Konsequenz ist, an Test-Verfahren für Schlüsselwechsel zu arbeiten, nicht den Schutzmechanismus aufzugeben.

"Resolver sollen tolerant sein." RFC 4033 nennt das ausdrücklich nicht als Option. Toleranz gegenüber bogus-Antworten ist gleichbedeutend mit Toleranz gegenüber absichtlich gefälschten Antworten. Ein Resolver, der das tut, ist als Sicherheitskomponente wertlos.

Was Sie jetzt tun sollten

Als Betreiber von Diensten unter .de-Namen oder als Verantwortlicher für Resolver lohnen sich diese Schritte:

1. DNSSEC nicht abschalten. Lassen Sie die Validierung aktiv; sie hat hier korrekt gewarnt. Eine dauerhafte Abschaltung tauscht eine seltene Störung gegen ein stilles, dauerhaftes Sicherheitsrisiko.
2. Eigene .de-Zonen überwachen. Richten Sie eine externe Prüfung ein, die dig +dnssec gegen Ihre wichtigen Domains laufen lässt und Alarm schlägt, wenn der ad-Flag (siehe Verifikation) fehlt.
3. Notfallplan für Resolver dokumentieren. Halten Sie fest, unter welchen klar definierten Bedingungen und wie lange die Validierung im Notfall ausgesetzt wird - und dass sie unmittelbar danach wieder eingeschaltet wird.
4. DANE/MTA-STS-Abhängigkeiten kennen. Prüfen Sie, welche Ihrer Mail- und TLS-Sicherheitsmechanismen auf DNSSEC aufsetzen, damit Sie im Störfall die Folgewirkung einordnen können.
5. Auf das Postmortem warten und nachsteuern. Lesen Sie den vollständigen Bericht von DENIC, sobald er vorliegt, und passen Sie Ihre Erwartung an die Wiederholungswahrscheinlichkeit an.

Wie Dernium hier hilft

Beobachtung von DNS- und DNSSEC-Zustand ist Tagesgeschäft eines Monitoring-Stacks. Dernium Watch ist genau dafür gebaut, Antworten produktiv genutzter DNS-Zonen aus mehreren Sichtachsen abzufragen und Auffälligkeiten, also neben dem Umlenken von Adressen auch frische bogus-Zustände beim eigenen Provider, innerhalb von wenigen Minuten aufzuzeigen, statt erst dann, wenn Ihr Support von zunächst unklaren Tickets ("die Seite geht nicht") überrollt wird. Dernium Mailcheck hängt eng am DNS, weil DMARC (Regelwerk gegen E-Mail-Fälschung), MTA-STS (erzwungene Transportverschlüsselung für E-Mail) und DANE (DNS-gestützte Bindung von TLS-Zertifikaten) allesamt DNS- und DNSSEC-getragen sind; ein Vorfall wie dieser legt für die Dauer der Störung nämlich auch praktisch jede DANE-Validierung in der betroffenen Zone lahm. Ob die DNSSEC-Kette einer Zone gerade sauber validiert, können Sie mit dem DNSSEC-Chain-Validator unter den kostenlosen Webtools selbst nachsehen.

Verifikation

Wer den Vorfall oder den Normalzustand selbst nachprüfen will, kommt mit Standard-Werkzeugen aus.

• Aktuelle Validierung auf einem kommerziellen DNS-Server: dig +dnssec de. SOA @1.1.1.1. Der ad-Flag (authenticated data) in der Antwort signalisiert eine geglückte DNSSEC-Validierung durch den Resolver.
• Schlüsselmaterial im Klartext: dig +short DNSKEY de. listet die aktuell autorisierten KSK- und ZSK-Records (KSK = Key-Signing-Key, der Schlüssel, der die Schlüssel signiert; ZSK = Zone-Signing-Key, der die Daten signiert).
• Vorfallsbericht der .de-Registry selbst: DENIC-Blog vom 6. Mai 2026 mit Zeitfenster und Maßnahmen.
• DNSSEC-Standards: RFC 4033 für Konzept und Validierungs-Vertrag, RFC 6781 für die operativen Verfahren beim Schlüsselwechsel.

Offene Punkte

DENIC hat zum Zeitpunkt dieses Artikels weder die genaue technische Ursache (Schlüsselmaterial, Signier-Pipeline oder Verteilung) noch erläutert, warum der defekte Stand nicht in einer Vorab-Validierung gegen einen unabhängigen Resolver auffiel. Beide Fragen sind für die Bewertung der Wiederholungswahrscheinlichkeit relevant. Solange die Antworten ausstehen, bleiben weitere ZSK-Wechsel an der .de-Wurzel ein Betriebsrisiko, das man als nachgelagerter Operator nur reaktiv beobachten kann; ein Aktualisierungs-Artikel folgt, sobald DENIC einen vollständigen Postmortem (eine technische Nachbetrachtung) veröffentlicht.

Häufige Fragen

War das ein Angriff auf die .de-Domains?

Nein. Ursache war ein misslungener routinemäßiger Schlüsselwechsel bei der Registry, kein böswilliger Eingriff. Das Symptom sah aber genauso aus wie ein Angriff, und genau deshalb haben die prüfenden DNS-Server die Antworten zu Recht verworfen - sie können einen Fehler nicht von einer echten Manipulation unterscheiden.

Warum waren manche Nutzer betroffen und andere nicht?

Betroffen waren Nutzer, deren DNS-Resolver die DNSSEC-Signaturen prüft - das tun die meisten großen Provider und sicherheitsbewusste eigene Resolver. Wer einen Resolver ohne DNSSEC-Prüfung nutzte, bekam die ungültig signierten Antworten ungeprüft ausgeliefert und merkte nichts, gab dabei aber den Echtheitsschutz auf.

Sollte ich DNSSEC abschalten, damit so etwas nicht wieder passiert?

Nein. Ohne DNSSEC fällt nicht das Problem weg, sondern nur die Warnung davor. Ein Angreifer könnte dann Ihre Domain unbemerkt auf eigene Server umlenken. Die richtige Lehre ist, Schlüsselwechsel besser vorab zu testen und den eigenen Zustand zu überwachen, nicht den Schutz zu entfernen.

Wie merke ich künftig schnell, dass meine .de-Domain betroffen ist?

Lassen Sie von außen regelmäßig dig +dnssec gegen Ihre wichtigen Domains laufen und prüfen Sie, ob der ad-Flag gesetzt ist. Ein Monitoring, das diesen Flag und die Auflösbarkeit überwacht, schlägt innerhalb weniger Minuten Alarm - lange bevor sich Störungen als unklare Support-Tickets bemerkbar machen.

Wieso dauerte die Erholung auch nach der Behebung noch an?

DNS-Antworten und ihre Signaturen werden in Caches mit einer Gültigkeitsdauer (TTL) zwischengespeichert, und ein als fehlerhaft erkanntes Ergebnis kann kurzzeitig negativ gecacht werden. Nach dem Rückbau musste sich der korrekte Stand erst durch diese Caches weltweit verbreiten, weshalb einzelne Nutzer noch eine Weile Reststörungen sahen.