Zusammenfassung

  • RFC 3152 wählte IP6.ARPA, verlangte dessen Delegation nach IAB-Anweisung und ordnete weitere Delegationen entsprechend der IPv6-Adressvergabe; einzelne Zonen und PTR-Daten entstanden dadurch nicht automatisch.
  • IP6.INT wurde für neue Implementierungen ungeeignet und sollte geordnet auslaufen. Der spätere Schritt von 2005 belegt, dass Konsens und operatives Ende verschiedene Zeitpunkte hatten.
  • Belastbare Evidenz trennt RFC-Status, Eltern- und Kinddelegation, PTR, abgefragtes Suffix, Cache, DNS-Antwort, Validierung und Anwendungsentscheidung. Reverse-Namen sind keine Identitätsnachweise.

Ein Ziel war beschlossen, bevor alle Systeme ankamen

Frühere IPv6-Dokumente verwiesen für die Adress-zu-Name-Suche auf IP6.INT. Gleichzeitig etablierte der IAB .ARPA als Ort technischer Infrastruktur-Namensräume. RFC 3152 brachte beides zusammen.

Das BCP änderte Verweise in fünf RFCs, bat IANA um die Delegation von IP6.ARPA nach IAB-Vorgaben und band die Hierarchie an die Zuteilung des IPv6-Adressraums. Regionale Register sollten die zu ihren Ressourcen passenden Teilbäume erhalten.

„Deprecated“ bedeutete ausdrücklich nicht sofort abgeschaltet. Alte Nutzung war für neue Implementierungen unpassend und sollte voraussichtlich geordnet verschwinden. Installierte Bibliotheken, parallele Zonen und alte Cache-Einträge konnten weiterbestehen. Der Standard schuf eine Richtung, keine globale Release-Nacht.

Delegation verteilte Kontrolle, nicht Gewissheit

IETF bestimmte die Konvention, IAB und IANA die Infrastrukturdelegation, RIRs und Adressinhaber nachgelagerte Teilbäume, DNS-Betreiber die Zonendaten. RFC 3172 beschrieb .ARPA als begrenzte, betriebskritische Infrastrukturdomäne und bestätigte die an Nummernressourcen gekoppelte Hierarchie.

Eine Adresszuteilung beweist dennoch keine Reverse-Delegation. Ein Referral beweist keinen funktionierenden Kindserver. Eine autoritative Zone beweist keinen PTR. Ein PTR beweist keine passende Vorwärtsauflösung, Erreichbarkeit oder Berechtigung.

Jede Stufe besitzt einen anderen Betreiber und Beleg. Ein einzelnes Feld wie reverse_dns_ready würde Fehlerursache und Verantwortung verdecken.

Der richtige Abfragename war nur der Anfang

RFC 3596 konsolidierte später die Nibble-Schreibweise unter IP6.ARPA: Hexadezimalstellen werden umgekehrt und einzeln als Labels angeordnet. Die korrekte Bildung des QNAME bestätigt lediglich den Einstieg.

Danach können Referral, NXDOMAIN, SERVFAIL, Timeout, Cache, unsichere oder validierte Antwort folgen. PTR ist veröffentlichte Zonendata, kein Zertifikat für Eigentum oder Hostidentität. Auch die Vorwärtsauflösung des Zielnamens muss nicht zur Ausgangsadresse führen.

Client und Autorität migrierten deshalb unabhängig. Software konnte den neuen Baum abfragen, bevor eine Zone bereitstand; eine Zone konnte bereitstehen, während alte Clients weiterhin IP6.INT nutzten.

Überlappung verhinderte Bruch und erschwerte Beweise

Zeitweiser Parallelbetrieb vermied einen atomaren globalen Wechsel. Stilles Fallback konnte jedoch verschleiern, welcher Baum antwortete. Zwei positive Antworten konnten unterschiedliche Namen liefern. Ein negativer Cache konnte eine neue Delegation unsichtbar machen.

Ein Migrationsbeleg braucht exakten QNAME, Resolverversion, Cache- und Fallback-Status, Referral-Kette, Autorität, RCODE, RRset, TTL und Validierung. „Reverse DNS funktioniert“ reicht nicht.

Die spätere Chronologie zeigt die Strecke: RFC 3596 nahm IP6.ARPA 2003 in die Standards-Track-Spezifikation auf. RFC 4159 erklärte, dass konforme Implementierungen ab 1. September 2005 IP6.INT nicht mehr nutzen sollten, und bat RIRs um abgestimmte Beendigungspläne. Die Entscheidung von 2001 war wirksam, aber nicht gleichbedeutend mit vollständigem Rückbau.

Ein obsoletes RFC konnte ein dauerhaftes Ergebnis hinterlassen

RFC 3596 obsoletierte RFC 3152, weil es dessen Änderung übernahm. IP6.ARPA wurde nicht aufgegeben. RFC 3363 verschob A6 und Bitstring Labels in den Experimental-Status und bevorzugte AAAA. RFC 5855 stabilisierte später die Servernamen der Reverse-Zonen. RFC 9121 dokumentierte IP6.INT schließlich als historische, entfernte .INT-Infrastrukturdomäne.

Datensatzformat, Wurzelwahl, Serverbetrieb und Altlastenabbau waren verschiedene Flächen. Eine Erzählung vom bloßen Umbenennen wäre historisch falsch.

Keine neue Bedrohung bedeutete keine Sicherheit

RFC 3152 erwähnte bereits aus IPv4 bekannte Manipulationen von Adresse-zu-Name-Zuordnungen und erklärte, die neue Delegation schaffe keine zusätzlichen Gefahren. Das war keine Authentifizierung des PTR.

RFC 3596 behandelte DNS-Daten ohne geeignete Sicherheitstechniken als unsicher. DNSSEC kann Daten innerhalb einer DNS-Vertrauenskette bestätigen, aber weder die menschliche Bedeutung eines Namens noch die aktuelle Geräteherrschaft oder Anwendungsberechtigung.

Validierung, Vorwärtsabgleich und Nutzungsrichtlinie brauchen eigene Belege. Ein Reverse-Name darf aus einem Anzeigeattribut nicht unbemerkt zur Zugangsberechtigung werden.

Laufender Code maß die tatsächliche Migration

Bei korrekter Delegation und korrektem PTR kann ein Altclient weiterhin IP6.INT fragen. Ein zweiter nutzt IP6.ARPA, hält aber ein altes negatives Cache-Ergebnis. Nur ein dritter sieht den neuen Namen. Der normative Zustand ist gleich, die Laufzeitbeobachtung nicht.

Running-Code Primacy hebt RFC 3152 nicht auf. Das BCP bestimmt Wurzel und Delegationsmodell. Die Ausführung zeigt Suffix, Autorität, Antwort und Folge.

Die minimale Anfangsspezifikation koordinierte mit wenig gemeinsamem Zwang: neue Wurzel, Delegationsauftrag, adressgerechte Hierarchie, geordnete Abkehr. Gerade weil kein atomarer Wechsel verlangt wurde, konnte die Migration stattfinden. IP6.ARPA war daher schon richtig, während letzte Spuren von IP6.INT noch liefen.

Quellen