Wie IPv6 DNS ankündigte: RDNSS, DNSSL und die RFCs 5006, 6106 und 8106

Zusammenfassung

SLAAC konnte einem IPv6-Host Adresse und Route geben, ohne den rekursiven DNS-Resolver mitzuliefern, der Namen in Ziele übersetzt.
RDNSS brachte die Resolver-Suche in Router Advertisements; DNSSL ergänzte Suchsuffixe, spätere RFCs regelten Ablaufzeiten, Quellenreihenfolge und verbindliche Unterstützung.

Eine Adresse ist kein Resolver

Ein IPv6-Host kann eine gültige Adresse, ein Präfix und einen Standardrouter haben und trotzdem schon vor dem Aufruf einer Website scheitern: Es fehlt ein rekursiver Resolver, der den Namen der Website einem Ziel zuordnet. Das Netz hat dem Host gesagt, wohin Pakete gehen können. Wo er nach Namen fragen soll, hat es offengelassen.

Neighbor Discovery und Stateless Address Autoconfiguration erledigten den ersten Teil. Router Advertisements transportierten Link-Informationen; mit SLAAC konnte ein Host eine Adresse ohne DHCPv6-Adresslease bilden. DNS lief auf einem anderen Pfad. 2007 hielt RFC 5006 fest, dass DHCP der einzige DNS-Konfigurationsmechanismus der IETF auf dem Standards Track war. Für ein Notebook, das zwischen WLANs wechselte, war es lästig, an jedem Ort den Resolver von Hand auszutauschen.

RFC 5006 bot einen weiteren Weg, allerdings als Experimental-Option: Ein IPv6-Router-Advertisement konnte eine Recursive-DNS-Server-Option, kurz RDNSS, enthalten. Der Host lernte die Resolver-Adresse mit derselben Ankündigung, die auch die Link-Konfiguration brachte. Ein zweiter Protokollaustausch war nicht nötig. Der Router musste dennoch eingerichtet werden; das RFC brachte ihm nicht bei, seinen eigenen DNS-Server zu finden.

Der Router kündigte nun auch Namen an

2010 brachte RFC 6106 die DNS-Optionen auf den Standards Track und ergänzte DNSSL, eine DNS-Suchliste. RDNSS lieferte eine oder mehrere Resolver-Adressen. DNSSL lieferte Suffixe, die ein Host an einen unvollständigen Namen anhängen konnte, den eine Anwendung abfragte. So konnten Präfix, Router, Resolver und Suchliste über denselben Strom von Router Advertisements ankommen.

DHCPv6 verschwand nicht. RFC 6106 beschrieb DHCPv6 und RA als Mechanismen, die nebeneinander bestehen und je nach Netz und Host-Konfiguration nützlich sein konnten. Später empfahl RFC 8106 dem Host, DNS-Informationen aus mehreren Router Advertisements oder aus DHCP in einer geordneten Liste zu führen. Ein vom Nutzer fest eingetragener DNS-Server blieb eine eigene Wahl. Die Frage lautete nun, welche Quelle Vorrang hat – nicht, welches Verfahren überall gewinnt.

Paketverlust änderte den Takt

RDNSS- und DNSSL-Einträge laufen ab. Nach Ablauf entfernt der Host die Information; eine Ankündigung ist eine befristete Zuweisung von Resolver-Daten, keine dauerhafte Einstellung. RFC 6106 begrenzte die Lebensdauer anhand des maximalen Abstands zwischen Router Advertisements. RFC 8106 hielt 2017 fest, dass die frühere Untergrenze von zwei solchen Intervallen DNS-Optionen auf stark verlustbehafteten Links ablaufen lassen konnte. Der neue Standardwert beträgt das Dreifache des maximalen Intervalls.

Im Paketdiagramm ist das ein kleiner Unterschied, im Störungsprotokoll ein großer: Adresse und Route können gültig bleiben, während der Resolver-Eintrag verschwindet. Für eine Anwendung sieht das dann nach einem Netzausfall aus, obwohl der Host eine IP-Adresse direkt erreichen kann.

Unterstützung wurde Teil der IPv6-Baseline

Mit der Entwicklung stieg auch die Anforderung. RFC 6434 sagte 2011, Implementierungen SHOULD die DNS-RA-Option unterstützen. RFC 8504 verlangte 2019, dass IPv6-Knoten sie MUST unterstützen. Aus dem experimentellen Ausweg wurde eine erforderliche Fähigkeit, denn eine Adresse allein reicht für praktisch nutzbares Internet nicht.

Die Quellenregeln geben dem Verfahren sein eigentliches Gewicht. RFC 8106 empfiehlt dem Host eine geordnete Liste von RA- und DHCP-Informationen; DHCP-Angaben stehen normalerweise zuerst. Ein mit SEND geschütztes RA hat Vorrang vor einer nicht authentifizierten DHCP-Quelle. Ein statisch vom Nutzer gesetzter DNS-Server kann die angekündigten Angaben überstimmen.

Die RFCs belegen Änderungen am Entwurf und an den Anforderungen. Eine offizielle Zählung der Hosts mit RDNSS enthalten sie nicht; eine Zahl für eingesetzte Clients lässt sich daraus nicht ableiten.