Aller au contenu principal

3. Background to DNS64-DNSSEC Interaction

DNSSEC ([RFC4033], [RFC4034], [RFC4035]) présente un défi particulier pour DNS64, car DNSSEC est conçu pour détecter les modifications apportées aux réponses DNS, et DNS64 peut modifier les réponses provenant d'un serveur faisant autorité.

Un résolveur récursif peut être conscient de la sécurité ou inconscient de la sécurité. De plus, un résolveur récursif conscient de la sécurité peut être validant ou non validant, selon la politique de l'opérateur. Dans les cas ci-dessous, le résolveur récursif effectue également DNS64, et a une politique locale pour valider. Nous appelons ce cas général vDNS64, mais dans tous les cas ci-dessous, la fonctionnalité DNS64 doit être supposée nécessaire.

DNSSEC inclut certains bits de signalisation qui offrent des indicateurs sur ce que l'initiateur de la requête comprend.

Si une requête arrive sur un dispositif vDNS64 avec le bit "DNSSEC OK" (DO) activé, l'initiateur de la requête signale qu'il comprend DNSSEC. Le bit DO n'indique pas que l'initiateur de la requête validera la réponse. Cela signifie seulement que l'initiateur de la requête peut comprendre les réponses contenant des données DNSSEC. Inversement, si le bit DO est désactivé, c'est une preuve que l'agent interrogeant n'est pas conscient de DNSSEC.

Si une requête arrive sur un dispositif vDNS64 avec le bit "Checking Disabled" (CD) activé, c'est une indication que l'agent interrogeant souhaite toutes les données de validation afin de pouvoir effectuer la vérification lui-même. Par politique locale, vDNS64 pourrait encore valider, mais il DOIT retourner toutes les données à l'agent interrogeant de toute façon.

Voici les cas possibles:

  1. Un DNS64 (conscient de DNSSEC ou inconscient de DNSSEC) reçoit une requête avec le bit DO désactivé. Dans ce cas, DNSSEC n'est pas une préoccupation, car l'agent interrogeant ne comprend pas les réponses DNSSEC. Le DNS64 peut effectuer la validation de la réponse, si cela est dicté par sa politique locale.

  2. Un DNS64 inconscient de la sécurité reçoit une requête avec le bit DO activé, et le bit CD désactivé ou activé. C'est comme le cas d'un DNS non-DNS64: le serveur ne le supporte pas, donc l'agent interrogeant n'a pas de chance.

  3. Un DNS64 conscient de la sécurité et non validant reçoit une requête avec le bit DO activé et le bit CD désactivé. Un tel résolveur ne valide pas les réponses, probablement en raison de la politique locale (voir [RFC4035], section 4.2). Pour cette raison, ce cas équivaut au cas précédent, et aucune validation ne se produit.

  4. Un DNS64 conscient de la sécurité et non validant reçoit une requête avec le bit DO activé et le bit CD activé. Dans ce cas, le DNS64 est censé transmettre toutes les données qu'il obtient à l'initiateur de la requête (voir section 3.2.2 de [RFC4035]). Ce cas ne fonctionnera pas avec DNS64, à moins que le résolveur validant ne soit prêt à effectuer DNS64 lui-même. Si le DNS64 modifie l'enregistrement, le client recevra les données et essaiera de les valider, et les données seront invalides du point de vue du client.

  5. Un résolveur DNS64 conscient de la sécurité et validant reçoit une requête avec le bit DO désactivé et le bit CD désactivé. Dans ce cas, le résolveur valide les données. S'il échoue, il retourne RCODE 2 (Server failure); sinon, il retourne la réponse. C'est le cas idéal pour vDNS64. Le résolveur valide les données, puis synthétise le nouvel enregistrement et le transmet au client. Le client, qui ne valide vraisemblablement pas (sinon il aurait dû activer DO et CD), ne peut pas dire que DNS64 est impliqué.

  6. Un résolveur DNS64 conscient de la sécurité et validant reçoit une requête avec le bit DO activé et le bit CD désactivé. Cela fonctionne comme le cas précédent, sauf que le résolveur DEVRAIT également activer le bit "Authentic Data" (AD) sur la réponse.

  7. Un résolveur DNS64 conscient de la sécurité et validant reçoit une requête avec le bit DO activé et le bit CD activé. Ceci est effectivement le même cas que celui où un résolveur récursif conscient de la sécurité et non validant reçoit une requête similaire, et la même chose se produira: le validateur en aval marquera les données comme invalides si DNS64 a effectué une synthèse. Le nœud doit effectuer DNS64 lui-même, sinon la communication échouera.

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

  • Alignement des paragraphes: 10 paragraphes originaux = 10 paragraphes traduits
  • Format des liens: Références RFC préservées
  • Terminologie bilingue: Termes techniques maintenus (DO, CD, AD, RCODE)
  • RFC 2119: DOIT/DEVRAIT correctement traduits
  • Sécurité MDX: Aucun caractère problématique
  • Préservation technique: Bits et codes 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-introduction, 2-overview, 3-background
  • Chapitre actuel: Préparation de 4-terminology
  • Progression globale: 35%
Dernière mise à jour le