O DNS não resolve quando o kill switch da VPN bloqueia a porta 53

Quando o kill switch derruba o túnel, ele leva junto o caminho do DNS, e o resolvedor que sobra raramente é o que você espera. Dois projetos tratam esse momento de forma muito diferente: bloquear todo pacote DNS que não esteja dentro do túnel, ou deixar um resolvedor de pé como exceção. Os dois são defensáveis. De uma aba do navegador os sintomas parecem quase idênticos, então a primeira tarefa é descobrir qual projeto você realmente implantou.

Mantenho essa distinção diante dos olhos porque a correção é oposta em cada caso. Um projeto precisa de uma exceção mais ampla, o outro de uma mais estreita. Adivinhar custa a você ou a privacidade ou uma tarde.

Dois projetos de DNS para a mesma queda

O projeto A trata o resolvedor como mais um serviço atrás do túnel. As regras do firewall permitem UDP e TCP 53 apenas na interface do túnel, e o endereço entregue ao cliente é um resolvedor dentro do túnel. Quando o túnel cai, as consultas param, e esse é o resultado pretendido, não uma falha.

O projeto B mantém um resolvedor acessível na rede local, normalmente o roteador em 192.168.1.1 ou o stub do sistema operacional em 127.0.0.53, com o argumento de que a resolução de nomes não deveria morrer com o túnel. É conveniente numa LAN doméstica onde o roteador resolve para a casa toda. No Wi-Fi de um hotel ou aeroporto a mesma exceção aponta para o servidor de outra pessoa, e todo nome que você digita fica exposto, mesmo que seu tráfego web continue bloqueado.

A fronteira é quem é dono do resolvedor. Se você confia no local, uma exceção é um buraco pequeno e honesto. Se não confia, o projeto só-túnel é o único que se sustenta, e o preço é que um túnel caído leva todos os nomes junto.

Por que a consulta do próprio cliente VPN continua funcionando

O cliente precisa resolver o nome de host do gateway antes de existir um túnel, então um bloqueio estrito não deve cobrir o caminho de inicialização do cliente. A maioria dos clientes ou faz cache do endereço do endpoint ou fornece uma exceção de inicialização documentada para esse único host. Se o seu conjunto de regras bloqueia essa consulta, o túnel nunca volta e os logs mostram um cliente que não alcança o próprio servidor, o que é um defeito de política e não de DNS.

O DNS dividido é o outro lugar onde isso aparece. O cliente empurra uma zona interna para um resolvedor privado e deixa todo o resto com o resolvedor do sistema. Depois de uma queda, nomes públicos podem ainda resolver enquanto os internos estouram o tempo, porque a zona privada não tem mais rota. Para o usuário isso é "a VPN quebrou a internet"; para o log do resolvedor é uma consulta que nunca chegou.

Com systemd-resolved você vê a divisão diretamente. resolvectl status lista os servidores DNS por enlace e os domínios de roteamento, e depois que o túnel cai o domínio interno continua apontando para um servidor num enlace que não existe mais. O stub em 127.0.0.53 ainda aceita a consulta, depois espera por um upstream que não vai responder, e é por isso que a falha leva segundos em vez de voltar de imediato.

DNS criptografado não contorna um filtro de pacotes

DNS sobre HTTPS e DNS sobre TLS trafegam nas portas 443 e 853, então uma regra que bloqueia a porta 53 não disse nada sobre eles. Bloquear "DNS" por porta é uma política sobre uma porta, não sobre resolução de nomes. Se o seu kill switch bloqueia todo o tráfego fora do túnel, o DoH fica coberto por acidente. Se você abriu uma exceção para um portal cativo ou um resolvedor público, não fica.

Os controles do lado do cliente são a alavanca mais barata. O Firefox abandona o próprio resolvedor DoH quando o nome canário use-application-dns.net não resolve, e é por isso que redes gerenciadas publicam esse domínio como NXDOMAIN; a política corporativa também pode fixá-lo desligado. O Android Private DNS e o DNS seguro do Chrome têm seus próprios interruptores e seus próprios padrões. Desligá-los é mais confiável do que correr atrás de endereços de resolvedores, porque a lista de endereços muda e o seu conjunto de regras não.

Existe uma versão disso que não trata de vazamentos de forma alguma. Um aplicativo com resolvedor fixado ainda precisa de um caminho de rede para alcançá-lo. A criptografia muda quem pode ler a consulta, não se o pacote pode sair da máquina, então um bloqueio para o dispositivo inteiro derrota o ajuste sem tocá-lo.

Case o sintoma com a camada

A maioria dos relatos chega como uma frase, e essa frase normalmente já nomeia a camada. A tabela abaixo é o que eu passo antes de tocar numa regra; o ponto é decidir se a consulta foi bloqueada, mal encaminhada ou nunca enviada.

As duas primeiras linhas são as que as pessoas diagnosticam errado. Uma queda silenciosa e uma recusa parecem ambas "o DNS quebrou" no navegador, mas só uma das duas significa que seu kill switch está fazendo o trabalho dele. Uma recusa significa que algo respondeu, então o bloqueio não está onde você pensa.

Restaure a política do resolvedor e depois prove

Conserte o projeto, não o sintoma. Para resolução só pelo túnel, permita 53 na interface do túnel, empurre o resolvedor interno junto com a configuração do túnel e deixe o enlace físico sem nenhuma permissão de DNS. No wg-quick, a linha DNS = é a que grava o resolvedor na configuração da interface, então um túnel que a omite deixa o resolvedor antigo no lugar e cada consulta no caminho errado. O manual do wg-quick documenta esse comportamento por plataforma.

Depois verifique nesta ordem. No Linux, resolvectl status mostra o enlace ativo, dig +short example.com testa um nome público, dig @10.8.0.1 internal.example.com testa o privado, e sudo tcpdump -ni any port 53 mostra qual interface os pacotes usam enquanto você executa os dois. No Windows, Get-DnsClientServerAddress -AddressFamily IPv4 e Resolve-DnsName example.com dão os mesmos dois fatos: quem está configurado e quem responde.

Termine com o teste negativo. Desconecte o túnel, confirme que um nome público novo falha, confirme que o nome privado falha, e confirme que nenhum pacote da porta 53 saiu do adaptador físico. Um bloqueio que só se sustenta para respostas em cache não se sustenta de jeito nenhum.

Lista de verificação antes de fechar o chamado:

• O resolvedor usado durante a queda é o que a política pretende.
• A consulta do próprio endpoint do cliente continua permitida, por cache ou por exceção.
• DoH e DoT estão cobertos pelo bloqueio ou desativados por política.
• As zonas privadas falham fechadas, não abertas, assim que o túnel some.