O problema das chaves DNS: quando a criptografia depende da rede

Você já comprou uma fechadura de alta segurança e depois percebeu que não tinha como pegar a chave? É exatamente assim que milhões de usuários estão vivendo a internet hoje.

Protocolos como DNS-over-HTTPS e DNS-over-TLS nasceram para proteger as consultas de domínio. Eles escondem o que você está acessando, impedindo que provedores e censores vejam os endereços que você digita.

Só que a criptografia não vale de nada se você não consegue nem começar o processo.

Bloquear a chave em vez de quebrar a fechadura

Os censores perceberam que não precisam decifrar o tráfego. Basta impedir que o usuário consiga as informações necessárias para criptografar.

Em 2021, usuários na China relataram algo estranho: as conexões criptografadas funcionavam por alguns segundos, depois falhavam, voltavam e caíam de novo. Nada estava quebrado de forma permanente. Era um bloqueio temporário e seletivo, repetido o suficiente para tornar o serviço inutilizável.

Essa tática revelou três camadas de controle:

• DNS comum: continua sendo adulterado com IPs falsos
• DNS-over-TLS (porta 853): simplesmente rejeitado na conexão
• DNS-over-HTTPS (porta 443): bloqueado por curtos períodos toda vez que uma consulta é detectada

O resultado prático é o mesmo: o usuário desiste.

A falha de origem

O problema está na arquitetura. Protocolos mais novos, como Encrypted Client Hello, precisam buscar chaves públicas no DNS antes mesmo de iniciar a conexão criptografada. Se o DNS pode ser interceptado, a criptografia nunca chega a acontecer.

É um ciclo vicioso: para usar DNS criptografado, você precisa fazer uma consulta DNS. Mas essa consulta pode ser bloqueada antes de ser protegida.

O que isso muda para quem publica sites

Se você administra domínios ou infraestrutura, três suposições comuns não se sustentam mais:

• Seus registros DNS estarão sempre disponíveis em qualquer lugar
• Criptografia resolve o problema de visibilidade
• Bloqueios precisam ser totais para funcionar

Na prática, regiões diferentes podem ter dificuldade para resolver seus domínios. E ataques que só criam atrito já são suficientes para afastar usuários.

O que está sendo testado agora

Nenhuma solução é definitiva, mas algumas abordagens estão ganhando espaço:

• Distribuição descentralizada de chaves, usando DNSSEC ou sistemas baseados em blockchain
• Ofuscação de tráfego para esconder padrões de consulta
• Redes anycast bem distribuídas geograficamente
• Inclusão de chaves diretamente na aplicação, reduzindo a dependência do DNS

Todas exigem algum compromisso entre desempenho, complexidade e facilidade de uso.

O que realmente importa

Sistemas de privacidade não existem isolados. Eles dependem da rede física, de políticas regionais e de quem controla os cabos.

Quando você projeta qualquer serviço — seja um domínio, uma API ou uma aplicação —, vale perguntar: o que acontece se alguém com controle de rede quiser impedir o acesso? E qual é o plano B?

O problema de distribuição de chaves DNS ainda não tem resposta definitiva. As soluções que estão surgindo tendem a ser mais distribuídas, mais complexas e exigem mais atenção do usuário. É o preço de construir privacidade em um ambiente onde ela é constantemente contestada.