Résumé

  • Dans son guide public des charges utiles Delegation Key, ARIN associe le type de condensat 3 à MD5 et indique une longueur de 32. Le registre IANA associe ce numéro à GOST R34.11-94, désormais déprécié.
  • L’unité de la colonne de longueur n’est pas précisée. Un condensat GOST de 256 bits représente 32 octets, mais 64 caractères hexadécimaux. Ce constat ne révèle pas les contrôles effectivement appliqués par l’API.
  • Les quatre colonnes de recommandations actuelles d’IANA portent MUST NOT pour ce type, conformément au RFC 9906. Rectifier son nom ne justifierait pas son utilisation. Aucun appel de provisionnement, aucune zone et aucun résolveur n’ont été testés ici.

Un entier dont le sens ne se négocie pas

Pour lire une interface de provisionnement, il faut parfois commencer par une question élémentaire : qui donne leur sens à ses numéros ? ARIN peut décrire les champs de son service. Cela ne lui donne pas une version particulière des identifiants DS. Or sa référence publique de Reg-RWS attribue à l’un d’entre eux un nom qui ne correspond pas au registre du protocole.

La section Delegation Key présente le type 3 sous le nom MD5. IANA inscrit à ce même numéro GOST R34.11-94, avec une mention de dépréciation. Il ne s’agit pas de deux graphies d’une fonction, ni d’une abréviation locale. Les fonctions sont différentes. Un libellé convivial peut expliquer un identifiant ; il ne peut pas en modifier l’attribution.

Le constat porte sur les pages accessibles et capturées le 14 septembre 2026. Il ne date pas l’apparition de la ligne contestée. Il ne prouve pas qu’ARIN produit, accepte ou publie des condensats MD5 sous le type 3. La durée du décalage, le comportement du service et l’état des délégations de ses utilisateurs ne peuvent pas être déduits de cette seule lecture.

Dans un enregistrement DS, le numéro de type accompagne les données du condensat. Il indique la fonction que ces données sont censées représenter. Si un développeur suivait le libellé MD5 pour fabriquer les données d’un type 3, il pourrait produire une association incompatible avec le sens enregistré. Cette proposition décrit un risque conditionnel. Elle ne rapporte ni un client identifié ni une défaillance observée.

Ce que contient réellement la référence

Le guide place une Delegation Key dans une Delegation Payload. Il présente notamment un champ algorithm et un champ digestType. Le premier renvoie à l’algorithme de la clé DNSKEY ; le second à la fonction de condensat DS. Lire les deux listes comme une seule famille de codes ferait perdre précisément la distinction dont dépend l’interprétation.

Le catalogue des algorithmes contient les valeurs 5, 7, 8, 10, 13, 14, 15 et 16, accompagnées de noms RSA, ECDSA ou EdDSA. Le tableau des condensats indique SHA1 pour 1, SHA256 pour 2, MD5 pour 3 et SHA384 pour 4. Ses longueurs sont respectivement 40, 64, 32 et 96. Il s’agit du contenu documenté, pas d’une liste blanche dont l’application en production aurait été vérifiée.

ARIN explique aussi que les noms d’algorithme et de type de condensat sont déterminés à partir des valeurs numériques saisies, et que les noms fournis sont écartés. Dans l’interface ainsi décrite, saisir un autre nom ne redéfinirait donc pas le numéro. La qualité de la correspondance entre nombre et nom devient d’autant plus utile à la personne qui consulte le guide.

Cette description ne constitue toutefois pas un reçu d’exécution. Elle ne montre pas le nom renvoyé par le service actuel, les étapes de validation, l’erreur produite pour une entrée donnée ou le contenu finalement conservé. Confondre une règle publiée et sa vérification transformerait une comparaison documentaire solide en accusation technique insuffisamment étayée.

Trois champs peuvent contenir 3 sans désigner la même chose

Le RFC 4034 définit le champ de type de condensat DS comme l’identifiant de l’algorithme utilisé pour construire ce condensat. Il décrit également son entrée : le nom propriétaire canonique de DNSKEY suivi des données de l’enregistrement DNSKEY, comprenant les drapeaux, le protocole, l’algorithme et la clé publique. Ce n’est pas simplement le hachage d’une chaîne de clé affichée à l’écran.

Le RFC 5933 rend les espaces d’identifiants GOST particulièrement visibles. Il attribue 12 à l’algorithme de signature DNSKEY ECC-GOST et 3 au type de condensat GOST R34.11-94. Le type DS 3 n’est donc pas un algorithme DNSKEY portant le numéro 3. Il n’est pas non plus la valeur 3 du champ protocole DNSKEY, ni une étiquette de clé dans laquelle apparaîtrait ce chiffre.

La répétition d’un entier ne crée pas une identité technique. Son champ fournit le contexte nécessaire. Cette discipline de lecture paraît modeste ; elle évite pourtant de demander à une liste d’algorithmes de signature de confirmer une attribution de condensat. Elle évite aussi de prendre une correction de vocabulaire pour un changement du format des enregistrements.

IANA et le RFC d’attribution concordent sur GOST pour le type de condensat 3. La dépréciation actuelle n’en fait pas un emplacement libre que la documentation d’un service pourrait remplir avec MD5. Le registre continue de permettre l’identification du numéro historique, même lorsque les recommandations interdisent désormais son usage.

