Comment détecter une fuite DNS ? 4 étapes de vérification

À retenir : si le test IP passe, cela signifie simplement que l'adresse de sortie a changé, et pas que les requêtes DNS empruntent le même chemin. Le proxy et le DNS gèrent deux étapes distinctes : le proxy décide par quelle sortie réseau passe la connexion, tandis que le DNS traduit les noms de domaine en adresses IP. Lorsque les requêtes de résolution suivent un chemin inattendu, on parle de fuite DNS. Quatre étapes suffisent pour la détecter, mais bien lire les résultats compte davantage que le test lui-même.

Vous configurez votre proxy, ouvrez un site de test IP, la page affiche bien l'adresse du proxy, et tout semble en ordre. Quelques jours plus tard, en enquêtant sur des anomalies de comptes, vous découvrez que les requêtes DNS passaient par le réseau local depuis le début.

Pas forcément la faute du proxy : les requêtes DNS ont pu l'éviter.

Pourquoi vérifier le DNS même quand le proxy est activé

Le proxy et le DNS sont deux mécanismes distincts : activer l'un n'entraîne pas la prise en charge de l'autre. Le proxy détermine par quelle sortie réseau part la connexion, tandis que le DNS assure la résolution des noms de domaine. Ces deux maillons du réseau sont indépendants, et un proxy qui fonctionne correctement ne garantit pas que les requêtes DNS se comportent comme prévu.

Concrètement, lors d'une visite de site, le client obtient d'abord l'adresse IP du domaine via une requête DNS, ou confie le nom de domaine au proxy. Ce choix dépend du protocole du proxy, de l'implémentation du client et des réglages DNS du navigateur. Activer un proxy ne signifie pas automatiquement que toutes les requêtes de résolution suivent le chemin attendu : seule une vérification réelle permet de trancher, l'indication « proxy connecté » ne suffit pas.

Une précision s'impose aussi sur le périmètre : une fuite DNS ne signifie pas que votre adresse IP publique réelle est exposée. Ce qui fuit, c'est le chemin des requêtes de domaines, qui peut révéler à votre service de résolution ou à votre réseau local quels noms vous avez consultés. Pour savoir si votre vraie adresse IP est exposée, il faut un test IP distinct. C'est précisément pour cette raison que l'agence de cybersécurité de Singapour liste le test de fuite DNS et le test de fuite d'adresse IP comme deux vérifications séparées dans ses recommandations de sécurité VPN : ils ne valident pas la même chose (voir les conseils VPN de la CSA).

Comment survient généralement une fuite DNS

Trois causes reviennent le plus souvent, toutes liées à la configuration et non à un proxy défectueux. Passons-les en revue.

Le proxy ne traite qu'une partie du trafic

Certains réglages de proxy ne prennent en charge que les requêtes web du navigateur, la résolution restant assurée par le système local. Cela dépend du protocole du proxy et de la façon dont le client gère les requêtes. Si les requêtes web passent par le proxy alors que la résolution passe par le réseau local, un résolveur local apparaîtra dans les résultats du test.

Le navigateur utilise son propre DNS sécurisé

Chrome comme Firefox prennent en charge le DNS over HTTPS (DoH) : une fois activé, les requêtes de résolution partent en HTTPS chiffré vers un service désigné, ce qui réduit les occasions pour le réseau local d'observer directement les requêtes. Mais le chiffrement ne garantit ni que les requêtes passent par le proxy, ni que le service choisi correspond aux attentes de l'environnement en cours. Cette fonction de Firefox se règle séparément, voir la documentation officielle de Mozilla.

Système, navigateur et client proxy : chacun son résolveur

La plus discrète des configurations. Le système s'appuie sur un résolveur, le navigateur avec DoH activé en utilise un autre, et le client proxy en configure un troisième. Empilés les uns sur les autres, ils transforment le chemin de résolution en boîte noire. Le simple statut « connecté » affiché par le logiciel proxy ne permet pas de trancher : il faut observer le chemin réellement suivi par le navigateur en cours d'exécution.

