DoH vs DoT : quelle est la différence entre le DNS sur HTTPS et le DNS sur TLS ?

Chaque fois que vous cliquez sur un lien ou que vous saisissez une adresse dans votre navigateur, votre appareil envoie une requête de résolution à un résolveur récursif. Pendant des décennies, les serveurs DNS traditionnels ont traité ces requêtes via les protocoles UDP et TCP en clair sur le port 53. Ce trafic étant totalement non chiffré, toute personne se trouvant sur le chemin de la communication peut examiner vos habitudes de navigation ou manipuler les réponses que vous recevez.

Pour remédier à cette faille de sécurité persistante, l’Internet Engineering Task Force (IETF) a normalisé deux protocoles de transport cryptographiques distincts : le DNS sur TLS (DoT) et le DNS sur HTTPS (DoH). Bien que ces deux protocoles chiffrent les requêtes de domaine entre votre client et un résolveur, ils opèrent à des couches différentes de la pile réseau et ont des conséquences très différentes en matière de contrôle du réseau d’entreprise, de confidentialité des utilisateurs et de gestion des menaces.

Pourquoi chiffrer le DNS ?

Le DNS en clair reste l'une des principales failles structurelles de l'architecture Internet traditionnelle. Lorsque les requêtes transitent par des connexions publiques ou non fiables sans être chiffrées, elles exposent les utilisateurs et les organisations à trois risques principaux :

1. Écoute passive : toute entité ayant accès au trafic réseau — notamment les fournisseurs d’accès à Internet (FAI), les opérateurs de Wi-Fi public et les programmes de surveillance — peut enregistrer chaque recherche de domaine effectuée par votre appareil. Même si le trafic Web qui s’ensuit utilise le protocole HTTPS, vos requêtes DNS révèlent toujours précisément les services, applications et domaines avec lesquels vous interagissez.

2. Falsification et interception en cours de route : les attaquants partageant un réseau local peuvent intercepter des requêtes en clair et y injecter des réponses falsifiées, une tactique connue sous le nom d’« attaque de l’homme du milieu ». Cela permet à un adversaire de rediriger le trafic légitime vers une infrastructure malveillante sans alerter la victime.

3. Redirection et usurpation : dans un scénario classique d'usurpation DNS, des réponses de recherche falsifiées redirigent les utilisateurs vers des pages de phishing imitant les portails internes d'une entreprise, des sites bancaires ou des fournisseurs d'authentification unique.

Le chiffrement du canal de transport entre le périphérique client (résolveur stub) et le résolveur récursif en amont permet de neutraliser ces vecteurs d'attaque. Il garantit que les espions ne voient que des flux chiffrés plutôt que des noms de domaine en clair, tout en s'assurant que les réponses ne peuvent pas être modifiées par des « middleboxes » situées sur le chemin.

Qu'est-ce que le DNS sur TLS (DoT) ?

Le protocole DNS over TLS, normalisé par l'IETF dans la spécification RFC 7858, sécurise les messages DNS au format classique au sein d'un tunnel TLS ( Transport Layer Security ) chiffré.

Au lieu d'utiliser le port standard 53, DoT fonctionne sur son propre port réseau dédié : le port 853.

Lorsqu'un appareil lance une session DoT, il établit une connexion TCP fiable vers le port 853 d'un résolveur désigné, effectue une poignée de main cryptographique TLS standard et échange des requêtes DNS au sein de cette session sécurisée. La RFC 7858 interdit l'envoi de données en clair sur le port 853 ; si la négociation TLS échoue, la connexion est interrompue plutôt que de basculer vers une transmission non chiffrée sur ce port.

Comme DoT n'ajoute aucun « wrapper » au niveau de la couche application, il réduit au minimum la surcharge liée aux requêtes. Une fois la connexion établie, les clients peuvent réutiliser les sessions TLS existantes et acheminer plusieurs requêtes simultanément afin d'éviter la latence liée à la négociation de connexion à chaque requête.

Prise en charge des systèmes d'exploitation et des plateformes

