Zusammenfassung

  • draft-ietf-dnsop-delegation-mgmt-via-ddns-02 schlägt vor, konkrete Änderungen an NS, Glue oder DS vom Kind per SIG(0)-signiertem DNS UPDATE an einen über DSYNC gefundenen Empfänger des Elternbereichs zu senden.
  • Der erste Bootstrap-Auftrag ist selbstsigniert. Damit ist der Besitz des angebotenen privaten Schlüssels belegt, nicht die Befugnis zur Verwaltung des Kindes. Erst eine getrennte Prüfung darf known in trusted überführen.
  • Ein Nachweis der Befugnisübergabe sollte alten Schlüssel, Bootstrap-Methode, unabhängige Evidenz, Richtlinienentscheid, Annahme und tatsächliche Veröffentlichung verbinden. Das ist eine Governance-Empfehlung dieses Artikels, keine DNSOP-Vorgabe.

Der Bootstrap-Auftrag kann zwei Anweisungen enthalten: die bisherigen KEY-Einträge löschen und den neuen KEY hinzufügen. Unterschrieben wird er mit genau dem neuen Schlüssel, dessen Vertrauenswürdigkeit erst entstehen soll. Die Signatur kann korrekt sein. Als Legitimation bleibt sie zirkulär.

Revision 02 von Automating DNS Delegation Management via DDNS erschien am 17. Juni 2026. Sie ist ein aktiver Working-Group-Internet-Draft der DNSOP und bleibt veränderliche Arbeit. Im gerenderten Kopf steht Standards Track; die Datatracker-Übersicht lässt den angestrebten RFC-Status leer. Der Text ist kein RFC, und sein Vorliegen belegt keine produktive Einführung.

Das Problem dahinter ist alltäglich. Ändert ein Kind seine autoritativen Server oder DNSSEC-Daten, können im Elternbereich alte NS-, Glue- oder DS-Einträge verbleiben. Solange ein alter Pfad noch funktioniert, erscheint die Zone gesund. Tatsächlich ist ihre erwartete Redundanz bereits geschrumpft; erst der nächste Ausfall zeigt die Tragweite.

CDS- und CSYNC-Scanner lassen den Elternbetreiber regelmäßig nach Signalen suchen. Der Entwurf verlagert die Initiative auf das Kind: Es kennt die eigene Änderung, berechnet die Differenz und schickt sie als sicheres DNS UPDATE. DSYNC veröffentlicht Ziel und Port des Empfängers. Das kann Abfragelast und Verzögerung senken und auch unsignierte Kinder einbeziehen.

Komplexität verschwindet dadurch nicht. Sie wandert von der Erkennung zur Autorisierung.

Der Empfänger entscheidet mehr als eine Signaturprüfung

Ein UPDATE transportiert die gewünschte Änderung selbst, nicht bloß einen Hinweis. SIG(0) bindet die Transaktion an einen privaten Schlüssel. Gegen einen bereits vertrauenswürdigen öffentlichen Schlüssel sind Integrität und Schlüsselbesitz gut prüfbar.

Beim ersten Kontakt fehlt jedoch genau dieses Vertrauen. Der Entwurf stellt klar, dass die kryptografische Stärke einer SIG(0)-Signatur der von DNSSEC entsprechen kann, ohne dass ihr Vertrauensmodell identisch wäre. DNSSEC führt typischerweise zu einem Vertrauensanker. Der UPDATE-Schlüssel wird nach einem eigenen Bootstrap einzeln akzeptiert.

Der UPDATE Receiver darf daher keine automatisch offene Schreibverbindung zur laufenden Elternzone sein. Er kann vom Primary getrennt und vom Elternbetreiber oder etwa einem Registrar betrieben werden. Er begrenzt zulässige Namen und Datentypen, führt die Prüfungen für CDS und CSYNC aus, protokolliert und übergibt den freigegebenen Auftrag an das Provisionierungssystem.

Standardmäßig muss eine Änderung für child.parent. von einem vertrauenswürdigen Schlüssel gleichen Namens signiert sein. So kann ein Kind nicht das andere verändern. Wird stattdessen ein Registrar-Schlüssel für viele Kinder zugelassen, trägt der Empfänger die Verantwortung, jeden Auftrag anderweitig dem richtigen Kind zuzuordnen. Die bequemere Schlüsselbreite vergrößert den Schadensradius.

