Zusammenfassung

  • Revision 02 lässt ein Kind konkrete NS-, Glue- und DS-Änderungen als gewöhnliches DNS UPDATE an den Elternbereich senden, mit SIG(0) geschützt und über DSYNC adressiert.
  • Eine Selbstsignatur beweist Schlüsselbesitz. Der Empfänger führt KEY zunächst als known und darf ihn erst nach einer getrennten Bootstrap-Prüfung zu trusted befördern.
  • Beim Re-Bootstrap bleibt der alte vertrauenswürdige Schlüssel bestehen, bis der Ersatz validiert ist. Auch danach belegt NOERROR nur Annahme, nicht autoritative Veröffentlichung oder Resolver-Sicht.

Der kritische Teil der Bootstrap-Nachricht ist nicht die Addition, sondern die Löschung.

draft-ietf-dnsop-delegation-mgmt-via-ddns-02 beschreibt eine selbst signierte DNS-UPDATE-Nachricht, die den bisherigen KEY-RRset des Kindes vollständig entfernen und einen neuen KEY hinzufügen will. Mit dem eingereichten öffentlichen Schlüssel lässt sich die Signatur prüfen. Damit steht fest, dass der Absender den passenden privaten Schlüssel besitzt. Würde der Empfänger daraus sofort Befugnis ableiten, könnte ein Angreifer ein eigenes Paar erzeugen und den gültigen Schlüssel verdrängen, ohne je die Autorisierungsprüfung zu bestehen.

Der Entwurf braucht deshalb zwei Zustände. Nach Eingang und erfolgreicher Selbstprüfung ist der Schlüssel bekannt. Erst ein vom Elternbereich zugelassenes Verfahren verankert, wessen Kontrolle dieser Besitz repräsentiert. Nach erfolgreicher Prüfung wird er vertrauenswürdig. Bis zu diesem Übergang darf der alte Schlüssel nicht gelöscht werden.

Diese Zustandsmaschine steht in einer aktuellen Debatte. DNSOP eröffnete den Working Group Last Call am 20. August und setzte den 7. September als Enddatum. Am 4. September bat ein Vorsitzender ausdrücklich um positive Unterstützung und konstruktive Kommentare; fehlender Widerspruch reiche nicht. Geoff Huston unterstützte die Veröffentlichung und sah im Push einen effizienteren Weg als elternseitiges Polling. Johan Stenstam hob den Fall unsignierter Kinder hervor und erklärte seine Implementierungsrolle.

Michael Richardson hielt den Text für implementierbar, fragte aber nach KEY statt DNSKEY, Schlüsselzuständen, künftigen Algorithmen und einem Zustandsdiagramm. Das sind persönliche Beiträge, kein belegter WG-Konsens und kein Nachweis von IETF-Freigabe oder interoperablem Betrieb.

Das Transportverfahren ist absichtlich vertraut. RFC 2136 liefert DNS UPDATE, RFC 2931 und RFC 3007 die SIG(0)-Transaktionssignatur. DSYNC aus RFC 9859 veröffentlicht, ob der Elternbereich diese Updates annimmt und wo sein logischer UPDATE Receiver liegt. Dieser kann vom primären Nameserver getrennt sein und zunächst ein Provisionierungssystem bedienen.

Eine authentisierte Nachricht ist daher noch kein Ausführungsbefehl. Der Receiver beschränkt die zulässigen RRsets. Ohne bewusst gewählte Alternativautorisierung darf ein vertrauenswürdiger, exakt nach dem Kind benannter SIG(0)-Schlüssel nur dieses Kind verwalten. Danach bleiben die sachlichen CDS/CDNSKEY- und CSYNC-Prüfungen bestehen. Geändert wird der Weg zum Entscheidungsort, nicht das Entscheidungsrecht des Elternbereichs.

Die Bootstrap-Verfahren tragen unterschiedliche Beweiskraft. Ein DNSSEC-signiertes Kind kann KEY am Apex veröffentlichen. Bei einem unsignierten Kind kann ein Nameserver-Betreiber in seiner eigenen signierten Zone einen besonderen KEY-Namen bereitstellen. Kleine Elternbereiche können einen manuellen Kanal verwenden.

Ohne signierte Kette vergleicht der Receiver den eingereichten KEY mit Beobachtungen des autoritativen Dienstes aus mehreren Standorten, zu mehreren Zeiten und über mehrere Transporte. Vielfalt erschwert einen On-Path-Angriff, macht aber aus Betriebskontrolle kein Registrantenrecht. Der Entwurf sagt, dass diese Methode den aktuellen Betreiber der autoritativen Server authentisiert, nicht den Registranten, und nicht stärker sein kann als der Dienst selbst.

Auch der Record-Typ ist Teil des Vertrags. SIG(0) verwendet KEY, nicht DNSKEY. DNSKEY gehört zur DNSSEC-Zonensignatur; KEY authentisiert hier eine Transaktion. Eine Oberfläche, die beide als „DNS-Schlüssel“ zusammenfasst, verschleiert getrennte Verwahrung, Rotation, Kompromissbehandlung und Reichweite.

Antwortcodes bleiben Teilbelege. NOERROR bestätigt Empfang und Annahme; eine spätere Änderung der Elterndaten darf erwartet werden. Es beweist weder Provisionierungs-Commit noch neuen autoritativen Stand, Cache-Ablauf oder erfolgreiche Auflösung. REFUSED kann Politik, Rate Limiting oder Fehlkonfiguration bedeuten. BADKEY meldet den fehlenden öffentlichen Prüfschlüssel, beschreibt aber nicht jeden Zwischenzustand. Ohne Antwort bleibt offen, welche Hälfte der Transaktion verloren ging.

Eine belastbare Beweiskette hält DSYNC-Endpunkt und Policy-Version, UPDATE-Hash und Voraussetzungen, KEY-Identität, Bootstrap-Methode, known- und trusted-Übergang, Receiver-Entscheidung und signierte Antwort, Provisionierungstransaktion, Eltern-Serial, autoritativen RRset, Resolver-Sichten nach TTL und erst danach das Dienstergebnis auseinander.

Damit folgt der Entwurf einer Kernlinie von Heng Lu: Ein Register beschreibt die Realität seiner Beobachtung, es beherrscht nicht automatisch die nächste. „Bekannt“ kann wahr sein, während „befugt“ falsch bleibt. Ein veröffentlichter Entwurf ist keine Adoption. Eine angenommene Nachricht ist noch kein öffentliches DNS. Genau diese Trennung begrenzt die symbolische Macht einer gültigen Signatur.

Quellen