En résumé : le DNS classique (le protocole de 1987) envoie les requêtes en clair via UDP port 53. Quiconque se trouve sur le chemin réseau peut lire chaque domaine que vous consultez, modifier les réponses ou bloquer des requêtes précises. DoT (RFC 7858, 2016) encapsule les requêtes DNS dans TLS sur le port 853. DoH (RFC 8484, 2018) les glisse dans des requêtes HTTPS sur le port 443. Les deux règlent le problème du texte en clair. Ils divergent sur la question de qui contrôle le déploiement, qui voit les requêtes et qui peut les bloquer — et c'est précisément la question que la plupart des gens posent quand ils demandent « lequel devrais-je utiliser ». Tout dépend de ce contre quoi vous cherchez à vous protéger.
Ce que le chiffrement DNS règle — et ce qu'il ne règle pas
Avant de comparer les deux, il vaut la peine de préciser ce que chaque protocole protège réellement. Le DNS classique expose chaque nom de domaine consulté par votre appareil. Visitez example.com : votre ISP — ou tout opérateur réseau sur le chemin — peut voir la requête pour example.com, avant même que votre navigateur envoie la première requête HTTPS. Le contenu de cette requête HTTPS est chiffré ; la résolution DNS qui l'a précédée ne l'est pas. Le DNS chiffré comble ce manque précis.
Ce qu'il ne règle pas : l'adresse IP de destination à laquelle vous vous connectez reste visible. Le champ TLS Server Name Indication (SNI), dans les versions TLS plus anciennes, laissait aussi fuiter le nom d'hôte lors de la négociation — bien que l'Encrypted Client Hello (ECH) y remédie dans TLS 1.3. Le DNS chiffré associé à ECH bouche les fuites les plus évidentes. Sans ECH, le DNS chiffré seul colmate une fuite mais laisse ouverte celle du SNI, ce qui signifie que le nom d'hôte de destination reste visible lors de la négociation TLS. Pour être honnête : le DNS chiffré est nécessaire, mais pas suffisant.
Comment fonctionne DoT — un canal dédié sur le port 853
DoT (DNS-over-TLS, défini dans RFC 7858) est la conception conceptuellement la plus simple. Votre appareil ouvre une connexion TCP vers le serveur DNS sur le port 853, effectue une négociation TLS — le même TLS qui protège HTTPS — puis envoie des requêtes DNS standards à l'intérieur du flux chiffré. Le serveur DNS répond avec des réponses DNS standards, également dans le flux chiffré. Vu du réseau, tout ce qu'on observe est une connexion TLS vers le port 853.
Comme le port 853 est officiellement attribué par l'IANA exclusivement à DoT, tout trafic TCP sur ce port est sans ambiguïté du DoT. Les opérateurs réseau peuvent identifier DoT sans effort — pas besoin d'inspection approfondie des paquets, il suffit de regarder le port de destination. S'ils souhaitent bloquer DoT, ils bloquent le port 853. S'ils veulent l'autoriser mais consigner l'IP du serveur DNS de destination, c'est tout aussi simple. DoT ne cache pas qu'il est du DNS, ce qui est un avantage dans certains cas d'usage et un inconvénient dans d'autres.
Comment fonctionne DoH — le DNS dissimulé dans le trafic web
DoH (DNS-over-HTTPS, défini dans RFC 8484) adopte une approche différente. Votre appareil envoie des requêtes DNS sous forme de requêtes HTTP POST (ou GET avec le paramètre de requête) vers une URL précise sur le serveur HTTPS du fournisseur DNS. Le corps du POST contient un message DNS binaire ; le corps de la réponse contient une réponse DNS binaire. Le tout se déroule via une connexion HTTPS ordinaire sur le port 443 — le même port qu'utilise votre navigateur pour charger des pages web.
Du point de vue du réseau, une requête DoH est indiscernable d'une requête HTTPS ordinaire vers le même serveur. La connexion ressemble à du trafic web. Les tailles de paquets ressemblent à du trafic web (après la requête initiale, les requêtes suivantes réutilisent la même connexion HTTP/2 ou HTTP/3). L'IP de destination appartient à un point de terminaison d'apparence générique — le 1.1.1.1 de Cloudflare ou le 8.8.8.8 de Google servent à la fois DoH et d'autres trafics web sur les mêmes IP. Pour bloquer DoH spécifiquement, un opérateur réseau doit identifier et bloquer les points de terminaison précis, ce qui est bien plus difficile que de bloquer un port.
Différences de visibilité sur le réseau
La différence de transport engendre une différence de visibilité. Avec DoT, votre opérateur réseau (IT d'entreprise, ISP, école, hôtel) peut voir que vous utilisez du DNS chiffré, identifier quel serveur DoT vous utilisez (par IP de destination), et choisir de le bloquer. Avec DoH, l'opérateur voit du trafic HTTPS chiffré vers l'IP du fournisseur DNS, mais à moins de tenir à jour des listes de blocage des points de terminaison DoH, il ne peut pas distinguer DoH d'un HTTPS ordinaire vers ce même fournisseur.
Les conséquences sont prévisibles. Les services IT d'entreprise ont longtemps préféré DoT parce qu'ils peuvent le bloquer proprement : bloquer le port 853, et le DNS bascule sur le résolveur de l'organisation, qu'ils surveillent et filtrent. Ils ont tendance à détester DoH pour la même raison — il contourne leur visibilité. Les défenseurs de la vie privée des consommateurs préfèrent en général DoH pour cette même raison. Des parties prenantes différentes attendent des résultats différents du même choix architectural.
Ce que les réseaux peuvent bloquer
DoT est facile à bloquer. Le port 853 n'est utilisé que par DoT ; une règle de pare-feu pour le bloquer suffit. De nombreux réseaux d'entreprise le font déjà. Beaucoup de pare-feux filtrants dans des régions restrictives aussi. Si vous configurez un appareil pour utiliser DoT et que le réseau bloque le port 853, les requêtes DNS de l'appareil échouent jusqu'à ce que le système ou l'application bascule sur le DNS en clair — et la plupart basculent silencieusement.
DoH est bien plus difficile à bloquer parce que la seule façon de le faire est d'identifier et de mettre sur liste noire chaque point de terminaison DoH. Le 1.1.1.1 de Cloudflare est le plus connu et figure généralement sur la liste ; le 8.8.8.8 de Google aussi. Mais les points de terminaison DoH indépendants se multiplient — des listes publiques comme le wiki DoH de curl en répertorient des centaines. Un opérateur réseau qui souhaite bloquer DoH globalement doit maintenir cette liste à jour et accepter d'avoir toujours un temps de retard sur les nouveaux points de terminaison. Certains réseaux restrictifs tentent de détecter DoH par analyse des caractéristiques du trafic (DoH a des caractéristiques distinctives de taille et de timing des requêtes), mais cette approche est fragile et génère des faux positifs.
La documentation Mozilla sur DoH cite explicitement cette propriété — la difficulté à bloquer DoH — comme un objectif de conception délibéré, non un accident. Cette même propriété rend DoH controversé en contexte d'entreprise, où l'opérateur réseau considère la visibilité DNS comme une composante légitime de son dispositif de sécurité plutôt que comme une atteinte à la vie privée des utilisateurs.
Implications pour les entreprises et le contrôle parental
Le filtrage au niveau DNS — celui qui alimente la plupart des logiciels de contrôle parental, le filtrage de « navigation sécurisée » en entreprise et les formes les plus simples de blocage de domaines malveillants — fonctionne en interceptant les requêtes DNS et en rejetant celles qui ciblent des domaines bloqués, ou en renvoyant des réponses falsifiées. Nous en avons décrit le fonctionnement dans notre article sur comment fonctionne vraiment le filtrage au niveau DNS.
Le DNS chiffré contourne entièrement ce mécanisme — DoT et DoH acheminent les requêtes vers un résolveur différent de celui du réseau local, rendant inutile tout filtrage appliqué au résolveur local. Du point de vue des fournisseurs de contrôle parental, c'est un problème. Du point de vue de l'utilisateur, tout dépend de si le filtrage est perçu comme légitime ou intrusif. La plupart des outils de gestion des postes en entreprise désactivent désormais DoH dans les navigateurs par politique et s'appuient soit sur la configuration DNS au niveau du système d'exploitation, soit sur une inspection complète du trafic pour maintenir la visibilité. Les profils iOS gérés par MDM d'Apple incluent un mécanisme de configuration DoH/DoT conçu précisément à cet effet : l'entreprise peut spécifier un résolveur DNS chiffré de son choix et empêcher les utilisateurs de le modifier.
Pour les foyers, la réalité pratique est qu'activer DoH dans un navigateur contourne tout filtrage de contenu basé sur le routeur que vous avez configuré. C'est une fonctionnalité ou un bug selon le côté de la configuration où vous vous trouvez.
Caractéristiques de performance
DoT a généralement une surcharge par requête légèrement inférieure à DoH. Les deux protocoles utilisent TLS, mais DoT n'encapsule chaque message DNS que dans une enveloppe très légère — pas de ligne de requête HTTP, pas d'en-têtes, pas de Content-Length, pas de méthode HTTP. Le message DNS est injecté directement dans le flux TLS. DoH, en revanche, encapsule chaque requête DNS dans un POST ou GET HTTP, ce qui ajoute des dizaines à des centaines d'octets de surcharge par requête.
Cette surcharge est en grande partie amortie par la réutilisation des connexions. DoT comme DoH maintiennent la connexion TLS ouverte pour de nombreuses requêtes, si bien que le coût de la négociation n'est payé qu'une fois. DoH sur HTTP/2 multiplexe les requêtes sur la même connexion, et HTTP/3 (sur QUIC) réduit encore la latence. En pratique, sur un réseau moderne, les deux protocoles produisent une latence indiscernable pour l'utilisateur — quelques millisecondes de différence au plus. Ne choisissez pas l'un plutôt que l'autre pour des raisons de performance ; le choix porte sur la visibilité, le contrôle et le modèle de menace.
DoT vs DoH en un coup d'œil
| Propriété | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| Port | 853 (dédié) | 443 (partagé avec HTTPS) |
| RFC | RFC 7858 (2016) | RFC 8484 (2018) |
| Transport | TLS brut sur TCP | HTTPS (HTTP/2 ou HTTP/3) |
| Identifiable sur le réseau | Oui — le port 853 est propre à DoT | Non — ressemble à du HTTPS ordinaire |
| Blocage par le réseau | Facile (bloquer le port 853) | Difficile (nécessite une liste noire de points de terminaison) |
| Support navigateur | Non (les navigateurs n'implémentent pas DoT) | Firefox, Chrome, Edge, Safari le supportent tous |
| Support système d'exploitation | Android 9+, iOS 14+, macOS 11+, Linux (systemd-resolved) | Android 9+, iOS 14+, macOS 11+, Windows 11+ |
| Visibilité en entreprise | Visible par port ; facile à surveiller ou bloquer | Contourne la surveillance par port ; nécessite une inspection des points de terminaison |
| Surcharge de latence par requête | Faible (enveloppe minimale) | Légèrement plus élevée (en-têtes HTTP) ; négligeable avec le multiplexage HTTP/2 |
| Résistance à la censure | Faible (port 853 bloquable) | Plus élevée (le port 443 est indispensable au web moderne) |
Lequel choisir — trois scénarios
« Quel protocole est le meilleur » dépend entièrement de ce que vous cherchez à accomplir. Voici trois scénarios concrets avec des réponses concrètes :
Scénario 1 : appareil personnel sur des réseaux hostiles ou non fiables
Cafés, hôtels, aéroports, Wi-Fi chez des amis. Le modèle de menace est l'opérateur du réseau local qui observe ou modifie votre DNS. Les deux protocoles assurent le chiffrement ; DoH est préférable parce qu'il est bien plus difficile à bloquer pour un réseau hostile. Si vous utilisez DoT sur un réseau qui bloque le port 853, vos requêtes basculent silencieusement vers le texte en clair sur le port 53 (la plupart des clients OS échouent de cette façon) — et vous avez divulgué tout ce que vous cherchiez à protéger. DoH atteint presque toujours son point de terminaison.
Scénario 2 : réseau domestique avec appareils gérés pour enfants
Vous voulez que les appareils des enfants utilisent un résolveur DNS filtrant (NextDNS, OpenDNS Family Shield, Cloudflare for Families) et que ceux-ci ne puissent pas le contourner. DoT est en fait plus pratique ici — vous configurez l'appareil pour utiliser un résolveur DoT précis, et l'enfant ne peut pas facilement changer un paramètre dans un navigateur pour utiliser un autre DNS. Le DoH des navigateurs peut être désactivé par une politique MDM ou en définissant le domaine canari. Le choix entre DoT et DoH importe moins que la configuration du DNS au niveau du système d'exploitation plutôt que de laisser chaque application décider.
Scénario 3 : vous utilisez déjà un VPN
Si vous utilisez un VPN, le réseau local ne peut voir vos requêtes DNS de toute façon — le tunnel VPN chiffre tout, DNS inclus. La question pertinente devient quel résolveur DNS le VPN utilise en interne et s'il prend en charge le DNS chiffré vers son résolveur amont. La plupart des VPN modernes (dont Casper's Cloak) utilisent le DNS chiffré en interne et appliquent un filtrage des domaines malveillants au niveau du résolveur avant de renvoyer la réponse dans le tunnel. Dans cette configuration, DoT ou DoH est surtout un détail d'implémentation ; ce qui compte, c'est que le résolveur ne soit pas votre ISP et ne consigne pas vos requêtes.
La question de confiance que les deux protocoles esquivent
DoT et DoH transfèrent tous deux la confiance de votre opérateur réseau local vers le fournisseur de DNS chiffré que vous choisissez. Cloudflare, Google, Quad9, NextDNS, ControlD — chacune de ces entreprises voit chaque requête DNS que vous leur envoyez. Le chiffrement vers eux ne signifie pas la confidentialité vis-à-vis d'eux. Si votre préoccupation est que votre ISP ne devrait pas voir votre DNS, le DNS chiffré résout le problème. Si votre préoccupation est qu'aucun tiers ne devrait voir votre DNS, aucun des deux protocoles n'aide ; vous devez faire tourner votre propre résolveur récursif (ce qui est un projet à part entière).
Ce que vous pouvez exiger du résolveur auquel vous faites confiance : une politique de journalisation claire, des audits tiers, la prise en charge de la minimisation des requêtes (pour que les serveurs faisant autorité en amont ne voient que les parties de la requête dont ils ont besoin) et la validation DNSSEC. Les principaux fournisseurs publics de DoH/DoT publient tous leurs politiques ; lisez-les. Notre guide approfondi sur ce sujet se trouve dans notre bilan DoH 2026.
En conclusion
DoT et DoH résolvent le même problème fondamental — la fuite en clair du DNS qui expose vos destinations de navigation au réseau — avec deux stratégies architecturales différentes. DoT est la conception honnête : un port dédié, facile à identifier, facile à gérer, facile à bloquer. DoH est la conception camouflée : cachée dans le trafic HTTPS, difficile à identifier sans listes noires de points de terminaison, difficile à bloquer à grande échelle.
Pour les consommateurs sur des réseaux hostiles, DoH est le bon choix parce que c'est celui qui atteint réellement son point de terminaison. Pour les entreprises qui ont besoin de visibilité DNS, DoT est le choix le plus coopératif. Pour ceux qui font tourner leur propre DNS filtrant chez eux, DoT est plus configurable et plus difficile à contourner par les utilisateurs au niveau applicatif. Pour les utilisateurs de VPN, le choix est en grande partie invisible — le client VPN s'en charge.
La vraie question est rarement « DoT ou DoH » — c'est « à quel résolveur est-ce que je fais confiance, et quelle est sa politique de journalisation ». Choisissez un résolveur en qui vous avez confiance, configurez-le au niveau du système (pas par navigateur), et vérifiez avec un test de fuite DNS que vous avez bien appliqué la configuration. Le protocole que vous utilisez pour lui parler compte moins que la politique de l'entité à l'autre bout.