Prévention des fuites DNS : chemins de résolution, proxys et tests

Un proxy modifie l’origine apparente du trafic des pages, mais le navigateur doit toujours convertir chaque nom d’hôte en adresse avant de se connecter. Si cette requête part vers un résolveur situé hors du chemin du proxy, ce résolveur apprend quels domaines ont été demandés et depuis quel réseau, même si la page s’est chargée via le proxy. Cette lacune est une fuite DNS, et c’est l’une des causes les plus fréquentes d’une configuration de proxy incohérente. BotBrowser peut garder cohérents les réglages de proxy et de DNS d’un contexte contrôlé pendant un test ; il ne peut pas contrôler les résolveurs ni les réseaux extérieurs à ce navigateur.

La corriger est une question de responsabilité : pour chaque requête, qui résout le nom, où se trouve ce résolveur et qui peut lire ses journaux. Les sections suivantes répondent à ces questions pour SOCKS5, SOCKS5H et HTTP CONNECT, comparent les parades courantes et la lacune que chacune laisse, puis se terminent par un test de fuite qui considère toute divergence comme un contrôle échoué.

TL;DR

• socks5:// peut résoudre localement ; socks5h:// envoie le nom d’hôte au proxy.
• Une page chargée proprement ne prouve pas que prefetch, dns-prefetch, IPv4 et IPv6 utilisent le résolveur attendu.
• Notez l’opérateur et la région attendus, puis considérez tout résolveur inexpliqué comme un échec.

Contents

• Qui résout le nom d’hôte
• Ce que révèle une fuite
• Préchargement et autres requêtes à traiter à part
• Choisir entre SOCKS5H, DNS local, DNS système, DoH et DNS de VPN
• Lancer un test de fuite et lire le résultat
• À retenir

Qui résout le nom d’hôte

L’entrée du glossaire MDN consacrée au DNS décrit le système qui associe des adresses IP aux noms de domaine. Le navigateur a besoin de cette association avant d’ouvrir une connexion ; chaque navigation, chaque ressource intégrée et chaque requête en arrière-plan pose donc la même question : quel composant effectue la résolution. Avec un proxy sur le trajet, il y a plusieurs candidats, et le schéma du proxy décide lequel répond.

Trois dispositions courantes se comportent différemment :

• SOCKS5. Le navigateur résout le nom avec un résolveur local et transmet une adresse IP au proxy. La résolution a lieu hors du chemin du proxy, de sorte que le résolveur du réseau local voit le nom.
• SOCKS5H. Le navigateur transmet au proxy le nom d’hôte lui-même et c’est le proxy qui le résout. Le résolveur local n’est pas interrogé pour les noms qui transitent par cette connexion.
• HTTP CONNECT. Le navigateur indique l’hôte cible dans la requête de tunnel, et le serveur proxy s’y connecte. La résolution de la cible a normalement lieu du côté du proxy.

Un quatrième cas se place à côté des schémas de proxy : le navigateur peut résoudre les noms avec son propre résolveur plutôt qu’avec celui du système d’exploitation. Ce choix change le résolveur interrogé et les serveurs qu’il contacte, mais il n’indique pas à lui seul si la réponse sert à une connexion directe ou est transmise au proxy. Considérez la résolution côté navigateur et la résolution côté proxy comme deux réglages indépendants, et notez la valeur de chacun.

La spécification SOCKS5, la RFC 1928, permet à un client d’envoyer au proxy soit une adresse, soit un nom de domaine. Le schéma socks5h:// utilisé par les navigateurs et les outils en ligne de commande est une convention côté client pour choisir la seconde forme. Lisez le schéma de votre configuration à la lettre : socks5:// et socks5h:// sont deux décisions différentes, et une seule lettre déplace la résolution de votre machine vers le fournisseur.

Déplacer la résolution vers le proxy ne la rend pas privée. Dès que le proxy résout un nom, le fournisseur décide quel résolveur amont répond, dans quelle région il se trouve, si les réponses sont mises en cache ou filtrées et ce qui est consigné. Ces choix sont propres à chaque fournisseur, échappent à votre contrôle, et la plupart ne les publient pas sous une forme que vous puissiez vérifier. L’article sur la configuration du proxy détaille les schémas, mais l’étiquette d’un schéma ne prouve jamais à elle seule où est partie une requête. La seule preuve est la vérification.

Ce que révèle une fuite

Un résolveur de votre réseau local ou de votre fournisseur d’accès voit les noms de domaine qu’on lui demande de résoudre, l’heure de chaque requête et l’adresse réseau qui a posé la question. Si le trafic de la page passe par le proxy alors que les noms sont résolus localement, ce résolveur peut tout de même reconstituer une liste de sites visités, même s’il ne voit jamais le contenu des pages. HTTPS protège la page ; il ne masque pas la requête de type A ou AAAA qui la précède.

