Résumé

  • RFC 3632 donne deux sens à -Approve:No : le registrar sponsor refuse la demande d’un autre, tandis que le registrar demandeur annule sa propre demande. L’identité authentifiée et l’état en attente complètent la grammaire.
  • Le code 200 confirme le traitement réussi d’une commande RRP. Il ne démontre ni l’intention du titulaire, ni son consentement, ni une modification DNS, ni le résultat vu par les utilisateurs.
  • Un dossier probant doit relier session, rôle, état antérieur, règle, horloge, réponse, état ultérieur et notifications hors bande. Conserver le texte sans ces relations revient à conserver une phrase sans son locuteur.

Avant de lire le verbe, identifier celui qui parle

Un protocole paraît souvent plus objectif qu’une procédure humaine : le message est exact, le serveur répond, le code est archivé. Mais l’exactitude du message ne garantit pas l’exactitude de l’interprétation. Dans RFC 3632, document informatif publié en décembre 2003, le sens d’une option dépendait d’un fait absent de l’option elle-même.

Avec -Approve:No, le registrar qui sponsorisait actuellement le domaine rejetait une demande de transfert. Avec les mêmes caractères, le registrar qui avait lancé cette demande l’annulait. Le premier s’opposait à l’initiative d’un tiers ; le second retirait la sienne. Ce ne sont pas deux formulations d’un même geste, mais deux compétences institutionnelles.

Le dossier RFC Editor, le Datatracker, l’historique documentaire et la recherche d’errata fixent le statut du texte. Ils ne disent pas quel opérateur l’a déployé ni comment une transaction réelle s’est terminée. RFC 3632 n’est pas une norme Internet ; il sert ici d’archive précise d’un problème d’autorité.

L’identité venait de la session, pas d’une déclaration libre

RFC 2832 décrivait le modèle antérieur de RRP. L’identité du registrar demandeur provenait de la session active authentifiée. Le registre connaissait déjà le registrar sponsor du domaine. La décision reposait donc sur la jonction de trois données : principal de session, rôle attaché à l’objet et état du transfert.

Cette construction évitait de croire un champ auto-déclaré. Écrire « je suis le sponsor » dans une charge utile ne crée pas le pouvoir de parrainer. Le registre devait comparer le locuteur authentifié à son propre état. Une tentative d’approbation ou de rejet par un autre registrar devait échouer.

RFC 2832 exigeait aussi un avis hors bande au registrar susceptible de perdre le domaine, par courrier électronique ou rapport. L’événement institutionnel débordait donc le dialogue réseau. Une trace complète devait réunir l’authentification, la commande, la mutation du registre et la notification.

Or RRP ne renvoyait ni horodatage ni identifiant de transaction. Les rapports quotidiens ou hebdomadaires décrits par le texte ajoutaient des dates en heure locale du registre. Une enquête ultérieure devait recoller des preuves portant des horloges et des clés différentes. Une réponse exacte pouvait rester impossible à attribuer.

L’annulation était une compétence limitée dans le temps

RFC 3375 formulait les exigences institutionnelles : le registrar demandeur lance le transfert et peut l’annuler avant décision ; le sponsor actuel peut l’approuver ou le refuser ; un tiers ne peut exercer aucun de ces pouvoirs. Les deux côtés doivent pouvoir suivre les états en attente et terminés.

RFC 3632 a ensuite donné à l’annulation une expression RRP, sans créer un nouveau verbe. Cette économie de syntaxe rendait l’état indispensable. Le demandeur ne pouvait retirer sa demande qu’avant l’approbation ou le refus explicite du sponsor, ou avant la décision implicite déclenchée par le délai du registre.

L’horloge faisait donc partie du sens, même si elle n’apparaissait pas dans la ligne. À 10 h 00, le message pouvait être une annulation valable. Après la fermeture de l’état en attente, les mêmes octets ne pouvaient plus produire cette transition. Un journal sans état antérieur et sans base de temps peut montrer qu’un message est arrivé sans montrer ce qu’il pouvait encore accomplir.

