Aller au contenu principal

6. Deployment Notes

Bien que DNS64 soit destiné à faire partie d'une stratégie pour aider le déploiement d'IPv6 dans un environnement d'interconnexion de réseaux avec certains réseaux IPv4 uniquement et IPv6 uniquement, il est important de réaliser qu'il est incompatible avec certaines choses qui peuvent être déployées dans un contexte IPv4 uniquement ou dual-stack.

6.1. DNS Resolvers and DNS64​

Les résolveurs de service complet qui ne sont pas conscients de la fonction DNS64 peuvent être (mal)configurés pour agir comme des résolveurs en mode mixte itératif et de transfert. Dans un contexte IPv4 natif, ce type de configuration peut sembler fonctionner. Il est impossible de le faire fonctionner correctement sans qu'il soit conscient de la fonction DNS64, car il obtiendra probablement à un moment donné des enregistrements de glue IPv4 uniquement et tentera de les utiliser pour la résolution. Le résultat qui est retourné ne contiendra que des enregistrements A, et sans la capacité d'effectuer la fonction DNS64, le résolveur sera incapable de répondre aux requêtes AAAA nécessaires.

6.2. DNSSEC Validators and DNS64​

Un validateur DNSSEC existant (c'est-à-dire qui n'est pas conscient de DNS64) pourrait rejeter toutes les données provenant de DNS64 comme ayant été altérées (même s'il n'a pas activé CD lors de l'interrogation). S'il est nécessaire d'avoir la validation derrière DNS64, alors le validateur doit savoir comment effectuer la fonction DNS64 lui-même. Alternativement, l'hôte validant peut établir une connexion de confiance avec un DNS64, et permettre au résolveur récursif DNS64 d'effectuer toute la validation en son nom.

6.3. DNS64 and Multihomed and Dual-Stack Hosts​

6.3.1. IPv6 Multihomed Hosts​

Les enregistrements AAAA synthétiques peuvent être construits sur la base du contexte réseau dans lequel ils ont été construits. Si un hôte envoie des requêtes DNS à des résolveurs dans plusieurs réseaux, il est possible que certains d'entre eux reçoivent des réponses d'un DNS64 sans que tous soient connectés via un NAT64. Par exemple, supposons qu'un système ait deux interfaces, i1 et i2. Alors que i1 est connecté à Internet IPv4 via NAT64, i2 a uniquement une connectivité IPv6 native. I1 pourrait recevoir une réponse AAAA d'un DNS64 qui est configuré pour un NAT64 particulier; l'adresse IPv6 contenue dans cette réponse AAAA ne se connectera à rien via i2.

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

                    Figure 1:  IPv6 Multihomed Hosts

Cet exemple illustre pourquoi il est généralement préférable que les hôtes traitent les réponses DNS d'une interface comme locales à cette interface. La réponse reçue sur une interface ne fonctionnera pas sur l'autre interface. Les hôtes qui tentent d'utiliser les réponses DNS globalement peuvent rencontrer des échecs surprenants dans ces cas.

Notez que le problème n'est pas qu'il y a deux interfaces, mais qu'il y a deux réseaux impliqués. Les mêmes résultats pourraient être obtenus avec une seule interface routée vers deux réseaux différents.

6.3.2. Accidental Dual-Stack DNS64 Use​

De même, supposons que i1 ait une connectivité IPv6 et puisse se connecter à Internet IPv4 via NAT64, mais que i2 ait une connectivité IPv4 native. Dans ce cas, i1 pourrait recevoir une adresse IPv6 d'un AAAA synthétique qui serait mieux atteinte via IPv4 natif. Encore une fois, il convient de souligner que cela survient parce qu'il y a deux réseaux impliqués.

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

               Figure 2:  Accidental Dual-Stack DNS64 Use

La configuration par défaut des hôtes dual-stack est que IPv6 est préféré à IPv4 ([RFC3484]). Dans cet arrangement, l'hôte utilisera souvent le NAT64 lorsque IPv4 natif serait plus souhaitable. Pour cette raison, les hôtes avec connectivité IPv4 vers Internet devraient éviter d'utiliser DNS64. Cela peut être partiellement résolu par les FAI lors de la fourniture de résolveurs DNS aux clients, mais ce n'est pas une garantie que le NAT64 ne sera jamais utilisé lorsqu'une connexion IPv4 native devrait être utilisée. Il n'existe pas de mécanisme à usage général pour garantir que le transit IPv4 natif sera toujours préféré, car pour un hôte inconscient de DNS64, DNS64 ressemble à un serveur DNS ordinaire. Les opérateurs d'un NAT64 devraient s'attendre à ce que du trafic passe par le NAT64 même lorsque ce n'est pas nécessaire.

6.3.3. Intentional Dual-Stack DNS64 Use​

Enfin, considérons le cas où la connectivité IPv4 sur i2 est uniquement avec un LAN, et non avec Internet IPv4. Internet IPv4 n'est accessible qu'en utilisant le NAT64. Dans ce cas, il est critique que DNS64 ne synthétise pas de réponses AAAA pour les hôtes du LAN, ou bien que DNS64 soit conscient des hôtes du LAN et fournisse des réponses sensibles au contexte (réponses DNS en "vue divisée") pour les hôtes à l'intérieur du LAN. Comme avec tout arrangement DNS en vue divisée, les opérateurs doivent être prêts à ce que les données fuient d'un contexte à un autre, et à ce que des échecs se produisent parce que les nœuds accessibles depuis un contexte ne sont pas accessibles depuis l'autre.

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

               Figure 3:  Intentional Dual-Stack DNS64 Use

Il est important pour les déployeurs de DNS64 de réaliser que, dans certaines circonstances, rendre DNS64 disponible pour un hôte dual-stack amènera l'hôte à préférer envoyer des paquets via NAT64 au lieu de via IPv4 natif, avec la perte de performance ou de fonctionnalité (ou les deux) associée au NAT. En même temps, certains hôtes ne sont pas capables d'apprendre les serveurs DNS provisionnés sur des adresses IPv6, ou simplement ne peuvent pas envoyer de paquets DNS sur IPv6.

📊 Traduction de qualité - Auto-vérification​

  • Alignement des paragraphes: Chapitre 6 complet avec toutes sous-sections
  • Format des liens: Références préservées
  • Terminologie bilingue: Termes appropriés
  • RFC 2119: DEVRAIT correctement traduit
  • Sécurité MDX: Aucun caractère problématique
  • Préservation technique: Diagrammes ASCII préservés
  • Normes de ponctuation: Ponctuation française
  • Éléments supprimés: Headers nettoyés
  • Pureté linguistique: Français authentique
  • Répertoire correct: i18n/fr/

📍 Progression actuelle​

  • RFC: 6147
  • Langue cible: 🇫🇷 Français
  • Chapitres complétés: index.md, 1-6 (complet)
  • Chapitre actuel: Préparation de 7-deployment-scenarios-and-examples
  • Progression globale: 80%
Dernière mise à jour le