Zusammenfassung

  • RFC 9975 leitet die Prüfmenge aus der bestehenden Child-Delegation im Parent ab: Sämtliche NS-Namen und alle dazu ermittelten Adressen müssen direkt befragt werden.
  • NODATA ist eine relevante autoritative Antwort; Schweigen erfordert Wiederholungen, Backoff und gegebenenfalls einen anderen Netzstandort.
  • Weichen die maßgeblichen Zustände voneinander ab, wird die ganze Operation ohne Erzeugung, Löschung oder Änderung im Parent abgebrochen. Einigkeit ersetzt weder Identität und Befugnis noch die Prüfung des resultierenden DNSSEC-Pfads.

Ein Server veröffentlicht einen neuen CDS-Schlüssel, ein zweiter liefert NODATA. Beide Antworten können korrekt signiert sein. Beide Systeme können funktionieren. Dennoch hat der Child-Dienst noch keinen gemeinsamen Änderungswunsch erkennen lassen.

Für einen Resolver reicht gewöhnlich eine brauchbare Antwort. Ein Parent-Agent, der DS-, NS- oder Glue-Daten dauerhaft ändern soll, übt eine andere Funktion aus. Er übersetzt einen beobachteten Zustand des Child in eine Entscheidung auf einer höheren Ebene des Namensraums. Das rechtfertigt einen strengeren Belegstandard als erfolgreiche Namensauflösung.

RFC 9975 erschien im Mai 2026 mit Peter Thomassen als alleinigem Autor. Sein Begriff der „plausiblen Konsistenz“ verspricht keine vollständige Sicht auf jedes Anycast-System. Er definiert aber eine nachvollziehbare Beobachtungsrunde und verbietet, aus einer widersprüchlichen Teilansicht einen Parent-Write abzuleiten.

Der bestehende Parent bestimmt den Zeugenraum

Der Agent übernimmt keine Serverliste aus der zu prüfenden Meldung. Er liest die NS-Namen der Child-Delegation im Parent, ermittelt für jeden Namen mit einem validierenden Resolver alle IP-Adressen und bezieht verfügbaren Glue ein. Anschließend sendet er die relevante Anfrage direkt an jede Adresse.

Diese Reihenfolge verhindert, dass ein Signal seine eigenen Bestätiger auswählt. Andernfalls könnte eine fehlerhafte oder manipulierte Quelle den Anbieter auslassen, der noch den alten Zustand ausliefert. Die Parent-Delegation beweist keine rechtliche Inhaberschaft, beschreibt aber den autoritativen Dienst, den der Parent bereits öffentlich angekündigt hat.

Auch eine einzige rekursive Abfrage des NS-Namens genügt nicht. Ein Name kann mehrere Adressen und damit verschiedene Instanzen oder Pfade erreichen. Bei Anycast kann dieselbe Adresse je nach Standort zu einem anderen System führen. Bleibt eine Anfrage unbeantwortet, kann ein zweiter Netzstandort klären, ob der Server oder nur ein Pfad unsichtbar ist.

Die Evidenz bleibt begrenzt. Gerade deshalb sollte der Entscheidungsnachweis zeigen, welche Delegation, Adressen, Glue-Quellen, Zeitpunkte und Standorte tatsächlich verwendet wurden.

NODATA ist eine Aussage, keine Lücke

NODATA bedeutet, dass der Server autoritativ geantwortet, aber den abgefragten Record-Typ nicht geliefert hat. RFC 9975 zählt dies ausdrücklich als empfangene Antwort. Steht auf einem Server ein CDS/CDNSKEY-Schlüssel und auf einem anderen NODATA, ist die Anforderung nicht gemeinsam veröffentlicht.

NODATA zu ignorieren würde Änderungen systematisch bevorzugen. Nur Server mit einem Änderungswunsch würden zählen, während eine gültige Sicht, die keine Änderung signalisiert, aus dem Belegsatz verschwände.

Gar keine Antwort ist anders. Paketverlust, Routing, Filterung oder Ausfall können die Beobachtung verhindern. Vor der Einstufung als dauerhaft unerreichbar muss der Agent erneut anfragen. Das RFC nennt exponentielle Abstände von 5, 10, 20 und 40 Minuten als Beispiel; die genaue Politik bleibt lokal. Eine zweite Perspektive hilft bei der Zuordnung zum Dienst oder zum Pfad.

