Dois servidores DNS num adaptador não separam espaços de nomes

Listar dois resolvers num adaptador parece uma forma de enviar um domínio para um servidor e outro domínio para o outro, e nada na lista de resolvers funciona assim. O Windows resolve por nome, e a decisão de que servidor consultar vem de objetos de política em vez de uma lista ordenada de endereços. O modelo mental a substituir é a fila: não existe um primeiro servidor para o domínio A nem um segundo servidor para o domínio B. Existe um conjunto de regras por espaço de nomes que nomeia os servidores explicitamente, e quando essas regras existem, a lista do adaptador deixa de ser interessante.

O mito: dois endereços separam dois domínios

A crença sobrevive porque funciona por acidente quando um servidor responde a tudo e o segundo é apenas uma reserva. Um cliente pergunta ao primeiro servidor, esse servidor reencaminha ou faz recursão, e a resposta chega; ninguém repara qual resolver detinha realmente a zona. A ilusão quebra no momento em que os dois espaços de nomes vivem em zonas privadas separadas sem reencaminhamento entre elas, porque então o primeiro servidor responde com autoridade que o nome não existe. Uma resposta negativa do primeiro servidor não aciona a reserva, já que o cliente recebeu uma resposta definitiva e não uma falha.

Uma lista ordenada não tem conceito de domínio, por isso não pode exprimir a intenção. O que a lista controla realmente é que servidor é consultado primeiro e qual é tentado em segundo, e ambas as respostas se aplicam por igual a todos os nomes.

O que o Windows usa realmente para escolher

A tabela de políticas de resolução de nomes faz corresponder um nome a espaços de nomes configurados e seleciona os servidores e opções para essa correspondência. As regras podem ser configuradas localmente, entregues por política de grupo ou fornecidas por um perfil VPN, e a política efetiva é uma combinação e não uma lista única. É por isso que o primeiro diagnóstico é sempre o estado efetivo: uma regra criada localmente que perde para uma política gerida produz um laboratório que se comporta de forma nada semelhante à sua configuração. As regras também são comparadas por especificidade, pelo que uma entrada ampla de espaço de nomes pode eclipsar uma estreita de formas invisíveis numa lista de itens configurados. Ler a ordem efetiva é a única forma de ver que regra ganha.

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, incluindo entradas que vieram de outro lugar. Se a saída efetiva contiver espaços de nomes geridos, o proprietário dessa política é o local correto para pedir a alteração, não a lista local de regras. Ambos os comandos apenas leem estado, por isso executá-los antes de alguém concordar com a alteração não custa nada.

Uma regra por espaço de nomes, guarde o objeto

Depois de compreendido o estado efetivo, crie uma regra por espaço de nomes e guarde o objeto que cada comando devolve. Os nomes de apresentação são etiquetas para pessoas, e o identificador único no objeto devolvido é depois o alvo de eliminação fiável. Escreva ambos os identificadores na mesma nota de alteração que registra os espaços de nomes e os resolvers, porque a sessão que os criou não será a sessão que limpa.

$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 ponto inicial marca uma correspondência de sufixo, pelo que a regra cobre app.svc.internal.example e tudo o que estiver por baixo. Os dois endereços aqui pertencem ao plano de encaminhamento próprio deste laboratório; uma regra não cria uma zona, não instala uma rota nem autoriza a aplicação que acaba por se ligar, e a referência de Add-DnsClientNrptRule documenta exatamente que parâmetro faz o quê.

Repare no que estes comandos não fazem: são para toda a máquina, não estão limitados a uma sessão VPN, e sobrevivem ao fecho da janela. Um laboratório que se esquece disto deixa políticas para trás depois de o túnel desaparecer.

Prove que o cliente escolheu o servidor

Perguntar a um servidor específico se conhece um nome prova que esse servidor consegue responder, o que não é a mesma afirmação que o cliente ter escolhido esse servidor. O teste que importa resolve um nome real pelo caminho comum do cliente e depois confirma qual resolver o tratou, idealmente enquanto o túnel que fornece a rota está ativo. Se o túnel estiver em baixo, uma regra corretamente delimitada continua a apontar para um servidor inalcançável, e isso é um problema de encaminhamento e não de política. Teste os dois estados para que possam ser distinguidos mais tarde.

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

Vigie as respostas em cache do período anterior às regras e as aplicações que contornam por completo o resolver do sistema com o seu próprio DNS cifrado. Os sufixos de pesquisa são outra funcionalidade separada: uma regra pode escolher um resolver para um nome completo sem ensinar o Windows a expandir um nome de anfitrião simples para esse espaço de nomes.

Remova exatamente o que criou

A limpeza é onde um laboratório se torna uma história exemplar. Eliminar todas as regras da máquina é rápido e remove políticas de que outra pessoa depende, por isso use os identificadores capturados quando as regras foram criadas, e volte a ler o estado efetivo para confirmar que a máquina regressou ao ponto de partida. Se a sessão que as criou já não existir, a nota de alteração é o único local onde os identificadores existem. É essa a razão para os escrever antes de o primeiro comando ser executado, e não depois.

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

Para uma implementação e não para um laboratório, a questão da duração conta tanto como a regra. Um perfil VPN pode transportar as regras de espaço de nomes e escolher se persistem para além da ligação; uma regra que persiste enquanto o resolver está inalcançável deixa os clientes a preferir um servidor morto, e uma regra limitada à ligação desaparece quando o túnel desaparece. Decida qual desses comportamentos o serviço precisa, marque quem é dono da regra, e deixe a divisão de autoridade documentada ao lado do perfil e não na memória de alguém sobre um laboratório.