Traditionnellement, pour trouver de l'information sur un objet
enregistré dans une base de données publique de l'Internet
(nom de domaine, adresse
IP, etc), on
utilisait le protocole whois (qui avait été normalisé, longtemps après sa création, dans le
RFC 3912). Ce protocole a de grosses limitations
(décrites au paragraphe suivant) et plusieurs tentatives ont déjà
été faites pour le remplacer. Le nouveau venu, RDAP (Registration Data
Access Protocol), va-t-il mieux réussir que les
précédents ?
Attention, comme le note le document SAC-051 « SSAC Report on Domain Name WHOIS
Terminology and Structure », le terme « whois » est
souvent employé incorrectement. Il désigne normalement un protocole
(celui normalisé dans le RFC 3912) mais est
également utilisé pour désigner un service (celui d'accès aux données
d'enregistrement) voire pour désigner les données elles-mêmes
(« informations WHOIS », terme erroné mais fréquent).
Voici un exemple d'utilisation de whois sur Unix, avec le logiciel client
GNU whois, pour avoir de l'information sur le domaine
reflets.info :
% whois reflets.info
Domain Name:REFLETS.INFO
Creation Date: 2010-12-23T13:46:11Z
Updated Date: 2014-12-12T17:24:31Z
Sponsoring Registrar:Gandi SAS (R191-LRMS)
...
Registrant Name:Antoine Champagne
Registrant Organization:
Registrant Street: Whois Protege / Obfuscated whois
Registrant Street: Gandi, 63-65 boulevard Massena
Registrant City:Paris
Registrant State/Province:
Registrant Postal Code:75013
Registrant Country:FR
Registrant Phone:+33.170377666
Registrant Email:ea208c9533d64ffbaa6ff82bdbf084d4-3087564@contact.gandi.net
Parmi les principales limites de whois :
- Aucun mécanisme d'authentification, donc pas de possibilité de
restreindre les données selon le client (certains registres utilisent
l'adresse IP du client pour donner des privilèges à certains
clients),
- Aucun mécanisme de confidentialité (ce point est lié au
précédent : comme tout est public actuellement, la confidentialité ne
servirait à rien),
- Aucun mécanisme standard pour fournir des options spécifiques à
la recherche,
- Aucune structuration des données : le client doit analyser des
dizaines de formats différents pour trouver ce qu'il cherche (certains
logiciels le font pour lui, comme Net::DRI mais ils sont rarement complets, il y a toujours un serveur whois
quelque part qui suit des règles différentes et non reconnues) ; même
chose pour les messages d'erreur (comme « entité non trouvée »),
- Aucune internationalisation : peut-on envoyer de
l'Unicode en réponse à un client et, si oui,
avec quel encodage ?
- Aucune façon normalisée d'adapter le résultat au lecteur (par
exemple envoyer une adresse en caractères chinois ou bien en
caractères latins selon le client),
- Aucun mécanisme standard pour trouver le serveur pertinent pour
un objet donné : chaque client whois utilise un truc particulier (par
exemple, GNU whois a une liste de serveurs, qu'on peut modifier en
éditant un fichier de configuration
/etc/whois.conf).
Cette liste est connue depuis longtemps. C'est ainsi que le RFC 3707 dressait déjà un cahier des charges d'un
bon successeur de whois.
En mai 2012, après pas mal de
discussions, l'IETF a créé le groupe de travail WEIRDS pour produire un
remplaçant à whois. Ce groupe WEIRDS publie aujourd'hui RDAP (Registration Data
Access Protocol), le nouveau protocole. Ses principes ? Modularité
(on peut utiliser plusieurs protocoles de transport, le langage
d'expression des requêtes est séparé de la définition du format des
réponses), et le respect des modes actuelles. Le premier transport
normalisé utilise REST et le premier format de
réponses est bâti sur JSON (RFC 7159). La requête RDAP avec REST+JSON équivalente à la
requête whois citée plus haut serait (cf. la documentation du service RDAP
expérimental de .info) :
% curl http://rdg.afilias.info/rdap/domain/reflets.info
{
"entities": [
{
"links": [
{
"href": "http://rdg.afilias.info/rdap/entity/AC12196-GANDI",
"rel": "self",
"type": "application/rdap+json",
"value": "http://rdg.afilias.info/rdap/entity/AC12196-GANDI"
}
],
"objectClassName": "entity",
"roles": [
"technical",
"billing",
"administrative",
"registrant"
],
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"Antoine Champagne"
],
[
"adr",
{},
"text",
[
"",
"",
"Whois Protege / Obfuscated whois",
"Paris",
"",
"75013",
"FR"
]
],
[
"email",
{},
"text",
"ea208c9533d64ffbaa6ff82bdbf084d4-3087564@contact.gandi.net"
],
[
"tel",
{
"type": "work"
},
"uri",
"tel:+33.170377666"
],
[
"tel",
{
"type": "fax"
},
"uri",
"tel:+33.143730576"
]
]
]
...
Les RFC qui forment la définition de RDAP sont :
- RFC 7482,
« Registration Data Access Protocol Query Format »,
explique comment former des requêtes RDAP, sous forme
d'URL.
- RFC 7483, « JSON Responses for the
Registration Data Access Protocol (RDAP) », décrit le format
des réponses du serveur RDAP, format qui utilise
JSON.
- RFC 7480, « HTTP usage in the
Registration Data Access Protocol (RDAP) », normalise
l'utilisation de HTTP pour transporter les requêtes et réponses
RDAP.
- RFC 7484,
« Finding the Authoritative Registration Data (RDAP)
Service », explique comment trouver le bon serveur
RDAP.
- RFC 7481, « Security Services for the
Registration Data Access Protocol », détaille les services
de sécurité de RDAP (en général fournis par
HTTP).
- RFC 7485, « Inventory and
Analysis of WHOIS Registration Objects », qui n'est pas à
proprement parler une partie de la définition de RDAP mais qui a servi
à spécifier RDAP.
RDAP remplacera-t-il whois ? C'est que whois en a eu, des
concurrents malheureux, et que tous sont bien oubliés
aujourd'hui. Dans l'ordre rétro-chronologique :
- IRIS (RFC 3981),
qui reposait sur XML et un protocole
spécifique. Trop compliqué, il a eu peu de déploiements
(DENIC avait un service IRIS mais y a renoncé).
- LDAP avait été sérieusement proposé comme
concurrent mais sans jamais de succès.
- rwhois (RFC 2167), le seul à avoir connu un réel
déploiement, à l'ARIN (voir la documentation).
- whois++ (RFC 1913).
En tout cas, RDAP est déjà largement mis en œuvre (dix implémentations
dont l'interopérabilité a été testée au cours de réunions IETF) même s'il n'y a
guère de déploiement en production pour l'instant.
L'exemple plus haut était pour trouver de l'information sur un
nom
de domaine. Mais RDAP marche aussi pour les adresses IP :
% curl http://rdap.apnic.net/ip/2001:dc7:dd01:0:218:241:97:42
{
"handle" : "2001:0DC7::/32",
"startAddress" : "2001:dc7::",
"endAddress" : "2001:dc7:ffff:ffff:ffff:ffff:ffff:ffff",
"name" : "CNNIC-CN-20040913",
"type" : "ALLOCATED PORTABLE",
"country" : "CN",
"parentHandle" : "2001:0C00::/23",
"entities" : [ {
"handle" : "IPAS1-AP",
"vcardArray" : [ "vcard", [ [ "version", { }, "text", "4.0" ], [ "fn", { }, "text", "CNNIC IPAS CONFEDERATION" ], [ "kind", { }, "text", "group" ], [ "adr", {
"label" : "No.4, Zhongguancun No.4 South Street,\\nHaidian District, Beijing"
}, "text", [ "", "", "", "", "", "", "" ] ], [ "tel", {
"type" : "voice"
}, "text", "+86-010-58813000" ], [ "tel", {
"type" : "fax"
}, "text", "+86-010-58813075" ], [ "email", { }, "text", "ipas@cnnic.cn" ] ] ],
...
C'est bien compliqué, tout ce JSON. Et si on
veut juste extraire certaines informations ? On peut utiliser un
client RDAP spécialisé, ou écrire soi-même un traitement, ou encore se
servir des
processeurs JSON tout faits comme
jq :
% curl -s http://rdap.apnic.net/ip/2001:dc7:dd01:0:218:241:97:42 | jq .country
"CN"
Questions mises en œuvre, on peut citer :
De bonnes lectures sur RDAP et le travail du groupe WEIRDS :
Et merci au dit Marc Blanchet pour sa relecture attentive de mon article.
