Teste de fuga DNS 2026: método completo + correção por sistema operativo

DNS — Domain Name System, definido no RFC 1034 — é a lista de endereços da Internet. Quando escreve anonymflow.com no navegador, o seu computador pede a um servidor DNS o endereço IP correspondente. O servidor responde 198.51.100.42, e a ligação pode ser estabelecida. O problema: se esta consulta DNS contornar o seu túnel VPN, o seu fornecedor de Internet (ISP) vê a lista exata dos domínios que visita — mesmo que todo o restante tráfego esteja cifrado no túnel VPN. Chama-se a isto uma fuga DNS, e a nossa auditoria interna a 6 grandes VPN mostra que continua a ser frequente em 2026 nas configurações não auditadas.

Porque ocorrem as fugas DNS? As 4 causas técnicas

Uma fuga DNS ocorre quando as consultas de resolução de nomes saem pelo resolver do seu operador em vez do túnel VPN, apesar de a VPN estar ativa. As quatro causas: (1) Windows Smart Multi-Homed DNS envia as consultas em paralelo por todas as interfaces; (2) o DoH do navegador (Firefox, Chrome) contorna completamente o DNS do sistema; (3) VPN sem gestão DNS nativa; (4) IPv6 não encapsulado em que as consultas DNS IPv6 saem em claro.

Uma VPN encapsula o seu tráfego num túnel cifrado entre o seu dispositivo e o servidor VPN remoto. Em teoria, todas as consultas — incluindo o DNS — passam por este túnel. Na prática, várias configurações do sistema contornam o túnel especificamente para as consultas DNS. Compreender as quatro causas principais permite-lhe identificar qual o afeta e aplicar a correção correta.

Causa #1 — Windows e Smart Multi-Homed DNS. Desde o Windows 8, a Microsoft implementou um comportamento chamado Smart Multi-Homed Name Resolution (SMHNR) que envia as consultas DNS para todas as placas de rede ativas em paralelo, mantendo a primeira resposta recebida. Quando uma VPN está ligada, o Windows envia portanto a consulta tanto para o DNS da VPN COMO para o DNS do operador através da interface Wi-Fi/Ethernet subjacente. Se a resposta do operador chegar primeiro (muitas vezes o caso a nível local), é usada e o operador registou a consulta. É um comportamento documentado "by design" que cria fugas sistemáticas nas VPN que não desativam explicitamente o SMHNR.

Causa #2 — Navegadores com DoH ativado separadamente. O Firefox ativa o DNS-over-HTTPS por predefinição em direção a Cloudflare 1.1.1.1 desde 2020. O Chrome oferece a mesma funcionalidade. Estes resolvers DoH do navegador contornam completamente o DNS do sistema — logo, também o da VPN — a menos que o navegador detete especificamente a presença de uma VPN ativa. O Firefox deteta-o por vezes ao observar a interface de rede ativa; o Chrome de forma menos sistemática. Resultado: as suas consultas DNS a partir do navegador vão diretamente para a Cloudflare, fora do túnel VPN.

Causa #3 — VPN sem gestão DNS nativa. Algumas VPN de gama baixa não declaram os seus próprios servidores DNS na configuração do sistema quando o túnel é ativado. O sistema operativo continua então a usar os servidores DNS que tinha antes — tipicamente os do operador fornecidos por DHCP. É o caso da maioria das VPN gratuitas e de várias VPN pagas secundárias. A NordVPN, ExpressVPN e Surfshark tratam corretamente deste aspeto desde as suas versões de 2023+.

Causa #4 — IPv6 não encapsulado. Muitas VPN encapsulam apenas o tráfego IPv4 no seu túnel. O tráfego IPv6 — ativo, no entanto, por predefinição na Free, em certas configurações Orange e em todos os routers modernos — sai diretamente fora da VPN. As consultas DNS IPv6 chegam aos servidores DNS IPv6 do operador, que as regista. A solução: a opção "Bloquear tráfego IPv6" ou "Encapsular IPv6" ativada na VPN. A NordVPN suporta o encapsulamento IPv6 desde 2024.

