Comment empêcher les fuites DNS sur macOS, même avec un VPN

Votre VPN est activé. L’icône du tunnel est verte. Vous ouvrez dnsleaktest.com et là, elle apparaît : le serveur DNS de votre fournisseur, comme si un VPN n’avait jamais été en cours d’exécution. Donc, soit votre Mac est possédé, soit macOS fait quelque chose avec le DNS que votre client VPN ne remplace pas complètement.

La seconde hypothèse est probablement la bonne. macOS a sa propre façon de gérer les DNS, où les clients VPN ne peuvent que partiellement intervenir, et c’est dans cette faille que se produisent la plupart des fuites. La bonne nouvelle : vous pouvez le déterminer et le réparer vous-même, sans devenir ingénieur réseau. Environ trois minutes pour l’explication, environ dix pour la solution.

Cet article fait quatre choses, dans cet ordre. D’abord, il explique pourquoi cela arrive. Ensuite, comment vous pouvez confirmer que vous avez effectivement une fuite. Puis, les solutions, par ordre d’impact. Et enfin, ce que vous devez faire si le problème vient de votre client VPN.

Comment macOS résout une requête DNS

Quand une application demande une adresse IP, cette requête est envoyée à mDNSResponder, le service système responsable de la résolution de noms sur macOS. mDNSResponder examine sa configuration de résolveur et choisit le serveur qui recevra la requête. Cette configuration peut contenir plusieurs résolveurs, chacun associé à une interface spécifique, un domaine spécifique, ou une priorité. Si votre client VPN s’inscrit correctement comme résolveur système, la requête passe par le tunnel. Si macOS choisit pour une raison quelconque un autre résolveur, la requête fuit.

Cela semble simple, mais ce n’est pas le cas. macOS ne propose aucun interrupteur qui dit “envoyer tout le DNS par cette interface.” Les clients VPN doivent utiliser une combinaison de configuration réseau, de coupures automatiques et parfois d’ajustements dans /etc/resolver/ pour approcher ce comportement. Certains clients le font complètement, d’autres partiellement.

Les quatre fuites courantes

Dans la pratique, les fuites DNS sur un Mac surviennent par quatre chemins.

1. Les requêtes IPv6 lorsque le VPN ne tunnelise que l’IPv4. macOS résout alors simplement l’IPv6 en dehors du tunnel, et le VPN ne voit jamais ces requêtes.
2. Les réponses DNS qui étaient mises en cache avant la connexion au VPN. macOS conserve les réponses pour la durée de leur TTL et les réutilise, donc vous recevez de vieilles réponses de votre fournisseur, même si le VPN fonctionne maintenant.
3. DNS sur HTTPS (DoH) au niveau du navigateur. Chrome et Firefox peuvent demander eux-mêmes le DNS, contournant complètement macOS. Un DNS système configuré correctement ne capte pas ces requêtes.
4. iCloud Private Relay, sur les Macs où cela est activé. Private Relay route certaines requêtes Safari via le relais à deux étapes d’Apple, ce qui peut entrer en conflit de manière inattendue avec ce que votre VPN attend en tant que chemin DNS.

Pourquoi les clients VPN ne résolvent pas toujours cela eux-mêmes

La combinaison des chemins mentionnés ci-dessus fait qu’un client VPN ne peut pas tout contrôler depuis son propre processus. Un client bien conçu essaie de le faire, mais réussit uniquement s’il donne activement des instructions à macOS à plusieurs niveaux en même temps : le résolveur système, le DNS de l’adaptateur, la pile IPv6 et (de préférence) une coupure automatique qui bloque tout le trafic non-VPN lorsque le tunnel tombe. Tous les clients ne le font pas. Avant de réparer quoi que ce soit, vous devez savoir quel chemin fuit chez vous.

Testez si vous avez réellement une fuite DNS

Test 1 : dnsleaktest.com (Test étendu)

Connectez votre VPN. Allez sur dnsleaktest.com et cliquez sur Test étendu, pas standard. Le Test étendu effectue plusieurs dizaines de requêtes et révèle également des résolveurs secondaires. Notez les adresses IP et les noms d’hôtes qui apparaissent. Si vous voyez le nom de votre fournisseur (Ziggo, KPN, T-Mobile, Vodafone, Odido), alors vous avez une fuite. Si vous voyez uniquement les résolveurs de votre fournisseur VPN, alors le Test 1 a réussi.

Test 2 : Utilisez scutil dans le terminal

Ouvrez le Terminal macOS et exécutez la commande ci-dessous :

$ scutil --dns

La sortie est un dump de ce que macOS pense de sa configuration DNS. Regardez le résolveur #1, le résolveur primaire. Les champs de serveur de noms devraient montrer les serveurs DNS de votre VPN. Si vous voyez les adresses IP de votre fournisseur dans le résolveur #1 ou dans un autre résolveur de niveau inférieur, votre client VPN n’a pas réussi à remplacer le DNS système. Ce test contourne complètement dnsleaktest et vous indique ce que fait réellement le système d’exploitation, et non ce qu’un site externe mesure.

