Zusammenfassung

  • Revision 02 von Automating DNS Delegation Management via DDNS ist aktive DNSOP-Arbeit, kein RFC und kein Nachweis einer produktiven Einführung.
  • DSYNC findet den UPDATE Receiver; SIG(0), Schlüssel-Bootstrap und Namensbindung authentisieren den Auftrag. Der Parent behält Prüfungen, Richtlinie, Audit und Provisionierung.
  • NOERROR bestätigt Empfang und Annahme. Laut Entwurf soll die Änderung irgendwann später im Parent veröffentlicht werden; der Code beweist weder die primäre noch die sekundäre Veröffentlichung.
  • Eine sichere Abschaltung braucht beobachtete Parent-Generationen, autoritative RRsets und Cache-Grenzen zusätzlich zum internen Jobstatus.

Eine grüne Warteschlange ist ein interner Beleg

Der Entwurf lässt offen, wie ein Parent seine Zone führt: Textdatei, Datenbank, API oder anderes System. Das ist richtig, weil das interoperable Protokoll nicht die interne Architektur diktieren sollte. Für die Beweiskette entsteht dadurch jedoch eine sichtbare Naht.

Der Receiver kann einen Auftrag vollständig annehmen und an die Provisionierung übergeben. Ein Generator kann eine neue Zone bauen. Der Primary kann sie laden. Erst danach übertragen Secondaries die Generation und beginnen, sie auszuliefern. Jeder Schritt hat eigene Fehler- und Verzögerungsarten.

Wer den Status des Provisionierungsjobs als öffentlichen DNS-Status ausgibt, überspringt diese Naht. Ein erfolgreicher Datenbank-Commit beweist nicht, dass der Primary neu geladen hat. Ein erfolgreicher Primary-Reload beweist nicht, dass alle Secondaries dieselbe Generation anbieten.

Das Dashboard sollte deshalb getrennte Zustände führen: angenommen, intern geschrieben, Zone erzeugt, Primary aktiv, Secondary-Menge konvergent, autoritativ beobachtet. Ein grüner früher Zustand darf einen späteren unbekannten Zustand nicht einfärben.

NOERROR verspricht eine spätere Veröffentlichung

Revision 02 formuliert die Semantik vorsichtig. RCODE Null bestätigt, dass das DNS UPDATE empfangen und angenommen wurde; die Änderung an den Parent-Daten soll zu einem zukünftigen Zeitpunkt veröffentlicht werden.

Dieser Futur ist die wichtigste Kontrollgrenze des Mechanismus. Er erlaubt dem Parent, Richtlinien und seine Betriebsarchitektur zu behalten. Gleichzeitig verbietet er dem Child, aus der Antwort eine sofortige Delegationsänderung abzuleiten.

Bei einem NS-Wechsel könnte eine voreilige Interpretation den alten Betreiber abschalten, obwohl eine Parent-Autorität ihn weiter ankündigt. Bei einem DS-Wechsel könnte ein Rückfallpfad verschwinden, bevor die öffentliche Vertrauenskette stabil ist.

Der nächste Beleg muss vom autoritativen Parent kommen. Er enthält Zielserver, Adresse, Zeitpunkt, RRset, TTL, DNSSEC-Zustand und Generationshinweis. Antworten verschiedener Parent-Server werden nicht gemittelt: Unterschiedlichkeit ist selbst ein Ergebnis und heißt partielle Veröffentlichung.

Ein Schlüssel wird nicht durch Selbstbehauptung zuständig

Beim Bootstrap kann das Child einen KEY in einem selbstsignierten UPDATE vorlegen. Eine gültige Signatur beweist Besitz des privaten Schlüssels. Sie beweist nicht die Befugnis, die Delegation dieses Childs zu verwalten.

Der Receiver hält den Kandidaten zunächst als bekannt, aber nicht vertrauenswürdig. Vertrauen entsteht durch DNSSEC-validierte Veröffentlichung am Child-Apex, unter einem Namen in einer signierten Nameserver-Zone oder durch manuelle Prüfung.

Der unsignierte Weg ist schwächer: Er authentisiert den aktuellen Betreiber der autoritativen Server, nicht den Registranten. Das kann für eine lokale Parent-Richtlinie ausreichen, muss aber als andere Autoritätsquelle im Beleg stehen.

Beim Re-Bootstrap bleibt der bisher vertrauenswürdige Schlüssel erhalten, bis der neue validiert ist. Andernfalls könnte ein ungültiger Kandidat den funktionierenden Schlüssel verdrängen, ohne selbst jemals Autorität zu erhalten. Der Übergang braucht eine Reihenfolge, nicht nur zwei erfolgreiche API-Aufrufe.

Namensbindung begrenzt den Explosionsradius

Standardmäßig muss der Name des vertrauenswürdigen SIG(0)-Schlüssels genau dem Child entsprechen, dessen Delegation verändert wird. Ein kompromittierter Child-Schlüssel darf kein Geschwister verändern.

Ein Parent kann eine alternative Berechtigung verwenden, etwa einen Registrar-Schlüssel für viele Children. Dann übernimmt er die Verantwortung, jede Änderung anderweitig zu autorisieren. Die größere Reichweite ist keine unsichtbare Optimierung, sondern ein Governance-Entscheid.

Auch nach Signatur- und Namensprüfung folgen die Korrektheits- und Richtlinienkontrollen von CDS/CDNSKEY beziehungsweise CSYNC. Der Parent entscheidet, ob NS, Glue oder DS in seiner Zone zulässig sind. Audit und Rate Limit bleiben bestehen.

