Résumé

  • draft-brown-epp-deleg-03 propose des opérations EPP pour lire, créer, ajouter, retirer ou supprimer en bloc des enregistrements DELEG liés à un domaine.
  • Le projet prévoit une coexistence durable entre DELEG et les NS classiques : une base de registre cohérente peut donc alimenter deux représentations publiques qui ne sont pas encore réconciliées.
  • La preuve exploitable doit prolonger la réponse EPP jusqu’à la génération de zone, la signature, le service autoritatif, la capacité du résolveur, les caches et le test applicatif.

Imaginons une maintenance qui se termine proprement à 02 h 14. Le client EPP est authentifié, la commande comporte deleg:all, le serveur renvoie un résultat positif et deux identifiants permettent de rapprocher la requête et la réponse. Le tableau du registraire devient vert. Quelques minutes plus tard, les sondes qui interrogent les NS historiques restent vertes elles aussi.

Ce double vert ne dit pas ce qu’un résolveur compatible avec DELEG a reçu du parent.

La révision 03 du projet de mapping EPP donne une forme précise à cette scène. Elle remplace l’ancienne syntaxe de paramètres par des éléments deleg:param nommés, change l’espace de noms, ajoute la suppression totale deleg:all et introduit des exigences d’exploitation. Le dossier Datatracker et son historique imposent toutefois une limite : il s’agit d’un Internet-Draft individuel, sans filière RFC. Ce n’est ni une norme IETF ni une preuve de mise en œuvre.

La transaction ferme le dépôt, pas le changement

Le projet distingue trois gestes. info peut restituer l’état DELEG conservé. create peut joindre des données DELEG à la création d’un domaine. update peut ajouter des records, retirer des records identifiés ou les retirer tous. La précision est utile : elle permet de savoir exactement ce que le serveur a accepté.

Mais EPP reste un protocole de dépôt. RFC 5730 définit le dialogue, les résultats et les identifiants de transaction. RFC 5731 décrit l’objet domaine et RFC 5732 l’objet hôte. Ces textes permettent de reconstruire une mutation de registre. Ils ne transforment pas la réponse du serveur en attestation émise par le générateur de zone, le signataire DNSSEC, chaque autorité parent ou les résolveurs.

Le client « sponsoring » dispose d’une autorité reconnue par le serveur sur l’objet. Cette autorité n’est pas universelle. Elle ne commande ni la version logicielle des résolveurs, ni le contenu de leurs caches, ni le chargement de la zone, ni le résultat observé par un utilisateur.

Deux délégations pendant une seule migration

Le point le plus important de la révision n’est peut-être pas le nouvel élément XML. Le projet prévoit que la plupart des domaines auront besoin, pendant une période indéterminée, de DELEG et des NS traditionnels dans la zone parente. Il recommande donc aux serveurs EPP d’autoriser DELEG en même temps que les objets ou attributs d’hôtes classiques.

La proposition de fond, Extensible Delegation for DNS, cherche précisément à éviter l’ambiguïté historique entre le jeu de NS du parent et celui de l’apex enfant. DELEG serait autoritatif chez le parent, extensible et protégeable par DNSSEC. Pourtant, pendant la transition, un jeu DELEG peut coexister avec NS. Sans NS, un logiciel qui ne comprend pas DELEG ne saura pas poursuivre la résolution.

Une suppression totale prend alors plusieurs sens possibles. Elle peut être un retour volontaire au service NS. Elle peut constituer un repli après essai. Elle peut aussi retirer par erreur la voie nouvelle tout en laissant les contrôles anciens au vert. La syntaxe ne permet pas de distinguer ces intentions.

Le projet DNSOP sur les extensions de délégation traite la négociation de capacité et la protection contre le repli forcé. Un serveur EPP qui accepte un objet ne peut pas témoigner à la place des serveurs DNS et des résolveurs qui doivent exécuter cette négociation.

Un vocabulaire évolutif peut diverger

La révision 03 interdit au serveur d’accepter un nom de paramètre inconnu ou une valeur mal formée. Elle impose aussi au client et au serveur de rafraîchir périodiquement la liste des DelegInfoKeys enregistrées. La règle évite l’invention locale de paramètres, mais crée une dépendance de version.

Un client peut connaître une clé que le serveur n’a pas encore intégrée. Plus tard, les deux peuvent accepter la clé alors que le générateur de zone ne sait pas encore la projeter. La validité du schéma, la compatibilité de l’écosystème et la publication effective sont trois constats différents.

Le projet DELEG demande la création d’un registre IANA des informations de délégation ; le projet EPP demande un espace de noms XML et l’inscription de l’extension. RFC 7451 encadre le registre des extensions EPP, et le registre IANA vivant est la référence pour les attributions réelles. Dans l’état gelé pour cette étude, l’extension proposée n’y figure pas. Une section « IANA Considerations » formule une demande ; elle n’effectue pas l’attribution.

La zone parente ouvre une seconde chaîne de preuve

La proposition DELEG interdit le RRset DELEG à l’apex enfant : un mauvais emplacement peut provoquer un échec de validation DNSSEC. RFC 4035 fournit le cadre de validation. Une réponse correctement authentifiée établit ce que la chaîne DNSSEC permet d’établir. Elle ne prouve pas que le RRset correspond à la dernière transaction EPP, ni que la représentation NS raconte la même histoire.

Le dossier de changement doit donc conserver l’intention et son mandataire, l’identité du client EPP, les octets de la commande, l’espace de noms, la photographie des DelegInfoKeys et les identifiants de transaction. Viennent ensuite la version réellement commitée, la règle de réconciliation entre DELEG et NS, l’entrée et la sortie du générateur de zone, le numéro de série parent et le résultat de signature.

Il faut enfin interroger chaque autorité pertinente par des chemins compatibles et non compatibles avec DELEG, enregistrer la capacité et la version du résolveur, la négociation, l’état de validation, l’âge du cache et le mécanisme de repli. Le dernier reçu appartient à l’application : elle est joignable, ou elle ne l’est pas, dans la fenêtre annoncée.

Les trois textes de Heng Lu servent ici de méthode éditoriale et non d’autorité protocolaire. La primauté du code en fonctionnement oblige à regarder l’état servi. La spécification initiale minimale et la décision locale séparent l’interopérabilité de la politique de migration. Les couches de réalité empêchent de transformer un symbole administratif en résultat technique.

Dossier officiel

Le paquet gelé comprend le dossier courant, l’historique des versions, le texte exact de la révision 03, les projets DELEG et DNSOP DELEXT, les RFC EPP cœur, domaine et hôte, le cadre d’extension, la validation DNSSEC et le registre IANA. Aucun de ces éléments ne démontre une transaction ou un déploiement nommé.