El DNS público funciona, pero eso no significa que se encuentre Active Directory

La VPN conecta, el navegador abre un sitio público y el portátil sigue sin poder iniciar sesión en el dominio. La conclusión habitual es que el DNS está bien porque los nombres se resuelven. No está bien, y la razón es que una prueba con el navegador ejercita una sola consulta de una cadena que necesita un cliente unido al dominio. El descubrimiento del dominio pide primero registros de servicio, después las direcciones de los controladores que esos registros nombran y por último una ruta hacia los puertos en los que escuchan esos controladores. Una respuesta pública no satisface ninguno de esos pasos.

El mito: los nombres se resuelven, así que el DNS está hecho

Que un sitio público se resuelva solo dice que algún resolutor respondió a una consulta A o AAAA de un nombre en una zona pública. Active Directory usa el mismo protocolo para otra pregunta: dónde están los servicios del dominio y qué controlador debe usar este cliente. La pregunta se expresa como registros SRV bajo una zona con el nombre del dominio, y un resolutor público recursivo no tiene motivo para tenerlos.

Cuando falta el registro, el resolutor devuelve una respuesta negativa, que es una respuesta DNS válida y no una caída. El cliente recurre entonces a información de controlador en caché si la tiene, y por eso mismo un escritorio puede parecer bien durante horas y fallar tras un reinicio o un cambio de contraseña.

Qué pide realmente un cliente de dominio, por orden

Para un dominio como corp.example, la consulta genérica de localizador es _ldap._tcp.dc._msdcs.corp.example. Las respuestas SRV nombran controladores candidatos y sus puertos, y después el cliente necesita registros de dirección para esos nombres de host antes de abrir una conexión. El descubrimiento consciente del sitio añade consultas bajo el subdominio del sitio, y las respuestas determinan qué controladores se prefieren, no cuál es obligatorio.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Siga la cadena en ese orden, desde la red donde ocurre el problema. Un nombre de host que se resuelve a una dirección inalcanzable es un fallo de enrutamiento, no un fallo de DNS. Un controlador alcanzable al que le faltan los registros de localizador es un fallo de DNS, no un fallo de enrutamiento. Los dos producen quejas de usuario parecidas y reparaciones completamente distintas.

Por qué un resolutor público responde y aun así rompe el inicio de sesión

Si el adaptador entrega al cliente un resolutor público, los nombres públicos funcionan y el espacio de nombres interno no. Añadir un segundo resolutor público no ayuda, porque ninguno de los dos tiene la zona. Tampoco la lista habitual «primero interno, después público» se comporta como una regla por dominio: una respuesta negativa del primer servidor es una respuesta legítima, y el cliente no reintenta el segundo servidor solo porque la respuesta estuviera vacía.

Ambos resolutores internos, si tiene dos, deben tener el espacio de nombres de AD y ser alcanzables desde la red actual del cliente. Esa es la parte que rompen los diseños de túnel dividido: la VPN puede transportar la subred del túnel mientras el resolutor interno está en un prefijo que el túnel no enruta, así que la consulta sale hacia un resolutor que no puede responderla.

Windows también aplica una directiva de resolución de nombres que puede dirigir espacios de nombres concretos a servidores concretos, y las direcciones DNS que muestra el adaptador no son toda la historia. Cambiar la lista del adaptador sin cambiar esa directiva puede dejar intacta la configuración efectiva, y por eso una corrección que parece aplicada no tiene ningún efecto.

Mantenga el DNS del túnel y sus rutas de acuerdo

Un perfil de VPN que empuja un resolutor pero no el prefijo que lo contiene crea un resolutor que el cliente no puede alcanzar; uno que empuja el prefijo pero ningún resolutor deja al cliente preguntando al local. Trate el par como un solo elemento de configuración y compruebe ambos tras cada cambio de perfil, porque un envío reordenado o una nueva directiva de túnel dividido puede separarlos.

Compruebe también qué hace el cliente con el ajuste enviado. Algunos clientes aplican el servidor DNS solo a la interfaz del túnel y dejan el resolutor del adaptador físico en su sitio, así que cuál gana depende de la métrica de la interfaz y del nombre consultado. Si la respuesta interna solo llega cuando el adaptador físico está deshabilitado, ese es el mecanismo que hay que corregir, no los registros del dominio.

Acepte con una llamada de descubrimiento y una operación en vivo

Una prueba de aceptación útil ejecuta la consulta de localizador y después realiza una operación autenticada real, como abrir un recurso compartido respaldado por directorio o pedir un tique. Hágalo antes de la transición de la VPN y otra vez después, en la misma máquina, sin reiniciar entre medias. Las credenciales en caché y las sesiones ya abiertas harán con gusto que un camino roto parezca sano, así que un inicio de sesión correcto en el escritorio no es la prueba.

Las recomendaciones de Microsoft para el cliente DNS trazan la misma línea entre resolver el espacio de nombres interno y reenviar las consultas públicas hacia arriba, y esa es la disposición que hay que conservar al introducir una VPN.

Si el fallo es solo lento y no fallido, mantenga el retraso separado del diagnóstico. Un tiempo de espera durante el descubrimiento puede venir de un controlador inalcanzable, un puerto bloqueado o un resolutor que responde tarde, y nada de eso queda demostrado solo por la espera. Capture la consulta real, su respuesta y el intento de conexión antes de cambiar cualquier ajuste del resolutor.