• Android : À partir d'Android 9 (Pie), Google a ajouté la prise en charge native du protocole DoT via le paramètre « DNS privé ». Lorsqu'il est activé avec un nom d'hôte défini, toutes les requêtes DNS de l'appareil transitent par le protocole DoT.
• Linux : les résolveurs système tels que systemd-resolved et les démons de mise en cache locale comme Unbound ou Stubby prennent en charge nativement le protocole DoT.
• Appareils d'entreprise : les pare-feu modernes de nouvelle génération (NGFW) et les résolveurs récursifs dédiés prennent souvent en charge nativement le protocole DoT afin de chiffrer les requêtes internes transmises aux résolveurs en amont chargés de la protection.

Qu'est-ce que le DNS sur HTTPS (DoH) ?

Le DNS sur HTTPS, normalisé dans la RFC 8484, adopte une approche architecturale différente. Plutôt que de mettre en place un canal de transport dédié aux requêtes de domaine, le DoH encapsule les messages de requête et de réponse DNS au sein de charges utiles HTTP/2 ou HTTP/3 standard, chiffrées à l'aide du protocole TLS.

DoH fonctionne sur le port 443, le même port réseau que celui utilisé par le trafic Web standard.

Conformément à la spécification RFC 8484, les requêtes DNS sont transmises sous forme de requêtes HTTP GET ou POST portant le type MIME spécifique « application/dns-message ». Ces échanges étant entièrement multiplexés avec le trafic Web sur le port 443, les observateurs externes du réseau ne peuvent pas facilement distinguer une requête DNS d'un simple téléchargement de page Web sécurisée.

Cette conception garantit une résilience maximale en matière de confidentialité pour l'utilisateur final. Si un réseau intermédiaire ou un FAI tente d'inspecter ou de filtrer le trafic DNS, le protocole DoH l'en empêche, à moins qu'il ne parvienne à intercepter et à inspecter toutes les connexions HTTPS sortantes.

Prise en charge des systèmes d'exploitation et des navigateurs

• Navigateurs Web : Mozilla Firefox, Google Chrome, Microsoft Edge et Brave intègrent tous des moteurs DoH configurables. Firefox a été le premier à déployer le protocole DoH par défaut dans plusieurs régions, tandis que les navigateurs basés sur Chromium prennent en charge la mise à niveau automatique vers le protocole DoH lorsque le système d'exploitation sous-jacent utilise un résolveur compatible.
• Windows 11 : Windows 11 intègre une prise en charge DoH à l'échelle du système. Les administrateurs réseau et les utilisateurs peuvent attribuer des adresses IP de serveurs DNS et définir manuellement des URL de modèles DoH via les propriétés de la carte réseau.
• Apple (macOS et iOS) : les plateformes Apple prennent en charge les protocoles DoH et DoT de manière native, via des profils de configuration DNS chiffrés ou des applications d'extension réseau dédiées.

DoH vs DoT : comparaison côte à côte

Explication des principales différences

Allocation des ports et visibilité du réseau

La divergence opérationnelle la plus flagrante entre le DoT et le DoH concerne les numéros de port qui leur sont attribués.

DoT fonctionne sur le port 853. Cette attribution dédiée rend la surveillance du réseau prévisible. Un administrateur système peut consulter les journaux du pare-feu, vérifier si le trafic du port 853 est acheminé vers un résolveur interne autorisé et bloquer les connexions indésirables à l'aide d'une seule règle. Si un terminal non géré tente de contacter un résolveur non autorisé sur le port 853, le pare-feu rejette le paquet sans perturber le trafic Web normal.

DoH transite par le port 443. Étant donné que le port 443 achemine la quasi-totalité du trafic Internet chiffré, un réseau ne peut pas bloquer le port 443 sans couper l'accès au World Wide Web. Par conséquent, les administrateurs réseau ne peuvent pas déterminer si un paquet sortant correspond à un simple appel d'API, à un utilisateur consultant un site de commerce électronique ou à une requête DNS chiffrée adressée à un résolveur externe.

Compromis entre sécurité et vie privée