Test 3 : fuite IPv6

Allez sur ipv6-test.com ou ipleak.net. Si vous voyez une adresse IPv6 dans les résultats correspondant à votre emplacement réel ou à votre fournisseur, alors vous avez une fuite IPv6. Si vous voyez une adresse IPv6 appartenant à votre VPN, alors le VPN tunnelise également l’IPv6 et tout va bien. C’est de loin la cause la plus fréquente des plaintes du type “mon VPN dit que je suis en Roumanie, mais dnsleaktest montre mon fournisseur néerlandais.”

Avec les résultats de ces trois tests, vous savez quel chemin fuit. Réparez dans l’ordre ci-dessous.

Arrêtez la fuite : corrections macOS par ordre d’impact

Travaillez ces corrections de haut en bas. Répétez ensuite le test pertinent de la section précédente après chaque correction. Arrêtez-vous dès que tous les trois tests réussissent.

Correction 1 : Forcer votre client VPN à pousser le DNS

Ouvrez les paramètres de votre client VPN. Recherchez une option qui s’appelle “Utiliser le DNS VPN”, “Forcer le DNS à travers le tunnel”, “DNS personnalisé” ou “Remplacer le DNS système.” Activez-la. Certains clients ont cela activé par défaut, d’autres non, et certains n’ont pas du tout cette option (ce qui est déjà un problème, nous en reparlerons plus tard).Reconnectez-vous après la modification. Exécutez à nouveau scutil –dns et confirmez que le résolveur #1 affiche maintenant les serveurs DNS de votre VPN.

Correction 2 : Désactiver l’IPv6 si votre VPN ne le tunnelise pas

Test 3 a-t-il montré une fuite IPv6 ? Il y a alors deux options. La solution propre est d’activer l’IPv6 dans votre client VPN (tous les clients ne le supportent pas). La solution brutale consiste à désactiver l’IPv6 sur votre interface réseau.

Commencez par trouver le nom exact de votre interface :

$ networksetup -listallnetworkservices

Désactivez l’IPv6 sur celle-ci (remplacez “Wi-Fi” par le nom réel s’il est différent) :

$ networksetup -setv6off "Wi-Fi"

Réexécutez le Test 3. L’adresse IPv6 devrait disparaître, ou la page de test devrait indiquer qu’il n’y a pas de connectivité IPv6. Si vous souhaitez le réactiver plus tard :

$ networksetup -setv6automatic "Wi-Fi"

Correction 3 : Remplacez le DNS au niveau de l’interface

Même avec un client VPN qui pousse correctement le DNS, définir explicitement le DNS sur votre adaptateur réseau capture les autres cas extrêmes. Ouvrez Préférences Système > Réseau. Cliquez sur votre interface active (Wi-Fi ou Ethernet) puis sur Détails. Ouvrez l’onglet DNS. Ajoutez 1.1.1.1 et 1.0.0.1 (Cloudflare) ou 9.9.9.9 et 149.112.112.112 (Quad9). Supprimez les entrées existantes. Cliquez sur OK.

Ou via le Terminal :

$ networksetup -setdnsservers "Wi-Fi" 1.1.1.1 1.0.0.1

C’est une sécurité double. Le tunnel VPN reste le chemin principal, et macOS refuse maintenant encore de s’appuyer sur le DNS de votre fournisseur, même si la poussée DNS du VPN échoue pour une raison quelconque. Vérifiez avec scutil –dns.

Correction 4 : Désactivez iCloud Private Relay

Avez-vous un abonnement iCloud+ ? Private Relay peut être actif. Cela achemine le trafic Safari et certaines requêtes système via le relais à deux étapes d’Apple, ce qui entraîne des résultats DNS qui ne correspondent pas à ce que votre VPN attend. Pour désactiver : Préférences Système > [Votre nom] > iCloud > Private Relay > désactivez l’interrupteur. Reconnectez votre VPN après ce changement. Répétez dnsleaktest pour confirmer que la fuite est disparue.

Correction 5 : Empêchez les navigateurs d’utiliser leur propre DNS

Chrome et Firefox peuvent eux-mêmes effectuer des requêtes DNS sur HTTPS, contournant complètement le résolveur de macOS. Si votre DNS fuit uniquement lors de la navigation, c’est ici que se trouve la cause.

• Chrome : allez sur chrome://settings/security, faites défiler jusqu’à “Utiliser le DNS sécurisé” et réglez-le sur “Avec votre fournisseur de services actuel” ou désactivez-le complètement. Désactiver signifie que Chrome suit le DNS de macOS, qui suit maintenant votre VPN.
• Firefox : ouvrez about:preferences#privacy, faites défiler vers DNS sur HTTPS et définissez-le sur Off. Ou définissez-le sur Max Protection avec un résolveur que vous surveillez.
• Safari : respecte par défaut le DNS système. Pas besoin d’un paramètre séparé, à moins que le Private Relay ne soit activé (voir Correction 4).

Correction 6 : Videz le cache DNS

Après chaque changement ci-dessus, vous devez vider le cache de macOS ; si ce n’est pas le cas, le système continuera à servir de vieilles réponses avant votre correction :

