Mon blog

Un registre, par exemple un registre de noms de domaine, utilise parfois le protocole EPP pour la communication avec ses clients. Ce RFC décrit comment utiliser ce protocole pour informer les clients des périodes d'indisponibilité du registre, par exemple lors d'une opération de maintenance.

Aujourd'hui, un registre prévient de ses periodes d'indisponibilité prévues par divers moyens : courriers aux BE, messages sur des réseaux sociaux, page Web dédiée comme :

Chaque registre le fait de façon différente, il n'existe pas de règles communes, et le côté non-structuré de ces annonces fait qu'il faut une interventon humaine pour les analyser et les mettre dans un agenda. Et un BE peut devoir interagir avec de nombreux registres ! Notre RFC propose d'utiliser EPP (RFC 5730) pour ces annonces.

Donc, premier principe, puisqu'on va souvent manipuler des dates, les dates et heures seront toutes représentées en UTC et dans le format du RFC 3339. Ensuite, les annonces seront dans un élément XML <item>, de l'espace de noms urn:ietf:params:xml:ns:epp:maintenance-1.0 (enregistré à l'IANA). Parmi les sous-éléments de cet élément :

• id, un identificateur de l'évènement,
• systems, qui permettra de désigner les systèmes affectés,
• environment, pour dire si l'évènement concerne la production ou bien un banc de test,
• start et end, qui indiquent le début et la fin (prévue…) de l'évènement,
• et plusieurs autres éléments.

Un exemple d'évènement, une intervention sur le serveur EPP epp.registry.example de production, peut être :

<maint:item>
  <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id>
  <maint:systems>
    <maint:system>
      <maint:name>EPP</maint:name>
      <maint:host>epp.registry.example</maint:host>
      <maint:impact>full</maint:impact>
    </maint:system>
  </maint:systems>
  <maint:environment type="production"/>
  <maint:start>2021-12-30T06:00:00Z</maint:start>
  <maint:end>2021-12-30T07:00:00Z</maint:end>
  <maint:reason>planned</maint:reason>
  <maint:detail>
    https://www.registry.example/notice?123
  </maint:detail>
  <maint:tlds>
    <maint:tld>example</maint:tld>
    <maint:tld>test</maint:tld>
  </maint:tlds>
</maint:item>
    
  

On voit que le serveur EPP sera arrêté pendant une heure (<impact>full</impact> indiquant une indisponibilité totale) et que cela affectera les TLD .example et .test. Une telle information, étant sous une forme structurée, peut être analysée par un programme et automatiquement insérée dans un agenda, ou un système de supervision.

Les commandes EPP exactes, maintenant (section 4 du RFC). La commande <info> peut renvoyer maintenant un élément <maint:info> qui contient l'information de maintenance. Voici l'exemple du RFC. D'abord, la question du client, qui veut de l'information sur l'évènement 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 :

<info>
  <maint:info
    xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
    <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id>
  </maint:info>
</info>

  

Puis la réponse du serveur :

    
 <response>
    <result code="1000">
       <msg>Command completed successfully</msg>
    </result>
    <resData>
      <maint:infData
        xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
        <maint:item>
          <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6
          </maint:id>
          <maint:type lang="en">Routine Maintenance</maint:type>
          <maint:systems>
            <maint:system>
              <maint:name>EPP</maint:name>
              <maint:host>epp.registry.example
              </maint:host>
              <maint:impact>full</maint:impact>
            </maint:system>
          </maint:systems>
          <maint:environment type="production"/>
          <maint:start>2021-12-30T06:00:00Z</maint:start>
          <maint:end>2021-12-30T07:00:00Z</maint:end>
          <maint:reason>planned</maint:reason>
          <maint:detail>
            https://www.registry.example/notice?123
          </maint:detail>
          <maint:description lang="en">free-text
          </maint:description>
          <maint:description lang="de">Freitext
          </maint:description>
          <maint:tlds>
            <maint:tld>example</maint:tld>
            <maint:tld>test</maint:tld>
          </maint:tlds>
          <maint:intervention>
            <maint:connection>false</maint:connection>
            <maint:implementation>false</maint:implementation>
          </maint:intervention>
          <maint:crDate>2021-11-08T22:10:00Z</maint:crDate>
        </maint:item>
      </maint:infData>
    </resData>
    ...

  

Ici, le client connaissait l'identificateur d'une opération de maintenance particulière. S'il ne le connait pas et veut récupérer une liste d'événements :

<info>
  <maint:info
    xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
    <maint:list/>
  </maint:info>
</info>

  

Il récupérera alors une <maint:list>, une liste d'opérations de maintenance.

Le client EPP peut également être prévenu des maintenances par la commande <poll>, qui dote EPP d'un système de messagerie (RFC 5730, section 2.9.2.3). Ainsi, un message dans la boite aux lettres du client pourra être :

<response>
  <result code="1301">
    <msg>Command completed successfully; ack to dequeue</msg>
  </result>
<msgQ count="1" id="12345">
  <qDate>2021-11-08T22:10:00Z</qDate>
  <msg lang="en">Registry Maintenance Notification</msg>
</msgQ>
<resData>
  <maint:infData
    xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0">
    <maint:item>
      <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id>
      <maint:pollType>create</maint:pollType>
      <maint:systems>
        <maint:system>
          <maint:name>EPP</maint:name>
          <maint:host>epp.registry.example
          </maint:host>
          <maint:impact>full</maint:impact>
...

  

La section 5 du RFC décrit la syntaxe formelle de cette extension (en XML Schema). Elle est dans le registre IANA des extensions à EPP.

Et question mises en œuvre ? Apparemment, les registres gérés par GoDaddy et Tango envoient déjà ces informations de maintenance.