Apenas um pacote ruim pode derrubar um servidor DNS vulnerável graças ao DNSSEC
Uma falha recém-divulgada chamada “KeyTrap” no padrão DNSSEC permite que um único pacote elaborado esgote a CPU de resolvedores que validam DNSSEC, potencialmente derrubando grandes softwares de DNS até que sejam corrigidos. Comentadores argumentam que isso expõe problemas mais profundos no projeto do DNSSEC — alta complexidade operacional, riscos de auto-DoS, benefícios limitados no mundo real dado o baixo índice de assinatura, e dependência de intermediários para o gerenciamento de chaves — especialmente quando HTTPS, DoH/DoT e CT já tratam da maior parte da segurança visível ao usuário. Outros contra-argumentam que o DNSSEC ainda importa para detectar adulteração entre resolvedores e servidores autoritativos e sustenta mecanismos como DANE, mas admitem que a implantação continua desigual e frequentemente frágil.
Escopo da vulnerabilidade
- O ataque afeta apenas resolvedores recursivos que validam DNSSEC, não servidores autoritativos comuns.
- O exploit (“KeyTrap”) abusa de uma decisão de projeto do DNSSEC com mais de 20 anos: validadores podem gastar tempo ilimitado rastreando e verificando múltiplas chaves/assinaturas inválidas.
- Todos os principais validadores (BIND, Unbound, dnsmasq, PowerDNS, etc.) foram afetados porque seguiram a especificação.
- Os patches, em sua maioria, adicionam limites ao trabalho/tempo de validação; tecnicamente, isso torna as implementações não conformes com a especificação, destacando uma falha na especificação e não um bug clássico de memória.
O projeto do DNSSEC e seus problemas operacionais
- O DNSSEC foi projetado nos anos 1990 em torno de assinatura offline devido ao custo assumido da criptografia; alguns argumentam que essa escolha arquitetural foi um “pecado original”.
- A rotação e a expiração de chaves são descritas como um grande obstáculo à adoção: fácil causar auto-DoS, difícil automatizar; CDS/CDNSKEY ajudam, mas têm pouco suporte.
- Má configurações e zonas quebradas levam a falhas opacas (“a Internet está quebrada”), fazendo com que operadores desativem a validação na prática.
- Alguns chamam o DNSSEC de “armadilha”, “taxa de infraestrutura”, e sugerem tratar o DNSSEC em si como uma responsabilidade de alta severidade.
Valor de segurança vs. WebPKI / DoH
- Lado pró-DNSSEC:
- Fornece detecção de adulteração entre o resolvedor e os servidores autoritativos; é a única forma de “confiar no conteúdo de uma zona”.
- Permite protocolos como DANE e verificação SSHFP/PGPKEY baseada em DNS.
- Lado cético:
- DNSSEC não oferece privacidade nem criptografia; DoH/DoT/ODoH protegem o último trecho de forma mais eficaz e são mais fáceis de implantar.
- Para a Web, TLS + CA + Certificate Transparency já tratam da integridade; respostas DNS incorretas geralmente viram DoS, não comprometimento silencioso.
- Existem ataques de downgrade/remoção do DNSSEC; a validação ocorre principalmente em resolvedores recursivos, não nos clientes finais.
Adoção e uso no mundo real
- Diz-se que a assinatura DNSSEC global de grandes TLDs (.com, .net) é muito baixa (cerca de alguns por cento), enquanto alguns ccTLDs (.nl, .se, .ch) são muito mais altos.
- As taxas de validação medidas em resolvedores são relatadas em ~30–40% globalmente, mas críticos observam que isso não equivale a segurança de ponta a ponta para o cliente.
- Há debate sobre se o DNSSEC gerenciado por registrador para muitos domínios conta como adoção “significativa”.
Alternativas e direções futuras
- Alguns promovem DNSCurve ou DNSCrypt como projetos melhores com segurança de transporte adequada, mas reconhecem que o DoH praticamente “venceu” esse nicho.
- Vários argumentam que o DNSSEC dificilmente substituirá o WebPKI; experimentos com DANE em navegadores foram testados e removidos.
- Há interesse em implementações de DNS mais seguras em memória (por exemplo, resolvedores baseados em Rust), mas vários comentaristas enfatizam que este problema específico é de projeto de protocolo, não de segurança de memória.