La longueur a besoin d’une unité

Le nom incorrect est un constat direct. L’entrée de longueur appelle une conclusion plus prudente. ARIN intitule sa colonne Digest Length sans préciser s’il compte des octets, des caractères hexadécimaux ou une autre représentation. Les valeurs voisines de 40, 64 et 96 sont cohérentes avec des nombres de caractères hexadécimaux. Cette cohérence suggère une lecture ; elle n’établit pas une contrainte du service.

Le condensat GOST décrit dans le RFC 5933 comporte 256 bits. Cela correspond à 32 octets. En représentation hexadécimale, chaque octet demande deux caractères, soit 64 au total. Le RFC 4034 décrit précisément une représentation DS en hexadécimal, insensible à la casse, avec possibilité d’espaces. La taille des données et la longueur d’un texte formaté ne sont donc pas la même mesure.

Si la colonne compte des caractères hexadécimaux, 32 ne décrit pas la longueur du condensat GOST affecté au type 3. Si elle compte des octets, cette valeur décrit GOST, mais les autres lignes demandent alors une explication différente. La page ne tranche pas cette ambiguïté. Une rectification utile préciserait l’unité, ainsi que la manière de compter d’éventuels espaces de présentation.

Il serait excessif d’en conclure que le service refuse 64 caractères ou accepte 32 caractères. La documentation n’expose ici aucune observation sur le décodage, la normalisation, les contrôles successifs ou les messages d’erreur. Ces questions pourraient faire l’objet d’éléments distincts, obtenus dans des conditions autorisées. Elles ne doivent pas être considérées comme résolues par une inférence sur l’alignement du tableau.

Identifier l’ancien sans le recommander

La réparation du libellé rencontre une autre limite. Remplacer MD5 par GOST rétablirait le sens de l’identifiant, mais ne rendrait pas le type 3 approprié à une nouvelle délégation. Le RFC 9906, publié en novembre 2025, retire ECC-GOST et GOST R34.11-94 de l’usage DNSSEC. Les recommandations actuelles d’IANA sont sans ambiguïté sur ce point.

Pour le type 3, les quatre colonnes indiquent MUST NOT : utilisation pour la délégation, utilisation pour la validation, implémentation pour la délégation et implémentation pour la validation. L’ancienne description d’une implémentation facultative dans le RFC 5933 explique un état historique. Elle ne constitue plus une recommandation actuelle et ne permet pas de présenter un ancien MAY comme une permission encore applicable.

Un catalogue peut néanmoins décrire un identifiant rencontré dans une ancienne configuration. L’identification, l’inspection, la modification ou la suppression ne sont pas l’approbation de sa génération. Aucun chemin de compatibilité ou de retrait proposé par ARIN n’a été testé pour cet article. Il est seulement nécessaire de séparer la reconnaissance historique d’un code et les recommandations actuelles qui lui sont attachées.

Le RFC 9906 distingue aussi une chaîne ne disposant que des algorithmes retirés d’un constat de signature invalide. En l’absence d’un autre chemin d’authentification acceptable, le traitement prescrit est insecure, plutôt qu’une validation par ces algorithmes conduisant à qualifier la chaîne de bogus. Cela ne signifie pas que le nom est inaccessible. Aucun de ces états n’a été observé sur une zone ARIN dans cette enquête.

Une surface parentale limitée

La documentation d’ARIN sur le DNS inverse situe le champ dans son contexte. Une fois la zone inverse sécurisée, l’opérateur peut signaler les données DS au parent et les gérer par délégation via ARIN Online ou le service RESTful de provisionnement. Le tableau concerne donc une frontière réelle, entre les données de la zone enfant et leur description côté parent.

Cette frontière ne contient pas l’ensemble du service DNS. Fournir des données DS au parent n’est pas signer la zone enfant, publier tous ses DNSKEY ou administrer les résolveurs des lecteurs. Une erreur descriptive pourrait influencer un client sans franchir toutes ces étapes. La page ne révèle pas le résultat final d’une chaîne opérationnelle dont plusieurs acteurs contrôlent des parties différentes.

La demande proportionnée consiste à corriger la correspondance du type, préciser l’unité de longueur et distinguer statut historique et traitement actuel. Si le comportement effectif est contesté, il faut lui consacrer des preuves datées, reproductibles et distinctes. Rien dans cette comparaison ne justifie une suppression préventive de DS, un changement de clé non testé ou une modification des pouvoirs d’allocation d’adresses d’ARIN.

Sources

  • Référence des charges utiles Reg-RWS d’ARIN : champs Delegation Key, traitement documenté des noms et tableau des types et longueurs.
  • Registre IANA des types de condensat DS : attribution du type 3 et quatre recommandations actuelles.
  • RFC 5933 : attributions GOST distinctes et condensat de 256 bits ; les recommandations historiques ne sont plus applicables.
  • RFC 9906 : retrait de novembre 2025 et traitement de validation prescrit.
  • Guide du DNS inverse d’ARIN : contexte du provisionnement DS côté parent, sans constat sur une zone précise.
  • RFC 4034 : sens des champs DS, données d’entrée et représentation hexadécimale, non une recommandation actuelle de choix d’algorithme.