Zusammenfassung

  • Eine noch korrekt signierte und ausgelieferte Zone ist nach dem Ausfall eines privaten Schlüssels ein zeitlich begrenzter Altbestand, keine Bestätigung dafür, dass der Schlüssel oder die Signierfähigkeit wiederhergestellt wurde.
  • ZSK, KSK und CSK erzwingen unterschiedliche Übergänge: Pre-Publication für den unbrauchbaren ZSK, Double-DS für den unbrauchbaren KSK und ein längeres, angepasstes Double-DS-Verfahren für den CSK.
  • Erst eine Beweiskette über Parent und Child, alle autoritativen Instanzen, Cache-Zeiten, positive und negative Antworten, ZONEMD sowie unabhängige Resolver und Anwendungen rechtfertigt die Aussage, die Funktion sei wiederhergestellt.

Die trügerische Ruhe nach dem Schlüsselverlust

Die Alarmmeldung kann eindeutig sein: Der private Teil eines DNSKEY ist nicht mehr verwendbar. Das HSM ist ausgefallen, die Schlüsseldatei lässt sich nicht öffnen, oder die letzte funktionsfähige Kopie ist verloren. Dennoch beantworten die autoritativen Nameserver Abfragen weiter mit NOERROR, und validierende Resolver melden Secure. Für den Betrieb sieht das zunächst besser aus, als die Lage tatsächlich ist. Die Server erzeugen in diesem Moment keine neue kryptografische Zukunft. Sie geben einen bereits signierten Zustand aus, dessen Beweise mit jeder Sekunde altern.

Das ist der Ausgangspunkt von draft-ietf-dnsop-dnssec-keyrestore-02. Bei der Überprüfung am 13. September 2026 führte der IETF Datatracker das Dokument als aktiven Internet-Draft der DNSOP Working Group, Revision 02, zuletzt aktualisiert am 10. August 2026. Es ist kein RFC. Der Entwurf von Florian Obser und Martin Pels ist als „work in progress“ zu behandeln, hat den vorgesehenen Status Informational und soll am 11. Februar 2027 ablaufen, falls er vorher nicht fortgeschrieben wird. Seine Verfahren gelten für Architekturen mit vorsignierten Records. Online Signing und die Root-Zone liegen außerhalb seines Anwendungsbereichs; bei der Root-Zone kann die Verteilung neuer Trust Anchors länger dauern als die Lebenszeit vorhandener RRSIGs.

Der Entwurf trennt zwei Dinge, die im Krisenmodus leicht vermischt werden. „Inoperable“ bedeutet, dass der private Teil eines DNSKEY in der Vertrauenskette nicht mehr signieren kann. Ein kompromittierter, aber technisch noch verwendbarer Schlüssel ist ein anderes Problem. Und wenn keine funktionsfähige Sicherung existiert, lässt sich der verlorene Schlüssel nicht zurückholen. Wiederhergestellt werden kann nur die Signierfunktion der Zone, gestützt auf eine vollständige Kopie des zuletzt korrekt DNSSEC-signierten Zonenstands, die etwa noch auf einem autoritativen Server vorhanden ist.

Geliehene Zeit mit mehreren Ablaufkanten

Ein RRSIG trägt Beginn und Ende seiner Gültigkeit. Solange die Signatur nicht abgelaufen ist, der zugehörige DNSKEY angeboten wird und die Kette zum DS des Parent passt, kann ein Resolver einen vorhandenen RRset weiterhin validieren. Viele Signaturen haben eine Restlaufzeit von Tagen. Diese Zeit ist jedoch kein einzelner Countdown. Sie wird gleichzeitig durch die früheste relevante RRSIG-Expiration, DNSKEY-, DS- und Signatur-TTLs, Übertragungs- und Registrierungsverzögerungen sowie die tatsächliche Ausbreitung über autoritative Systeme begrenzt.

