Cada vez que abres un sitio, tu dispositivo le pide a un resolutor que convierta el nombre de dominio en una dirección IP. Esa pregunta es un registro en texto plano de adónde estás a punto de ir, y por defecto va al resolutor que te haya asignado la red, normalmente el de tu operador de internet.
Una fuga de DNS es cuando esas consultas van a un sitio al que no querías mandarlas. El caso habitual es un dispositivo configurado para usar un resolutor privado o cifrado que, por alguna de varias razones estructurales, sigue enviando parte o la totalidad de las consultas al operador de todos modos. No se rompe nada visible, y por eso las fugas duran años sin que nadie las note.
¿Qué expone realmente el DNS?
El dominio, la marca de tiempo y el origen, que es suficiente para reconstruir una sesión de navegación.
El DNS clásico va sin cifrar por el puerto 53. Cualquiera situado entre tú y el resolutor puede leer la consulta, y el propio resolutor las ve todas atribuidas a tu conexión. No ve la página concreta, pero el dominio suele ser la parte sensible.
El cifrado cambia quién guarda ese registro, no si el registro existe:
| Transporte | ¿Cifrado? | Quién ve la consulta |
|---|---|---|
| DNS en claro (puerto 53) | No | Tu red, tu operador, el resolutor |
| DNS over TLS (DoT, puerto 853) | Sí | El resolutor que elegiste |
| DNS over HTTPS (DoH, puerto 443) | Sí | El resolutor que elegiste; más difícil de distinguir del tráfico web para la red |
| DNSSEC | No: lo que hace es autenticar | Igual que el DNS en claro; demuestra que las respuestas son auténticas, no las oculta |
DNSSEC es la entrada que más se malinterpreta. Firma las respuestas para que no se puedan falsificar. No aporta confidencialidad alguna.
¿Cómo se producen las fugas?
Seis causas estructurales cubren casi todas.
| Causa | Mecanismo |
|---|---|
| Enrutado dividido | Parte del tráfico va por un túnel, el DNS sale por la interfaz por defecto |
| IPv6 sin cubrir | El túnel solo maneja IPv4, así que las consultas IPv6 toman la ruta del operador |
| Resolución paralela del sistema | Windows puede consultar todas las interfaces a la vez y quedarse con la primera respuesta |
| DoH en el navegador | El navegador resuelve al margen de la configuración del sistema, en cualquiera de los dos sentidos |
| Imposición del router | El router fuerza su propio resolutor por DHCP o intercepta el puerto 53 |
| Portal cautivo | Las redes de hoteles o aeropuertos secuestran el DNS para forzar su página de acceso |
Vale la pena detallar el caso del navegador, porque corta por los dos lados. Un navegador con su propia configuración de DoH puede saltarse un resolutor de sistema cuidadosamente configurado, y al revés: un navegador bien configurado puede tapar el hecho de que todo lo que hay fuera de ese navegador sigue con fugas. Comprobar uno y dar el otro por bueno es el error de test más frecuente.
¿Cómo se comprueba?
Prueba cada capa por separado, porque pueden contradecirse.
Sistema operativo, qué resolutores están configurados:
| Sistema | Comando |
|---|---|
| macOS | scutil --dns | grep nameserver |
| Windows | Get-DnsClientServerAddress |
| Linux (systemd-resolved) | resolvectl status |
| Linux (genérico) | cat /etc/resolv.conf |
Qué resolutor respondió de verdad, porque configuración y comportamiento no son lo mismo:
dig +short whoami.akamai.net devuelve la dirección IP del resolutor que hizo la
consulta en tu nombre. Compárala con el resolutor que esperabas.
A nivel de navegador: abre la opción de DNS seguro del navegador y fíjate en si está activada y qué proveedor hay seleccionado. Luego carga una página de test de fugas de DNS en ese navegador. Si la página informa de un resolutor distinto al de tu prueba por línea de comandos, el navegador está resolviendo por su cuenta.
IPv6: repite la comprobación con una consulta solo por IPv6. Un túnel que solo transporta IPv4 es, por sí solo, la causa más frecuente de fuga parcial.
¿Cómo se interpreta el resultado?
Compara quién es el dueño del resolutor con lo que esperabas, no con una lista de direcciones «buenas».
| Observación | Interpretación |
|---|---|
| El resolutor pertenece a tu operador y tú configuraste otro | Fuga |
| Varios resolutores, uno de ellos tu operador | Fuga parcial: las consultas van repartidas |
| IPv4 muestra el resolutor esperado, IPv6 muestra el del operador | Fuga por IPv6 |
| El navegador y el sistema informan de resolutores distintos | No es necesariamente una fuga, pero son dos rutas independientes que verificar |
| El resolutor está en un país inesperado | Suele ser normal: los resolutores anycast responden desde el nodo más cercano |
| El resolutor es la dirección privada del router | No concluyente; el router reenvía hacia arriba, así que revisa la configuración del propio router |
Esa última fila es la que atrapa a la gente en redes domésticas. Un resultado de
192.168.1.1 solo te dice que respondió tu router. Adónde reenvía el router es
otra pregunta, y se responde en los ajustes de WAN o de DNS del router.
¿Qué límites tiene arreglar esto?
Arreglar una fuga de DNS cambia quién se entera de qué dominios has consultado. No hace que la visita sea privada, y exagerar este punto es la principal forma en que se tergiversa el tema.
Una vez resuelto el nombre, tu dispositivo abre una conexión a esa dirección IP. Cualquier observador en la ruta ve la dirección de destino y, en la mayoría de las conexiones TLS, el nombre del servidor viaja sin cifrar en el handshake salvo que se use Encrypted Client Hello en ambos extremos. Las dos señales identifican el sitio con independencia del DNS.
Así que el resumen honesto es estrecho pero real: usar DNS cifrado hacia un resolutor que tú elijas saca de tu red local y de los registros de tu operador la lista en texto plano de todos los dominios que visitas, y traslada esa lista al operador del resolutor. Mueve la confianza en lugar de eliminarla, y eso convierte en la pregunta que de verdad importa quién opera el resolutor y qué registra.