O DNS encriptado sem VPN esconde a consulta, não o seu endereço

Um teste de fuga de DNS que mostra a sua rede doméstica não é prova de que o DNS encriptado falhou, nem prova de que algo funcionou. O teste responde a uma pergunta: a que resolvedor chegou esta consulta a partir desta rede. Se isso é um problema depende do que e de quem estava a proteger.

Escreva o objetivo antes de executar qualquer teste.

Passo 1: nomeie a proteção que realmente quer

Três objetivos misturam-se. Pode querer que um observador no caminho deixe de ler consultas. Pode querer que um determinado resolvedor deixe de as receber. Pode querer que os sites que visita deixem de ver o seu endereço de casa. O DNS encriptado serve o primeiro, muda quem satisfaz o segundo e não faz absolutamente nada pelo terceiro.

Uma VPN serve o terceiro e, dependendo do fornecedor, o primeiro. Nenhuma das ferramentas é um superconjunto da outra.

Passo 2: escolha um resolvedor e verifique a sua identidade

O DNS over TLS envolve a consulta numa sessão TLS com o resolvedor, e o DNS over HTTPS envolve-a num pedido HTTP; os RFC 7858 e RFC 8484 descrevem ambos, e nenhum precisa de um túnel. O que importa operacionalmente é que o certificado seja verificado contra o nome que configurou, porque uma sessão encriptada com a parte errada é pior do que texto simples com a certa. Isso significa modo estrito onde a plataforma o oferece, não um modo oportunista que recua quando a verificação falha. Verifique a sessão diretamente antes de confiar na definição: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

O handshake deve nomear o resolvedor que configurou e devolver uma cadeia que possa verificar.

Passo 3: decida o comportamento em caso de falha

Cada implementação tem uma política para um resolvedor encriptado inalcançável, e essa política é a decisão de privacidade. O modo estrito falha a pesquisa, o que é visível e irritante. O modo oportunista tenta novamente em texto simples, o que é invisível e arruína o propósito precisamente no dia em que importa. Escolha deliberadamente e depois registe a escolha ao lado do requisito.

No systemd-resolved isso significa DNSOverTLS=yes em vez de opportunistic; no Android significa o modo de nome de anfitrião do Private DNS em vez de automático.

Verifique o que está realmente em vigor com resolvectl status | grep -i -A1 "dns over tls", porque um ficheiro drop-in que nunca foi recarregado não muda nada.

Passo 4: verifique se as aplicações seguem o resolvedor do sistema

Um navegador com a sua própria definição de DNS seguro ignora completamente a configuração do sistema, e o mesmo faz um runtime de contentores com um resolvedor incorporado ou um runtime de linguagem que lê uma lista codificada. Ou faz com que sigam o sistema, ou configura-os explicitamente e registe isso. Depois veja o comportamento de recuo de cada um, porque não falham todos de forma fechada. O inventário na prática é curto: navegador, runtime de contentores e qualquer cliente VPN que também execute.

Os nomes privados da organização ficam no resolvedor interno aprovado. Enviá-los para um serviço público para que um teste pareça arrumado cria deliberadamente outro problema.

Passo 5: leia o teste de fuga face ao requisito

Um teste que relata um resolvedor inesperado é uma pista, não um veredicto. Pode ter observado o resolvedor encriptado pretendido, uma definição específica de uma aplicação ou um recuo para texto simples que não conhecia. Compare o resolvedor relatado com o que o passo 2 configurou e compare o resultado com o objetivo do passo 1.

Se o objetivo era manter as consultas longe da rede local, um teste que mostra o seu resolvedor habitual é uma descoberta real. Se o objetivo era o anonimato durante a navegação, nenhuma definição de DNS o teria alguma vez proporcionado.

Escreva a linha de aceitação na língua do objetivo: estas pesquisas usam este resolvedor verificado nestas condições. Tudo o que seja mais amplo é uma afirmação que não pode testar.