Résumé

  • La RFC 9904 installe dans les registres IANA la source canonique de quatre recommandations distinctes : usage et implémentation, côté signature/délégation et côté validation.
  • La RFC 9905 interdit de créer de nouveaux éléments DNSSEC fondés sur SHA-1, mais conserve la capacité de les valider pendant la sortie. Le registre fixe la direction ; la zone doit encore accomplir le parcours.

À minuit, une cellule IANA passe à MUST NOT. À minuit une seconde, le parent sert toujours son ancien DS, les caches gardent leurs TTL et les autorités répondent avec le dernier numéro de série publié. Ce décalage n’est pas une anomalie. Il révèle simplement que le registre et le DNS n’habitent pas la même horloge.

Publiée en novembre 2025, la RFC 9904 remplace la RFC 8624 comme source des recommandations d’algorithmes DNSSEC et les place dans les registres IANA. Sa notice officielle en fixe le statut ; elle reprend aussi le cadre révisé de la RFC 9157. Point essentiel : la RFC 9904 n’a pas modifié les valeurs initiales. Elle a rendu leur futur changement plus visible et plus facile à référencer.

Le registre des algorithmes DNSSEC ne dit plus simplement « pris en charge ». Il distingue l’usage pour signer, l’usage pour valider, l’implémentation dans un logiciel de signature et l’implémentation dans un validateur. Le registre des condensats DS sépare de même la création d’une délégation et sa validation. Cette matrice empêche une compatibilité commerciale de masquer une recommandation d’exploitation.

La RFC 9905 donne au mécanisme son premier cas décisif. RSASHA1 et RSASHA1-NSEC3-SHA1 ne doivent plus servir à créer DNSKEY, RRSIG ou DS. En revanche, les validateurs doivent continuer à savoir traiter ces signatures pendant leur retrait. Il faut tarir la nouvelle dépendance sans rendre immédiatement inaccessibles les dépendances existantes.

La migration se déroule ensuite chez plusieurs responsables. Le signataire change de configuration et produit un nouveau jeu de clés et de signatures. La zone enfant publie un numéro de série. Le canal registrar-registre modifie le DS parent. Les serveurs faisant autorité convergent. Les résolveurs récursifs voient les anciennes et nouvelles données selon leurs caches, leurs versions et leurs algorithmes.

La RFC 9364 situe DNSSEC comme pratique d’authentification d’origine. La RFC 4035 oblige à distinguer les résultats secure, insecure, bogus et indeterminate. La RFC 9905 prévoit un traitement insecure dans des cas SHA-1 précis quand aucun chemin accepté ne valide. En déduire que toute zone contenant SHA-1 est « cassée » serait effacer le mécanisme même de transition.

L’ordre protège cette transition. La RFC 9904 avertit qu’un changement simultané d’algorithme DS et de KSK peut provoquer des échecs et demande de mettre d’abord à niveau l’algorithme DS. La RFC 6781 détaille l’enchaînement de RRSIG, DNSKEY et DS, avec des délais de propagation et d’expiration. Un outil peut déclarer sa tâche réussie alors que le monde observable demeure partagé.

Le dossier de clôture doit donc relier version IANA, RFC autorisante, logiciel du signataire, révision de configuration, numéro de série, empreintes DNSKEY/RRSIG/DS, reçu du parent, observations autoritatives, fenêtres TTL, versions de validateurs, résultats, erreurs et possibilité de retour. Aucun de ces éléments ne parle au nom des autres.

La spécification initiale minimale de Heng Lu justifie un socle commun mince. La primauté du code en fonctionnement réclame l’état réellement servi et validé. Les couches de réalité empêchent que la recommandation devienne la preuve de la configuration puis du résultat. Ce cadre est éditorial, non normatif.

Le registre peut rendre la destination incontestable. La preuve du voyage reste à construire zone par zone.

Sources