Zusammenfassung

  • CDS und CDNSKEY übermitteln den vom Child-DNS-Betreiber gewünschten Delegationszustand. Der Parental Agent muss das Signal authentisieren, alle Adressen aller autoritativen Nameserver abfragen, beide Darstellungen abgleichen und einen fortbestehenden DNSSEC-Validierungspfad nachweisen.
  • NOTIFY(CDS) beschleunigt die Entdeckung, erteilt aber keine Änderungsbefugnis. Annahme, Veröffentlichung in der Parent-Zone, Cache-Ablauf und externe Validierung brauchen jeweils eigene Nachweise.

Die eine Antwort, die alles stoppt

Der neue DNSKEY-Satz ist signiert. Primärserver und mehrere Sekundärserver liefern die erwarteten CDS- und CDNSKEY-Werte. Das Provisionierungssystem meldet Erfolg.

Der Parental Agent fragt jedoch jede IP-Adresse jedes in der Parent-Delegation genannten Nameservers ab. Eine Adresse liefert noch den alten Satz. Die DS-Änderung wird abgebrochen, der bestehende Parent-Zustand bleibt unangetastet.

Das ist ein analytisches Szenario, kein Bericht über einen bestimmten Betreiber. Es zeigt, warum eine Minderheitsantwort nicht ignoriert werden darf. Die Child-Zone hat über ihren tatsächlich delegierten Dienst zwei Zustände ausgedrückt. Der Parent dürfte durch Mehrheitsentscheid oder Zeitstempelraten eine Absicht erfinden, die der Child-Betreiber noch nicht eindeutig veröffentlicht hat.

„Veröffentlicht“ bezeichnet hier mindestens vier Vorgänge: in ein Steuersystem geschrieben, an allen autoritativen Endpunkten ausgeliefert, als DS in der Parent-Zone erschienen und nach Ablauf alter Caches von Resolvern gesehen. Ein einziger grüner Status kann diese Vorgänge nicht belegen.

Automatisierung hebt den Zonenschnitt nicht auf

Der Parent veröffentlicht den DS-RRset, der auf einen DNSKEY des Child verweist. Das Child veröffentlicht und signiert seinen DNSKEY-RRset. Validatoren bauen aus beiden Verwaltungsbereichen eine Vertrauenskette.

RFC 7344 definiert CDS als DS-formatierte Information und CDNSKEY als Schlüsselinformation, aus der der Parent einen DS berechnen kann. Beide werden am Child-Apex veröffentlicht. Sie sind maschinenlesbare Absicht, kein Fernschreibrecht in der Parent-Zone.

Als Parental Agent kann ein Registry-, Registrar-, Reseller- oder anderer autorisierter Dienst fungieren. Wo Registrar und Registry beide Änderungen bewirken können, müssen Zuständigkeit, Vorrang und das Verhalten nach manuellen Eingriffen feststehen. Sonst konkurrieren zwei korrekte Automationen um denselben Parent-Zustand.

Die Grenze schützt beide Seiten. Das Child behält Schlüssel-, Signatur- und Auslieferungsentscheidungen. Der Parent verantwortet den Link, den er signiert und Dritten anbietet. Seine legitime Prüfung betrifft Interoperabilität und Sicherheit, nicht Geschäftsmodell oder Kundenstandorte des Child-Betreibers.

Geprüft wird jede Adresse

RFC 9975 verlangt, dass der Parental Agent mit einem validierenden Resolver alle IP-Adressen jedes Nameserver-Hostnamens aus der Parent-Delegation ermittelt, einschließlich verfügbarem Glue. Anschließend fragt er jede Adresse ab.

Ein Hostname kann mehrere A- und AAAA-Einträge besitzen, Anycast verwenden oder verschiedene Bereitstellungssysteme erreichen. Multi-Provider-Setups machen diesen Unterschied noch deutlicher. Ein einzelner zufällig gewählter Server beweist nicht den Zustand des delegierten Dienstes.

Konsistenz gilt zwischen allen empfangenen Antworten; NODATA ist ebenfalls eine Antwort. Bei einem Widerspruch muss der Agent abbrechen und darf keine betroffenen RRsets anlegen, ändern oder löschen. Er darf nicht raten, welche Antwort neuer ist.

Unerreichbarkeit ist ein anderer Zustand. Spätere Versuche mit exponentiellem Backoff und ein zweiter Netzstandpunkt helfen, einen lokalen Routingfehler von dauerhafter Nichterreichbarkeit zu trennen. Das Entscheidungsprotokoll muss Timeout, Widerspruch und Validierungsfehler auseinanderhalten.

Zwei Formen müssen denselben Schlüssel meinen

CDS überlässt dem Child die DS-Digestdarstellung. Bei CDNSKEY berechnet der Parent den DS und kann den Digest wählen. Da das Child die Formatpräferenz des Parent nicht allgemein entdecken kann, verlangt RFC 10026 die Veröffentlichung beider Formen, sofern die Präferenz nicht bekannt ist.

Die Redundanz dient Kompatibilität und erlaubt keine zwei Absichten. CDS und CDNSKEY müssen denselben Schlüsselsatz bezeichnen. Bei Abweichung verwirft der Parent den Antrag, anstatt eine Form zu bevorzugen.

Auch Kryptografieempfehlungen verändern sich. Die IANA-Register für DNSSEC-Algorithmen und DS-Digests sind laufende Referenzen. Eine auditierbare Entscheidung speichert Eingaben, berechneten DS und angewandte Richtlinienversion.

Kontinuität ist der Kern der Annahme

