6. Deployment Notes (Deployment-Hinweise)

Während DNS64 Teil einer Strategie zur Unterstützung der IPv6-Bereitstellung in einer Internetworking-Umgebung mit einigen reinen IPv4- und reinen IPv6-Netzwerken sein soll, ist es wichtig zu erkennen, dass es mit einigen Dingen inkompatibel ist, die möglicherweise in einem reinen IPv4- oder Dual-Stack-Kontext bereitgestellt werden.

6.1. DNS Resolvers and DNS64 (DNS-Resolver und DNS64)

Full-Service-Resolver, die sich der DNS64-Funktion nicht bewusst sind, können (fehl)konfiguriert werden, um als Mixed-Mode-Iterative- und Forwarding-Resolver zu fungieren. In einem nativen IPv4-Kontext kann diese Art von Konfiguration funktionieren. Es ist unmöglich, sie ordnungsgemäß zum Laufen zu bringen, ohne dass sie sich der DNS64-Funktion bewusst ist, da sie wahrscheinlich irgendwann reine IPv4-Glue-Records erhält und versucht, diese für die Auflösung zu verwenden. Das zurückgegebene Ergebnis wird nur A-Einträge enthalten, und ohne die Fähigkeit, die DNS64-Funktion durchzuführen, wird der Resolver nicht in der Lage sein, die notwendigen AAAA-Abfragen zu beantworten.

6.2. DNSSEC Validators and DNS64 (DNSSEC-Validatoren und DNS64)

Ein vorhandener DNSSEC-Validator (d.h. einer, der sich DNS64 nicht bewusst ist) könnte alle Daten, die von DNS64 kommen, als manipuliert ablehnen (selbst wenn er bei der Abfrage nicht CD gesetzt hat). Wenn es notwendig ist, eine Validierung hinter dem DNS64 zu haben, muss der Validator wissen, wie er die DNS64-Funktion selbst durchführen kann. Alternativ kann der validierende Host eine vertrauenswürdige Verbindung mit einem DNS64 herstellen und dem DNS64-rekursiven Resolver erlauben, alle Validierungen in seinem Namen durchzuführen.

6.3. DNS64 and Multihomed and Dual-Stack Hosts (DNS64 und Multihomed- und Dual-Stack-Hosts)

6.3.1. IPv6 Multihomed Hosts (IPv6 Multihomed-Hosts)

Synthetische AAAA-Einträge können auf der Grundlage des Netzwerkkontexts konstruiert werden, in dem sie konstruiert wurden. Wenn ein Host DNS-Abfragen an Resolver in mehreren Netzwerken sendet, ist es möglich, dass einige von ihnen Antworten von einem DNS64 erhalten, ohne dass alle über ein NAT64 verbunden sind. Angenommen, ein System hat zwei Schnittstellen, i1 und i2. Während i1 über NAT64 mit dem IPv4-Internet verbunden ist, hat i2 nur native IPv6-Konnektivität. I1 könnte eine AAAA-Antwort von einem DNS64 erhalten, das für ein bestimmtes NAT64 konfiguriert ist; die in dieser AAAA-Antwort enthaltene IPv6-Adresse wird über i2 mit nichts verbinden.

+---------------+                 +-------------+
|      i1 (IPv6)+----NAT64--------+IPv4 Internet|
|               |                 +-------------+
| host          |
|               |                 +-------------+
|      i2 (IPv6)+-----------------+IPv6 Internet|
+---------------+                 +-------------+

Dieses Beispiel veranschaulicht, warum es im Allgemeinen vorzuziehen ist, dass Hosts DNS-Antworten von einer Schnittstelle als lokal für diese Schnittstelle behandeln. Die auf einer Schnittstelle empfangene Antwort funktioniert nicht auf der anderen Schnittstelle. Hosts, die versuchen, DNS-Antworten global zu verwenden, können in diesen Fällen auf überraschende Fehler stoßen.