Der Betreiber kann das Fenster sogar selbst verkürzen. Entfernt der Signer den alten DNSKEY automatisch, verwirft er alte RRSIGs oder verändert er Records, die der unbrauchbare Schlüssel nicht erneut signieren kann, geht ein noch brauchbarer Altzustand verloren. Deshalb darf der Signer DNSKEYs erst nach ausdrücklicher Anweisung entfernen und sollte alte RRSIGs behalten. Kann die Software das nicht, müssen vor der Veröffentlichung alle alten Signaturen außer der alten Signatur des DNSKEY-RRsets manuell wieder eingesetzt werden. Ein gleichzeitiger Algorithmuswechsel vergrößert die Zahl der veränderlichen Teile.

Sofern er nicht bereits lief, sollte zunächst mit dem bestehenden Algorithmus die Funktion wiederhergestellt und erst danach ein gewöhnlicher Algorithm Rollover vorgenommen werden.

RFC 7583 liefert dafür die präzise Zustandslogik: veröffentlicht, bereit, aktiv, zurückgezogen und tot sind verschiedene Phasen. Sichtbarkeit ist nicht Bereitschaft; Bereitschaft ist nicht Aktivierung; erfolgreiche Aktivierung ist nicht die Erlaubnis zur Entfernung des alten Materials. RFC 6781 beschreibt die bekannten Verfahren Pre-Publication, Double-Signature und Double-DS. Im Notfall sind sie keine frei austauschbaren Rezepte. Welcher Weg möglich ist, hängt davon ab, welcher private Schlüssel verloren ist und welche Alt-Signaturen noch erhalten sind.

Wenn der ZSK ausfällt: Veröffentlichung vor Aktivierung

Bei getrenntem KSK und ZSK kann ein funktionsfähiger KSK den DNSKEY-RRset weiterhin signieren, obwohl der alte ZSK keine neuen Signaturen für Zonendaten mehr erzeugt. Die Zone darf zunächst nicht inhaltlich geändert werden. Der brauchbare Weg ist Pre-Publication.

Zum Zeitpunkt Tpub wird der neue ZSK in den DNSKEY-RRset aufgenommen. Der alte, unbrauchbare ZSK und seine RRSIGs bleiben erhalten. Normalerweise wird die SOA nur wegen dieses Schritts nicht geändert. Alle Secondaries und autoritativen Instanzen müssen dennoch gezielt den neuen Stand laden. Danach läuft das Veröffentlichungsintervall Ipub = Dprp + TTLkey: Dprp ist die Zeit bis zur Verbreitung auf alle autoritativen Instanzen, TTLkey die TTL des DNSKEY-RRsets. Erst bei Trdy = Tpub + Ipub ist der neue ZSK bereit. Davor können Resolver noch einen DNSKEY-RRset aus dem Cache besitzen, in dem der neue Schlüssel fehlt.

Nach Trdy darf die Zone geändert und mit dem neuen ZSK signiert werden. Alte RRSIGs können dann entfernt werden, doch der alte ZSK bleibt vorerst im DNSKEY-RRset. Seine Entfernung wartet das Rückzugsintervall Iret = Dsgn + Dprp + TTLsig ab. Darin stecken die Signierverzögerung, die Ausbreitung zu den autoritativen Instanzen und die maximale TTL der RRSIGs. Ein theoretischer Double-Signature-Weg ist für diese Wiederherstellung langsamer, weil Zonendaten bis zum Ende von Dsgn + Dprp + max(TTLkey, TTLsig) unverändert bleiben müssten.

Die entscheidende Grenze lautet: Ein auf einem Server sichtbarer neuer ZSK beweist nur lokale Veröffentlichung. Er belegt weder, dass jede Anycast- oder Unicast-Instanz ihn anbietet, noch dass alle Resolver ihre zuvor gecachten DNSKEY-Sätze ersetzt haben. Erst Beobachtungen nach dem vollständigen Veröffentlichungsintervall machen Aktivierung vertretbar.

Wenn der KSK ausfällt: Der Parent bestimmt den frühesten Termin

