Para evaluar la fiabilidad de una VPN, la pregunta no es solo «¿cifra bien?», sino: ¿pasa realmente todo mi tráfico, incluidas mis consultas DNS, por el túnel? Una fuga de DNS es uno de los puntos ciegos más problemáticos: no revela tu dirección IP, pero expone tus hábitos de navegación —los sitios visitados, a qué hora, con qué frecuencia—. Exactamente lo que una VPN se supone que protege. Todo ello sin alerta ni indicación visible: solo una exposición silenciosa.

Lo que una fuga de DNS realmente revela

El DNS traduce un nombre de dominio en una dirección IP; cada sitio visitado genera una consulta identificable. Una consulta DNS expone el dominio exacto visitado, la hora precisa, la frecuencia de las visitas y el resolvedor usado. El contenido no se filtra, pero el recorrido es visible —suficientemente rico para establecer un perfil—. A distinguir de la fuga de IP (tu IP real aparece fuera del túnel: gravedad inmediata). La fuga de DNS hace visible tu navegación sin exponer la IP: gravedad variable según el modelo de amenaza (no crítica pero real en uso estándar, crítica en uso sensible —periodismo, activismo, censura—). Una VPN confiable apunta a cero fugas, sea cual sea el uso.

Las 4 causas reales

  • El SO elige la interfaz «más eficiente»: con varias interfaces (wifi, Ethernet, túnel), si la VPN no impone correctamente su prioridad, algunas consultas pasan por la interfaz física. Frecuente en Windows, intermitente en macOS, raro en Linux.
  • Split tunneling sin gestión del DNS: una aplicación excluida del túnel resuelve sus nombres de dominio fuera del túnel, vía el proveedor de Internet —y apps que comparten la misma pila de red pueden seguir el mismo camino—.
  • IPv6 no admitido o mal bloqueado: muchas VPN siguen siendo solo IPv4; en una red IPv6, las consultas AAAA salen directamente (IPv4 = servidores de la VPN, IPv6 = servidores del proveedor de Internet: fuga confirmada).
  • Aplicaciones con resolvedor DNS integrado (DoH/DoT): Firefox, Chrome, ciertas mensajerías o juegos gestionan su propio DNS; esas consultas ya no pasan por el túnel sino que salen hacia Cloudflare/Google. La aplicación sortea deliberadamente el sistema, pero el efecto es idéntico.

Fugas de DNS y dual-stack: el riesgo IPv6

En los sistemas en dual-stack (IPv4 e IPv6 activos simultáneamente), una conexión VPN puede proteger el tráfico IPv4 mientras deja escapar las consultas DNS IPv6. Si el cliente VPN no admite explícitamente IPv6 —ya sea enrutándolo en el túnel, ya sea desactivándolo— las resoluciones toman la pila IPv6 local y salen hacia los servidores DNS del sistema, casi siempre los del proveedor de Internet. El tráfico IPv4 se encapsula correctamente, pero los dominios visitados siguen siendo visibles: una fuga silenciosa, invisible para el usuario, particularmente común allí donde IPv6 está activado por defecto (Windows, macOS, la mayoría de las distribuciones Linux).

Comprobar una fuga de DNS: método progresivo

Prueba rápida en el navegador

  1. Activa la VPN.
  2. Abre DNSLeakTest en modo Extended, BrowserLeaks DNS o IPLeak.net.
  3. Ejecuta la prueba completa y revisa los servidores DNS detectados.
  4. Repite el control después de reconectar la red o cambiar entre wifi y datos celulares.

Resultado normal: los servidores pertenecen a la VPN o corresponden al resolvedor que configuraste de forma deliberada. Resultado anormal: aparece un servidor de tu proveedor de Internet, permanece un resolvedor IPv6 local o la ubicación del DNS sigue siendo la de tu conexión aunque el servidor VPN esté en otro país. Una sola línea fuera del recorrido previsto basta para señalar una fuga.

