A VPN corrigiu o DNS ou apenas reutilizou uma resposta em cache?

Abrir uma página segundos depois de o túnel subir não prova que o DNS agora funciona, embora o ticket normalmente diga isso. Nada nessa observação exigia uma consulta: o nome pode ter sido resolvido antes da mudança e reutilizado a partir de um cache que o túnel nunca tocou. Dois testes diferentes produzem a mesma tela.

Compare o que cada teste realmente exercitou antes de atribuir o mérito à mudança.

Carregar uma página não é uma consulta

Cada camada entre a aplicação e o resolvedor pode lembrar uma resposta durante a sua vida útil. O sistema operacional guarda uma, o navegador guarda a sua, e uma aplicação com ligação de longa duração pode nunca mais resolver nada durante a sessão. Um carregamento bem-sucedido após uma mudança de túnel pode, portanto, ser uma demonstração de memória e não de encaminhamento. A ausência de uma falha não é a presença de uma consulta.

Essa distinção muda o que deve testar a seguir. Se o objetivo é mostrar que o novo resolvedor responde, precisa de uma consulta que não possa ser servida a partir de um cache que não limpou.

Ler um sucesso em cache como prova de que um servidor antes inacessível recuperou é a versão mais cara deste erro, porque fecha o incidente com uma premissa falsa.

Conte os caches antes de concluir

Quatro merecem nome: a resolução da própria aplicação, o cache de cliente do sistema operacional, o estado interno do navegador e qualquer resolvedor recursivo que a consulta acabe por alcançar. Cada um tem uma vida útil separada e uma forma separada de ser limpo. Limpar um e testar outro é como as pessoas concluem que a limpeza não fez nada. Um comando de limpeza nunca resolve a questão.

As respostas negativas também são guardadas em cache. Um nome reportado como ausente pode continuar ausente depois de a rede ser corrigida, o que é lido como um túnel avariado quando é um TTL que ainda não expirou. A especificação DNS descreve como estes dados devem ser mantidos e reutilizados.

Registe o evento, não a impressão

Anote qual das três coisas mudou: o registo, o caminho até ao resolvedor ou uma definição do cliente. A edição de um registo propaga-se segundo o seu próprio calendário, uma mudança de rota entra em vigor ao reconectar, e uma definição do navegador aplica-se apenas a esse navegador. Juntá-las num único antes-e-depois produz uma cronologia que ninguém consegue auditar.

Anote a hora, o resolvedor utilizado e a resposta recebida, incluindo o caso em que a resposta é negativa. Isso é um facto que outra pessoa pode verificar.

Faça a comparação duas vezes da mesma forma

Limpe o cache que pretende testar, guarde a observação original e depois consulte de forma a contornar o máximo de memória possível. Nomear o resolvedor explicitamente diz-lhe o que esse resolvedor sabe; não lhe diz que resolvedor a aplicação teria escolhido.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

No Windows, a limpeza do cache de cliente limpa o cache de cliente DNS e nada mais. Não descreve o estado privado de um navegador nem limpa um servidor a montante, pelo que um teste baseado nela só pode ser interpretado de forma estreita. Diga que cache limpou sempre que relatar o resultado.

Depois, volte a testar a aplicação real com um pedido novo e a política de resolvedor pretendida ativa. Um resultado produzido sob uma política diferente não se transfere.