Prevención de fugas DNS: rutas de resolución, proxies y pruebas

Un proxy cambia el origen aparente del tráfico de las páginas, pero el navegador sigue necesitando convertir cada nombre de host en una dirección antes de conectarse. Si esa consulta llega a un resolutor que está fuera de la ruta del proxy, el resolutor sabe qué dominios se pidieron y desde qué red, aunque la página se haya cargado a través del proxy. Ese hueco es una fuga DNS, y es una de las causas más habituales de que una configuración con proxy resulte incoherente. BotBrowser puede mantener coherentes la configuración de proxy y de DNS de un contexto controlado durante una prueba; no puede controlar los resolutores ni las redes ajenos a ese navegador.

Corregirlo es una cuestión de propiedad: para cada consulta, quién resuelve el nombre, dónde está ese resolutor y quién puede leer sus registros. Las secciones siguientes responden a esas preguntas para SOCKS5, SOCKS5H y HTTP CONNECT, comparan las mitigaciones habituales y el hueco que deja cada una, y terminan con una prueba de fugas que trata cualquier discrepancia como una comprobación fallida.

TL;DR

• socks5:// puede resolver localmente; socks5h:// envía el nombre de host al proxy.
• Una carga de página limpia no demuestra que prefetch, dns-prefetch, IPv4 e IPv6 usen el resolutor esperado.
• Registra el operador y la región esperados, y trata cualquier resolutor inexplicable como una comprobación fallida.

Contents

• Quién resuelve el nombre de host
• Qué revela una fuga
• Precarga y otras consultas que requieren atención aparte
• Elegir entre SOCKS5H, DNS local, DNS del sistema, DoH y DNS de VPN
• Ejecutar una prueba de fugas e interpretar el resultado
• Conclusión

Quién resuelve el nombre de host

La entrada del glosario de MDN sobre DNS describe el sistema que asigna direcciones IP a los nombres de dominio. El navegador necesita esa asignación antes de abrir una conexión, de modo que cada navegación, recurso incrustado y solicitud en segundo plano plantea la misma pregunta: qué componente realiza la consulta. Con un proxy en el camino hay varios candidatos, y el esquema del proxy decide cuál responde.

Tres disposiciones habituales se comportan de forma distinta:

• SOCKS5. El navegador resuelve el nombre con un resolutor local y entrega al proxy una dirección IP. La consulta ocurre fuera de la ruta del proxy, así que el resolutor de la red local ve el nombre.
• SOCKS5H. El navegador entrega al proxy el propio nombre de host y es el proxy quien lo resuelve. No se consulta al resolutor local por los nombres que viajan por esa conexión.
• HTTP CONNECT. El navegador indica el host de destino en la solicitud del túnel y el servidor proxy se conecta a él. La resolución del destino suele ocurrir en el lado del proxy.

Existe además un cuarto caso, junto a los esquemas de proxy: el navegador puede resolver los nombres con su propio resolutor en lugar del del sistema operativo. Esa elección cambia a qué resolutor se pregunta y con qué servidores contacta, pero por sí sola no indica si la respuesta se usa para una conexión directa o se entrega al proxy. Trata la resolución del lado del navegador y la del lado del proxy como dos interruptores independientes, y anota el valor de cada uno.

La especificación de SOCKS5, RFC 1928, permite que el cliente envíe al proxy una dirección o un nombre de dominio. El esquema socks5h:// que usan los navegadores y las herramientas de línea de comandos es una convención del cliente para elegir la segunda forma. Lee el esquema de tu configuración al pie de la letra: socks5:// y socks5h:// son decisiones distintas, y una sola letra traslada la consulta de tu equipo al proveedor.

Trasladar la consulta al proxy no la vuelve privada. Cuando el proxy resuelve un nombre, el proveedor decide qué resolutor ascendente responde, en qué región está, si las respuestas se guardan en caché o se filtran y qué se registra. Esas decisiones son propias de cada proveedor, quedan fuera de tu control y la mayoría no las publica de un modo que puedas comprobar. El artículo sobre configuración de proxy detalla los esquemas, pero la etiqueta del esquema nunca demuestra por sí sola adónde fue una consulta. La única evidencia es la verificación.

Qué revela una fuga