Ist bei getrennten Rollen der KSK unbrauchbar, kann er einen veränderten DNSKEY-RRset nicht mehr signieren. Pre-Publication allein hilft deshalb nicht. Der Übergang muss über Double-DS laufen. Sind KSK und ZSK gleichzeitig unbrauchbar, wird zuerst die KSK-Funktion wiederhergestellt; der ZSK folgt erst danach über den zuvor beschriebenen Weg.

Der neue DS wird zum Zeitpunkt Tsbm beim Parent eingereicht. Eine Bestätigung des Registrars oder Registry-Systems ist nur ein Verwaltungsbeleg. Nach der Registrierungsverzögerung Dreg erscheint der DS zum Zeitpunkt Tpub in der Parent-Zone. Auch das reicht nicht: Es folgt IpubP = DprpP + TTLds, also die Ausbreitung auf jede autoritative Parent-Instanz plus die DS-TTL. Erst Trdy = Tpub + IpubP macht den neuen KSK bereit.

Bei der Aktivierung wird der neue KSK in den DNSKEY-RRset der Child-Zone aufgenommen und signiert diesen RRset. Der alte unbrauchbare KSK kann aus dem Child-DNSKEY-RRset verschwinden, während der ZSK bestehen bleibt. Der alte DS beim Parent muss jedoch noch Iret = DprpC + TTLkey nach der Aktivierung erhalten bleiben. So können Resolver, die noch den alten Child-DNSKEY-RRset gecacht haben, ihre Kette weiterhin aufbauen. Der früheste Zeitpunkt zur Entfernung lautet Trem = Tact + Iret.

Das Ereignis „DS akzeptiert“ und das Ereignis „DS auf allen Parent-Servern veröffentlicht und durch die Caches gelaufen“ liegen somit auf zwei verschiedenen Beweisachsen. Wer sie in einem grünen Status zusammenzieht, verschiebt die Entscheidungsgewalt unbemerkt vom beobachtbaren DNS in ein Verwaltungsportal.

Wenn der CSK ausfällt: Ein Schlüssel, ein längerer Übergang

Ein CSK signiert sowohl den DNSKEY-RRset als auch die übrigen Zonendaten. Fällt sein privater Teil aus, bleibt nur ein angepasstes Double-DS-Verfahren. Zuerst wird der neue DS beim Parent veröffentlicht. Nach Dreg sowie IpubP = DprpP + TTLds kann der neue CSK aktiviert werden. Dann wird er zum Child-DNSKEY-RRset hinzugefügt und signiert diesen. Der alte unbrauchbare CSK und alle seine noch benötigten RRSIGs bleiben erhalten; eine riskante SOA-Änderung wird vermieden, und Secondaries werden zum Laden gezwungen.

Das Rückzugsintervall ist länger als im reinen KSK-Fall: Iret = Dsgn + DprpC + max(TTLkey, TTLsig). Erst bei Trem = Tact + Iret dürfen alter Parent-DS, alter CSK und alte Signaturen gemeinsam entfernt werden. Erst dann können normale Zonenänderungen wieder beginnen. Der lange Überlapp ist kein übertriebener Puffer. Er schützt gleichzeitig Resolver mit alten DS-Daten, alte DNSKEY-Sätze und Signaturen auf Zonendaten.

Der gemeinsame Zustand kann trotz gültiger Signaturen brechen

Beim Wiederherstellen eines ZSK oder CSK sollte die SOA nicht bloß wegen des neuen DNSKEY geändert werden. Der alte Schlüssel kann die veränderte SOA nicht signieren. Antworten auf bestehende Records mögen weiterhin gültig sein, während Beweise für die Nichtexistenz eines Namens oder Typs Bogus werden. NSEC und NSEC3 enthalten nicht nur Ketten über Namen, sondern auch Type Bitmaps. Schon das erstmalige Hinzufügen von CDS oder CDNSKEY am Apex verändert diese Aussage und verlangt eine neue Signatur.