Known ist ein eigener Kontrollzustand

Nach erfolgreicher Selbstsignatur weiß der Empfänger, dass der Absender den neuen privaten Schlüssel hält. Mehr nicht. Der öffentliche Schlüssel wird known. Erst DNSSEC-gestützte, beobachtungsbasierte oder manuelle Validierung macht ihn trusted.

Bis dahin bleibt ein zuvor vertrauenswürdiger Schlüssel bestehen. Scheitert die neue Prüfung, darf der Kandidat nicht aufsteigen und der alte Schlüssel nicht verschwinden. Diese Reihenfolge verhindert, dass ein Angreifer mit einer beliebigen selbstsignierten Vorlage die gültige Autorität verdrängt, obwohl die eigene Vorlage später abgelehnt wird.

Auch Datenmodell und Oberfläche müssen diesen Zwischenraum zeigen. Empfangen, bekannt, in Prüfung, gescheitert, vertrauenswürdig, ersetzt und widerrufen sind keine Varianten eines einzigen Status. Wer nur den aktuellen KEY-Wert speichert, kann später nicht erklären, welcher Nachweis die Befugnis tatsächlich übertragen hat.

Die Verfahren authentisieren nicht dieselbe Rolle

Eine signierte Kindzone kann den SIG(0)-Schlüssel am Zonenapex veröffentlichen; der Empfänger validiert die DNSSEC-Kette. Ist das Kind unsigniert, aber einer seiner autoritativen Nameserver liegt in einer signierten Zone, kann der Nameserverbetreiber den Schlüssel unter einem besonderen Namen in seiner Zone veröffentlichen. Die Kette wird prüfbar, doch die betriebliche Koordination mit dem DNS-Anbieter bleibt außerhalb der vollständigen Spezifikation.

Für ein vollständig unsigniertes Kind vergleicht das Verfahren unsigned den KEY über mehrere Netzstandorte, Zeitpunkte und möglichst Transporte. Gleichbleibende Antworten erschweren einen kurzfristigen On-Path-Angriff. Sie weisen nicht den Registranten nach. Laut Entwurf wird der gegenwärtige Betreiber der autoritativen Server authentisiert, nicht der Inhaber; es ist die schwächste automatische Methode.

Manueller Bootstrap kann ein authentisiertes Portal oder einen anderen Out-of-Band-Prozess benutzen. Sein Name ist kein Gütesiegel. Entscheidend sind geprüfte Rolle, Autoritätsquelle, gebundene Challenge, Kontowiederherstellung, Ausnahmen und Aufbewahrung.

Der Elternbetreiber sollte deshalb zuerst festlegen, welchen Prinzipal er ermächtigt. DNS-Betreiber, Registrant, Registrar-Kontoinhaber und Verwalter einer signierten Zone können identisch sein, müssen es aber nicht. Ein korrekter Nachweis der einen Rolle ersetzt den der anderen nicht.

Schon die Verfahrensauswahl gehört zum Vertrauenspfad

Am DSYNC-Ziel kann ein SVCB-Parameter bootstrap die Methoden at-apex, at-ns, unsigned und manual ankündigen. Das Kind erkennt damit die Möglichkeiten des Empfängers.

Eine ungeschützte Ankündigung kann jedoch herabgestuft werden. Ein Angreifer könnte eine starke Option ausblenden und das Kind zu unsigned lenken. Der Entwurf empfiehlt daher eine DNSSEC-Signatur des SVCB, wo möglich, und die Wahl der stärksten erfüllbaren Methode.

Für die Prüfung genügt folglich nicht der Eintrag „unsigned erfolgreich“. Gespeichert werden müssen die angekündigte Menge, deren Validierung, die Fähigkeiten des Kindes und die Auswahlregel. Sonst kann ein sauber bestandenes, zuvor manipuliertes Prüfverfahren wie der bestmögliche Nachweis aussehen.

NOERROR bestätigt die Annahme, nicht die Sichtbarkeit

