Résumé

  • La RFC 9905 est un document IETF Standards Track de novembre 2025 qui met à jour les RFC 4034 et RFC 5155.
  • RSASHA1 et RSASHA1-NSEC3-SHA1 ne doivent impérativement pas créer d’enregistrements DS, DNSKEY ou RRSIG. Une délégation qui ne dispose que d’un DS concerné est traitée comme non sécurisée lorsqu’aucune autre chaîne DS acceptée n’existe.
  • Les implémentations de validateurs doivent impérativement continuer à valider avec ces algorithmes. Cette obligation est distincte de l’interdiction de signer et du résultat « non sécurisé » d’une délégation.

Le mécanisme se lit directement dans les lignes du registre : la production porte la valeur MUST NOT, tandis que l’implémentation de validation conserve une exigence de continuité. La RFC 9905 ne dit donc pas que tous les validateurs peuvent supprimer SHA-1 dès maintenant. Elle demande aux exploitants de zones de passer aux algorithmes plus robustes recommandés par les registres IANA, alors que les consommateurs doivent encore pouvoir valider les données héritées pendant la transition. Un logiciel qui a déjà supprimé la validation SHA-1 peut nécessiter une compilation manuelle pour satisfaire cette obligation.

La séquence opérationnelle comporte trois contrôles séparés. D’abord, le signataire faisant autorité doit cesser de produire des DNSKEY et RRSIG RSASHA1 ou RSASHA1-NSEC3-SHA1. Ensuite, la délégation doit cesser de créer des DS avec ces algorithmes et publier une chaîne DS plus robuste avant de retirer l’ancienne. Enfin, l’infrastructure de validation récursive doit conserver l’implémentation et tester sa capacité à valider les données héritées. Une nouvelle configuration de signature ne prouve ni la migration de la délégation ni celle du parc récursif.

Une transition maîtrisée repose sur le chevauchement. Publiez et validez les DNSKEY et RRSIG plus robustes, publiez le DS correspondant, puis observez la validation récursive réussie tandis que l’ancien chemin reste seulement un artefact de transition. Conservez les réponses faisant autorité, les ensembles DS, les récupérations DNSKEY/RRSIG, les résultats de validation et les délais liés aux caches. Les preuves de retour arrière sont tout aussi concrètes : conserver la configuration précédente de zone et de clés, consigner le dernier état DS validé et définir la restauration de la configuration acceptée sans produire de nouveau SHA-1.

Un retour arrière ne constitue pas une permission de reprendre une production interdite.

Vérifications concrètes :

  1. Rechercher RSASHA1 et RSASHA1-NSEC3-SHA1 dans la configuration du signataire et les zones générées ; le résultat doit être nul pour toute nouvelle production.
  2. Examiner séparément la publication des DS chez le parent. Vérifier que l’algorithme plus robuste est présent et qu’une délégation uniquement SHA-1 n’est pas considérée comme sécurisée.
  3. Tester un validateur récursif avec des jeux de données hérités et avec une zone utilisant l’algorithme plus robuste. Noter le résultat, la version et les options de compilation.
  4. Vérifier si le logiciel déployé a supprimé la validation SHA-1. Si oui, prévoir une compilation manuelle ou une autre voie satisfaisant l’exigence de validation maintenue.

Il s’agit aussi d’un problème de software-lifecycle-and-lock-in : une suppression trop précoce peut éliminer la compatibilité nécessaire au parc installé, tandis qu’un signataire inchangé peut enfreindre la nouvelle règle de production. Les sources gelées ne donnent aucune donnée actuelle sur l’adoption, les fournisseurs, les incidents, les performances ou de futures modifications du registre ; ces sujets exigent donc des preuves distinctes.

Sources