Zusammenfassung

  • RFC 10001 löst RFC 3901 ab und verlangt für eine Zone mindestens zwei über IPv4 und zwei über IPv6 erreichbare autoritative Server, voneinander unabhängige Delegationswege und äquivalente DNS-Daten auf beiden Transporten.
  • Der BCP-Text ist weder Implementierungsnachweis noch automatische Registrierungsregel. Nur getrennte Laufzeittests der ganzen Kette—Eltern, Glue, Geschwisterabhängigkeiten, Listener, UDP/TCP, PMTU und Anwendung—belegen Kontinuität.

Die Beschaffungsunterlage sagt „RFC-10001-konform“. Der Zonenbestand enthält A und AAAA, zwei NS-Namen und DNSSEC. Ein externer IPv6-only-Resolver erreicht die Autorität trotzdem nicht, weil die Elternzone für einen In-Domain-NS kein passendes Glue liefert. Der Text war richtig zitiert. Die Schlussfolgerung war unbelegt.

Standards können gemeinsame Bedingungen benennen. Ein Registrierungsverfahren kann einzelne Bedingungen kontrollieren. Ein Provider kann Konfigurationen versprechen. Erst ein laufender Pfad kann zeigen, ob ein konkreter Resolver zu einem konkreten Zeitpunkt die Autorität erreicht. Wer diese Ebenen zusammenzieht, macht Dokumentation zu Betriebswirklichkeit.

RFC 10001 wurde im August 2026 als BCP 91 veröffentlicht. Es beschreibt eine Namensraumaufteilung, wenn ein Resolver den Verweisen bis zu einem autoritativen Serversatz folgt, dieser aber nur über eine nicht unterstützte Adressfamilie erreichbar ist. Die Zone ist veröffentlicht; für diesen Resolver fehlt die Antwortinstanz.

Die Anforderung gilt für die vollständige Kette

Iterative Auflösung beginnt an der Wurzel. Jede Elternzone liefert einen Verweis. Ein NS-Name innerhalb der delegierten Zone benötigt Glue beim Elternteil. Die Kindzone muss dazu passende A- und AAAA-Daten führen. Liegt der NS-Name in einer Geschwisterzone, muss deren eigene Delegation über dieselbe Familie funktionieren. Ein unerreichbarer Elternknoten unterbricht alle darunterliegenden Kinder.

Auch ein vorhandenes Adress-RR belegt keinen Dienst. RFC 10001 nennt ausdrücklich die Konfiguration, in der A oder AAAA auf eine Adresse zeigt, an der kein DNS über diese Familie antwortet. Bestandsprüfung und Paketprüfung haben unterschiedliche Aussagehoheit.

Die 2023 veröffentlichte Studie How Ready Is DNS for an IPv6-Only World? untersuchte deshalb die gesamte Delegationskette. Sie zeigte außerdem, dass defekte IPv6-Delegationen bei relativ wenigen Anbietern konzentriert sein können. Die Messwerte sind zeitgebunden und keine aktuelle Anbieterbewertung. Für Risikoanalysen bleibt jedoch wichtig, dass ein Eltern- oder Providerfehler viele Zonen gleichzeitig betrifft.

Aus einer Übergangsschutzregel wird Symmetrie

RFC 3901 sollte 2004 verhindern, dass IPv6-only-Autoritäten den damals verfügbaren IPv4-Namensraum fragmentieren. Es forderte mindestens einen IPv4-erreichbaren autoritativen Server. IPv6 war die experimentelle Seite.

RFC 10001 ersetzt diese Einseitigkeit. Für jede Zone MÜSSEN mindestens zwei autoritative Server über IPv4 und zwei über IPv6 erreichbar sein. Ein Dual-Stack-Server zählt je einmal. Der IPv4-Delegationspfad darf nicht auf IPv6 angewiesen sein; der IPv6-Pfad nicht auf IPv4. Beide Transporte müssen äquivalente Daten liefern.

Diese Regel erzeugt drei Prüfungen statt einer: Pfad A erreichbar, Pfad B erreichbar, Inhalte äquivalent. Ein Porttest kann die dritte nicht erfüllen. SOA, RRset-Fingerprints, DNSSEC-Ergebnis und Autoritätsstatus müssen verglichen werden.

