Résumé

  • La révision 01 d’un Internet-Draft individuel consigne deux attributions réalisées par Expert Review le 20 août 2026 : le type DNS 69 porte le nom UNECE et le type 70 le nom ISO. Les numéros figurent déjà au registre IANA ; le texte n’est ni un RFC ni un document adopté par DNSOP.
  • Le format transporte sans modification le code d’un registre externe, mais omet année d’édition, amendement et corrigendum. Le projet propose d’utiliser le début de validité du RRSIG pour retrouver la version historique ; ce champ temporel ne nomme pas lui-même l’artefact UNECE ou ISO consulté.

Dans le registre des paramètres DNS d’IANA, deux lignes nouvelles se suivent désormais. UNECE reçoit la valeur décimale 69, ISO la valeur 70. La date d’enregistrement est le 20 août 2026. Les deux lignes renvoient encore à la révision 00 du projet ainsi qu’à leur formulaire d’examen.

Ce tableau établit l’unicité des numéros. Il ne transforme pas IANA en conservateur des monnaies, des pays, des langues ou des unités de mesure.

La révision 01, déposée le 9 septembre, rend cette distinction explicite. Son annexe et la comparaison officielle indiquent que l’unique changement depuis la révision 00 consiste à consigner les deux attributions et la fin de l’Expert Review. La fiche Datatracker, son historique et l’enregistrement API décrivent toujours un Internet-Draft individuel actif, sans numéro de RFC, flux ni Area Director responsable.

L’en-tête vise le Standards Track, mais il ne vaut pas adoption. RFC 6895 soumet l’attribution des RRTYPE à Expert Review ; RFC 8126 décrit le jugement des experts désignés. C’est un mécanisme d’allocation contrôlée, distinct du parcours qui pourrait un jour conduire le document à un RFC.

Une enveloppe IANA, deux autorités sémantiques

Le projet refuse sciemment de recopier chez IANA les listes tenues par UNECE ou ISO. Le type DNS identifie l’organisme. Un discriminateur désigne ensuite une recommandation UNECE, par exemple 16 ou 20, ou une norme ISO telle que 3166-1, 4217 ou 639. Le code est transporté tel quel et comparé octet par octet. L’émetteur ne peut pas en inventer un.

Le formulaire UNECE et le formulaire ISO justifient cette architecture : les conventions TXT privées perdent la structure et l’interopérabilité, tandis qu’un miroir IANA créerait un second prétendant à l’autorité. Les listes continuent donc de vivre sur le site des recommandations UNECE et dans les mécanismes de maintenance d’ISO 3166. RFC 6116 offre un précédent avec ENUM et les codes E.164.

Le récepteur doit aussi conserver un discriminateur ou un code inconnu et l’afficher sans l’interpréter. C’est une excellente discipline : la nouveauté n’est pas assimilée à l’invalidité. Mais elle reporte la décision métier vers le système qui consomme le RRset.

La compatibilité future efface l’année d’édition

Le jeton de recommandation ou de norme ne comprend ni année, ni amendement, ni corrigendum. ISO 3166-1 reste donc le même identifiant lorsque sa liste évolue. UNECE 20 suit la même logique. Le format réseau demeure stable et n’exige pas une nouvelle action IANA à chaque publication externe.

Cette stabilité n’est pas une stabilité de sens. Les régimes de retrait diffèrent. Selon le projet, UNECE conserve les codes supprimés ou déconseillés dans ses listes ; ISO 4217 garde les anciennes monnaies avec leur date de retrait ; ISO 639 ne réattribue pas un identifiant retiré ; ISO 3166 applique une période de réservation, mais des réattributions ont existé. Le même octet peut donc être durable, historique, retiré ou réutilisable suivant l’autorité concernée.

Le texte impose un premier filtre : au moment de publier le RR, la liste doit être active, gratuite d’accès et citable. Il demande aussi aux futurs types fondés sur ce modèle de documenter les règles de retrait et de réattribution. Cela protège l’entrée. Cela ne conserve pas automatiquement ce que le récepteur a lu.

Le début du RRSIG situe, il n’identifie pas

Pour une lecture historique, le projet recommande la version du registre en vigueur au moment où commence la validité du RRSIG couvrant le RRset. Ce point temporel est utile. Il ne constitue pas une référence d’édition.

RFC 4034 définit Signature Inception comme le premier instant où le RRSIG peut servir à authentifier le RRset. Les autres champs portent notamment l’expiration, l’algorithme, le key tag et le nom du signataire. Aucun ne contient le numéro d’édition UNECE, l’URL ISO ni l’empreinte de la table externe. RFC 9364 replace ces éléments dans l’authentification de l’origine et l’intégrité DNSSEC, non dans l’archivage des organismes de normalisation.

Un opérateur peut signer de nouveau un RDATA inchangé. La date de début change, pas nécessairement l’assertion. Inversement, une liste externe peut évoluer pendant qu’une ancienne signature reste valide. Pour passer de l’horloge du RRSIG à une interprétation, le récepteur dépend encore d’un calendrier public, d’un artefact récupérable et d’une règle de retrait.

Aucune source de ce dossier ne montre une erreur réelle. La lacune est documentaire : une vérification cryptographique réussie peut coexister avec deux interprétations historiques si les récepteurs n’ont pas résolu la même édition.

Garder la preuve de l’interprétation

Une fiche locale de résolution du registre externe suffit. Elle associe : RRTYPE et discriminateur ; valeur et code bruts ; organisme mainteneur ; édition exacte quand elle existe, sinon URL, heure de récupération et empreinte ; début, expiration, signataire et résultat du RRSIG ; règle de retrait appliquée ; traitement d’un code inconnu ; version de la politique de l’émetteur ; et décision locale ayant utilisé le sens obtenu.

Cette fiche ne certifie ni UNECE ni ISO. Elle rend reconstructible le chemin du récepteur. Elle distingue ce que le DNS a authentifié de ce que la source externe a défini et de ce que l’organisation locale a décidé. Une nouvelle signature ne réécrit pas silencieusement l’histoire sémantique d’un code inchangé.

La proposition suit l’économie de la spécification initiale minimale de Heng Lu : rendre déterministe la frontière de confiance, sans centraliser les règles métier. The Policy Mirror ajoute le besoin de relier règle, autorité et résultat. La fiche reste mon analyse ; elle ne figure pas dans le projet.

Les numéros 69 et 70 sont désormais visibles. Leur bonne gouvernance dépendra de la capacité à montrer non seulement quel code a été signé, mais quelle version externe lui a donné sens.

Sources