La versión corta: un túnel VPN cifra los paquetes IP que tu dispositivo envía a otros servidores. DNS es la consulta que ocurre antes de que se envíe el paquete — tu dispositivo preguntando «¿qué dirección IP corresponde a example.com?» Si esa consulta va al resolver de tu ISP en lugar de pasar por la VPN, tu ISP ve el dominio aunque nunca vea el tráfico cifrado que le sigue. Eso es una fuga. Anula la promesa principal de privacidad de una VPN por la razón más sencilla posible: se consultó al resolver DNS equivocado. La buena noticia es que las fugas son fáciles de detectar, normalmente fáciles de corregir, y la mayoría de las aplicaciones VPN bien construidas las previenen por defecto. La mala noticia es que «la mayoría» no significa «todas», y unas pocas configuraciones habituales provocan fugas incluso en instalaciones VPN correctas en todo lo demás.
Qué hace DNS y por qué se producen fugas
DNS — el Domain Name System — es la guía de teléfonos de internet. Cada vez que tu dispositivo se conecta a un sitio web, primero tiene que traducir el nombre de host legible por humanos (example.com) a una dirección IP numérica (algo como 93.184.216.34) a la que los routers puedan reenviar paquetes. Ese paso de traducción es una consulta DNS, y es una operación de red separada de la solicitud web real que viene después.
En una conexión doméstica típica, tu resolver DNS es asignado por tu ISP mediante DHCP — el mismo mecanismo que entrega tu dirección IP. Cuando te conectas al Wi-Fi, el router le dice a tu dispositivo «tu servidor DNS es 192.168.1.1, que reenvía al resolver recursivo de tu ISP». Cada dominio que consultas pasa por ese resolver. El ISP puede registrarlo, venderlo a un bróker de datos (en Estados Unidos esto es legal) o entregarlo a las fuerzas del orden.
Cuando conectas una VPN, deberían ocurrir dos cosas. Primero, tu tráfico de red se cifra y se enruta a través del túnel VPN. Segundo, tu resolver DNS debería cambiar — del resolver del ISP a uno operado por el proveedor VPN (o un resolver de terceros centrado en privacidad), accesible solo a través del túnel cifrado. Si solo ocurre la primera mitad, tienes una fuga de DNS. El tráfico está cifrado pero las consultas previas siguen llegando al ISP, que así conoce cada sitio que estás a punto de visitar.
Desde el punto de vista de la privacidad, la consulta DNS es casi tan reveladora como el propio tráfico. La consulta revela el dominio exacto (hasta el subdominio — mail.example.com es distinguible de www.example.com) y el momento en que se realiza. Combinado con el volumen de tráfico cifrado inmediatamente después, una VPN con fuga de DNS le proporciona a un observador los metadatos suficientes para reconstruir tu sesión de navegación en casi todos los sentidos relevantes.
Las cuatro formas en que se produce una fuga de DNS
Las fugas de DNS no son un único bug. Son una familia de configuraciones incorrectas relacionadas, cada una con una causa raíz distinta y una solución diferente. En orden aproximado de frecuencia:
1. Bypass del sistema operativo — Windows split DNS / Smart Multi-Homed Name Resolution
Windows tiene una función llamada Smart Multi-Homed Name Resolution que, cuando está activa, envía las consultas DNS en paralelo a todos los resolvers DNS disponibles — incluido el del ISP en la interfaz física, aunque haya una VPN activa. Gana el resolver que responda más rápido; los demás se ignoran, pero las consultas ya han sido enviadas. En la mayoría de los equipos Windows esta opción está activada por defecto. La solución es desactivar la función mediante la Directiva de grupo o configurando el cliente VPN para que lo haga al conectarse. Linux tiene un problema similar con systemd-resolved si no está configurado correctamente; macOS e iOS gestionan esto mejor, pero no de forma perfecta.
2. Configuración incorrecta del túnel dividido
El split tunneling te permite enrutar algunas aplicaciones a través de la VPN y otras a través de tu conexión normal. Un error de configuración habitual es configurar el split tunneling por aplicación sin configurar también el DNS por aplicación — lo que significa que una aplicación enrutada fuera del túnel VPN sigue intentando usar el resolver DNS de la VPN, o viceversa, y acaba filtrando por el camino que proporcione el sistema operativo. Una variante peor: el túnel dividido enruta correctamente el tráfico TCP de la aplicación fuera del túnel, pero el resolver DNS del sistema sigue siendo el del ISP, por lo que todas las aplicaciones — tunelizadas o no — filtran sus consultas DNS al ISP. Abordamos este tema con más profundidad en nuestro artículo sobre qué hace realmente el split tunneling.
3. Fallback por IPv6
Muchos clientes VPN fueron diseñados cuando IPv4 era la única preocupación de enrutamiento. Instalan reglas de firewall y enrutamiento IPv4 que enrutan correctamente el DNS a través del túnel, pero no instalan las reglas IPv6 equivalentes. Si tu red tiene conectividad IPv6, el sistema operativo a veces preferirá IPv6 para las consultas DNS — y esas consultas salen por la interfaz directa, evitando la VPN por completo. Este es uno de los modos de fuga más comunes en 2026 y es especialmente frecuente en conexiones de banda ancha residencial con doble pila IPv4/IPv6 del ISP. La solución es desactivar IPv6 globalmente (contundente pero fiable) o usar un cliente VPN que gestione explícitamente las rutas IPv6.
4. WebRTC y DNS resuelto por el navegador
Los navegadores modernos — Chrome, Edge, Firefox, Safari — pueden realizar consultas DNS por sí mismos en lugar de usar el resolver del sistema operativo. El caso más conocido es WebRTC, el protocolo de comunicación entre pares usado en las videollamadas. WebRTC utiliza servidores STUN para descubrir tus direcciones IP locales y públicas reales, y históricamente las difundía aunque hubiera una VPN activa. La IP «real» de WebRTC ha sido una filtración clásica del lado del navegador que requiere mitigación explícita. Por separado, los navegadores que usan DNS-over-HTTPS (DoH) pueden enrutar las consultas DNS directamente a Cloudflare, Google o NextDNS independientemente del resolver del sistema operativo — lo que a veces ayuda (DoH hacia un resolver público es más privado que texto plano hacia el ISP) y a veces perjudica (el resolver público sigue viendo tus consultas, y el navegador está saltándose las reglas DNS de la VPN).
Cómo detectar una fuga de DNS en menos de un minuto
Detectar una fuga de DNS lleva más tiempo describirlo que hacerlo. Conecta tu VPN y visita cualquiera de estas tres herramientas. Cada una revela aspectos ligeramente diferentes de la superficie de fuga.
dnsleaktest.com
La clásica. Visita dnsleaktest.com, haz clic en «Extended test» y espera unos 20 segundos. La herramienta emite una serie de consultas DNS para nombres de host únicos que controla, y luego te muestra qué resolvers realizaron realmente esas búsquedas. Si ves el nombre de tu ISP (Comcast, Verizon, BT, etc.) en la lista de resolvers, estás filtrando. Si ves únicamente el resolver del proveedor VPN (o un resolver público centrado en privacidad como Quad9 o el 1.1.1.1 de Cloudflare), la ruta DNS del sistema es correcta.
browserleaks.com/dns
Más detallado que dnsleaktest. Muestra no solo qué resolvers gestionaron la consulta, sino también su ubicación geográfica, el ASN (el operador de red) y si admiten DNS-over-HTTPS o DNS-over-TLS. Útil para detectar fugas sutiles en las que se utiliza el tipo correcto de resolver pero está en el país equivocado, o para confirmar que se está usando realmente un protocolo DNS cifrado.
ipleak.net
El más completo — comprueba fugas de DNS, fugas de WebRTC, visibilidad de IPv4 e IPv6, y muestra cuál es tu geolocalización aparente. La sección de WebRTC es crítica: si ves una dirección IP «local» en el rango 192.168.x.x o 10.x.x.x junto a una IP «pública» que coincide con tu endpoint VPN, la VPN está haciendo su trabajo pero el navegador está filtrando a través de WebRTC. La sección de IPv6 detecta fugas de fallback IPv6 que dnsleaktest a veces pasa por alto.
Cómo es un resultado limpio frente a uno con fugas
En el test extendido de dnsleaktest.com con una VPN correctamente configurada, deberías ver algo así:
Test results (clean):
Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands
Server: 1.2.3.5 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands
Conclusion: No DNS leak detected. All queries went to the VPN's resolver.
Y así es como se ve una fuga:
Test results (leaking):
Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands
Server: 75.75.75.75 Hostname: cdns01.comcast.net ISP: Comcast Country: United States
Server: 75.75.76.76 Hostname: cdns02.comcast.net ISP: Comcast Country: United States
Conclusion: DNS leak detected. ISP resolver (Comcast) received queries.
La señal clave es la columna ISP. Si aparece algo que no sea tu proveedor VPN (o un resolver público elegido deliberadamente), tu DNS está filtrando. Si la columna de país muestra tu país real junto al país del punto de salida VPN, estás filtrando. Si solo aparece el país del endpoint de tu VPN, todo está limpio.
Comparación de tipos de fugas
Cada uno de los cuatro tipos de fuga tiene una huella característica en los resultados del test, un conjunto diferente de observadores que pueden aprovecharlo y una solución distinta:
| Tipo de fuga | Qué filtra | Quién puede verlo | Cómo solucionarlo |
|---|---|---|---|
| Bypass del SO (Windows SMHNR) | Todas las consultas DNS, en paralelo | ISP, operador de Wi-Fi público, cualquiera en la ruta | Desactivar SMHNR mediante Directiva de grupo o registro; usar un cliente VPN que lo gestione |
| Configuración incorrecta del túnel dividido | Consultas DNS de aplicaciones que deberían estar tunelizadas | ISP, operador de red local | Auditar las reglas del túnel dividido; asegurarse de que el DNS esté tunelizado para las apps protegidas |
| Fallback por IPv6 | Consultas DNS solo por la ruta IPv6 | ISP si ofrece IPv6; cualquiera en la ruta IPv6 | El cliente VPN debe instalar reglas IPv6 equivalentes; o desactivar IPv6 |
| WebRTC / DoH del navegador | IPs locales, más consultas DNS del navegador | Cualquier peer WebRTC, más el resolver elegido por el navegador | Desactivar WebRTC en el navegador; alinear el DoH del navegador con el resolver de la VPN |
Cómo solucionar las cuatro causas habituales
Solucionar fugas de bypass del SO (Windows)
En Windows 10 y 11, desactiva Smart Multi-Homed Name Resolution mediante la Directiva de grupo (Configuración del equipo → Plantillas administrativas → Red → Cliente DNS → «Desactivar la resolución de nombres multitarjeta inteligente» → Habilitado) o mediante PowerShell: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. Reinicia. Algunos clientes VPN bien mantenidos hacen esto automáticamente al conectarse — si el tuyo no lo hace, hazlo manualmente.
Solucionar fugas de túnel dividido
Audita tu conjunto de reglas de split tunneling. Para cada aplicación que deba estar protegida, verifica que tanto su tráfico TCP como sus consultas DNS estén enrutados a través del túnel. Algunos clientes VPN permiten configurar el DNS por aplicación; la mayoría no. Si el tuyo no lo permite, la opción más segura es desactivar el split tunneling por completo y usar un túnel completo — que enruta todo (incluido todo el DNS) a través de la VPN. Para la mayoría de los usuarios, la comodidad del split tunneling no compensa el riesgo de fuga.
Solucionar fugas de IPv6
La solución más fiable es usar un cliente VPN que admita IPv6 dentro del túnel (o que al menos instale reglas de firewall IPv6 equivalentes que bloqueen el tráfico IPv6 cuando el túnel está activo). Si no puedes cambiar de cliente, desactiva IPv6 en la interfaz de red física: en Windows, en las propiedades del adaptador; en macOS, en Ajustes del sistema → Red → Avanzado → TCP/IP. Es una medida contundente (pierdes la conectividad IPv6 por completo) pero elimina el vector de fuga.
Solucionar fugas de WebRTC
En Firefox, establece media.peerconnection.enabled en false en about:config. En Chrome y Edge, instala una extensión como WebRTC Network Limiter o la opción de bloqueo WebRTC de uBlock Origin. Safari gestiona WebRTC de forma más conservadora por defecto, aunque en algunas configuraciones aún puede filtrar IPs locales; Safari 17+ mejoró esto notablemente. Comprueba el resultado con ipleak.net tras el cambio.
Por qué «usa una VPN» por sí solo no garantiza la ausencia de fugas
Existe una suposición generalizada de que conectarse a una VPN previene automáticamente las fugas de DNS. No es así — la prevención depende de que el cliente VPN haga una serie de cosas correctamente: cambiar el resolver DNS del sistema, instalar reglas de firewall para bloquear el DNS directo al ISP, gestionar IPv6, desactivar el SMHNR de Windows (o funciones equivalentes de bypass a nivel del SO) y sobrevivir a los cambios de red (cambios de Wi-Fi, ciclos de suspensión/activación) sin reintroducir la fuga.
Un cliente VPN bien construido hace todo esto automáticamente y no tienes que pensar en ello. Uno mal construido — o una VPN «gratuita» que usa el perfil VPN integrado del SO sin ninguna protección adicional contra fugas — hace solo un subconjunto de esas cosas, dejando vectores de fuga abiertos. La única forma de saber en qué categoría estás es ejecutar realmente un test de fugas después de conectarte. Si el resultado sale limpio, puedes dejar de preocuparte; si muestra fugas, tienes problemas concretos que resolver y ya sabes cuáles son.
Prevención de fugas de DNS en iOS, Android, Mac y Windows
iOS
iOS gestiona el DNS a través del framework NetworkExtension. Una aplicación VPN bien construida usa el objeto NEDNSSettings para especificar un resolver personalizado que se usa mientras el túnel está activo. iOS lo aplica a nivel del SO — las aplicaciones no pueden saltarse el DNS configurado sin permiso explícito. El principal vector de fuga en iOS es iCloud Private Relay, que (cuando está activado junto a una VPN) puede enrutar el DNS a través del resolver de Apple en lugar del de la VPN. Si usas una VPN por privacidad, desactiva iCloud Private Relay para evitar conflictos entre ambos. iOS 14 añadió el indicador includeAllNetworks (usado frecuentemente junto al comportamiento de kill switch) que garantiza que incluso el DNS del sistema pasa por el túnel.
Android
La API VpnService de Android permite que el cliente VPN especifique servidores DNS que se aplican a todo el tráfico tunelizado. El ajuste de sistema «VPN siempre activa» con «Bloquear conexiones sin VPN» habilitado ofrece la garantía más sólida — ninguna aplicación puede resolver DNS sin que el túnel esté activo. Android también admite DNS privado a nivel de sistema (Ajustes → Red e internet → DNS privado), que fuerza todo el DNS a usar DNS-over-TLS con el proveedor elegido. Combinar la VPN siempre activa con el DNS privado ofrece doble protección contra fugas de DNS.
macOS
macOS usa scutil y el framework System Configuration para gestionar la configuración DNS. Un cliente VPN que funciona a través del framework NetworkExtension puede instalar ajustes DNS con prioridad mientras el túnel está activo. El principal vector de fuga en macOS es el DNS-over-HTTPS a nivel de navegador, que evita por completo el resolver del sistema — desactiva el DoH a nivel de navegador o configúralo para que apunte al mismo resolver que la VPN. Usa scutil --dns en el Terminal para ver los resolvers activos; solo debería aparecer el resolver de la VPN en la sección de máxima prioridad.
Windows
Windows tiene la mayor superficie de fuga de todos los sistemas operativos principales, principalmente por Smart Multi-Homed Name Resolution. Además de desactivar SMHNR (descrito más arriba), verifica que el adaptador virtual de la VPN tenga mayor prioridad de métrica que el adaptador físico, que IPv6 esté desactivado o correctamente tunelizado, y que ninguna aplicación tenga sus propias anulaciones de DNS configuradas. Windows 11 añadió una interfaz de usuario mejorada para los ajustes DNS, pero el comportamiento subyacente es similar al de Windows 10. El comando ipconfig /all muestra los resolvers activos por interfaz.
Qué hacen las buenas aplicaciones VPN internamente para prevenir fugas
Un cliente VPN bien diseñado no te pide que pienses en las fugas de DNS. Las gestiona como parte fundamental del proceso de conexión. En concreto:
- Configura un resolver personalizado al conectarse. El cliente le dice al SO «mientras estoy conectado, todas las consultas DNS van a esta dirección IP concreta» — normalmente el propio resolver del proveedor VPN, accesible solo a través del túnel. El cliente también restaura la configuración DNS anterior al desconectarse.
- Instala reglas de firewall para bloquear el DNS directo. Incluso si alguna aplicación intenta consultar un servidor DNS por su cuenta (por ejemplo, una consulta a 8.8.8.8 hardcodeada), la regla de firewall bloquea el paquete saliente en el puerto UDP 53. El único DNS que puede salir del dispositivo es el que fluye por el túnel.
- Usa DNS cifrado (DoT o DoH) dentro del túnel. Incluso una vez que la consulta está dentro del túnel, el salto del resolver al servidor está cifrado con DNS-over-TLS (RFC 7858) o DNS-over-HTTPS, de modo que el operador ascendente no puede ver el contenido de la consulta. Nuestro artículo sobre DNS-over-HTTPS vs DNS-over-TLS cubre las ventajas e inconvenientes de ambos protocolos.
- Gestiona IPv6 explícitamente. Las rutas IPv6 se tunelizarán a través de la VPN (preferible) o se bloquearán en el firewall para evitar el fallback IPv6. El cliente nunca deja el enrutamiento IPv6 sin configurar.
- Se combina con un kill switch. Si el túnel cae momentáneamente, el kill switch bloquea todo el tráfico — incluido el DNS — hasta que el túnel se restablezca. Esto evita la condición de carrera «el túnel cayó, el DNS filtró, el túnel volvió». Lo explicamos en detalle en qué es un kill switch de VPN.
- Realiza pruebas en cada conexión. Algunos clientes ejecutan un test de fugas integrado después de cada conexión y alertan al usuario de cualquier anomalía. Esto es poco habitual, pero es el modelo más robusto posible.
Casper's Cloak usa un resolver DNS personalizado accesible únicamente dentro del túnel WireGuard, cifrado de extremo a extremo mediante DNS-over-TLS, con rutas IPv6 explícitamente tunelizadas y el SMHNR de Windows desactivado en el momento de la instalación. La función de protección contra amenazas realiza filtrado a nivel DNS contra dominios maliciosos conocidos en el mismo resolver, de modo que el mismo DNS protegido contra fugas también bloquea activamente el phishing y el malware. El mecanismo está documentado en nuestro artículo sobre cómo funciona realmente el filtrado a nivel DNS. El efecto combinado: correctamente configurado por defecto, sin fugas en ninguno de los cuatro modos de fallo habituales, y con filtrado activo por encima.
Para más contexto sobre el protocolo subyacente, la especificación IETF de DNS-over-TLS está documentada en RFC 7858, que cubre los requisitos criptográficos y de capa de transporte para enviar DNS sobre un canal seguro TLS. El mismo marco es el que usan los resolvers públicos centrados en privacidad (Cloudflare, Quad9, NextDNS) para sus endpoints DNS seguros.
Conclusión: una fuga de DNS es la forma más habitual en que la promesa de privacidad de una VPN falla en silencio. Es fácil de detectar, normalmente fácil de corregir, y cualquier VPN en la que confíes debería pasar un test de fugas sin intervención manual. Si la tuya no lo hace, eso es una señal — o hay una configuración incorrecta, o es hora de cambiar.