Prevention des fuites DNS : protegez votre activite de navigation

Introduction

Lorsque vous utilisez un proxy pour proteger votre identite de navigation, vous vous attendez a ce que tout le trafic passe par ce proxy. Mais les requetes DNS empruntent souvent un chemin different. Avant que votre navigateur puisse se connecter a un site web via le proxy, il doit resoudre le nom de domaine en adresse IP. Si cette requete DNS est envoyee au resolveur de votre FAI au lieu de passer par le proxy, votre FAI voit chaque domaine que vous visitez. C'est une fuite DNS, et c'est l'une des causes les plus courantes d'echec des configurations de confidentialite basees sur un proxy.

BotBrowser resout les fuites DNS au niveau du moteur du navigateur avec le flag --bot-local-dns, qui active un resolveur DNS local integre gardant la resolution sous votre controle.

Impact sur la confidentialite

Les fuites DNS compromettent la confidentialite du proxy de plusieurs facons. Le resolveur DNS de votre FAI enregistre chaque domaine que vous resolvez, creant un historique complet de votre activite de navigation. Cela se produit meme lorsque tout le trafic HTTP et HTTPS passe par le proxy. Le FAI voit les noms de domaine, le timing de vos requetes et votre veritable adresse IP.

Au-dela de la visibilite du FAI, les requetes DNS revelent votre localisation geographique. Les resolveurs DNS sont regionaux. Si vous utilisez un proxy en Allemagne mais que vos requetes DNS vont vers un resolveur en Virginie, l'incoherence geographique est evidente. Les systemes de suivi qui correlent la localisation du resolveur DNS avec la localisation IP declaree peuvent identifier cette incoherence.

Les fuites DNS peuvent egalement survenir par des chemins moins evidents. Le prefetching DNS, que les navigateurs utilisent pour accelerer la navigation, peut resoudre des domaines avant que vous ne cliquiez dessus. WebRTC peut declencher des recherches DNS en dehors du chemin du proxy. Certaines configurations de proxy gerent le trafic TCP mais laissent les requetes DNS basees sur UDP non protegees.

Le controle DNS au niveau du moteur de BotBrowser ferme tous ces chemins simultanement.

Contexte technique

Comment fonctionne la resolution DNS dans les navigateurs

Lorsque vous naviguez vers https://example.com, le navigateur doit resoudre example.com en adresse IP avant d'etablir une connexion. Le processus de resolution suit generalement ce chemin :

1. Le navigateur verifie son cache DNS interne
2. S'il n'est pas en cache, il interroge le resolveur DNS du systeme d'exploitation
3. Le resolveur du systeme verifie son propre cache, puis transmet la requete aux serveurs DNS configures (generalement ceux de votre FAI)
4. Le serveur DNS repond avec l'adresse IP

Lorsqu'un proxy est configure, le comportement ideal depend du protocole du proxy :

• SOCKS5H : le navigateur envoie le nom d'hote directement au proxy, qui gere la resolution DNS. Aucune requete DNS locale n'a lieu.
• SOCKS5 : le navigateur resout le DNS localement, puis envoie l'IP resolue au proxy. La requete DNS fuit.
• HTTP CONNECT : le navigateur envoie le nom d'hote au proxy dans la requete CONNECT. La resolution DNS depend de l'implementation.

Prefetching DNS et resolution speculative

Les navigateurs modernes prefetchent agressivement les enregistrements DNS pour reduire la latence. Lorsqu'une page contient des liens, le navigateur peut resoudre ces domaines avant que vous ne cliquiez dessus. Ce prefetching se produit au niveau du moteur du navigateur et peut ne pas respecter les parametres du proxy dans toutes les configurations.

De meme, les navigateurs effectuent une resolution DNS speculative pour les domaines qui apparaissent dans la barre d'adresse pendant que vous tapez. Ces requetes passent par le resolveur du systeme par defaut, creant des chemins de fuite difficiles a controler avec les seuls parametres du proxy.

Le probleme du DNS du fournisseur de proxy

Meme lorsque les requetes DNS passent par le proxy (comme avec SOCKS5H), le comportement DNS du fournisseur de proxy peut ne pas etre ideal :

• Le fournisseur peut utiliser des serveurs DNS qui ne correspondent pas a la region geographique du proxy
• Les reponses DNS peuvent etre mises en cache ou reecrites par le fournisseur
• Les politiques DNS du fournisseur peuvent bloquer certains domaines
• Le support DNS-over-HTTPS ou DNS-over-TLS varie selon le fournisseur