DSYNC löst nur die Endpoint-Suche. Endpoint gefunden, Endpoint authentisiert, Child autorisiert, Update angenommen und Daten veröffentlicht sind fünf verschiedene Aussagen. Ein belastbarer Datensatz hält sie getrennt.

Die Antwort braucht eine Gegenrichtung des Vertrauens

Das Child signiert die Anfrage. Damit ist eine empfangene Antwort noch nicht automatisch dem erwarteten Receiver zugeordnet. Der Receiver kann mit einem eigenen SIG(0)-Schlüssel signieren; das Child muss diesen Schlüssel über Parent-DNSSEC oder manuell validieren.

Ohne Gegenrichtung kann ein Angreifer fälschlich melden, der Child-Schlüssel sei unbekannt, und unnötigen Re-Bootstrap auslösen. Er kann keine unberechtigte Delegationsänderung genehmigen, aber Betrieb und Schlüsselverwaltung stören.

Der Response-Beleg nennt Signatur, Receiver-Fingerprint, Vertrauensweg, RCODE, EDE und Request-Generation. „Antwort erhalten“ ist schwächer als „der erwartete Receiver hat diese Aussage authentisiert gemacht“.

Doch selbst die authentisierte Aussage reicht nur bis zur Annahme. Die Identität des Sprechers vergrößert nicht die Semantik des Satzes.

Schweigen kann nach einem Commit eintreten

Fehlt eine Antwort, kann die Anfrage verloren sein, die Antwort nach Annahme verloren sein oder der Receiver ausfallen. Der Sender kann aus dem Timeout nicht erkennen, ob Parent-Zustand mutiert wurde.

Der Entwurf empfiehlt mindestens fünf Sekunden, exponentiellen Backoff und standardmäßig höchstens fünf Wiederholungen. Das schützt Kapazität. Es beweist nicht, dass nichts geschehen ist.

Jede Wiederholung braucht eine Intent-Generation. Ein alter Auftrag darf nach einer neueren Entscheidung keine frühere Glue- oder NS-Menge wiederherstellen. SIG(0)-Zeitgrenzen reduzieren Replay, lösen aber nicht die Reihenfolge zweier legitimer Aufträge.

Vor dem Retry wird der Parent beobachtet. Entspricht er bereits dem Wunsch, ist Wiederholung unnötig. Sind Parent-Server gemischt, liegt der nächste Schritt in Provisionierung und Zonenübertragung, nicht im blinden erneuten Schreiben.

Cache und Anwendung folgen eigenen Uhren

Nach autoritativer Konvergenz können Resolver den alten Satz innerhalb seines TTL weitergeben. Ein aufgezeichneter Publikationsbeginn und der alte TTL erlauben eine obere Expositionsgrenze, aber keine Behauptung über jeden Cache.

Repräsentative Resolver-Proben zeigen, was verschiedene Beobachter sehen. Sie dürfen nicht zum Beweis universeller Konvergenz werden. Ebenso zeigt ein Anwendungstest Wirkung, nicht automatisch den zugrunde liegenden DNS-Zustand.

Eine Anwendung kann durch einen alten Cache oder einen alternativen Pfad funktionieren, bevor die Änderung öffentlich ist. Sie kann trotz korrekter Delegation aus einem anderen Grund scheitern. Beide Ebenen gehören nebeneinander in den Abschlussbericht.

Die Abschaltung des alten Pfads folgt dem letzten erforderlichen Beleg. Ein Vertragsdatum ersetzt ihn nicht. Führung muss bestimmen, wer Überlappung verlängern, Kosten übernehmen und eine voreilige Stilllegung stoppen darf.

Der Quellenstatus begrenzt jede Aussage

Beim Freeze war Revision 02 auf den 17. Juni 2026 datiert, im Datatracker zuletzt am 25. September aktualisiert und sollte am 19. Dezember ablaufen. WG-Status: Waiting for WG Chair Go-Ahead Other - see Comment Log; IESG-Status: I-D Exists.

Datatracker zeigte keinen Intended RFC Status, der Dokumentkopf Standards Track. Der Artikel bewahrt diesen Unterschied. Vorgeschlagene IANA-Werte und Beispiele sind keine finalen Zuweisungen.

Keine Quelle beweist einen Einsatz bei einer benannten Registry, einem Registrar, einer TLD oder einem DNS-Betreiber. Der Einstieg ist konstruiert und darf nicht als Vorfall gelesen werden.

Der eigentliche Output ist ein Beleggraph

Der Graph beginnt mit Child-Intent, vorherigem Zustand, gewünschten RRsets, Generation und Genehmiger. Er verbindet DSYNC, Vertrauen in beide Schlüssel, Namensbereich, Prüfungen, Parent-Policy und Antwort. Danach folgen Provisionierungsjob, Parent-Generationen, autoritative Beobachtungen, Cache-Grenze, Resolver-Proben und Anwendung.

Jede Kante hat Eigentümer, Zeit, Ein- und Ausgabe sowie Hash. Unbekannt bleibt unbekannt. So kann Betrieb Stilllegung anhalten, veralteten Retry verhindern, den letzten guten Schlüssel schützen und die Störung der richtigen Stelle zuordnen.

Die belastbare Schlussfolgerung ist klein: SIG(0) kann einen begrenzten Auftrag authentisieren, NOERROR seine Annahme bestätigen. Ob der Parent veröffentlicht hat, zeigt nur der Parent.

Quellen