Como testar uma fuga DNS? (método de 3 ferramentas)

Teste de 2 minutos: com a VPN ativa, vá a dnsleaktest.com → Extended Test. A ferramenta lista quais os servidores DNS que resolveram as suas consultas. Se vir os resolvers do seu operador (Orange, Comcast, BT, Free), é uma fuga confirmada. Confirme cruzando com browserleaks.com/dns para isolar se a origem é o sistema ou o DoH do navegador.

O método clássico consiste em visitar um serviço que lhe diz qual o servidor DNS que efetivamente resolveu a sua consulta. Estes serviços funcionam gerando um subdomínio aleatório único (abc123xyz.dnsleaktest.com), provocando a sua resolução a partir do seu navegador e lendo, do lado do servidor, que IP fez a resolução. Três ferramentas de terceiros reconhecidas permitem o cruzamento dos resultados.

Ferramenta #1 — DNSLeakTest.com. O teste de referência desde 2008. Procedimento: ligue a VPN, abra o URL, clique em "Extended Test" (não em "Standard Test", que é insuficiente), aguarde 10-20 segundos. A ferramenta lista os servidores DNS que responderam — tipicamente 2 a 6 resolvers diferentes (os servidores DNS modernos usam arquiteturas com balanceamento de carga). Compare com os servidores DNS do seu operador: se corresponderem, fuga confirmada.

Ferramenta #2 — BrowserLeaks DNS. Teste complementar que cruza DNS padrão, DNS-over-HTTPS e resolvers detetados via WebRTC. Particularmente útil para identificar se a fuga vem do navegador (DoH ativado) em vez do sistema. Execute após dnsleaktest.com para validar a consistência do resultado.

Ferramenta #3 — a nossa ferramenta integrada /tools/dns-leak-test. Para o teste WebRTC em particular (que é a causa de fuga do lado do navegador mais frequente em 2026), a ferramenta interna do site sonda os candidatos ICE WebRTC a partir do seu navegador e revela o seu IP real se existir uma fuga a este nível.

Para identificar o DNS do seu operador a comparar com os resultados: pesquise no Google "DNS Orange" (resolvers 80.10.246.X), "DNS Free" (212.27.40.240 e 212.27.40.241), "DNS SFR" (109.0.66.20), "DNS Bouygues" (194.158.122.10). Se o endereço mostrado pelo DNSLeakTest corresponder a um intervalo do operador ou ao nome do seu sistema autónomo (AS), está a ter uma fuga. Se corresponder à NordVPN ("Tefincom", AS136787), ExpressVPN, Cloudflare (AS13335), Quad9 (AS19281), Google Public DNS (AS15169), está tudo bem.

Como corrigir consoante a causa detetada

Caso 1 — VPN com opção "DNS Leak Protection" adormecida

O caso mais comum e mais simples. Na NordVPN, Surfshark, ExpressVPN, ProtonVPN, Mullvad, a opção de proteção contra fugas DNS existe mas pode estar desativada por predefinição em instalações mais antigas. Procedimento de verificação na NordVPN: Settings → Connection → Custom DNS Protection → ative "Auto DNS" ou "NordVPN DNS". Na Surfshark: Settings → Connectivity → Custom DNS → desative (deixe a Surfshark gerir). Na ExpressVPN: Preferences → Advanced → DNS Network Lock → verifique se está ativado.

Após a ativação, reinicie a VPN (desligue / volte a ligar) e refaça o DNSLeakTest. Na maioria dos casos, a fuga desaparece nesta etapa.

Caso 2 — Windows Smart Multi-Homed DNS

Se ativar a DNS Protection da VPN não for suficiente e estiver no Windows 10/11, o culpado é provavelmente o SMHNR. Desativação manual via PowerShell como administrador:

Set-DnsClientGlobalSetting -SmartMultiHomedNameResolution $false

