Fuite DNS : quand vos requêtes sortent du tunnel

Une fuite DNS, ou DNS leakage, se produit quand vos requêtes de résolution de noms quittent le tunnel chiffré et atteignent le résolveur de votre opérateur au lieu de celui du VPN. L'historique des domaines visités reste alors lisible par un tiers, même si le trafic web est bien chiffré.

Sommaire

Ce qui fuit, et ce qui ne fuit pas

Vous montez un VPN, un site de test affiche l'adresse IP du serveur de sortie, tout paraît en ordre. Pendant ce temps, votre machine continue d'interroger le résolveur de la box pour chaque nom de domaine. Chaque visite y laisse une ligne : le nom demandé, l'heure, l'adresse qui a posé la question. Le contenu est chiffré, la table des matières ne l'est pas.

Une fuite DNS ne dit pas ce que vous lisez. Elle dit où vous allez, quand, et à quelle fréquence.

Le DNS classique circule en clair sur le port 53 (RFC 1035). N'importe quel équipement sur le chemin voit passer le QNAME, c'est-à-dire le nom demandé. Le RFC 9076, consacré aux considérations de vie privée du DNS et qui remplace le RFC 7626, décrit précisément ce risque d'observation passive. Ajoutez que le résolveur conserve généralement des journaux, et vous obtenez un historique de navigation exploitable, revendable, réquisitionnable.

Une réserve honnête : fermer la fuite DNS ne rend pas la navigation anonyme. Le champ SNI du ClientHello TLS transporte encore le nom du serveur en clair tant que l'Encrypted Client Hello n'est pas actif des deux côtés.

Les causes qu’on retrouve à chaque diagnostic

Quatre configurations couvrent la quasi-totalité des cas rencontrés.

Depuis Windows 8, et de façon plus agressive sur Windows 10, le service client DNS interroge toutes les interfaces actives en parallèle et retient la réponse arrivée en premier. Sur une machine reliée au Wi-Fi et à un tunnel, la box répond souvent avant un serveur VPN situé 30 ms plus loin. La stratégie de groupe Configuration ordinateur > Modèles d'administration > Réseau > Client DNS > Désactiver la résolution de noms multirésidente intelligente (Turn off smart multi-homed name resolution) ferme ce comportement. Sans domaine Active Directory, la clé HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient avec la valeur DWORD DisableSmartNameResolution à 1 produit le même effet.

L'IPv6 est le deuxième suspect.

Beaucoup de profils VPN ne poussent qu'une route par défaut IPv4. Si votre opérateur vous délivre un préfixe IPv6, les requêtes AAAA partent par la carte physique, et le nom demandé avec elles. Deux issues seulement : tunneliser réellement l'IPv6, ou le désactiver sur l'interface le temps de la session.

Le proxy DNS transparent d'un opérateur, lui, ne se corrige pas côté client : il intercepte et réécrit le trafic sortant sur le port 53, quel que soit le serveur que vous déclarez. Basculer en DoT (port 853, RFC 7858) ou en DoH (port 443, RFC 8484) le contourne, puisque l'interception ne porte que sur le port 53.

Cause	Mécanisme	Signe visible
Résolution multi-interfaces Windows	La requête part sur toutes les cartes actives, la première réponse gagne	Le résolveur du FAI apparaît un test sur deux
IPv6 non tunnelisé	Le VPN ne route que l'IPv4, les requêtes AAAA sortent en natif	Un résolveur en 2a01: ou 2001: dans le résultat
Proxy DNS transparent du FAI	Le port 53 sortant est intercepté et réécrit	Changer de résolveur ne change rien au résultat
DNS sécurisé du navigateur	Firefox ou Chrome parlent en DoH à leur propre fournisseur	Le test du navigateur diffère du test système

Diagnostiquer en ligne de commande

Les sites de test répondent à une question précise : quel résolveur a contacté le serveur autoritaire. C'est utile, mais ils mesurent le comportement du navigateur, pas celui du système. Un client mail, un agent de supervision ou un conteneur peuvent fuir pendant que la page de test affiche un résultat propre.

Un cas de panne classique, et parfaitement silencieux.

Un conteneur Docker attaché à un réseau utilisateur interroge le résolveur embarqué en 127.0.0.11, qui relaie vers les serveurs lus dans le /etc/resolv.conf de l'hôte au moment du démarrage. Montez le tunnel après avoir lancé la pile et les conteneurs continuent d'utiliser le résolveur de l'opérateur jusqu'au prochain redémarrage. Aucun journal applicatif ne le signale. Le correctif tient en une ligne dans le compose : une directive dns: pointant vers le résolveur du VPN, ou un simple redémarrage de la pile une fois la connexion établie.

