Ce qui se passe dans un Bureau d’Enregistrement (BE)

Beaucoup de registres de noms de domaine ne vendent pas les noms en direct, il faut passer par un BE (Bureau d’Enregistrement, registrar en anglais). Par exemple, en France, l’article L45-4 du Code des Postes et Communications Électroniques spécifie que « L’attribution des noms de domaine est assurée par les offices d’enregistrement [registres, en fait], par l’intermédiaire des bureaux d’enregistrement ». Pour les TLD (Top Level Domain, domaines de premier niveau comme .com ou .pizza) qui sont sous contrat avec l’ICANN, ces contrats imposent également le passage par un BE. Que fait concrètement un BE ?

L’interface avec le registre

La partie la moins visible du travail du BE est de s’interfacer avec le registre. Cela peut se faire par le protocole EPP (Extensible Provisioning Protocol), une interface Web, ou encore une API (Application Programming Interface) réseau spécifique au registre. Les gros BE, qui traitent d’innombrables opérations chaque jour, préfèrent en général EPP, qui est normalisé¹ et est utilisé par beaucoup de registres. Les opérations peuvent ainsi être entièrement automatisées. Les plus petits BE se servent souvent d’une interface Web (lorsqu’elle existe) et leurs opérations sont en général manuelles. Un gros BE doit donc développer ou acquérir un logiciel client EPP². Le reste de cet article parlera surtout de ces BE de taille.

Comme chaque registre a des politiques spécifiques³, cette interface nécessite également de lire des documents comme, pour .fr, le Guide des Procédures.

L’interface avec l’utilisateur

Mais la partie la  plus visible du BE est évidemment celle qui fait face à l’utilisateur, à la personne qui va déposer puis gérer des noms de domaine. De même que le registre peut offrir plusieurs interfaces à ses BE (EPP, Web, API…), un BE peut avoir plusieurs interfaces pour ses clients. Il s’agit en général d’interfaces Web et d’API⁴.

Interfaces Web

Contrairement au registre, dont l’interface Web d’avitaillement (créer et gérer des noms de domaine) n’est accessible qu’à ses BE, une population réduite et formée, le BE doit concevoir une interface Web pour un très large public. C’est une tâche difficile, mettant en jeu des questions d’UX (User eXperience, le vécu des utilisateurs tout au long des opérations d’avitaillement), d’ergonomie, d’accessibilité à tous et toutes, même en présence de divers handicaps, etc.

La sécurité de ce système est un des points importants à traiter. Une des principales menaces qui guettent le ou la titulaire de noms de domaine est en effet le risque de détournement d’un nom, lorsqu’un malveillant arrive à prendre le contrôle d’un nom de domaine qui n’est pas le sien. Ce détournement peut être le résultat d’une imprudence du titulaire, mais il peut aussi survenir suite à une faille de sécurité au BE. Faire un système d’information fiable n’est pas une tâche aisée.

API du BE

Les BE de grande taille ayant souvent eux-mêmes des clients qui ont beaucoup de noms de domaine à gérer, ces BE fournissent souvent une API (Application Programming Interface), un service permettant à leurs clients de développer leurs propres programmes, évitant à ces clients de faire de fastidieuses opérations manuelles sur leurs nombreux noms. Pour donner un exemple concret, nous allons utiliser l’API du BE Gandi (sans que cela signifie une recommandation particulière pour ce BE⁵). Ces API ne sont pas standardisées, et il va falloir regarder la documentation de celle que vous voulez utiliser (ici, celle de Gandi). Comme la plupart des API, elle nécessite la création préalable d’une clé permettant l’authentification. Dans le cas de Gandi, cela se fait dans la rubrique « Sécurité » de votre compte au BE. Ensuite, les requêtes peuvent être faites dans n’importe quel langage de programmation : il faut faire des requêtes HTTP en ajoutant à l’en-tête un champ Authorization contenant la clé. Vous n’êtes plus ensuite limités que par votre imagination ; vous pouvez, via l’API, créer des domaines, changer les contacts, changer les serveurs de noms, etc. Des exemples détaillés figurent en annexe de cet article.

Autres activités du BE

Un BE ne se limite pas à ses interfaces techniques avec le registre et avec l’utilisateur. Il doit également assurer , entre autres, des fonctions d’aide aux utilisateurs (et c’est une tâche difficile et chronophage, quand le client appelle et dit juste « ça marche pas »).

Et il y a aussi des activités juridiques, par exemple pour faire face à des abus comme l’enregistrement de noms à des fins malveillantes.