Quand le chemin de résolution aboutit au fournisseur d'accès local, les requêtes transitent par son service de résolution. Pour aller plus loin, consultez le principe des proxys ISP et leurs cas d'usage.

Comment détecter une fuite DNS : les quatre étapes

Le test en lui-même est simple : l'essentiel est d'avoir des attentes avant le test et une base de comparaison après. Ce n'est qu'au terme des quatre étapes que la conclusion tient debout.

Étape 1 : notez d'abord le résultat attendu. Avant le test, consignez trois choses : dans quelle région se trouve la sortie de votre proxy, qui doit assurer la résolution des domaines, et si le navigateur a DoH activé. Sans attentes claires, impossible d'interpréter les résultats.

Étape 2 : lancez le test avec le proxy activé. Utilisez un site proposant un test de fuite DNS, par exemple dnsleaktest.com, et cliquez sur le test étendu (Extended test) pour afficher davantage de résolveurs. Vous pouvez aussi ouvrir la page de test DNS de BrowserLeaks pour voir à quelles organisations appartiennent les résolveurs. Notez leur nom, leur organisation et leur région.

Étape 3 : comparez les résultats à vos attentes. Vérifiez si les résolveurs obtenus correspondent à la configuration du système, du navigateur et du proxy. S'ils appartiennent au service DNS attendu et qu'aucun chemin de résolution local inattendu n'apparaît, le test peut être considéré comme conforme à première vue. Si le fournisseur d'accès local ou un service inconnu se manifeste, confirmez d'abord qu'il ne fait pas partie de la configuration prévue, puis examinez un par un la gestion DNS du client proxy, le DNS sécurisé du navigateur et les réglages réseau du système, sans conclure trop vite à un proxy défaillant. Un test isolé ne reflète que les conditions du moment et ne garantit pas que toutes les requêtes soient exemptes de problème.

Étape 4 : modifiez un réglage et relancez le test. Si un ajustement est nécessaire, ne touchez qu'un seul élément à la fois : la gestion DNS du client proxy, l'interrupteur DoH du navigateur ou les réglages réseau du système, puis relancez le test pour comparer. En changeant plusieurs choses d'un coup, impossible de savoir laquelle a fait la différence.

Comment interpréter les résultats

Un même résultat bien lu devient un indice, mal lu il mène à une erreur d'appréciation. Voici comment traiter les cinq cas les plus fréquents :

Autre piège : Anycast et les nœuds distribués masquent la sortie réelle.

Quelles différences entre fuite DNS, fuite WebRTC et empreinte du navigateur ?

Quatre vérifications pour quatre types d'informations différentes : réussir l'une ne garantit pas les autres. C'est côte à côte que leurs frontières se voient le mieux :

DNS et WebRTC sont les deux que l'on confond le plus facilement, car tous deux portent le mot « fuite ». Pourtant, leurs principes de test comme leurs remèdes diffèrent complètement. La détection et le réglage de la fuite WebRTC ont déjà fait l'objet d'un article dédié, nous n'y revenons pas ici. La fuite IPv6, elle aussi, appartient à la même famille : elle vérifie si une adresse IPv6 contourne le proxy. La méthode est décrite dans le guide de détection des fuites IPv6.

Ces quatre points renseignent sur des informations différentes et ne se remplacent pas. Pour auditer un environnement proxy, il est conseillé de commencer par l'adresse IP publique, puis de passer au DNS et au WebRTC, et enfin de vérifier l'empreinte et la configuration de l'environnement, le choix précis dépendant de votre scénario.

Comment intégrer ces vérifications dans votre flux de travail avec MostMate

L'ordre recommandé : d'abord la sortie, ensuite la résolution, puis WebRTC, et enfin la configuration de l'environnement. Lorsque vous gérez plusieurs environnements de navigateur via MostMate, il vaut mieux mener le test de connectivité du proxy et le test de fuite DNS séparément.

