Zusammenfassung

  • Revision 05 von DNSSEC automation ist ein aktiver DNSOP-Internet-Draft, kein RFC und kein Nachweis einer produktiven Migration.
  • Der Entwurf verbindet Multi-Signer-Modell 2 mit CDS/CDNSKEY und CSYNC und trennt Wartefenster für DS, DNSKEY, NS und RRSIG.
  • Ein TTL liefert erst zusammen mit einer beobachteten autoritativen Veröffentlichung eine prüfbare früheste Folgeaktion. Lokales Schreiben oder Workflow-Erfolg reicht nicht.
  • Gewöhnliche Zonendaten-Synchronisation ist ausdrücklich außerhalb des Geltungsbereichs. Gleiche Infrastruktur kann unterschiedliche, jeweils gültig signierte Inhalte verbergen.

Eine Dauer ohne Ereignis

Das Multi-Signer-Modell erlaubt mehreren Betreibern, dieselbe Zone mit eigenen Schlüsseln zu signieren. Damit entsteht Redundanz ohne gemeinsame private Schlüssel. Gleichzeitig müssen Teilnehmer fremde öffentliche Schlüssel, gemeinsame Elternsignale und Delegationsdaten in einer kontrollierten Reihenfolge übernehmen.

Revision 05 beschreibt dafür Aufbau, Beitritt, Austritt sowie ZSK-, KSK/CSK- und Algorithmuswechsel. Der Wert liegt nicht in einem neuen grünen Gesamtstatus, sondern in der Aufteilung der Abhängigkeiten: Kindabsicht, Elternentscheidung, autoritative Veröffentlichung, Cachefrist, Resolverprüfung und Anwendungsergebnis.

Zeit schützt nur, wenn bekannt ist, ab welchem Zustand sie läuft. Beginnt DNSKEY-Wait-Time beim lokalen API-Erfolg, bleiben verzögerte Secondaries unsichtbar. Beginnt DS-Wait-Time mit CDS-Publikation, wird Kindabsicht zur Elternpublikation umgedeutet. Beginnt NS-Wait-Time mit der Annahme eines CSYNC-Vorgangs, ersetzt ein Workflowbeleg den öffentlichen DNS-Zustand.

Ein belastbarer Startbeleg enthält RRset, autoritativen Messpunkt, Zeitpunkt, TTL, Validierungszustand, Zonengeneration und Richtlinie. Nach Ablauf folgt eine erneute Beobachtung. sleep kann Zeit verbrauchen, aber keinen Zustand bezeugen.

Vier Fenster, vier Risiken

DS-Wait-Time startet nach Veröffentlichung des kombinierten DS durch die Elternzone und ist mindestens so lang wie dessen TTL. Es schützt Resolver mit altem Vertrauensankerzustand.

DNSKEY-Wait-Time startet, wenn die beabsichtigten DNSKEY-Sätze aller Signer veröffentlicht sind. Der Mindestwert umfasst den größten DNSKEY-TTL sowie die Zeit zur Verteilung auf alle Secondaries. Er schützt die Verfügbarkeit der Schlüsselansicht.

NS-Wait-Time startet nach der neuen Eltern-Delegation und berücksichtigt die größten NS-TTLs von Eltern- und Signerseite. Es schützt die Erreichbarkeit während eines Betreiberwechsels.

RRSIG-Wait-Time startet, wenn ein Schlüssel nicht mehr zum Signieren verwendet wird. Der öffentliche Schlüssel bleibt, bis früher signierte Daten aus Caches verschwunden sein können. Es schützt nicht den Pfad, sondern die Validierbarkeit vorhandener Daten.

Die vier Werte als identische Countdown-Kacheln darzustellen, beseitigt ihre Semantik. Jeder braucht einen eigenen Start, ein geschütztes Objekt, Annahmen und einen verantwortlichen Beobachter.

Beitritt ist eine Gruppenbehauptung

Ein neuer Signer muss eine funktionierende signierte Zone betreiben, kompatible Algorithmen nutzen und eigene von fremden Schlüsseln sowie eigene von gruppenverwalteten NS unterscheiden. Danach verteilen alle Teilnehmer die öffentlichen ZSK/CSK, erstellen gemeinsame CDS/CDNSKEY und warten auf den kombinierten DS der Elternzone.

Erst nach den DS- und DNSKEY-Bedingungen wird der gemeinsame NS-Satz vorbereitet und gegebenenfalls per CSYNC zur Elternzone projiziert. Ein einzelner korrekter Signer beweist nicht, dass alle Teilnehmer dieselbe Ansicht besitzen.

