DNS privado versus VPN: o que cada camada cobre de verdade

O seu telefone tem o DNS privado definido para um nome de host de provedor e um aplicativo de VPN em execução ao mesmo tempo. É razoável supor que um dos dois agora esteja encarregado das consultas de nomes. Nenhum dos dois está, no sentido que essa frase sugere, e a maneira mais rápida de ver por quê é acompanhar uma única consulta desde o momento em que você toca em um link.

Esses dois recursos ficam em pontos diferentes da mesma jornada. O DNS privado criptografa a pergunta que você faz a um resolvedor. Uma VPN muda a rota que a conexão da resposta percorre.

Então percorra isso em ordem, em um dispositivo onde os dois estão ativados, e observe o que cada camada ainda consegue ver.

Passo um: a consulta sai do aplicativo

Você toca em um link. Antes que qualquer coisa se conecte, o aplicativo precisa de um endereço para esse nome de host. No Android, a tela relevante é Configurações, Rede e Internet, DNS privado. Escolher Nome do host do provedor de DNS privado coloca o dispositivo no modo estrito: ele faz DNS sobre TLS para esse nome de host na porta 853, e se a troca criptografada falhar, a consulta falha em vez de voltar silenciosamente para texto simples na porta 53.

Essa é uma diferença importante em relação a Automático, que usa criptografia oportunista e usará sem hesitar um resolvedor não criptografado quando a rede interferir. Se o seu objetivo é que as consultas nunca ocorram em texto simples, o modo estrito com um nome de host de provedor é a configuração que corresponde a isso.

Aqui está a primeira coisa que o percurso revela: a consulta está protegida contra a rede local, e o resolvedor ainda assim descobre o nome. A criptografia cobre o salto. O operador desse resolvedor vê a consulta porque responder a ela é o seu trabalho.

Passo dois: a conexão pega outra rota

O resolvedor devolve um endereço e o aplicativo se conecta a ele. Esse passo não é afetado por como a consulta foi criptografada. Sem um túnel, a conexão sai do seu endereço público normal, e o IP de destino e o aperto de mão TLS geralmente tornam o nome de host visível para a rede de qualquer forma, com ou sem DNS criptografado.

Ative a VPN e é este o passo que muda. O tráfego que corresponde à política de roteamento do cliente passa pelo túnel, a rede local vê uma conexão com o endpoint da VPN, e o site geralmente vê o endereço de saída. A resolução de nomes também pode viajar dentro do túnel, dependendo do que o cliente enviar.

Essa separação é toda a comparação em uma frase. A criptografia de DNS responde quem pode ler a pergunta. Uma VPN responde para onde vai a conversa.

Passo três: dentro do túnel, o DNS se torna uma questão de política

Agora os dois recursos interagem, e o navegador é a fonte habitual de surpresas. Um navegador com sua própria configuração de DNS seguro pode enviar consultas ao resolvedor escolhido por HTTPS em vez de perguntar ao sistema operacional. A configuração de DNS privado do Android não alcança essa decisão.

No Firefox, o interruptor fica em Configurações, Privacidade e segurança, Ativar DNS seguro. No Chrome, fica em Configurações, Privacidade e segurança, Usar DNS seguro. Ambos podem ser definidos para um provedor específico ou deixados desativados, e quando estão ativados, a configuração de DNS do túnel é ignorada para essas consultas, mesmo que o tráfego da página ainda use o túnel.

Se a VPN envia o próprio resolvedor e o navegador insiste no dele, você obtém uma divisão: os nomes são resolvidos, as páginas carregam, e as consultas que deveriam passar pelo túnel saíram diretamente. Um endereço de resolvedor diferente do endpoint da VPN não é prova de vazamento por si só, mas um caminho de consulta que contradiz a sua intenção declarada merece ser corrigido.

Passo quatro: os nomes internos são onde quebra

Conecte-se a uma VPN de trabalho e abra um host da intranet. Se o DNS seguro do navegador estiver ativado e apontando para um resolvedor público, esse nome não existe para o navegador. O túnel está de pé, todo o resto funciona, e um nome de host falha com um erro que parece que o site está fora do ar.

A mesma falha aparece ao contrário no Android. O DNS privado estrito com um provedor público não resolverá nomes que só o resolvedor interno conhece, e o modo estrito não tem alternativa. Dividir o DNS de um telefone entre um resolvedor público criptografado e um resolvedor corporativo não é uma configuração; é uma questão de política de roteamento que precisa ser respondida por quem opera a VPN.

Verifique isso antes de culpar o túnel: consulte o nome interno, depois o mesmo nome com o DNS seguro do navegador desativado. Se resolver, a seleção de resolvedor era o problema, não a conexão.

O que o percurso manda você mudar

Quatro telas carregam quase tudo. Olhe para elas nesta ordem e anote o que cada uma diz, porque a resposta geralmente fica visível na combinação:

1. Configurações do Android, Rede e Internet, DNS privado: Automático ou um nome de host de provedor, e qual nome de host.
2. A configuração de DNS seguro do navegador: desativada, ou fixada em um resolvedor específico.
3. A política de DNS do cliente VPN: ele envia um resolvedor, e o túnel dividido exclui algo que ainda precisa de nomes?
4. Um teste de nome de host interno com o túnel de pé, executado duas vezes, uma com o DNS do navegador ativado e outra desativado.

Depois ajuste a correção ao requisito, e não o contrário. Se o requisito é que as consultas saiam criptografadas e vão para um resolvedor que você escolheu, defina o DNS privado estrito e faça o navegador concordar com isso. Se o requisito é que o tráfego saia em outro lugar, configure o túnel e pare de esperar que uma configuração de DNS mova o seu endereço.

E mantenha os limites em vista. Nenhum dos dois recursos torna um destino hostil seguro, e nenhum remove uma identidade com a qual você entrou. A criptografia muda quem pode ler a pergunta; o túnel muda para onde vai a conexão; nada disso anonimiza a conta.