Red

Prevención de fugas DNS: Mantén tu actividad de navegación privada

Cómo las fugas DNS exponen tu actividad de navegación y ubicación real, y cómo enrutar la resolución DNS a través de tu proxy para privacidad completa.

Documentación

Prefieres la documentación del producto mantenida?

Este artículo tiene una página equivalente en el centro de documentación. Usa los docs para el flujo canónico, las flags actuales y la referencia duradera.

Introducción

Cuando usas un proxy para proteger tu identidad de navegación, esperas que todo el tráfico pase por ese proxy. Sin embargo, las consultas DNS a menudo siguen una ruta distinta. Antes de que el navegador pueda conectar con un sitio a través del proxy, debe resolver el nombre de dominio a una IP. Si esa consulta DNS se envía al resolvedor de tu ISP en lugar de pasar por el proxy, el ISP ve cada dominio que visitas. Esto es una fuga DNS y es una de las formas más comunes en que fallan las configuraciones de privacidad basadas en proxies.

BotBrowser aborda las fugas DNS en el nivel del motor del navegador mediante la opción --bot-local-dns, que habilita un resolvedor DNS local integrado que mantiene la resolución bajo tu control.

Impacto en la privacidad

Las fugas DNS socavan la privacidad del proxy de varias maneras. El resolvedor DNS del ISP registra cada dominio resuelto, creando un registro completo de tu actividad de navegación, incluso cuando todo el tráfico HTTP/HTTPS pase por el proxy. El ISP ve los nombres de dominio, los tiempos de las solicitudes y tu IP real.

Además, las consultas DNS revelan ubicación geográfica, ya que los resolvedores son regionales. Si usas un proxy en Alemania pero tus consultas DNS se resuelven en Virginia, la discrepancia geográfica es evidente. Los sistemas de seguimiento que correlacionan la ubicación del resolvedor DNS con la IP informada pueden detectar esta inconsistencia.

Las fugas DNS también pueden ocurrir por vías menos obvias: el prefetching DNS puede resolver dominios antes de que hagas clic; WebRTC puede provocar búsquedas DNS fuera del camino del proxy; algunas configuraciones de proxy manejan TCP pero no protegen las consultas DNS basadas en UDP.

El control de DNS a nivel de motor de BotBrowser cierra todas estas vías.

Antecedentes técnicos

Cómo funciona la resolución DNS en los navegadores

Al navegar a https://example.com, el navegador debe resolver example.com a una IP antes de establecer la conexión. El proceso usualmente sigue:

  1. El navegador revisa su caché DNS interna
  2. Si no está en caché, consulta el resolvedor DNS del sistema operativo
  3. El resolvedor del SO consulta su caché y luego reenvía la consulta a los servidores DNS configurados (habitualmente del ISP)
  4. El servidor DNS responde con la IP

Con un proxy configurado, el comportamiento ideal depende del protocolo:

  • SOCKS5H: el navegador envía el nombre de host al proxy, que resuelve DNS. No ocurre consulta DNS local.
  • SOCKS5: el navegador resuelve DNS localmente y envía la IP al proxy. Aquí ocurre una fuga DNS.
  • HTTP CONNECT: el navegador manda el host en la petición CONNECT; la resolución depende de la implementación.

Prefetching DNS y resolución especulativa

Los navegadores modernos prefetchan registros DNS para reducir latencia. Cuando una página contiene enlaces, el navegador puede resolver esos dominios antes de que los visites. Este prefetching ocurre en el motor del navegador y puede no respetar la configuración del proxy en todas las situaciones.

Asimismo, los navegadores realizan resolución especulativa de dominios que aparecen en la barra de direcciones mientras escribes; por defecto estas consultas pasan por el resolvedor del SO, creando rutas de fuga difíciles de controlar solo con ajustes de proxy.

Problemas con el DNS del proveedor de proxy

Incluso si las consultas DNS pasan por el proxy (como con SOCKS5H), el comportamiento DNS del proveedor puede ser problemático:

  • El proveedor puede usar servidores DNS en una región distinta a la del proxy
  • Las respuestas pueden ser almacenadas en caché o reescritas
  • El proveedor puede bloquear ciertos dominios por política
  • El soporte de DoH/DoT varía entre proveedores
DNS Leak Path vs. Protected Path DNS Leak (without --bot-local-dns): Browser ISP DNS Proxy Destination DNS leak! Protected (with --bot-local-dns): BotBrowser Local DNS Proxy Destination All traffic via proxy No DNS queries reach ISP. All resolution happens locally or through the proxy tunnel.

Enfoques comunes y sus limitaciones

Usar SOCKS5H en lugar de SOCKS5

Cambiar socks5:// por socks5h:// indica al navegador que envíe nombres de host al proxy para resolución en lugar de resolverlos localmente. Es un buen primer paso, pero tiene limitaciones:

  • El prefetching DNS puede seguir usando el resolvedor local para búsquedas especulativas
  • El comportamiento DNS del proveedor del proxy queda fuera de tu control
  • No todos los protocolos de proxy admiten resolución DNS remota
  • El comportamiento de caché DNS interno del navegador varía según la implementación

Configuración DNS a nivel de sistema

Configurar el SO para usar servidores DNS específicos (Cloudflare 1.1.1.1, Google 8.8.8.8) evita que el ISP vea las consultas, pero esos servidores siguen viendo las consultas. Su ubicación geográfica puede diferir de la del proxy y generar inconsistencias. Además, no aborda el prefetching interno del navegador.