Este comando desativa completamente o comportamento SMHNR. Para reativar mais tarde: Set-DnsClientGlobalSetting -SmartMultiHomedNameResolution $true. Após a desativação, reinicie o computador. O SMHNR não se reativará até uma atualização importante do Windows (volte a verificar após cada feature update do Windows).

Alternativa menos invasiva: forçar a prioridade da interface VPN com Get-NetAdapter | Set-NetIPInterface -InterfaceMetric 1 que define todas as interfaces VPN como prioridade mais alta. Menos fiável do que desativar o SMHNR mas não mexe no registo do Windows.

Caso 3 — Firefox com bypass de DoH

Se o teste BrowserLeaks DNS revelar a Cloudflare como resolver quando não configurou a Cloudflare como DNS do sistema, o seu navegador Firefox é o culpado. Procedimento de correção: abra about:preferences#general → desça até "DNS over HTTPS" → selecione "Off" ou "Default protection" que desativa automaticamente o DoH quando é detetada uma VPN ativa. Guarde, reinicie o Firefox, teste novamente.

Para o Chrome: chrome://settings/security → desative "Usar DNS seguro". Para o Edge: edge://settings/privacy → idem. Para o Safari: sem DoH do navegador, o sistema trata disso.

Caso 4 — Sem opção na sua VPN atual

Se a sua VPN não tiver nenhuma das opções acima e continuar a ter fugas, duas opções. Opção radical: configurar manualmente um DNS público cifrado ao nível do sistema. No Windows: Definições → Rede → Placa → Propriedades → IPv4 → DNS manual → Cloudflare 1.1.1.1 / 1.0.0.1. No macOS: Preferências do Sistema → Rede → Avançado → DNS → adicione 1.1.1.1. No Linux: edite /etc/resolv.conf (ou via systemd-resolved). Não é ideal — a sua VPN deveria tratar disso — mas neutraliza a fuga.

Opção pragmática: mudar de VPN. Uma VPN que tem fuga DNS em 2026 sem uma opção adequada está tecnicamente obsoleta. A nossa análise completa da NordVPN confirma a ausência de fugas DNS nos testes cruzados padrão.

O DNS over HTTPS (DoH) substitui uma VPN?

Pergunta frequente: se o DoH cifra as consultas DNS, é suficiente como proteção em vez de uma VPN completa? A resposta técnica precisa: não, o DoH não substitui uma VPN.

O DoH (DNS-over-HTTPS, definido no RFC 8484) cifra as suas consultas DNS entre o seu navegador e um resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). É uma camada de proteção útil contra um sniffer numa rede Wi-Fi pública ou um operador que examina as suas consultas DNS em claro. Mas o DoH não altera as outras três dimensões que uma VPN protege:

O DoH não oculta o seu IP público visto pelos sites visitados. Um site que vê oSeuIPpublico.com aceder ao seu conteúdo continua a segui-lo por IP, independentemente de a sua resolução DNS estar cifrada. O DoH não altera a rota do seu tráfego principal — apenas a resolução DNS é cifrada. O tráfego HTTPS principal para o site continua a circular em claro a partir do seu IP real. O DoH também não encapsula outros protocolos (BitTorrent, SSH, etc.) que permanecem visíveis para o seu operador.

Se já usa uma VPN, desative o DoH ao nível do navegador para evitar criar dois caminhos DNS divergentes (um via DoH do navegador, outro via túnel VPN). Deixe a VPN tratar da resolução completa através do seu túnel. Se não tem uma VPN, ativar o DoH acrescenta uma camada de proteção parcial mas não substitui uma VPN nos casos de uso em que o IP público importa (streaming com restrições geográficas, contorno da censura, proteção contra a criação de perfis baseada em IP).

O aspeto legal de uma fuga DNS em França

