Por qué Windows envía los nombres de tu VPN a un servidor DNS que nunca configuraste
Cambiar el DNS del adaptador parece que debería zanjar la cuestión. Una regla de espacio de nombres puede anular esa lista, y sin ninguna regla Windows pregunta a varios adaptadores.
Configuras el servidor DNS en el adaptador de la VPN, vuelves a conectarte y el nombre privado sigue llegando desde el resolutor de la oficina que nadie ha configurado en este portátil. El resultado parece indicar que se ignoró la configuración, y en cierto sentido así fue, porque la lista de adaptadores es un conjunto de candidatos y no una decisión. Windows resuelve nombres mediante una política de espacio de nombres que puede designar otro servidor para un sufijo concreto, y esa política se aplica antes de consultar la configuración del adaptador. Encontrar la regla que ganó es una tarea de cinco minutos cuando sabes qué tabla leer.
Qué cambiaste y qué decide en realidad
La dirección DNS de un adaptador le dice al cliente adónde podría enviar consultas esa interfaz. La tabla de directivas de resolución de nombres le dice al cliente adónde debe enviar consultas para un espacio de nombres dado, y se evalúa por nombre, no por adaptador. Cuando una regla coincide con el sufijo que escribiste, se usan los servidores de la regla y la lista de adaptadores deja de importar para esa consulta.
Por eso dos nombres en el mismo portátil pueden seguir caminos distintos en el mismo momento. Un equipo bajo el sufijo corporativo sigue su regla; un nombre público sigue la ruta predeterminada, que normalmente significa el adaptador que responde primero.
Cómo empareja la tabla un nombre
Las reglas se indexan por espacio de nombres y gana la coincidencia más específica. Una regla para corp.example se aplica a vpn.corp.example y no se aplica a example.net. Una regla con el espacio de nombres . cubre todo lo que las demás no cubren, lo que la convierte en la entrada más peligrosa de la lista y en la que conviene revisar cuando un sitio no relacionado se resuelve por el túnel.
Una regla también puede llevar un comentario, una directiva que desactiva la entrada y ajustes de seguridad que no tienen nada que ver con direcciones DNS. Una regla desactivada sigue visible en la configuración sin efecto alguno, así que una entrada que sobre el papel parece correcta puede quedar inerte tras un cambio de perfil.
Lee la tabla efectiva, no la lista de deseos
Las reglas configuradas y las reglas efectivas son dos preguntas distintas. Get-DnsClientNrptRule enumera lo que existe en la máquina. Get-DnsClientNrptPolicy -Effective muestra lo que el cliente aplicará de verdad, con los valores fusionados de la directiva y la configuración local.
Compara el sufijo de esa salida con el nombre que estás probando, carácter por carácter. Una regla para corp.example no captura un nombre que termina en corp.example.com, y un punto final en un sitio y no en el otro basta para cambiar la coincidencia.
Sin ninguna regla, Windows pregunta a más de un adaptador
Cuando nada de la tabla reclama el nombre, el cliente puede enviar la consulta por varias interfaces y quedarse con la primera respuesta que llegue. El resultado depende del momento: el mismo nombre puede resolverse desde el adaptador cableado el lunes y desde el túnel el martes, y nada en la configuración de ninguno de los adaptadores explica la diferencia.
Existen dos salidas. Añade una regla para el espacio de nombres para que la decisión deje de ser una carrera, o desactiva el comportamiento paralelo mediante la directiva de cliente DNS y acepta la resolución más lenta y determinista. La primera suele encajar mejor en una VPN con túnel dividido, porque documenta la intención en lugar de depender del orden.
Rutas que se saltan el resolutor por completo
Un navegador con DNS seguro activado resuelve por su cuenta y solo entrega la dirección a Windows, así que la tabla de reglas nunca ve el nombre. Los clientes construidos sobre entornos con su propio resolutor pueden comportarse igual. Cuando un nombre se resuelve en una aplicación y falla en otra de la misma máquina, compara las dos rutas de resolución antes de tocar la directiva.
Comprueba también si la aplicación se conecta a una dirección en caché de una sesión anterior. Clear-DnsClientCache y después la misma consulta da una respuesta más limpia que deducirla de un resultado antiguo.
Prueba con el nombre que falló
Resuelve el nombre de host exacto del informe, no un dominio público de prueba de velocidad, y anota qué servidor respondió. Después cambia una cosa: la regla, la lista de adaptadores o la asignación de directiva, y repite la misma consulta tras reconectar para que se reconstruya el estado aplicado.
Si el nombre se resuelve y el servicio sigue negándose, deja de editar DNS. El siguiente paso útil es la dirección y la ruta hacia ella, porque la resolución de nombres ya ha hecho su trabajo.