DNS da VPN versus DoH do navegador: o que um teste de vazamento não pode dizer

A página do teste de vazamento diz que o seu DNS está bem, o selo do navegador diz seguro, e a wiki interna continua sem carregar. As três coisas podem ser verdadeiras ao mesmo tempo, porque o endereço de um resolver não é a mesma coisa que a política que o escolheu nem o caminho percorrido pela consulta. O que as pessoas chamam de vazamento de DNS é, na verdade, uma única pergunta: qual resolver recebeu o nome, e essa escolha foi intencional? Esclarecer isso exige três verificações, e só a última envolve mudar uma configuração.

Mito um: o selo nomeia o seu resolver

Um teste de vazamento resolve um nome de sonda e informa o endereço que respondeu. Ele não informa a política que escolheu esse resolver, e quando a consulta está envolvida em DNS sobre HTTPS, uma caixa intermediária no caminho não consegue ver o nome de jeito nenhum. Duas máquinas muito diferentes produzem o mesmo selo tranquilizador: uma em que a VPN empurrou 10.8.0.1 e o navegador o usa, e outra em que o navegador ignorou a lista do sistema e enviou o nome pelo túnel ao seu próprio provedor cifrado.

A distinção importa no momento em que um nome privado falha. Na primeira configuração o resolver da VPN responde pela zona corporativa; na segunda o navegador nunca lhe perguntou, então o nome de host curto não é resolvido e a falha parece uma VPN quebrada. A verificação não é outro teste de vazamento, é uma consulta a um nome que só um resolver conhece.

Mito dois: o navegador sai do túnel

O DNS escolhe um endereço, o roteamento carrega a conexão, e são duas camadas separadas. Uma consulta enviada a um provedor DoH público continua sendo TCP porta 443 para um endereço roteável. Se a sua tabela de rotas envia a rota padrão para o túnel, essa consulta também passa pelo túnel. A marca do resolver não decide o caminho.

O que o DoH do navegador muda é o destinatário dos nomes. É uma decisão real de privacidade e uma decisão real de política, mas não é um desvio de roteamento. Se o seu requisito é que os nomes fiquem com o operador da VPN, uma consulta cifrada a outra pessoa falha nesse requisito enquanto ainda usa o túnel para a conexão real.

Mito três: cada VPN sobrepõe-se a cada navegador

O DNS seguro de um navegador tem modos, não um interruptor: desativado, um provedor padrão com alternativa, um modelo personalizado ou uma política imposta pelo sistema operacional ou pela organização. É o caso de alternativa que produz relatórios intermitentes. Quando o ponto final cifrado não é acessível, o navegador pode recorrer ao resolver do sistema, então o mesmo portátil resolve corretamente um nome privado na segunda-feira e não na terça.

Ao mesmo tempo, a maioria dos clientes VPN configura o resolver do sistema quando a conexão sobe e restaura o anterior quando ela cai. Um navegador que mantém um resolver cifrado personalizado não observa essa restauração de forma alguma. Por isso o mesmo perfil se comporta de maneira diferente em dois portáteis e por isso resolv.conf parece correto enquanto o navegador ainda pergunta a outra pessoa.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Execute esses comandos enquanto estiver conectado, anote quais domínios cada resolver reivindica e compare com o que o navegador relata sobre o próprio modo. A documentação de DoH da Mozilla é uma descrição razoável de como o comportamento padrão e o de alternativa de um navegador devem funcionar.

A decisão tem três entradas, não uma

Os nomes privados, a confiança no operador e a acessibilidade decidem a disposição correta. Os nomes que só o resolver da VPN conhece obrigam a um DNS dividido: o sufixo privado vai para o resolver empurrado, e todo o resto segue a política que você escolheu para nomes públicos. A confiança no operador decide se os nomes públicos também devem ir para esse resolver ou para um serviço separado. A acessibilidade decide se o resolver cifrado escolhido é sequer utilizável nesta rede.

Nenhuma destas linhas é uma recomendação universal. Um resolver operado pela VPN concentra as observações nesse operador; um serviço separado acrescenta outro destinatário dos nomes consultados. Nenhuma das duas disposições prova nada sobre retenção, a menos que você leia a política.

Anote a decisão por perfil, porque essas configurações derivam. Um perfil que empurrou um resolver no mês passado talvez hoje não empurre nenhum, e o navegador manterá de bom grado um ponto final personalizado antigo que ainda responde. Na nota devem constar o endereço do resolver, os sufixos que ele possui e o modo do navegador, não a marca do serviço.

Teste a política que você acredita ter configurado

Teste por nome, não por selo. Resolva um nome público e um nome privado pelo resolver do sistema, e depois repita dentro do navegador com a configuração de DNS seguro dele no modo que você pretende usar. Se o nome privado falhar apenas no navegador, você encontrou a incompatibilidade de destinatário sem tocar em uma única configuração da VPN.

Depois reconecte e verifique a restauração, porque é aí que vivem os erros de transferência: desconecte, confirme que o resolver anterior voltou, reconecte, confirme que o empurrado voltou. Por fim, teste um navegador com política gerenciada se tiver um, porque esse modo pode recusar totalmente a sua alteração e manter silenciosamente o resolver anterior.

Comece pela pergunta do espaço de nomes e você evitará a maior parte disso. Se a máquina precisa alcançar nomes internos, o resolver cifrado do navegador é uma decisão apenas sobre a metade pública, e a metade privada fica com o que a VPN tiver empurrado.