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

5 Min Lesezeit Serie: dns #dns#dnssec#infrastructure#postmortem

Am Abend des 5. Mai 2026 lieferte die .de-Zone fehlerhafte DNSSEC-Signaturen aus. Validierende Resolver verwarfen sämtliche Antworten als ungültig. Was passiert ist, warum DNSSEC genau so reagieren muss und wie wir bei Dernium auf solche Vorgänge schauen.

Problem

Am 5. Mai 2026 ab etwa 21:57 Uhr lieferten die autoritativen Nameserver der .de-Zone Antworten aus, deren DNSSEC-Signaturen 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-Domain 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 einen Rückabwicklung der neuen Schlüssel-Generation auf den vorhergehenden Stand. Der Einschlagskratzer wäre weitaus größer gewesen (mit potenziell bis zu Milliardenverlusten) wenn dies tagsüber passiert wäre.

Kurze Antwort

Eine routinemäßige Rotation des Zone-Signing-Keys in der .de-Zone erzeugte ungültige Signaturen, prominent für den SOA-Record am Apex. Validierende Resolver mussten die Antworten verwerfen; das ist die korrekte und gewollte Reaktion von DNSSEC. Die Behebung war kein Problemlösung im engeren Sinne, sondern eine vollständige Rückabwicklung auf den vorherigen Zustand. Geplante weitere Schlüsselwechsel hat DENIC nun 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), sondern auch die zugehörige Signatur RRSIG. Validierende Resolver prüfen, ob diese RRSIG mit einem der für die Zone autorisierten DNSKEYs kryptografisch übereinstimmt. Stimmt sie nicht, wird die gesamte Antwort gemäß RFC 4035, Abschnitt 5 als bogus (= "falsch") markiert und verworfen.

Ein weiterer Eintrag, der SOA-Record ist dabei besonders heikel. Er liegt am Apex (= der Spitze) der DNS-Zone und wird in nahezu jeder negativen Antwort (NXDOMAIN, NODATA) 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): pre-publish (der neue Key wird zuerst per DNSKEY-Set veröffentlicht und erst nach Ablauf der DNSKEY-TTLs 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 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 haben und ein Resolver die als bogus erkannte Antwort kurzzeitig negativ cachen kann (Details in RFC 8767 zur Behandlung von stale data). 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.

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, MTA-STS und DANE 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.

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 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.
  • 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 veröffentlicht.