La deuxième exposition est géographique. Les résolveurs sont exploités dans des régions précises, et de nombreux réseaux attribuent des résolveurs proches du client. Si la sortie du proxy est en Allemagne alors que les requêtes arrivent d’un résolveur qui dessert votre région d’origine, les deux signaux divergent. Qu’un service donné les compare ou non varie, et personne ne peut promettre l’un ou l’autre. Une divergence reste une raison de considérer la configuration comme incohérente, car le but du chemin est que ses signaux concordent.

La troisième tient aux journaux que vous ne maîtrisez pas. Un résolveur peut conserver la trace des noms auxquels il a répondu. Pointer le navigateur vers un autre résolveur change qui détient ces traces sans les supprimer. La question utile n’est donc jamais de savoir si le DNS est masqué, mais quel opérateur peut voir ces noms, dans quelle région, et s’il s’agit bien de l’opérateur et de la région que vous avez choisis.

Les familles d’adresses comptent aussi. Un navigateur qui peut utiliser IPv4 et IPv6 peut atteindre une destination par une famille que le chemin du proxy ne couvre pas ; un test qui n’examine qu’une famille peut donc manquer une fuite. Vérifiez quelles familles d’adresses votre proxy et le test de fuite prennent en charge, et comparez-les au comportement que vous attendez.

Préchargement et autres requêtes à traiter à part

Les navigateurs résolvent des noms avant qu’on leur demande de les charger. Une page contenant de nombreux liens peut déclencher en arrière-plan des requêtes pour les cibles de ces liens, et la barre d’adresse peut résoudre un nom d’hôte pendant que la personne tape encore. Ces requêtes spéculatives, notamment prefetch et dns-prefetch, suivent le chemin de résolution du navigateur, pas celui de la connexion que vous avez ouverte volontairement. Si ce chemin sort de la route du proxy, les noms divulgués incluent des sites qui n’ont jamais été visités.

C’est pourquoi un proxy qui gère correctement toutes les connexions explicites peut tout de même afficher un résolveur local dans un test de fuite. Les requêtes de la page, les indications de préchargement et les requêtes en arrière-plan doivent chacune être vérifiées, et elles ne se confondent pas avec un simple chargement de page. WebRTC soulève une question voisine mais distincte, qui porte sur les adresses et non sur les noms, et que traite l’article sur la prévention des fuites WebRTC.

Vous pouvez tester les requêtes spéculatives sans vous fier à une page de test publique. Utilisez un domaine que vous contrôlez, dont le serveur de noms faisant autorité enregistre les requêtes, publiez une page qui renvoie vers un nom d’hôte unique sous ce domaine, ouvrez-la par la route configurée, puis regardez quelles adresses de résolveur apparaissent dans le journal du serveur. Une requête provenant d’une adresse qui n’appartient ni à votre fournisseur ni au résolveur que vous avez choisi est une fuite qu’un test sur une seule page n’aurait pas montrée.

Le cache complique la situation. Un nom résolu plus tôt dans la même session peut recevoir une réponse depuis la mémoire par la suite, de sorte qu’un résultat propre à la seconde visite prouve peu de chose. Démarrez le navigateur à neuf, utilisez des noms d’hôte jamais résolus auparavant et répétez le contrôle après chaque changement de configuration.

Les modes de défaillance diffèrent eux aussi. Quand un résolveur configuré est injoignable, certaines configurations basculent silencieusement vers un autre, et ce basculement est un nouveau chemin que le test décrit plus bas doit détecter. Préférez les configurations qui échouent de façon visible à celles qui détournent discrètement les requêtes ailleurs, et confirmez votre cas en bloquant le résolveur dans un environnement de test qui vous appartient pour observer ce que fait le navigateur.

Choisir entre SOCKS5H, DNS local, DNS système, DoH et DNS de VPN

Aucun contrôle ne referme toutes les lacunes ; la comparaison utile porte donc sur la lacune résiduelle de chacun. Quatre questions permettent de classer les options : qui résout le nom, dans quelle région, qui peut le consigner, et si le réglage s’applique à ce seul navigateur ou à toute la machine.

SOCKS5H. Il tient à l’écart du résolveur local les noms qui transitent par la connexion du proxy et n’exige aucune fonction du navigateur en dehors du schéma. Ses lacunes sont le résolveur amont du fournisseur, que vous ne pouvez pas inspecter, les proxys qui ne gèrent pas la résolution distante et les requêtes que le navigateur émet hors de la connexion passant par le proxy.

