Aller au contenu principal

5. DNS64 Normative Specification (Spécification normative DNS64)

DNS64 est une fonction logique qui synthétise des enregistrements AAAA à partir d'enregistrements A. La fonction DNS64 peut être implémentée dans un résolveur stub, dans un résolveur récursif ou dans un serveur de noms faisant autorité. Elle fonctionne au sein de ces fonctions DNS et apparaît sur le réseau comme s'il s'agissait d'un résolveur DNS ou d'un serveur de noms "simple" conforme à [RFC1034] et [RFC1035].

L'implémentation DEVRAIT prendre en charge le mappage de plages d'adresses IPv4 séparées vers des préfixes IPv6 séparés pour la synthèse d'enregistrements AAAA. Cela permet de gérer les adresses IPv4 à usage spécial [RFC5735].

Les messages DNS contiennent plusieurs sections. La partie d'un message DNS qui est modifiée par DNS64 est la section de réponse, qui est discutée ci-dessous dans la section 5.1. La réponse synthétique résultante est assemblée avec d'autres sections, et cela crée le message qui est réellement retourné en tant que réponse à la requête DNS. L'assemblage de cette réponse est couvert ci-dessous dans la section 5.4.

DNS64 répond également aux requêtes PTR impliquant des adresses contenant l'un des préfixes IPv6 qu'il utilise pour la synthèse d'enregistrements RR AAAA.

5.1. Resolving AAAA Queries and the Answer Section (Résolution des requêtes AAAA et section de réponse)​

Lorsque DNS64 reçoit une requête pour des enregistrements RR de type AAAA et de classe IN, il tente d'abord de récupérer des enregistrements RR non synthétiques de ce type et de cette classe, soit en effectuant une requête, soit, dans le cas d'un serveur faisant autorité, en examinant ses propres résultats. La requête peut être répondue à partir d'un cache local, si celui-ci est disponible. Le fonctionnement de DNS64 pour les classes autres que IN n'est pas défini, et un DNS64 DOIT se comporter comme si aucune fonction DNS64 n'était configurée.

