Resumo
- A RFC 9904 é uma RFC do IETF na via de normalização, publicada em novembro de 2025; ela substitui formalmente a RFC 8624 e atualiza a RFC 9157.
- As recomendações de requisitos de implementação e de uso de algoritmos DNSSEC que estavam na RFC 8624 passam a ter como superfície canônica os registros IANA DNS Security Algorithm Numbers e DS Digest Algorithms. A RFC 9904 não altera, por si só, nenhum status MUST, MAY, RECOMMENDED ou outro status herdado.
- As quatro colunas — implementação do validador, implementação do assinador, uso na validação e uso na assinatura — têm funções distintas. Alterar um valor exige uma ação de padronização e deve explicar as consequências de transição e interoperabilidade.
“Levar para o registro” não significa que a IANA possa mudar valores sem uma ação de padronização. A mudança é de superfície de controle e de manutenção: os registros IANA passam a ser o local canônico para consultar as recomendações, enquanto o texto da RFC continua sendo a autoridade sobre o processo que pode alterá-las. A RFC 9904 também incorpora e atualiza as considerações de registro DNSSEC da RFC 9157. A RFC 9364 fornece o contexto protocolar para autenticação DNSSEC e provas de inexistência, mas não acrescenta uma mudança de recomendação à RFC 9904.
A separação das quatro células é operacionalmente decisiva. Um validador pode ter uma obrigação de implementação diferente da de um assinador; a recomendação para usar um algoritmo ao validar não é automaticamente a recomendação para usá-lo ao assinar. Se essas dimensões forem reduzidas a “suportado” ou “não suportado”, desaparecem tanto a responsabilidade específica quanto a assimetria do risco de migração. Uma política precisa dizer qual função está mudando e qual ainda precisa manter compatibilidade.
A análise de Theo March propõe que equipes operacionais registrem o nome do registro consultado, uma cópia datada, o horário de observação e os valores das quatro células usados na decisão. Também propõe separar as responsabilidades por validadores recursivos, assinadores autoritativos, política de validação e política de assinatura. Antes de aposentar um algoritmo, a análise de Theo March recomenda considerar testes com assinatura sobreposta e validação usando os algoritmos antigo e novo, além do registro de resultados, falhas, janela temporal e instruções de recuperação.
A mesma análise recomenda mudanças deliberadas, possivelmente graduais, e um caminho de reversão. Essas são recomendações analíticas de operação, não requisitos adicionais impostos pela RFC 9904. A RFC 9904 alerta que aposentar cedo demais o único algoritmo usado para assinar uma zona pode fazer essa zona parecer efetivamente sem assinatura para validadores.
Fontes
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
