Captura de Split-DNS: diga onde cada observação foi feita
Uma API de resolução, um filtro de cliente e uma captura de pacotes mostram fases diferentes de uma mesma consulta. Nomeie o ponto de observação antes de chamá-las de contraditórias.
Duas pessoas diagnosticam o mesmo problema de Split-DNS e obtêm endereços de resolvedor diferentes. Uma usou uma ferramenta de consulta, outra capturou pacotes no adaptador e uma terceira leu o diagnóstico do próprio cliente. Nenhuma mente e nenhuma descreve a mesma fase. Nomear o ponto de observação transforma uma contradição num mapa.
Uma consulta, vários pontos de observação
Para um único nome interno existem pelo menos cinco lugares para olhar: a aplicação e a API de resolução que ela chama, a política de domínio efetiva no cliente, uma captura no adaptador ou no filtro, uma fronteira de gateway controlada e o resolvedor que recebe realmente a consulta.
Cada um responde a uma pergunta diferente, e nenhum sozinho prova para onde foi a consulta.
Uma captura no adaptador mostra pacotes, não intenção. Não diz qual resolvedor o cliente escolheu, e uma captura vazia pode significar uma resposta em cache ou outra API de resolução em vez de um pacote descartado. Trate cada observação como prova de uma fase. Depois monte as fases num caminho.
O filtro do cliente fica entre a aplicação e o cabo
Um cliente VPN com Split-DNS aplica a correspondência de domínios antes de o pacote sair da máquina. Os nomes no sufixo tunelizado vão para o resolvedor interno; todo o resto vai para o local. O filtro é política, e a política pode variar conforme a plataforma e a versão do cliente.
O guia de Split-DNS do Secure Client da Cisco cobre a correspondência de domínios e o filtro do Windows, e separa o que uma aplicação vê quando usa a API de resolução nativa do que vê uma ferramenta como o nslookup. São essas distinções o ponto.
Comece pelo perfil efetivo e por uma consulta normal da aplicação. Qualquer teste que nomeie um servidor explícito é um desvio deliberado; explique-o com o diagnóstico do próprio cliente e não deixe que se torne o critério de aceitação.
O nslookup segue um caminho diferente do da aplicação
O nslookup constrói a sua própria consulta DNS e pode contornar a política de resolução do sistema operativo. Isso torna-o útil para fazer uma pergunta concreta a um servidor concreto, e enganador para testar o que uma aplicação vai experimentar.
No Windows, a tabela de política de resolução de nomes decide que sufixo usa que servidor. Lê-la mostra a política que a aplicação vai seguir, e muitas vezes é essa a peça que falta.
Leia a política e depois faça a mesma pergunta pelo resolvedor normal:
Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example
Os resolvedores cifrados escondem a consulta, não a ligação
Um navegador com o seu próprio resolvedor DNS-over-HTTPS é um caso completamente diferente. A consulta sai dentro de TLS, por isso uma captura de pacotes mostra uma ligação a um endereço de resolvedor mas não o nome que está a ser pedido.
Descubra primeiro a política gerida do navegador e compare-a depois com uma consulta do sistema operativo. Pode acontecer que um navegador autorizado a escolher o seu próprio resolvedor nunca veja a política de Split-DNS.
A mesma cautela aplica-se a qualquer cliente que traga o seu próprio resolvedor. Uma captura que identifica a ligação remota não é prova sobre o nome da consulta. Se precisar do nome, obtenha-o a partir dos registos do próprio resolvedor ou do diagnóstico da aplicação, com as regras de privacidade aplicáveis.
Compare com um teste etiquetado
Escolha um nome interno aprovado para o teste, mais um nome público que não transporte qualquer significado sensível. Para cada um, registe a hora, o tipo de registo, a resposta e a política que esperava.
Onde for permitido, compare a receção no resolvedor com uma observação estreita do cliente ou do gateway:
nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List
Nunca envie nomes privados para resolvedores públicos não relacionados só para criar uma comparação, e redija tudo o que partilhar. Por fim, separe uma resposta DNS correta da ligação ao serviço que se segue: o endereço privado resolvido continua a precisar de uma rota e de uma autorização da aplicação.