Mon blog

Le protocole IRIS d'accès aux informations dites « sociales » qui sont stockées dans un registre, par exemple un registre d'adresses IP, est défini indépendemment du schéma des données stockées. Il faut donc le compléter, pour chaque registre, par un schéma indiquant comment sont structurées les données. Notre RFC le fait pour les registres de noms de domaine.

Comme tous les schémas IRIS, ce document utilise le langage W3C Schema pour spécifier les éléments XML qui peuvent être présents dans les requêtes au serveur IRIS et dans ses réponses. Le schéma a reçu le nom de DREG (Domain Registry). La section 3 liste en langue naturelle les éléments possibles de DREG, la section 4 contenant le schéma formel.

Par exemple, l'élément <findDomainsByName> (section 3.1.3) permet des interogations analogues à celles de whois en interrogeant le registre sur les données liées à un domaine dont on connait le nom.

Mais il contient aussi des requêtes qui ne sont pas possibles avec tous les serveurs whois comme <findDomainsByContact> (section 3.1.2) qui permet de retrouver tous les domaines d'une personne ou d'une organisation donnée (très intrusive, cette requête ne sera probablement jamais disponible publiquement).

Et les réponses ? La section 3.2.2 décrit la forme d'un élément <domain>. Cet élément contient les informations associées à un domaine comme ses serveurs de noms, sa date de création ou son état (status). Les états possibles sont énumérés, on y trouve, par exemple, reservedDelegation (réservé mais pas publié dans le DNS, un état qui n'existe pas aujourd'hui dans .fr mais qui peut être présent dans d'autres TLD).

Il faut noter que la liste des états possibles n'est pas la même qu'avec EPP (RFC 4931), cela serait trop simple...

D'autres types d'objet peuvent être stockés par le registre et interrogés via IRIS, comme les contacts (les personnes ou organisations responsables d'un domaine), traités en section 3.2.4.

Ce schéma DREG ne semble pas encore utilisé dans aucun serveur IRIS publiquement accessible.

Emprunté à l'annexe A du RFC, voici un exemple de requête IRIS/DREG :

<?xml version="1.0"?>
<request xmlns="urn:ietf:params:xml:ns:iris1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
  <searchSet>
    <lookupEntity
      registryType="urn:ietf:params:xml:ns:dreg1"
      entityClass="domain-name"
      entityName="example.com" />
  </searchSet>
</request>

et la réponse possible d'un serveur IRIS :

<?xml version="1.0"?>
<iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <iris:resultSet>
    <iris:answer>
      <domain xmlns="urn:ietf:params:xml:ns:dreg1"
        authority="iana.org" registryType="dreg1"
        entityClass="domain-handle" entityName="example-com-1">

        <domainName>example.com</domainName>
        <domainHandle>tcs-com-1</domainHandle>

        <nameServer iris:referentType="host" authority="iana.org"
          registryType="dreg1" entityClass="host-handle"
          entityName="research7" />
        <nameServer iris:referentType="host" authority="iana.org"
          registryType="dreg1" entityClass="host-handle"
          entityName="nsol184" />

        <technicalContact iris:referentType="contact"
          authority="iana.org" registryType="dreg1"
          entityClass="contact-handle" entityName="dbarton" />

        <status>
          <assignedAndActive denied="true" />
        </status>

        <registry iris:referentType="registrationAuthority"
          authority="com" registryType="dreg1"
          entityClass="contact-handle" entityName="VGRS" />
        <initialDelegationDateTime xsi:nil="true"/>
        <iris:seeAlso iris:referentType="ANY" authority="iana.org"
          registryType="dreg1" entityClass="local"
          entityName="notice"  />
      </domain>
    </iris:answer>
  </iris:resultSet>
</iris:response>