Teste de fuga de DNS: o nome do resolver não é a rota

Três arranjos contam como DNS correto para um utilizador de VPN: consultas ao resolver do operador, consultas a um resolver encriptado que escolheu e split DNS que envia nomes de trabalho para a organização. Um teste de fuga reporta um resolver, e esse único rótulo não lhe diz qual arranjo tem realmente. Decida primeiro a política pretendida e teste depois em relação a ela. Caso contrário, está a comparar um número com uma sensação.

Decida o que queria antes de ler o resultado

Nomeie a política numa frase: todos os nomes para o resolver da VPN, todos os nomes para um resolver encriptado escolhido, ou split DNS com nomes internos a ir para a organização. Cada uma é defensável para um utilizador diferente, e cada uma produz uma resposta esperada diferente. Sem essa frase, qualquer resultado diferente de uma captura de ecrã num post de fórum parece alarmante. Escreva a política antes do primeiro teste.

Um teste feito antes de a política ser definida não mede nada. Produz um nome de resolver sem qualquer ponto de referência.

O nome do resolver não prova o caminho nem o destinatário

Duas perguntas importam: quem recebeu a consulta e que rota a transportou. Um resolver de terceiros pode ser alcançado através do túnel enquanto o ecrã de definições mostra o endereço do fornecedor. O rótulo numa página de teste de fuga descreve a visão do observador, não a sua tabela de encaminhamento.

Um navegador pode usar o seu próprio DNS encriptado enquanto o tráfego do site passa pelo túnel, e respostas em cache podem permitir que uma página carregue sem uma nova consulta. É por isso que um resultado de IP público não diz nada sobre DNS. DoH e DoT protegem a consulta no caminho até ao resolver, e esse resolver continua a ver os nomes.

resolvectl status
resolvectl query example.com
dig +short example.com

O split DNS torna vários resolvers corretos

Uma organização pode enviar nomes internos para o seu próprio DNS e todo o resto para outro lugar. Um teste que lista vários resolvers pode, por isso, descrever a política pretendida e não uma falha. Compare o conjunto observado com as regras de split DNS documentadas antes de desativar algo. Desligar o resolver interno para uma página de teste parecer mais limpa quebra nomes privados.

Split tunneling e split DNS são escolhas diferentes: um encaminha pacotes, o outro encaminha perguntas. Mudar uma rota do túnel não move uma procura de nome, e mudar o resolver não corrige o caminho de um site. IPv6 é uma terceira pergunta, porque uma ligação IPv6 não intencional não é automaticamente uma fuga de DNS.

Transforme o resultado numa investigação

Registe a política pretendida e a definição de DNS seguro do navegador antes de testar. Execute o teste com o túnel ativo, anote cada resolver que ele nomeia e compare o conjunto com a política e não com um único endereço esperado.

Repita após uma reconexão se é então que o sintoma aparece, porque uma política aplicada no momento da ligação pode perder-se mais tarde. Use a documentação do cliente para exceções de DNS internas em vez de adivinhar as definições.

Corrija a discrepância que encontrou: uma escolha do navegador, uma definição de DNS da VPN ou uma regra de split DNS. Se as consultas têm de parar quando o túnel falha, o kill switch é uma definição separada, e a configuração de DNS sozinha não a fornece. A especificação RFC 8484 é útil quando precisa de explicar o que um resolver encriptado esconde e o que não esconde.