Résumé

  • La RFC 9904 est une RFC de l’IETF inscrite dans sa voie de normalisation, publiée en novembre 2025. Elle remplace officiellement la RFC 8624 et met à jour la RFC 9157.
  • Elle transfère les exigences d’implémentation et les recommandations d’usage DNSSEC vers les registres IANA DNS Security Algorithm Numbers et DS Digest Algorithms.
  • Les quatre cases restent distinctes : les responsabilités du validateur et du signataire ne se confondent pas, pas plus que l’usage pour valider et l’usage pour signer.
  • La RFC 9904 ne modifie elle-même aucun statut MUST, MAY, RECOMMENDED ou autre statut hérité. Toute modification ultérieure d’une recommandation exige une action de normalisation et doit décrire les conséquences de transition et d’interopérabilité.

Le changement porte donc sur le mécanisme de gouvernance, pas sur un nouveau verdict concernant un algorithme. La RFC 8624 présentait les exigences d’implémentation et les indications d’usage dans une table statique. La RFC 9904 place cette information dans les deux registres IANA pertinents. De futurs RFC pourront ainsi modifier les colonnes concernées par une action de normalisation ciblée, au lieu de remplacer à chaque fois une table complète dans un document général.

Pour un même numéro d’algorithme, quatre questions doivent être distinguées : le validateur doit-il l’implémenter ? Le signataire doit-il l’implémenter ? Son usage est-il recommandé pour la validation ? Est-il recommandé pour la signature ? Une seule étiquette telle que « pris en charge » ne répond pas à ces quatre questions. Après la RFC 9904, les registres IANA constituent la surface de référence des recommandations ; le texte des RFC reste l’autorité pour la procédure qui permet de modifier leurs colonnes.

La RFC 9157 fournit le contexte des considérations IANA DNSSEC mises à jour, tandis que la RFC 9364 fournit le contexte protocolaire de l’authentification DNSSEC et des preuves de non-existence. Les sources gelées ne permettent pas de conclure à une adoption actuelle, à un support fournisseur, à une fréquence d’incident, à une performance, à un coût de migration ou à un futur jugement cryptographique.

Analyse de Theo March : pour éclairer une décision, il peut être utile de conserver une copie datée des deux registres concernés, leur source et les quatre cases examinées. Lorsque le contexte de déploiement le permet, cette analyse peut également recommander un test de chevauchement entre l’ancien et le nouvel algorithme, une vérification séparée des validateurs et des signataires, un changement progressif et des éléments permettant un retour arrière. Ces pratiques relèvent de l’analyse de Theo March ; la RFC 9904 ne les impose pas comme opérations obligatoires.

La RFC 9904 formule néanmoins un avertissement concret : retirer trop tôt un algorithme peut faire paraître effectivement non signée, pour les validateurs, une zone signée uniquement avec cet algorithme. La dépréciation doit donc être délibérée et, idéalement, progressive. L’analyse de Theo March traduit ce risque en questions de gestion du changement : quelle case évolue, quels rôles sont concernés, quel texte décrit la transition et quelles conséquences d’interopérabilité faut-il examiner ? Les sources ne disent pas si un tel scénario est actuel, fréquent, rapide ou coûteux.

Repères de décision proposés par Theo March

  1. Observer : relever la version et l’heure des registres IANA utilisés pour la décision.
  2. Distinguer : rattacher l’action à l’implémentation du validateur, à celle du signataire, à la validation ou à la signature, sans fusionner les cases.
  3. Lire : examiner l’action de normalisation applicable et sa description de la transition et de l’interopérabilité.
  4. Évaluer : lorsque c’est pertinent, comparer les chemins de signature et de validation et examiner les résultats d’un test de chevauchement.
  5. Documenter : conserver, selon l’analyse de Theo March, les éléments utiles à la décision et à un éventuel retour arrière.

Cette liste est une proposition analytique de Theo March sur la gestion du cycle de vie ; elle n’ajoute pas d’exigences à la RFC 9904.

Sources