Zusammenfassung

  • A6 konnte eine IPv6-Adresse aus getrennt gepflegten DNS-Fragmenten zusammensetzen. Das ersparte bei manchen Umnummerierungen Änderungen, machte aber aus jedem Kettenglied eine weitere Abfrage, einen weiteren Cachezustand, eine weitere Ausfallchance und eine zusätzliche Verwaltungsabhängigkeit.
  • RFC 3363 verschob A6 und Binärlabels von Proposed Standard zu Experimental und bevorzugte AAAA für den Produktionsbetrieb. Die Statusänderung verengte die Empfehlung; sie schrieb weder laufenden Code noch bestehende Zonen um.

Eine veränderliche Adresse in Teilen zu speichern, hat einen unmittelbaren Reiz. Der stabile Hostanteil bleibt beim Host. Der Provider verwaltet den Präfix, den er austauschen kann. Erst bei einer Anfrage setzt ein Resolver die Teile zusammen.

Genau darin lag das besondere Versprechen des in RFC 2874 definierten A6-Records. Das DNS-Modell spiegelte eine administrative Tatsache: IPv6-Präfix und lokaler Identifikator können sich nach unterschiedlichen Zeitplänen ändern. Bei einer schnellen Umnummerierung ließ sich unter Umständen ein übergeordneter Präfix ersetzen, ohne jeden Blatt-Record anzufassen. Beim Multihoming konnte dieselbe Konstruktion mehrere Präfixbeziehungen ausdrücken. Als Entwurf war A6 allgemeiner als ein AAAA-Record, der die vollständigen 128 Bit enthält.

Der Preis wurde sichtbar, sobald aus der Darstellung eine Antwort werden musste. Ein Resolver konnte nicht zwingend einen Record lesen und aufhören. Er folgte dem Präfixnamen zu einem weiteren Record und vielleicht zu einem dritten. Jeder Schritt konnte eine eigene autoritative Abfrage verlangen. Jede Antwort besaß ihren eigenen Cachezustand, ihre eigene Lebensdauer, ihren Betreiber und ihre Möglichkeit, zu fehlen.

RFC 3363 machte aus diesem Abhängigkeitsgraphen eine Standardsentscheidung. Das im August 2002 als Informational veröffentlichte Dokument aktualisierte RFC 2673 und RFC 2874 und verschob beide Spezifikationen von Proposed Standard zu Experimental. Es hielt einen wahrgenommenen Konsens der DNSEXT- und NGTRANS-Gemeinschaften fest: Für die Produktion war AAAA vorzuziehen; A6 hatte interessante Eigenschaften, die besser verstanden werden sollten; und noch war unbekannt, ob sein Nutzen Kosten und Risiken überwog.

Diese Formulierung ist entscheidend. Sie besagte nicht, dass Zusammensetzbarkeit wertlos sei. Das begleitende RFC 3364 erläuterte den echten Vorteil von A6 ausführlich. A6 konnte Adressen darstellen, deren Präfixe sich ohne Vorwarnung änderten, auf eine Weise, die statische AAAA-Records während einer Abfrage nicht nachbilden konnten. Ein Vorverarbeitungssystem konnte zwar AAAA-Zonendaten neu erzeugen, verlagerte damit aber die Abhängigkeitsinformation lediglich in das Provisioning.

RFC 3363 richtete den Blick auf den Weg der Abfrage. Ohne bereits gecachte Antworten, so die Überlegung, würde die Auflösungszeit einer A6-Kette mit N Gliedern ungefähr proportional zu N wachsen. Auch die Ausfallwahrscheinlichkeit würde grob mit N steigen, weil jede Teilabfrage eine eigene Fehlerchance besaß. Das waren architektonische Abschätzungen, keine globale Messreihe. Das Dokument veröffentlichte weder einen weltweiten Latenzzensus noch behauptete es einen universellen Faktor.

Die Verwaltungsgrenze war ebenso wichtig wie die Zahl der Abfragen. Einige besonders nützliche A6-Anordnungen verwiesen aus der Blattzone hinaus auf eine Zone unter der Kontrolle einer anderen Organisation. Das DNS kann solche Verweise ausdrücken. Ihre Pflege ist schwieriger. Erfahrungen mit Glue und Reverse-Pointern hatten bereits gezeigt, dass organisationsübergreifende Referenzen schlecht altern, wenn kein Betreiber den vollständigen Reparaturweg kontrolliert.

Eine Kette konnte deshalb bei jeder lokalen Änderung korrekt und als Gesamtsystem dennoch defekt sein. Der Hostadministrator bewahrte den Suffix, der Provider veröffentlichte den Präfix, eine dritte Partei pflegte eine weitere Delegation. Der Resolver benötigte eine zeitlich konsistente Sicht auf alle Teile. Ein alter Cache konnte zwei Beobachter verschiedene Adressen zusammensetzen lassen, obwohl kein einzelner Record syntaktisch ungültig war.

AAAA traf eine andere Wahl. Die vollständige IPv6-Adresse stand in einem Resource Record. Umnummerierung konnte mehr Datensätze betreffen, und Automatisierung blieb nötig. Doch die Abhängigkeit einer Abfrage war sichtbar begrenzt. RFC 3363 empfahl, RFC 1886 auf dem Standardisierungspfad zu belassen und voranzubringen, während RFC 2874 Experimental wurde. RFC 3596 spezifizierte später das AAAA- und IP6.ARPA-Modell, das zur üblichen Produktionsreferenz wurde.