Cette frontière devient irréversible quand les données de session expirent, que le rapport est agrégé ou qu’un transfert ultérieur remplace le dernier état. Il faut préserver le demandeur, le sponsor, l’heure serveur, la politique de délai, l’événement qui ferme la fenêtre et les états avant/après au moment où ils existent.

Le succès du protocole ne parle qu’au nom du protocole

L’exemple d’annulation se termine par 200 Command completed successfully. C’est une preuve utile : le serveur RRP annonce avoir exécuté la commande. Le problème commence lorsqu’un tableau de bord élargit le sujet de cette preuve.

Le code 200 ne dit pas que le titulaire du domaine a demandé l’annulation. Il ne vérifie pas l’autorisation interne chez le registrar. Il n’affirme pas qu’un humain a compris la conséquence, qu’aucune nouvelle demande n’a suivi, ou que la délégation DNS a changé. Il n’est pas une observation de service.

Chaque niveau a son autorité. Le registrar connaît son processus client ; le registre tient l’état de parrainage ; le DNS publie une délégation ; les sondes observent une résolution et une disponibilité. Une organisation peut relier ces preuves, mais ne doit pas donner à la réponse du registre la voix de toutes les autres.

C’est l’apport pratique de On Authority and Belief de Lu Heng : demander qui émet l’assertion, sur quel objet et jusqu’où s’étend son mandat. « Commande traitée » est une assertion forte dans son périmètre. Elle devient fragile lorsqu’on la renomme « consentement établi ».

EPP a rendu la distinction plus visible, pas automatique

Le protocole EPP ultérieur a choisi une autre exposition. RFC 5731 distingue request, cancel, approve, reject et query. Une réponse de transfert peut montrer le client demandeur, la date de demande, le client agissant, la date d’action et l’état en attente. RFC 5730 ajoute des identifiants de transaction côté client et côté serveur.

Cette explicitation améliore la preuve. Elle réduit le risque qu’un analyste transforme toute valeur négative en refus. Elle facilite aussi le rapprochement entre deux journaux. Mais le champ ne se conserve pas tout seul. L’identifiant peut être perdu au passage vers une plateforme d’observabilité ; l’horloge peut dériver ; le registrar demandeur n’est toujours pas le titulaire ; une réponse EPP ne montre pas la publication DNS.

RFC 3730 documente une génération antérieure d’EPP. Ces textes permettent une comparaison de conception, non une affirmation sur le calendrier ou la conformité d’un registre nommé. La règle de Lu Heng dans Running Code Primary reste nécessaire : vérifier ce que le système exécuté a réellement retenu et produit.

Un code d’encodage ne décide pas de l’identité

RFC 3632 a ajouté le code 510 pour signaler un encodage invalide d’un nom lors d’une opération ADD ou MOD. RFC 5890 donnera plus tard un vocabulaire plus précis aux formes internationalisées.

Le résultat du parseur reste borné. Une forme acceptée a franchi un contrôle syntaxique et une politique du registre. Elle ne démontre ni droit sur un nom, ni identité d’une organisation, ni intention du déclarant, ni délégation, ni innocuité d’affichage. Une forme rejetée ne reçoit pas davantage un jugement universel ; elle échoue à une interface donnée.

La précision des codes est utile précisément lorsqu’on refuse de les surinterpréter. Le code 510 appartient à l’autorité du registre sur son entrée. Il ne devient pas l’arbitre de tous les conflits associés à la chaîne.

Enregistrer une adresse IPv6 n’est pas observer un service

RFC 3632 a également autorisé des adresses IPv6, sous forme complète ou comprimée, dans les objets de serveurs de noms. RFC 4291 décrit l’architecture d’adressage ; RFC 5952 recommandera ensuite une représentation textuelle canonique.

