Toda vez que você abre um site, o seu aparelho pede a um resolvedor que transforme o nome de domínio num endereço IP. Essa pergunta é um registro em texto puro de para onde você está indo, e por padrão ela vai para o resolvedor que a sua rede entregou — normalmente o do seu provedor de internet.
Um vazamento de DNS é quando essas consultas vão para um lugar que você não pretendia. O caso comum é um aparelho configurado para usar um resolvedor privado ou criptografado que, por uma entre várias razões estruturais, continua mandando parte ou todas as consultas para o provedor mesmo assim. Nada quebra de forma visível, e é por isso que vazamentos passam anos despercebidos.
O que o DNS expõe de fato?
O domínio, o horário e a origem — o que já basta para reconstruir uma sessão de navegação.
O DNS clássico roda sem criptografia na porta 53. Qualquer um posicionado entre você e o resolvedor consegue ler a consulta, e o próprio resolvedor vê todas elas atribuídas à sua conexão. Ele não vê a página específica, mas o domínio costuma ser a parte sensível.
A criptografia muda quem guarda esse registro, não se ele existe:
| Transporte | Criptografado? | Quem vê a consulta |
|---|---|---|
| DNS puro (porta 53) | Não | A sua rede, o seu provedor, o resolvedor |
| DNS over TLS (DoT, porta 853) | Sim | O resolvedor que você escolheu |
| DNS over HTTPS (DoH, porta 443) | Sim | O resolvedor que você escolheu; mais difícil para a rede distinguir do tráfego web |
| DNSSEC | Não — ele autentica | Igual ao DNS puro; prova que as respostas são genuínas, não as esconde |
DNSSEC é a linha mais mal compreendida. Ele assina as respostas para que não possam ser forjadas. Não oferece confidencialidade nenhuma.
Como os vazamentos acontecem na prática?
Seis causas estruturais cobrem quase todos eles.
| Causa | Mecanismo |
|---|---|
| Roteamento dividido | Parte do tráfego usa um túnel, o DNS vai pela interface padrão |
| IPv6 fora do túnel | O túnel trata só de IPv4, então as consultas IPv6 seguem o caminho do provedor |
| Resolução paralela do sistema | O Windows pode consultar todas as interfaces de uma vez e aceitar a primeira resposta |
| DoH no navegador | O navegador resolve por conta própria, independentemente da configuração do sistema, nos dois sentidos |
| Imposição do roteador | O roteador força o próprio resolvedor via DHCP ou intercepta a porta 53 |
| Portal cativo | Redes de hotel ou aeroporto sequestram o DNS para forçar a página de login |
Vale detalhar o caso do navegador, porque ele corta dos dois lados. Um navegador com a própria configuração de DoH pode ignorar um resolvedor de sistema cuidadosamente configurado e, do mesmo modo, um navegador bem configurado pode esconder o fato de que tudo fora dele continua vazando. Testar um e supor o outro é o erro de teste mais comum.
Como você testa?
Teste cada camada separadamente, porque elas podem discordar entre si.
Sistema operacional — quais resolvedores estão configurados:
| Sistema | Comando |
|---|---|
| macOS | scutil --dns | grep nameserver |
| Windows | Get-DnsClientServerAddress |
| Linux (systemd-resolved) | resolvectl status |
| Linux (genérico) | cat /etc/resolv.conf |
Qual resolvedor realmente respondeu — configuração e comportamento são coisas diferentes:
dig +short whoami.akamai.net devolve o endereço IP do resolvedor que fez a
consulta em seu nome. Compare com o resolvedor que você esperava.
No navegador: abra a configuração de DNS seguro do navegador e veja se está ativada e qual provedor está selecionado. Depois carregue uma página de teste de vazamento de DNS nesse navegador. Se a página apontar um resolvedor diferente do teste em linha de comando, o navegador está resolvendo por conta própria.
IPv6: repita o teste com uma consulta só em IPv6. Um túnel que carrega apenas IPv4 é de longe a causa mais comum de vazamento parcial.
Como você lê o resultado?
Compare o dono do resolvedor com o que você esperava, não com uma lista de endereços "bons".
| Observação | Interpretação |
|---|---|
| O resolvedor é do seu provedor, e você configurou outro | Vazamento |
| Vários resolvedores, um deles do seu provedor | Vazamento parcial — as consultas estão divididas |
| O IPv4 mostra o resolvedor esperado, o IPv6 mostra o provedor | Vazamento de IPv6 |
| Navegador e sistema apontam resolvedores diferentes | Não necessariamente um vazamento, mas dois caminhos independentes a verificar |
| O resolvedor está num país inesperado | Muitas vezes normal — resolvedores anycast respondem do ponto mais próximo |
| O resolvedor é o endereço privado do roteador | Inconclusivo; o roteador encaminha adiante, então cheque a configuração do próprio roteador |
Essa última linha pega muita gente em rede doméstica. Um resultado
192.168.1.1 diz apenas que o seu roteador respondeu. Para onde o roteador
encaminha é outra pergunta, respondida nas configurações de WAN ou de DNS dele.
Quais são os limites de corrigir isso?
Corrigir um vazamento de DNS muda quem fica sabendo quais domínios você consultou. Não torna a visita privada, e exagerar nesse ponto é a principal forma de distorcer o assunto.
Depois que o nome é resolvido, o seu aparelho abre uma conexão com aquele endereço IP. Qualquer observador no caminho vê o endereço de destino e, na maioria das conexões TLS, o nome do servidor é transmitido sem criptografia no handshake, a menos que o Encrypted Client Hello esteja em uso nas duas pontas. Os dois sinais identificam o site independentemente do DNS.
Então o resumo honesto é estreito, mas real: DNS criptografado para um resolvedor da sua escolha tira a lista em texto puro de todos os domínios que você visita da sua rede local e dos registros do seu provedor, e transfere essa lista para quem opera o resolvedor. Isso desloca a confiança em vez de eliminá-la — o que faz de quem opera o resolvedor, e do que ele registra, a pergunta que realmente importa.