Warum IPv6-Netzwerke DNS-Konfigurationsprobleme verursachen

Automatische Konfiguration in IPv6-Netzwerken

SLAAC ermöglich eine verteilte Adresszuweisung, wobei jeder Host die Netzwerkpräfixe, die für das lokale Netzwerk verwendet werden sollen, automatisch erfährt und nachfolgend seine eigenen IPv6-Adressen konfiguriert, indem er eine geeignete Schnittstellenkennung, den sogenannten Interface Identifier (analog zur Host-ID von IPv4), für jedes Netzwerkpräfix auswählt. SLAAC erlaubt auch einige andere grundlegende Netzwerkkonfigurationen, zum Beispiel IPv6-Standardrouten. Es gilt als schlankes Protokoll zur Netzwerkkonfiguration, das die Anforderungen hinsichtlich der automatischen Konfiguration für die meisten einfachen Netzwerk-Setups erfüllen kann.

Demgegenüber steht mit DHCPv6 ein umfassenderes Protokoll für die Netzwerkkonfiguration. DHCPv6 ermöglicht eine zentrale Host-Konfiguration, wobei ein DHCPv6-Server – oder eine Gruppe von DHCPv6-Servern – IPv6-Hosts alle Informationen für die Netzwerkkonfiguration zur Verfügung stellt. Ähnlich wie sein IPv4-Pendant „least“ DHCPv6 IPv6-Adressen an IPv6-Hosts und kann außerdem alle möglichen Informationen bezüglich der Netzwerkkonfiguration liefern, zum Beispiel Web-Proxies.

Die Unterstützung für SLAAC ist obligatorisch, für DHCPv6 hingegen nur optional. Infolgedessen ist SLAAC der kleinste gemeinsame Nenner, wenn es um die automatische Konfiguration von IPv6-Hosts geht.

Automatische DNS-Konfiguration bei IPv6

Bereits am Anfang des Designs von SLAAC und DHCPv6 waren die einzigen Informationen zur Netzwerkkonfiguration, die als unverzichtbar galten, eine IPv6-Adresse und eine IPv6-Standardroute. Alle sonstigen Konfigurationsinformationen wurden überwiegend als optional angesehen und fehlen deshalb in SLAAC. Sie finden nur bei DHCPv6 Unterstützung.

Daher mussten Netzwerk-Setups, die die automatische Konfiguration eines RDNSS erforderten – Server, deren Rolle darin besteht, einem anfragenden Host die korrekte IP-Adresse eines bestimmten Domain-Namens zu liefern – DHCPv6 verwenden, um solche Informationen zu übermitteln. Im Laufe der Zeit stellte sich heraus, dass Informationen im Zusammenhang mit dem Domain Name System (DNS) in der Praxis so wichtig waren wie IPv6-Adressen oder IPv6-Routen, da auf die meisten Netzwerkservices nicht über ihre IP-Adressen, sondern über die jeweiligen Domain-Namen zugegriffen wird. Die Unterstützung für eine DNS-bezogene Konfiguration erhielt SLAAC schließlich 2007 in Form von experimentellen DNS-Optionen für SLAAC. Und erst 2010 wurde ein einsatzreifer Standard für diese DNS-Optionen veröffentlicht.

Teilweise als Ergebnis einer solch späten Standardisierung enthielt eine Reihe von SLAAC-Implementierungen nie Unterstützung für DNS-bezogene Optionen und war zur DNS-Konfiguration auf die entsprechende DHCPv6-Unterstützung angewiesen. Auf der anderen Seite erachteten die IPv6-Implementierungen, die Unterstützung für die zuvor genannten DNS-bezogenen Optionen enthielten, eine DHCPv6-Unterstützung im Grunde als unnötig. Daher entfiel die Unterstützung von DHCPv6 komplett – noch nicht einmal, um DNS-bezogene Informationen zu konfigurieren.

Die Unterstützung für die automatische DNS-Konfiguration in IPv6 wurde am Ende zum Gegenstand einer erbitterten Auseinandersetzung in bestimmten Kreisen der Internet Engineering Task Force zwischen Befürwortern von SLAAC und DHCPv6. Die SLAAC-Anhänger (zum Beispiel Googles Android) weigerten sich, DHCPv6 zu implementieren, während sich die DHCPv6-Anhänger (zum Beispiel Microsoft) weigerten, die DNS-Optionen von SLAAC zu implementieren.

Der Streit wirkte sich nicht nur auf Host-Implementierungen aus, sondern betraf ebenso Router- und Serverimplementierungen. Beispielsweise implementieren einige Router SLAAC, setzen die DNS-bezogenen Optionen für SLAAC aber nicht um. Ähnlich verzichten einige Netzwerkgeräte, die Informationen zur Netzwerkkonfiguration liefern sollen, auf die Implementierung von DHCPv6 – selbst die grundlegende DHCPv6-Serverfunktionalität fehlt, die es ihnen erlauben würde, DNS-bezogene Informationen via DHCPv6 zu übermitteln.

