Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist

Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist (Motivationen und Implikationen der Synthese von AAAA Resource Records, wenn echte AAAA Resource Records existieren)

Die Motivation für die Synthese von AAAA RRs, wenn echte AAAA RRs existieren, besteht darin, das folgende Szenario zu unterstützen:

• Eine reine IPv4-Serveranwendung (z.B. Webserver-Software) läuft auf einem Dual-Stack-Host. Es können auch Dual-Stack-Serveranwendungen auf demselben Host laufen. Dieser Host hat vollständig routbare IPv4- und IPv6-Adressen, und daher hat der autoritative DNS-Server einen A-Eintrag und einen AAAA-Eintrag.

• Ein reiner IPv6-Client (unabhängig davon, ob die Clientanwendung rein IPv6 ist, der Client-Stack rein IPv6 ist oder er nur eine IPv6-Adresse hat) möchte auf den oben genannten Server zugreifen.

• Der Client stellt eine DNS-Abfrage an einen DNS64-Resolver.

Wenn DNS64 nur einen synthetischen AAAA generiert, wenn es keinen echten AAAA gibt, schlägt die Kommunikation fehl. Obwohl es einen echten AAAA gibt, ist der einzige Weg für eine erfolgreiche Kommunikation die übersetzte Adresse. Um dieses Szenario zu unterstützen, möchte der Administrator eines DNS64-Dienstes möglicherweise die Synthese von AAAA RRs auch dann aktivieren, wenn echte AAAA RRs existieren.

Die Implikation der Einbeziehung synthetischer AAAA RRs, wenn echte AAAA RRs existieren, besteht darin, dass übersetzte Konnektivität in einigen Fällen gegenüber nativer Konnektivität bevorzugt werden kann, wenn DNS64 im DNS-Server-Modus betrieben wird.

RFC 3484 [RFC3484]-Regeln verwenden "longest matching prefix", um die bevorzugte zu verwendende Zieladresse auszuwählen. Wenn also der DNS64-Resolver sowohl die synthetischen AAAA RRs als auch die echten AAAA RRs zurückgibt, dann wird, wenn DNS64 von derselben Domain wie der initiierende Host betrieben wird und ein globales Unicast-Präfix (bezeichnet als Network-Specific Prefix (NSP) in [RFC6052]) verwendet wird, ein synthetischer AAAA RR wahrscheinlich bevorzugt.

Dies bedeutet, dass ohne weitere Konfiguration:

• Im Szenario "ein IPv6-Netzwerk zum IPv4-Internet" wird der Host übersetzte Konnektivität bevorzugen, wenn ein NSP verwendet wird. Wenn das in [RFC6052] definierte Well-Known Prefix verwendet wird, wird er wahrscheinlich native Konnektivität bevorzugen.

• Im Szenario "IPv6-Internet zu einem IPv4-Netzwerk" ist es möglich, die Auswahl in Richtung des echten AAAA RR zu beeinflussen, wenn der DNS64-Resolver den echten AAAA zuerst in der DNS-Antwort zurückgibt, wenn ein NSP verwendet wird (die Verwendung des Well-Known Prefix wird in diesem Fall nicht unterstützt).

• Im Szenario "ein IPv6-Netzwerk zu einem IPv4-Netzwerk" ist es für lokale Ziele (d.h. Zielhosts innerhalb des lokalen Standorts) wahrscheinlich, dass das NSP und das Zielpräfix gleich sind, sodass wir die Reihenfolge der RR in der DNS-Antwort verwenden können, um die Auswahl durch native Konnektivität zu beeinflussen. Wenn das Well-Known Prefix verwendet wird, wählt die "longest matching prefix"-Regel native Konnektivität aus.

Das Problem kann durch ordnungsgemäße Konfiguration der RFC 3484 [RFC3484]-Policy-Tabelle gelöst werden.