Résumé

  • La révision 05 de l’extension RDAP pour DNS DELEG retire priority et target, adopte le nom DelegInfos et reprend les exemples de DELEG-11.
  • Le projet d’extension EPP qu’elle cite comme référence normative garde ces deux attributs dans son schéma XML présenté comme complet.
  • Le marqueur de conformité dnsDeleg est déjà prescrit dans le projet RDAP, alors que la liste et la conversion complètes des paires clé-valeur sont encore notées TBD.
  • Les sources ne documentent ni déploiement ni perte de données réelle. Elles montrent seulement qu’un aller-retour EPP–DNS–RDAP ne peut pas encore être reproduit à partir des textes courants.

Une mise à jour qui règle un côté de l’interface

L’annonce des Internet-Drafts date draft-albanna-regext-rdap-deleg-05 du 4 septembre 2026. Le projet veut insérer des valeurs DELEG et DELEGPARAM dans les réponses RDAP relatives aux domaines. Il ne s’agit donc pas de définir le nouveau mécanisme DNS lui-même, mais de rendre son état lisible dans le protocole public des données d’enregistrement.

Son historique de modification dit exactement ce qui a bougé depuis la version 04 : suppression des références à priority et target, passage de delegInfo à DelegInfos, et remplacement des exemples pour suivre DELEG-11. La raison apparaît dans le texte de DELEG-11. Malgré son héritage conceptuel de SVCB, DELEG n’emploie ni SvcPriority ni TargetName. Le contenu est une liste de paires DelegInfo.

Le projet de groupe de travail définit aujourd’hui quatre clés pour localiser les serveurs de noms : adresses IPv4, adresses IPv6, noms de serveurs et pointeurs include-delegparam. Une clé mandatory complète ce premier ensemble. Il prévoit aussi un registre IANA distinct où chaque future clé aurait un numéro, un nom, un sens, une référence stable et un responsable du changement.

La révision RDAP s’est donc rapprochée du modèle DNS courant. Pour un client qui lit du JSON, les deux anciens champs ne font plus partie de l’histoire racontée.

Le schéma d’entrée n’a pas encore fait le même trajet

Le projet RDAP fonde pourtant sa structure sur deux dépendances normatives : DELEG et le projet de mappage EPP pour DELEG. Ce deuxième texte couvre la commande par laquelle un client autorisé peut créer, modifier ou consulter les informations d’un domaine dans un registre. Il prolonge le mappage de domaine normalisé par le RFC 5731.

La révision 02 du projet EPP affirme que sa section de syntaxe formelle constitue un schéma complet, utilisable pour valider automatiquement les instances XML. Dans ce schéma, delegType possède toujours un attribut priority de type entier court non signé et un attribut target. Le conteneur de paramètres accepte en outre des attributs quelconques avec processContents="skip".

Le calendrier explique peut-être tout : cette révision est du 21 juillet, DELEG-11 du 23 juillet, et RDAP-05 du 4 septembre. Mais un décalage éditorial plausible n’est pas encore une règle d’interopérabilité. Si une entrée conforme au schéma EPP comporte les deux attributs, les textes actuels ne disent pas de façon normative si le pont doit les refuser, les ignorer, les conserver ailleurs ou les convertir.

Rien ici ne prouve qu’une telle entrée circule réellement. Aucun journal de registre, serveur RDAP ou logiciel de résolveur n’a été observé. Le constat porte sur les spécifications publiées, pas sur un produit.

Le mot de conformité ne donne pas la provenance

Le projet RDAP impose dnsDeleg dans rdapConformance lorsque sa nouvelle structure est présente. Selon le RFC 9083, ces identifiants indiquent les spécifications employées pour construire une réponse et permettent aux clients de reconnaître des valeurs JSON étendues. Ils ne décrivent pas chaque transformation antérieure.

Or la section décisive de RDAP-05 porte toujours la mention TBD : la spécification complète des clés qui peuvent apparaître dans DelegInfos sera définie après évolution de DELEG et du mappage EPP. Les exemples offrent une intuition, non une table normative reliant XML, format DNS de présentation, octets DNS et JSON.

Au moment de la collecte, le registre IANA des extensions RDAP ne contenait pas dnsDeleg. Le projet demande son enregistrement pour tout opérateur. Ce fait n’est ni un refus ni un retard imputable à IANA ; il situe simplement un identifiant encore proposé.

Un autre projet du groupe REGEXT, consacré au versionnage de RDAP, prévoit des versions lisibles par machine, des liens prédécesseur/successeur, des avis d’obsolescence et des politiques de transition. RDAP DELEG n’utilise pas encore ce dispositif pour annoncer le modèle exact de sa charge utile.

Les statuts de procédure ne sont pas interchangeables

Le Datatracker de RDAP DELEG le classe comme Internet-Draft individuel, sans filière RFC ni Area Director responsable. Le mappage EPP a le même caractère individuel. Leur publication ne vaut pas adoption par l’IETF.

DELEG-11 est bien un document du groupe DELEG et se trouve en Working Group Last Call. Il demeure néanmoins un projet ; certains numéros de types DNS et le futur registre des informations de délégation sont encore demandés ou provisoires. Un document de groupe et deux contributions individuelles ne forment pas, par simple juxtaposition, une pile approuvée.

Le risque immédiat est donc un risque de cristallisation, pas la preuve d’une panne. Si chaque équipe implémente la version qui lui convient, le coût du raccord apparaîtra plus tard entre organisations.

Ce qu’il manque : la garde du sens entre les formats

Une chaîne vérifiable doit nommer l’autorité de chaque champ et la règle de chaque passage. L’entrée EPP a-t-elle été acceptée sous quelle version ? Quel état DNS en résulte ? Le JSON RDAP reflète-t-il l’intention du registre, une observation de la zone autoritative ou une projection locale ? Que devient un champ sans équivalent ?

Tant que ces réponses ne sont pas gelées, dnsDeleg indique une capacité sans identifier le chemin qui l’a produite. Celui qui contrôle ce chemin décide quelle version de l’intention devient publiquement visible. C’est là que la question de format devient une question de gouvernance.