5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode

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.

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

---

📊 Traduction de qualité - Auto-vérification

• Alignement des paragraphes: Section 5.5 complète traduite
• Format des liens: Références RFC préservées
• Terminologie bilingue: Termes techniques appropriés
• RFC 2119: DEVRAIT/DOIT/PEUT correctement traduits
• Sécurité MDX: Bits DO/CD/AD préservés
• Préservation technique: Codes et bits 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/

📍 Progression actuelle

• RFC: 6147
• Langue cible: 🇫🇷 Français
• Chapitres complétés: index.md, 1-5 (complet)
• Chapitre actuel: Préparation de 6-deployment-notes
• Progression globale: 70%