Premier point : la configuration du proxy. Après avoir associé un proxy à l'environnement, contrôlez l'état de la connexion avec le test de proxy intégré au produit, en vérifiant aussi le type de protocole (HTTP, HTTPS, SOCKS5, SSH) et les identifiants d'authentification. Gardez à l'esprit qu'un test de proxy réussi ne remplace pas un test de fuite DNS : le chemin réel des requêtes DNS dépend toujours de la configuration du client proxy, du navigateur et du système.

Ouvrez ensuite la page de test DNS dans un environnement où le proxy est associé, selon les quatre étapes décrites plus haut, et regardez si l'appartenance des résolveurs correspond à vos attentes.

Deuxième point : l'isolement de l'environnement lui-même. Dans un scénario multi-comptes, le proxy, les cookies et les paramètres d'empreinte de chaque environnement doivent rester indépendants, sans emprunt mutuel. Le périmètre exact de l'isolement est détaillé dans le périmètre et la configuration de l'isolement des environnements de navigateur. Si un proxy erroné est attribué à un environnement ou si la configuration est partagée, les résultats du test perdent toute valeur de comparaison. L'isolement facilite la gestion des sessions et des configurations, mais il ne garantit pas que le chemin DNS soit correct pour autant, et ne remplace pas une vérification externe.

Troisième point : ne perdez pas de vue les limites. Le rôle du navigateur antidétection est de mettre l'environnement en ordre ; que le proxy fonctionne réellement et que le DNS suive le chemin prévu, cela relève toujours de vérifications externes. Un test réussi ne règle rien une fois pour toutes : après un changement de configuration ou une mise à jour du système, il est prudent de retester.

Questions fréquentes

Le proxy est activé, mais le test DNS affiche un résolveur local : le proxy est-il hors service ?

Pas nécessairement. Le proxy peut ne prendre en charge que les requêtes web, la résolution étant traitée séparément par le système ou le navigateur. Examinez un par un la gestion DNS du client proxy et les réglages DoH du navigateur, en ne modifiant qu'un élément à la fois avant chaque nouveau test.

Une fuite DNS expose-t-elle mon adresse IP réelle ?

L'assimilation directe est impossible. Une fuite DNS révèle le chemin des requêtes de résolution de domaines, et les informations effectivement exposées dépendent de la configuration réseau et du scénario de test. Pour savoir si votre adresse IP publique réelle est masquée, un test IP indépendant s'impose, la vérification du chemin de résolution étant un exercice à part.

Une fuite DNS peut-elle se produire avec un navigateur antidétection ?

Oui, c'est possible. Le navigateur antidétection gère l'isolement de l'environnement et les paramètres d'empreinte, tandis que le comportement DNS dépend du protocole du proxy ainsi que de la configuration du système et du navigateur. Le test ne doit donc pas être négligé.

Le test DNS est passé : que vérifier ensuite ?

Restent la fuite WebRTC et l'empreinte du navigateur, à valider chacun avec l'outil correspondant. Une fois tout validé, le contrôle de la couche réseau de l'environnement est complet.

Conclusion

La valeur d'un test de fuite DNS ne réside pas dans l'obtention d'un « réussi » ou d'un « échec », mais dans la confirmation que les requêtes réseau de l'environnement actuel se comportent comme prévu. L'adresse IP publique, le DNS, le WebRTC et l'empreinte du navigateur ont chacun leur méthode de vérification, et le résultat de l'une ne remplace pas la vérification des autres. Quel que soit le navigateur antidétection utilisé, il est recommandé de retester après chaque modification du proxy ou de la configuration réseau.

Si vous devez gérer plusieurs environnements de navigateur, commencez par découvrir la configuration des environnements et la gestion des proxys dans MostMate, puis validez chaque point en suivant les étapes de cet article. Pour une couche proxy plus solide, vous pouvez télécharger MostMate : la version gratuite offre deux environnements, de quoi boucler d'abord tout le cycle de test sur le premier.