Fuite DNS : pourquoi vos requêtes sortent du tunnel

Une fuite DNS, c'est une requête de résolution qui part vers un autre résolveur que celui prévu : votre fournisseur d'accès voit alors les noms de domaine visités, même quand le trafic HTTPS passe correctement dans le tunnel VPN. La plupart des cas tiennent à trois causes : IPv6 non tunnellisé, résolution parallèle multi-interface de Windows, et résolveur codé en dur dans un appareil ou une application.

Sommaire

Ce qui sort du tunnel, et ce qui n’en sort pas

Vous êtes connecté à un VPN, le site de test affiche bien l'adresse IP du serveur de sortie, et pourtant votre FAI sait que vous avez consulté tel domaine. C'est une fuite DNS. Le trafic applicatif emprunte le tunnel ; la question posée juste avant lui, celle qui traduit whoisip.fr en adresse IP, est partie ailleurs.

Le DNS historique (RFC 1034 et 1035) circule en clair sur le port 53, en UDP la plupart du temps, en TCP quand la réponse dépasse la taille annoncée. Le résolveur qui reçoit la requête enregistre trois choses : l'adresse IP source, l'horodatage et le nom demandé. Cela suffit à reconstituer un historique de navigation assez fidèle sans déchiffrer la moindre page.

La fuite ne révèle pas le contenu. Elle révèle la destination, et c'est généralement ce qui intéresse un observateur.

À noter au passage : le nom de domaine transite aussi en clair dans le champ SNI du handshake TLS, sauf si le serveur et le navigateur négocient ECH. Corriger la résolution sans faire passer le reste du trafic dans un tunnel ne masque donc pas vos destinations vis-à-vis du réseau local.

Les causes, de la plus fréquente à la plus rare

Une fuite n'est presque jamais un défaut de chiffrement. C'est un problème de routage ou de politique de résolution du système d'exploitation, deux couches que le client VPN ne contrôle pas toujours complètement.

IPv6 oublié : le client pousse une route par défaut 0.0.0.0/0 mais pas ::/0. La machine a reçu une adresse IPv6 globale par SLAAC, elle interroge le résolveur annoncé sur le lien local pour les enregistrements AAAA, hors tunnel.
Résolution multi-interface de Windows : depuis Windows 8, le client DNS interroge en parallèle toutes les interfaces actives et retient la réponse la plus rapide. La carte Wi-Fi et l'interface du tunnel partent ensemble, le résolveur du FAI est plus proche, il gagne la course souvent.
systemd-resolved et ses domaines de routage : si le lien du VPN ne réclame pas le domaine catch-all ~., les requêtes continuent de partir vers les serveurs déclarés sur l'interface physique.
Résolveur codé en dur : certains appareils ignorent le serveur DHCP et pointent vers 8.8.8.8 en dur, un Chromecast typiquement. Même chose pour une application qui embarque son propre client DoH.
Portail captif et split tunneling : le premier réécrit temporairement la configuration DNS, le second exclut délibérément des applications du tunnel, DNS compris.

Cause	Symptôme observé	Où regarder
IPv6 hors tunnel	Fuite sur les AAAA seulement, jamais sur les A	ip -6 route show, présence d'une route ::/0 via le lien physique
Windows multi-homed	Fuite intermittente, une requête sur cinq	Get-DnsClientServerAddress sur chaque carte
Domaine de routage manquant	Toutes les requêtes fuient, IPv4 comprise	resolvectl status, ligne DNS Domain du lien du tunnel
Résolveur en dur	Un seul appareil fuit, les autres non	Journal du pare-feu sur le port 53 sortant

Tester sans passer par un site de test

Le principe tient en une idée : faire dire à un serveur autoritatif quelle adresse IP l'a réellement contacté. Cette adresse est celle de votre résolveur récursif, pas la vôtre. Si elle appartient au réseau de votre FAI alors que le VPN est actif, la fuite est confirmée.

Rejouez le test cinq ou six fois de suite. Sur Windows, la résolution parallèle est une course : une seule réponse sur plusieurs peut suffire à trahir, et un test unique renvoie facilement un faux négatif rassurant.

Système	Commande	Ce que vous lisez
Linux, macOS	dig +short whoami.akamai.net	L'adresse IP publique du résolveur qui a posé la question
Tous	dig +short -t txt o-o.myaddr.l.google.com @ns1.google.com	L'IP vue par Google, plus le préfixe ECS s'il est transmis
Linux avec systemd	resolvectl status	Les serveurs DNS lien par lien et le domaine de routage actif
macOS	scutil --dns	L'ordre des résolveurs et leur portée par interface
Windows	Resolve-DnsName whoami.akamai.net	Même résultat que dig, sans installer BIND utils

Corriger selon le système

