DNS : le maillon que personne ne durcit

Audit réseau d’une PME industrielle, une matinée. Je branche une sonde passive sur le port miroir du switch principal et je regarde passer le trafic. Tout est en HTTPS, le DRH est fier de son pare-feu neuf à 18 000 €. Sauf que sur le port 53, en clair, défile la navigation complète de l’entreprise : le domaine du cabinet d’avocats consulté la veille, le site de l’acquéreur potentiel, la banque, le médecin du travail, le concurrent. En vingt minutes, j’ai reconstitué un dossier M&A confidentiel sans déchiffrer une seule connexion. Le DNS m’a tout donné.

Le piège habituel

Tout le monde a intégré que HTTPSVersion sécurisée de HTTP, qui chiffre la communication entre navigateur et serveur via TLS.Voir le lexique protège. Le cadenas vert, le « s » dans la barre d’adresse, la formation interne qui répète « vérifiez que le site est en HTTPS » : le réflexe est acquis. Et il est juste — le contenu de vos échanges est bien chiffré entre votre navigateur et le serveur. Le problème, c’est que ce réflexe s’arrête exactement là où il devrait commencer à se poser des questions. Personne ne se demande ce qui se passe avant la connexion HTTPS. Et avant, il y a le DNSSystème qui résout les noms de domaine en adresses IP. Vecteur de surveillance et de censure très sous-estimé.Voir le lexique.

Avant que votre navigateur ouvre une connexion chiffrée vers messagerie-banque.fr, il doit traduire ce nom en adresse IP. Cette traduction, dans la configuration par défaut de pratiquement tous les appareils de la planète, part en clair, sur le port 53, vers le résolveur de votre FAISystème qui résout les noms de domaine en adresses IP. Vecteur de surveillance et de censure très sous-estimé.Voir le lexique ou de votre opérateur mobile. Pas de chiffrement, pas d’authentification, pas de confidentialité. C’est le protocole de 1987, et c’est encore le défaut en 2026. Le contenu de votre échange avec la banque est protégé. Le fait que vous parliez à cette banque, à quelle heure, combien de fois, depuis quel appareil : visible par tout le monde sur le chemin.

Le discours dominant sur la « sécurité réseau » entretient ce trou. On vend des pare-feux nouvelle génération, des passerelles web, des solutions d’inspection de trafic à cinq chiffres, pendant que le canal de fuite le plus élémentaire reste grand ouvert. Pire : beaucoup de ces équipements forcent le DNS à passer par eux en clair, sous prétexte de « visibilité ». Le réflexe « j’ai HTTPS, je suis tranquille » est devenu un angle mort collectif. Le DNS est le maillon que personne ne durcit parce que personne ne le regarde — et c’est précisément ce qui en fait un vecteur de surveillance aussi rentable pour qui sait écouter.

Modèle de menace réel : ce que le DNS révèle, et à qui

Pensez au DNS comme à l’annuaire d’internet. Chaque fois qu’un appareil veut joindre un service, il interroge un résolveur : « quelle est l’adresse de ce domaine ? » Cette question, répétée des milliers de fois par jour et par appareil, dessine un portrait d’une précision redoutable. Pas le contenu — l’intention. Et l’intention suffit largement.

En DNS non chiffré, voici ce qui est lisible par quiconque écoute : chaque domaine que vous visitez, l’horodatage exact, la fréquence. Ce ne sont pas seulement les sites que vous ouvrez à la main dans le navigateur. Vos applications mobiles font des requêtes DNS en permanence — votre client mail interroge le serveur toutes les minutes, votre messagerie chiffrée résout son domaine de relais, vos objets connectés appellent leur cloud, vos mises à jour automatiques contactent leurs serveurs. Le DNS trahit la liste de vos applications, vos habitudes de sommeil (l’heure de la première requête le matin), vos rythmes de travail, les services bancaires et médicaux que vous utilisez, parfois votre localisation implicite via le choix des résolveurs régionaux et des CDNSystème qui résout les noms de domaine en adresses IP. Vecteur de surveillance et de censure très sous-estimé.Voir le lexique.

