Tous les protocoles de chiffrement DNS ne se valent pas — et votre fournisseur d’accès à Internet préfère que vous l’ignoriez.
Derrière l’apparente simplicité des adresses web que nous tapons quotidiennement se cache une mécanique bien plus austère : l’Internet fonctionne sur la base d’adresses IP et de serveurs distants. Le cœur de cette machinerie repose sur le Domain Name System (DNS), une architecture qui traduit les noms de domaine en identifiants numériques lisibles par les machines.
Chaque requête saisie dans votre navigateur enclenche cette conversion : le DNS traduit le langage humain en syntaxe informatique. À ce moment précis, votre terminal interroge un serveur DNS et transmet un flot de métadonnées. Mais voici le détail qu’on préfère taire : votre fournisseur d’accès, les autorités, ou toute entité dotée d’outils de surveillance peuvent observer ces requêtes, en clair, sans effort particulier.
Le rempart possible à cette exposition ? Le chiffrement des requêtes DNS. En théorie, cela devrait empêcher toute tierce partie de suivre vos allées et venues numériques. En pratique, la situation est plus ambiguë : tous les protocoles de chiffrement ne protègent pas de la même manière, et certains laissent filtrer des traces comportementales exploitables pour identifier votre localisation ou vos habitudes. Croire qu’un simple « DNS chiffré » équivaut à un anonymat absolu est une illusion commode – et dangereuse.
Quand votre fournisseur d’accès s’intéresse à vos résolutions DNS
Les requêtes DNS constituent la fenêtre la plus simple par laquelle un fournisseur d’accès peut observer votre activité. Même si vous consultez des sites protégés par HTTPS, la requête DNS initiale trahit déjà le domaine visité. Ce n’est pas le contenu de la page, mais le nom du site, suffisant pour dresser un profil d’usage. Certains fournisseurs exploitent cette visibilité à des fins de gestion de réseau, d’autres y voient un levier commercial : la Federal Trade Commission américaine a déjà documenté la revente de données issues des requêtes DNS ou l’injection de publicités ciblées.
L’introduction du chiffrement DNS vient perturber ce modèle économique. Les protocoles DNS over HTTPS (DoH) et DNS over TLS (DoT) rendent opaques ces requêtes, coupant la ligne de visibilité directe des FAI. Pour l’utilisateur, c’est un gain de confidentialité ; pour les fournisseurs, une perte de contrôle et de revenus. Toutefois, la confiance se déplace : vous confiez désormais vos résolutions à un résolveur tiers, souvent géré par des géants tels que Cloudflare ou Google.
Mais cette mutation a un coût : les FAI ne peuvent plus aisément appliquer les filtres de protection parentale, bloquer des sites malveillants ou se conformer à certaines régulations locales. Le chiffrement DNS déplace donc le centre de gravité du contrôle : il protège l’utilisateur, tout en rendant plus opaques les mécanismes de supervision du réseau.
DoH, DoT, ODoH : des chemins divergents vers un même objectif
Historiquement, il n’existait pas de standard unifié pour le chiffrement DNS. Chaque approche adoptait sa propre méthode, avec ses compromis techniques. Aujourd’hui, DoH et DoT constituent les deux piliers dominants. Tous deux masquent les requêtes en texte clair, mais leur fonctionnement diffère.
DoH se fond dans le trafic web global : il transite via HTTPS, ce qui le rend indiscernable du flux habituel et difficile à bloquer. Les navigateurs tels que Chrome ou Firefox peuvent l’activer nativement, sans intervention système. DoT, à l’inverse, repose sur un port dédié (853) et une connexion TCP/TLS, davantage adaptée aux configurations réseau ou routeurs. Il offre une isolation technique plus nette, mais peut être plus aisément filtré par un pare-feu.
Une évolution plus récente, Oblivious DoH (ODoH), tente de résoudre la faille structurelle du modèle : le résolveur, même s’il ne lit pas vos données, voit toujours votre adresse IP, donc votre origine. ODoH introduit un proxy intermédiaire : l’un voit l’adresse IP, l’autre voit le domaine, mais jamais les deux. Ce cloisonnement réduit la capacité d’identification directe. Cependant, la double couche de chiffrement engendre une légère latence, et le protocole, encore expérimental selon l’IETF, reste marginal dans les implémentations actuelles.
Plus ancien mais toujours pertinent, DNSCrypt propose lui aussi un chiffrement robuste et une authentification stricte, sans dépendre des standards IETF. Son écosystème demeure actif, et certaines implémentations modernes supportent déjà ODoH.
Au final, le choix entre ces méthodes ne repose pas uniquement sur la sécurité brute, mais sur un équilibre entre performance, fiabilité et transfert de confiance.+
Quelles différences techniques majeures entre DoH et DoT ?
| Critère | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|
| Protocole/port | TLS sur port 853 | HTTPS sur port 443 |
| Couche OSI | Couche transport (niveau OS : global) | Couche application (niveau app/browser) |
| Configuration | Système/OS, routeur, appareil | Navigateur, app spécifique |
| Détection réseau | Facilement repérable, car port dédié | Difficile à filtrer, camouflé dans HTTPS |
| Performance | Légère latence, paquets plus petits | Latence un peu supérieure, paquets + gros |
| Résistance à la censure | Faible (port bloquable par les FAI) | Forte (hors du lot, car comme HTTPS) |
| Visibilité réseau | Pratique pour l’analyse réseau d’entreprise | Plus opaque côté administrateur |
| Usage principal | Réseaux/OS, appliances, familles, pro | Navigateur web, mobile, public, anonymat |
L’ombre du tiers de confiance
Le chiffrement DNS ne vous rend pas invisible : il ne fait que déplacer le point d’observation. Vos requêtes deviennent illisibles pour les observateurs extérieurs, mais votre résolveur DNS chiffré conserve une vision claire des domaines consultés. Vous troquez la surveillance de votre FAI contre celle d’un acteur centralisé.
Les métadonnées résiduelles – rythme des requêtes, volumes, corrélations temporelles – permettent encore d’inférer des comportements. Des schémas d’accès ou des paquets synchrones peuvent révéler, par simple analyse statistique, les sites consultés sans briser le chiffrement.
Autre écueil : la centralisation. Une part substantielle du trafic DNS chiffré passe par une poignée d’acteurs dominants. Si l’un d’eux subit une injonction légale, une compromission, ou modifie sa politique interne, l’ensemble de la confidentialité mondiale s’en trouve affecté.
Vers une décision éclairée
Construire son propre résolveur local est possible, mais complexe à maintenir. Les solutions chiffrées grand public restent plus réalistes, avec leurs concessions :
- DoH/DoT déplacent la confiance vers des entités tierces, mais assurent une compatibilité large et une latence modérée.
- ODoH renforce la séparation entre identité et requête, mais reste embryonnaire et légèrement plus lent.
Aucune de ces approches n’offre une invulnérabilité totale. Elles incarnent plutôt des stratégies de compromis : entre performance, indépendance et exposition résiduelle.
En définitive, le choix du protocole n’est pas une question d’outil, mais de philosophie : qui choisissez-vous d’autoriser à voir votre empreinte numérique ?
La souveraineté numérique n’est pas un absolu ; elle se mesure au degré de contrôle que vous êtes prêt à céder. Connaître ces mécanismes, c’est reprendre partiellement la main sur un système conçu pour vous observer.
FAQ
Quelle est la différence principale entre DoH et DoT ?
La distinction majeure réside dans le protocole de transport et le port utilisés pour chiffrer les requêtes. Le DoT (DNS over TLS) encapsule le trafic DNS directement dans un tunnel TLS via un port dédié, tandis que le DoH (DNS over HTTPS) dissimule les requêtes DNS au sein du trafic HTTPS classique. En résumé, le DoT est un protocole réseau dédié à la sécurité, alors que le DoH est conçu pour se fondre dans le trafic web standard.
Quels ports sont utilisés par DoH et DoT ?
Le DNS over TLS (DoT) utilise le port spécifique 853, ce qui le rend facilement identifiable par les administrateurs réseau. À l’inverse, le DNS over HTTPS (DoH) utilise le port 443, le même port que celui utilisé par tout le trafic web sécurisé (HTTPS), rendant les requêtes indiscernables d’une navigation web normale.
Lequel offre la meilleure confidentialité (privacy) ?
Le DoH est souvent considéré comme supérieur pour la confidentialité de l’utilisateur final car il rend les requêtes DNS presque impossibles à distinguer des autres données HTTPS. Cela empêche les fournisseurs d’accès (FAI) ou les censeurs de bloquer ou de surveiller spécifiquement les requêtes DNS sans bloquer l’ensemble du trafic web. Le DoT, bien que chiffré, reste visible en tant que trafic DNS distinct sur le réseau.
Pourquoi les administrateurs réseau préfèrent-ils le DoT ?
Les administrateurs réseau privilégient généralement le DoT car l’utilisation d’un port dédié (853) leur permet de surveiller le trafic à des fins de sécurité et de détection de menaces (comme les malwares). Le DoH complique cette tâche car il contourne les filtres DNS traditionnels de l’entreprise et les pare-feux en se cachant dans le trafic web global.
Dois-je choisir DoH ou DoT ?
Le choix dépend de votre priorité entre discrétion et contrôle. Si vous souhaitez contourner la censure ou empêcher votre FAI de voir que vous faites des requêtes DNS, le DoH est préférable. Si vous gérez un réseau et souhaitez maintenir une visibilité sur le trafic tout en le chiffrant, ou si vous utilisez un appareil Android (qui supporte nativement le DoT), le DoT est souvent le standard recommandé.
Est-ce que ces protocoles ralentissent ma connexion ?
L’impact est généralement minime, mais le DoT peut être théoriquement plus rapide car il nécessite moins de surcharge (overhead) que le protocole HTTP utilisé par le DoH. Cependant, dans la pratique, les deux protocoles sont suffisamment rapides pour que l’utilisateur moyen ne perçoive aucune latence significative par rapport au DNS non chiffré classique (port 53).
Sources
https://www.cloudns.net/blog/understanding-dot-and-doh-dns-over-tls-vs-dns-over-https/
https://www.catchpoint.com/http2-vs-http3/dns-over-https-vs-tls
https://blog.avangarde-consulting.com/sécurité-et-performance-faut-il-adopter-le-dns-over-https
https://www.dnsfilter.com/blog/dns-over-tls
https://www.ssl.com/fr/faq/qu’est-ce-que-le-DNS-sur-https-doh/
https://www.reddit.com/r/Adguard/comments/1c2hzlu/https_or_tls/
https://www.cloudflare.com/learning/dns/dns-over-tls
https://controld.com/blog/dns-over-tls-vs-dns-over-https/
https://help.dnsfilter.com/hc/en-us/articles/4415250133779-DNS-over-TLS-vs-DNS-over-HTTPS
https://corelight.com/blog/dns-over-tls-and-dns-over-https
https://dns-over-https.org/fr/faq/
https://support.mozilla.org/fr/kb/dns-via-https-faq
https://www.cloudflare.com/fr-fr/learning/dns/dns-over-tls
https://mullvad.net/fr/help/dns-over-https-and-dns-over-tls