Unendliches Warten wird nicht verlangt. Sichtbar sein muss jedoch die Regel, nach der ein fehlender Zeuge schließlich ausgeschlossen wird. Frist, Perspektiven, Eskalation und verantwortliche Rolle gehören in den Nachweis. Schweigen darf nicht unbemerkt zu Zustimmung werden.

Bei Widerspruch bleibt der Parent atomar unverändert

Sobald relevante Antworten abweichen, entscheidet weder Mehrheit noch höchste Seriennummer oder niedrigste Latenz. Der Agent bricht die Operation ab. Er erzeugt keine vorgesehenen Records, entfernt keine und verändert die vorhandene Menge nicht.

Der Status quo wird damit nicht zur ewigen Wahrheit erklärt. Er ist der bereits veröffentlichte Zustand mit bekannter Wirkung. Eine von zwei widersprüchlichen Child-Sichten auszuwählen, kann Auflösung oder DNSSEC-Validierung beschädigen. Unverändert zu bleiben gibt den Betreibern Zeit, Replikation abzuschließen, einen Multi-Provider-Split zu beheben oder einen authentisierten Out-of-Band-Weg zu nutzen.

Ein neuer Versuch bildet eine neue Abfragerunde; er sammelt nicht nur günstige Antworten aus verschiedenen Zeitfenstern. Bestätigt eine Antwort bereits den Status quo, dürfen manche ausstehenden Entscheidungsabfragen vorzeitig beendet werden. Weitere Antworten könnten nur ebenfalls keine Änderung verlangen oder Inkonsistenz zeigen – beides führt zu keinem Write. Diagnoseabfragen können weiterlaufen.

Die Atomarität untersagt auch, bei widersprüchlichem CSYNC den scheinbar sicheren Teil vorab anzuwenden. Bewertet wird die gesamte projizierte Operation.

CDS und CDNSKEY vergleichen Schlüsselreferenzen

Plausible Konsistenz verlangt keine Bytegleichheit sämtlicher Pakete. Bei CDS/CDNSKEY muss jeder geeignete Schlüssel, der irgendwo referenziert wird, auch in allen anderen relevanten Antworten referenziert sein. Vorhandensein an einem Ort und Fehlen an einem anderen ist Inkonsistenz.

Auch die vollständige Entfernung des DS-Satzes muss gemeinsam angefordert werden. Eine Löschanforderung neben einer anderen Aktualisierung oder NODATA darf nicht als Zwischenphase umgedeutet werden. Für Digest-Typen setzt das Verfahren definierte Grenzen. Der Parent kann innerhalb dieser Grenzen eigene Veröffentlichungsentscheidungen treffen, nicht aber nachträglich den gemeinsam referenzierten Schlüsselsatz umdefinieren.

RFC 10026, von Steve Sheng und Thomassen verfasst und im Juli 2026 als Best Current Practice veröffentlicht, stellt daneben eine zweite Prüfung: Der projizierte DS-Satz muss einen gültigen DNSSEC-Pfad erhalten. Ein einstimmiger Wunsch kann technisch gefährlich sein. Konsistenz zeigt gemeinsame Absicht, fortgesetzte Validierung technische Kontinuität.

CSYNC erlaubt Serienunterschiede, nicht Entscheidungsunterschiede

Bei CSYNC sind manche Abweichungen durch normale Replikation zulässig. Immediate-Flag und Typ-Bitmap müssen zwischen den Antworten gleich sein. SOA-Serien dürfen differieren; jede CSYNC-Serie wird gegen das SOA desselben Servers bewertet. Das daraus folgende Urteil, ob die Aktualisierung zulässig ist, muss übereinstimmen.

Bestimmt CSYNC zu synchronisierende Mengen wie NS oder Adressen, müssen die relevanten RDATA-Sätze gleich sein, auch wenn sie überall leer sind. Weitere CSYNC-Regeln, darunter die Reihenfolge für Nameserver und Glue, gelten fort.

„Alle fragen“ beschreibt daher nur die Reichweite. Die Implementierung braucht pro Record-Familie ein Vergleichsmodell, das erlaubte Variation, Übergangszustand und blockierenden Widerspruch auseinanderhält.

Eine Benachrichtigung startet nur die Prüfung

