Resumo

  • Uma zona assinada hostil podia multiplicar chaves com o mesmo key tag e assinaturas candidatas, impondo ao resolvedor um produto de tentativas criptográficas.
  • Os reparos mantiveram o DNSSEC, mas permitiram encerrar a validação patológica, preservar outras consultas e registrar quando o limite local fosse atingido.

O remetente escolhia o trabalho do destinatário

Várias DNSKEY e RRSIG são legítimas em trocas de chave, migrações de algoritmo e ambientes com múltiplos signatários. O key tag de 16 bits ajuda a selecionar uma chave, mas não é exclusivo. Colisões são possíveis.

O KeyTrap organizava essa flexibilidade contra o resolvedor. Uma zona sob controle do atacante oferecia muitas chaves com o mesmo tag e assinaturas que não validavam. Antes de chegar à resposta negativa, o software diligente experimentava combinações sucessivas. O custo de rede permanecia pequeno; a conta em operações de chave pública ficava do outro lado.

Nenhuma assinatura era forjada. A zona não recebia autoridade sobre outro nome, a raiz não era quebrada e dados falsos não se tornavam Secure. Era um ataque à disponibilidade. Desligar a validação eliminaria a carga, mas também a autenticação que o resolvedor deveria entregar.

Pesquisadores do ATHENE iniciaram a coordenação com fornecedores e grandes operadores em novembro de 2023. A divulgação pública ocorreu em 13 de fevereiro de 2024. Experimentos observaram travamentos de cerca de um minuto a horas em implementações e configurações testadas. Esses números não são uma duração universal de indisponibilidade.

Corrigir significou aprender a parar

O ISC classificou CVE-2023-50387 como High e remotamente explorável nas linhas avaliadas do BIND 9. Recomendou versões corrigidas e informou que não conhecia exploração ativa na data da publicação.

O Unbound 1.19.1 passou a suspender validações depois de tentativas limitadas. A tarefa cara devolve CPU, outros pedidos progridem e, após retomadas também limitadas, a consulta hostil termina em erro. A proteção está na criptografia e no escalonamento.

A Cloudflare definiu limites por RRset e por tarefa completa, acrescentou métricas e erro de excesso. Segundo sua cronologia, o 1.1.1.1 estava corrigido contra KeyTrap em 8 de dezembro de 2023; o resolvedor interno do CDN completou as correções contra KeyTrap e o problema NSEC3 relacionado em 13 de fevereiro de 2024.

As implementações não precisam usar o mesmo número. Compartilham uma regra: publicar material assinado não concede direito ilimitado à CPU, à fila e ao tempo de resposta de quem valida.

Interoperabilidade sem esforço infinito

Os RFCs 4034 e 4035 definem objetos e comportamento de validação. Esse núcleo comum tornou o DNSSEC interoperável. Porém, um procedimento que chega à conclusão correta ainda é inseguro quando o adversário controla o tamanho da busca e o sistema para antes de concluir.

Um Internet-Draft de 2026 sobre valores máximos no DNS registra a ausência de limites explícitos para DNSKEY, DS e RRSIG ligados a esse custo. É sinal de trabalho em curso, não um padrão aprovado.

Por isso, o processo de padronização do IETF é o foco institucional duradouro deste caso. A pergunta já não é apenas qual fornecedor corrigiu primeiro, mas quais limites devem integrar o contrato comum do protocolo e quais precisam continuar locais a cada implementação. Um rascunho individual não representa consenso do IETF; operadores não podem trocar limites implantados por um trabalho ainda em andamento.

Os princípios de Heng Lu separam as funções. A especificação inicial mínima preserva a linguagem criptográfica comum. A decisão futura localizada devolve a cada resolvedor o orçamento de recursos. A adoção voluntária permite que diferentes códigos demonstrem limites operacionais sem transformar o escalonador de um fornecedor em lei universal.

Evidência de correção na frota

O inventário precisa conter implementação, versão exata, origem do pacote, prova do patch e data de implantação. “DNSSEC habilitado” não informa se o caminho de custo explosivo permanece.

Métricas devem separar tentativas de assinatura, tempo de validação, atraso de fila, atendimento pelo cache e erros de limite. Fixtures maliciosas devem ficar isoladas, enquanto o teste confirma que consultas normais com e sem cache continuam.

Se uma emergência exigir desabilitar DNSSEC, a exceção precisa de proprietário, escopo mínimo, vencimento e comprovação de retorno. Caso contrário, uma escolha temporária de disponibilidade vira redução permanente de confiança.

Limites da evidência

As fontes não comprovam exploração global, pane mundial nem proporção completa de resolvedores vulneráveis. O lançamento do fornecedor não prova atualização simultânea de distribuições e frotas privadas. As medições do ATHENE não descrevem toda configuração, e superlativos não substituem comparação.

O achado defensável é preciso: uma afirmação assinada pode impor custo assimétrico. A parte que confia deve governar tanto o veredito quanto o preço para alcançá-lo.

Fontes