DoH et DoT : chiffrer le DNS sans perdre la main dessus

Une confusion revient dans presque tous les audits qu'on mène : « on a signé nos zones en DNSSEC, donc notre DNS est chiffré ». Non. DNSSEC signe, il ne chiffre rien. La chaîne de confiance DNSSEC garantit qu'une réponse n'a pas été falsifiée en route, mais elle circule en clair sur le réseau, lisible par le premier équipement traversé. Le résolveur de l'opérateur, le proxy du réseau invité, la borne Wi-Fi de l'hôtel : tout le monde voit passer la liste des domaines interrogés.

Intégrité et confidentialité sont deux problèmes distincts. DoT et DoH traitent le second. Et ils créent, au passage, un problème d'exploitation que peu d'équipes anticipent avant de le subir.

DNS over TLS, spécifié par la RFC 7858 en mai 2016, encapsule les messages DNS dans une session TLS sur le port TCP 853. DNS over HTTPS, spécifié par la RFC 8484 en octobre 2018, transporte le même message DNS binaire dans une requête HTTP, avec le type de média application/dns-message, sur le port 443.

Dans les deux cas, le périmètre de protection est le même, et il est plus étroit qu'on ne le croit : le segment entre le client et le résolveur récursif. La RFC 7858 le dit explicitement, l'application au trafic récursif vers serveur faisant autorité reste hors périmètre. En clair, le chiffrement s'arrête au résolveur. Derrière lui, quand il va interroger les serveurs racine puis le TLD puis la zone, ça repart en UDP 53 en clair.

Ce que ça protège concrètement :

Le résolveur de l'opérateur qui journalise l'intégralité des requêtes de ses abonnés ne voit plus rien si le client parle à un autre résolveur en TLS. Sur un réseau public, un attaquant en position d'écoute ne peut plus reconstituer la navigation à partir des requêtes DNS, ni injecter une réponse forgée avant celle du vrai résolveur. Cette dernière attaque, la course à la réponse UDP, est triviale sur un Wi-Fi ouvert et elle passe sous le radar de DNSSEC dès que le client ne valide pas lui-même.

Ce que ça ne protège pas, et c'est là que les discours marketing dérapent : la RFC 7858 reconnaît que le chiffrement n'empêche ni l'analyse de trafic, ni les fuites par timing et taille de message. Le SNI en clair du TLS applicatif qui suit, et surtout l'adresse IP de destination, trahissent de toute façon le domaine visité dans la majorité des cas. Chiffrer le DNS améliore la confidentialité, ça ne la garantit pas.

La différence tient en une phrase : DoT est identifiable, DoH ne l'est pas.

DoT vit sur son propre port. La RFC 7858 impose de ne jamais faire transiter du DNS en clair sur 853, précisément pour éviter les attaques de repli. Conséquence directe côté ops : un pare-feu voit le port 853, sait que c'est du DNS chiffré, peut l'autoriser vers un résolveur donné et le bloquer partout ailleurs. C'est administrable.

DoH se noie dans le port 443. Une requête DoH ressemble à du trafic HTTPS ordinaire, parce que c'en est. Impossible de la distinguer d'un appel d'API sans inspection profonde. Ce n'était pas un accident de conception, c'était l'objectif : rendre le blocage du DNS chiffré aussi coûteux que le blocage du web.

Selon le camp où l'on se place, c'est une fonctionnalité ou un défaut. Pour un journaliste dans un pays qui censure par le DNS, c'est une fonctionnalité vitale. Pour un RSSI qui a construit sa politique de filtrage sur le résolveur d'entreprise, c'est une brèche ouverte par défaut dans un navigateur qu'il n'a pas configuré.

Ces deux vérités coexistent. Le débat public sur DoH a été pourri par des gens qui refusaient d'en admettre une des deux.

Le chiffrement du transport DNS n'a jamais posé de problème d'exploitation. Ce qui en pose un, c'est un navigateur qui décide unilatéralement d'ignorer le résolveur du système et d'envoyer ses requêtes chez un résolveur public tiers, en HTTPS, sans rien demander à personne.

