Resumo

  • A revisão 00 cria uma opção EDNS(0) para anunciar até oito SigTags de ladders assinadas conhecidas e permitir respostas MTL condensadas.
  • O hash de 32 octetos identifica uma ladder; não comprova que o cliente ainda a possui, a vinculou ao signatário correto ou concluiu DNSSEC.
  • A operação responsável exige recuperação por assinatura completa, evidência por etapa e decisão consciente sobre privacidade e retenção de cache.

A assinatura grande ganhou um endereço no cache

No desenho ML-DSA-MTL, uma assinatura completa combina o caminho Merkle condensado com uma signed ladder que contém a assinatura ML-DSA subjacente. A mesma ladder pode cobrir vários RRsets. Isso distribui custo, mas o draft-base informa que a resposta completa excede DNS sobre UDP.

SigTag transforma a ladder serializada em SHAKE128(SIGNED_LADDER, 256). O resolvedor envia valores conhecidos em EDNS(0), até oito. Havendo correspondência e posse no servidor, o RRSIG pode vir como condensed 0x02. Sem correspondência — ou se o servidor já descartou a ladder — a resposta deve conter a assinatura completa.

Nada disso autentica por atalho. O resolvedor busca a ladder correta, valida sua assinatura com a DNSKEY aplicável, confere o caminho de inclusão e segue com a cadeia DNSSEC. O servidor recebeu uma afirmação sobre estado do cliente, não uma prova de posse nem autorização para marcar a resposta como segura.

SID não é identidade global

O draft-base alerta que outro signatário pode usar o mesmo SID. Por isso, a ladder em cache precisa estar associada ao nome do signatário. Um índice apenas por SID ou SigTag pode encontrar bytes coerentes no contexto de autoridade errado.

Há também diferença entre tempo de consulta e de resposta. A entrada pode ser removida depois que o pacote foi montado; uma rotação de chave pode alterar o contexto; a cópia do servidor pode desaparecer. O caminho condensado recebido ainda precisa combinar com o objeto efetivamente carregado. Um único contador de cache hit apagaria essas fronteiras.

O cliente sem tag conhecido pode mandar a opção vazia. O eco vazio do servidor demonstra suporte e possibilita deduplicação entre vários RRSIGs da mesma resposta. Não demonstra validação, e o cliente deve ignorar dados que apareçam na opção de resposta.

Recuperar a prova inteira é requisito de continuidade

Uma resposta inválida pode ser repetida com SigTag vazio, sem SigTag para exigir full signatures ou contra outro servidor. Assinatura condensada incompatível e payload ausente aparecem como exemplos. Esses caminhos definem se uma falha de cache será transparente ou virará indisponibilidade.

Escolher TCP desde o início pode evitar truncation e repetição, mas não entrega um recibo de uso. Meça separadamente bytes, UDP, TCP, latência, retry, troca de upstream, validação DNSSEC e resultado da aplicação.

Eficiência revela memória de consulta

Um SigTag não vazio informa à autoridade que o cliente viu determinada ladder. O draft reconhece que isso pode revelar consultas anteriores ou permitir tracking se ladders forem individualizadas. Enviar apenas a opção vazia mantém a deduplicação dentro da resposta sem expor tags; limpar o cache ao trocar endereço ou interface reduz persistência.

Essas medidas trocam eficiência por privacidade. A decisão deve ficar com o operador do resolvedor. Nem a autoridade ganha poder de perfilamento, nem o fornecedor deveria transformar divulgação histórica em padrão invisível.

Evidência de execução começa depois do draft

A revisão 00 é de 28 de setembro de 2026 e mantém como TBD os valores de registro. LDNS, NSD e Unbound são citados como implementações de teste, mas a seção declara que as informações vieram de contribuidores, não foram verificadas e não representam endosso do IETF.

Registro torna números legíveis. Código torna uma ideia executável. Só testes com versões, traces, validação, rollovers e distribuição de falhas demonstram comportamento operacional.

Fontes