Qui voit ces données ? Trois acteurs, au minimum. Votre FAI ou opérateur mobile d’abord, qui opère le résolveur par défaut — en France et dans toute l’Union, les métadonnées de connexion sont conservées légalement pendant un an, et plusieurs FAI exploitent commercialement ces données ou redirigent les domaines inexistants vers leurs propres pages de pub. Ensuite, quiconque écoute sur le réseau local : le Wi-Fi de l’hôtel, le café, l’aéroport, la salle de conférence, là où vous ne contrôlez rien et où le port 53 passe en clair sous le nez de tous les autres clients. Enfin, votre résolveur lui-même, quel qu’il soit — choisir un résolveur, c’est choisir à qui vous confiez l’intégralité de votre historique de navigation.

Il y a une subtilité que les gens oublient. Même quand vous chiffrez le DNS, la poignée de main TLSProtocole de chiffrement de transport, base de HTTPS et de la sécurité web moderne.Voir le lexique contient encore le Server Name Indication (SNI) en clair — le nom du domaine, visible pour tout observateur réseau. Le mécanisme Encrypted Client Hello (ECH), standardisé via la RFC 9460, chiffre ce SNI, mais son déploiement reste partiel en 2026 et dépend du fait que le site cible le supporte côté serveur. Autrement dit : durcir le DNS est nécessaire, mais ce n’est qu’une partie du tableau. Le DNS demeure néanmoins le vecteur de fuite le plus large, le plus systématique et le plus simple à colmater.

Un autre point que je dois marteler en audit, parce qu’il revient sans cesse : le DNS en clair n’est pas seulement un problème de confidentialité, c’est aussi un problème d’intégrité. Sur le port 53 non authentifié, n’importe quel acteur sur le chemin réseau peut répondre à votre place — c’est le DNS spoofing. Vous demandez l’adresse de votre banque, un attaquant sur le Wi-Fi de l’hôtel répond avec l’IP de son serveur de phishing, et votre navigateur ira docilement chez lui. HTTPS et la validation de certificat rattrapent une partie du coup (le faux site n’aura pas le bon certificat), mais pas toujours, et pas pour les nombreux flux qui ne valident pas strictement le certificat. Chiffrer et authentifier le DNS ferme cette porte en même temps qu’il ferme l’écoute. Deux problèmes, une seule mesure.

Et il faut sortir de l’idée que « ça ne me concerne pas, je n’ai rien à cacher ». Le modèle de menace réel n’est pas « quelqu’un lit mes recherches Google ». C’est un agrégat : votre opérateur revend un profil comportemental, un courtier en données le croise avec d’autres sources, un assureur ou un employeur potentiel l’achète, un État le réquisitionne, ou un attaquant ciblé reconstitue vos habitudes pour préparer un spear phishingPhishing ciblé sur une personne précise, construit à partir de son profil OSINT.Voir le lexique crédible. La requête DNS isolée est anodine. Le flux DNS complet sur six mois est un dossier.

La bonne approche : Do53, DoT, DoH, et le bon résolveur

La bascule est l’une des plus rentables de toute la sécurité opérationnelle : peu d’effort, effet immédiat, gratuit dans la majorité des cas. Mais il faut comprendre les trois modes pour ne pas se tromper de combat.

Do53 — le DNS classique, port 53, en clair. C’est le défaut sur tous vos appareils. Aucun chiffrement, aucune authentification de la réponse. Votre résolveur voit vos requêtes en clair, et n’importe quel équipement sur le chemin réseau aussi. C’est ce que vous voulez quitter.

DoTVariante de DoH utilisant TLS direct au lieu de HTTPS.Voir le lexique — DNS over TLS, port 853. Les requêtes sont chiffrées dans un tunnel TLS dédié, défini par la RFC 7858. Personne ne peut plus les lire en transit. L’inconvénient : le port 853 est identifiable comme « trafic DNS chiffré ». Un équipement réseau hostile peut le bloquer, ce qui force certains systèmes à rebasculer en clair sur le port 53. C’est le mode natif et le plus propre sur mobile (le « DNS privé » d’Android), parce qu’il s’applique au système entier.

