En résumé : un tunnel VPN chiffre les paquets IP que votre appareil envoie aux autres serveurs. DNS est la résolution qui se produit avant l'envoi du paquet — votre appareil demandant « quelle adresse IP correspond à example.com ? » Si cette résolution aboutit au résolveur de votre FAI plutôt que de passer par le VPN, alors votre FAI voit le domaine même s'il ne voit jamais le trafic chiffré qui suit. C'est une fuite. Elle annule la promesse de confidentialité fondamentale d'un VPN pour la raison la plus simple qui soit : le mauvais résolveur DNS a été interrogé. La bonne nouvelle, c'est que les fuites sont faciles à détecter, généralement faciles à corriger, et que la plupart des applications VPN correctement conçues les préviennent par défaut. La mauvaise nouvelle, c'est que « la plupart » ne signifie pas « toutes », et que quelques configurations courantes provoquent des fuites même sur des configurations VPN par ailleurs correctes.
Ce que DNS fait réellement et pourquoi il fuit
DNS — le Domain Name System — est le carnet d'adresses d'internet. Chaque fois que votre appareil se connecte à un site web, il doit d'abord traduire le nom d'hôte lisible par un humain (example.com) en une adresse IP numérique (quelque chose comme 93.184.216.34) que les routeurs peuvent effectivement acheminer. Cette étape de traduction est une requête DNS, et c'est une opération réseau distincte de la requête web réelle qui la suit.
Sur une connexion domestique classique, votre résolveur DNS est attribué par votre FAI via DHCP — le même mécanisme qui distribue votre adresse IP. Lorsque vous vous connectez au Wi-Fi, le routeur indique à votre appareil « votre serveur DNS est 192.168.1.1, qui transfère vers le résolveur récursif de votre FAI ». Chaque domaine que vous résolvez transite par ce résolveur. Le FAI peut le journaliser, le vendre à un courtier en données (aux États-Unis, c'est légal) ou le transmettre aux autorités.
Lorsque vous connectez un VPN, deux choses doivent se produire. D'abord, votre trafic réseau est chiffré et acheminé via le tunnel VPN. Ensuite, votre résolveur DNS doit changer — du résolveur du FAI vers un résolveur opéré par le fournisseur VPN (ou un résolveur public axé sur la confidentialité), accessible uniquement via le tunnel chiffré. Si seule la première partie se produit, vous avez une fuite DNS. Le trafic est chiffré, mais les résolutions qui précèdent le trafic continuent d'atteindre le FAI, lui révélant chaque site que vous êtes sur le point de visiter.
Du point de vue de la confidentialité, la requête DNS est presque aussi révélatrice que le trafic lui-même. La requête révèle le domaine exact (jusqu'au sous-domaine — mail.example.com se distingue de www.example.com) et l'horodatage. Combinées avec le volume de trafic chiffré qui suit immédiatement, les métadonnées d'un VPN qui fuit permettent à un observateur de reconstituer votre session de navigation dans presque tous les sens importants.
Les quatre façons dont une fuite DNS se produit
Les fuites DNS ne sont pas un seul bug. C'est une famille de mauvaises configurations connexes, chacune avec une cause racine différente et un correctif différent. Par ordre de fréquence approximatif :
1. Contournement par l'OS — DNS fractionné Windows / Smart Multi-Homed Name Resolution
Windows dispose d'une fonctionnalité appelée Smart Multi-Homed Name Resolution qui, lorsqu'elle est activée, envoie des requêtes DNS en parallèle à tous les résolveurs DNS disponibles — y compris le résolveur du FAI sur l'interface physique, même lorsqu'un VPN est actif. Le résolveur qui répond le plus vite gagne, et les autres sont ignorés, mais les requêtes elles-mêmes ont déjà été envoyées. Sur la plupart des machines Windows, cette fonctionnalité est activée par défaut. Le correctif consiste à la désactiver via la stratégie de groupe ou en configurant le client VPN pour le faire lors de la connexion. Linux présente un problème similaire avec systemd-resolved si ce n'est pas configuré correctement ; macOS et iOS gèrent cela mieux mais pas parfaitement.
2. Mauvaise configuration du tunnel fractionné
Le tunnel fractionné vous permet d'acheminer certaines applications via le VPN et d'autres via votre connexion normale. Une erreur de configuration courante consiste à mettre en place un tunnel fractionné basé sur les applications sans configurer également le DNS par application — ce qui signifie qu'une application acheminée hors du tunnel VPN tente quand même d'utiliser le résolveur DNS du VPN, ou vice versa, et finit par fuiter via le chemin que l'OS fournit. Une variante pire : le tunnel fractionné achemine correctement le trafic TCP de l'application hors du tunnel, mais le résolveur DNS à l'échelle du système est toujours celui du FAI, de sorte que chaque application — tunnelisée ou non — fait fuiter ses requêtes DNS vers le FAI. Nous abordons le sujet plus en détail dans notre article sur ce que fait réellement le tunnel fractionné.
3. Repli IPv6
De nombreux clients VPN ont été conçus à une époque où IPv4 était le seul souci de routage. Ils installent des règles de pare-feu et de routage IPv4 qui acheminent correctement DNS via le tunnel, mais n'installent pas de règles IPv6 correspondantes. Si votre réseau dispose d'une connectivité IPv6, l'OS préférera parfois IPv6 pour les requêtes DNS — et ces requêtes sortent par l'interface non protégée, contournant entièrement le VPN. C'est l'un des modes de fuite les plus courants en 2026, particulièrement fréquent sur les connexions haut débit résidentielles disposant d'une double pile IPv4/IPv6 du FAI. Le correctif consiste soit à désactiver IPv6 globalement (radical mais fiable), soit à utiliser un client VPN qui gère explicitement les routes IPv6.
4. WebRTC et DNS résolu par le navigateur
Les navigateurs modernes — Chrome, Edge, Firefox, Safari — peuvent effectuer des résolutions DNS eux-mêmes plutôt que d'utiliser le résolveur de l'OS. Le cas le plus notoire est WebRTC, le protocole pair-à-pair utilisé pour la vidéoconférence. WebRTC utilise des serveurs STUN pour découvrir vos adresses IP locales et publiques réelles, et diffusait historiquement les deux même lorsqu'un VPN était actif. L'IP « réelle » via WebRTC a longtemps été une fuite côté navigateur nécessitant une atténuation explicite. Par ailleurs, les navigateurs utilisant DNS-over-HTTPS (DoH) peuvent acheminer les requêtes DNS directement vers Cloudflare, Google ou NextDNS indépendamment du paramètre de résolveur de l'OS — ce qui aide parfois (DoH vers un résolveur public est plus privé que du texte clair vers le FAI) et nuit parfois (le résolveur public voit toujours vos requêtes, et le navigateur contourne les règles DNS du VPN).
Comment tester une fuite DNS en moins d'une minute
Tester une fuite DNS prend plus de temps à décrire qu'à faire. Connectez votre VPN, puis visitez l'un de ces trois outils. Chacun révèle des aspects légèrement différents de la surface de fuite.
dnsleaktest.com
Le classique. Visitez dnsleaktest.com, cliquez sur « Extended test » et attendez environ 20 secondes. L'outil émet une série de requêtes DNS pour des noms d'hôtes uniques qu'il contrôle, puis vous montre quels résolveurs ont réellement effectué ces résolutions. Si vous voyez le nom de votre FAI (Comcast, Verizon, BT, etc.) dans la liste des résolveurs, vous fuitez. Si vous ne voyez que le résolveur du fournisseur VPN (ou un résolveur public axé sur la confidentialité comme Quad9 ou le 1.1.1.1 de Cloudflare), le chemin DNS de l'OS est correct.
browserleaks.com/dns
Plus détaillé que dnsleaktest. Il vous montre non seulement quels résolveurs ont traité la requête, mais aussi leur emplacement géographique, leur ASN (l'opérateur réseau) et s'ils prennent en charge DNS-over-HTTPS ou DNS-over-TLS. Utile pour détecter des fuites subtiles où le bon type de résolveur est utilisé mais dans le mauvais pays, ou pour confirmer qu'un protocole DNS chiffré est effectivement utilisé.
ipleak.net
Le plus complet — il teste les fuites DNS, les fuites WebRTC, la visibilité IPv4 et IPv6, et indique à quoi ressemble votre géolocalisation. La section WebRTC est critique : si vous voyez une adresse IP « locale » dans la plage 192.168.x.x ou 10.x.x.x exposée aux côtés d'une IP « publique » correspondant à votre point de sortie VPN, votre VPN fait son travail mais votre navigateur fuit via WebRTC. La section IPv6 détecte les fuites par repli IPv6 que dnsleaktest rate parfois.
À quoi ressemble un résultat propre vs un résultat qui fuit
Sur le test étendu de dnsleaktest.com avec un VPN correctement configuré, vous devriez voir quelque chose comme ceci :
Test results (clean):
Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands
Server: 1.2.3.5 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands
Conclusion: No DNS leak detected. All queries went to the VPN's resolver.
Et voici à quoi ressemble une fuite :
Test results (leaking):
Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands
Server: 75.75.75.75 Hostname: cdns01.comcast.net ISP: Comcast Country: United States
Server: 75.75.76.76 Hostname: cdns02.comcast.net ISP: Comcast Country: United States
Conclusion: DNS leak detected. ISP resolver (Comcast) received queries.
Le signal clé est la colonne ISP. Si quoi que ce soit d'autre que votre fournisseur VPN (ou un résolveur public délibérément choisi) apparaît, votre DNS fuit. Si la colonne pays montre votre vrai pays aux côtés du pays de sortie VPN, vous fuitez. Si seul le pays du point de sortie VPN apparaît, vous êtes propre.
Comparaison des types de fuites
Chacun des quatre types de fuites a une empreinte distincte dans les résultats des tests, un ensemble distinct d'observateurs pouvant l'exploiter, et un correctif distinct :
| Type de fuite | Ce qui fuit | Qui peut le voir | Comment corriger |
|---|---|---|---|
| Contournement OS (Windows SMHNR) | Chaque requête DNS, en parallèle | FAI, opérateur Wi-Fi public, quiconque sur le chemin | Désactiver SMHNR via la stratégie de groupe ou le registre ; utiliser un client VPN qui le gère |
| Mauvaise config tunnel fractionné | Requêtes DNS des applications qui devraient être tunnelisées | FAI, opérateur réseau local | Auditer les règles de tunnel fractionné ; s'assurer que DNS est tunnelisé pour les apps protégées |
| Repli IPv6 | Requêtes DNS sur le chemin IPv6 uniquement | FAI s'il propose IPv6 ; quiconque sur le chemin IPv6 | Le client VPN doit installer les règles IPv6 correspondantes ; ou désactiver IPv6 |
| WebRTC / DoH navigateur | IP locales, plus requêtes DNS du navigateur | Tout pair WebRTC, plus le résolveur choisi par le navigateur | Désactiver WebRTC dans le navigateur ; aligner le DoH du navigateur avec le résolveur du VPN |
Corriger les quatre causes courantes
Corriger les fuites de contournement OS (Windows)
Sur Windows 10 et 11, désactivez Smart Multi-Homed Name Resolution soit via la stratégie de groupe (Configuration ordinateur → Modèles d'administration → Réseau → Client DNS → « Désactiver la résolution de noms multirésidants intelligente » → Activé) soit via PowerShell : Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. Redémarrez. Certains clients VPN bien maintenus le font automatiquement à la connexion — si ce n'est pas le cas du vôtre, faites-le manuellement.
Corriger les fuites de tunnel fractionné
Auditez votre ensemble de règles de tunnel fractionné. Pour toute application qui doit être protégée, vérifiez que son trafic TCP et ses requêtes DNS sont acheminés via le tunnel. Certains clients VPN permettent de configurer DNS par application ; la plupart ne le font pas. Si ce n'est pas le cas du vôtre, l'option la plus sûre est de désactiver entièrement le tunnel fractionné et d'utiliser un tunnel complet — qui achemine tout (y compris tout DNS) via le VPN. Pour la plupart des utilisateurs, l'avantage pratique du tunnel fractionné ne vaut pas le risque de fuite.
Corriger les fuites IPv6
Le correctif le plus fiable consiste à utiliser un client VPN qui prend en charge IPv6 à l'intérieur du tunnel (ou qui installe au minimum des règles de pare-feu IPv6 correspondantes qui bloquent le trafic IPv6 lorsque le tunnel est actif). Si vous ne pouvez pas changer de client, désactivez IPv6 sur l'interface réseau physique : sur Windows, dans les propriétés de l'adaptateur ; sur macOS, dans Réglages Système → Réseau → Avancé → TCP/IP. C'est radical (vous perdez entièrement la connectivité IPv6) mais cela élimine le vecteur de fuite.
Corriger les fuites WebRTC
Dans Firefox, définissez media.peerconnection.enabled sur false dans about:config. Dans Chrome et Edge, installez une extension comme WebRTC Network Limiter ou l'option de blocage WebRTC d'uBlock Origin. Safari gère WebRTC de manière plus conservative par défaut, mais vous pouvez quand même fuiter des IP locales dans certaines configurations ; Safari 17+ a amélioré cela significativement. Testez après le changement avec ipleak.net.
Pourquoi « utiliser un VPN » seul ne garantit pas l'absence de fuites
Il existe une idée reçue selon laquelle se connecter à un VPN prévient automatiquement les fuites DNS. Ce n'est pas le cas — la prévention dépend du client VPN qui effectue correctement une série d'actions : changer le résolveur DNS système, installer des règles de pare-feu pour bloquer le DNS direct vers le FAI, gérer IPv6, désactiver Windows SMHNR (ou les fonctionnalités de contournement OS équivalentes), et survivre aux changements réseau (bascules Wi-Fi, cycles veille/réveil) sans réintroduire la fuite.
Un client VPN bien conçu fait tout cela automatiquement et vous n'avez jamais à y penser. Un client mal conçu — ou un VPN « gratuit » qui utilise le profil VPN intégré de l'OS sans protection supplémentaire contre les fuites — n'en fait qu'une partie, laissant des vecteurs de fuite ouverts. La seule façon de savoir dans quelle catégorie vous vous trouvez est d'exécuter réellement un test de fuite après la connexion. Si le test revient propre, vous pouvez cesser de vous en inquiéter ; s'il montre des fuites, vous avez des problèmes spécifiques à corriger et vous savez maintenant lesquels.
Prévention des fuites DNS sur iOS, Android, Mac et Windows
iOS
iOS gère DNS via le framework NetworkExtension. Une application VPN correctement conçue utilise l'objet NEDNSSettings pour spécifier un résolveur personnalisé utilisé pendant que le tunnel est actif. iOS applique cela au niveau de l'OS — les applications ne peuvent pas contourner le DNS configuré sans autorisation explicite. Le principal vecteur de fuite sur iOS est iCloud Private Relay, qui (lorsqu'activé en même temps qu'un VPN) peut acheminer DNS via le résolveur d'Apple plutôt que celui du VPN. Si vous utilisez un VPN pour la confidentialité, désactivez iCloud Private Relay pour éviter les conflits entre les deux. iOS 14 a ajouté le flag includeAllNetworks (souvent utilisé avec le comportement de kill switch) qui garantit que même le DNS système passe par le tunnel.
Android
L'API VpnService d'Android permet au client VPN de spécifier des serveurs DNS qui s'appliquent à tout le trafic tunnelisé. Le paramètre système « VPN toujours actif » avec « Bloquer les connexions sans VPN » activé offre la garantie la plus forte — aucune application ne peut résoudre DNS sans que le tunnel soit actif. Android prend également en charge le DNS privé à l'échelle du système (Paramètres → Réseau et internet → DNS privé), qui force tout DNS à utiliser DNS-over-TLS vers un fournisseur choisi. La combinaison du VPN toujours actif et du DNS privé offre une protection redondante contre les fuites DNS.
macOS
macOS utilise scutil et le framework System Configuration pour gérer les paramètres DNS. Un client VPN fonctionnant via le framework NetworkExtension peut installer des paramètres DNS qui ont la priorité pendant que le tunnel est actif. Le principal vecteur de fuite sur macOS est le DNS-over-HTTPS au niveau du navigateur, qui contourne entièrement le résolveur système — désactivez le DoH au niveau du navigateur ou configurez-le pour pointer vers le même résolveur que le VPN. Testez avec scutil --dns dans le Terminal pour voir les résolveurs actifs ; seul le résolveur du VPN devrait apparaître dans la section de priorité la plus haute.
Windows
Windows présente la plus grande surface de fuite de tout OS majeur, principalement en raison de Smart Multi-Homed Name Resolution. Au-delà de la désactivation de SMHNR (couverte ci-dessus), vérifiez que l'adaptateur virtuel du VPN a une priorité de métrique plus élevée que votre adaptateur physique, qu'IPv6 est soit désactivé soit correctement tunnelisé, et qu'aucune application n'est configurée avec ses propres remplacements DNS. Windows 11 a ajouté une interface utilisateur améliorée pour les paramètres DNS mais le comportement sous-jacent est similaire à Windows 10. La commande ipconfig /all affiche les résolveurs actifs par interface.
Ce que font les bonnes applications VPN en coulisses pour prévenir les fuites
Un client VPN bien conçu ne vous demande pas de réfléchir aux fuites DNS. Il les gère comme une partie fondamentale du processus de connexion. Plus précisément :
- Configure un résolveur personnalisé à la connexion. Le client indique à l'OS « pendant que je suis connecté, toutes les requêtes DNS vont à cette adresse IP spécifique » — généralement le propre résolveur du fournisseur VPN, accessible uniquement via le tunnel. Le client restaure également les paramètres DNS précédents à la déconnexion.
- Installe des règles de pare-feu pour bloquer le DNS direct. Même si une application tente d'interroger un serveur DNS par elle-même (par ex. une requête codée en dur vers 8.8.8.8), la règle de pare-feu bloque le paquet sortant sur le port UDP 53. Le seul DNS qui peut quitter l'appareil est celui qui transite par le tunnel.
- Utilise un DNS chiffré (DoT ou DoH) à l'intérieur du tunnel. Même après que la requête est à l'intérieur du tunnel, le saut résolveur-vers-serveur est chiffré avec DNS-over-TLS (RFC 7858) ou DNS-over-HTTPS pour que l'opérateur en amont ne puisse pas voir le contenu de la requête. Notre article sur DNS-over-HTTPS vs DNS-over-TLS couvre les compromis entre les deux protocoles.
- Gère IPv6 explicitement. Les routes IPv6 sont soit tunnelisées via le VPN (préférable) soit bloquées au pare-feu pour prévenir le repli IPv6. Le client ne laisse jamais le routage IPv6 non configuré.
- S'associe à un kill switch. Si le tunnel tombe momentanément, le kill switch bloque tout le trafic — y compris DNS — jusqu'à ce que le tunnel se rétablisse. Cela prévient la condition de course « tunnel tombé, DNS fui, tunnel revenu ». Nous le couvrons en détail dans qu'est-ce qu'un kill switch VPN.
- Teste à chaque connexion. Certains clients exécutent un test de fuite intégré après chaque connexion, signalant toute anomalie à l'utilisateur. C'est rare mais c'est le modèle le plus solide possible.
Casper's Cloak utilise un résolveur DNS personnalisé accessible uniquement à l'intérieur du tunnel WireGuard, chiffré de bout en bout via DNS-over-TLS, avec les routes IPv6 explicitement tunnelisées et Windows SMHNR désactivé à l'installation. La fonctionnalité de protection contre les menaces effectue un filtrage DNS contre les domaines malveillants connus au même résolveur, de sorte que le même DNS protégé contre les fuites bloque également activement le phishing et les malwares. Le mécanisme est documenté dans notre article sur comment fonctionne réellement le filtrage DNS. L'effet combiné : correctement configuré par défaut, aucune fuite sous aucun des quatre modes d'échec courants, et filtrage actif en prime.
Pour les bases protocolaires, la spécification IETF de DNS-over-TLS est documentée dans RFC 7858, qui couvre les exigences cryptographiques et de couche transport pour l'envoi de DNS sur un canal sécurisé par TLS. C'est le même cadre qu'utilisent les résolveurs publics axés sur la confidentialité (Cloudflare, Quad9, NextDNS) pour leurs points de terminaison DNS sécurisés.
En résumé : une fuite DNS est la façon la plus courante dont la promesse de confidentialité d'un VPN échoue silencieusement. C'est facile à tester, généralement facile à corriger, et tout VPN en lequel vous avez confiance devrait passer un test de fuite sans intervention manuelle. Si ce n'est pas le cas du vôtre, c'est un signal — soit une mauvaise configuration, soit il faut passer à autre chose.