Tout ce qui repose sur le résolveur tombe d'un coup : le filtrage de domaines malveillants, la résolution des noms internes, le split-horizon, la journalisation utile aux investigations, et la détection de tunneling DNS ou de contact avec une infrastructure de commande. Une machine compromise dont le navigateur parle DoH à un résolveur externe ne laisse plus aucune trace exploitable dans les logs du résolveur d'entreprise.

Mozilla a introduit un mécanisme de sortie, le domaine canari use-application-dns.net. Firefox le résout via le résolveur système et, s'il reçoit NXDOMAIN, SERVFAIL, ou un NOERROR sans enregistrement A ni AAAA, il désactive DoH. Le piège classique est de considérer ça comme une protection : le canari ne s'applique qu'aux utilisateurs pour qui DoH est actif par défaut. Un utilisateur qui a coché la case lui-même voit sa préférence respectée, et le signal réseau ignoré. Sur un poste maîtrisé, le seul mécanisme fiable est la politique d'entreprise, ADMX sous Windows ou équivalent, avec DoH désactivé et le réglage verrouillé.

La conclusion opérationnelle est désagréable mais claire : un contrôle qui dépend du bon vouloir de l'application cliente n'est pas un contrôle. Le canari est un signal de courtoisie, pas une mesure de sécurité.

La bonne réponse n'est pas de bloquer le DNS chiffré. C'est d'en devenir le fournisseur. Un poste qui obtient de la confidentialité vers un résolveur interne n'a aucune raison d'aller la chercher chez un tiers.

Côté Unbound, l'activation est directe. Le service écoute en DoT sur 853 et présente un certificat :

server:
    interface: 0.0.0.0@853
    tls-service-key: "/etc/unbound/tls/privkey.pem"
    tls-service-pem: "/etc/unbound/tls/fullchain.pem"
    tls-port: 853
    access-control: 10.0.0.0/8 allow

Pour DoH, le port par défaut est 443, ajustable via https-port. Deux contraintes à connaître avant de planifier : l'implémentation DoH d'Unbound exige TLS, et elle ne fonctionne qu'en HTTP/2. Un binaire compilé sans nghttp2 n'aura tout simplement pas le support, ce qui explique la plupart des configurations qui « ne prennent pas » sur des paquets de distribution. Le reste des réglages de résolveur validant, cache et forward, ne change pas par rapport à un Unbound classique.

Côté dnsdist, la logique est celle d'un frontal : il termine les sessions chiffrées et distribue vers un pool de résolveurs en clair, à l'intérieur du périmètre de confiance.

addTLSLocal('[::]:853', '/etc/dnsdist/ssl/fullchain.pem',
            '/etc/dnsdist/ssl/privkey.pem', { minTLSVersion='tls1.2' })
addDOHLocal('[::]:443', '/etc/dnsdist/ssl/fullchain.pem',
            '/etc/dnsdist/ssl/privkey.pem', { '/dns-query' })

C'est l'architecture qu'on privilégie quand le volume monte, pour les mêmes raisons qui font choisir dnsdist devant PowerDNS : la terminaison TLS, la répartition de charge et les règles de filtrage sont au même endroit, découplées du résolveur lui-même. Un thread dédié par directive addTLSLocal gère l'acceptation des connexions, ce qui isole proprement le coût du chiffrement.

Trois points à traiter sérieusement, sinon le déploiement se retourne contre vous :

Le certificat. Un résolveur DoT interne présente un certificat que les clients doivent valider. Certificat public sur un nom résolvable, ou PKI interne déployée sur le parc. Pas de certificat auto-signé bricolé sans distribution du CA : les stubs modernes refusent, et le repli silencieux vers du DNS en clair est exactement ce qu'on cherchait à éviter. Les règles de configuration TLS s'appliquent ici comme ailleurs, TLS 1.2 en plancher absolu.

La réutilisation de connexion. La RFC 7858 insiste sur ce point, et il est structurant : une poignée de main TLS complète pour chaque requête DNS est un désastre de latence. Connexions persistantes, pipelining des requêtes et reprise de session TLS ne sont pas des optimisations optionnelles, ce sont les prérequis pour que le surcoût reste négligeable. Un déploiement DoT qui rouvre une session par requête donnera des chiffres catastrophiques, et l'équipe conclura à tort que le chiffrement coûte cher.