DoHProtocole qui chiffre les requêtes DNS dans du HTTPS, les masquant au FAI.Voir le lexique — DNS over HTTPS, port 443. Les requêtes sont encapsulées dans du trafic HTTPS standard, selon la RFC 8484. Double avantage : le chiffrement, et surtout l’indistinguabilité — vos requêtes DNS ressemblent à n’importe quelle connexion web. Bloquer DoH sans casser tout le trafic HTTPS est extrêmement difficile, ce qui en fait l’arme de choix contre la surveillance réseau active. C’est le mode privilégié dans le navigateur et dans les contextes où le réseau local est hostile.

Ne confondez pas tout ça avec DNSSEC, qui revient souvent dans la discussion. DNSSEC signe cryptographiquement les réponses DNS — il garantit l’intégrité (la réponse n’a pas été falsifiée en route), mais ne chiffre rien. DNSSEC et DoH/DoT sont complémentaires, pas concurrents : l’un protège contre la falsification, les autres contre l’écoute.

Une fois le mode choisi, reste la vraie décision : le résolveur. C’est l’entité qui fait les requêtes réelles pour vous, donc celle qui voit tout. En changer est l’action la plus impactante pour le moindre effort.

• Quad9Système qui résout les noms de domaine en adresses IP. Vecteur de surveillance et de censure très sous-estimé.Voir le lexique (9.9.9.9) — opéré par une fondation suisse à but non lucratif, politique no-logs documentée, filtrage des domaines malveillants actif par défaut (base de menaces agrégée), support DoH et DoT. Mon choix par défaut pour qui veut de la sécurité sans configuration. Si je devais recommander un seul résolveur à quelqu’un qui ne veut rien régler, c’est celui-là.
• Mullvad DNS — orienté confidentialité pure. Si vous utilisez déjà Mullvad VPN, le DNS passe dans le tunnel. Mullvad propose aussi des résolveurs publics utilisables seuls, avec variantes filtrant pub et tracking. Pas de filtrage de sécurité par défaut : choix de privacy, pas de sécurité.
• NextDNSSystème qui résout les noms de domaine en adresses IP. Vecteur de surveillance et de censure très sous-estimé.Voir le lexique — le configurable. Vous créez un profil : blocage pub, tracking, malware, catégories. Logs optionnels — activables pour auditer votre trafic, désactivables totalement. Freemium : 300 000 requêtes/mois gratuites, puis environ 2 €/mois. Excellent pour les familles et les PME qui veulent de la visibilité maîtrisée.
• CloudflareSystème qui résout les noms de domaine en adresses IP. Vecteur de surveillance et de censure très sous-estimé.Voir le lexique (1.1.1.1) — le plus rapide en latence, claim no-logs partiellement audité. Réserve : Cloudflare est une megacorp américaine qui héberge déjà une fraction massive du web. Leur visibilité sur les flux est colossale. Acceptable pour le grand public, moins pour qui veut éviter la concentration de risque chez un seul acteur soumis au droit américain.
• FAI par défaut — à fuir. Profilage commercial, redirections publicitaires, conservation légale. C’est exactement le résolveur que vous voulez quitter.
• Self-hosted (Unbound + Pi-hole) — contrôle total. Unbound résout en récursif directement auprès des serveurs racine, sans tiers. Pi-hole filtre localement pub et tracking pour tout le réseau. Vous portez la maintenance, et ça ne vous suit pas en mobilité (sauf VPN retour). Le bon choix pour le domicile durci, pas pour le voyage.

Un mot sur le self-hosted, parce que c’est là que les gens se font le plus d’illusions. Pi-hole est un résolveur local qui consulte des listes de blocage : quand un appareil demande l’IP de doubleclick.net ou d’un domaine de télémétrie, Pi-hole répond « NXDOMAIN » et la connexion ne se fait jamais. C’est puissant — ça bloque pub et tracking au niveau réseau pour tous les appareils, y compris la SmartTV, la console et les objets connectés qu’on ne peut configurer individuellement, et ça vous donne une visibilité complète sur ce que chaque appareil appelle. Mais Pi-hole, seul, ne chiffre rien. Tout ce qu’il ne bloque pas part en clair vers votre FAI. La combinaison qui tient debout, c’est Pi-hole pour le filtrage, Unbound derrière pour la résolution récursive directe, et un upstream chiffré (DoT) pour les requêtes qui sortent quand même. Plus complexe à monter, mais c’est le seul montage qui vous donne à la fois filtrage, confidentialité et contrôle. Et gardez en tête que certaines apps en DoH codé en dur (Firefox, certains services Google) contournent purement et simplement Pi-hole — le filtrage réseau a ses limites face aux applications qui décident de leur propre résolveur.