No lado francês, as fugas DNS implicam uma questão legal não negligenciável. Ao abrigo da lei Hadopi 2.0 e da diretiva europeia ePrivacy, os operadores franceses são obrigados a conservar os registos de resolução DNS durante pelo menos 12 meses. Estes registos são acessíveis mediante ordem judicial no âmbito de investigações ou ações cíveis. Se usa uma VPN para proteger o histórico dos domínios visitados (por exemplo, porque consulta sites politicamente sensíveis, sites médicos confidenciais ou fóruns anónimos), uma fuga DNS revela a lista exata dos domínios ao seu operador — e potencialmente às autoridades.

A situação é comparável em Espanha (o RDL 14/2019 impõe a conservação de dados pelos operadores) e no Reino Unido (Investigatory Powers Act 2016 — vigilância estatal ativa sobre os operadores britânicos). Nos Estados Unidos, a FCC removeu as proteções de privacidade dos operadores em 2017, autorizando a venda direta dos históricos DNS a corretores de dados.

Consequência prática: uma VPN cujo DNS tem fugas é tecnicamente inútil para o objetivo de privacidade, independentemente da qualidade da cifragem do túnel para o resto do tráfego. É por isso que o DNSLeakTest se tornou um critério obrigatório em qualquer avaliação séria de VPN — tem mais valor do que os benchmarks de velocidade.

Resumo dos passos — checklist aplicável em 2 minutos

Para não falhar nada, eis a sequência exata de auditoria DNS a aplicar após a instalação da VPN ou uma atualização importante do Windows/macOS: (1) desligue a VPN e execute dnsleaktest.com → anote os servidores DNS revelados (referência do operador), (2) ligue a VPN e volte a executar dnsleaktest.com → anote os novos servidores DNS, (3) se os servidores corresponderem à VPN, OK; se corresponderem ao operador, fuga confirmada, (4) aplique a correção consoante a causa identificada (casos 1 a 4 acima), (5) volte a verificar após cada alteração.

Este procedimento deve ser refeito após cada atualização importante: os feature updates do Windows 11 por vezes restauram o SMHNR; as versões do macOS podem reintroduzir resolvers DNS Apple em paralelo; os navegadores Firefox/Chrome ativam automaticamente o DoH em certas instalações. O nosso protocolo completo de teste de VPN inclui este teste em cada ciclo trimestral. Para ir mais além no perfil de rede exposto ao ponto de acesso, veja também o nosso guia de spoofing MAC em Wi-Fi público — a aleatorização MAC complementa utilmente a proteção DNS.

O que reter

Uma fuga DNS não é uma catástrofe imediata em termos de cibersegurança, mas é uma falha de privacidade silenciosa: o seu operador continua a registar o histórico dos domínios visitados apesar da VPN ativa. Se usa uma VPN precisamente para isso, é irónico. O teste demora 2 minutos via dnsleaktest.com ou a nossa ferramenta integrada /tools/dns-leak-test. Como verificação complementar, verificar o seu verdadeiro endereço IP público antes e depois do túnel continua a ser o controlo de consistência mais rápido para confirmar que a VPN mascara o IP além de fechar a fuga DNS.

Se detetar uma fuga, a solução depende da causa (opção VPN a ativar, SMHNR do Windows a desativar, DoH do navegador a desativar, IPv6 a encapsular). Na maioria dos casos, uma VPN séria e atualizada resolve o problema ativando a sua opção dedicada. Se continuar a ter fugas depois disso, a VPN está tecnicamente obsoleta — mude. A NordVPN, ExpressVPN e Surfshark ativam a sua DNS Leak Protection por predefinição desde 2023 e passam estes testes de forma fiável.

Avaliação editorial independente baseada em capacidades de serviço documentadas, auditorias independentes publicadas e benchmarks públicos, com verificações através de ferramentas padrão (iperf3, dnsleaktest.com, browserleaks). As ligações comerciais têm o atributo rel="sponsored nofollow"; uma comissão de afiliação pode aplicar-se sem custo adicional para o leitor e sem qualquer influência na classificação.