Testar DNS dividido sem vazar nomes internos

Consultar um nome interno num resolvedor público vaza o nome e ignora a regra que querias testar. A consulta chega a um servidor que não controlas, a resposta vem de um espaço de nomes que nunca deveria tê-lo visto, e o resultado não diz nada sobre se o DNS dividido funciona. Testar DNS dividido significa testar o caminho do resolvedor que uma aplicação usa de facto. Esse caminho é escolhido pelo sistema operativo, pela lista de domínios do perfil VPN e, às vezes, pelo navegador.

Escolhe dois nomes e prevê primeiro as duas respostas

Pede ao responsável da rede um nome de teste interno documentado e escolhe um nome público comum que não diga nada sobre a organização. Escreve o que deveria acontecer com cada um antes de executar seja o que for: o nome interno deveria chegar ao resolvedor do túnel e devolver um endereço interno, enquanto o nome público deveria ser resolvido através do resolvedor que o sistema usa normalmente. Essas duas previsões são o teste, porque sem elas qualquer resposta pode ser justificada depois. Mantém o par fixo entre execuções para que uma comparação posterior signifique algo.

Verifica as regras efetivas, não as previstas. A lista de domínios associada à ligação VPN decide que sufixos vão para que resolvedor, e um erro tipográfico nessa lista produz uma divisão plausível mas errada. Num dispositivo gerido, usa o caminho de diagnóstico do administrador, já que as substituições locais podem ser repostas por política na verificação seguinte.

Anota a previsão ao lado da resposta observada no mesmo ticket. Um teste sem previsão não pode falhar, e um teste que não pode falhar não ensina nada.

Testa o caminho que a aplicação usa, não um servidor que escolheste

Um comando que nomeia explicitamente um resolvedor testa esse resolvedor e mais nada. Diz-te se o servidor interno responde, o que é útil, e não te diz se uma aplicação envia o nome para lá. Testa primeiro pelo caminho normal: resolve o nome interno como uma aplicação faria e depois resolve o nome público da mesma forma. Só depois consulta servidores específicos para encontrar onde o comportamento diverge.

Os navegadores complicam o quadro, porque as definições de DNS seguro podem contornar por completo o resolvedor do sistema. Um navegador configurado com o seu próprio resolvedor cifrado nunca vê a divisão, e a falha parece um perfil VPN avariado. Verifica essa definição antes de mudar o túnel.

Repete a consulta depois de reconectar se a questão for o restauro. Uma resposta em cache de antes da reconexão pode fazer uma divisão corretamente restaurada parecer melhor ou pior do que é.

Regista a categoria da resposta, não apenas sucesso ou falha

Anota qual de quatro coisas aconteceu: um endereço interno, um endereço público, uma resposta negativa ou um tempo limite. Cada uma tem um significado diferente. Um endereço interno para o nome interno é o sucesso esperado; um endereço público para um nome interno sugere que a consulta saiu do túnel; uma resposta negativa do servidor autoritativo aponta para um registo em falta e não para uma falha de encaminhamento; e um tempo limite indica um problema de acessibilidade ou um resolvedor que nunca recebeu a consulta. Sucesso e falha são demasiado grosseiros para agir.

Tem em conta a cache antes de interpretares uma consulta nova em falta, porque uma resposta negativa em cache parece idêntica a um nome que não existe. Captura a resposta antes de limpares seja o que for com controlos suportados, porque a primeira resposta é a prova.

Interpreta os dois ramos sem adivinhar

Se o nome interno for resolvido corretamente e a aplicação continuar a falhar, o resolvedor fez o seu trabalho e os suspeitos seguintes são as rotas e as permissões no próprio recurso. Se o nome privado chegou a um resolvedor público, a regra de divisão não está a ser aplicada a essa consulta, por isso revê a lista de domínios e qualquer política do navegador com o proprietário do espaço de nomes. Esses dois ramos têm proprietários diferentes, e é por isso que registar qual viste importa mais do que registar que algo se partiu.

Oculta os dados sensíveis da saída partilhada mantendo a estrutura: que espaço de nomes, que regra, que categoria de resposta. Uma resposta de resolvedor pode conter endereços internos e nomes de anfitrião, e um ticket é uma casa duradoura para ambos.

Depois entrega o resultado ao proprietário do espaço de nomes com as duas categorias que observaste e os nomes removidos. É uma conversa de cinco minutos em vez de uma semana de especulação.