Le ministère de la Santé et le ministère des Transports mettent en lumière un débat récurrent entre la protection de la vie privée des utilisateurs finaux et la défense centralisée des réseaux.

En matière de protection de la vie privée, le protocole DoH est particulièrement performant. Sur les réseaux Wi-Fi publics ou dans les régions où les fournisseurs d'accès enregistrent et monétisent l'historique de navigation de leurs clients, le protocole DoH dissimule les métadonnées des requêtes au sein du flux de navigation Web habituel, protégeant ainsi les utilisateurs contre un suivi intrusif.

Du point de vue de la sécurité d'entreprise, le protocole DoH non géré présente un risque important. De nombreux systèmes modernes de prévention des menaces s'appuient sur le filtrage DNS pour intercepter les domaines de commande et de contrôle (C2) connus, mettre fin aux tunnels d'exfiltration de données et bloquer les tentatives d'hameçonnage avant même que la phase d'établissement de la connexion TCP ne puisse commencer.

Lorsqu'un navigateur ou une application malveillante au sein d'un réseau d'entreprise passe par défaut au protocole DoH externe :

• Il contourne entièrement les pare-feu DNS locaux et les résolveurs Active Directory.
• Cela empêche les outils de gestion des informations et des événements de sécurité (SIEM) d'accéder aux journaux de requêtes des terminaux.
• Les acteurs malveillants avancés peuvent exploiter les canaux DoH pour communiquer discrètement avec une infrastructure de commande externe, en dissimulant des charges utiles malveillantes au sein de sessions ordinaires sur le port 443.

C'est pourquoi les équipes informatiques des entreprises bloquent souvent les terminaux DoH non autorisés au niveau de la frontière IP ou déploient des stratégies de groupe imposant l'utilisation de résolveurs approuvés par l'entreprise.

Performances et latence

Dans des environnements courants, ces deux protocoles offrent des réponses rapides dès que leurs connexions initiales sont établies. Cependant, leurs mécanismes sous-jacents entraînent de légères différences de performances.

Le protocole DoT utilise des charges utiles DNS brutes sur TLS. Cela permet de conserver un format compact, ce qui réduit le nombre d'octets nécessaires par transaction. Il s'appuie sur les mécanismes standard de maintien de connexion TCP et de reprise de session TLS pour minimiser la surcharge liée à la connexion.

Le protocole DoH entraîne une charge de traitement légèrement supérieure, car il doit encapsuler les requêtes DNS dans des en-têtes HTTP et gérer les machines à états HTTP. Cependant, comme le DoH tire parti du multiplexage HTTP/2 et HTTP/3, il peut traiter des centaines de requêtes simultanées au sein d’un seul flux sans blocage en tête de file, tout en utilisant les mécanismes de mise en cache HTTP. Pour la navigation Web standard, la différence de latence réelle entre le DoT et le DoH est rarement perceptible pour les utilisateurs.

Lequel choisir ?

Le choix entre DoT et DoH dépend de votre environnement, de vos besoins opérationnels et de l'entité qui gère l'infrastructure réseau.

Utilisateurs individuels sur des réseaux non fiables ou publics

Si vous voyagez souvent, travaillez depuis des cafés ou utilisez des FAI résidentiels qui surveillent vos requêtes, le protocole DoH est généralement l'option la plus sûre. Activer le protocole DoH dans votre navigateur préféré garantit que les opérateurs de réseau locaux ne peuvent pas enregistrer les domaines que vous visitez ni y injecter de scripts de suivi.

Réseaux d'entreprise et réseaux professionnels

Les organisations devraient privilégier le protocole DoT ou le protocole DoH strictement géré.

Dans les environnements d'entreprise, la visibilité est une exigence incontournable. Les équipes informatiques doivent s'assurer que tous les postes de travail, appareils mobiles et périphériques IoT effectuent la résolution des noms via des résolveurs sécurisés et approuvés.

Pour conserver le contrôle tout en préservant le chiffrement, les entreprises devraient :

