Prueba de fuga de DNS: el nombre del resolutor no es la ruta
El nombre de un resolutor no puede decirte si el DNS evitó el túnel. Decide la política que querías y luego compara el destinatario, la ruta y las excepciones.
Tres disposiciones cuentan como DNS correcto para un usuario de VPN: consultas al resolutor del operador, consultas a un resolutor cifrado que hayas elegido y DNS dividido que envía los nombres de trabajo a la organización. Una prueba de fuga informa de un resolutor, y esa única etiqueta no puede decirte qué disposición tienes en realidad. Decide primero la política prevista y luego prueba contra ella. De lo contrario, comparas un número con una sensación.
Decide qué querías antes de leer el resultado
Nombra la política en una frase: todos los nombres al resolutor de la VPN, todos los nombres a un resolutor cifrado elegido, o DNS dividido con los nombres internos hacia la organización. Cada una es defendible para un usuario distinto, y cada una produce una respuesta esperada distinta. Sin esa frase, cualquier resultado que difiera de una captura en un hilo de foro parece alarmante. Escribe la política antes de la primera prueba.
Una prueba realizada antes de definir la política no mide nada. Produce un nombre de resolutor sin ningún punto de referencia.
Un nombre de resolutor no demuestra ni la ruta ni el destinatario
Importan dos preguntas: quién recibió la consulta y qué ruta la transportó. Se puede llegar a un resolutor de terceros a través del túnel mientras una pantalla de ajustes muestra la dirección del proveedor. La etiqueta de una página de prueba de fuga describe la visión del observador, no tu tabla de enrutamiento.
Un navegador puede usar su propio DNS cifrado mientras el tráfico del sitio pasa por el túnel, y las respuestas en caché pueden permitir que una página cargue sin una consulta nueva. Por eso un resultado de IP pública no dice nada sobre DNS. DoH y DoT protegen la consulta en el trayecto hasta el resolutor, y ese resolutor sigue viendo los nombres.
resolvectl status
resolvectl query example.com
dig +short example.com
El DNS dividido hace correctos varios resolutores
Una organización puede enviar los nombres internos a su propio DNS y todo lo demás a otro lugar. Por eso una prueba que enumera varios resolutores puede describir la política prevista y no una avería. Compara el conjunto observado con las reglas de DNS dividido documentadas antes de desactivar nada. Apagar el resolutor interno para que una página de prueba se vea más limpia rompe los nombres privados.
El enrutamiento dividido y el DNS dividido son decisiones distintas: uno enruta paquetes, el otro enruta preguntas. Cambiar una ruta del túnel no mueve una consulta de nombre, y cambiar el resolutor no arregla la ruta de un sitio web. IPv6 es una tercera cuestión, ya que una conexión IPv6 no deseada no es automáticamente una fuga de DNS.
Convierte el resultado en una investigación
Anota la política prevista y el ajuste de DNS seguro del navegador antes de probar. Ejecuta la prueba con el túnel activo, anota cada resolutor que mencione y compara el conjunto con la política, no con una única dirección esperada.
Repite tras una reconexión si es entonces cuando aparece el síntoma, porque una política aplicada al conectar puede perderse después. Usa la documentación del cliente para las excepciones internas de DNS en lugar de adivinar los ajustes.
Corrige la discrepancia que hayas encontrado: una elección del navegador, un ajuste de DNS de la VPN o una regla de DNS dividido. Si las consultas deben detenerse cuando falla el túnel, el kill switch es un ajuste aparte, y la configuración de DNS por sí sola no lo proporcionará. La especificación RFC 8484 es útil cuando necesitas explicar qué oculta y qué no oculta un resolutor cifrado.