Das ist besonders wichtig, wenn CDS/CDNSKEY normalerweise Parent-Updates automatisieren. RFC 8078 beschreibt diese Automatisierung, doch bei einem unbrauchbaren ZSK oder CSK kann ein neu eingeführter CDS/CDNSKEY nicht zuverlässig kryptografisch validiert werden. Die Parent-Änderung muss dann möglicherweise über einen manuellen, außerhalb dieses Signalkanals abgesicherten Weg erfolgen. RFC 10026 unterstreicht die Bedeutung nachvollziehbarer Parent-Entscheidungen; auch sie ersetzen nicht die spätere DNS-Beobachtung.

Eine Änderung des DNSKEY-RRsets macht außerdem einen veröffentlichten ZONEMD-Digest ungültig. Ein neuer Digest muss für den veränderten Zoneninhalt erzeugt und mit DNSSEC signiert werden. RFC 8976 behandelt ZONEMD, seine RRSIG und die Konstruktion von NSEC oder NSEC3 als geordnete Einheit. Ein gültiger ZONEMD-Nachweis spricht für die Integrität des Zoneninhalts im Rahmen seines Schemas. Er ersetzt weder die Validierung der Delegationskette noch die Beobachtung eines laufenden Dienstes.

Auch die Verteilung an Secondaries ist eine eigenständige Fehlerfläche. Ohne SOA-Erhöhung kann die gewöhnliche serialbasierte Konvergenz ausbleiben. NOTIFY, AXFR und IXFR aus RFC 1996 und RFC 9103 liefern Mechanismen und Protokollsignale, aber kein automatisches Endergebnis. Ein identischer SOA-Serial ist ein nützlicher Versionshinweis, kein kryptografischer Beweis für identischen Inhalt. Für jede Secondary und jedes Backend wird ein Lade- oder Transferbeleg benötigt, gefolgt von einer Abfrage des tatsächlich ausgelieferten Zustands.

Acht Beobachtungen, acht begrenzte Aussagen

Die Wiederherstellung scheitert häufig nicht an fehlenden Daten, sondern an zu großen Schlussfolgerungen aus kleinen Beobachtungen.

  1. Ein alter DNSKEY und ein nicht abgelaufenes altes RRSIG auf einem autoritativen Server zeigen, dass dieser Server zu diesem Zeitpunkt einen prüfbaren Altzustand ausgeben kann. Sie sagen nichts über das Vorhandensein des privaten Schlüssels, neue Signaturen oder andere Server.
  2. Ein neuer DNSKEY auf einem Server belegt einen Veröffentlichungspunkt, nicht vollständige autoritative Verbreitung und nicht den Ablauf jedes alten Cache-Eintrags.
  3. Die Annahme eines DS durch Registrar oder Registry belegt höchstens Einreichung und administrative Verarbeitung, nicht Parent-Publikation, Parent-Verbreitung, Ablauf von TTLds oder Resolver-Sichtbarkeit.
  4. Ein mit dem neuen Schlüssel validierendes RRSIG beweist genau die Beziehung zwischen einem RRset, dieser Signatur und diesem Schlüssel zu diesem Zeitpunkt. Es beweist keine vollständige Neusignierung, keine kohärenten Denial-of-Existence-Beweise und keine sichere Entfernung des alten Pfads.
  5. Ein übereinstimmender SOA-Serial unterstützt die Transferdiagnose, sagt aber nicht, dass jedes Byte und jeder abgeleitete NSEC/NSEC3-Zustand gleich ist.
  6. Eine gültige NSEC- oder NSEC3-Antwort belegt eine negative Antwort, nicht jede Name-Type-Kombination auf jedem Server.
  7. Secure bei einem validierenden Resolver belegt dessen Kette und Cache-Zustand in diesem Augenblick. Es ist keine Volkszählung aller rekursiven Caches.
  8. Erfolgreiches HTTP, TLS oder eine funktionierende Anwendung nach der Auflösung zeigt einen erreichbaren Anwendungspfad. Es sagt nicht, dass alle DNS-Clients validieren oder der Übergang geschlossen werden darf.