DNS-Konfigurationsprobleme in IPv6-Netzwerken

Die fehlende Unterstützung für die DNS-bezogenen Optionen von SLAAC oder für DHCPv6 in verschiedenen populären IPv6-Implementierungen führte zu einer Situation, in der es keinen einzelnen Mechanismus gibt, mit dem sich DNS-bezogene Informationen für alle wichtigen IPv6-Host-Implementierungen bereitstellen lassen. Mit anderen Worten: Da unterschiedliche Host-Implementierungen DNS-bezogene Informationen nur über DHCPv6 oder SLAAC erfahren können, muss ein Netzwerk, das alle wichtigen IPv6-Implementierungen unterstützen soll, DNS-bezogene Konfigurationsinformationen sowohl über SLAAC als auch DHCPv6 zur Verfügung stellen.

Das Gleiche gilt für Router- und Serverimplementierungen: Nicht alle Router-Implementierungen unterstützen die DNS-Optionen von SLAAC und DHCPv6. Deshalb kann die Unterstützung eines spezifischen Mechanismus für die DNS-Konfiguration, ob SLAAC oder DHCPv6, nicht praktikabel sein oder zusätzliche Netzwerkgeräte mit der entsprechenden Unterstützung erfordern.

In vielen Netzwerk-Setups wurden Probleme bei der rekursiven DNS-Konfiguration durch die Tatsache verdeckt, dass die meisten Bereitstellungen von IPv6-Netzwerken im Dual-Stack-Verfahren stattfinden, das heißt, hier kommen IPv6 und IPv4 zum Einsatz, nicht ausschließlich IPv6. Weil DNS-bezogene Informationen ohne Weiteres per DHCPv4 verfügbar sind, können sich Dual-Stack-Knoten immer auf IPv4-basierte DNS-Anfragen verlassen.

Doch Dual Stack wird nicht ewig die dominante Deployment-Option bleiben. Schon jetzt basieren einige mobile Netzwerke rein auf IPv6, und es ist nur eine Frage der Zeit, bis RDNSS-Probleme sich weiter ausbreiten werden.

SLAAC und DHCPv6 gemeinsam nutzen?

Reine IPv6-Netzwerke verfügen über keine andere Möglichkeit, als DNS-bezogene Informationen via SLAAC und DHCPv6 zu übertragen. Aber diese Alternative verursacht drei Hauptprobleme: zusätzliche Komplexität, die Möglichkeit von nicht synchronen Informationen zwischen SLAAC und DHCPv6 sowie die Möglichkeit einer inkonsistenten Host-Konfiguration.

Zwei verschiedene Protokolle für die Übermittlung der gleichen Konfigurationsinformationen zu unterstützen, führt zu unnötiger Komplexität und diese wiederum zu größeren Schwierigkeiten beim Troubleshooting von Problemen mit der Netzwerkkonfiguration.

Da die serverseitige SLAAC- und DHCPv6-Konfiguration in der Regel separat durchgeführt wird, ist es sehr wahrscheinlich, dass die zugehörigen Konfigurationen nicht mehr synchron sind oder sogar Konflikte hervorrufen. So könnte ein Administrator etwa die RDNSS-Adressen in der SLAAC-Konfiguration aktualisieren, aber vergessen, diese Informationen in der entsprechenden DHCPv6-Konfiguration upzudaten. Daher würde das Netzwerk über diese zwei Protokolle widersprüchliche Informationen liefern.

Darüber hinaus könnten Betriebssysteme verschiedene Netzwerkkonfigurationen aufweisen, je nachdem, ob sie nur SLAAC unterstützen, wie Microsoft es vorsieht, nur DHCPv6 oder beides. Für Netzwerkbetrieb und -Management ist das ein klarer Nachteil, der auch in einer Studie der Internet Engineering Task Force zum Ausdruck kommt. Die Untersuchung aus dem Jahr 2017 überprüfte, inwieweit rekursive DNS-Server durch einzelne Betriebssysteme betroffen waren.

Die Konfiguration von RDNSS in reinen IPv6-Netzwerken wird auch weiterhin eine Herausforderung bleiben, bis es zu einem Konsens kommt, wie sich diese Informationen am besten übermitteln lassen. Bis auf Weiteres bewältigen Dual Stack Deployments Probleme bei der rekursiven DNS-Konfiguration typischerweise dadurch, indem sie sich auf DHCPv4 stützen. Das grundlegende Problem ist dadurch aber nicht vom Tisch. Kurz- oder langfristig wird es bei Dual Stack Deployments höchstwahrscheinlich einige unangenehme Überraschungen geben.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!