La panne. Un résolveur DoT indisponible ne dégrade pas, il coupe. Deux instances minimum, sur deux chemins réseau distincts, avec supervision de la validité du certificat au même titre que celle du service. Un certificat expiré sur un résolveur, c'est l'intégralité de la résolution du site à terre, et un diagnostic qui part dans le décor si personne n'a pensé à surveiller cette date. Les réflexes de dépannage DNS restent valables, avec une couche TLS de plus à écarter avant de conclure.

Il faut poser les choses franchement. Sur le poste nomade d'un commercial, sur un réseau invité, sur du Wi-Fi public, la confidentialité gagne : le résolveur chiffré interne, ou à défaut un résolveur public de confiance, vaut mieux que le résolveur du réseau visité. Sur le réseau interne d'un SI d'entreprise, l'observabilité gagne : le résolveur voit les requêtes, le filtrage fonctionne, et la journalisation nourrit les investigations. Vouloir les deux au maximum sur le même segment, c'est se raconter une histoire.

Le compromis qui tient en exploitation : chiffré du poste jusqu'au résolveur interne, en clair et journalisé à l'intérieur du périmètre maîtrisé, et rien de tout ça ne dispense de valider DNSSEC en sortie. Le chiffrement du transport et la validation des signatures répondent à deux menaces différentes, on déploie les deux ou on accepte de rester exposé à l'une des deux.

Cette architecture rejoint d'ailleurs le principe de séparation que l'ANSSI défend dans ses recommandations sur les services DNS : isoler la résolution interne de la résolution Internet, et séparer les rôles de résolveur et de serveur faisant autorité. DoT et DoH s'insèrent dans ce découpage, ils ne le remplacent pas.

Fournir le DNS chiffré plutôt que le combattre. Un résolveur interne en DoT sur 853, publié aux postes par configuration, DoH sur 443 si des applications l'exigent, et politique d'entreprise verrouillant le DoH navigateur vers un résolveur externe. Le filtrage et les logs restent en place parce que le trafic revient chez vous, et l'utilisateur gagne réellement la confidentialité qu'il serait allé chercher ailleurs.

Et avant de basculer le parc : coupez le résolveur DoT en préproduction et regardez ce que font les clients. Repli en clair, échec franc, ou boucle de retentative qui sature le lien ? Test grandeur nature, ou rien. Une architecture DNS chiffrée dont le scénario de panne n'a jamais été joué n'est pas une architecture, c'est un pari.

Un service de résolution est un composant de production au même titre qu'une base de données : redondance réelle, supervision du certificat autant que du processus, et procédure de bascule écrite. C'est ce qu'on met en place sur les infrastructures qu'on opère, avec un résolveur validant redondé de part et d'autre du backbone AS41652 plutôt qu'une instance unique dans un coin de VM. Si votre résolution DNS repose aujourd'hui sur une machine sans doublure et sans surveillance d'expiration de certificat, on peut reprendre l'architecture et l'exploiter.

• RFC 7858, Specification for DNS over Transport Layer Security : spécification DoT de mai 2016, port 853, profils de confidentialité et considérations de performance sur la réutilisation de connexion.
• RFC 8484, DNS Queries over HTTPS : spécification DoH d'octobre 2018, encodage des requêtes en HTTP GET et POST, type de média application/dns-message.
• DNS-over-HTTPS, documentation Unbound : configuration DoH et DoT de référence, port par défaut, contrainte HTTP/2 et dépendance nghttp2.
• DNS-over-HTTPS, documentation dnsdist : directives addDOHLocal et addTLSLocal, gestion des certificats et terminaison TLS en frontal.
• Canary domain use-application-dns.net, Mozilla : mécanisme de signalisation réseau pour désactiver DoH dans Firefox, et ses limites face à une activation manuelle.
• Recommandations relatives aux architectures des services DNS, ANSSI : guide d'août 2024 sur la séparation des services DNS internes, Internet et faisant autorité.