Un resolutor de tu red local o de tu proveedor de internet ve los nombres de dominio que se le piden, la hora de cada consulta y la dirección de red que preguntó. Si el tráfico de la página pasa por el proxy mientras los nombres se resuelven en local, ese resolutor puede reconstruir igualmente una lista de sitios visitados, aunque nunca vea el contenido de las páginas. HTTPS protege la página, pero no oculta la consulta de tipo A o AAAA que la precede.

La segunda exposición es geográfica. Los resolutores se operan en regiones concretas y muchas redes asignan resolutores cercanos al cliente. Si la salida del proxy está en Alemania y las consultas llegan desde un resolutor que sirve a tu región de origen, las dos señales no coinciden. Que un servicio concreto las compare o no varía, y nadie puede prometer lo uno ni lo otro. Aun así, una discrepancia es motivo para considerar la configuración incoherente, porque el objetivo de la ruta es que sus señales coincidan.

La tercera son los registros que no controlas. Un resolutor puede conservar los nombres que respondió. Apuntar el navegador a otro resolutor cambia quién guarda esos registros sin eliminarlos. Por eso la pregunta útil nunca es si el DNS está oculto, sino qué operador puede ver estos nombres, en qué región, y si es el operador y la región que elegiste.

Las familias de direcciones también importan. Un navegador que puede usar IPv4 e IPv6 podría llegar a un destino por una familia que la ruta del proxy no cubre, de modo que una prueba que mire solo una familia puede pasar por alto una fuga. Comprueba qué familias de direcciones admiten tu proxy y la prueba de fugas, y compáralas con el comportamiento que esperas.

Precarga y otras consultas que requieren atención aparte

Los navegadores resuelven nombres antes de que se les pida cargarlos. Una página con muchos enlaces puede provocar consultas en segundo plano para los destinos de esos enlaces, y la barra de direcciones puede resolver un nombre de host mientras la persona aún escribe. Estas consultas especulativas, incluidas prefetch y dns-prefetch, siguen la ruta de resolución del navegador, no la de la conexión que abriste a propósito. Si esa ruta sale de la del proxy, los nombres filtrados incluyen sitios que nunca se visitaron.

Por eso un proxy que gestiona bien todas las conexiones explícitas puede seguir mostrando un resolutor local en una prueba de fugas. Las solicitudes de la página, las indicaciones de precarga y las consultas en segundo plano deben comprobarse por separado, y no equivalen a una sola carga de página. WebRTC plantea una cuestión relacionada pero distinta, sobre direcciones y no sobre nombres, que trata el artículo sobre prevención de fugas de WebRTC.

Puedes probar las consultas especulativas sin depender de una página de pruebas pública. Usa un dominio que controles, cuyo servidor de nombres autoritativo registre las consultas, publica una página que enlace a un nombre de host único bajo ese dominio, ábrela a través de la ruta configurada y mira qué direcciones de resolutor aparecen en el registro del servidor. Una consulta que llegue desde una dirección que no pertenece ni a tu proveedor ni al resolutor que elegiste es una fuga que una prueba de una sola página no habría mostrado.

La caché complica el panorama. Un nombre resuelto antes en la misma sesión puede responderse desde memoria más tarde, así que un resultado limpio en la segunda visita demuestra poco. Inicia el navegador desde cero, usa nombres de host que no se hayan resuelto antes y repite la comprobación tras cada cambio de configuración.

Los modos de fallo también difieren. Cuando un resolutor configurado no está disponible, algunas configuraciones cambian en silencio a otro, y ese cambio es una ruta nueva que la prueba descrita más abajo debe detectar. Prefiere configuraciones que fallen de forma visible frente a las que desvían las consultas en silencio, y confirma cuál es tu caso bloqueando el resolutor en un entorno de pruebas propio y observando qué hace el navegador.

Elegir entre SOCKS5H, DNS local, DNS del sistema, DoH y DNS de VPN

Ningún control cierra todos los huecos, así que la comparación útil es el hueco residual que deja cada uno. Cuatro preguntas ordenan las opciones: quién resuelve el nombre, en qué región, quién puede registrarlo y si el ajuste afecta solo a este navegador o a toda la máquina.