5.1.1. The Answer when There is AAAA Data Available (Réponse lorsqu'il y a des données AAAA disponibles)​

Si la requête résulte en un ou plusieurs enregistrements AAAA dans la section de réponse, le résultat est retourné au client demandeur conformément à la sémantique DNS normale, sauf dans le cas où l'un des enregistrements AAAA correspond à un ensemble d'exclusion spécial de préfixes, comme considéré dans la section 5.1.4. S'il y a des données AAAA (non exclues) disponibles, DNS64 NE DEVRAIT PAS inclure d'enregistrements RR AAAA synthétiques dans la réponse (voir l'annexe A pour une analyse des motivations et des implications du non-respect de cette recommandation). Par défaut, les implémentations DNS64 NE DOIVENT PAS synthétiser d'enregistrements RR AAAA lorsque de véritables enregistrements RR AAAA existent.

5.1.2. The Answer when There is an Error (Réponse lorsqu'il y a une erreur)​

Si la requête résulte en une réponse avec un RCODE autre que 0 (pas de condition d'erreur), alors il y a deux possibilités. Un résultat avec RCODE=3 (Name Error) est traité selon le fonctionnement DNS normal (qui consiste normalement à retourner l'erreur au client). Cette étape est toujours avant que toute synthèse n'ait eu lieu, donc une réponse à retourner au client n'a pas besoin d'un assemblage spécial autre que ce qui se produirait habituellement dans le fonctionnement DNS.

Tout autre RCODE est traité comme si le RCODE était 0 (voir sections 5.1.6 et 5.1.7) et la section de réponse était vide. Cela est dû au grand nombre de réponses différentes des serveurs de noms déployés lorsqu'ils reçoivent des requêtes AAAA sans qu'un enregistrement AAAA soit disponible (voir [RFC4074]). Notez que cela signifie, à des fins pratiques, que plusieurs classes différentes d'erreurs dans le DNS sont toutes traitées comme si un enregistrement AAAA n'était pas disponible pour ce nom de propriétaire.

Il est important de noter que, au moment de la rédaction, certains serveurs répondent avec RCODE=3 à une requête AAAA même s'il y a un enregistrement A disponible pour ce nom de propriétaire. Ces serveurs violent clairement la signification du RCODE 3, et il est prévu qu'ils diminueront en utilisation à mesure que le déploiement d'IPv6 augmentera.

5.1.3. Dealing with Timeouts (Gestion des délais d'expiration)​

Si la requête ne reçoit aucune réponse avant le délai d'expiration (qui peut être le délai d'expiration de chaque serveur faisant autorité, selon que DNS64 est en mode résolveur récursif), elle est traitée comme RCODE=2 (Server failure).

5.1.4. Special Exclusion Set for AAAA Records (Ensemble d'exclusion spécial pour les enregistrements AAAA)​

Certaines adresses IPv6 ne sont pas réellement utilisables par les hôtes IPv6 uniquement. Si elles sont retournées aux agents interrogeant IPv6 uniquement en tant qu'enregistrements AAAA, par conséquent, l'objectif de diminuer le nombre de modes de défaillance ne sera pas atteint. Les exemples incluent les enregistrements AAAA avec des adresses dans le réseau ::ffff:0:0/96, et éventuellement (selon le contexte) les enregistrements AAAA avec le Pref64::/n du site ou le préfixe bien connu (voir ci-dessous pour plus d'informations sur le préfixe bien connu). Une implémentation DNS64 DEVRAIT fournir un mécanisme pour spécifier les plages de préfixes IPv6 à traiter comme si le AAAA les contenant était une réponse vide. Une implémentation DEVRAIT inclure le réseau ::ffff/96 dans cette plage par défaut. L'absence de cette facilité signifiera que les clients interrogeant la fonction DNS64 peuvent ne pas être en mesure de communiquer avec des hôtes qui seraient accessibles depuis un hôte dual-stack.

Lorsque DNS64 effectue sa requête AAAA initiale, s'il reçoit une réponse avec seulement des enregistrements AAAA contenant des adresses dans la ou les plages exclues, alors il DOIT traiter la réponse comme si elle était une réponse vide, et procéder en conséquence. S'il reçoit une réponse avec au moins un enregistrement AAAA contenant une adresse en dehors de toutes les plages exclues, alors il DEVRAIT par défaut construire une section de réponse pour une réponse incluant uniquement le ou les enregistrements AAAA qui ne contiennent aucune des adresses à l'intérieur des plages exclues. Cette section de réponse est utilisée dans l'assemblage d'une réponse telle que détaillée dans la section 5.4. Alternativement, il PEUT traiter la réponse comme si elle était une réponse vide, et procéder en conséquence. Il NE DOIT PAS retourner les enregistrements AAAA offensants dans le cadre d'une réponse.

5.1.5. Dealing with CNAME and DNAME (Gestion des CNAME et DNAME)​

Si la réponse contient un CNAME ou un DNAME, alors la chaîne CNAME ou DNAME est suivie jusqu'à ce que le premier enregistrement A ou AAAA terminal soit atteint. Cela peut nécessiter que DNS64 demande un enregistrement A, au cas où la réponse à la requête AAAA originale est un CNAME ou DNAME sans enregistrement AAAA à suivre. L'enregistrement AAAA ou A résultant est traité comme n'importe quel autre cas AAAA ou A, selon le cas.

Lors de l'assemblage de la section de réponse, toutes les chaînes d'enregistrements RR CNAME ou DNAME sont incluses dans le cadre de la réponse avec le AAAA synthétique (le cas échéant).

5.1.6. Data for the Answer when Performing Synthesis (Données pour la réponse lors de la synthèse)​

Si la requête résulte en aucune erreur mais une section de réponse vide dans la réponse, DNS64 tente de récupérer des enregistrements A pour le nom en question, soit en effectuant une autre requête, soit, dans le cas d'un serveur faisant autorité, en examinant ses propres résultats. Si cette nouvelle requête d'enregistrement RR A résulte en une réponse vide ou en une erreur, alors la réponse vide ou l'erreur est utilisée comme base pour la réponse retournée au client interrogeant. Si au contraire la requête résulte en un ou plusieurs enregistrements RR A, DNS64 synthétise des enregistrements RR AAAA basés sur les enregistrements RR A selon la procédure décrite dans la section 5.1.7. DNS64 retourne les enregistrements AAAA synthétisés dans la section de réponse, en supprimant les enregistrements A qui forment la base de la synthèse.

5.1.7. Performing the Synthesis (Réalisation de la synthèse)​

Un enregistrement AAAA synthétique est créé à partir d'un enregistrement A comme suit:

  • Le champ NAME est défini sur le champ NAME de l'enregistrement A.

  • Le champ TYPE est défini sur 28 (AAAA).

  • Le champ CLASS est défini sur le champ CLASS original, 1. Selon cette spécification, DNS64 pour toute CLASS autre que 1 n'est pas défini.

  • Le champ Time to Live (TTL) est défini sur le minimum du TTL de l'enregistrement RR A original et de l'enregistrement RR SOA pour le domaine interrogé. (Notez que pour obtenir le TTL de l'enregistrement RR SOA, DNS64 n'a pas besoin d'effectuer une nouvelle requête, mais il peut se souvenir du TTL de l'enregistrement RR SOA dans la réponse négative à la requête AAAA. Si l'enregistrement RR SOA n'a pas été livré avec la réponse négative à la requête AAAA, alors DNS64 DEVRAIT utiliser le TTL de l'enregistrement RR A original ou 600 secondes, selon la valeur la plus courte. Il est possible à la place de requêter explicitement l'enregistrement RR SOA et d'utiliser le résultat de cette requête, mais cela augmentera la charge de requête et le temps de résolution pour peu de bénéfice supplémentaire.) Ceci est conforme à l'approche utilisée dans la mise en cache négative [RFC2308].

  • Le champ RDLENGTH est défini sur 16.

  • Le champ RDATA est défini sur la représentation IPv6 de l'adresse IPv4 du champ RDATA de l'enregistrement A. DNS64 DOIT vérifier chaque enregistrement RR A par rapport aux plages d'adresses IPv4 configurées et sélectionner le préfixe IPv6 correspondant à utiliser pour synthétiser l'enregistrement RR AAAA. Voir la section 5.2 pour la discussion des algorithmes à utiliser pour effectuer la transformation.

5.1.8. Querying in Parallel (Interrogation en parallèle)​

DNS64 PEUT effectuer la requête pour l'enregistrement RR AAAA et pour l'enregistrement RR A en parallèle, afin de minimiser le délai.

NOTE: Interroger en parallèle entraînera l'exécution de requêtes d'enregistrements RR A inutiles dans le cas où aucune synthèse d'enregistrements RR AAAA n'est requise. Un compromis possible serait de les effectuer séquentiellement mais avec un intervalle très court entre eux, donc si nous obtenons une réponse rapide, nous évitons de faire la requête supplémentaire. (Notez que cette discussion n'est pertinente que si la fonction DNS64 doit effectuer des requêtes externes pour récupérer l'enregistrement RR. Si les informations d'enregistrement RR nécessaires sont disponibles localement, comme dans le cas d'un serveur faisant autorité, le problème n'est plus pertinent.)

5.2. Generation of the IPv6 Representations of IPv4 Addresses (Génération des représentations IPv6 des adresses IPv4)​

DNS64 prend en charge plusieurs algorithmes pour la génération de la représentation IPv6 d'une adresse IPv4. Les contraintes imposées sur les algorithmes de génération sont les suivantes:

  • Le même algorithme pour créer une adresse IPv6 à partir d'une adresse IPv4 DOIT être utilisé à la fois par un DNS64 pour créer l'adresse IPv6 à retourner dans l'enregistrement RR AAAA synthétique à partir de l'adresse IPv4 contenue dans un enregistrement RR A original, et par un traducteur IPv6/IPv4 pour créer l'adresse IPv6 à inclure dans le champ d'adresse source des paquets IPv6 sortants à partir de l'adresse IPv4 incluse dans le champ d'adresse source du paquet IPv4 entrant.

  • L'algorithme DOIT être réversible; c'est-à-dire qu'il DOIT être possible de dériver l'adresse IPv4 originale à partir de la représentation IPv6.

  • L'entrée pour l'algorithme DOIT être limitée à l'adresse IPv4; le préfixe IPv6 (noté Pref64::/n) utilisé dans les représentations IPv6; et, éventuellement, un ensemble de paramètres stables qui sont configurés dans DNS64 et dans NAT64 (comme une chaîne fixe à utiliser comme suffixe).

    • Pour chaque préfixe Pref64::/n, n DOIT être inférieur ou égal à 96. Si un ou plusieurs Pref64::/n sont configurés dans DNS64 par n'importe quel moyen (tel que la configuration manuelle, ou d'autres moyens automatiques non spécifiés dans ce document), l'algorithme par défaut DOIT utiliser ces préfixes (et ne pas utiliser le préfixe bien connu). Si aucun préfixe n'est disponible, l'algorithme DOIT utiliser le préfixe bien connu 64:ff9b::/96 défini dans [RFC6052] pour représenter la plage d'adresses unicast IPv4.

Un DNS64 DOIT prendre en charge l'algorithme de génération de représentations IPv6 d'adresses IPv4 défini dans la section 2 de [RFC6052]. De plus, l'algorithme susmentionné DOIT être l'algorithme par défaut utilisé par DNS64. Bien que la description normative de l'algorithme soit fournie dans [RFC6052], une description d'exemple de l'algorithme et son application à différents scénarios sont fournies dans la section 7 à des fins d'illustration.

5.3. Handling Other Resource Records and the Additional Section (Traitement des autres enregistrements de ressources et de la section supplémentaire)​

5.3.1. PTR Resource Record (Enregistrement de ressource PTR)​

Si un serveur DNS64 reçoit une requête PTR pour un enregistrement dans le domaine IP6.ARPA, il DOIT retirer les étiquettes IP6.ARPA du QNAME, inverser la partie adresse du QNAME selon le schéma d'encodage décrit dans la section 2.5 de [RFC3596], et examiner l'adresse résultante pour voir si son préfixe correspond à l'un des Pref64::/n configurés localement ou au préfixe bien connu par défaut. Il existe deux alternatives pour qu'un serveur DNS64 réponde à de telles requêtes PTR. Un serveur DNS64 DOIT fournir l'une de ces alternatives, et NE DEVRAIT PAS fournir les deux en même temps à moins que différentes zones IP6.ARPA ne nécessitent des réponses de types différents:

  1. La première option consiste pour le serveur DNS64 à répondre de manière autoritaire pour ses préfixes. Si le préfixe d'adresse correspond à tout Pref64::/n utilisé dans le site, soit un NSP soit le préfixe bien connu (c'est-à-dire 64:ff9b::/96), alors le serveur DNS64 PEUT répondre à la requête en utilisant des RDATA localement appropriées. Le serveur DNS64 PEUT utiliser les mêmes RDATA pour toutes les réponses. Notez que l'exigence est de correspondre à tout Pref64::/n utilisé sur le site, et pas seulement au Pref64::/n configuré localement. Cela est dû au fait que les clients terminaux pourraient demander un enregistrement PTR correspondant à une adresse reçue via un DNS64 différent (fourni par le site), et si cette stratégie est en vigueur, ces requêtes ne devraient jamais être envoyées au DNS global. L'avantage de cette stratégie est qu'elle rend clair au client interrogeant que le préfixe est exploité par le site (DNS64), et que les réponses que le client obtient sont générées par DNS64. L'inconvénient est que toute information d'arbre inverse utile qui pourrait être dans le DNS global n'est pas disponible pour les clients interrogeant DNS64.

  2. La deuxième option consiste pour le serveur de noms DNS64 à synthétiser un CNAME mappant l'espace de noms IP6.ARPA au nom IN-ADDR.ARPA correspondant. Dans ce cas, le serveur de noms DNS64 DEVRAIT s'assurer qu'il y a des RDATA au PTR du nom IN-ADDR.ARPA correspondant, et qu'il n'y a pas de CNAME existant à ce nom. Ceci afin d'éviter de synthétiser un CNAME qui allonge une chaîne CNAME ou qui ne pointe réellement vers rien. Le reste de la réponse serait le traitement DNS normal. Le CNAME peut être signé à la volée si nécessaire. L'avantage de cette approche est que toute information utile dans l'arbre inverse est disponible pour le client interrogeant. Les inconvénients sont qu'elle ajoute une charge supplémentaire à DNS64 (car les CNAME doivent être synthétisés pour chaque requête PTR qui correspond au Pref64::/n), et qu'elle peut nécessiter une signature à la volée.

Si le préfixe d'adresse ne correspond à aucun Pref64::/n, alors le serveur DNS64 DOIT traiter la requête comme toute autre requête; c'est-à-dire qu'un serveur de noms récursif DOIT tenter de résoudre la requête comme toute autre requête (non-A/AAAA), et un serveur faisant autorité DOIT répondre de manière autoritaire ou avec une référence, selon le cas.

5.3.2. Handling the Additional Section (Traitement de la section supplémentaire)​

La synthèse DNS64 NE DOIT PAS être effectuée sur les enregistrements de la section supplémentaire des réponses synthétisées. DNS64 DOIT passer la section supplémentaire inchangée.

NOTE: Il peut sembler souhaitable d'ajouter des enregistrements synthétiques à la section supplémentaire, car les clients utilisent parfois les données de la section supplémentaire pour procéder sans avoir à interroger à nouveau. Il n'y a en général aucune promesse, cependant, que la section supplémentaire contiendra tous les enregistrements pertinents, donc tout client qui dépend de la capacité de la section supplémentaire à satisfaire ses besoins (c'est-à-dire sans requêtes supplémentaires) est nécessairement défaillant. Un client IPv6 uniquement qui a besoin d'un enregistrement AAAA, par conséquent, enverra une requête pour l'enregistrement AAAA nécessaire s'il ne peut pas trouver un tel enregistrement dans la section supplémentaire d'une réponse qu'il consomme. Pour un client fonctionnant correctement, l'effet ne serait pas différent si la section supplémentaire était vide. L'alternative consistant à supprimer les enregistrements A de la section supplémentaire et à les remplacer par des enregistrements AAAA synthétiques peut amener un hôte derrière un NAT64 à interroger directement un serveur de noms qui n'est pas conscient du NAT64 en question. Le résultat dans ce cas sera de toute façon un échec de résolution, mais plus tard dans l'opération de résolution. L'interdiction de données synthétiques dans la section supplémentaire réduit, mais n'élimine pas, la possibilité d'échecs de résolution dus aux données DNS mises en cache depuis derrière DNS64. Voir la section 6.

5.3.3. Other Resource Records (Autres enregistrements de ressources)​

Si DNS64 est en mode résolveur récursif, alors les considérations décrites dans [DEFAULT-LOCAL-ZONES] peuvent être pertinentes.

Tous les autres enregistrements RR DOIVENT être retournés inchangés. Cela inclut les réponses aux requêtes pour les enregistrements RR A.

5.4. Assembling a Synthesized Response to a AAAA Query (Assemblage d'une réponse synthétisée à une requête AAAA)​

Un DNS64 utilise différentes pièces de données pour construire la réponse retournée au client interrogeant.

La requête qui est utilisée comme base pour la synthèse résulte soit en une erreur, une réponse qui peut être utilisée comme base pour la synthèse, ou une réponse (autoritaire) vide. S'il y a une réponse vide, alors DNS64 répond au client interrogeant original avec la réponse que DNS64 a reçue à la requête originale (de l'initiateur). Sinon, la réponse est assemblée comme suit.

Les champs d'en-tête sont définis selon les règles habituelles pour les serveurs récursifs ou faisant autorité, selon le rôle que DNS64 joue. La section de question est copiée de la requête originale (de l'initiateur). La section de réponse est peuplée selon les règles de la section 5.1.7. Les sections d'autorité et supplémentaires sont copiées de la réponse à la dernière requête que DNS64 a effectuée, et utilisées comme base pour la synthèse.

La réponse finale de DNS64 est soumise à toutes les règles DNS standard, y compris la troncature [RFC1035] et le traitement EDNS0 [RFC2671].

5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode (Traitement DNSSEC: DNS64 en mode résolveur validant)​

Nous considérons le cas où un résolveur récursif qui effectue DNS64 a également une politique locale pour valider les réponses selon les procédures décrites dans [RFC4035], section 5. Nous appelons ce cas général vDNS64.

Le vDNS64 utilise la présence des bits DO et CD pour prendre certaines décisions sur ce que l'initiateur de la requête a besoin, et peut réagir en conséquence:

  1. Si CD n'est pas activé et DO n'est pas activé, vDNS64 DEVRAIT effectuer la validation et faire la synthèse au besoin. Voir l'élément suivant pour les règles sur la façon d'effectuer la validation et la synthèse. Dans ce cas, cependant, vDNS64 NE DOIT PAS activer le bit AD dans aucune réponse.

  2. Si CD n'est pas activé et DO est activé, alors vDNS64 DEVRAIT effectuer la validation. Chaque fois que vDNS64 effectue la validation, il DOIT valider la réponse négative pour les requêtes AAAA avant de procéder à la requête des enregistrements A pour le même nom, afin de s'assurer qu'il n'y a pas d'enregistrement AAAA légitime sur Internet. Ne pas observer cette étape permettrait à un attaquant d'utiliser DNS64 comme mécanisme pour contourner DNSSEC. Si la réponse négative valide, et que la réponse à la requête A valide, alors vDNS64 PEUT effectuer la synthèse et DEVRAIT activer le bit AD dans la réponse au client. Ceci est acceptable, car [RFC4035], section 3.2.3 dit que le bit AD est activé par le côté serveur de noms d'un serveur de noms récursif conscient de la sécurité si et seulement s'il considère tous les RRSet dans les sections de réponse et d'autorité comme authentiques. Dans ce cas, le serveur de noms a des raisons de croire que les RRSet sont tous authentiques, donc il DEVRAIT activer le bit AD. Si les données ne valident pas, vDNS64 DOIT répondre avec RCODE=2 (Server failure).

Un point terminal conscient de la sécurité pourrait prendre la présence du bit AD comme une indication que les données sont valides, et peut transmettre les données DNS (et DNSSEC) à une application. Si l'application tente de valider les données synthétisées, bien sûr, la validation échouera. On pourrait donc argumenter que cette approche n'est pas souhaitable, mais les résolveurs stub conscients de la sécurité ne doivent placer aucune confiance dans les données reçues des résolveurs et validées en leur nom sans certains critères établis par [RFC4035], section 4.9.3. Une application qui veut effectuer la validation par elle-même devrait utiliser le bit CD.

  1. Si le bit CD est activé et DO est activé, alors vDNS64 PEUT effectuer la validation, mais NE DOIT PAS effectuer la synthèse. Il DOIT retourner les données à l'initiateur de la requête, tout comme un résolveur récursif régulier, et dépendre du client pour effectuer la validation et la synthèse lui-même.

L'inconvénient de cette approche est qu'un point terminal inconscient de la traduction mais conscient de la sécurité et validant ne pourra pas utiliser la fonctionnalité DNS64. Dans ce cas, le point terminal n'aura pas le bénéfice souhaité de NAT64. En effet, cette stratégie signifie que tout point terminal qui souhaite effectuer la validation dans un contexte NAT64 doit être mis à niveau pour être également conscient de la traduction.