• Configurer les terminaux pour qu'ils utilisent des résolveurs récursifs internes via DoT.
• Appliquez des politiques administratives dans les navigateurs tels que Chrome, Edge et Firefox afin d'empêcher les utilisateurs ou les mises à jour d'activer ou de désactiver les résolveurs DoH publics non gérés.
• Bloquez le trafic sortant vers les adresses IP publiques connues des résolveurs DoH au niveau des pare-feu afin d'empêcher le contournement des contrôles de sécurité internes.
• Appliquer les meilleures pratiques établies en matière de sécurité DNS afin de garantir une protection uniforme dans toutes les zones internes.

Appareils mobiles

Les appareils mobiles passent constamment du réseau Wi-Fi d'entreprise sécurisé aux routeurs domestiques et aux antennes-relais des opérateurs de téléphonie mobile. Android gère cette transition de manière transparente grâce à sa fonctionnalité « DNS privé » intégrée, qui utilise le protocole DoT, assurant ainsi un chiffrement uniforme pour toutes les applications de l'appareil sans nécessiter de logiciel supplémentaire. Les appareils iOS et macOS peuvent bénéficier de la même protection grâce à des profils de configuration prenant en charge soit le protocole DoT, soit le protocole DoH.

Qu'en est-il du DNS sur QUIC (DoQ) ?

À mesure que les architectures de transport évoluent, un nouveau protocole fait son apparition : le DNS sur QUIC (DoQ), normalisé dans la RFC 9250.

Alors que les protocoles DoT et DoH traditionnels fonctionnent sur TCP, le protocole DoQ fonctionne sur QUIC via le port UDP 853. QUIC intègre directement le chiffrement TLS 1.3 dans sa phase d'établissement de la connexion. Cette architecture résout le problème du blocage en tête de file, accélère l'établissement de la connexion grâce à la reprise de session en 0 RTT et prend en charge la migration transparente de la connexion lorsque les appareils mobiles basculent entre le Wi-Fi et les réseaux de données mobiles.

Si DoQ est à la pointe de la recherche et des performances en matière de DNS chiffré, son adoption en production n'en est encore qu'à ses débuts par rapport aux écosystèmes bien établis que sont DoT et DoH.

DoH/DoT vs DNSSEC : pourquoi les deux sont indispensables

On croit souvent à tort que l'activation de DoH ou de DoT rend les autres protocoles de sécurité DNS superflus. En réalité, le transport chiffré et les extensions de sécurité du système de noms de domaine (DNSSEC) concernent deux aspects totalement distincts du cycle de vie de la sécurité.

• Les protocoles DoH et DoT protègent le chemin de transport : ils chiffrent la connexion entre votre appareil et le résolveur récursif. Ils empêchent les espions présents sur votre réseau local ou chez votre FAI d'intercepter la requête. Cependant, ils ne vous permettent pas de savoir si le résolveur en amont fournit une réponse exacte provenant du véritable propriétaire du domaine.
• Le protocole DNSSEC garantit l'intégrité des données : il utilise des signatures numériques cryptographiques (enregistrements RRSIG) publiées dans le fichier de zone pour vérifier que les données DNS renvoyées n'ont pas été altérées au niveau du serveur de référence ni corrompues dans les caches des résolveurs.

Si un pirate parvient à compromettre un serveur de noms faisant autorité en amont ou mène une attaque par empoisonnement du cache DNS, les protocoles DoH et DoT transmettront cette réponse falsifiée directement à votre appareil via un tunnel sécurisé et chiffré.

Pour garantir l'intégrité totale de leur infrastructure, les organisations doivent mettre en œuvre le protocole DNSSEC dans leurs propres zones de domaine, tout en configurant leurs résolveurs pour qu'ils valident les signatures. Vous pouvez vérifier si vos domaines actuels publient des signatures cryptographiques valides en les soumettant à notre outil de vérification DNSSEC automatisé.

Foire aux questions

Le protocole DoH est-il plus sécurisé que le protocole DoT ?