DNS-over-HTTPS (DoH)

Chromium soporta DoH, que encripta consultas DNS. Esto impide que el ISP lea el tráfico DNS, pero el proveedor DoH aún ve las consultas y tu IP real (en muchas configuraciones las solicitudes DoH no pasan por el proxy). DoH mejora confidencialidad pero no necesariamente elimina la ruta de fuga.

Protección a nivel de VPN

Un VPN normalmente enruta todas las consultas DNS a través del túnel, lo cual es efectivo pero añade la sobrecarga del túnel completo. Para usuarios que necesitan control por navegador o por contexto, un VPN es demasiado amplio.

Enfoque de BotBrowser

La opción --bot-local-dns

La opción --bot-local-dns de BotBrowser (ENT Tier1) habilita un resolvedor DNS local integrado en el motor del navegador:

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

Esto controla la resolución DNS en la pila de red, lo que significa:

  • Todas las consultas DNS se manejan localmente. Ninguna consulta llega al resolvedor del ISP.
  • El prefetching respeta la configuración del proxy. Las búsquedas especulativas no filtran información.
  • WebRTC y otros protocolos no pueden provocar búsquedas DNS sin protección. La protección cubre todas las rutas de red.
  • La protección es invisible para los sitios web. No hay diferencias observables desde la página.

Cuándo usar --bot-local-dns

Esta opción es útil cuando:

  • El proveedor del proxy bloquea o reescribe consultas DNS
  • Necesitas comportamiento DNS consistente entre ejecuciones
  • Quieres evitar políticas DNS del proveedor
  • Usas SOCKS5 (no SOCKS5H) y quieres evitar fugas por resolución local

Combinación con otras protecciones de red

Para privacidad de red completa, combina protección DNS con ajustes de proxy y WebRTC:

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

Esta configuración cierra las tres rutas principales de fuga: tráfico HTTP/HTTPS por proxy, DNS resuelto localmente y candidatos ICE de WebRTC controlados.

Configuración y uso

Configuración CLI básica

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

Despliegue en servidor headless

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

Integración con 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');

  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();
})();

Integración con 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();
})();

Verificación

Tras lanzar BotBrowser con --bot-local-dns:

  1. Visita un sitio de prueba de fugas DNS (dnsleaktest.com o browserleaks.com/dns)
  2. Ejecuta la prueba extendida para realizar múltiples consultas y detectar todos los resolvedores
  3. Comprueba que no aparezcan servidores DNS de tu ISP
  4. Verifica que las consultas DNS se resuelvan a través de los servidores esperados
  5. Confirma que la ubicación del resolvedor DNS coincide con la región de tu proxy

Ejemplo de verificación automatizada:

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

// La IP HTTP debería coincidir con la del proxy
// Las consultas DNS no deberían revelar una ubicación distinta

Buenas prácticas

  1. Usa siempre --bot-local-dns con proxies. Las fugas DNS son la brecha de privacidad más común en configuraciones de proxy.

  2. Combina con socks5h:// para mayor protección. socks5h:// + --bot-local-dns ofrece capas adicionales.

  3. Úsalo junto con --bot-webrtc-ice. DNS y WebRTC son las rutas de fuga más habituales; ciérralas ambas.

  4. Realiza pruebas extendidas de fugas DNS. Las pruebas rápidas pueden no detectar todas las vías.

  5. Monitoriza DNS en CI/CD. Añade verificación de fugas DNS en pipelines automáticos para detectar malconfiguraciones.

  6. No mezcles herramientas DNS del sistema con BotBrowser. La interacción puede producir resultados inesperados. Deja que BotBrowser gestione la resolución.

Preguntas frecuentes

¿Funciona --bot-local-dns sin proxy? Sí, habilita resolución DNS local, pero sin proxy la IP real seguirá apareciendo en peticiones HTTP.

¿Afecta al rendimiento de carga? La sobrecarga es mínima; a veces es más rápido que servidores DNS de proveedores lentos o lejanos.

¿Funciona con proxies HTTP? Sí. --bot-local-dns es compatible con SOCKS5, SOCKS5H, HTTP y HTTPS.

¿Qué servidores DNS usa --bot-local-dns? El resolvedor local maneja la resolución dentro del motor para evitar consultas a nivel de SO; la estrategia interna gestiona la consistencia.

¿Bloquea el prefetching? Sí. Todas las resoluciones, incluido el prefetching y la resolución especulativa, pasan por el resolvedor local.

¿Puedo combinar --bot-local-dns con DoH? No se recomienda; --bot-local-dns ya controla las rutas de resolución y DoH puede generar conflictos.

¿Necesito --bot-local-dns si uso SOCKS5H? SOCKS5H enruta resolución por el proxy, pero --bot-local-dns añade protección contra prefetching y rutas especulativas que SOCKS5H puede no cubrir.

Resumen

Las fugas DNS son una brecha de privacidad frecuente y crítica. --bot-local-dns de BotBrowser cierra esta brecha a nivel del motor, evitando que consultas DNS lleguen a ISP u otros resolvedores fuera de tu control. Combinado con configuración de proxy y protección WebRTC, ofrece privacidad de red integral.

Para protección completa, combina esto con Proxy Configuration y WebRTC Leak Prevention; para gestión de identidades con aislamiento de red, consulta Multi-Account Browser Isolation.

#Dns#Leak-Prevention#proxy#Privacy#Network

Lleva BotBrowser de la investigación a producción

Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.