Certaines registres exigent une accréditation des BE, c’est-à-dire que ceux-ci doivent démontrer des capacités (techniques, financières, etc) minimales. C’est par exemple le cas des BE accrédités par l’ICANN pour l’enregistrement dans les TLD ayant un contrat avec l’ICANN.

Et nous n’avons parlé ici que de l’enregistrement des noms de domaine mais il faut noter que la plupart des BE ont bien d’autres services, comme l’hébergement DNS (serveurs faisant autorité), l’hébergement de sites Web, le courrier électronique, la messagerie instantanée avec des services comme Matrix, etc.

Mais c’est plus compliqué que cela

Il faut d’abord expliquer qu’il y a deux sortes de registres de noms de domaine, les registres minces et les registres épais. Les registres épais sont ceux où l’ensemble des données « sociales » (nom et coordonnées du titulaire, des contacts, etc) sont au registre. Le BE peut avoir une copie des données qu’il a transmises mais ce n’est pas obligatoire. Quelqu’un qui veut obtenir des informations sur ces données sociales peut n’interroger que le registre, via par exemple une interface Web publique du registre, ou bien via les protocoles whois ou RDAP⁶. Le modèle du registre épais est le plus simple, conceptuellement. En outre, la très grande majorité des TLD, comme .fr, .nl ou .org, sont des registres épais.

Tout va bien et on peut donc ne pas tenir compte des registres minces ? Pas vraiment, car le plus gros TLD, .com est un registre mince, tout comme .net. Un BE a donc souvent besoin de gérer ces registres minces. Leur principe est que le registre ne connaît, pour un nom de domaine, que la liste des serveurs de noms, le nom du BE, et quelques métadonnées comme la date de création. Le reste, et notamment les données sociales, est au BE⁷. Cela impose notamment que le BE, lui aussi, offre des services d’interrogation comme whois ou RDAP⁸. Vous voyez bien cette séparation entre le registre et le BE lorsque vous utilisez un client whois. Ici, avec le client whois en ligne de commande, on se renseigne sur twitter.com :

% whois twitter.com

Domain Name: TWITTER.COM

Registrar WHOIS Server: whois.corporatedomains.com

Registrar: CSC Corporate Domains, Inc.  

Creation Date: 2000-01-21T16:28:17Z

…

Puis la réponse du registre est terminée et on a la réponse du BE, vers laquelle le client whois a été redirigé. Cette fois, on a l’identité du titulaire :

Domain Name: twitter.com

Creation Date: 2000-01-21T11:28:17Z

Registrant Name: Twitter, Inc.

Registrant Organization: Twitter, Inc.

Registrant Street: 1355 Market Street

Registrant City: San Francisco

Registrant Country: US

…

Un cas où cette séparation entre le registre et le BE se voit bien est lorsqu’une action juridique auprès du registre supprime ou modifie un domaine, sans que le BE soit prévenu. On peut alors voir les deux bases de données (registre et BE) donner des informations contraires.

En parlant de base de données, si le BE travaille avec un registre mince, il faut forcément qu’il ait une telle base de données locale, pour stocker les informations sociales (les contacts), que le registre ne connaît pas. Mais avec les registres épais ? En théorie, un BE pourrait alors tout sous-traiter au registre et se passer complètement de base de données. Cela serait plus simple pour le BE mais, en pratique, beaucoup de BE travaillent avec au moins un registre mince (typiquement .com) et, de toute façon, souhaitent avoir une base de données à eux, par exemple pour y mettre d’autres informations sur leurs clients. Il faut donc gérer une base de données (avec tout ce que cela implique, notamment les sauvegardes)  et s’assurer de sa synchronisation avec celle du registre. C’est d’ailleurs pour faciliter cette synchronisation que les registres ont souvent un mécanisme permettant au BE de récupérer la liste des domaines qu’il gère. On pourrait penser que c’est inutile, le BE connaissant quand même ses domaines ! Mais cela sert si un problème technique entraine une désynchronisation des deux bases.

Conclusion

Un BE, on le voit, n’est pas un pur intermédiaire qui se contente de relayer des demandes du client au registre. Il assure de nombreuses fonctions, souvent délicates.

Annexe : utilisation d’une API de BE

Cette annexe, destinée aux programmeurs, montre quelques exemples d’utilisation de l’API d’un BE, en l’occurrence Gandi. Pour en savoir plus, nous recommandons de consulter leur documentation. D’abord, on se crée une clé d’API via l’interface Web de Gandi. Dans les exemples, on supposera qu’elle vaut 12345 (les vraies sont évidemment plus complexes).