Thomassen ist ebenfalls Mitautor von RFC 9859. Ein Child kann damit melden, dass sich CDS-bezogener Zustand geändert hat. Der Parent beginnt schneller, statt auf den nächsten periodischen Scan zu warten.

Die Nachricht überspringt keinen Belegschritt. Der Empfänger führt dieselben DNS-Abfragen und Prüfungen aus, die ein Timer ausgelöst hätte. Eingang, Adressabdeckung, Konsistenz, Prüfung des projizierten DS, Parent-Publikation und Sichtbarkeit nach Cache-Ablauf sind getrennte Nachweise.

Ein einziges grünes Feld „automatisiert“ würde die letzte Nachricht zum scheinbaren Beleg für alle früheren und späteren Schritte machen. Die Benachrichtigung verkürzt Erkennung, nicht die Anforderungen an Befugnis und Evidenz.

Einigkeit ist weder Identität noch Auftrag

Gleiche Daten auf allen Servern beweisen nicht, wem die Domain gehört, wer dem DNS-Anbieter Anweisungen geben durfte oder ob ein Konto kompromittiert wurde. Eine bestehende DNSSEC-Kette kann Wartung technisch authentisieren. Beim erstmaligen Aufbau fehlt der Parent-DS; dafür sind Verfahren wie RFC 9615 nötig. Registry-, Registrar- und Registrantenkontrollen bleiben außerhalb des RDATA-Vergleichs.

Auch erfolgreiche Parent-Publikation ist nicht das Endergebnis. Rekursive Resolver halten alte DS- oder Delegationsdaten bis zum TTL-Ablauf. Der nächste Rollover-Schritt kann zu früh erfolgen. RFC 10026 behandelt deshalb Zeitpunkt, Validierung, Rollback und Reporting als eigenständige Betriebsaufgaben.

Können Child-Betreiber keinen gemeinsamen Zustand herstellen, erhält RFC 9975 einen authentisierten Out-of-Band-Weg. Das ist keine Umgehung, sondern ein anderer Autoritätspfad. Ein Governance-Konflikt zwischen Anbietern darf nicht dadurch gelöst werden, dass der zuerst erreichbare Server gewinnt.

Autorenschaft dokumentiert Beitrag, nicht Betriebsmacht

Der RFC Editor nennt Peter Thomassen als alleinigen Autor von RFC 9975. Sein öffentliches IETF-Profil beschreibt ihn im geprüften Zeitraum als Gründer und CTO von deSEC, Geschäftsführer von SSE, Vorsitzenden von Domain Connect und DNSOP-Sekretär. Außerdem wirkte er an RFC 9615, 9859 und 10026 mit.

Diese Angaben dokumentieren einen Beitrag zur Standardentwicklung. Sie bedeuten nicht, dass Thomassen Parent-Agenten oder Registrys kontrolliert, Implementierungen zertifiziert oder einen bestimmten Vorfall verursacht hat. Das RFC setzt Mindestverhalten; nur Betriebsnachweise zeigen, welche Adressen gefragt wurden und ob ein Konflikt den Parent wirklich unverändert ließ.

Die Grenze entspricht dem Mechanismus: Ein Autorenname belegt Beitrag, nicht Kontrolle über alle Deployments. Ein Servername in einer Delegation bezeichnet eine Belegquelle, nicht die alleinige Befugnis zur Parent-Änderung.

Das eigentliche Ergebnis ist ein Entscheidungsnachweis

Ein geeignetes System bewahrt die scopegebende Parent-Delegation, alle Adressen und Glue-Herkünfte, Anfragezeiten und Standorte, relevante Antworten oder NODATA, Validierung, Vergleiche, Wiederholungen, Backoff und jeden Ausschluss als dauerhaft unerreichbar auf.

Hinzu kommen der projizierte Parent-Diff, die fortgesetzte Validierungsprüfung, die Entscheidung zum Abbruch oder zur Anwendung und der danach beobachtete Parent-Zustand. Geheimnisse gehören nicht hinein; reproduzierbare Entscheidungsfakten schon.

Die gemeinsame Mindestspezifikation lautet: Kein inkonsistenter Teilbeleg darf eine delegationsändernde Folgerung auslösen. Wiederholungsfenster, Perspektiven, Meldewege und zulässige Digest-Politik können lokal bleiben. Laufender Code muss beweisen, dass die Grenze außerhalb des Dokuments existiert.

Quellen