Cómo las fugas de DNS exponen tu ubicación incluso con VPN

Una VPN encripta tu tráfico y lo enruta por un servidor de salida. Esa parte funciona. Lo que es menos confiable, en Windows específicamente, es asegurar que cada consulta DNS también tome ese camino. Cuando hay fuga de DNS, tu ISP ve los dominios que visitás aunque todo lo demás esté encriptado. La fuga es silenciosa: tu navegador no muestra advertencia, el cliente VPN dice que estás conectado, y tu ISP igual está logueando cada sitio que consultás.

Este post explica las cuatro rutas de fuga comunes, cómo testearlas, y cómo Fexyn las cierra.

De dónde vienen las fugas

1. Smart Multi-Homed Name Resolution (SMHNR)

Windows 8 introdujo una función llamada Smart Multi-Homed Name Resolution. Envía consultas DNS simultáneamente a cada servidor DNS disponible y usa la respuesta que llega primero. La intención era acelerar la resolución DNS para usuarios con múltiples interfaces de red.

El resultado, con una VPN corriendo: tus consultas DNS van tanto al resolver de la VPN (dentro del túnel) COMO al resolver de tu ISP (fuera del túnel) al mismo tiempo. Tu ISP ve la consulta sin importar si la respuesta de la VPN gana la carrera.

Esto cambió levemente en Windows 10: SMHNR se supone que prefiera el túnel VPN cuando existe uno. En la práctica, no siempre lo hace. El comportamiento depende del orden de métricas de adaptadores, del Network Connectivity Status Indicator (NCSI), y cuál interfaz Windows considera "primaria" en cada momento. Las fugas son intermitentes, que es la peor clase: un test puntual pasa, pero el uso real filtra.

2. Caída a IPv6

La mayoría de los protocolos VPN sólo tunelizan IPv4. Si tu ISP te da conectividad IPv6 (la mayoría lo hace, en 2026) y tu computadora prefiere IPv6 sobre IPv4, entonces las consultas DNS pueden tomar la ruta IPv6. La consulta IPv6 sale por tu interfaz real, llega al resolver DNS IPv6 de tu ISP, y tu ISP ve la consulta.

Esto no es teórico: es el comportamiento por defecto en Windows desde hace una década. La solución es deshabilitar IPv6 en la interfaz subyacente mientras la VPN está activa, o tunelizar el tráfico IPv6 por la VPN.

3. DNS-over-HTTPS en el navegador

Chrome, Firefox, Edge y Brave modernos pueden hacer DNS-over-HTTPS a un resolver público (Cloudflare, Google, Quad9, NextDNS). Cuando DoH está activo, el navegador evita por completo la capa DNS del sistema.

Esto es bueno para la privacidad frente a tu ISP: DoH a Cloudflare es más privado que el resolver de tu ISP. Es malo para el DNS tunelizado por VPN, porque el navegador ahora le habla a Cloudflare directamente a través de la interfaz subyacente (DoH usa HTTPS, que el SO enruta por la interfaz activa, y eso es el túnel de la VPN sólo si la VPN tuneliza todo).

El resultado: los testeadores de fuga DNS que esperan que todo el DNS venga del resolver de la VPN marcan a los navegadores con DoH como "filtrando." Si esto es realmente una fuga depende del modelo de amenaza que te importe.

4. WebRTC y STUN

WebRTC es una API de navegador para conexiones peer-to-peer. Usa servidores STUN para descubrir tu IP pública. El intercambio STUN opera por encima de la pila de red: el navegador conoce tu IP real localmente y simplemente se la dice a la página cuando se le pregunta.

Esto no es una fuga DNS per se, pero es adyacente. Una página corriendo WebRTC puede aprender tu dirección IP real incluso con la VPN activa y con todo tu DNS pasando por el túnel. Es un fix completamente distinto.

Lee la pieza sobre WebRTC para eso.

Cómo testear

Usá la herramienta de test de fugas DNS de Fexyn mientras la VPN está conectada. Dos verificaciones:

Test estándar. Una sola tanda de consultas. Detecta fugas consistentes.
Test extendido. Seis rondas espaciadas en el tiempo. Detecta fugas intermitentes de SMHNR o carreras de prioridad de adaptadores.

El resultado debería mostrar sólo resolvers operados por el proveedor VPN. Si muestra los resolvers de tu ISP (o el nombre de tu ISP en cualquiera de las entradas), tenés una fuga.

Qué ve un atacante o ISP de una fuga

Cada consulta DNS filtrada les da:

El dominio exacto que estás consultando
El timestamp
La frecuencia (si pasa repetidamente)
El patrón de tu navegación: qué sitios se correlacionan con otros

Esto es suficiente para construir un perfil detallado de navegación. El tráfico encriptado en sí mismo es opaco, pero los destinos no. Tu ISP sabe lo que navegás sin nunca ver los contenidos.

En países que retienen logs de consultas DNS por defecto (Reino Unido bajo la Investigatory Powers Act, Francia bajo la Loi Renseignement, otros), las fugas se vuelven registros de largo plazo. La ventana de retención varía; la existencia de los registros no.

Cómo Fexyn previene fugas en Windows

El helper service de Fexyn instala una defensa por capas:

Reglas de Name Resolution Policy Table (NRPT). NRPT opera a nivel del SO, antes de que cualquier aplicación vea la solicitud DNS. Fexyn instala reglas NRPT catch-all que fuerzan cada consulta de dominio por el resolver de la VPN. NRPT sobrescribe configuraciones DNS por adaptador, configuraciones manuales y SMHNR. Es el cerrojo a nivel del SO sobre el routing de DNS.

Configuración DNS por protocolo. Cada protocolo VPN (WireGuard, VLESS Reality, OpenVPN) está configurado con su propia ruta DNS. WireGuard usa el catch-all de AllowedIPs. VLESS usa tun2socks con un override de DNS de túnel. OpenVPN empuja DNS vía dhcp-option DNS. Los tres convergen en el resolver VPN.

Null-routing de IPv6. Cuando la VPN está activa, Fexyn null-routes el tráfico IPv6. En lugar de esperar que IPv6 tome el túnel (a veces no lo hace), todo el tráfico IPv6 se enruta a un destino nulo local. Esto elimina la ruta de fuga IPv6 por completo. La conectividad IPv4 por el túnel no se ve afectada.

Kill switch de Windows Filtering Platform. Si el túnel se cae, los filtros WFP bloquean todo el tráfico que no sea por el túnel, incluyendo DNS. No hay ventana de fuga durante reconexiones.

La combinación aborda SMHNR (NRPT lo sobrescribe), caída a IPv6 (null-routed) y fugas por caída de túnel (WFP bloquea). DoH en el navegador queda intacto: es elección del usuario si usar un resolver DoH público o el de la VPN.

Qué hacer si estás filtrando

Si el test muestra fugas, trabajá en orden:

Reconectá la VPN. El fix más simple. Las reglas NRPT a veces se desfasan después de ciclos de sleep/resume o tras una actualización de Windows. Una conexión fresca las re-aplica.
Probá un protocolo distinto. Cambiá a Fexyn Stealth (VLESS Reality) o Fexyn Secure (OpenVPN). Cada uno tiene una ruta DNS distinta; si uno está mal configurado para tu red, otro puede no estarlo.
Probá un servidor distinto. Algunos resolvers de servidores son más lentos; si el resolver está dropeando consultas, el SO puede caer al resolver del sistema.
Verificá si hay otros clientes VPN corriendo. Cloudflare WARP, Meshnet de NordVPN, Tailscale, clientes VPN corporativos: múltiples VPNs instalan reglas NRPT que compiten y se pelean entre sí. Cerrá (no sólo desconectes) cualquier otra VPN.
Deshabilitá DoH del navegador temporalmente. Si querés que todo el DNS fluya por el túnel para fines de testeo, apagá el DoH a nivel navegador para la sesión de test.

La guía completa de troubleshooting está en la página de soporte.

Relacionados

Probá Fexyn gratis 7 días. El cerrojo de DNS está activo por defecto; no tenés que habilitarlo.