DNS local du navigateur avec --bot-local-dns. Le résolveur intégré de BotBrowser rend la résolution indépendante du comportement DNS du fournisseur, ce qui aide quand un fournisseur bloque, réécrit ou ralentit les requêtes. Sa lacune est qu’il ne gouverne que le côté navigateur. Il ne change pas ce que fait un fournisseur pour une connexion qu’il résout lui-même, et si vous le pointez vers un serveur DNS précis, ce serveur devient un nouvel observateur auquel vous devez faire confiance.

DNS système. Configurer le système d’exploitation avec un résolveur choisi remplace le résolveur de votre fournisseur d’accès par un autre. L’observateur ne disparaît pas, et le nouveau résolveur se trouve généralement dans une région sans rapport avec le proxy. Ce réglage ne dit rien non plus sur la question de savoir si un nom donné est résolu par le navigateur ou par le proxy.

DNS sur HTTPS. La RFC 8484 transporte les messages DNS sur HTTPS, ce qui empêche les observateurs du chemin réseau de les lire ou de les modifier. Le résolveur voit toujours chaque nom, sa région doit toujours correspondre à la route, et le réglage ne décide pas qui effectue la résolution. L’article sur le DNS sur HTTPS traite des contrôles du navigateur et des limites du résolveur.

DNS de VPN. Un VPN fait généralement passer le DNS du système d’exploitation par son tunnel, ce qui couvre toutes les applications à la fois. C’est trop grossier pour un routage par navigateur ou par contexte, le résolveur de l’opérateur du VPN voit les noms, et la région du résolveur suit la sortie du VPN plutôt qu’une sortie de proxy distincte.

Les combinaisons aident quand les lacunes ne se recouvrent pas, par exemple SOCKS5H plus un résolveur côté navigateur choisi délibérément. Elles ajoutent aussi des décisions, et chaque nouvel élément est un observateur de plus ou un endroit de plus où une divergence peut apparaître. Choisissez le plus petit ensemble dont vous savez nommer les observateurs, puis testez.

Une règle pratique aide quand le choix n’est pas évident. Si le fournisseur prend en charge SOCKS5H et que vous faites confiance à son résolveur, commencez par là et vérifiez. Si le fournisseur bloque, réécrit ou ralentit les requêtes, ou ne propose que SOCKS5, un résolveur côté navigateur vous donne une politique qui ne dépend pas du DNS du fournisseur. Si d’autres applications de la machine ont aussi besoin de protection, c’est le rôle du système d’exploitation ou d’un VPN, pas d’un paramètre de navigateur.

Lancer un test de fuite et lire le résultat

Un test de fuite est utile quand il est lancé de la même façon à chaque fois et lu par rapport à une attente fixe. Une séquence reproductible :

1. Notez l’adresse de sortie du proxy, son pays et l’opérateur que le fournisseur indique pour elle.
2. Démarrez le navigateur à neuf avec exactement les paramètres que vous comptez utiliser.
3. Ouvrez un test de fuite comme dnsleaktest.com et lancez son test étendu, qui effectue plusieurs requêtes au lieu d’une seule.
4. Relevez chaque résolveur signalé par le test, avec son opérateur et sa région.
5. Comparez cette liste à l’étape 1. Chaque résolveur doit appartenir à un opérateur et à une région que vous savez expliquer.

Considérez toute différence comme un contrôle échoué. Un résolveur exploité par votre fournisseur d’accès, un résolveur situé dans un pays qui ne correspond pas à la sortie ou un opérateur que vous n’avez pas choisi signifient que la route et les requêtes divergent. N’écartez pas la différence par une hypothèse ; modifiez une seule variable, comme le schéma du proxy ou le paramètre de DNS local, puis relancez le test. Comparez l’opérateur et la région plutôt que les adresses exactes, car les grands opérateurs répondent depuis de nombreuses adresses de la même région.

Le motif observé dans le résultat oriente vers la cause. Le résolveur de votre propre fournisseur signifie généralement qu’un nom a été résolu localement ; vérifiez donc le schéma et si le préchargement est couvert. Un résolveur public connu dans la mauvaise région renvoie au DNS du système d’exploitation, à un réglage DoH ou à un VPN. Un résolveur dans la bonne région mais exploité par un opérateur inattendu renvoie au choix amont du fournisseur, que vous ne pouvez changer qu’en changeant de fournisseur.

Un test de fuite a ses limites. Il montre les résolveurs que les serveurs du test ont vus à ce moment-là pour les noms d’hôte qu’il a utilisés. Il n’observe pas les requêtes portant sur d’autres noms, ne montre pas les journaux côté fournisseur et ne peut pas prouver l’anonymat. Un résultat propre atteste qu’un chemin concordait un jour donné.

