Resumo

  • Em 1º de setembro de 2026, os chairs do DNSOP registraram apoio claro à adoção de draft-huque-dnsop-multi-alg-rules-08, mas preservaram para o trabalho futuro as preocupações sobre a complexidade.
  • A proposta cria estados UNIVERSAL e FORMERLY-UNIVERSAL que, em certas combinações, permitiriam ao signatário omitir assinaturas de algoritmos anunciados.
  • Os estados também mudariam a resposta de um validador que desativou localmente um algoritmo; não são apenas metadados explicativos.
  • Daniel Kade propõe um recibo de evidência de implantação separado para cada futura classificação. Adoção escolhe um trabalho; Standards Action autorizaria a mudança do registro.

O resultado não eliminou a ressalva

A mensagem de encerramento diz que houve apoio claro à adoção. Logo depois, diz que as preocupações com a complexidade do mecanismo devem ser tratadas no trabalho posterior do grupo. O alcance institucional está nas duas frases, não apenas na primeira.

A chamada começou em 13 de agosto e terminou no dia 31. O Datatracker atual classifica o Internet-Draft como ativo e Adopted by a WG. No lado do IESG, permanece I-D Exists, sem shepherd, Area Director responsável ou data de telechat. A revisão 08 passou à custódia de mudança do DNSOP. Não virou RFC, Standards Action ou regra implantada.

Adoção é a decisão de trabalhar um texto dentro do grupo. O objetivo é poder alterá-lo. Tratar o estado como aprovação integral inverteria a função dessa etapa, especialmente quando os próprios chairs nomearam o que ainda precisa ser resolvido.

A regra atual troca custo por previsibilidade

O RFC 4035 exige uma RRSIG, para cada RRset, feita por ao menos uma DNSKEY de cada algoritmo presente no conjunto DNSKEY do ápice. Esse conjunto também deve ser assinado por cada algoritmo anunciado no DS do pai. O RFC 6840 reafirma a completude exigida do signatário, enquanto manda o validador aceitar qualquer caminho válido.

O signatário não sabe quais algoritmos cada validador entende. Servir o conjunto anunciado reduz a possibilidade de que uma assinatura compatível removida pareça uma omissão normal. Mas a obrigação acopla fornecedores. O RFC 8901 requer um algoritmo comum entre participantes de um modelo multi-signer. Dois provedores com conjuntos disjuntos não conseguem formar a transição apenas publicando suas próprias chaves.

A revisão 08 procura aliviar essa restrição. Cobre multi-signer permanente, troca de provedor, mudanças separadas de KSK e ZSK, pré-publicação de trust anchor e teste de algoritmo novo por um provedor sem sincronizar todos os demais. O DNSOP aceitou que esses casos merecem trabalho coletivo. A forma final continua em aberto.

O estado no registro executaria uma política

O draft propõe uma coluna IANA chamada Validation support status, com UNIVERSAL, FORMERLY-UNIVERSAL ou vazio. Algoritmos 8 e 13 seriam inicialmente UNIVERSAL. O registro IANA de algoritmos DNSSEC ainda não tem essa coluna; ele registra 8 e 13 como MUST para implementação de validação.

Na proposta, quando o conjunto de DS ou trust anchors contém ao menos um UNIVERSAL e nenhum FORMERLY-UNIVERSAL, o signatário precisa servir apenas uma assinatura de algoritmo universal. As demais assinaturas anunciadas se tornam opcionais. Fora dessa condição, todos os algoritmos continuam obrigatórios.

O validador também recebe uma nova bifurcação. Se não suporta um algoritmo anunciado que seja ou tenha sido UNIVERSAL, deve tratar a zona como não assinada, mesmo quando suporta outro algoritmo anunciado. Nos demais casos, aceita qualquer caminho válido. Quando desativa um algoritmo por política local, precisa conservar a memória de seu antigo estado.

Logo, UNIVERSAL não seria uma medalha. Determinaria o que pode faltar na resposta e se uma incompatibilidade produz Insecure ou Bogus. Uma classificação precoce ou envelhecida entraria diretamente no comportamento de disponibilidade e segurança.

O RFC 9904 já separa orientações de uso e requisitos de implementação e tornou o registro IANA a fonte canônica para ambos. Ele prevê mudança ao longo do tempo e retirada gradual. A nova classificação tem outra função. A proximidade entre colunas não substitui a evidência específica de cada uma.

A discussão adotada inclui objeções

As respostas públicas dão conteúdo à ressalva dos chairs. Mark Andrews se opôs ao draft e contestou sua premissa sobre o suporte dos validadores. Paul Hoffman apoiou relaxar a regra antiga, mas rejeitou o desenho atual dos estados. Paul Wouters apoiou a adoção e pediu simplificação substancial.

São intervenções individuais, não votos que esta reportagem possa recontar como consenso. Elas mostram apenas onde está a complexidade preservada pelo encerramento: generalização, ciclo de vida, validadores antigos, preferência local e futuras assinaturas pós-quânticas.

O draft reconhece o limite central. O protocolo não consegue determinar sozinho o que tem suporte universal. A comunidade deveria promover um algoritmo apenas quando a população sem suporte for considerada desprezível. Essa conclusão global exige uma base observável: população, amostra, data e regra de decisão.

Um recibo para cada mudança de classificação

Uma futura Standards Action deveria anexar ao estado um recibo curto. Ele identificaria algoritmo, versão do registro, data da medição, coorte de validadores observada, exclusões conhecidas, implementações antigas e o limiar usado para chamar o não suporte de desprezível.

O recibo também mostraria os resultados Secure, Insecure e Bogus esperados em estados representativos de multi-signer e troca de provedor; o contato com preferências locais; dependências entre signatários; janela de vigência; e responsável por transição ou reversão emergencial. Identidades de resolvedores e dados comerciais podem permanecer protegidos. O alcance de uma afirmação de interoperabilidade não pode ficar secreto.

A camada comum mínima de Heng Lu oferece o critério. Só deve virar classificação compartilhada aquilo que operadores independentes precisam compartilhar para interoperar. Preferir um algoritmo entre opções aceitáveis permanece decisão local, salvo se um processo normativo posterior mudar essa fronteira de forma expressa e justificável.

O DNSOP adotou a responsabilidade de resolver o problema. A taxonomia ainda precisa conquistar sua autoridade por texto, evidência e etapas posteriores. Separar o recibo de adoção do recibo de classificação impede que uma decisão sobre edição seja tratada como decisão sobre a rede.

Fontes