Beachten Sie, dass das Problem nicht darin besteht, dass es zwei Schnittstellen gibt, sondern dass zwei Netzwerke beteiligt sind. Dieselben Ergebnisse könnten mit einer einzigen Schnittstelle erzielt werden, die zu zwei verschiedenen Netzwerken geroutet wird.

6.3.2. Accidental Dual-Stack DNS64 Use (Versehentliche Dual-Stack-DNS64-Nutzung)

Angenommen, i1 hat IPv6-Konnektivität und kann über NAT64 eine Verbindung zum IPv4-Internet herstellen, aber i2 hat native IPv4-Konnektivität. In diesem Fall könnte i1 eine IPv6-Adresse von einem synthetischen AAAA erhalten, die besser über natives IPv4 erreicht werden würde. Es ist wiederum wert zu betonen, dass dies auftritt, weil zwei Netzwerke beteiligt sind.

+---------------+                 +-------------+
|      i1 (IPv6)+----NAT64--------+IPv4 Internet|
|               |                 +-------------+
| host          |
|               |                 +-------------+
|      i2 (IPv4)+-----------------+IPv4 Internet|
+---------------+                 +-------------+

Die Standardkonfiguration von Dual-Stack-Hosts besteht darin, dass IPv6 gegenüber IPv4 bevorzugt wird ([RFC3484]). In dieser Anordnung wird der Host häufig das NAT64 verwenden, wenn natives IPv4 wünschenswerter wäre. Aus diesem Grund sollten Hosts mit IPv4-Konnektivität zum Internet die Verwendung von DNS64 vermeiden. Dies kann teilweise von ISPs gelöst werden, wenn sie DNS-Resolver für Clients bereitstellen, aber das ist keine Garantie dafür, dass das NAT64 niemals verwendet wird, wenn eine native IPv4-Verbindung verwendet werden sollte. Es gibt keinen allgemeinen Mechanismus, um sicherzustellen, dass nativer IPv4-Transit immer bevorzugt wird, da für einen DNS64-oblivious-Host DNS64 genau wie ein gewöhnlicher DNS-Server aussieht. Betreiber eines NAT64 sollten erwarten, dass Verkehr durch das NAT64 geleitet wird, selbst wenn es nicht notwendig ist.

6.3.3. Intentional Dual-Stack DNS64 Use (Absichtliche Dual-Stack-DNS64-Nutzung)

Betrachten Sie schließlich den Fall, in dem die IPv4-Konnektivität auf i2 nur mit einem LAN besteht und nicht mit dem IPv4-Internet. Das IPv4-Internet ist nur über NAT64 zugänglich. In diesem Fall ist es kritisch, dass DNS64 keine AAAA-Antworten für Hosts im LAN synthetisiert, oder dass DNS64 über Hosts im LAN Bescheid weiß und kontextsensitive Antworten ("Split-View"-DNS-Antworten) für Hosts innerhalb des LAN bereitstellt. Wie bei jeder Split-View-DNS-Anordnung müssen Betreiber darauf vorbereitet sein, dass Daten von einem Kontext in einen anderen gelangen und dass Fehler auftreten, weil Knoten, die von einem Kontext aus zugänglich sind, von dem anderen aus nicht zugänglich sind.

+---------------+                 +-------------+
|      i1 (IPv6)+----NAT64--------+IPv4 Internet|
|               |                 +-------------+
| host          |
|               |
|      i2 (IPv4)+---(local LAN only)
+---------------+

Es ist wichtig für Deployer von DNS64 zu erkennen, dass die Bereitstellung von DNS64 für einen Dual-Stack-Host unter bestimmten Umständen dazu führt, dass der Host es vorzieht, Pakete über NAT64 anstelle von nativem IPv4 zu senden, mit dem damit verbundenen Verlust an Leistung oder Funktionalität (oder beidem), der durch das NAT verursacht wird. Gleichzeitig sind einige Hosts nicht in der Lage, über DNS-Server zu lernen, die auf IPv6-Adressen bereitgestellt werden, oder können einfach keine DNS-Pakete über IPv6 senden.