Dous servidores DNS nun adaptador non separan espazos de nomes

Listar dous resolutores nun adaptador parece un xeito de enviar un dominio a un servidor e outro dominio ao outro, e nada na lista de resolutores funciona así. Windows resolve por nome, e a decisión de a que servidor preguntar vén de obxectos de política en lugar dunha lista ordenada de enderezos. O modelo mental que hai que substituír é a cola: non existe un primeiro servidor para o dominio A nin un segundo servidor para o dominio B. Hai un conxunto de regras por espazo de nomes que nomea os servidores explicitamente, e unha vez que existen esas regras, a lista do adaptador deixa de ser interesante.

O mito: dous enderezos separan dous dominios

A crenza sobrevive porque funciona por accidente cando un servidor responde a todo e o segundo só é un respaldo. Un cliente pregunta ao primeiro servidor, ese servidor reenvía ou recursa, e a resposta chega; ninguén nota que resolutor tiña realmente a zona. A ilusión rompe no momento en que os dous espazos de nomes viven en zonas privadas separadas sen reenvío entre elas, porque entón o primeiro servidor responde con autoridade que o nome non existe. Unha resposta negativa do primeiro servidor non activa o respaldo, xa que o cliente recibiu unha resposta definitiva e non un fallo.

Unha lista ordenada non ten concepto de dominio, así que non pode expresar a intención. O que a lista controla realmente é que servidor se pregunta primeiro e cal se proba segundo, e ambas as dúas respostas se aplican por igual a todos os nomes.

Que usa realmente Windows para elixir

A táboa de políticas de resolución de nomes fai coincidir un nome con espazos de nomes configurados e selecciona os servidores e opcións para esa coincidencia. As regras pódense configurar localmente, entregar por directiva de grupo ou proporcionar desde un perfil VPN, e a política efectiva é unha combinación e non unha lista única. Por iso o primeiro diagnóstico sempre é o estado efectivo: unha regra creada localmente que perde fronte a unha política administrada produce un laboratorio que non se comporta en absoluto como a súa configuración suxire. As regras tamén coinciden por especificidade, así que unha entrada ampla de espazo de nomes pode eclipsar unha concreta de formas invisibles nunha lista de elementos configurados. Ler a orde efectiva é a única forma de ver que regra gaña.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

O primeiro comando enumera o que está configurado na máquina; o segundo mostra o que o cliente aplicará realmente, incluídas as entradas que chegaron doutro lugar. Se a saída efectiva contén espazos de nomes administrados, o propietario desa política é o lugar correcto para pedir o cambio, non a lista local de regras. Ambos os comandos só len estado, así que executalos antes de que alguén acepte o cambio non custa nada.

Unha regra por espazo de nomes, conserve o obxecto

Unha vez entendido o estado efectivo, cree unha regra por espazo de nomes e conserve o obxecto que devolve cada comando. Os nomes para mostrar son etiquetas para persoas, e o identificador único do obxecto devolto é despois o obxectivo de eliminación fiable. Escriba ambos os identificadores na mesma nota de cambio que rexistra os espazos de nomes e os resolutores, porque a sesión que os creou non será a sesión que limpe.

$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

O punto inicial marca unha coincidencia de sufixo, así que a regra cobre app.svc.internal.example e calquera outra cousa por debaixo. Os dous enderezos de aquí pertencen ao plan de encamiñamento propio deste laboratorio; unha regra non crea unha zona, non instala unha ruta nin autoriza a aplicación que finalmente se conecta, e a referencia de Add-DnsClientNrptRule documenta exactamente que parámetro fai que.

Fíxese no que estes comandos non fan: son para toda a máquina, non están limitados a unha sesión VPN, e sobreviven ao peche da xanela. Un laboratorio que esquece isto deixa políticas atrás cando o túnel xa non está.

Demostre que o cliente elixiu o servidor

Preguntar a un servidor concreto se coñece un nome demostra que o servidor pode responder, o que non é a mesma afirmación que o cliente elixise ese servidor. A proba que importa resolve un nome real pola ruta ordinaria do cliente e despois confirma que resolutor se encargou del, idealmente mentres o túnel que proporciona a ruta está activo. Se o túnel está caído, unha regra ben delimitada segue apuntando a un servidor inalcanzable, o que é un problema de encamiñamento e non de política. Probe ambos os estados para que logo se poidan distinguir.

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

Vixíe as respostas na caché do período anterior á existencia das regras, e vixíe as aplicacións que evitan por completo o resolutor do sistema co seu propio DNS cifrado. Os sufixos de busca son outra función aparte: unha regra pode elixir un resolutor para un nome completo sen ensinar a Windows a expandir un nome de host nu dentro dese espazo de nomes.

Elimine exactamente o que creou

A limpeza é onde un laboratorio se converte nunha historia aleccionadora. Eliminar todas as regras da máquina é rápido e quita políticas das que alguén máis depende, así que use os identificadores capturados cando se crearon as regras, e volva ler o estado efectivo despois para confirmar que a máquina volveu a onde empezou. Se a sesión que as creou xa non está, a nota de cambio é o único lugar onde existen os identificadores. Esa é a razón de escribilos antes de que se execute o primeiro comando, non despois.

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

Para un despregamento e non para un laboratorio, a cuestión da duración importa tanto como a regra. Un perfil VPN pode levar as regras de espazo de nomes e elixir se persisten máis alá da conexión; unha regra que persiste mentres o resolutor é inalcanzable deixa os clientes preferindo un servidor morto, e unha regra limitada á conexión desaparece cando o fai o túnel. Decida cal deses comportamentos necesita o servizo, marque quen posúe a regra e deixe a división de autoridade documentada xunto ao perfil e non na memoria de alguén sobre un laboratorio.