NXDOMAIN através de uma VPN não significa uma queda do túnel

É tentador ler uma consulta falhada como prova de que o túnel colapsou, sobretudo quando o nome funcionava dez minutos antes. A resposta diz outra coisa. NXDOMAIN é uma transação DNS concluída em que um resolvedor declarou que o nome consultado não existe; um túnel quebrado costuma produzir silêncio, um tempo limite esgotado ou uma tentativa de resolução contra o servidor errado. A versão do argumento sem wireshark é uma consulta, um respondedor e um código de resposta, e essa tríade merece ser registada antes de qualquer alteração de configuração.

O que a resposta estabelece realmente

O DNS separa resultados que os clientes costumam fundir numa única falha. Um nome que não existe produz uma resposta negativa com o código NXDOMAIN, enquanto um nome que existe mas não tem qualquer registo do tipo pedido produz uma resposta bem-sucedida com uma secção de respostas vazia. Ambos parecem nada de útil a uma aplicação, e apenas um deles significa que o nome está errado.

Essa diferença decide onde pertence a reparação. Um registo AAAA em falta num anfitrião que tem um registo A não é um anfitrião em falta, e reemitir um certificado ou reconstruir um túnel para o perseguir desperdiça a única pista disponível. A distinção também fixa a forma do seguimento: um problema de nomes corrige-se na zona, e um problema de tipo corrige-se pedindo o registo correto ou aceitando que a família de endereços simplesmente não existe.

O mito: um nome privado em falta significa que o túnel falhou

O mito sobrevive porque os dois acontecimentos chegam tantas vezes juntos. Um cliente liga-se à VPN, o sistema operativo mantém um resolvedor em que já confiava, e o nome interno de que agora precisa é perguntado a um servidor que nunca ouviu falar da zona privada. Esse servidor responde com honestidade e negativamente. O túnel transporta o pacote; a resposta diz apenas respeito a um espaço de nomes que o respondedor não serve.

As disposições de horizonte dividido tornam isto rotineiro: o mesmo nome de zona existe publicamente e internamente com conteúdos diferentes, e só o resolvedor interno conhece os registos privados. Obter uma resposta negativa que parece autoritativa é, portanto, prova de qual resolvedor respondeu, não prova do estado da interface.

Dois detalhes de configuração decidem o resultado. O túnel tem de empurrar ou selecionar o resolvedor interno, e o cliente tem de aplicar essa seleção ao nome consultado. Uma regra por domínio que nomeie um sufixo ligeiramente diferente do registo que escreveu enviará a consulta pelo caminho público, e a resposta será correta e inútil.

Pergunte ao resolvedor certo com o nome certo

Registe o respondedor antes de registar o veredicto. Uma consulta que não mostra que servidor respondeu não consegue distinguir um problema de política de um problema de espaço de nomes, e os dois têm arranjos não relacionados.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

As duas primeiras linhas mostram o que o resolvedor local decidiu e a quem perguntaria. A consulta +search reproduz o que uma aplicação faz quando acrescenta um sufixo de pesquisa, que muitas vezes é a consulta real e não a escrita numa ferramenta de diagnóstico. A última linha pergunta diretamente ao servidor interno, contornando a política do cliente; se isso resultar enquanto a consulta simples falha, a zona está bem e o encaminhamento das consultas não.

A cache negativa explica o atraso após uma correção

As respostas negativas são colocadas em cache por design, e RFC 2308 descreve como o tempo de vida da cache negativa é derivado do registo de autoridade da zona. Corrigir um registo ou uma regra de resolvedor não garante, por isso, uma alteração imediata no cliente, e repetir uma consulta que continua a devolver a resposta em cache não prova nada de novo. Só um respondedor diferente, um nome diferente ou uma cache limpa produzem provas frescas.

Limpe a cache local e depois repita a mesma consulta contra o mesmo respondedor. Em sistemas que utilizam o serviço de resolvedor local isso é um comando; noutros é um reinício do serviço ou um utilitário da plataforma, e a ferramenta concreta importa menos do que repetir depois um teste idêntico.

Separe o nome do caminho

Assim que o nome resolve para o endereço privado esperado, o DNS está terminado como assunto e o caminho da aplicação passa a ser a pergunta seguinte. Um anfitrião que responde às consultas mas recusa uma ligação tem outro problema, e continuar a ajustar resolvedores depois de uma resposta correta é como um incidente adquire três alterações não relacionadas. Compare o endereço resolvido com aquele em que o serviço escuta realmente antes de assumir que os dois coincidem.

Guarde a transcrição: a consulta, o respondedor, o código e o endereço resolvido. Esse registo é também o que torna verificável um relatório posterior, e é a diferença entre um diagnóstico e uma história sobre um túnel que parecia lento.