La prueba rápida se limita al navegador, puede cubrir mal IPv6 y depende de un servicio externo. Es un buen diagnóstico inicial, no una prueba exhaustiva.

Prueba avanzada: captura de red

Wireshark en Windows, macOS o Linux

Wireshark permite ver la interfaz utilizada y el destino real de las consultas. Inicia una captura en la interfaz física y aplica uno de estos filtros:

dns
udp.port == 53 || tcp.port == 53

Si aparecen consultas DNS en la interfaz física cuando deberían permanecer dentro del túnel, la fuga está confirmada. Este control no detecta automáticamente todo el DNS cifrado mediante HTTPS o TLS: también hay que observar las conexiones hacia los resolvedores DoH/DoT configurados.

tcpdump en Linux o macOS

sudo tcpdump -i en0 -n port 53

Reemplaza en0 por la interfaz física de tu sistema. La herramienta resulta útil para confirmar una fuga intermitente después de una reconexión.

Herramientas y límites

  • DNSLeakTest Extended: simple y claro, pero con cobertura limitada de IPv6.
  • BrowserLeaks DNS: ofrece más detalles sobre el navegador e IPv6, sin cubrir todas las aplicaciones.
  • IPLeak.net: permite cruzar DNS, IPv4, IPv6 y WebRTC.
  • Wireshark: el control más completo, aunque requiere más conocimientos de red.
  • tcpdump: ligero y directo, pero exige conocer la interfaz observada.

Corregir una fuga de DNS

Lo que debe hacer una VPN confiable: kill switch de DNS, DNS binding estricto, gestión correcta o bloqueo limpio del IPv6, y mantenimiento de las reglas DNS durante las reconexiones. Lo que tú puedes hacer: desactivar DoH/DoT en el navegador, desactivar temporalmente el IPv6 si la VPN no lo admite, limitar el split tunneling, probar tras cada actualización de SO/VPN, e identificar las aplicaciones que usan un DNS interno (mensajerías, juegos, P2P).

DoH/DoT: ¿protección o elusión?

DoH/DoT protege tus consultas DNS frente a tu proveedor de Internet o a una red local hostil, pero con una VPN activa crea un conflicto de enrutamiento: la VPN pierde el control del DNS, las consultas salen hacia Cloudflare, Google o Quad9, y transfieres la confianza de la VPN hacia un resolvedor de terceros. En la práctica: si confías en la VPN, desactiva DoH/DoT en el navegador; si no confías en ella, un DoH/DoT local es coherente —pero entonces cuestiona el interés de usar esa VPN—; y combinar ambos sin entenderlo rompe la cadena de protección.

Lo que una fuga de DNS no muestra

Para evitar fantasías: una fuga de DNS no expone tu IP real, ni el contenido de tus comunicaciones cifradas, ni tus credenciales, ni las páginas exactas visitadas en un dominio. Lo que muestra realmente: los dominios visitados, la frecuencia, la cronología y los servicios usados —suficiente para perfilar un comportamiento—.

Acción inmediata. Conecta la VPN, ejecuta una prueba extendida y repítela después de una reconexión. Si vuelve a aparecer un DNS de tu proveedor de Internet pese a una configuración correcta, es una señal directa sobre la madurez técnica del cliente VPN.

La fuga de DNS, barómetro de madurez de una VPN

Una fuga de DNS no es un detalle técnico: es una prueba de madurez estructural. Una VPN confiable debe dominar las interfaces de red, el IPv6, el split tunneling, los resolvedores DNS y las reconexiones —en particular la gestión del dual-stack, donde IPv6 suele seguir activo por defecto y puede resolver fuera del túnel si el cliente no lo integra explícitamente—. Una VPN que deja escapar consultas DNS no protege tu actividad: la fragmenta. La fiabilidad no se evalúa sobre una promesa de marketing, sino sobre un comportamiento observable —una prueba DNS completa, repetida tras una reconexión—. Consulta también la velocidad de los protocolos y el panorama.