DNS de la VPN frente a DoH del navegador: qué no puede decirte una prueba de fugas

La página de prueba de fugas dice que tu DNS está bien, la insignia del navegador dice seguro, y la wiki interna sigue sin cargar. Las tres cosas pueden ser ciertas a la vez, porque la dirección de un resolutor no es lo mismo que la política que lo eligió ni el camino que recorrió la consulta. Lo que la gente llama fuga de DNS es en realidad una sola pregunta: qué resolutor recibió el nombre, y ¿fue intencionada esa elección? Aclararlo exige tres comprobaciones, y solo la última implica cambiar un ajuste.

Mito uno: la insignia nombra tu resolutor

Una prueba de fugas resuelve un nombre de sonda e informa de la dirección que respondió. No informa de la política que eligió ese resolutor, y cuando la consulta va envuelta en DNS sobre HTTPS, una caja intermedia del camino no puede ver el nombre en absoluto. Dos máquinas muy distintas producen la misma insignia tranquilizadora: una donde la VPN empujó 10.8.0.1 y el navegador lo usa, y otra donde el navegador ignoró la lista del sistema y envió el nombre por el túnel a su propio proveedor cifrado.

La distinción importa en el momento en que falla un nombre privado. En la primera configuración el resolutor de la VPN responde por la zona corporativa; en la segunda el navegador nunca se lo preguntó, así que el nombre de host corto no se resuelve y el fallo parece una VPN rota. La comprobación no es otra prueba de fugas, es una consulta a un nombre que solo conoce un resolutor.

Mito dos: el navegador abandona el túnel

El DNS elige una dirección, el enrutamiento transporta la conexión, y son dos capas separadas. Una consulta enviada a un proveedor DoH público sigue siendo TCP puerto 443 hacia una dirección enrutable. Si tu tabla de rutas envía la ruta predeterminada al túnel, esa consulta también pasa por el túnel. La marca del resolutor no decide el camino.

Lo que cambia el DoH del navegador es el destinatario de los nombres. Es una decisión real de privacidad y una decisión real de política, pero no es una evasión del enrutamiento. Si tu requisito es que los nombres se queden con el operador de la VPN, una consulta cifrada a otro incumple ese requisito mientras sigue usando el túnel para la conexión real.

Mito tres: cada VPN anula cada navegador

El DNS seguro de un navegador tiene modos, no un interruptor: desactivado, un proveedor predeterminado con respaldo, una plantilla personalizada o una política impuesta por el sistema operativo o la organización. El caso de respaldo es el que produce informes intermitentes. Cuando el punto final cifrado no es accesible, el navegador puede volver al resolutor del sistema, así que el mismo portátil resuelve correctamente un nombre privado el lunes y el martes no.

Al mismo tiempo, la mayoría de los clientes VPN configuran el resolutor del sistema cuando la conexión sube y restauran el anterior cuando cae. Un navegador que mantiene un resolutor cifrado personalizado no observa esa restauración en absoluto. Por eso el mismo perfil se comporta distinto en dos portátiles y por eso resolv.conf parece correcto mientras el navegador sigue preguntando a otro.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Ejecuta esos comandos mientras estés conectado, anota qué dominios reclama cada resolutor y compáralo con lo que el navegador informa sobre su propio modo. La documentación de DoH de Mozilla es una descripción razonable de cómo deben funcionar el comportamiento predeterminado y el de respaldo de un navegador.

La decisión tiene tres entradas, no una

Los nombres privados, la confianza en el operador y la accesibilidad deciden la disposición correcta. Los nombres que solo conoce el resolutor de la VPN obligan a un DNS dividido: el sufijo privado va al resolutor empujado, y todo lo demás sigue la política que hayas elegido para los nombres públicos. La confianza en el operador decide si los nombres públicos también deben ir a ese resolutor o a un servicio aparte. La accesibilidad decide si el resolutor cifrado elegido es siquiera utilizable en esta red.

Ninguna de estas filas es una recomendación universal. Un resolutor operado por la VPN concentra las observaciones en ese operador; un servicio aparte añade otro destinatario de los nombres consultados. Ninguna de las dos disposiciones demuestra nada sobre la retención a menos que leas la política.

Anota la decisión por perfil, porque estos ajustes se desplazan. Un perfil que empujó un resolutor el mes pasado quizá hoy no empuje nada, y el navegador mantendrá gustoso un punto final personalizado antiguo que aún responde. En la nota deben constar la dirección del resolutor, los sufijos que posee y el modo del navegador, no la marca del servicio.

Prueba la política que crees que has configurado

Prueba por nombre, no por insignia. Resuelve un nombre público y un nombre privado a través del resolutor del sistema, y luego repítelo dentro del navegador con su propio ajuste de DNS seguro en el modo que piensas usar. Si el nombre privado falla solo en el navegador, has encontrado el desajuste de destinatario sin tocar un solo ajuste de la VPN.

Después reconecta y comprueba la restauración, porque ahí viven los errores de traspaso: desconecta, confirma que volvió el resolutor anterior, reconecta, confirma que volvió el empujado. Por último, prueba un navegador con una política gestionada si tienes uno, porque ese modo puede rechazar del todo tu cambio y mantener en silencio el resolutor anterior.

Empieza por la pregunta del espacio de nombres y evitarás la mayor parte de esto. Si la máquina tiene que llegar a nombres internos, el resolutor cifrado del navegador es una decisión solo sobre la mitad pública, y la mitad privada se queda con lo que la VPN haya empujado.