Serverzahl ist zudem keine Fehlerdomänenzahl. RFC 2182 fordert topologische und operative Diversität. Mehrere Namen und Adressen auf derselben Plattform, im selben Anycast und im selben Änderungssystem können gemeinsam ausfallen. Der Nachweis muss Anbieter, Routingpolitik, Glue-Eigentümer, Listener und Steuerungspfad enthalten.

Ein korrekter Datensatz kann am MTU-Rand verschwinden

Große DNSSEC-Antworten können die effektive Pfad-MTU überschreiten. Fragmentiertes UDP wird mitunter still verworfen. TCP kann ebenfalls stehen bleiben, wenn PMTU-Rückmeldungen blockiert oder falsch sind und die gesendeten Segmente den wirklichen Pfad überfordern.

RFC 10001 folgt RFC 9715 und empfiehlt Fragmentierungsvermeidung. Es nennt für UDP eine Obergrenze von 1400 Oktetten oder konservativ 1232; für TCP entsprechende Sender-MSS-Werte von 1388 oder 1220. RFC 9210 verlangt TCP als Rückfallweg.

Kleinere UDP-Antworten verschieben Arbeit zu TCP. Das Dokument nennt gemessene 3–5 Prozent, fordert aber lokale Lastbeobachtung. Eine fremde Messung genehmigt keine eigene Kapazität. Benötigt werden EDNS-Größe, tatsächliche Bytes, TC, Verbindungsrate, MSS, Latenz und Ressourcenverbrauch.

Sonderwege brauchen eigene Herkunftsfelder

Rekursive Resolver sollten Dual Stack sein. Ein Single-Stack-Resolver darf jedoch Translation oder Weiterleitung an einen Dual-Stack-Resolver nutzen. Diese Freiheit ist operativ nützlich, darf aber nicht als unabhängiger nativer Pfad ausgewiesen werden.

Eine mit PREF64 synthetisierte IPv6-Adresse hängt von Präfix, Übersetzer und IPv4-Ziel ab. RFC 10001 verweist für sichere Entdeckung auf RFC 9872. Der Nachweis muss native, übersetzte und weitergeleitete Auflösung unterscheiden.

Zwei Single-Stack-Resolver dürfen ungelöste Anfragen nicht gegenseitig weiterleiten. Ist eine Zone in beiden Familien kaputt, entsteht eine Endlosschleife. Der Empfänger der Weiterleitung muss beide Familien selbst vervollständigen und darf nicht zurückleiten.

Auch Stub-Resolver können die vom Netz angebotene Auswahl verkleinern. Manche Implementierungen behalten nur wenige Resolver-Adressen und ignorieren Überschüsse nichtdeterministisch. DHCP- oder RA-Ausgabe ist Absicht; der tatsächlich geladene Clientzustand ist Betrieb.

Drei Spalten im Nachweis: Norm, Verfahren, Laufzeit

Für jede kritische Zone braucht die Laufzeitspalte getrennte IPv4-only- und IPv6-only-Traces: Beobachtungspunkt, Zeit, Resolver-Version, alle Verweise, NS, A, AAAA, Glue, Geschwisterpfade, kontaktiertes Ziel, UDP/TCP, EDNS, Antwortgröße, Timeout-Stufe, DNSSEC und RRset-Fingerprint. Anwendungsauswahl und Verbindungsergebnis gehören in eine weitere Schicht.

Die Verfahrensspalte beschreibt, was Registrar, Registry oder DNS-Provider tatsächlich prüft. Die technischen Nameserver-Anforderungen der IANA sind ein konkretes Verfahren, aber RFC 10001 hat keine IANA-Aktion. Es regt eine Überprüfung an. Erst eine veröffentlichte Verfahrensänderung und deren Anwendung belegen den nächsten Zustand.

Die Normspalte enthält die BCP-Anforderung. Sie darf weder die anderen Spalten überschreiben noch von ihnen verschwinden. So bleibt sichtbar, ob ein Fehler in der Regel, in der Kontrolle oder im Betrieb liegt.

Heng Lus Primat des laufenden Codes liefert dafür den Maßstab: Veröffentlichung ist keine Wirklichkeit. Seine Minimale Anfangsspezifikation und freiwillige Übernahme erlaubt strikte gemeinsame Invarianten für Interoperabilität, lässt aber Umsetzung, Anbieterwahl und spätere Änderung bei den Betreibern.

Die Richtlinie kann zwei Wege fordern. Betriebsautorität entsteht erst, wenn beide Wege laufen und ihre Daten übereinstimmen.