Quatre réalités doivent rester distinctes : la chaîne a une grammaire valide ; le registre a sauvegardé l’adresse ; la délégation la publie ; le serveur répond correctement depuis les réseaux pertinents. L’une peut être vraie pendant que l’autre ne l’est pas. Le mot « valide » doit toujours conserver son complément.

Une preuve opérationnelle réunit l’objet hôte, la zone parente ou racine, la vue de routage, les réponses DNS faisant autorité et des observations distribuées. Elle ne réduit pas ces surfaces à une unique case « IPv6 : oui ».

Le verrou 557 protégeait une autre surface de décision

Le code 557 signalait qu’un objet de serveur de noms associé à un domaine de premier niveau était verrouillé. La modification devait passer par une coordination hors bande avec le support du registre. Ce refus ne signifiait pas « changement impossible », mais « ce chemin et cet acteur ne possèdent pas seuls le pouvoir de le faire ».

La gestion actuelle de la zone racine par l’IANA est une surface différente. La présentation du service, le guide de gestion d’un TLD, les règles de consentement, les exigences techniques des serveurs de noms et l’API RZMS séparent identité, permission, consentement, contrôle technique, mise en œuvre et vérification.

Ces procédures contemporaines ne prouvent rien sur une transaction RRP historique. Elles montrent pourquoi un état d’objet dans un registre ne peut pas certifier une publication racine. Lorsqu’un même serveur sert plusieurs TLD, le consentement d’autres parties peut entrer en jeu ; quand un test technique passe, il reste un test de base, pas une garantie universelle de service.

Concevoir un reçu qui conserve la relation

Le minimum probant n’est pas une charge utile infinie. Il s’agit d’un lien exportable entre version du protocole, session authentifiée, identifiant client, rôle du demandeur, sponsor courant, objet, heure de demande, état antérieur, commande, politique de délai, règle d’autorisation, réponse, état ultérieur, avis hors bande et décision finale.

Cette architecture rejoint le Minimum Initial Specification : rendre portable un noyau commun sans confisquer les décisions ultérieures. Le registre n’a pas à devenir l’autorité du consentement client ou de la disponibilité DNS ; il doit rendre son propre acte corrélable.

Avec les Reality Layers, la présentation devient elle aussi disciplinée. La commande symbolique, l’autorisation institutionnelle, l’état du registre, la publication DNS et l’expérience utilisateur peuvent converger. Aucun niveau ne doit être utilisé pour masquer l’absence d’un autre.

Le journal initial semblait complet parce qu’aucun caractère n’y manquait. Il était pourtant incapable de dire qui avait exercé le pouvoir. La leçon de RFC 3632 tient dans cette contradiction : la fidélité au message n’est pas encore la fidélité à l’acte.

Sources

  1. RFC 3632 — VeriSign Registry Registrar Protocol Version 2.0.0
  2. RFC 3632, version texte
  3. Fiche RFC Editor de RFC 3632
  4. Dossier IETF Datatracker de RFC 3632
  5. Historique IETF de RFC 3632
  6. Recherche d’errata de RFC 3632
  7. RFC 2832 — Registry Registrar Protocol 1.1
  8. RFC 3375 — Exigences génériques de protocole registre–registrar
  9. RFC 3730 — Extensible Provisioning Protocol
  10. RFC 5730 — Extensible Provisioning Protocol
  11. RFC 5731 — Mappage des domaines EPP
  12. RFC 5732 — Mappage des hôtes EPP
  13. RFC 4291 — Architecture d’adressage IPv6
  14. RFC 5952 — Représentation textuelle IPv6
  15. RFC 5890 — Définitions IDNA
  16. IANA — Gestion de la zone racine
  17. IANA — Gérer un domaine de premier niveau
  18. IANA — Obtenir le consentement pour un changement de zone racine
  19. IANA — Exigences techniques des serveurs de noms
  20. IANA — API du système de gestion de la zone racine
  21. Lu Heng — On Authority and Belief
  22. Lu Heng — On Reality Layers
  23. Lu Heng — Running Code Primary
  24. Lu Heng — Minimum Initial Specification