Sur Windows, la valeur DWORD DisableSmartNameResolution à 1 dans HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient désactive la résolution parallèle. L'équivalent en stratégie de groupe se trouve sous Configuration ordinateur, Modèles d'administration, Réseau, Client DNS. Le réglage a perdu de sa fiabilité au fil des versions de Windows 10 : vérifiez toujours son effet avec le test précédent plutôt que de le supposer appliqué.

Sur une distribution Linux qui utilise systemd-resolved, deux commandes règlent le cas classique après montée du tunnel : resolvectl dns tun0 10.8.0.1 pour déclarer le résolveur interne, puis resolvectl domain tun0 '~.' pour que ce lien capte toutes les requêtes. Sans le second, le premier ne sert presque à rien.

Pour IPv6, choisissez franchement. Soit le VPN route ::/0 et pousse un résolveur IPv6, soit vous désactivez la pile avec net.ipv6.conf.all.disable_ipv6=1. Le demi-choix, IPv6 actif sur le LAN et absent du tunnel, est exactement la configuration qui fuit.

La seule parade qui tienne quel que soit le coupable reste le pare-feu. Bloquez le port 53 en sortie, UDP et TCP, sur toutes les interfaces sauf celle du tunnel. Un appareil qui code son résolveur en dur ne se corrige pas autrement : sur le routeur, une redirection NAT du port 53 vers votre propre résolveur force le trafic à revenir chez vous, que l'appareil le veuille ou non.

Ce que « fuite DNS » ne désigne pas

La fuite WebRTC est un autre problème. Le navigateur, via STUN, expose les adresses IP locales et publiques de la machine à une page web. Un testeur en ligne qui affiche 192.168.1.20 mesure WebRTC, pas la résolution de noms.

Le détournement DNS, ou DNS hijacking, désigne un résolveur qui répond faux : redirection vers une page de parking, blocage réglementaire, empoisonnement. La fuite, elle, produit une réponse correcte, mais fournie par le mauvais interlocuteur.

DNSSEC (RFC 4033 à 4035) signe les réponses, il ne les chiffre pas. Un domaine parfaitement signé fuit exactement comme les autres. Pour la confidentialité du transport, les protocoles sont DoT sur le port 853 (RFC 7858), DoH sur le port 443 (RFC 8484) et DoQ (RFC 9250). Android propose DoT en natif depuis la version 9 sous l'intitulé DNS privé.

Dernier point, souvent ignoré : même sans fuite, EDNS Client Subnet (RFC 7871) autorise votre résolveur à transmettre un préfixe de votre adresse aux serveurs autoritatifs pour améliorer le routage CDN. Certains résolveurs publics s'en abstiennent, d'autres non. Le test o-o.myaddr.l.google.com affiche ce préfixe quand il est envoyé.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Sur quel port le DNS non chiffré circule-t-il par défaut ?

Questions fréquentes

Mon client VPN annonce une protection contre les fuites DNS, est-ce suffisant ?

Pas toujours. Cette mention couvre en général le cas IPv4 simple. Testez vous-même avec le tunnel actif, puis coupez brutalement la connexion réseau et relancez le test : beaucoup de clients laissent passer des requêtes pendant la fenêtre de reconnexion, quelques secondes qui suffisent à révéler les domaines demandés.

Les sites de test en ligne sont-ils fiables ?

Ils font le travail pour un diagnostic rapide, en interrogeant des sous-domaines uniques dont ils lisent les serveurs de logs. Deux limites : ils testent depuis le navigateur, donc pas la configuration système utilisée par vos autres applications, et un seul passage rate les fuites intermittentes. dig depuis un terminal reste plus représentatif.

DNS over HTTPS règle-t-il le problème ?

Il chiffre la requête et empêche votre FAI de la lire au passage, ce qui traite le symptôme le plus gênant. Mais il déplace la confiance vers le fournisseur DoH, et un navigateur qui active son propre DoH court-circuite le résolveur poussé par le VPN, ce qui peut aussi casser la résolution des noms internes de votre réseau d'entreprise.

La navigation privée empêche-t-elle une fuite DNS ?

Non. Le mode privé n'agit que sur ce que le navigateur conserve localement : historique, cookies, cache. Les requêtes DNS partent du système, empruntent le même chemin qu'en session normale et sont vues par le même résolveur.

Une fuite DNS révèle-t-elle mon adresse IP réelle ?

Elle la révèle à votre résolveur, qui est celui de votre FAI et connaît déjà votre ligne. Le risque se situe ailleurs : l'opérateur du domaine consulté voit arriver une requête depuis un résolveur d'un opérateur français pendant que sa connexion HTTPS provient d'un serveur VPN étranger. Le recoupement des horodatages annule une bonne partie de l'anonymat recherché.