dig +short TXT whoami.ds.akahelp.net : renvoie l'adresse du résolveur qui a réellement interrogé l'autorité Akamai, plus un champ ecs s'il y en a un
dig @1.1.1.1 +short TXT CH whoami.cloudflare : renvoie l'adresse vue par Cloudflare, à comparer avec l'IP de sortie du VPN
resolvectl status sous Linux avec systemd-resolved : affiche le résolveur rattaché à chaque lien et les domaines routés vers lui
scutil --dns sous macOS : liste les résolveurs par ordre de service, le tunnel doit occuper la position resolver #1
Get-DnsClientServerAddress sous Windows : donne les serveurs déclarés interface par interface, y compris celles que vous aviez oubliées

Fermer la fuite, système par système

L'ordre des corrections compte plus que l'outil choisi.

Commencez par forcer un résolveur unique, joignable uniquement à travers le tunnel. Avec systemd-resolved, la commande resolvectl domain tun0 '~.' route l'ensemble des requêtes vers le lien du VPN et retire aux autres interfaces le droit de répondre. Contrôlez ensuite avec resolvectl status qu'aucune ligne DNS Servers ne mentionne encore l'adresse de la passerelle locale.

Sur macOS, tout se vérifie avec scutil --dns, suivi d'un vidage de cache par sudo killall -HUP mDNSResponder.

Sur Windows, ajoutez à la désactivation de la résolution multirésidente une seconde clé : DisableParallelAandAAAA à 1 dans HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters, qui empêche l'envoi simultané des requêtes A et AAAA. Redémarrez le service Dnscache, puis relancez le test. Si le résolveur affiché change encore d'un essai à l'autre, une interface reste en course.

Dernier point, souvent négligé : le kill switch. Sans lui, chaque reconnexion du tunnel ouvre une fenêtre de quelques secondes pendant laquelle tout repart en clair, résolution comprise.

Trois problèmes qu’on confond avec la fuite DNS

Le détournement DNS n'est pas une fuite. Un attaquant ou un opérateur y modifie la réponse pour vous envoyer ailleurs, par empoisonnement de cache ou par changement des serveurs déclarés sur le routeur. La fuite, elle, laisse la réponse intacte et se contente d'exposer la question.

La fuite WebRTC ne touche pas au DNS du tout.

Elle vient du navigateur, qui expose à une page les adresses locales et publiques de ses candidats ICE. Le résultat se ressemble, votre adresse réelle apparaît, mais le mécanisme n'a aucun rapport et le correctif non plus.

Reste le cas EDNS Client Subnet (RFC 7871). Votre résolveur public transmet aux serveurs autoritaires une partie de votre adresse pour aider les CDN à choisir un point de présence proche. Google Public DNS envoie par défaut un préfixe /24 en IPv4, Cloudflare n'envoie pas d'ECS. Ce n'est pas un DNS leak au sens strict, mais c'est bien une information de localisation qui sort du tunnel, et elle s'affiche dans le champ ecs du test Akamai cité plus haut.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Sur Windows, quel comportement provoque le plus souvent une fuite DNS ?

Questions fréquentes

Comment vérifier une fuite DNS sans installer d’outil ?

Lancez dig +short TXT whoami.ds.akahelp.net et comparez l'adresse renvoyée avec l'IP de sortie de votre VPN. Si le résultat correspond à un préfixe de votre opérateur, la requête est sortie du tunnel. Répétez le test plusieurs fois : sur Windows, la fuite est intermittente par nature.

La navigation privée protège-t-elle d’un DNS leak ?

Non. Le mode privé empêche l'enregistrement local de l'historique et des cookies, il ne modifie pas la route empruntée par les requêtes de résolution. Le résolveur voit exactement les mêmes noms que dans une fenêtre normale.

Mon VPN annonce une protection anti-fuite DNS, est-ce suffisant ?

Généralement oui pour l'IPv4, rarement pour le reste. Testez séparément l'IPv6, le DoH du navigateur et les processus qui ne passent pas par la pile réseau habituelle, conteneurs en tête. Une protection qui ne s'active qu'après la connexion laisse aussi passer les requêtes émises pendant l'établissement du tunnel.

Faut-il activer le DNS sécurisé de Firefox ou Chrome avec un VPN ?

Cela dépend de qui vous voulez tenir à l'écart. Le DoH du navigateur court-circuite le résolveur poussé par le VPN et envoie vos requêtes à Cloudflare, NextDNS ou un autre fournisseur choisi par l'éditeur. Ce n'est pas une fuite vers votre opérateur, c'est un déplacement de la confiance. Si votre VPN fournit son propre résolveur, désactivez le DoH du navigateur ou pointez-le vers le même fournisseur.

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

À l'opérateur du résolveur, oui : il voit votre adresse source et les noms demandés. Aux sites visités, pas directement, puisque la connexion arrive bien par le VPN. L'exception vient d'EDNS Client Subnet, qui peut transmettre un préfixe de votre adresse jusqu'aux serveurs autoritaires.