Dos servidores DNS en un adaptador no separan espacios de nombres

Listar dos resolutores en un adaptador parece una forma de enviar un dominio a un servidor y otro dominio al otro, y nada en la lista de resolutores funciona así. Windows resuelve por nombre, y la decisión de a qué servidor preguntar proviene de objetos de directiva en lugar de una lista ordenada de direcciones. El modelo mental que hay que sustituir es la cola: no existe un primer servidor para el dominio A ni un segundo servidor para el dominio B. Hay un conjunto de reglas por espacio de nombres que nombra los servidores explícitamente, y una vez que existen esas reglas, la lista del adaptador deja de ser interesante.

El mito: dos direcciones separan dos dominios

La creencia sobrevive porque funciona por accidente cuando un servidor responde a todo y el segundo solo es un respaldo. Un cliente pregunta al primer servidor, ese servidor reenvía o recursa, y la respuesta llega; nadie nota qué resolutor tenía realmente la zona. La ilusión se rompe en el momento en que los dos espacios de nombres viven en zonas privadas separadas sin reenvío entre ellas, porque entonces el primer servidor responde con autoridad que el nombre no existe. Una respuesta negativa del primer servidor no activa el respaldo, ya que el cliente recibió una respuesta definitiva y no un fallo.

Una lista ordenada no tiene concepto de dominio, así que no puede expresar la intención. Lo que la lista controla realmente es qué servidor se pregunta primero y cuál se prueba segundo, y ambas respuestas se aplican por igual a todos los nombres.

Qué usa realmente Windows para elegir

La tabla de directivas de resolución de nombres hace coincidir un nombre con espacios de nombres configurados y selecciona los servidores y opciones para esa coincidencia. Las reglas pueden configurarse localmente, entregarse por directiva de grupo o proporcionarse desde un perfil VPN, y la directiva efectiva es una combinación y no una lista única. Por eso el primer diagnóstico siempre es el estado efectivo: una regla creada localmente que pierde frente a una directiva administrada produce un laboratorio que no se comporta en absoluto como su configuración sugiere. Las reglas también coinciden por especificidad, así que una entrada amplia de espacio de nombres puede eclipsar una concreta de formas invisibles en una lista de elementos configurados. Leer el orden efectivo es la única manera de ver qué regla gana.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

El primer comando enumera lo que está configurado en la máquina; el segundo muestra lo que el cliente aplicará realmente, incluidas las entradas que llegaron de otro lugar. Si la salida efectiva contiene espacios de nombres administrados, el propietario de esa directiva es el lugar correcto para pedir el cambio, no la lista local de reglas. Ambos comandos solo leen estado, así que ejecutarlos antes de que alguien acepte el cambio no cuesta nada.

Una regla por espacio de nombres, conserve el objeto

Una vez entendido el estado efectivo, cree una regla por espacio de nombres y conserve el objeto que devuelve cada comando. Los nombres para mostrar son etiquetas para personas, y el identificador único del objeto devuelto es después el objetivo de eliminación fiable. Escriba ambos identificadores en la misma nota de cambio que registra los espacios de nombres y los resolutores, porque la sesión que los creó no será la sesión que limpie.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

El punto inicial marca una coincidencia de sufijo, así que la regla cubre app.svc.internal.example y cualquier otra cosa por debajo. Las dos direcciones de aquí pertenecen al plan de enrutamiento propio de este laboratorio; una regla no crea una zona, no instala una ruta ni autoriza la aplicación que finalmente se conecta, y la referencia de Add-DnsClientNrptRule documenta exactamente qué parámetro hace qué.

Fíjese en lo que estos comandos no hacen: son para toda la máquina, no están limitados a una sesión VPN, y sobreviven al cierre de la ventana. Un laboratorio que olvida esto deja directivas atrás cuando el túnel ya no está.

Demuestre que el cliente eligió el servidor

Preguntar a un servidor concreto si conoce un nombre demuestra que el servidor puede responder, lo que no es la misma afirmación que el cliente haya elegido ese servidor. La prueba que importa resuelve un nombre real por la ruta ordinaria del cliente y después confirma qué resolutor se encargó de él, idealmente mientras el túnel que proporciona la ruta está activo. Si el túnel está caído, una regla bien delimitada sigue apuntando a un servidor inalcanzable, lo que es un problema de enrutamiento y no de directiva. Pruebe ambos estados para que luego se puedan distinguir.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

Vigile las respuestas en caché del periodo anterior a la existencia de las reglas, y vigile las aplicaciones que evitan por completo el resolutor del sistema con su propio DNS cifrado. Los sufijos de búsqueda son otra función aparte: una regla puede elegir un resolutor para un nombre completo sin enseñar a Windows a expandir un nombre de host desnudo dentro de ese espacio de nombres.

Elimine exactamente lo que creó

La limpieza es donde un laboratorio se convierte en una historia aleccionadora. Eliminar todas las reglas de la máquina es rápido y quita directivas de las que alguien más depende, así que use los identificadores capturados cuando se crearon las reglas, y vuelva a leer el estado efectivo después para confirmar que la máquina volvió a donde empezó. Si la sesión que las creó ya no está, la nota de cambio es el único lugar donde existen los identificadores. Esa es la razón de escribirlos antes de que se ejecute el primer comando, no después.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

Para un despliegue y no para un laboratorio, la cuestión de la duración importa tanto como la regla. Un perfil VPN puede llevar las reglas de espacio de nombres y elegir si persisten más allá de la conexión; una regla que persiste mientras el resolutor es inalcanzable deja a los clientes prefiriendo un servidor muerto, y una regla limitada a la conexión desaparece cuando lo hace el túnel. Decida cuál de esos comportamientos necesita el servicio, marque quién posee la regla y deje la división de autoridad documentada junto al perfil y no en la memoria de alguien sobre un laboratorio.