¿Cómo detectar una fuga de DNS? 4 pasos de revisión

Conclusión clave: si la prueba de IP pasa, solo significa que el punto de salida cambió, no que las consultas DNS sigan el mismo camino. El proxy y el DNS gestionan dos tramos distintos: el proxy decide por qué salida de red sale la conexión, mientras que el DNS convierte los dominios en direcciones IP. Cuando las consultas de resolución siguen una ruta no prevista, hablamos de fuga de DNS. Basta con cuatro pasos para detectarla, aunque interpretar bien los resultados importa más que ejecutar la prueba.

Configuras el proxy, abres una web de pruebas de IP, la página muestra la dirección del proxy y todo parece correcto. Días después, al investigar incidencias en las cuentas, descubres que las consultas DNS siempre habían ido por la red local.

El proxy quizá no tenga culpa: las consultas DNS nunca pasaron por él.

Por qué revisar el DNS aunque el proxy esté activo

El proxy y el DNS son dos tramos separados: activar el primero no implica que el segundo quede también cubierto. El proxy determina por qué salida de red se envía la conexión, y el DNS se ocupa de resolver los nombres de dominio. Son eslabones distintos de la red: un proxy en buen estado no garantiza que las consultas DNS se comporten como se espera.

En la práctica, al visitar un sitio, el cliente o bien obtiene primero la IP del dominio mediante una consulta DNS, o bien entrega el dominio al proxy para que lo procese. La opción depende del protocolo del proxy, de la implementación del cliente y de los ajustes DNS del navegador. Activar el proxy no supone automáticamente que todas las consultas de resolución sigan la ruta prevista: solo una comprobación real permite confirmarlo, con que el panel diga «proxy conectado» no basta.

Conviene delimitar también el alcance: una fuga de DNS no equivale a exponer tu IP pública real. Lo que se filtra es la ruta de las consultas de dominios, que puede revelar al proveedor de resolución o a la red local qué nombres consultaste. Para saber si tu IP real queda expuesta hace falta una prueba de IP independiente. Precisamente por eso la agencia de ciberseguridad de Singapur trata la prueba de fuga DNS y la de fuga de IP como dos comprobaciones separadas en sus recomendaciones de seguridad para VPN: no validan lo mismo (véanse las orientaciones de seguridad VPN de la CSA).

Cómo se produce normalmente una fuga de DNS

Hay tres orígenes muy frecuentes, y todos dependen de la configuración, no de que el proxy funcione o no. Vamos uno por uno.

El proxy solo gestiona parte del tráfico

Algunas configuraciones del proxy solo asumen las peticiones web del navegador, y la resolución corre a cargo del sistema local. Si ocurre así depende del protocolo del proxy y de cómo lo trate el cliente. Cuando las peticiones web van por el proxy pero la resolución va por la red local, en los resultados de la prueba aparece un resolutor local.

El navegador tiene activado su propio DNS seguro

Chrome y Firefox admiten DNS over HTTPS (DoH): al activarlo, las consultas de resolución viajan por una conexión HTTPS cifrada hacia el servicio elegido, lo que reduce las ocasiones de que la red local observe directamente las consultas. Pero cifrar no garantiza que las consultas pasen por el proxy, ni que el servicio escogido encaje con lo previsto en el entorno actual. Esta función de Firefox se puede activar por separado, véase la documentación oficial de Mozilla.

Sistema, navegador y cliente de proxy, cada uno con su resolutor

La más discreta de las configuraciones. El sistema usa un resolutor, el navegador con DoH activado emplea otro y el cliente de proxy añade uno tercero: juntos convierten la ruta de resolución en una caja negra. Con el «conectado» que muestra el software del proxy no basta para saber qué pasa; hay que ver qué camino sigue de verdad el navegador en ejecución.

Si la ruta de resolución termina en el ISP local, las consultas atraviesan su servicio de resolución. Para comparar, puedes consultar el funcionamiento de los proxys ISP y sus casos de uso.

¿Cómo detectar una fuga de DNS? Los cuatro pasos

La prueba en sí es sencilla: lo importante es tener expectativas antes de medir y un punto de comparación después. Solo al completar los cuatro pasos la conclusión se sostiene.

Paso 1: anota primero el resultado esperado. Antes de la prueba deja por escrito tres cosas: en qué región está la salida del proxy actual, quién debería encargarse de la resolución de dominios y si el navegador tiene DoH activado. Sin expectativas, los resultados no se pueden valorar.

Paso 2: ejecuta la prueba con el proxy activado. Usa un sitio que ofrezca pruebas de fuga de DNS, por ejemplo dnsleaktest.com, y pulsa la prueba extendida (Extended test) para que aparezcan más resolutores. También puedes abrir la página de prueba de DNS de BrowserLeaks y ver a qué organizaciones pertenecen los resolutores. Anota sus nombres, organizaciones y regiones.

Paso 3: contrasta el resultado con lo esperado. Comprueba si los resolutores que aparecen encajan con la configuración del sistema, del navegador y del proxy. Si pertenecen al servicio DNS previsto y no surge ninguna ruta local inesperada, la prueba puede considerarse conforme en principio. Si aparece el ISP local o un servicio de resolución desconocido, confirma primero que de verdad no forma parte de la configuración prevista y luego revisa uno a uno el tratamiento DNS del cliente de proxy, el DNS seguro del navegador y los ajustes de red del sistema, sin dar por hecho de inmediato que el proxy falló. Una prueba aislada solo refleja las condiciones del momento y no garantiza que todas las consultas estén libres de problemas.

