Seu VPN criptografa o DNS ou apenas o próximo salto?

Ativar DNS criptografado no servidor VPN costuma ser descrito como fechar um vazamento, e essa descrição esconde qual conexão mudou. O salto do cliente até o resolvedor e o salto do resolvedor até a montante são conexões separadas com donos separados. Criptografar uma delas deixa a outra exatamente como estava.

Anote quem recebe a consulta em cada etapa antes de tocar em um arquivo de configuração.

Duas configurações parecem iguais na página de ajustes

Na primeira configuração, o dispositivo executa o DNS over TLS por conta própria, e o túnel apenas transporta essa conexão até um resolvedor que você escolheu. A sessão TLS termina no resolvedor, o que significa que o resolvedor vê a consulta e a saída da VPN vê texto cifrado que não consegue ler. Na segunda configuração, o dispositivo envia DNS comum pelo túnel até um encaminhador no host da VPN, e esse encaminhador abre a própria conexão criptografada com um resolvedor a montante. Numa lista de recursos, as duas parecem "DNS criptografado com uma VPN", e colocam a consulta legível em prédios diferentes.

A diferença é mensurável, não filosófica. Procure a sessão TLS no cliente ou no servidor, e você descobre qual configuração realmente tem.

Mapeie a cadeia de resolvedores antes de alterá-la

Conte os resolvedores no caminho e nomeie o papel de cada um. Um componente de encaminhamento entrega uma requisição a outro resolvedor, enquanto um resolvedor recursivo faz o trabalho de encontrar uma resposta e pode falar diretamente com servidores autoritativos. Esses papéis são definidos separadamente exatamente por esse motivo, e as definições de resolvedor da RFC 9076 valem a leitura antes de você supor que existe um único destino a montante. Um host que executa o próprio resolvedor recursivo não tem um único "upstream" para criptografar, o que invalida o plano inteiro.

Depois pergunte qual componente o cliente está configurado para usar. Um endereço DNS enviado pelo perfil da VPN informa para onde as consultas vão, não qual processo as responde.

Observe também o comportamento em falha. Se a montante criptografada ficar inalcançável, o encaminhador falha fechado, volta para texto simples ou volta para outro resolvedor? Essa decisão pertence ao registro, porque altera a garantia de privacidade no momento em que o túnel está menos saudável.

Verifique qual salto está criptografado

Comece no cliente e confirme se ele mantém uma sessão TLS para a porta 853. Uma consulta que resolve corretamente pela porta 53 não prova nada sobre criptografia.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Em seguida, vá para o host da VPN e procure a conexão criptografada de saída que o encaminhador abriu. A tabela de sockets informa se existe uma sessão TLS a montante e qual processo a possui:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Se o cliente mostra uma sessão TLS e o servidor não mostra nenhuma, você está na primeira configuração e o servidor não consegue ler as consultas que encaminha na camada IP. Se o servidor mostra a sessão TLS e o cliente mostra tráfego comum da porta 53 dentro do túnel, você está na segunda configuração: o salto seguinte está protegido, e o encaminhador ainda lê todo nome que o dispositivo pede. Esse segundo resultado não é uma falha, mas chamá-lo de criptografia ponta a ponta é errado.

Registre o dono e o comportamento em falha

A propriedade decide o que você tem permissão para prometer. O dono do dispositivo controla uma conexão criptografada no lado do cliente, enquanto o administrador da VPN controla a conexão seguinte que o encaminhador dele cria. Quem não opera nenhuma das duas só pode descrever o caminho.

Antes de ativar qualquer coisa, verifique a nomenclatura interna. Enviar nomes organizacionais para um resolvedor público não é um projeto equivalente, e uma zona split-horizon que existe apenas dentro da rede não será resolvida na montante de forma alguma. Teste um nome interno e um nome público após a mudança, e guarde o resultado junto com a alteração de configuração. Se o caminho criptografado quebrar a resolução para hosts internos, a correção é uma regra de resolvedor com escopo, não um túnel mais amplo.

Termine escrevendo uma frase por salto: qual componente recebeu a consulta, se aquele salto era criptografado e quem pode ler o nome. Quando a frase sobre o host da VPN ainda diz que ele consegue ler as consultas, a documentação deve dizer o mesmo, porque um diagrama que afirma o contrário será confiado por alguém que nunca executou os comandos.