Approches courantes et leurs limites

Utiliser SOCKS5H au lieu de SOCKS5

Passer de socks5:// a socks5h:// demande au navigateur d'envoyer les noms d'hote au proxy pour la resolution au lieu de resoudre localement. C'est un bon premier pas, mais cette approche a des limites :

• Le prefetching DNS peut toujours utiliser le resolveur local pour les recherches speculatives
• Le comportement DNS du fournisseur de proxy echappe a votre controle
• Tous les protocoles de proxy ne supportent pas la resolution DNS distante
• Le comportement de mise en cache DNS interne du navigateur varie selon les implementations

Configuration DNS au niveau du systeme

Configurer votre systeme d'exploitation pour utiliser des serveurs DNS specifiques (comme le 1.1.1.1 de Cloudflare ou le 8.8.8.8 de Google) empeche votre FAI de voir les requetes DNS, mais le serveur DNS les voit toujours. Ces serveurs DNS sont souvent situes dans des regions geographiques differentes de celles de votre proxy, creant des incoherences de localisation. Le DNS au niveau du systeme ne resout pas non plus le probleme du prefetching DNS interne du navigateur.

DNS-over-HTTPS (DoH)

Chromium supporte DNS-over-HTTPS, qui chiffre les requetes DNS. Cela empeche votre FAI de lire le trafic DNS, mais le fournisseur DoH voit toujours les requetes et votre veritable adresse IP (puisque les requetes DoH sortent du chemin du proxy dans de nombreuses configurations). DoH repond au probleme de confidentialite mais pas au chemin de fuite lui-meme.

Protection DNS au niveau VPN

Un VPN route generalement toutes les requetes DNS a travers le tunnel VPN. C'est efficace pour la navigation generale mais ajoute la surcharge d'un tunnel VPN complet. Pour les utilisateurs qui ont besoin d'un controle de proxy par navigateur ou par contexte, un VPN est trop grossier.

L'approche de BotBrowser

Le flag --bot-local-dns

Le flag --bot-local-dns de BotBrowser (ENT Tier1) active un resolveur DNS local integre au moteur du navigateur :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns

Ce flag controle le comportement DNS au niveau de la pile reseau, ce qui signifie :

• Toutes les requetes DNS sont gerees localement. Aucune requete n'atteint le resolveur de votre FAI.
• Le prefetching DNS respecte la configuration du proxy. Les recherches speculatives ne fuient pas.
• WebRTC et les autres protocoles ne peuvent pas declencher de recherches DNS non protegees. La protection couvre tous les chemins reseau.
• La protection est invisible pour les sites web. Il n'y a pas de differences observables dans le comportement DNS du point de vue de la page.

Quand utiliser --bot-local-dns

Le flag --bot-local-dns est particulierement utile lorsque :

• Votre fournisseur de proxy bloque ou reecrit les recherches DNS
• Vous avez besoin d'un comportement DNS coherent entre plusieurs executions
• Vous souhaitez eviter les politiques DNS cote fournisseur
• Vous utilisez un proxy SOCKS5 (pas SOCKS5H) et voulez empecher la resolution DNS locale de fuiter

Combinaison avec d'autres protections reseau

Pour une confidentialite reseau complete, combinez la protection DNS avec les parametres de proxy et WebRTC :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns \
       --bot-webrtc-ice="google"

Cette configuration ferme les trois principaux chemins de fuite reseau : le trafic HTTP/HTTPS passe par le proxy, les requetes DNS sont resolues localement, et les candidats ICE WebRTC sont controles.

Configuration et utilisation

Configuration CLI de base

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns

Deploiement sur serveur headless

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns \
       --headless=new

Integration Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-local-dns',
      '--bot-webrtc-ice=google',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');

  // Verifier que le DNS ne fuit pas
  const ip = await page.evaluate(async () => {
    const res = await fetch('https://httpbin.org/ip');
    return res.json();
  });
  console.log('Detected IP:', ip.origin);

  await browser.close();
})();

Integration Puppeteer

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-local-dns',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Verification

Apres avoir lance BotBrowser avec --bot-local-dns :