SOCKS5H. Mantiene los nombres que viajan por la conexión del proxy lejos del resolutor local y no necesita ninguna función del navegador aparte del esquema. Sus huecos son el resolutor ascendente del propio proveedor, que no puedes inspeccionar, los proxies que no admiten resolución remota y las consultas que el navegador hace fuera de la conexión con proxy.

DNS local del navegador con --bot-local-dns. El resolutor integrado de BotBrowser mantiene la resolución independiente del comportamiento DNS del proveedor, lo que ayuda cuando un proveedor bloquea, reescribe o ralentiza las consultas. Su hueco es que solo gobierna el lado del navegador. No cambia lo que hace un proveedor con una conexión que él mismo resuelve y, si lo apuntas a un servidor DNS concreto, ese servidor pasa a ser un nuevo observador en el que tienes que confiar.

DNS del sistema. Configurar el sistema operativo con un resolutor elegido sustituye el resolutor de tu proveedor de internet por otro. No elimina al observador, y el nuevo resolutor suele estar en una región sin relación con el proxy. Además, el ajuste no dice nada sobre si un nombre concreto lo resuelve el navegador o el proxy.

DNS sobre HTTPS. La RFC 8484 transporta los mensajes DNS sobre HTTPS, lo que impide que los observadores del camino de red los lean o los alteren. El resolutor sigue viendo todos los nombres, su región tiene que seguir coincidiendo con la ruta y el ajuste no decide quién realiza la consulta. El artículo sobre DNS sobre HTTPS trata los controles del navegador y los límites del resolutor.

DNS de VPN. Una VPN suele llevar el DNS del sistema operativo por su túnel, lo que cubre todas las aplicaciones a la vez. Es demasiado burdo para un enrutamiento por navegador o por contexto, el resolutor del operador de la VPN ve los nombres y la región del resolutor sigue la salida de la VPN, no una salida de proxy independiente.

Las combinaciones ayudan cuando los huecos no se solapan, por ejemplo SOCKS5H más un resolutor del lado del navegador elegido a propósito. También añaden decisiones, y cada elemento nuevo es otro observador u otro lugar donde puede aparecer una discrepancia. Elige el conjunto más pequeño cuyos observadores sepas nombrar y después pruébalo.

Una regla práctica ayuda cuando la elección no es evidente. Si el proveedor admite SOCKS5H y confías en su resolutor, empieza por ahí y verifica. Si el proveedor bloquea, reescribe o ralentiza las consultas, o solo ofrece SOCKS5, un resolutor del lado del navegador te da una política que no depende del DNS del proveedor. Si otras aplicaciones de la máquina también necesitan protección, eso es tarea del sistema operativo o de una VPN, no de un parámetro del navegador.

Ejecutar una prueba de fugas e interpretar el resultado

Una prueba de fugas es útil cuando se ejecuta siempre del mismo modo y se lee frente a una expectativa fija. Una secuencia repetible:

1. Anota la dirección de salida del proxy, su país y el operador que el proveedor indica para ella.
2. Inicia el navegador desde cero con los parámetros exactos que piensas usar.
3. Abre una prueba de fugas como dnsleaktest.com y ejecuta su prueba extendida, que hace varias consultas en lugar de una.
4. Apunta cada resolutor que informe la prueba, con su operador y su región.
5. Compara esa lista con el paso 1. Cada resolutor debe pertenecer a un operador y a una región que sepas explicar.

Trata cualquier diferencia como una comprobación fallida. Un resolutor de tu proveedor de internet, un resolutor en un país que no coincide con la salida o un operador que no elegiste significan que la ruta y las consultas no coinciden. No expliques la diferencia con una conjetura; cambia una sola variable, como el esquema del proxy o el parámetro de DNS local, y repite la prueba. Compara operador y región, no direcciones exactas, ya que los operadores grandes responden desde muchas direcciones de la misma región.

El patrón del resultado apunta a la causa. El resolutor de tu propio proveedor suele significar que un nombre se resolvió en local, así que revisa el esquema y si la precarga está cubierta. Un resolutor público conocido en la región equivocada apunta al DNS del sistema operativo, a un ajuste de DoH o a una VPN. Un resolutor en la región correcta pero de un operador inesperado apunta a la elección ascendente del proveedor, que solo puedes cambiar cambiando de proveedor.