D’un point de vue purement cryptographique, aucun des deux protocoles n’est intrinsèquement plus sûr que l’autre. Tous deux utilisent un chiffrement TLS robuste pour protéger les requêtes DNS contre toute surveillance et manipulation. La véritable différence réside dans la visibilité réseau : le protocole DoH offre une meilleure protection de la vie privée contre la surveillance du réseau local en partageant le port 443 avec le trafic Web, tandis que le protocole DoT offre des capacités de gestion supérieures aux équipes de sécurité des entreprises grâce à l’utilisation du port dédié 853.

Dois-je activer ou désactiver le DNS sur HTTPS ?

Pour les utilisateurs individuels utilisant des appareils personnels, le fait de laisser la fonctionnalité DoH activée offre des avantages immédiats en matière de confidentialité, car cela empêche les opérateurs de réseau locaux et les FAI d'enregistrer les requêtes de résolution d'adresses.

Toutefois, dans les environnements d'entreprise, le protocole DoH non géré doit généralement être désactivé ou redirigé vers des résolveurs approuvés par l'entreprise. Lorsqu'il n'est pas géré, le protocole DoH au niveau du navigateur contourne les pare-feu du réseau interne, les règles de filtrage de contenu et les dispositifs de surveillance des menaces.

Le protocole DoH peut-il être bloqué sur un réseau ?

Oui. Bien qu’il ne soit pas possible de bloquer le protocole DoH en fermant un port spécifique sans désactiver également le trafic Web HTTPS sur le port 443, les entreprises peuvent limiter l’utilisation du DoH à l’aide d’autres mesures de contrôle. Les administrateurs réseau peuvent bloquer l’accès aux adresses IP publiques des résolveurs DoH commerciaux connus, restreindre l’accès via des proxys Web ou utiliser des pare-feu de nouvelle génération dotés de moteurs d’identification des applications (App-ID) capables de reconnaître les signatures du trafic DoH.

Un VPN rend-il le DoH ou le DoT superflus ?

Un réseau privé virtuel (VPN) crypte l'ensemble du trafic réseau sortant de votre appareil, y compris vos requêtes DNS, au sein d'un tunnel crypté menant à la passerelle VPN. Si vous faites confiance à votre fournisseur de VPN et que vous configurez votre système pour qu'il résolve les requêtes via ses résolveurs récursifs privés, vous n'avez pas nécessairement besoin des protocoles DoH ou DoT, car l'intégralité du tunnel est déjà cryptée.

Cependant, l'utilisation de DoH ou de DoT à l'intérieur ou à l'extérieur d'un VPN renforce la sécurité en profondeur, garantissant ainsi que les requêtes restent protégées même si le « split tunneling » entraîne la fuite de paquets DNS standard.

Conclusion : protégez vos résolveurs et vos enregistrements

Le DNS sur HTTPS et le DNS sur TLS apportent tous deux des améliorations notables en matière de confidentialité par rapport à la norme UDP en clair sur le port 53, vieille de quarante ans. Le choix entre les deux dépend du contexte : le DoH offre aux utilisateurs individuels discrétion et confidentialité sur les réseaux publics, tandis que le DoT fournit aux organisations les limites claires et la visibilité nécessaires pour appliquer les politiques de sécurité d'entreprise.

Cependant, le chiffrement de la manière dont votre équipe effectue des requêtes vers des domaines tiers ne résout que la moitié du problème lié à la vulnérabilité de votre infrastructure. Vous devez également protéger les enregistrements DNS publics qui orientent le reste du monde vers les services web, les applications et les serveurs de messagerie de votre entreprise.

Les zones de domaine non surveillées sont exposées à des modifications non autorisées des enregistrements, à l'absence de signatures cryptographiques et à des certificats périmés. PowerDMARC aide les organisations à maintenir une surveillance totale de leurs domaines grâce à la surveillance de la sécurité DNS et à la conformité.

En associant la surveillance continue des enregistrements et les alertes de modification de la chronologie DNS à notre outil gratuit de vérification DNSSEC, vous pouvez vous assurer que l'infrastructure DNS de votre entreprise reste vérifiable, conforme et protégée contre l'usurpation d'identité sous tous les angles.