Resumo

  • Desde 10 de setembro de 2026, o resolvedor 1.1.1.1 da Cloudflare validava ML-DSA-44 para zonas de teste. Em RIPE 93, Joe Abley apresentou um desafio DNSSEC medido pelo navegador.
  • Entre resolvedores validadores, a dupla assinatura contra o controle clássico mostrou +1 ms na mediana e +1.405 ms no p99. Os slides chamam o resultado agregado de net breakage de 6,0%; o teste inicial e ruidoso não mediu uma taxa de falha para toda a população.

A mediana tranquiliza; a cauda chama o plantão

Um milissegundo a mais na mediana é o número que uma apresentação de upgrade colocaria em destaque. Joe Abley levou a RIPE 93 a linha menos confortável: no p99, o caminho com duas assinaturas ficou 1.405 milissegundos mais lento que o controle clássico. É a ponta da distribuição em que alguns usuários esperam enquanto a maioria rápida deixa a média com boa aparência.

O gráfico dos slides originais da RIPE 93 compara o tempo decorrido da dupla assinatura menos o controle de algoritmo 13 em resolvedores validadores. As diferenças foram +1 ms na mediana, +147 ms no p90, +618 ms no p95 e +1.405 ms no p99. São tempos do desafio no navegador, não um cronômetro exclusivo da verificação criptográfica. Abley também exibiu um parâmetro não validador — assinatura clássica 13 deliberadamente quebrada contra o controle — com diferenças de 0, +73, +215 e +1.132 ms nesses percentis.

O teste somou cerca de 140 mil pontos de dados, após o desafio ser mostrado a um em cada mil usuários. Cada execução disparava quatro requisições HTTPS paralelas para nomes DNS servidos pela Cloudflare: controle com algoritmo 13, assinatura 13 quebrada de propósito, caminho ML-DSA-44 com algoritmo 18 e nome assinado com ambos. O slide 19 chama o resultado agregado dos resolvedores validadores de “net breakage” de 6,0%. Abley relatou aumento significativo de falhas em cerca de 20 sistemas autônomos; na maioria dos AS observados não houve diferença. A apresentação não atribui uma causa a cada falha.

A assinatura nova pode fechar a saída antiga

O teste foi possível porque o 1.1.1.1 passou a validar ML-DSA-44 para todos os clientes em 10 de setembro, usando zonas de teste. Isso era capacidade de validação, não lançamento de assinatura pós-quântica para clientes. O registro da IANA lista o algoritmo 18 como ML-DSA-44 e marca MAY para assinatura e validação. O algoritmo 13, ECDSA P-256 com SHA-256, aparece como RECOMMENDED.

No DNSSEC habitual, um resolvedor pode aceitar um conjunto de registros se qualquer RRSIG que o cobre for válida. A RFC 6840 diz que o resolvedor deve aceitar qualquer assinatura válida e só marcar o conjunto como bogus se todas falharem; a RFC 4035 entrega o tratamento de conflitos à política de segurança local. A regra pós-quântica mais rígida da Cloudflare fecha essa saída: quando há uma assinatura de algoritmo 18, ela precisa validar. Uma assinatura 13 válida não compensa uma ML-DSA-44 quebrada. A intenção é impedir que uma atualização quântica vire um rebaixamento silencioso para a assinatura clássica.

Essa proteção faz da assinatura nova uma condição de disponibilidade. Se estiver malformada, uma resposta que a assinatura clássica autenticaria pode ser recusada. A escolha é da política local do resolvedor; o protocolo DNSSEC básico não mudou.

O navegador não era uma sala limpa

Abley chamou os resultados de muito iniciais e ruidosos. O teste reutilizou os mesmos nomes DNS, então o cache podia contaminar a comparação; o teste não neutralizou o cache. Redirecionamentos HTTPS acrescentaram tempo. Quem completava o desafio rapidamente podia sair antes do fim da medição, e o limite de dois segundos cortava requisições lentas. A rede doméstica e o navegador também variavam. Os slides registram uma pista para investigar, não uma causa comprovada para cada falha.

A decisão de implantação continuava em aberto. A Cloudflare ainda experimentava assinatura on-line ML-DSA-44 e não havia anunciado quando a ofereceria a clientes. Requisitos de conformidade poderiam criar demanda por adesão voluntária; dupla assinatura por padrão exigiria grande confiança de que o serviço não seria quebrado. O Internet-Draft individual de Joe Abley propõe um sinal Extended DNS Error para que o cliente reconheça a política local rígida do resolvedor, em vez de receber uma resposta negativa sem explicação.

Uma repetição aleatória, com nomes que evitem cache e rastros no resolvedor, mudaria a decisão de implantação: separaria falhas de validação DNS de redirecionamentos, saídas do navegador e timeouts. Por enquanto, a forma do resultado já impõe uma pergunta: o meio ficou quase plano, a cauda disparou e a política manda que a assinatura pós-quântica conte.

Fontes