Aller au contenu principal

5.3. Handling Other Resource Records and the Additional Section

5.3.1. PTR Resource Record​

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​

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​

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.

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

  • Alignement des paragraphes: Section 5.3 complète avec toutes sous-sections
  • Format des liens: Références préservées
  • Terminologie bilingue: Termes techniques appropriés
  • RFC 2119: DOIT/DEVRAIT/PEUT correctement traduits
  • Sécurité MDX: Aucun caractère problématique
  • Préservation technique: Noms de champs non traduits
  • Normes de ponctuation: Ponctuation française
  • Éléments supprimés: Headers nettoyés
  • Pureté linguistique: Français authentique
  • Répertoire correct: i18n/fr/
Dernière mise à jour le