DNSSEC ou VPN: qual esconde as suas consultas DNS?

Dois mecanismos recebem o mesmo trabalho e nenhum dos dois o executa. O DNSSEC responde se os dados que recebeu vieram realmente da zona que os publica, e uma VPN decide que caminho os seus pacotes percorrem. Nenhum deles esconde em todos os casos o nome que perguntou, e as configurações que parecem dever fazê-lo tratam normalmente do transporte ou do encaminhamento e não da validação. Nomear a camada primeiro transforma uma pergunta vaga sobre privacidade numa pergunta concreta.

Três afirmações fundidas numa

A autenticidade é a afirmação de que a resposta é a que a zona publicou e não foi alterada no caminho. A confidencialidade é a afirmação de que ninguém no caminho pode ler a consulta nem a resposta. O encaminhamento é a afirmação de que os pacotes seguem um caminho que escolheu, que é exatamente o que um túnel oferece.

O DNSSEC trata da primeira e não diz nada sobre as outras duas. O DoT e o DoH tratam da segunda para o salto até o resolver. Uma VPN trata da terceira e pode também afetar a segunda, mas apenas como efeito colateral de para onde vai o tráfego.

O tráfego de aplicações é um quarto caso: o HTTPS protege e autentica a troca web entre o seu cliente e o site, e nenhuma camada DNS o substitui.

O que a validação de assinaturas pode e não pode fazer

Um resolver que valida verifica a cadeia de assinaturas desde a zona até uma âncora de confiança configurada e devolve depois uma resposta com o indicador de dados autenticados ativo quando a verificação tem sucesso. Esse indicador é uma prova sobre os dados, não sobre a ligação nem sobre as intenções do destino.

Não pode impedir um proprietário legítimo de uma zona de publicar registos autênticos para um serviço em que não deveria confiar. Uma resposta corretamente assinada de um domínio comprometido continua corretamente assinada, e o DNSSEC não tem opinião sobre se esse domínio merece as suas credenciais.

Também não esconde nada. A consulta e a resposta atravessam a rede numa forma que um resolver e qualquer observador desse caminho podem ler, a menos que outra camada proteja o transporte. Uma resposta assinada e uma resposta privada são propriedades diferentes, e uma implementação pode ter apenas uma delas. Teste ambas se alguma lhe importa.

De onde vem realmente a confidencialidade

O transporte cifrado até ao resolver envolve a troca DNS em TLS, pelo que o resolver continua a ver a pergunta mas o caminho entre si e ele não. Isso desloca a confiança em vez de a eliminar: confia mais no resolver e menos na rede local.

Uma VPN pode levar as consultas a um resolver do outro lado, o que muda tanto o caminho como o resolver que as vê. É uma decisão de encaminhamento com uma consequência para a privacidade, e numa rede gerida o resolver interno pode ser o único que consegue responder a nomes internos.

A combinação que as pessoas querem de facto costuma ser três coisas ao mesmo tempo: validação ativa, transporte cifrado até um resolver que escolheram e TLS da aplicação no destino. Cada uma é independente, e saltar uma deixa uma lacuna diferente.

Verifique a validação e o transporte separadamente

Dois testes resolvem a maior parte da confusão. O primeiro pergunta se o resolver validou a resposta; o segundo pergunta se o transporte estava protegido. Falham de formas diferentes e nenhum implica o outro.

Estes comandos imprimem os indicadores de uma consulta que valida, repetem a consulta com a verificação desativada e executam a validação local com delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Uma resposta com o indicador de dados autenticados e uma assinatura presente mostra validação nesse resolver. Uma falha de validação com delv mostra uma cadeia quebrada algures entre a zona e a âncora de confiança, que é um problema de publicação e não um problema de túnel. Um tempo limite sem qualquer indicador é um problema de transporte ou de alcance, e tratá-lo como uma falha de assinatura leva-o à camada errada.

O que fazer quando uma VPN quebra as consultas

Se as consultas funcionavam antes do túnel e param depois, compare o resolver que cada caminho usa. O túnel dividido, um resolver interno apenas acessível através do túnel e um cliente que reescreve as configurações do resolver alteram todos a resposta sem tocar no DNSSEC.

Desativar a validação globalmente é o primeiro passo errado, porque elimina o único mecanismo que reporta manipulação e não corrige um resolver inalcançável. Restrinja primeiro a falha: resolução, transporte, validação e depois política. Só a terceira pertence ao DNSSEC, e só a segunda pertence ao transporte cifrado.