Una prueba de fugas tiene límites. Muestra los resolutores que los servidores de la propia prueba vieron en ese momento para los nombres de host que usó. No observa consultas de otros nombres, no muestra los registros del lado del proveedor y no puede demostrar el anonimato. Un resultado limpio es evidencia de que una ruta coincidió un día concreto.

Un segundo límite es el alcance. La resolución de nombres es solo una de varias rutas de red. La exposición de direcciones por WebRTC, la dirección de salida del propio proxy y el comportamiento de transporte de la conexión son comprobaciones aparte, y que la prueba DNS salga bien no dice nada sobre ellas.

Los parámetros siguientes son la forma documentada de ejecutar BotBrowser con un proxy SOCKS5H y el resolutor local:

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

La misma configuración desde Playwright, con las rutas del ejecutable y del perfil tomadas del entorno:

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

Cuando distintos contextos del navegador usan proxies distintos, la expectativa es por contexto. Cada contexto tiene su propia salida, su propia región y, por tanto, su propio operador de resolutor esperado, así que ejecuta la secuencia una vez por ruta y conserva los resultados lado a lado. Un único resultado limpio para una ruta no dice nada sobre una segunda ruta que use otro proveedor.

Decide de antemano qué ocurre tras una comprobación fallida. Lo que mejor funciona es una respuesta acotada: detener la ejecución, conservar la configuración y la lista de resolutores observada, y cambiar una variable cada vez. Evita los bucles de reintentos que siguen enviando tráfico mientras las consultas siguen sin explicación, y evita recopilar más que el operador y la región que necesitas.

Repite la comprobación siempre que cambien el proveedor de proxy, el esquema, los parámetros o la versión del navegador, y limita el registro a operador y región. El historial de navegación no pertenece a un registro de pruebas. Para la cuestión más amplia de mantener coherentes las señales de dirección, DNS y WebRTC, consulta coherencia entre proxy, DNS y WebRTC.

Qué soporta BotBrowser y qué queda fuera de su alcance

El parámetro --bot-local-dns figura en la documentación como una función ENT Tier1. El parámetro sin valor o con true resuelve mediante el resolutor integrado del navegador, false lo desactiva para que el proxy resuelva los nombres, y un valor IP o IP:port envía las consultas únicamente a ese servidor DNS, con el puerto 53 por defecto. Un valor no válido se trata como false. Cuando un servidor personalizado no devuelve respuesta, BotBrowser no recurre al resolutor del sistema. Para las conexiones de proxy admitidas, la documentación indica además que la selección de destino de doble pila se mantiene alineada con la ruta activa del proxy sin otro parámetro.

BotBrowser documenta --bot-local-dns (ENT Tier1) como un resolutor DNS integrado que mantiene la resolución de nombres independiente del comportamiento DNS del proveedor de proxy, y enruta las consultas de precarga DNS por la misma ruta del proxy, de modo que un equipo puede aplicar una política DNS repetible y verificarla con una prueba de fugas. BotBrowser no puede controlar ni garantizar el DNS ascendente del proveedor de proxy, los servidores DNS o los registros fuera del navegador, ni la interpretación de una prueba de fugas, y no sustituye la elección de SOCKS5H ni de un proveedor de confianza.

En la práctica son dos tareas separadas. El lado del navegador es configurable y repetible, y el lado del proveedor es una decisión sobre en quién confiar que ningún parámetro puede tomar por ti. Anota junto a cada configuración el esquema elegido, el ajuste de DNS local, el operador de resolutor esperado y la región esperada, de modo que un cambio posterior se vea como una diferencia frente a una expectativa registrada. Consulta la documentación de prevención de fugas DNS para conocer la semántica vigente de los valores antes de cambiar una configuración de producción.

Conclusión

Elige la ruta de resolución más pequeña cuyo operador y región puedas nombrar. Verifícala con una sesión nueva y nombres de host nunca usados, incluye las consultas especulativas y ambas familias de direcciones, y detén el despliegue cuando el resolutor observado no pueda explicarse por la política del proxy.

Fuentes

• Documentación de BotBrowser: prevención de fugas DNS
• MDN: DNS
• RFC 8484: consultas DNS sobre HTTPS (DoH)
• RFC 1928: SOCKS versión 5
• Prueba de fugas DNS