Ein überall gleiches Signal kann trotzdem einen unbrauchbaren DS ergeben. RFC 10026 fordert die Prüfung, dass der resultierende Satz fortgesetzte DNSSEC-Validierung erlaubt; andernfalls wird die Änderung abgebrochen.

Mindestens ein vom Ergebnis-DS referenzierter Schlüssel muss die Signatur des Child-DNSKEY-RRsets mit geeigneten Algorithmen und Digests validieren. Die Überlappung alter und neuer Schlüssel während eines Rollovers hält einen Pfad für Resolver mit altem wie mit neuem Parent-DS offen.

Diese Invariante begrenzt die Parent-Befugnis sinnvoll. Zusätzliche lokale Kryptovorgaben können bestehen, sollten aber veröffentlicht, versioniert und reproduzierbar sein. Eine nicht erklärte Ablehnung ist keine technische Sicherheitskontrolle.

Running-Code Primacy liefert die Reihenfolge: Standardisierung und Publikation sind Voraussetzungen, keine operative Realität. Erst kompatible Implementierung, Parent-Publikation und erfolgreiche Validierung machen den neuen Zustand wirksam.

Erstaufnahme braucht eine unabhängige Authentisierung

Bei einer bereits sicheren Delegation authentisiert die bestehende Kette spätere CDS/CDNSKEY-Änderungen. Bei der ersten DS-Aufnahme fehlt genau dieser Parent-Link. Eine Signatur am unsicheren Child-Apex kann sich nicht über den fehlenden DS selbst bestätigen.

RFC 9615 verwendet signierte Signalisierungszonen des DNS-Betreibers. Der Parental Agent validiert diese Zonen und findet kindbezogene _dsboot-Signale, mit denen er die CDS/CDNSKEY-Daten einer noch unsicheren Delegation authentisieren kann.

Das Verfahren hat Grenzen, etwa sehr lange Child-Namen oder Delegationen ausschließlich mit In-Domain-Nameservern. Fähigkeiten müssen deshalb getrennt angegeben werden: authentisiertes Bootstrap, Pflege einer bereits sicheren Delegation und konventioneller Wiederherstellungskanal.

Für die Deaktivierung definiert RFC 8078 ein ausdrückliches Signal: CDS mit Algorithmus 0, Digesttyp 0 und Digest 00. Das bloße Fehlen von CDS bedeutet keine Löschabsicht. Schweigen kann ein Bereitstellungsfehler sein und darf keine irreversible Änderung auslösen.

Eine Benachrichtigung ist nur die Klingel

Periodisches Scannen skaliert schlecht und entdeckt Änderungen spät. RFC 9859 lässt den Parent über DSYNC ein Benachrichtigungsziel veröffentlichen. Das Child sendet nach einer Änderung NOTIFY(CDS).

Die Nachricht fordert eine sofortige Abfrage an. Sie autorisiert keinen DS. Der Agent holt weiterhin autoritative Daten, prüft Signaturen und alle Adressen, vergleicht CDS/CDNSKEY, berechnet das Ergebnis und testet Kontinuität.

Verlorene Meldungen verzögern die Entdeckung und können durch langsame Abstimmungsläufe aufgefangen werden. Duplikate müssen idempotent sein. Gefälschte Meldungen erzeugen ohne geänderte autoritative RRsets keinen akzeptablen Zustand.

Monitoring trennt daher Zielentdeckung, Meldungseingang, Scanbeginn, Konsistenz, Annahme, Parent-Publikation und Validierung. „Meldung zugestellt“ ist kein Synonym für „DS geändert“.

Nach der Parent-Publikation beginnt die Cache-Phase

Eine Annahme kann in einer Bereitstellungswarteschlange liegen bleiben. Publikationsbeweis ist der DS-Fingerabdruck auf autoritativen Parent-Servern zusammen mit Zonenversion, TTL und Beobachtungszeit.

Rekursive Resolver behalten den vorherigen DS bis zum TTL-Ablauf. Während des Übergangs sehen verschiedene Validatoren unterschiedliche Parent-Zustände. Der Rollover muss für beide mindestens einen gültigen Weg erhalten.

RFC 10026 empfiehlt nach einer Änderung vorübergehend einen DS-TTL von ungefähr fünf bis fünfzehn Minuten, um einen Rollback zu beschleunigen. Der normale Wert wird erst wiederhergestellt, nachdem der vorherige RRset aus Caches verschwinden konnte. Ein kurzer neuer TTL überschreibt keine bereits gespeicherten alten Werte.

Externe Prüfungen müssen daher den alten TTL-Horizont abdecken und mehrere Netze nutzen. Jede Probe speichert gesehenen DS, verwendeten Child-DNSKEY und Validierungsergebnis. Eine erfolgreiche Probe belegt einen Pfad, nicht das gesamte Internet.

Automatisierung braucht einen unabhängigen Ausweg

Schlüsselpflege ist Normalbetrieb. Eine gewöhnliche Registrar- oder Registry-Updatesperre sollte authentisierte DS-Automation nicht allein stoppen, weil sie meist Portaländerungen und nicht Handlungen des Intermediärs selbst begrenzt.

Gleichzeitig verlangt RFC 10026 einen weiteren, auch manuellen Wartungskanal. Schlüssel gehen verloren, Anbieter unterstützen das Verfahren nicht oder Migrationen erzeugen konkurrierende Einreicher. Der Ersatzweg muss unabhängig vom ausgefallenen Schlüssel authentisierbar sein und eine gleichwertige Spur hinterlassen.

Ein manueller Eingriff kann Automation bis zur Festlegung einer neuen Basis aussetzen. Er darf nicht zu einer unbegründeten Dauersperre werden.

Quellen