5.1. Resolving AAAA Queries and the Answer Section

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

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

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

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

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

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

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

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

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.)

📊 Traduction de qualité - Auto-vérification

📍 Progression actuelle

RFC: 6147
Langue cible: 🇫🇷 Français
Chapitres complétés: index.md, 1-5.1
Chapitre actuel: Préparation 5.2-5.5
Progression globale: 60%

5.1.1. The Answer when There is AAAA Data Available​

5.1.2. The Answer when There is an Error​

5.1.3. Dealing with Timeouts​

5.1.4. Special Exclusion Set for AAAA Records​

5.1.5. Dealing with CNAME and DNAME​

5.1.6. Data for the Answer when Performing Synthesis​

5.1.7. Performing the Synthesis​

5.1.8. Querying in Parallel​

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

📍 Progression actuelle​