Resumo

  • A RFC 9905 é um documento IETF Standards Track, publicado em novembro de 2025, que atualiza as RFC 4034 e RFC 5155. Ela transforma a retirada do SHA-1 em uma migração assimétrica: parar de produzir, mas continuar validando.
  • RSASHA1 e RSASHA1-NSEC3-SHA1 MUST NOT criar registros DS, DNSKEY ou RRSIG. Delegações que tenham somente DS afetados devem ser tratadas como insecure nas condições especificadas; esse resultado não deve ser descrito como bogus ou falha universal de validação.
  • Implementações de validadores MUST continuar oferecendo validação para os dois algoritmos. Portanto, não se pode afirmar que todos os validadores já podem remover SHA-1. Software que já removeu essa validação pode precisar de uma compilação manual para cumprir a obrigação de implementação.
  • O plano operacional deve separar assinatura autoritativa, publicação de DS e validação recursiva, com evidências de sobreposição, cadeia verificável e rollback preparado.

A norma não cria um único estado operacional chamado “SHA-1 ativo” ou “SHA-1 desligado”. O sistema autoritativo recebe uma proibição de criar novo material. A publicação no pai recebe uma proibição de criar DS com os algoritmos afetados; quando não existe outro DS aceitável, a delegação e os dados abaixo dela são tratados como insecure. O software recursivo recebe uma obrigação diferente: continuar implementando a validação. Essas obrigações não devem ser colapsadas.

Análise de Theo March: a assimetria é uma resposta ao ciclo de vida do software e ao lock-in. Remover primeiro o código de validação pode tornar impossível demonstrar compatibilidade com dados ainda instalados. Continuar assinando com SHA-1, por outro lado, prolonga a produção do material que a RFC 9905 proíbe. A transição segura fica entre esses extremos: introduzir um algoritmo mais forte, confirmar a cadeia e preservar a capacidade de validar o legado enquanto ela ainda for exigida.

Sequência operacional e verificações concretas

Primeiro, inventarie os assinadores autoritativos. Para cada zona, registre os algoritmos presentes em DNSKEY e RRSIG e confirme que RSASHA1 e RSASHA1-NSEC3-SHA1 não são usados para criar novos registros. A RFC 9905 orienta proprietários de zonas que usam algoritmos baseados em SHA-1 a migrar imediatamente para algoritmos mais fortes recomendados pelos registros IANA. O texto não presume qual algoritmo é mais adotado nem antecipa alterações futuras no registro.

Segundo, verifique a publicação de DS no pai. Não gere DS com os dois algoritmos afetados e confirme se há um DS usando algoritmo aceito para formar a cadeia. Se houver somente um DS SHA-1 e nenhum outro DS aceito puder validar a delegação, o resultado normativo é insecure. Não transforme esse resultado em bogus, failed ou numa autorização geral para remover suporte de SHA-1 dos validadores.

Terceiro, teste a validação recursiva. Confirme no build efetivamente executado que os dois algoritmos ainda podem validar, usando consultas controladas, respostas DNSKEY e RRSIG e a cadeia completa. Guarde os resultados. Se o software já removeu a validação SHA-1, avalie uma compilação manual para atingir o nível de implementação ainda exigido. Não atribua esse comportamento a um fornecedor específico nem invente padrões de implantação, incidentes ou números de desempenho.

A evidência de sobreposição deve mostrar um DNSKEY/RRSIG mais forte publicado e validável, um DS correspondente publicado pelo pai e uma cadeia vista pelo resolvedor recursivo. Só depois avance para retirar o caminho antigo de produção. Se a nova cadeia não validar, se a visibilidade do DS divergir da zona autoritativa ou se o teste recursivo falhar, interrompa a retirada e volte à última configuração comprovadamente válida. Esse rollback restaura a configuração forte e os estados de DS já preparados; não significa recriar material SHA-1 proibido. Documente janela, responsável, critério de sucesso e condição de parada para cada etapa.

Fontes