Une seconde limite est la portée. La résolution de noms n’est qu’un des chemins réseau. L’exposition d’adresses par WebRTC, l’adresse de sortie du proxy lui-même et le comportement de transport de la connexion sont des contrôles distincts, et un test DNS réussi n’en dit rien.

Les paramètres ci-dessous sont la manière documentée de lancer BotBrowser avec un proxy SOCKS5H et le résolveur local :

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server="socks5h://user:[email protected]:1080" \
       --bot-local-dns

La même configuration depuis Playwright, avec les chemins de l’exécutable et du profil lus dans l’environnement :

import { chromium } from 'playwright-core';
const browser = await chromium.launch({
  executablePath: process.env.BOTBROWSER_EXEC_PATH,
  headless: true,
  args: [
    `--bot-profile=${process.env.BOT_PROFILE_PATH}`,
    '--proxy-server=socks5h://user:[email protected]:1080',
    '--bot-local-dns',
  ],
});
const page = await browser.newPage();
await page.goto('https://www.dnsleaktest.com');
await browser.close();

Quand plusieurs contextes de navigateur utilisent des proxys différents, l’attente est propre à chaque contexte. Chaque contexte a sa propre sortie, sa propre région et donc son propre opérateur de résolveur attendu ; exécutez la séquence une fois par route et conservez les résultats côte à côte. Un seul résultat propre pour une route ne dit rien d’une seconde route qui utilise un autre fournisseur.

Décidez à l’avance de ce qui se passe après un contrôle échoué. Une réponse bornée fonctionne le mieux : arrêter l’exécution, conserver la configuration et la liste de résolveurs observée, et ne changer qu’une variable à la fois. Évitez les boucles de nouvelles tentatives qui continuent d’envoyer du trafic alors que les requêtes restent inexpliquées, et évitez de collecter plus que l’opérateur et la région dont vous avez besoin.

Répétez le contrôle chaque fois que le fournisseur de proxy, le schéma, les paramètres ou la version du navigateur changent, et limitez l’enregistrement à l’opérateur et à la région. L’historique de navigation n’a pas sa place dans un journal de test. Pour la question plus large de la cohérence des signaux d’adresse, de DNS et de WebRTC, voir cohérence entre proxy, DNS et WebRTC.

Ce que BotBrowser prend en charge et ce qui reste hors de sa portée

Le paramètre --bot-local-dns est documenté comme une fonction ENT Tier1. Le paramètre seul ou avec true résout par le résolveur intégré du navigateur, false le désactive pour que le proxy résolve les noms, et une valeur IP ou IP:port envoie les requêtes uniquement à ce serveur DNS, le port 53 étant celui par défaut. Une valeur invalide est traitée comme false. Lorsqu’un serveur personnalisé ne renvoie aucune réponse, BotBrowser ne se rabat pas sur le résolveur du système. Pour les connexions de proxy prises en charge, la documentation indique aussi que la sélection de cible en double pile reste alignée sur la route active du proxy sans autre paramètre.

BotBrowser documente --bot-local-dns (ENT Tier1) comme un résolveur DNS intégré qui rend la résolution des noms indépendante du comportement DNS du fournisseur de proxy, et il achemine les requêtes de préchargement DNS par le même chemin de proxy, de sorte qu’une équipe peut appliquer une politique DNS reproductible et la vérifier avec un test de fuite. BotBrowser ne peut pas contrôler ni garantir le DNS amont du fournisseur de proxy, les serveurs DNS ou les journaux situés hors du navigateur, ni l’interprétation d’un test de fuite, et il ne remplace pas le choix de SOCKS5H ou d’un fournisseur digne de confiance.

En pratique, cela fait deux tâches distinctes. Le côté navigateur est configurable et reproductible, et le côté fournisseur relève d’une décision sur la confiance qu’aucun paramètre ne peut prendre à votre place. Notez à côté de chaque configuration le schéma choisi, le réglage de DNS local, l’opérateur de résolveur attendu et la région attendue, afin qu’un changement ultérieur apparaisse comme un écart par rapport à une attente consignée. Consultez la documentation sur la prévention des fuites DNS pour connaître la sémantique actuelle des valeurs avant de modifier une configuration de production.

À retenir

Choisissez le chemin de résolution le plus court dont vous pouvez nommer l’opérateur et la région. Vérifiez-le avec une session neuve et des noms d’hôte jamais résolus, incluez les requêtes spéculatives et les deux familles d’adresses, puis arrêtez le déploiement si le résolveur observé ne s’explique pas par la politique du proxy.

Sources

• Documentation BotBrowser : prévention des fuites DNS
• MDN : DNS
• RFC 8484 : requêtes DNS sur HTTPS (DoH)
• RFC 1928 : SOCKS version 5
• Test de fuite DNS