Relatório de DNS da VPN: o que incluir para que seja reproduzível

«O DNS está quebrado» é uma conclusão, e não é uma conclusão sobre a qual alguém possa agir. A parte útil de um relatório é a forma da falha: qual nome, por qual resolver, com qual resposta. Três detalhes transformam uma queixa em algo reproduzível, e todos os três são seguros de compartilhar depois que as partes privadas forem renomeadas. O que segue é o mínimo que um relatório de DNS de VPN precisa antes que alguém possa ajudar.

Uma categoria de nome, não um veredito

Comece pelo próprio nome e classifique-o: público, interno, curto, totalmente qualificado ou atendido por um sufixo específico. Um nome interno que falha enquanto os nomes públicos resolvem aponta para a seleção de resolver, não para a acessibilidade. Se todos os nomes falham, aponta para o caminho até o resolver, que é outra investigação com outras evidências. A categoria carrega o diagnóstico, e a string exata pode ser ocultada.

Diga se a falha exige que o túnel esteja ativo ou se ocorre depois de ele ser desconectado. Um nome que só quebra enquanto a VPN está ativa implica a configuração por link, enquanto um que quebra após a desconexão implica estado residual. Os relatórios costumam omitir isso e depois se perguntam por que a primeira sugestão não ajuda.

Registre o caminho do resolver

Uma consulta enviada a um servidor escolhido explicitamente e a busca comum de uma aplicação são experimentos diferentes. Diga qual dos dois produziu a falha, porque uma consulta manual a um servidor que funciona prova apenas que o servidor funciona. Os comandos abaixo separam o caminho do sistema de uma pergunta direta.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

A saída de status nomeia os servidores por link e os domínios de roteamento, ou seja, onde o split DNS é decidido. A chamada getent segue o mesmo caminho da aplicação, incluindo a ordem do nsswitch. A consulta direta contorna ambos e testa um servidor isoladamente. Informe qual dos três falhou e qual funcionou, e o leitor não precisa mais adivinhar o caminho.

Indique a comparação controlada

Mude uma variável e diga o que mudou. Nomes públicos resolvendo enquanto os internos falham é um problema de seleção; todo nome expirando é um problema de caminho; e um nome privado que resolve para um endereço público é um vazamento para o resolver errado. Duas dessas três coisas não têm nada a ver com o túnel estar ativo. Um relatório que afirma que todas as consultas estão quebradas costuma conter uma comparação que nunca foi executada.

Separe a resolução da entrega. Quando o nome resolve e o site ainda falha, a etapa de DNS teve sucesso e o relatório deve dizer isso, porque o próximo passo é uma rota ou um listener, não um resolver. Essa única distinção poupa uma rodada de perguntas mais vezes do que qualquer trecho de log.

Oculte o espaço de nomes, mantenha as relações

Os nomes internos podem ser substituídos, desde que as substituições preservem a estrutura. Mapeie cada servidor e sufixo distintos para um rótulo estável, e mantenha esse mapeamento fora da cópia compartilhada. Substituir cada host interno pelo mesmo marcador destrói exatamente a evidência de que o relatório precisa, porque o leitor não consegue mais ver que um sufixo resolveu e outro não. A mesma regra vale para endereços: mantenha as relações de prefixo e mude os bits do host se a política exigir.

Envie o registro pelo canal verificado e deixe de fora o que o diagnóstico nunca precisa. Senhas, chaves privadas e nomes de empresas não relacionadas não fazem parte de uma pergunta de DNS. O que o leitor precisa é a categoria da falha, o caminho do resolver, o erro exato e a única comparação que você fez.