Greboca  

Blog de Stéphane Bortzmeyer  -  RFC 8543: Extensible Provisioning Protocol (EPP) Organization Mapping

 -  12 avril - 

L'industrie des noms de domaine est d'une grande complexité. Les utilisateurs s'y perdent facilement entre registres, bureaux d'enregistrement, hébergeurs DNS, revendeurs divers, sociétés qui développent des sites Web, prête-noms pour protéger la vie privée, etc. Cette complexité fait qu'il est difficile de savoir qui est responsable de quoi. Dans le contexte d'EPP, protocole d'avitaillement de noms de domaine (création, modification, suppression de noms), il n'y avait jusqu'à présent pas de moyen de décrire ces acteurs. Par exemple, l'ajout d'un enregistrement DS dépend d'actions de l'hébergeur DNS, qui n'est pas forcément le BE. Mais ces hébergeurs DNS n'étaient pas définis et connus. Désormais, avec ce nouveau RFC, on peut utiliser EPP pour l'avitaillement d'objets « organisation ».

EPP (RFC 5730) est le protocole standard d'avitaillement de noms de domaine, permettant à un client (en général le BE) de créer des objets dans un registre, en parlant au serveur EPP. EPP permettait déjà des objets de type « contact » RFC 5733, identifiant les personnes ou les organisations qui assuraient certaines fonctions pour un nom de domaine. Par exemple, le contact technique était la personne ou l'organisation à contacter en cas de problème technique avec le nom de domaine.

Désormais, avec notre nouveau RFC 8543, une nouvelle catégorie (mapping) d'objets est créée, les organisations. On peut ainsi utiliser EPP pour enregistrer l'hébergeur DNS d'un domaine (qui peut être le titulaire du domaine, mais ce n'est pas toujours le cas, ou qui peut être le BE, mais ce n'est pas systématique). Ce nouveau RFC décrit donc une extension à EPP, qui figure désormais dans le registre des extensions (cf. RFC 7451).

EPP utilise XML et tout ici va donc être spécifié en XML, avec un nouvel espace de noms XML, urn:ietf:params:xml:ns:epp:org-1.0, abrégé en org dans le RFC (mais rappelez-vous que le vrai identificateur d'un espace de noms XML est l'URI, pas l'abréviation). Le nouvel espace de noms est désormais dans le registre des espaces de noms.

La section 3 de notre RFC décrit les attributs d'une organisation (notez que le vocabulaire est trompeur : ils s'appellent attributs mais ne sont pas des attributs XML). Mais commençons par un exemple, décrivant le BE nommé « Example Registrar Inc. » :

registrar1362registrar1362-REPregistraroklinked1362okExample Registrar Inc.123 Example Dr.DullesVAUS+1.7035555555contact@organization.examplehttps://organization.examplesh8013sh8013sh8013ClientX1999-04-03T22:00:00.0ZClientX1999-12-03T09:00:00.0Z
Voyons maintenant quelques-uns des attributs possibles.

Une organisation a un identificateur, indiqué par l'élément XML , attribué par le registre (c'est registrar1362 dans l'exemple). Il a aussi un ou plusieurs rôles, dans l'élement XML . Un même acteur peut avoir plusieurs rôles (par exemple il est fréquent que les BE soient également hébergeurs DNS). Le rôle inclut un type, qui peut valoir :

  • registrar : BE, comme dans le cas ci-dessus,
  • reseller : revendeur, par exemple l'organisation à laquelle le titulaire du nom de domaine achète un domaine n'est pas toujours un « vrai » BE, ce peut être un revendeur,
  • privacyproxy : un prête-nom qui, en se mettant devant l'utilisateur, permet de protéger sa vie privée,
  • et enfin dns-operator, l'hébergeur DNS.
D'autres types pourront apparaitre dans le futur, ils sont indiqués dans un registre IANA, des nouveaux types seront ajoutés en suivant la procédure « Examen par un expert » du RFC 8126.

Notez qu'au début du travail à l'IETF sur cette extension, seul le cas des revendeurs était prévu. Après des discussions sur l'importance relative des différents acteurs, il a été décidé de prévoir d'autres types que les seuls revendeurs.

Il y a aussi dans l'objet un ou plusieurs état(s), , qui peut valoir notamment :

  • ok, l'état normal, celui du BE dans l'exemple ci-dessus,
  • terminated, quand l'organisation va être retirée de la base et ne peut plus être utilisée (c'est le cas d'un BE qui n'est plus accrédité),
  • linked, qui indique que cette organisation est liée à d'autres objets, et ne doit donc pas être supprimée.

Il existe également un attribut , qui indique une relation avec une autre organisation. Par exemple, un revendeur aura une relation vers le BE dont il est revendeur. (Dans l'exemple plus haut, il n'y a pas de .)

La section 4 du RFC présente ensuite les commandes EPP qui peuvent être appliquées à ces objets « organisation ». permet au client EPP de savoir s'il pourra créer un objet, lui donnera les moyens de s'informer sur une oranisation (l'exemple en XML ci-dessus était le résultat d'une commande EPP ) et bien sûr une commande et une . Voici en action, pour créer un objet de rôle « revendeur » (notez que, cette fois, il a un parent) :

res1523reseller1523resExample Organization Inc.123 Example Dr.DullesVAUS+1.7035555555contact@organization.examplehttps://organization.examplesh8013sh8013

Le schéma complet, en syntaxe XML Schema, figure dans la section 5 du RFC.

Question mise en œuvre de cette extension EPP, Verisign l'a ajouté dans son SDK, disponible en ligne. CNNIC a une implémentation, mais non publique.

par Stéphane Bortzmeyer

Blog de Stéphane Bortzmeyer

Sur l'Internet, citoyen ou simple consommateur ?

 -  9 mai - 

Si vous regardez la télévision, ou écoutez les discours officiels, vous avez l'impression que l'Internet sert uniquement au commerce en ligne, et à (...)


RFC 8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

 -  3 mai - 

IPv6 dispose de trois mécanismes principaux pour l'allocation d'une adresse IP à une machine. L'allocation statique, « à la main », le système d'« (...)


RFC 8546: The Wire Image of a Network Protocol

 -  29 avril - 

Ce nouveau RFC de l'IAB décrit le très important concept de vue depuis le réseau (wire image), une abstraction servant à modéliser ce que voit, sur le (...)


RFC 8553: DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names

 -  19 avril - 

Autrefois, de nombreux services et protocoles Internet avaient « réservé » de manière informelle, et sans enregistrement de cette réservation, des (...)


RFC 8552: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves

 -  19 avril - 

Une convention répandue pour les noms de domaine est de préfixer les services par un tiret bas, par exemple _xmpp-client._tcp.jabber.ietf.org. (...)