Zusammenfassung

  • draft-ietf-dnsop-dnssec-keyrestore-02 behandelt den Ausfall eines privaten DNSSEC-Schlüssels ohne brauchbares Backup, während eine vollständige vorsignierte Zone und noch gültige Signaturen erhalten sind.
  • Für die sichere Wiederherstellung laufen getrennte Uhren: RRSIG-Ablauf, DNSKEY-Verbreitung, DS-Veröffentlichung im Parent, Laden der Secondarys und Cache-Auslauf. Der Signierer beherrscht sie nicht allein.
  • Ein Wiederherstellungszeit-Beleg sollte jede Zustandsänderung mit Befugnis, Berechnung und Nachweis verbinden. Das ist Daniel Kades Governance-Vorschlag, keine IETF-Vorgabe.

Ein erfolgreicher DNS-Abruf kann in diesem Fall eine falsche Diagnose fördern. Validatoren kombinieren weiterhin das alte DNSKEY-RRset, gültige RRSIGs und gegebenenfalls den DS des Parents. Der Betreiber kann aber keine neue Adresse, keine geänderte Mailroute und keine Notfallkorrektur sicher signieren. Die Zone ist erreichbar, jedoch im alten Zustand eingefroren.

Revision 02 von DNSSEC Key Restore erschien am 10. August 2026. Sie ist ein aktiver Internet-Draft der DNSOP Working Group und nennt im gerenderten Text Informational als Ziel. Sie bleibt veränderliches Arbeitsmaterial, kein RFC, keine BCP und kein Serviceversprechen von RIPE NCC, dem Arbeitgeber der Autoren. Erfasst sind vorsignierte Zonen; Online-Signierung und Root-Zone sind ausgeschlossen.

Auch „Restore“ ist enger gemeint, als der Titel zunächst klingt. Ohne Backup wird der verlorene private Schlüssel nicht wiederhergestellt. Wiederhergestellt wird die Signierfunktion mit neuem Material. Alte öffentliche Schlüssel und Signaturen bleiben so lange stehen, wie die Validierung noch von ihnen abhängt.

Die Störung beginnt vor dem Ausfall der Auflösung

Der Entwurf nennt einen privaten Schlüssel inoperable, wenn er keine Signaturen mehr erzeugen kann. Hardwaredefekt, Naturereignis, Bedienfehler oder böswillige Handlung können Ursachen sein. Ein kompromittierter, aber weiterhin funktionsfähiger Schlüssel ist ausdrücklich ein anderer Zustand. Dort droht gegnerisches Signieren; hier steht zunächst die Kontinuität im Vordergrund. Die Klassifizierung entscheidet über das richtige Verfahren.

Zum Fehlerzeitpunkt kann die Zone vollständig und korrekt signiert ausgeliefert werden. RRSIGs gelten häufig noch mehrere Tage. Daraus folgt keine feste Frist. Maßgeblich sind die tatsächlichen Ablaufzeiten sämtlicher relevanter Signaturen, die verteilten Zonenstände und die Kombinationen, die rekursive Validatoren bereits gespeichert haben.

Das verbleibende Fenster ist deshalb kein frei verfügbares Wartungsintervall. Die früheste kritische Signatur setzt die Grenze. Gleichzeitig darf ein Signierprogramm ein DNSKEY nicht nur deshalb entfernen, weil dessen privater Anteil fehlt. Auch alte RRSIGs müssen erhalten bleiben; löscht das Werkzeug sie, kann manuelles Wiedereinfügen nötig sein. Das unproduktive alte Material trägt weiter den aktiven Vertrauenspfad.

Ein ZSK-Ausfall bleibt im Kind – aber nicht im Signierer

Fällt der ZSK aus, während der KSK funktioniert, kann ein neuer ZSK in das DNSKEY-RRset aufgenommen und dieses mit dem bestehenden KSK signiert werden. Sichtbarkeit auf dem Primary bedeutet noch keine Bereitschaft. Die Veröffentlichung muss die autoritative Ausbreitung und den DNSKEY-TTL abdecken: Ipub = Dprp + TTLkey.

Erst danach beginnt das Signieren mit dem neuen ZSK. Der alte Schlüssel bleibt bis zum Abschluss der Signierung, der Verbreitung und dem Ablauf seiner RRSIGs in den Caches erhalten. Dafür gilt Iret = Dsgn + Dprp + TTLsig. Störung, Veröffentlichung, Bereitschaft, Aktivierung und sichere Entfernung besitzen eigene Zeitpunkte.

Im Protokoll von IETF 126 wird festgehalten, dass der alleinige Verlust des ZSK die Kontinuität nicht zerstört. Das ist keine Aussage über volle Betriebsfähigkeit. Alte Antworten können validieren, während jede sichere Änderung warten muss.

Beim KSK wird der Parent zum Zeitgeber

Ein Ersatz-KSK braucht einen neuen DS im Parent. Der Entwurf folgt Double-DS: DS einreichen, Registrierung und Veröffentlichung im Parent abwarten, Verbreitung und DS-TTL verstreichen lassen und erst dann den neuen KSK im Kind aktivieren.

Der Veröffentlichungszeitpunkt folgt Tpub = Tsbm + Dreg; bis zur Bereitschaft kommt IpubP = DprpP + TTLds hinzu. RFC 7583 hält fest, dass KSK-Zeiten mit Parent-Beteiligung nicht vollständig vom Zonenmanager kontrolliert werden. Ein schneller lokaler Workflow kann weder den Parent beschleunigen noch entfernte Resolver-Caches leeren.