1. Naviguez vers un site de test de fuite DNS (comme dnsleaktest.com ou browserleaks.com/dns)
2. Lancez le test etendu, qui effectue plusieurs requetes pour identifier tous les resolveurs
3. Verifiez qu'aucun serveur DNS appartenant a votre FAI n'apparait dans les resultats
4. Confirmez que toutes les requetes DNS sont resolues via les serveurs attendus
5. Verifiez que la localisation du resolveur DNS correspond a la region geographique de votre proxy

Pour une verification automatisee :

const page = await context.newPage();
await page.goto('https://httpbin.org/ip');
const ipResponse = await page.textContent('body');
console.log('HTTP IP:', ipResponse);

// L'IP des requetes HTTP devrait correspondre a l'IP du proxy
// Les requetes DNS ne devraient pas reveler une localisation differente

Bonnes pratiques

1. Utilisez toujours --bot-local-dns avec les proxies. Les fuites DNS sont la faille de confidentialite la plus courante dans les configurations proxy. Ce flag comble la faille au niveau du moteur.

2. Utilisez SOCKS5H pour une protection supplementaire. Combiner socks5h:// avec --bot-local-dns offre deux couches de prevention des fuites DNS.

3. Combinez avec --bot-webrtc-ice. Le DNS et WebRTC sont les deux chemins de fuite reseau les plus courants. Fermez les deux pour une protection complete.

4. Testez avec des tests de fuite DNS etendus. Les tests rapides peuvent ne pas detecter tous les chemins de fuite. Les tests etendus qui effectuent de nombreuses requetes sur une periode plus longue sont plus approfondis.

5. Surveillez le comportement DNS en CI/CD. Si vous executez des pipelines automatises, incluez la verification des fuites DNS comme etape de test pour detecter les erreurs de configuration rapidement.

6. Ne melangez pas les outils DNS systeme avec BotBrowser. Si vous configurez des parametres DNS au niveau du systeme en parallele de --bot-local-dns, l'interaction peut produire des resultats inattendus. Laissez BotBrowser gerer la resolution DNS.

Questions frequentes

Est-ce que --bot-local-dns fonctionne sans proxy ? Oui, le flag active la resolution DNS locale independamment de la configuration du proxy. Cependant, sans proxy, votre veritable IP est visible dans les requetes HTTP, donc la confidentialite DNS seule offre un benefice limite.

Est-ce que --bot-local-dns affecte la vitesse de chargement des pages ? Le resolveur DNS local ajoute un surcout minimal. Dans certains cas, il peut etre plus rapide que de router les requetes DNS via un fournisseur de proxy qui a des serveurs DNS lents ou geographiquement eloignes.

Puis-je utiliser --bot-local-dns avec des proxies HTTP ? Oui. Le flag fonctionne avec tous les protocoles de proxy : SOCKS5, SOCKS5H, HTTP et HTTPS.

Quels serveurs DNS utilise --bot-local-dns ? Le resolveur local gere la resolution DNS au sein du moteur du navigateur, evitant les requetes DNS au niveau du systeme. La strategie de resolution specifique est geree en interne pour assurer la coherence.

Est-ce que --bot-local-dns empeche le prefetching DNS ? Oui. Toute resolution DNS, y compris le prefetching et la resolution speculative, passe par le resolveur local. Aucune requete DNS ne fuit par les chemins de prefetching.

Puis-je combiner --bot-local-dns avec le DoH au niveau du navigateur ? Ce n'est pas recommande. Le flag --bot-local-dns fournit un controle DNS complet. Ajouter le DoH par-dessus peut creer des chemins de resolution conflictuels.

Est-ce que --bot-local-dns est necessaire avec SOCKS5H ? SOCKS5H route deja la resolution des noms d'hote via le proxy. Cependant, --bot-local-dns fournit une protection supplementaire contre le prefetching DNS et d'autres chemins de resolution speculative que SOCKS5H pourrait ne pas couvrir.

Resume

Les fuites DNS sont une faille de confidentialite courante et serieuse qui se produit meme lorsque tout le trafic HTTP passe par un proxy. Le flag --bot-local-dns de BotBrowser comble cette faille au niveau du moteur du navigateur, garantissant qu'aucune requete DNS n'atteint votre FAI ou un resolveur hors de votre controle. Combine avec la configuration du proxy et la protection WebRTC, il fournit une confidentialite reseau complete.

Pour une protection reseau complete, associez la prevention des fuites DNS avec la Configuration du proxy et la Prevention des fuites WebRTC. Pour gerer plusieurs identites avec une isolation reseau complete, consultez Isolation multi-comptes du navigateur.