Résumé

  • DoH protège le canal vers un résolveur sans décider quel résolveur convient au contexte de l’utilisateur.
  • La découverte peut conserver le service chiffré du réseau, tandis que la politique du client garde le dernier mot sur sa sélection.
  • Les espaces de noms privés, le filtrage, le repli et la juridiction des journaux suivent le choix du résolveur.
  • Une carte de politique doit réunir désignation, authentification, sélection, périmètre de noms et traitement des données.

Imaginons un scénario hypothétique. Deux ordinateurs administrés rejoignent le même réseau de bureau. Le système du premier découvre le service chiffré du résolveur désigné par le réseau, le valide et résout encore le nom d’un service interne. Sur le second, le navigateur préfère un service DoH public. La connexion TLS fonctionne, mais le nom privé disparaît et le contrôle DNS du réseau ne voit plus la requête. Les deux transports sont sains; leur autorité de résolution diffère.

La RFC 8484 place chaque couple requête-réponse DNS dans un échange HTTPS. La confidentialité et l’intégrité du canal sont ainsi renforcées. Le texte rappelle toutefois que le choix du serveur peut modifier la réponse lorsque le réseau applique une politique locale ou un DNS scindé. Il précise aussi que les dispositifs fondés sur l’observation du DNS non chiffré ne fonctionnent plus sur le trafic DoH. Le chiffrement résout donc l’exposition du canal, tout en obligeant à nommer l’acteur qui gouverne désormais la résolution.

La RFC 9462 encadre la découverte. DDR permet de passer d’un résolveur non chiffré déjà connu à un service chiffré du même opérateur, ou d’un acteur coopérant. La découverte vérifiée exige une chaîne de certificats valide et un subjectAltName de type adresse IP couvrant le résolveur désignateur. La découverte opportuniste autorise plutôt le service chiffré lorsqu’il partage l’adresse IP du service non chiffré; ce mode est recommandé uniquement pour une adresse privée ou locale. Elle chiffre le transport sans authentifier l’identité du résolveur par le nom du certificat.

Les deux méthodes offrent donc des niveaux d’assurance différents et laissent au client sa décision de sélection.

La RFC 9463 donne au réseau un moyen explicite de proposer des résolveurs chiffrés par DHCPv4, DHCPv6 ou annonce de routeur IPv6. L’offre comprend un nom de domaine d’authentification, des adresses, les protocoles disponibles et une priorité de service. Mais désigner ne signifie pas imposer. Le système ou l’application peut accepter, comparer ou refuser cette offre. La frontière de responsabilité traverse alors le réseau d’accès, la plateforme cliente, l’application et l’opérateur du résolveur.

La politique des données se déplace elle aussi. La RFC 8932 recommande de minimiser les données, de réduire la conservation opérationnelle, de limiter les accès internes et de rendre les pratiques transparentes. Changer de résolveur peut donc changer en même temps le lieu de traitement, la durée de conservation et les preuves disponibles lors d’un incident.

Une carte de politique du résolveur rend ce système exploitable. Pour chaque groupe de clients et contexte réseau, elle indique le responsable de la politique et l’instant de la décision, la source de désignation, la preuve d’identité, le composant qui sélectionne, l’espace de noms servi, les contrôles appliqués et le comportement de repli. Elle précise aussi qui gouverne les requêtes et les journaux, leur durée de conservation et la juridiction applicable. Elle teste les noms publics et privés et est renouvelée à chaque changement d’application, de système, de profil DHCP ou de service.

Sources