Paso 4: cambia un ajuste y vuelve a probar. Si hay que retocar algo, toca un solo punto cada vez: el tratamiento DNS del cliente de proxy, el interruptor DoH del navegador o los ajustes de red del sistema; después repite la prueba y compara. Si cambias varias cosas a la vez, no sabrás cuál surtió efecto.

Cómo interpretar los resultados

El mismo resultado, bien leído, es una pista; mal leído, lleva a un juicio equivocado. Así se trata cada uno de los cinco casos habituales:

Hay otra trampa: Anycast y nodos distribuidos ocultan la salida real.

¿En qué se diferencian la fuga de DNS, la de WebRTC y la huella del navegador?

Cuatro comprobaciones para cuatro tipos de información: superar una no asegura las demás. Vistas juntas, los límites quedan claros:

DNS y WebRTC son los dos que más se confunden, porque en ambos aparece la palabra «fuga». Sin embargo, sus principios de prueba y sus soluciones no tienen nada que ver. La detección y configuración de la fuga de WebRTC se trataron en un artículo aparte, así que aquí no lo repetimos. Además, la fuga de IPv6 es otro miembro de la misma familia: comprueba si una dirección IPv6 se salta el proxy. El método está descrito en la guía para detectar fugas de IPv6.

Estos cuatro puntos reflejan información distinta y ninguno sustituye a los demás. Al revisar un entorno con proxy, conviene confirmar primero la IP pública, seguir con el DNS y el WebRTC, y cerrar con la huella y la configuración del entorno; los puntos concretos dependen de cada escenario.

Cómo encajar estas comprobaciones en tu flujo de trabajo con MostMate

El orden recomendado es: primero la salida, después la resolución, luego WebRTC y por último la configuración del entorno. Cuando gestionas varios entornos de navegador con MostMate, conviene separar la prueba de conectividad del proxy de la prueba de fuga de DNS.

Lo primero es la configuración del proxy. Tras vincular un proxy al entorno, comprueba el estado de la conexión con la prueba de proxy del propio producto, repasando también el tipo de protocolo (HTTP, HTTPS, SOCKS5, SSH) y los datos de autenticación. Recuerda que una prueba de proxy satisfactoria no sustituye a la prueba de fuga de DNS: la ruta real de las consultas DNS sigue dependiendo de la configuración del cliente de proxy, del navegador y del sistema.

Después abre la página de prueba de DNS en un entorno con el proxy vinculado, siguiendo los cuatro pasos de antes, y comprueba si la procedencia de los resolutores coincide con lo esperado.

Lo segundo es el aislamiento del propio entorno. En escenarios con varias cuentas, el proxy, las cookies y los parámetros de huella de cada entorno deben ser independientes, sin préstamos entre ellos. El alcance exacto del aislamiento se detalla en el alcance y la configuración del aislamiento de entornos de navegador. Si a un entorno se le asigna un proxy erróneo o la configuración se comparte, los resultados de la prueba pierden valor de comparación. El aislamiento facilita gestionar sesiones y configuraciones distintas, pero no implica que la ruta DNS sea correcta por arte de magia, ni sustituye a una verificación externa.

Lo tercero es no perder de vista los límites: el navegador antidetección se encarga de tener el entorno bien ordenado, pero que el proxy funcione de verdad y que el DNS siga la ruta prevista se comprueba con pruebas externas. Que un test salga bien tampoco lo soluciona todo para siempre: tras un cambio de configuración o una actualización del sistema, conviene repetir la prueba.

Preguntas frecuentes

El proxy está activo, pero la prueba de DNS muestra un resolutor local. ¿Significa que el proxy no funciona?

No necesariamente. Puede que el proxy solo asuma las peticiones web y que la resolución la lleven el sistema o el navegador por su cuenta. Revisa uno a uno el tratamiento DNS del cliente de proxy y los ajustes DoH del navegador, cambiando un solo punto antes de cada prueba.

¿Una fuga de DNS expone mi IP real?

No se puede equiparar así. Una fuga de DNS muestra la ruta de las consultas de resolución de dominios, y qué información queda realmente expuesta depende de la configuración de red y del escenario de prueba. Para saber si tu IP pública real está oculta hace falta una prueba de IP independiente; la ruta de resolución se comprueba por separado.

¿Puede producirse una fuga de DNS usando un navegador antidetección?

Sí, puede. El navegador antidetección gestiona el aislamiento del entorno y los parámetros de huella, mientras que el comportamiento del DNS depende del protocolo del proxy y de la configuración del sistema y el navegador. La prueba no se puede saltar.

La prueba de DNS ya ha pasado. ¿Qué queda por revisar?

Quedan la fuga de WebRTC y la huella del navegador, cada una con su herramienta correspondiente. Cuando todo esté superado, la revisión de la capa de red del entorno estará completa.

Conclusión

El valor de la prueba de fuga de DNS no está en obtener un «aprobado» o un «suspendido», sino en confirmar que las peticiones de red del entorno actual se comportan como se espera. La IP pública, el DNS, el WebRTC y la huella del navegador tienen cada uno su método de comprobación, y el resultado de uno no reemplaza la verificación de los demás. Con el navegador antidetección que sea, conviene repetir la prueba tras cualquier cambio de proxy o de configuración de red.

Si necesitas gestionar varios entornos de navegador, empieza por conocer la configuración de entornos y la gestión de proxys de MostMate, y después valida cada punto siguiendo los pasos de este artículo. Para dejar la capa de proxy más firme, puedes descargar MostMate: la versión gratuita incluye dos entornos, perfecto para completar primero todo el ciclo de pruebas en el primero.