Summary

  • O primeiro rascunho do grupo DNSOP propõe que, havendo algoritmo UNIVERSAL no conjunto DS ou nas âncoras de confiança e nenhum FORMERLY-UNIVERSAL, a zona assine com pelo menos um UNIVERSAL; as demais assinaturas seriam opcionais.
  • Algoritmos 8 e 13 receberiam inicialmente a nova classificação. O registro atual da IANA já exige implementação de ambos para validação, mas ainda não contém a coluna proposta.
  • Um resolvedor que desative localmente um UNIVERSAL anunciado trataria a zona como não assinada, mesmo que suporte outro algoritmo anunciado. A escolha local passaria a aparecer como perda de autenticação.

O assinador de uma zona DNS trabalha mais que o resolvedor. Pelas regras de RFC 4035 e RFC 6840, ele produz assinaturas para todos os algoritmos sinalizados; o validador aceita um único caminho válido. A diferença protege contra resolvedores de capacidade desconhecida. Também impõe assinaturas redundantes a quem publica cada resposta. Um novo texto do DNSOP tenta diminuir o custo quando há um algoritmo que todos os validadores deveriam entender.

Para uma zona servida por dois provedores, o custo é organizacional. No modelo de chaves independentes da RFC 8901, cada empresa assina com seu material. Se os algoritmos forem distintos, a regra atual pode obrigá-las a coordenar assinaturas que nenhuma produziria isoladamente. Trocar de provedor cria um intervalo semelhante. Na preparação de uma nova âncora de confiança, a obrigação de assinar tudo antes da publicação retira a liberdade de separar anúncio e execução.

O selo UNIVERSAL não é prêmio de popularidade

O rascunho pede uma coluna chamada Validation support status no registro de algoritmos da IANA. Os valores seriam UNIVERSAL, FORMERLY-UNIVERSAL ou vazio. No começo, o algoritmo 8, RSA/SHA-256, e o 13, ECDSA P-256/SHA-256, seriam UNIVERSAL. A tabela vigente já os marca como implementação obrigatória para validação. Nenhum algoritmo começaria na categoria de ex-universal. A nova coluna converteria uma expectativa de suporte em autorização concreta para o assinador omitir trabalho.

A condição é precisa. Se os DS do pai ou as âncoras da zona tiverem ao menos um UNIVERSAL e nenhum FORMERLY-UNIVERSAL, o assinador deve usar um UNIVERSAL; as demais assinaturas são facultativas. Pode também publicar DNSKEY apenas para os algoritmos efetivamente usados. Sem UNIVERSAL, ou com qualquer FORMERLY-UNIVERSAL, permanece a assinatura com todos. A regra não permite escolher a economia por vontade do fornecedor.

Dois provedores, um com 8 e outro com 13, poderiam servir caminhos válidos diferentes. Uma âncora nova poderia ser publicada antes da chave e das assinaturas correspondentes. Um provedor também poderia experimentar um algoritmo pós-quântico sem exigir que todos os parceiros mudassem no mesmo dia. Para completar a migração a um algoritmo ainda fora da categoria UNIVERSAL, uma fase de assinatura dupla pode continuar necessária.

A política privada do resolvedor muda o resultado público

Imagine a zona anunciando 8 e 13. Um provedor responde com assinatura válida em 8. O operador de um resolvedor desativou 8 por política local, embora o software ainda trate 13. Pela proposta, esse resolvedor deve classificar a zona como não assinada. Não deve imputar ao provedor um bogus e devolver SERVFAIL apenas porque recusou, por iniciativa própria, o algoritmo que o registro obriga a implementar. A lógica vale também para um algoritmo anteriormente UNIVERSAL que o resolvedor já não aceita.

O responsável pela zona seguiu uma expectativa comum. O responsável pelo resolvedor decidiu afastar-se dela. O usuário pode receber uma resposta DNS, mas ela perdeu a autenticação naquela visão. Um painel que conte somente consultas bem-sucedidas apagará o custo da política. É preciso registrar secure, insecure e bogus separadamente, além da mudança de configuração que provocou a diferença.

A exigência antiga de todas as assinaturas defendia contra um ataque real: retirar as assinaturas compreendidas pelo resolvedor não pode rebaixar silenciosamente uma resposta segura a uma resposta aparentemente insegura. O rascunho afirma manter essa defesa ao distinguir algoritmos UNIVERSAL e FORMERLY-UNIVERSAL. O validador deve lembrar os que um dia tiveram status universal, mesmo depois de desativados localmente. A classificação errada altera a fronteira de segurança.

O texto é a versão 00, datada de 31 de outubro de 2026, e ainda está no começo da análise do grupo. Não apresenta números de adoção ou incidentes. O fato necessário para uma implantação é uma matriz dos resolvedores reais: que estado cada um retorna para os subconjuntos de assinaturas dos provedores, e como esse estado muda quando 8 ou 13 é desligado? “Compatível com DNSSEC” não responde à pergunta.

O acordo proposto dá mais independência a quem assina e mais responsabilidade a quem valida. Uma assinatura pode bastar para a zona. O administrador que desliga o verificador não pode usar a resposta recebida como atestado de segurança.

Rascunho da IETF · RFC 4035 · RFC 6840 · RFC 8901 · Registro da IANA