Commençons par le plus simple, récupérer la liste de mes domaines. L’intérêt d’une API HTTP est de pouvoir utiliser le langage de programmation de son choix. Voyons d’abord avec deux programmes en ligne de commande, curl et jq :

% curl  https://api.gandi.net/v5/domain/domains \

               --header "Authorization: Apikey 12345"

On récupère un long objet JSON. On va utiliser jq pour n’avoir que les noms des domaines :

 % curl --silent  https://api.gandi.net/v5/domain/domains  \

            --header "Authorization: Apikey $12345"  | jq '.[].fqdn'

"cyberstructure.fr"

"internautique.fr"

…

On a demandé à jq de parcourir tout le tableau JSON récupéré, puis d’extraire le champ fqdn.

Bien sûr, utiliser l’API pour un seul domaine n’a pas un grand intérêt. A priori, on fera des boucles sur des listes de domaines qu’on veut gérer.

Un exemple dans un autre langage ? On va utiliser Python,  sa bibliothèque standard json et la bibliothèque HTTP requests.

r = requests.get("https://api.gandi.net/v5/domain/domains",

                  headers={'Authorization’ : ‘12345’})

d = json.loads(r.text)

for domain in d:

    print(domain["fqdn"])

Un cas où l’API est très importante est pour la gestion de DNSSEC, technique de sécurisation du DNS par des signatures cryptographiques. Lorsqu’on ajoute ou retire des clés cryptographiques, on doit prévenir le registre, par l’intermédiaire du BE. Avec l’API de Gandi, il faut envoyer les informations sur la clé en JSON. Si on a créé des clés avec l’utilitaire dnssec-keygen, on peut, en Python, faire ainsi :

f = open(keyfile, 'r')

key = None

for line in f:

    match = re.search("^%s\.?\s+IN\s+DNSKEY\s+256\s+3\s+([0-9]+)\s+(.+)$" % domain,

                      line[:-1])

    if match:

        key = """{

        "algorithm": %s,

        "type": "zsk",

        "public_key": "%s"

        }""" % (match.group(1), match.group(2))

f.close()

if key is None:

    print("No ZSK key found in %s for domain %s" % (keyfile, domain),

          file=sys.stderr)

    sys.exit(1)

r = requests.post(Gandi.URL + "domain/domains/%s/dnskeys" % domain, data=key,

                  headers=[comme avant]

Notez qu’on utilise désormais la méthode HTTP POST et non plus GET. L’API Gandi suit les principes REST (REpresentational State Transfer) habituels. Pour supprimer une clé, c’est donc la méthode DELETE :

r = requests.delete(Gandi.URL + "domain/domains/%s/dnskeys/%s" % (domain, keyid),

                    headers=[comme avant]

^{1 – RFC 5730 et quelques autres.}

^{2 – Mais on ne peut pas tout faire avec EPP. Par exemple, le BE ne peut pas récupérer la liste de ses domaines, ni gérer les verrous des noms sensibles. Il doit donc utiliser une autre méthode, comme une API spécifique au registre.}

^{3 – Et à juste titre. Par exemple, les ccTLD (Country-Code Top Level Domain) comme .de ou .bf dépendent des lois et coutumes de leurs pays respectifs.}

^{4 – EPP pourrait être utilisé mais il est clairement trop complexe pour la plupart des clients.}

^{5 – Mais cette API est particulièrement bien documentée, avec de nombreux exemples dans différents langages de programmation.}

^{6 – Qu’on regroupe parfois sous l’acronyme RDDS (Registry Data Directory Service).}

^{7 – Ce modèle avait été choisi par l’ICANN dans l’espoir qu’il permettrait de traiter le problème de la vie privée des utilisateurs. L’idée était que les BE seraient concurrents sur la protection des données personnelles et que les utilisateurs soucieux de vie privée iraient vers les BE les plus protecteurs. En pratique, ce fut un échec, à la fois parce que certaines lois, comme le RGPD en Europe, imposent des protections minimales, et ne laissent pas le marché en proposer moins, et aussi parce qu’il est difficile pour l’utilisateur de choisir un BE, et que des promesses vagues « nous protégeons votre vie privée » ne sont pas évidentes à interpréter.}

^{8 – En pratique, l’ICANN impose aux BE qu’elle accrédite, de tels serveurs whois et RDAP, même s’ils ne travaillent qu’avec des registres épais. Ceci dit, vu l’importance de .com, la plupart des BE ont à gérer au moins un registre mince.}