Der Reverse-Baum lieferte eine zweite Korrektur. RFC 2673 hatte Binärlabels eingeführt, den ersten neuen DNS-Labeltyp seit RFC 1035. Der Mechanismus bündelte Ein-Bit-Labels zu Bitfolgen und bot eine kompakte Darstellung für Reverse-Mapping. Der Einsatz zeigte ein härteres Problem: Server ohne Unterstützung für den neuen Labeltyp konnten Abfragen mit solchen Labels als fehlerhaft zurückweisen.

RFC 3363 kam zu dem Schluss, dass hexadezimale Textlabels die damals erwarteten Reverse-Delegationsmodelle darstellen konnten. Auch Binärlabels wurden auf Experimental gesetzt. Die geplante Verwendung von DNAME im Reverse-Baum wurde zusammen mit fragmentiertem A6 verworfen. Die Frage nach der Wurzel des Reverse-Baums lag außerhalb des Geltungsbereichs und war in RFC 3152 behandelt worden.

Dies war Standardisierung durch kontrollierte Subtraktion. Zwei Dokumente hatten Proposed Standard erreicht, doch die Einsatzdiskussion zeigte, dass ihre Neuheit die Kompatibilitätsfläche vergrößerte, bevor genügend Betriebserfahrung vorlag. Die Antwort löschte die Arbeit nicht. Experimental bewahrte sie zur Untersuchung und entfernte sie zugleich aus dem bevorzugten Produktionspfad.

Die Wirkung dieser Statushandlung darf nicht überhöht werden. Ein Dokument kann den formalen Pfad eines anderen Dokuments ändern. Es kann keinen Code aus einem Resolver entfernen, keine Zone neu schreiben, keinen Cache leeren, keinen organisationsübergreifenden Verweis reparieren und keine Migration zu AAAA beweisen. Standardstatus, Implementierungsunterstützung, veröffentlichte Daten und beobachtetes Ergebnis bleiben getrennte Belege.

Dieselbe Trennung verhindert einen AAAA-Siegesmythos. Ein vollständiger Record vermeidet serielle Adressmontage, garantiert aber weder frisches Provisioning noch korrekte Reverse-Daten, DNSSEC-Validierung, erreichbares Routing oder einen funktionierenden Dienst. RFC 4472 katalogisierte später zahlreiche IPv6-DNS-Betriebsprobleme, nachdem AAAA zur üblichen Darstellung geworden war. Die einfachere Abhängigkeitsstruktur reduzierte eine Klasse von Unsicherheit; sie schaffte den Betrieb nicht ab.

RFC 3597 ergänzt eine benachbarte Lehre. DNS-Software braucht eine Möglichkeit, unbekannte Resource-Record-Typen zu transportieren, ohne ihre Semantik sofort verstehen zu müssen. Generischer Umgang mit einem unbekannten Typ und Unterstützung einer neuen Labelsyntax sind jedoch verschiedene Kompatibilitätsflächen. Ein Server konnte unbekannte Recorddaten weitergeben und zugleich eine unbekannte Namenscodierung ablehnen.

Das heutige IANA-Register der DNS-Parameter hält Kennungen und Status fest. Es ist ein dauerhaftes Koordinationsartefakt, aber keine Bestandsaufnahme früherer Installationen. Es verrät nicht, welche Resolverversionen A6 unterstützten, welche Zonen es veröffentlichten, wie lange Records nach der Rückstufung überlebten oder was Nutzer tatsächlich beobachteten.

Zwei Essays von Lu Heng liefern den offengelegten analytischen Rahmen. „Minimum Initial Specification“ argumentiert, dass eine gemeinsame Schicht nur die deterministische Struktur enthalten sollte, die für Kompatibilität nötig ist, und die weitere Annahme den Teilnehmern mit laufendem Code überlassen sollte. A6 legte mehr dynamische Zusammensetzung in den gemeinsamen Auflösungspfad; AAAA ließ mehr Umnummerierungsarbeit bei Provisioning und Betreibern. „On Reality Layers“ verhindert, dass die Rückstufung mit einem sofortigen Betriebsereignis verwechselt wird. Zuerst änderte sich das Dokument.

Code, Zonen, Caches und Ergebnisse konnten auf unterschiedlichen Uhren folgen.

Die historische Lehre lautet nicht, dass Eleganz verdächtig ist. Sie lautet, dass Zusammensetzbarkeit Zuverlässigkeit verbraucht. Ein Baustein ist wertvoll, wenn er sich unabhängig ändern kann. Dieselbe Unabhängigkeit wird zum Risiko, wenn die endgültige Antwort nur entsteht, falls jeder Baustein, jeder Verwalter und jede Abfrage gleichzeitig verfügbar ist.

RFC 3363 vollzog einen disziplinierten Rückzug. Es hielt die Idee als Experiment verfügbar, verengte die Produktionsempfehlung und überließ den laufenden Systemen den Nachweis der Annahme. Die Adresse konnte weiterhin aus Teilen entstehen. Produktions-DNS musste nicht länger so tun, als wäre jedes zusätzliche Teil kostenlos.

Quellen