Zusammenfassung

  • Ein DNSSEC-Wechsel durchläuft mehrere Schlüsselzustände und besteht nicht aus einem einzigen Zeremonietermin.
  • Autoritative Verteilung, Cache-Ablauf, Parent-DS und Vertrauensanker-Wartezeit folgen eigenen Uhren.
  • Altes Material bleibt erforderlich, solange eine plausible Validierungskombination davon abhängt.
  • Aktivierung, Ausmusterung und Entfernung gehören in ein Rollover-Nachweisprotokoll.

Stellen wir uns eine planmäßige Schlüsselzeremonie vor, die ohne Warnung endet. Der neue DNSKEY ist sichtbar, der Signierer erzeugt gültige Signaturen, das Kontrollfeld meldet Erfolg. Zum vorgesehenen Zeitpunkt wird der alte Schlüssel entfernt. Kurz darauf erhalten die Kunden einer Gruppe mit validierenden Resolvern SERVFAIL; Prüfungen nahe den autoritativen Servern bleiben grün.

Die Kryptografie hat sich nicht verändert. Das Betriebsmodell hat mehrere Uhren mit der Zeremonieuhr gleichgesetzt.

RFC 7583 beschreibt den Wechsel als zeitliche Folge von Zuständen wie erzeugt, veröffentlicht, bereit, aktiv, ausgemustert, tot und entfernt. Ein Schlüssel kann sichtbar, aber nicht bereit sein; aktiv, aber noch nicht für alle Resolver nutzbar; ausgemustert, obwohl Cache-Daten ihn weiterhin benötigen. Sicherheit bedeutet, während veränderter DNSKEY-, RRSIG- und bei KSK-Wechseln DS-Kombinationen mindestens einen gültigen Validierungspfad zu erhalten.

Die erste Uhr misst die Verteilung auf den autoritativen Servern. Eine Veröffentlichung auf dem Primärserver erreicht nicht sofort jeden autoritativen Server. RFC 7583 zählt die Verteilungsverzögerung zur Bereitschaftsfrist. RFC 6781 verlangt beim Vorveröffentlichen eines ZSK dasselbe: den neuen DNSKEY einführen, auf den autoritativen Servern verteilen und für die Dauer der DNSKEY-TTL veröffentlicht halten, bevor er Produktionsdaten signiert.

Die zweite Uhr liegt in den Resolver-Caches. Ein Validator kann einen alten DNSKEY-RRset halten und eine neue RRSIG abrufen oder eine alte Signatur mit aktualisierten Schlüsseln verbinden. Die Methode muss solche Kreuzkombinationen validierbar halten. Bei Vorveröffentlichung wartet der neue Schlüssel vor dem Einsatz; nach dem Signaturwechsel bleibt der alte erhalten. Bei Doppelsignatur überlappen beide Generationen, was größere Antworten gegen ein einfacheres Kompatibilitätsfenster tauscht.

Die dritte Uhr gehört zur übergeordneten Zone. Ein ZSK-Wechsel kann innerhalb einer Zone bleiben. Ein KSK-Wechsel verbindet gewöhnlich den DNSKEY des Kindes mit einem vom Parent veröffentlichten DS. Das Einreichen eines DS beim Registry-Workflow beweist keine Veröffentlichung im DNS. Der neue DS muss beobachtet, die TTL des alten berücksichtigt und der bisherige Validierungspfad bis zur Nutzbarkeit des Nachfolgers erhalten werden.

Die vierte Uhr betrifft Resolver mit Vertrauensankern nach RFC 5011. Ein neuer SEP-Schlüssel beginnt im Wartezustand. Nach Ablauf der Aufnahmefrist muss der Resolver einen weiteren DNSKEY-RRset mit diesem Schlüssel abrufen und validieren, bevor er ihn als Anker akzeptiert. Die Frist beträgt 30 Tage oder die ursprüngliche TTL-Laufzeit, falls diese länger ist. Bei der Entfernung erreicht ein Vertrauensanker den Zustand Removed erst nach den vorgeschriebenen Beobachtungen von Widerruf oder Abwesenheit; anschließend bleibt sein Zustand 30 Tage gespeichert, bevor der interne Datensatz gelöscht wird. Diese Frist betrifft den Vertrauensankerzustand im Resolver und ist keine allgemeine Erlaubnis, einen DNSKEY aus der Zone zu löschen. Diese Uhr lebt im Validator und steht nicht unter direkter Kontrolle des Zonenbetreibers.

Die vier Uhren sind keine Anzeigen desselben Countdowns. Sie starten mit unterschiedlichen Beobachtungen, gehören unterschiedlichen Komponenten und belegen unterschiedliche Übergänge. „Neuer Schlüssel veröffentlicht“ erlaubt keine Aktivierung. Eine gültige Signatur an einem Messpunkt erlaubt keine Entfernung des Vorgängers. Der Beleg des übergeordneten Zonenbetreibers schließt keine Caches. Dreißig Kalendertage beweisen nicht den von RFC 5011 geforderten späteren Abruf.

Das geeignete Beweisobjekt ist ein Rollover-Nachweisprotokoll. Es nennt Zone, Methode, Schlüssel-Tags und Algorithmen; protokolliert die Zustandswechsel; bewahrt DNSKEY-, RRSIG- und DS-Beobachtungen benannter Punkte auf; dokumentiert TTLs, Verteilungsgrenzen und Signaturgültigkeit; und trennt Einreichung, Sichtbarkeit auf autoritativen Servern und Cache-Ablauf.

Für RFC-5011-Gruppen enthält es zusätzlich Vertrauenspunkt, erste validierte Beobachtung, Ende der Wartezeit und die spätere Beobachtung, die die Aufnahme abschließt. Für alle Gruppen hält es Validierungsergebnisse repräsentativer Resolver fest und benennt Übergangsberechtigte sowie Rückrollauslöser.

Damit wird die Abschlussaussage präzise. „Die Zeremonie lief“ beschreibt eine Verwaltungsaktion. „Der neue Schlüssel ist aktiv“ beschreibt einen kompatiblen Zustand der gewählten Methode. „Der alte Schlüssel ist entfernbar“ bedeutet, dass kein anwendbarer Cache- oder Ankerzustand ihn mehr benötigt. Die Daten können nah beieinanderliegen; die Aussagen sind verschieden.

Quellen

RFC 7583 — Zeitplanung für DNSSEC-Schlüsselwechsel; RFC 6781 — DNSSEC-Betriebspraxis; RFC 5011 — automatische Aktualisierung von DNSSEC-Vertrauensankern.