Résumé

  • RFC 3375 organisait un système partagé : plusieurs bureaux pouvaient parrainer et administrer des objets, mais un seul registre restait l’autorité pour un espace de noms et une zone donnés.
  • Identité de l’objet, parrainage, association à une ressource commune, transfert, réponse transactionnelle et publication DNS formaient des preuves distinctes. La réussite d’une commande n’achevait pas automatiquement toute la chaîne.

Un titulaire commande un domaine auprès d’un bureau d’enregistrement. Le bureau transmet une opération au registre. Plus tard, le domaine change de bureau, tandis que son identité technique persiste. Un serveur de noms géré par le premier peut aussi desservir un domaine parrainé par le second. Enfin, certaines données du dépôt deviennent une zone DNS. Dans l’expérience du client, tout semble être une seule opération ; dans l’infrastructure, chaque étape engage une autorité différente.

Publié en septembre 2002 avec le statut Informational, RFC 3375 formula les exigences d’un protocole générique entre registre et bureaux d’enregistrement. Ce n’était ni une norme Internet ni un constat de déploiement. Le document décrivait les fonctions nécessaires à des modèles d’exploitation variés au moment où l’enregistrement partagé cessait d’être une exception administrative.

Son vocabulaire institutionnel était précis. Le titulaire demandait l’enregistrement par l’intermédiaire d’un bureau. Le bureau fournissait l’interface commerciale et accédait au registre. Le registre conservait le dépôt central lié aux délégations et produisait normalement les fichiers de zone. Dans un système partagé, plusieurs bureaux indépendants utilisaient ce même service de registre sans être étroitement confondus avec lui.

La concurrence à l’entrée ne divisait donc pas l’autorité finale. RFC 3375 affirmait qu’un espace de noms et une zone n’avaient qu’un seul registre faisant autorité, même si un registre pouvait servir plusieurs espaces. Le bureau détenait des capacités de gestion sur les objets qu’il parrainait ; il ne recevait pas pour autant une part souveraine de la zone.

Le protocole commun devait ouvrir et fermer des sessions, interroger les objets, les créer, les mettre à jour, les renouveler, les supprimer et les transférer. Authentification, autorisation, état et identifiants de transaction rendaient les actions attribuables. Mais l’identifiant d’une transaction réussie attestait d’abord une opération dans le registre. Il ne prouvait ni l’intention juridique du titulaire, ni la génération d’une zone, ni son chargement par les serveurs faisant autorité, ni la réponse vue par un résolveur distant.

L’identité des objets constituait un second axe. Chaque objet devait avoir un identifiant globalement unique, conservé pendant toute sa vie dans un dépôt, y compris après un changement de contrôle administratif. Le protocole pouvait donc enregistrer une nouvelle garde sans fabriquer une nouvelle identité. Cette permanence rendait le transfert auditable.

Les ressources partagées révélaient une distinction plus fine. Un serveur de noms pouvait être associé à des domaines relevant de plusieurs bureaux. Le bureau Y pouvait référencer un serveur administré par le bureau X pour son propre domaine ; cette association ne lui donnait pas le droit de modifier le serveur. Utiliser une ressource n’équivalait pas à la contrôler.

Le transfert d’un domaine devait alors être une procédure autorisée. Le futur administrateur lançait la demande ; le système vérifiait l’autorisation, exposait l’état, décrivait les objets entraînés par le transfert, permettait une annulation avant décision et annonçait l’acceptation ou le refus. Les serveurs internes au domaine pouvaient suivre celui-ci. La conséquence devait être visible, non cachée dans un changement de ligne.

RFC 3375 ménageait également les architectures dites épaisses et minces. Dans un registre épais, informations techniques et informations sociales ou de contact résidaient au registre. Dans un modèle mince, une partie restait chez les bureaux. Le protocole générique cherchait l’interopérabilité entre ces choix, pas leur uniformisation.

La frontière avec le DNS est cruciale. RFC 1034 et RFC 1035 décrivent les zones, les serveurs faisant autorité, la résolution et les caches. RFC 2136 définit une voie de mise à jour dynamique. RFC 3375, lui, traite d’objets de registre et attribue au registre la production des fichiers de zone. Un renouvellement ou un changement de contact peut réussir sans modifier la zone ; une délégation acceptée peut attendre une projection, une distribution et un chargement avant d’être observable. Base de registre et DNS public ne sont pas un reçu unique.

RFC 2832 avait spécifié un protocole Registry Registrar. RFC 3730 décrivit ensuite EPP, remplacé plus tard par RFC 5730 ; RFC 5731, RFC 5732 et RFC 5733 précisèrent les mappages pour domaines, hôtes et contacts. Cette filiation montre l’affinement des interfaces. Elle ne fournit ni recensement mondial des mises en œuvre ni garantie d’un délai opérationnel commun.

Il faut aussi lire les mots normatifs avec RFC 2119 : « MUST » impose une propriété au protocole envisagé, il ne certifie pas le monde réel. La politique d’internationalisation de RFC 2277 rappelle qu’une infrastructure mondiale devait distinguer identifiants techniques, langues humaines et informations de contact, plutôt que de les rabattre sur une seule représentation.

La « spécification initiale minimale » de Lu Heng éclaire cette architecture : définir juste assez de règles communes pour coopérer, sans confisquer les décisions locales ultérieures. Son analyse des couches de réalité fournit la méthode d’audit. Demande du titulaire, autorisation du bureau, parrainage, acceptation du registre, état du dépôt, génération de zone, service faisant autorité et observation du résolveur sont corrélés, mais restent des assertions séparées.

L’héritage de RFC 3375 réside ainsi dans une séparation productive. Le marché pouvait multiplier les guichets sans multiplier l’autorité d’un espace de noms. Un objet pouvait changer de gardien sans perdre son identité. Une ressource pouvait être partagée sans devenir administrable par tous ceux qui la citaient. L’échelle naissait de ces frontières ; la preuve opérationnelle doit les respecter.

Sources