Das Inventar muss Herkunft und Eigentümer jedes Schlüssels und NS bewahren. Sonst kann der Austritt nicht sauber rückgängig machen, was der Beitritt hinzugefügt hat. Bereits beim Einstieg gehören Austrittsbedingung, Überlappungskosten und Stopprecht in den Vertrag.

Austritt trennt Erreichbarkeit und Signaturleben

Beim Austritt entfernen die verbleibenden Signer zunächst die NS des alten Betreibers. Die Elternzone veröffentlicht die reduzierte Delegation, dann verstreicht das NS-Fenster. Erst danach stellt der alte Betreiber Antworten ein.

Anschließend werden CDS/CDNSKEY für die verbleibenden Schlüssel vorbereitet. Die alte Schlüsselreferenz bleibt so lange in DNSKEY, wie frühere RRSIG noch aus Resolvercaches auftauchen können. Erst danach kann sie verschwinden.

Eine Vertragsbeendigung beantwortet weder, ob Anfragen den alten Server erreichen, noch ob dessen Signaturen noch validierbar sein müssen. Führung muss festlegen, wer den kommerziellen Termin verschieben darf, wer die Überlappung finanziert und welcher Beleg den austretenden Betreiber freigibt.

Identische Schlüssel sind kein identischer Inhalt

Der Entwurf schließt die Synchronisation gewöhnlicher Zonendaten aus. Er koordiniert Infrastruktur-RRsets, nicht den Transport aller Anwendungsdaten.

Mehrere Autoritäten können denselben DNSKEY-Satz veröffentlichen und verschiedene A-, MX- oder signierte Negativantworten liefern. Jede Antwort kann DNSSEC-valid sein. Validierung beweist die Authentizität unter der passenden Kette, nicht die Aktualität gegenüber der Absicht des Zoneninhabers.

Darum benötigt die Migration einen separaten Datenvertrag: autorisierter Transfer, erwartete Generation oder SOA, Inhaltsvergleich, Signaturrichtlinie und Abfragen an jede Autorität. „Schlüssel konvergent“ und „Zone konvergent“ bleiben eigene Zustände.

Zentral und dezentral haben andere Fehlermuster

Im zentralen Modell berechnet ein Controller alle Wartezeiten und steuert die Signer. Das erleichtert ein einheitliches Journal, konzentriert aber Berechtigungen und Fehlerwirkung. Eine veraltete Beobachtung bewegt die ganze Gruppe.

Im dezentralen Modell berechnet jeder Signer anhand ausgetauschter Informationen. Teilnehmer können unterschiedliche TTLs, Mitgliedschaften oder Elternbeobachtungen haben. Lokal korrekte Entscheidungen können gemeinsam unsicher sein.

Der erforderliche authentisierte Vertrauensmechanismus für DNSKEY, CDS/CDNSKEY, CSYNC und NS ist im Detail außerhalb des Entwurfs. Er braucht trotzdem Identität, Zonen- und Typbereich, Genehmigung, Rotation, Widerruf und Audit. Authentisierung des Kanals ist keine unbegrenzte Autorisierung.

Der Dokumentstatus begrenzt die Aussage

Am Stichtag führt Datatracker Revision 05 als aktiven DNSOP-Entwurf, der auf Freigabe des WG-Vorsitzes wartet. Datatracker nennt Informational als geplanten Status, der Dokumentkopf Standards Track. Das Ablaufdatum ist der 6. Januar 2027.

Diese Abweichung bleibt als Prozessunsicherheit stehen. Sie belegt weder fertigen Konsens noch RFC, Softwareunterstützung, Verbreitung oder Interoperabilität. Keine Quelle belegt einen genannten Anbieter, eine Zone, Migration, Störung oder Leistung. Der Einstieg ist konstruiert.

Ein Übergangsjournal statt Erfolgsbanner

Jede Zeile des Journals nennt Zone, Gruppengeneration, Teilnehmer, Objekt, erwarteten und beobachteten Hash, autoritativen Messpunkt, TTL, Zeit, Validierung, Richtlinie, früheste Folgeaktion und genehmigendes Principal. Kindabsicht und Elternpublikation, Cachegrenze und Beobachtung, Schlüssel und Inhalt, DNS und Anwendung bleiben getrennt.

Unbekanntes wird nicht auf null gesetzt. Ohne Veröffentlichungszeit aller Secondaries ist der DNSKEY-Beginn ungewiss. Ohne Elternantwort startet kein DS- oder NS-Fenster. Ohne integrierte Datensynchronisation lautet der Endzustand „Inhalt nicht verifiziert“.

Der Entwurf kann notwendige Reihenfolge und Mindestzeiten stützen. Globale Caches, gleiche Zonendaten, Resolverergebnis und Dienstkontinuität brauchen eigene Beobachter und Verantwortliche.

Quellen