Resumo

  • draft-kaizer-dnsop-ml-dsa-mtl-dnssec-02 permite que muitos RRsets compartilhem uma assinatura ML-DSA sobre uma Merkle ladder, usando provas de inclusão por mensagem.
  • A prova cabe numa única resposta lógica, mas não certifica que o estado do signer sobreviveu a atualização, réplica, transferência de zona ou desastre; o draft deixa essas regras para trabalho futuro.

A revisão 02 foi publicada em 28 de setembro de 2026. Ela passou a declarar intenção Standards Track e propôs um registro IANA para MTL Types. Continua sendo Internet-Draft individual, não adoção do DNSOP, consenso do IETF ou RFC. O número de algoritmo permanece TBD. As implementações citadas em LDNS, NSD, Unbound e numa biblioteca C são para teste; o próprio documento diz que a lista é fornecida por contribuidores, não verificada e sem endosso do IETF.

O problema de tamanho é concreto. ML-DSA, padronizado pelo NIST, oferece assinatura pós-quântica, mas suas assinaturas completas são grandes para DNSSEC. Repetir uma em cada RRset aumenta zona, memória de cache e resposta. Merkle Tree Ladders compartilham a operação cara.

O DNSKEY carrega a chave pública ML-DSA. Para cada mensagem, o signer escolhe um randomizer, calcula uma folha e atribui o próximo índice a partir de zero. As folhas entram num node set evolutivo identificado por um SID de 32 octetos. Um conjunto de rungs autentica as folhas existentes. ML-DSA assina a ladder formada por flags, SID, contagem e dados dos rungs.

Uma RRSIG completa leva o índice, randomizer, sibling hashes e a ladder assinada. O resolver verifica a assinatura da ladder, recalcula a folha a partir do RRset e percorre o authentication path até um rung compatível. Depois ainda executa a validação DNSSEC comum. O ganho é claro: uma assinatura cheia pode autenticar numerosos RRsets.

Mas o ganho depende de uma sequência. SID define a série. Índice define a posição. Randomizer participa do hash. Rungs mudam à medida que folhas são anexadas. Uma mensagem antiga pode precisar de um caminho novo relativo à ladder atual. A estrutura comprimida carrega memória operacional.

Por isso restaurar apenas a chave não fecha a recuperação. O operador precisa saber qual SID pertence a qual papel, qual foi o último índice aceito, qual ladder foi promovida e quais dados permitem recomputar caminhos. O draft proíbe o mesmo SID em instâncias MTL diferentes e cita KSK e ZSK como separação obrigatória. Um snapshot antigo pode ter material criptográfico válido e ainda assim representar uma geração errada.

A revisão atual não afirma que o estado seja irrecuperável. Uma implementação pode replicá-lo, reconstruí-lo com material suficiente ou iniciar uma nova série. Ela apenas não padroniza o caminho. O texto concentra-se em DNSKEY, RRSIG e operações criptográficas, deixando zone signing, composition, updates, transfer, nameserver, resolver e caching para versões ou documentos posteriores.

Essa lacuna muda o significado de disaster recovery. Um exercício não deve terminar quando o processo abre a chave e assina alguma coisa. Deve demonstrar que o signer restaurado não reutiliza SID ou índice de modo ambíguo, não promove ladder mais velha sem detecção e consegue continuar a série aceita — ou iniciar outra por transição explícita.

Batch signing combina economia e frescor. Vários RRsets entram no node set antes de uma nova ladder ser assinada, reduzindo o custo médio e talvez a carga do HSM. Enquanto o lote espera, a alteração recente ainda não dispõe daquela prova. O tamanho correto depende da zona, mas precisa de um SLO: atraso máximo, regra de promoção e resposta a divergência entre signers.

Online signing não elimina o cálculo. O draft menciona um node set novo para cada resposta dinâmica. Isso pode limitar o estado compartilhado, porém também restringe a amortização aos dados da consulta. Desempenho, latência e recuperação precisam ser medidos no desenho escolhido.

No wire, a revisão 01 retirou a opção EDNS(0) da versão inicial e adotou somente a resposta MTL completa para cada RRset. A revisão 02 declara que ela sempre excede DNS sobre UDP, prevê mais TCP e recomenda TCP desde o início quando o cliente quer evitar truncamento seguido de retry.

TCP transporta a resposta; não escolhe a história correta. Uma conexão bem-sucedida não prova coerência entre autoritativos. Uma ladder válida não prova suporte do algoritmo no resolver. A Merkle proof não substitui a cadeia DS/DNSKEY até o trust anchor. E DNSSEC válido não é recibo de disponibilidade da aplicação.

O artigo anterior sobre SigTag permanece separado. Ele analisou a alegação do cliente de possuir ladders em cache, a escolha full/condensed, privacidade e fallback. Esta pauta vem antes: como o signer cria e preserva a ladder que um cliente futuramente tentaria reutilizar.

Running-code primacy exige que o rótulo Standards Track, o pedido de code point e o código de teste sejam tratados como etapas, não como implantação. A adoção começa quando implementações independentes atravessam update, transferência, separação KSK/ZSK, rollback, failover e carga TCP com resultados reproduzíveis.

Um ladder receipt deve registrar role, SID, intervalo de índices, rungs, SOA serial, signer, versão, horário e predecessor. O teste decisivo restaura deliberadamente uma cópia defasada e mostra como a divergência é bloqueada. Validar uma resposta antiga prova a resposta antiga; não prova a continuidade do serviço de assinatura.

Fontes