Aller au contenu principal

Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist (Annexe A. Motivations et implications de la synthèse d'enregistrements de ressources AAAA lorsque de véritables enregistrements de ressources AAAA existent)

La motivation pour synthétiser des enregistrements RR AAAA lorsque de véritables enregistrements RR AAAA existent est de supporter le scénario suivant:

  • Une application serveur IPv4 uniquement (par exemple, un logiciel de serveur web) s'exécute sur un hôte dual-stack. Il peut également y avoir des applications serveur dual-stack s'exécutant sur le même hôte. Cet hôte a des adresses IPv4 et IPv6 entièrement routables, et par conséquent le serveur DNS faisant autorité a un enregistrement A et un enregistrement AAAA.

  • Un client IPv6 uniquement (que l'application cliente soit IPv6 uniquement, que la pile du client soit IPv6 uniquement, ou qu'il n'ait qu'une adresse IPv6) veut accéder au serveur ci-dessus.

  • Le client émet une requête DNS à un résolveur DNS64.

Si DNS64 ne génère un AAAA synthétique que s'il n'y a pas de AAAA réel, alors la communication échouera. Même s'il y a un AAAA réel, le seul moyen pour que la communication réussisse est avec l'adresse traduite. Donc, afin de supporter ce scénario, l'administrateur d'un service DNS64 peut vouloir activer la synthèse d'enregistrements RR AAAA même lorsque de véritables enregistrements RR AAAA existent.

L'implication de l'inclusion d'enregistrements RR AAAA synthétiques lorsque de véritables enregistrements RR AAAA existent est que la connectivité traduite peut être préférée à la connectivité native dans certains cas où DNS64 est exploité en mode serveur DNS.

Les règles du RFC 3484 [RFC3484] utilisent "le préfixe correspondant le plus long" pour sélectionner l'adresse de destination préférée à utiliser. Donc, si le résolveur DNS64 retourne à la fois les enregistrements RR AAAA synthétiques et les véritables enregistrements RR AAAA, alors si DNS64 est exploité par le même domaine que l'hôte initiateur, et qu'un préfixe unicast global (appelé préfixe spécifique au réseau (NSP) dans [RFC6052]) est utilisé, alors un enregistrement RR AAAA synthétique est susceptible d'être préféré.

Cela signifie que sans configuration supplémentaire:

  • Dans le scénario "d'un réseau IPv6 vers Internet IPv4", l'hôte préférera la connectivité traduite si un NSP est utilisé. Si le préfixe bien connu défini dans [RFC6052] est utilisé, il préférera probablement la connectivité native.

  • Dans le scénario "Internet IPv6 vers un réseau IPv4", il est possible de biaiser la sélection vers le véritable enregistrement RR AAAA si le résolveur DNS64 retourne le AAAA réel en premier dans la réponse DNS, lorsqu'un NSP est utilisé (l'utilisation du préfixe bien connu n'est pas supportée dans ce cas).

  • Dans le scénario "d'un réseau IPv6 vers un réseau IPv4", pour les destinations locales (c'est-à-dire les hôtes cibles à l'intérieur du site local), il est probable que le NSP et le préfixe de destination soient les mêmes, donc nous pouvons utiliser l'ordre des enregistrements RR dans la réponse DNS pour biaiser la sélection vers la connectivité native. Si le préfixe bien connu est utilisé, la règle "préfixe correspondant le plus long" sélectionnera la connectivité native.

Le problème peut être résolu en configurant correctement la table de politique du RFC 3484 [RFC3484].