Ein UPDATE mit vertrauenswürdigem Schlüssel durchläuft weiterhin Richtlinien- und Korrektheitsprüfungen. NOERROR bestätigt Empfang und Annahme. Der Entwurf formuliert ausdrücklich, dass die Änderung später in der Elternzone erwartet werden darf. Das Provisionieren und Publizieren liegt noch dazwischen.

Bei einem Nameserverwechsel kann die voreilige Abschaltung alter Server einen Ausfall erzeugen, solange der Elternbereich alte NS veröffentlicht. Bei DS-Änderungen kann eine falsche Annahme über Sichtbarkeit zu DNSSEC-Validierungsfehlern führen.

Vier Meilensteine sind nötig: Schlüssel bekannt, Schlüssel vertrauenswürdig, UPDATE angenommen, RRsets veröffentlicht. BADKEY, laufende Prüfung, fehlgeschlagene Validierung, Richtlinienablehnung und Provisionierungsstau sind unterschiedliche Zustände mit unterschiedlichen Verantwortlichen.

Auch Antworten brauchen Vertrauen. Das Kind kann automatisierte Aussagen über seinen Schlüsselzustand nur sicher verwenden, wenn es den Antwortschlüssel des Receivers validiert. Eine gefälschte Antwort kann zwar keine Delegation ändern, aber unnötigen Bootstrap und Störung auslösen.

Ein Beleg für die Befugnisübergabe

Ich schlage für jeden Bootstrap und Re-Bootstrap einen zugriffsgeschützten Übergabebeleg vor. Er ist keine zusätzliche IETF-Anforderung. Er beantwortet, warum ein System aus einer bekannten eine vertrauenswürdige Berechtigung gemacht hat.

Der Beleg bindet Elternzone, Kind, Receiver, DSYNC-Antwort und Validierung, Software- und Richtlinienversion, Fingerabdrücke alter und neuer Schlüssel, Digest des selbstsignierten Auftrags und Signaturzeiten. Er nennt alle angekündigten und verfügbaren Methoden sowie den Auswahlgrund.

Für DNSSEC hält er Abfragenamen, Kette, Zeitpunkt und Ergebnis fest. Für unsigned dokumentiert er die tatsächliche Unabhängigkeit der Beobachtungspunkte, Zeiten, Transporte, vollständige Antwortfingerabdrücke und Konsistenz. Beim manuellen Weg verweist er kontrolliert auf Sitzung, geprüfte Rolle, Challenge, Entscheider, Wiederherstellung und Ausnahmen, ohne persönliche Daten zu veröffentlichen.

Known, Prüfungsbeginn, Fehler, trusted, Ablösung und Widerruf werden eigene Ereignisse. Der Fortbestand des alten Schlüssels bis zum Erfolg bleibt nachweisbar. Spätere UPDATE-Belege fügen genaue NS-/Glue-/DS-Differenz, Prüfungen, Entscheidung, Antwort und Provisionierungsauftrag hinzu. Am Ende steht die Beobachtung der veröffentlichten RRsets auf den autoritativen Elternservern.

Der neue Mechanismus kann Delegationen schneller synchronisieren. Er sollte nicht schneller Macht verteilen als Nachweise sie begründen können. Ein Schlüssel unterschreibt seinen Besitz. Seine Befugnis muss von außen kommen.

Quellen

  1. Automatisierte DNS-Delegationsverwaltung über DDNS — Revision 02
  2. Datatracker-Eintrag des DNSOP-Entwurfs
  3. Entwurfshistorie
  4. DNSOP-Dokumente
  5. DNSOP-Arbeitsgruppe
  6. RFC 9859 — Generalisierte DNS-Benachrichtigungen
  7. RFC 2136 — Dynamische DNS-Aktualisierung
  8. RFC 2931 — DNS-Anfrage- und Transaktionssignaturen
  9. RFC 3007 — Sichere dynamische DNS-Aktualisierung
  10. RFC 8078 — Elternseitige DS-Verwaltung über CDS/CDNSKEY
  11. RFC 7477 — Synchronisierung vom Kind zum Elternbereich
  12. The Policy Mirror