Darum sind eingereicht, authentifiziert, angenommen, beobachtbar veröffentlicht und cache-bereit getrennte Zustände. Eine Annahmebestätigung ist kein Publikationsnachweis. Ein sichtbarer DS auf einer Instanz beweist noch keine vollständige Parent-Verbreitung.

Beim Ausfall eines Combined Signing Key verbinden sich beide Pfade. Derselbe Schlüssel schützt DNSKEY-RRset und Zonendaten. Der neue DS muss durch den Parent, zugleich muss die Signierfähigkeit der Zone zurückkehren. Der Rückzugszeitraum umfasst Signierdauer, Verbreitung im Kind und das Maximum aus DNSKEY- und RRSIG-TTL.

Aus automatisierter Pflege wird eine Autorisierungszeremonie

CDS und CDNSKEY können DS-Pflege im Normalfall automatisieren. Ein ausgefallener ZSK oder CSK kann die neuen Anforderungsrecords jedoch nicht wie vorgesehen signieren. Revision 02 verlangt deshalb für den betroffenen Pfad eine manuelle DS-Aktualisierung beim Parent.

Manuell ist kein Synonym für formlos. DNS-Hoster, Registrar, Registry und Parent-Betreiber besitzen unterschiedliche Identitäts- und Betriebsnachweise. Der Wiederherstellungsfall muss zeigen, wer das Kind vertreten durfte, wer das Ersatzmaterial prüfte, wer die Ausnahme genehmigte und wer die tatsächliche Veröffentlichung beobachtete.

Secondarys bilden eine weitere Nahtstelle. Um den SOA nicht zu ändern, den der alte Schlüssel nicht mehr neu signieren kann, kann der Betreiber das neue DNSKEY bei gleichbleibendem SOA einführen. Dann löst IXFR oder AXFR möglicherweise keinen normalen Ladevorgang aus. Jeder Secondary muss gegebenenfalls zwangsweise laden. Die korrekte Antwort eines Primarys belegt nicht den Zustand der gesamten autoritativen Flotte.

Die DNSKEY-Änderung macht außerdem den vorhandenen ZONEMD-Digest ungültig. Ein neuer Digest muss erzeugt und signiert werden. Die Implementierungssektion für Knot DNS vermerkt, dass die manuelle Erzeugung im beschriebenen Ablauf nicht unterstützt wird. Das ist ein belegter Randfall, kein Vergleich aller Signierprodukte.

Bei IETF 126 baten Teilnehmer um einen genaueren Vergleich von TTLs und Signaturablauf sowie um Implementierungsnachweise. Der Vortragende berichtete von Knot DNS; der Vorsitz verlangte eine Implementierungssektion. Diese Evidenz ist konkret, aber auf einen begrenzten Versuch beschränkt.

Der Beleg für alle Uhren

Ein gewöhnlicher Incident-Report mit Start- und Endzeit verschluckt die entscheidenden Übergänge. Der vorgeschlagene Beleg beginnt mit Fehlerklasse, Schlüsselrolle, Algorithmus und der frühesten tatsächlichen RRSIG-Grenze. Er dokumentiert, dass alte DNSKEYs und Signaturen weiter ausgeliefert werden, und hält das Erscheinen des Ersatzschlüssels auf jeder autoritativen Instanz fest.

Die Berechnung legt Verbreitungswerte, TTLkey, TTLds, TTLsig und Signierdauer offen. Bei KSK und CSK trennt sie Parent-Einreichung, Berechtigungsprüfung, Annahme, beobachtete Veröffentlichung und Cache-Bereitschaft. Für Secondarys nennt sie jedes erzwungene Laden und den danach gesehenen Inhalt. Für ZONEMD nennt sie den neuen Digest oder die genehmigte Ausnahme.

Neue Signaturen, Stichprobenvalidierung, frühester sicherer Rückzug und tatsächliche Entfernung erhalten eigene Einträge. Jede manuelle Handlung hat einen Entscheider und einen Korrekturweg. Private Schlüssel, HSM-Details und personenbezogene Daten bleiben geheim; Artefakt-Hashes, Key Tags, Zeitstempel, Policy-Versionen, beobachtete RRsets und Organisationsrollen reichen für einen prüfbaren Ablauf.

Der Beleg darf keine allwissende Cache-Beobachtung vortäuschen. TTLs definieren konservative Grenzen, Messpunkte liefern Stichproben. Wer die Eingabewerte kennt, kann die Sicherheitsentscheidung nachrechnen. Eine grüne Anzeige ohne Parameter ist nur eine Behauptung.

Der Entwurf zeigt einen belastbaren technischen Weg, verbliebene Signaturen zu nutzen, ohne die Zone absichtlich unsicher oder bogus zu machen. Er bietet keine universelle Wiederherstellungszeit, keine Parent-SLA, keine Resolver-Vollerhebung und kein Auditformat. Sein Governance-Ergebnis lautet: Die verbleibende Signaturzeit ist ein gemeinsames Budget. Verantwortlich wird der Ablauf, wenn jede Uhr dem Akteur und dem Nachweis zugeordnet ist, die sie weiterbewegen.

Quellen

  1. DNSSEC Key Restore — Revision 02
  2. Datatracker-Dokumentseite
  3. Dokumenthistorie
  4. DNSOP-Protokoll von IETF 126
  5. Aktive DNSOP-Dokumente
  6. DNSOP-Charta
  7. RFC 9364: DNS Security Extensions
  8. RFC 7583: Zeitfragen beim DNSSEC-Schlüsselwechsel
  9. RFC 8078: DS-Verwaltung über CDS/CDNSKEY
  10. RFC 8976: Digest für DNS-Zonen
  11. RFC 9499: DNS-Terminologie