O fallback de DNS da sua VPN: para onde a consulta realmente vai

Uma configuração de resolvedor muda do endereço privado para um público, e a conclusão vem imediatamente: o túnel está vazando. Às vezes é verdade. Muitas vezes a consulta de fallback ainda viajou dentro do túnel até um resolvedor que o administrador escolheu, o que a torna uma decisão de política e não um defeito. Separar esses casos exige três fatos em vez de um, e o primeiro é quem respondeu. Descubra quem recebeu a consulta, qual rota a levou e quais nomes foram solicitados.

O fallback é uma política, não um único comportamento

Todo cliente precisa decidir o que fazer quando o resolvedor preferido para de responder. Ele pode bloquear a resolução, tentar de novo, usar uma alternativa configurada ou delegar ao sistema operacional, e do ponto de vista da privacidade esses são quatro produtos diferentes. Ler a tela de configurações diz qual comportamento está configurado; não diz qual ocorreu. Uma tela com um único interruptor não descreve quatro possibilidades.

Os navegadores acrescentam a própria camada. Um navegador com DNS seguro ativado pode resolver um nome pelo provedor que ele mesmo escolheu mesmo quando o sistema operacional aponta para outro lugar, o que significa que a política do cliente do túnel pode nunca ser consultada para as requisições que realmente importam para você. Verifique o aplicativo que fez a requisição, não apenas a configuração do sistema.

A identidade do resolvedor substituto é o primeiro fato que vale a pena estabelecer. Um resolvedor público pertencente a um provedor em que você já confia é uma situação diferente de um endereço fornecido pela rede em que você está. O endereço por si só raramente diz diante de qual dos dois você está.

Quem recebe a consulta após a troca

O destinatário e a rota são independentes, e só a combinação dos dois descreve a exposição. Um resolvedor público alcançado pelo túnel nunca vê o endereço da sua rede de acesso, enquanto o mesmo resolvedor alcançado diretamente o vê. Os dois casos produzem uma resposta, e um teste de vazamento que relata apenas o endereço do resolvedor vai descrevê-los de forma idêntica. Peça a interface além do endereço ao ler o resultado.

Nomes internos tornam a distinção concreta. Um resolvedor público normalmente não consegue responder a um nome de horizonte dividido, então a consulta falha enquanto o nome ainda foi revelado a uma parte que não tinha por que vê-lo. Disponibilidade e privacidade, portanto, andam juntas aqui em vez de serem trocadas.

Um túnel também pode levar a consulta a um resolvedor que não é operado pelo provedor de VPN, porque o túnel encaminha em vez de resolver. O host que encaminha vê a consulta em texto claro e depois abre a própria conexão adiante, o que protege o próximo salto sem proteger o primeiro.

Verifique a rota e o destinatário juntos

Observe os pacotes em vez da configuração. Pergunte ao sistema qual resolvedor seria usado e depois confirme que a consulta saiu de fato da interface esperada para o endereço esperado.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Se a captura mostrar a consulta saindo da interface física com o túnel ativo, o fallback contornou o túnel independentemente do que diga a lista de resolvedores. Se ela aparecer na interface do túnel, a pergunta passa a ser quem opera a extremidade remota e o que ela retém.

Repita a verificação com um nome interno e um nome público. A consulta interna é onde uma configuração de fallback costuma se revelar, porque um resolvedor que não consegue responder recebe a pergunta de qualquer forma.

Decida se o fallback deve ser permitido

Se o requisito é que a resolução pare quando o resolvedor preferido não estiver disponível, configure uma política de aplicação que falhe fechada e aceite a consequência: os nomes não serão resolvidos durante uma interrupção. É uma troca deliberada de disponibilidade e não um mau funcionamento, e o projeto deveria dizer isso antes que a interrupção aconteça.

Se o requisito é apenas que as consultas não viajem para fora do túnel, um resolvedor público alcançado pelo túnel pode ser aceitável desde que o operador e sua política de retenção sejam compreendidos. Essa aceitação é um julgamento sobre terceiros e não uma afirmação sobre criptografia, e pertence a quem sustenta a alegação de privacidade. Se nomes internos precisarem continuar funcionando, o fallback tem de ser um resolvedor que detenha as zonas internas, o que normalmente significa que o alvo do fallback é outro servidor e não outra família de endereços.

Documente o resultado como uma frase sobre comportamento: qual resolvedor recebe consultas em operação normal, qual as recebe após uma falha e se os nomes internos resolvem no segundo caso. Um teste de vazamento que por fim carrega uma página prova menos do que essa frase, porque uma página pode carregar por um resolvedor que nunca deveria ter sido consultado.