$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Ensuite, fermez tous les onglets de navigateur qui étaient déjà ouverts avant la correction et ouvrez à nouveau les sites. Les navigateurs conservent leur propre cache DNS, et la seule manière fiable de le vider est de redémarrer le navigateur.

Répétez les tests et examinez les résultats

Réalisez à nouveau les trois tests de la section précédente. Avec une correction réussie, vous obtiendrez le tableau suivant :

1. dnsleaktest Extended montre uniquement les résolveurs de votre fournisseur VPN, aucun fournisseur.
2. scutil –dns montre dans le résolveur #1 les serveurs DNS de votre VPN.
3. ipv6-test.com ne montre pas d’adresse IPv6, ou l’adresse IPv6 de votre VPN.

Tous les trois tests réussissent-ils ? Dans ce cas, vous avez terminé. Si un test échoue encore, le problème ne vient plus de macOS. Il réside dans le client VPN lui-même.

Lorsque le client VPN lui-même est le problème

Avez-vous appliqué chaque correction de la section précédente et le Test 1 montre toujours le DNS de votre fournisseur, alors votre client VPN ne pousse pas le DNS à travers le tunnel. C’est un choix d’implémentation du client, pas un défaut de macOS. Signes courants : il n’y a pas d’interrupteur “forcer DNS”, pas de coupure automatique, pas de protection contre les fuites IPv6, et la documentation du développeur ne mentionne pas de comportement spécifique à macOS.

Un bon client VPN pour macOS fait quatre choses à la fois. Il pousse ses propres serveurs DNS et vérifie qu’ils sont effectivement actifs au niveau système (le test scutil de la section de diagnostic doit toujours réussir tant que le tunnel est actif). Il gère l’IPv6, soit en le tunnelisant, soit en le bloquant proprement tant que la connexion est active. Il dispose d’une coupure automatique qui bloque tout le trafic non-VPN lorsque le tunnel se déconnecte, y compris le DNS. Et il documente son comportement spécifiquement pour macOS, au lieu de traiter macOS comme une plate-forme générique.

Différents VPN sérieux font cela correctement. Le VPN pour Mac de Windscribe par exemple impose son propre DNS au niveau système dès que la connexion est établie, propose un mode Firewall qui fonctionne en mode de sécurité (de manière à ce que les requêtes DNS ne puissent pas s’échapper lorsque le tunnel se déconnecte) et tunnelise l’IPv6 au lieu de le laisser fuir. Si vous avez passé en revue les six corrections ci-dessus et que la fuite persiste, passez à un client qui s’occupe de cela pour vous et répétez les trois tests. Le diagnostic de la section précédente vous dira en une minute si le changement a colmaté la fuite.

La plupart des lecteurs n’ont pas besoin de changer de client. Les corrections macOS ci-dessus colmatent la fuite pour la grande majorité des configurations. La substitution de client est le recours lorsque tout fonctionne du côté de macOS et que la fuite reste pourtant persistante.

FAQ

Pourquoi dnsleaktest montre-t-il toujours mon fournisseur après que j’ai ajusté mes paramètres DNS ?

Deux causes probables. Tout d’abord, votre navigateur met en cache les réponses DNS d’avant le changement. Redémarrez le navigateur. Deuxièmement, macOS lui-même met en cache des réponses. Exécutez la commande de vidage de cache de la Correction 6. Si les deux caches sont vides et que la fuite persiste, exécutez scutil –dns pour voir ce que macOS utilise réellement comme résolveur. La sortie du Terminal est plus fiable pour le diagnostic que dnsleaktest.

Dois-je désactiver l’IPv6 définitivement sur mon Mac ?

Seulement si votre VPN ne tunnelise pas l’IPv6. La solution plus propre est un VPN qui gère correctement l’IPv6. Si vous désactivez l’IPv6, gardez à l’esprit qu’un petit nombre de services ne sont accessibles que via l’IPv6 (rare en 2026, mais possible). Le réactiver nécessite une seule commande : networksetup -setv6automatic “Wi-Fi”.

iCloud Private Relay protège-t-il mon DNS tout comme un VPN ?

Non. Private Relay ne gère que le trafic Safari et certaines requêtes système, pas tout votre réseau. Il achemine également uniquement via les relais d’Apple, pas via un serveur de votre choix. Si vous souhaitez une protection DNS complète sur toutes les applications, vous avez besoin d’un VPN. Faire fonctionner les deux simultanément est précisément ce qui provoque les conflits mentionnés dans la Correction 4.

J’utilise un fichier hosts ou un Pi-hole sur mon LAN. Les corrections de ce guide vont-elles le casser ?

Oui. Le remplacement du DNS au niveau de l’adaptateur (Correction 3) et la poussée DNS du VPN (Correction 1) passent au-dessus de votre résolveur local. Si vous comptez sur Pi-hole ou un fichier hosts, configurez votre VPN pour utiliser votre résolveur local comme DNS amont ou acceptez que le tunnel VPN prenne la priorité tant que vous êtes connecté.