Ce que ça implique concrètement

Erreurs qu’on voit tout le temps

• Configurer DoH dans le navigateur seulement. Partiel par construction. Le client mail, les apps mobiles, les services système et les objets connectés continuent avec le résolveur en clair par défaut. On coche une case et on se croit couvert pour 100 % du trafic alors qu’on en couvre une fraction.
• Croire que Pi-hole chiffre les requêtes. Pi-hole filtre, il ne chiffre pas. Sans upstream DoHProtocole qui chiffre les requêtes DNS dans du HTTPS, les masquant au FAI.Voir le lexique ou DoTVariante de DoH utilisant TLS direct au lieu de HTTPS.Voir le lexique configuré, tout ce que Pi-hole ne bloque pas — soit la grande majorité — part en clair vers votre FAI. Pi-hole sans upstream chiffré, c’est du filtrage publicitaire, pas de la confidentialité.
• Oublier le DNS en voyage. Une config DoH posée à la maison ne s’applique pas sur la 4G ou le Wi-Fi d’hôtel si elle vit seulement dans le navigateur. À l’étranger, c’est le résolveur de l’opérateur local qui reprend la main. Seul le DNS au niveau système (profil iOS, DNS privé Android) voyage avec vous.
• Laisser le SMS ou le FAI comme résolveur « parce que ça marche ». Ça marche, oui, et c’est exactement le problème : ça marche tout en exposant votre navigation complète à un acteur qui la conserve un an et l’exploite commercialement.
• Ne jamais tester. Beaucoup pensent être en DoH et fuient en réalité vers le résolveur du FAI. dnsleaktest.com(opens in a new tab) et ipleak.net(opens in a new tab) tranchent la question en dix secondes. Une config DNS non vérifiée est une hypothèse, pas une protection.

Checklist actionnable

• N1 Activer DoH ou DoT au niveau système sur tous vos appareils, pas seulement dans le navigateur
• N1 Choisir Quad9 (9.9.9.9) pour la sécurité, ou Mullvad/NextDNS selon le besoin de confidentialité ou de visibilité
• N1 Vérifier l'absence de DNS leak avec dnsleaktest.com après chaque changement
• N2 Sur iOS 14+ : installer le profil DNS NextDNS ou Cloudflare (Réglages > Profil DNS)
• N2 Sur Android 9+ : activer le DNS privé (DoT) dans Paramètres > Réseau et Internet
• N2 Vérifier que le DNS du voyage tient au niveau système, pas seulement dans le navigateur
• N2 Au domicile : Pi-hole pour le filtrage + Unbound en résolution récursive + upstream chiffré
• N3 En entreprise : résolveur DNS interne avec logging (Umbrella, NextDNS Business, Infoblox) branché au SIEM
• N3 En entreprise : désactiver le DoH applicatif sauvage par GPO/MDM, imposer le résolveur maîtrisé comme point de chiffrement unique
• N3 Suivre le taux de requêtes passant par le résolveur maîtrisé (> 98 %) et le délai de détection des domaines malveillants

Pour aller plus loin

Les références normatives sont dans le frontmatter : la RFC 8484 spécifie DoH, la RFC 7858 spécifie DoT, et la RFC 9460 décrit le chiffrement du SNI via ECH qui complète le tableau. Côté résolveurs, les politiques de confidentialité de Quad9 et NextDNS détaillent exactement ce qui est journalisé — lisez-les avant de confier votre historique à qui que ce soit.

Le DNS n’est qu’une pièce du durcissement réseau. Pour comprendre ce qu’un VPN protège vraiment et ce qu’il ne touche pas — y compris le piège du DNS leak hors tunnel —, voir VPN : 95 % du marketing est faux. Pour les réseaux non maîtrisés où le DNS en clair est le plus exposé, lisez Wi-Fi public : le vrai risque. Et pour appliquer ce durcissement au niveau du système d’exploitation plutôt que d’application par application, voir Durcir son OS.