Zusammenfassung

  • Die IP-Version, die einen DNS-Austausch transportiert, bestimmt nicht die Adressfamilie der angefragten Datensätze: Eine AAAA-Anfrage kann über IPv4 laufen, eine A-Anfrage über IPv6.
  • RFC 3596 ergänzte den 128-Bit-AAAA-Record und passte bestehende Antwortregeln an, ohne DNS-Daten an den Netzwerkpfad der Anfrage zu binden.

IPv6 – aber auf welcher Ebene?

Ein Resolver sendet eine DNS-Frage in einem IPv4-Paket: „Welche AAAA-Records gehören zu diesem Namen?“ Der IPv4-Header beschreibt den Weg genau dieser Nachricht. Der Abfragetyp verlangt Daten zu einer IPv6-Adresse. Das widerspricht sich nicht. RFC 3596 hält ausdrücklich fest, dass die IP-Version für eine Abfrage unabhängig von der Protokollversion der abgefragten Records ist. RFC 4472 formuliert die praktische Folge: AAAA kann über IPv4 abgefragt werden, A über IPv6.

Die Unterscheidung geht leicht verloren, weil beide Ebenen dieselben Wörter IPv4 und IPv6 verwenden. Die eine bezeichnet die Netzwerkkapselung der Anfrage, die andere den Inhalt eines DNS-Resource-Records. Würde ein Server seine Antwort vom beobachteten Transport abhängig machen, hinge der DNS-Befund vom Weg der Frage ab – obwohl dieser Weg nicht festlegt, welche Adressen zum Namen gehören.

Die Unabhängigkeit gilt ebenso in umgekehrter Richtung. IPv6-Transport zwingt niemanden zur AAAA-Abfrage; er kann auch eine A-Anfrage tragen. Aus der Adressfamilie des ankommenden Pakets folgt zudem nicht, dass der Fragesteller eine zurückgegebene Adresse nutzen kann. Der Standard definiert die Trennung, nicht die spätere Erreichbarkeit oder eine erfolgreiche Anwendungssitzung.

Den Datensatz erweitern, nicht den Transport austauschen

Im früheren DNS-Modell speicherte der A-Record eine 32-Bit-IPv4-Adresse. RFC 1886 führte AAAA für 128-Bit-IPv6-Adressen und einen Mechanismus für Reverse-Lookups ein. RFC 3152 verlegte anschließend den Reverse-Baum von IP6.INT nach IP6.ARPA. RFC 3596 führte diese Änderungen zusammen, erhielt die IPv4-Unterstützung und definierte AAAA, Typ 28, als Record mit einer vollständigen IPv6-Adresse.

Das war eine Erweiterung des DNS-Datenmodells, kein neuer IPv6-Transport für DNS-Nachrichten. Anfragen und Antworten nutzten weiterhin den DNS-Austausch. Der IP-Transport konnte IPv4 oder IPv6 sein, unabhängig davon, ob A oder AAAA angefragt wurde. Der gemeinsame globale Namensraum musste sich nicht in ein „IPv4-DNS“ und ein „IPv6-DNS“ aufspalten, nur weil er nun beide Adressfamilien enthalten konnte.

Es gab eine echte Alternative. A6-Records konnten Adressen in Teile zerlegen und diese über DNS verketten; bei einem Präfixwechsel hätte das manche Aktualisierungen reduzieren können. Die Flexibilität brachte aber verkettete Abfragen und zusätzliche Abhängigkeiten mit sich. RFC 3363 dokumentierte die Entscheidung, AAAA auf dem Standards Track zu belassen und A6 sowie Bit Labels auf Experimental zu setzen; RFC 3364 legte die Abwägungen dar. RFC 3596 entschied sich damit für einen vollständigen, direkt abrufbaren Adressdatensatz – nicht für eine Universallösung für Renummerierung oder IPv6-Einführung.

Auch die Antwortregeln wurden angepasst

RFC 3596 änderte außerdem die Additional-Section-Verarbeitung für NS-, SRV- und MX-Abfragen: lokal verfügbare, relevante A- und AAAA-Adressen konnten aufgenommen werden. Eine AAAA-Abfrage löst diese Verarbeitung nicht selbst aus. Ein direkt angefragter RR und eine Adresse als Zusatzinformation in einer anderen Antwort sind unterschiedliche Protokollverhalten.

„Der Server kann sie hinzufügen“ beweist nicht, dass alle Adressen existieren. Lokale Daten können fehlen, Caches unvollständig sein, und ein DNS-Record ist kein Testpaket. RFC 4472 warnt davor, Antwortdaten allein nach der Transportfamilie auszuwählen oder zu filtern: Der Weg zum DNS-Server sagt häufig nichts darüber aus, welche Record-Familie der Client benötigt. Wird eine Familie aus diesem Grund unterdrückt, kann derselbe Name je nach Anfragepfad scheinbar unterschiedliche Tatsachen haben.

Eine AAAA-Antwort belegt lediglich, dass DNS für einen Namen IPv6-Adressdaten zurückgegeben hat. Sie beweist weder eine IPv6-Route von diesem Resolver noch einen lauschenden Dienst an der Adresse, eine freigegebene Firewall-Sitzung, erfolgreiche DNSSEC-Validierung oder eine Verbindung der Anwendung. Der Empfang über IPv4 sagt ebenso wenig darüber aus, welche IP-Version eine spätere Verbindung zum Dienst verwendet.

Eine Grenze, die Koexistenz verständlich machte

Der historische Beitrag von RFC 3596 wird oft mit „DNS bekam AAAA“ zusammengefasst. Er bewahrte zugleich eine Invariante, als das Internet eine weitere Adressfamilie hinzufügte: Das Paket, das eine Frage transportiert, und die im Record codierte Adressfamilie sind zwei unabhängige Dimensionen. Während der Übergangszeit konnte IPv4-Transport IPv6-Daten abrufen und IPv6-Transport weiterhin IPv4-Daten – im selben Namensraum.

Die RFCs definieren den Mechanismus und die beabsichtigte Trennung. Sie zeigen nicht, wie umfassend Implementierungen sie befolgten, wie sich ein bestimmter Resolver verhielt oder ob A und AAAA eines Namens gleichzeitig brauchbar waren. Dafür braucht es eigene Belege zu Implementierung, Konfiguration, Messung und Erreichbarkeit.

Quellen: RFC 1034; RFC 1035; RFC 1886; RFC 3152; RFC 3363; RFC 3364; RFC 3596; RFC 3597; RFC 4472.