Die Begriffe Secure und Bogus folgen der DNSSEC-Validierungslogik aus RFC 4034, RFC 4035 und RFC 9364. Diese technische Semantik ist unverzichtbar, darf aber nicht mit geschäftlicher Kontinuität gleichgesetzt werden.

Eine Beweiskette statt eines Erfolgsscreenshots

Vor jedem Eingriff steht eine unveränderliche Sicherung der letzten guten, vollständig signierten Zone. Dazu gehören Inventare von DNSKEY und DS, Beginn und Ablauf aller relevanten RRSIGs, SOA, NSEC oder NSEC3 und ZONEMD. Dieses Bild setzt den letzten Zeitpunkt fest, an dem Altzustand und Restlaufzeiten gemeinsam bekannt waren.

Danach muss jede autoritative Instanz separat beobachtet werden: alter Zustand erhalten, neues Material vorhanden, tatsächlich ausgelieferte DNSKEY- und RRSIG-Sätze, positive und negative Antworten. Wo Anycast die direkte Zuordnung erschwert, sind Messungen über unterschiedliche Standorte und kontrollierbare Backends nötig. Auf Parent-Seite werden DS-Antrag, Annahme, Veröffentlichung auf den autoritativen Servern und das Ende der DS-TTL als getrennte Ereignisse geführt.

Auf Child-Seite gilt dasselbe für Veröffentlichung, Bereitschaft und Aktivierung des Ersatzschlüssels, vollständige Neusignierung, Verbreitung und spätere Entfernung des alten Materials.

Unabhängig betriebene rekursive Resolver müssen mit kalten und warmen Caches, aus mehreren Netzen und zu wiederholten Zeitpunkten geprüft werden. Die Testmenge umfasst gewöhnliche positive Antworten, DNSKEY und DS, bewusst negative Namens- und Typabfragen sowie RRSIG-Laufzeiten. Das Leeren eines einzigen Testresolver-Caches erzeugt einen günstigen Laborzustand, aber keinen Beleg für das Internet. Da globale Resolver-Caches nicht inventarisierbar sind, bleibt der konservative Zeitplan eine aus beobachteter Veröffentlichung und bekannten TTL-Grenzen gebaute Zusicherung, keine Messung jedes Clients.

Parallel werden Ladebestätigungen der Secondaries, Konsistenz von SOA und Denial Records sowie ein neu erzeugter und signierter ZONEMD geprüft. Anwendungstests aus mehreren Netzen laufen während des gesamten Überlapp- und Rückzugsintervalls weiter. Haltepunkte sind ausdrücklich: Kein alter DS, DNSKEY oder RRSIG wird entfernt, solange eine benötigte Beobachtung noch davon abhängt oder die maximale zugehörige TTL nicht nachweislich verstrichen ist.

Der Entwurf berichtet, dass seine Verfahren mit Knot DNS erprobt wurden. Er enthält jedoch manuelle Schritte; im beschriebenen Umsetzungspfad wird die manuelle Erzeugung eines neuen ZONEMD-Digests nicht unterstützt. Das ist ein wertvoller Implementierungsnachweis, aber kein Beleg für universelle Produktunterstützung. Unbekannte Ausbreitungszeiten, heterogene autoritative Plattformen und nicht einsehbare Resolver-Caches vergrößern die Unsicherheit. Die Formeln sind nur dann konservativ, wenn die verwendeten Maximalwerte stimmen und die tatsächliche Publikation beobachtet wurde.

Am Ende steht deshalb keine Behauptung, der verlorene Schlüssel sei zurück. Die belastbare Aussage ist enger und stärker: Ein neuer Signierpfad wurde veröffentlicht, nach den erforderlichen Cache-Zeiten aktiviert, auf Parent und Child durch unabhängige Beobachtungen bestätigt, über alle autoritativen Instanzen verteilt und während der Entfernung des alten Pfads ohne Validierungs- oder Anwendungsausfall gehalten. Die noch antwortende vorsignierte Zone war dafür keine Lösung. Sie war die letzte nutzbare Zeitreserve.

Quellen