Dans le cadre de la mise au point du protocole RDAP d'accès aux informations sur des
objets enregistrés, le groupe de travail à
l'IETF s'était livré à une intéressante étude sur
les objets enregistrés et accessibles via l'ancien protocole
whois. Cette étude a servi à mieux définir ce
qu'il fallait comme services dans RDAP, et à spécifier le format de
sortie de RDAP, normalisé dans le RFC 7483. Elle
a montré, sans surprises, une grande variabilité : si beaucoup
d'éléments d'information sont communs à un grand nombre de registres, c'est
souvent sous des noms différents. Cette variabilité est, selon les
goûts, un des charmes ou un des principaux défauts des registres de l'Internet.
L'étude qui a servi de base à ce RFC date de
2012 (section 3 de notre RFC, pour la méthodologie). Les données ont été récoltées via
whois mais aussi via les interfaces Web
d'interrogation des registres (à la fois registres de noms
de domaine et registres d'adresses
IP). Pour les TLD, le nom
nic.$TLD a été utilisé, 106 ccTLD ont permis de
récupérer de l'information sur ce nom, ainsi que 18
gTLD. Parfois, l'information a été vérifiée en
essayant d'autres noms que nic.$TLD. Les
capacités des serveurs whois interrogés étaient très variées
(cf. section 5.1). Par exemple, si tous permettent évidemment des
requêtes au sujet d'un domaine donné, certains permettent aussi des requêtes pour
un contact précis ou pour un BE particulier. Pour les
registres d'adresses IP, les cinq RIR ont été
interrogés.
La section 4 présente les résultats pour les RIR. On y voit déjà la
variété des étiquettes qui fait la beauté de whois. Ainsi, le nom de
l'organisation titulaire d'un préfixe IP est étiqueté
organisation à AfriNIC,
Owner à LACNIC et
org-name au RIPE-NCC. La
date d'enregistrement d'un contact est changed à
AfriNIC, RegDate à ARIN et
created à LACNIC. Un préfixe IP se nomme
inetnum à l'APNIC ou au RIPE-NCC, mais
NetRange ou CIDR à l'ARIN
(selon qu'il est IPv4 ou
IPv6 !) Voici un exemple à l'APNIC :
inetnum: 1.2.2.0 - 1.2.2.255
netname: KNET
descr: KNET Techonlogy (BeiJing) Co.,Ltd.
descr: 4,South 4th treet, Zhongguancun,Haidian District,Beijing
admin-c: ZX2975-AP
tech-c: WL1818-AP
country: CN
mnt-by: MAINT-CNNIC-AP
mnt-irt: IRT-CNNIC-CN
mnt-routes: MAINT-CNNIC-AP
status: ALLOCATED PORTABLE
changed: ipas@cnnic.cn 20150107
Certains éléments ne sont pas présents dans tous les RIR et ceux
qui le sont reçoivent, comme on vient de le voir, des noms
différents.
Et pour les registres de noms de domaine ?
C'est évidemment encore plus varié (au fait, les résultats bruts de la
collecte faite pendant l'étude sont disponibles
en ligne). Au total, 68 éléments différents ont été identifiés,
sous 550 étiquettes distinctes. Les auteurs du RFC les ont classé en
éléments publics et autres éléments. Les éléments publics sont ceux
qui sont mentionnés dans le document ICANN,
« gTLD
Applicant Guidebook » de 2012, ou bien dans les RFC
sur EPP,
RFC 5730, RFC 5731, RFC 5732 ou RFC 5733 (un choix
très contestable qui donne une sorte de privilège aux règles des TLD
régulés par le gouvernement états-unien).
Parmi les exemples d'éléments publics, on peut trouver évidemment
le nom de domaine (l'étiquette la plus fréquente étant
domain name mais cinq autres ont été trouvées)
suivi de la date de création (en général created
mais vingt-trois autres étiquettes sont possible, la deuxième plus
grande variété de vocabulaire). 95 % des registres
ont donc un élément « nom de domaine » (on peut se demander comment
font les 5 % restants...), 85 % une date de création, 77 % un statut
du domaine, etc. Par contre, « dernier transfert », le moins fréquent, n'est présent que
chez 3 % des registres.
On retrouve la même variété pour les titulaires et les
contacts. Aucun élément n'est présent dans la majorité des
registres (même pas l'adresse de courrier électronique). Ceux qui le sont ont des noms très variés. Ainsi, pour le contact technique, le téléphone dudit contact
est décrit par pas moins de dix étiquettes différentes.
Le cas des serveurs de noms est plus compliqué car, contrairement
aux contacts, le serveur de noms n'est pas forcément un objet de
première classe dans le modèle de données du registre : il peut être
un simple attribut du domaine. C'est pour cela que, dans le monde
EPP, le RFC 5732 n'est
pas mis en œuvre partout. Ainsi, alors que 92 % des registres
indiquent les serveurs de noms dans les réponses (sous 63 étiquettes
distinctes, un record, en partie dû à des mécanismes de nommage comme
nameserver N avec N indiquant le rang du serveur), tous ne permettent pas des requêtes whois directes sur un
serveur de noms.
Enfin, il y a les éléments « divers », ceux qui ne sont pas
spécifiés dans les règles ICANN ou dans les RFC sur EPP et qui
incluent, par exemple, l'URL d'un site Web
associé au domaine, un champ de commentaires
(remarks), une date d'anniversaire (six TLD sont
dans ce cas, probablement tous à l'AFNIC), un
identificateur de marque déposée, etc. La
section 6 de notre RFC suggère que des extensions au modèle de données de
RDAP pourraient s'inspirer de ces éléments divers, par exemple le
point de contact du NOC (pourquoi diable ne pas
se contenter du contact technique ?), le fait que l'identité du
titulaire soit masquée (ce qui est parfois noté, bien à tort,
anonymous), etc.
Il n'y a pas que le modèle de données (et la terminologie associée)
qui varie beaucoup d'un
registre à l'autre, il y a aussi le format de présentation. Les deux
les plus populaires sont clé:valeur et en bloc. Un exemple en
clé:valeur est donné par .org :
Domain Name:TV5.ORG
Creation Date: 1995-09-29T04:00:00Z
Updated Date: 2013-09-30T14:24:25Z
Sponsoring Registrar:Gandi SAS (R42-LROR)
...
Registrant Name:Thomas Derobe
Registrant Organization:TV5 Monde
Registrant Street: 131 avenue de Wagram
Un exemple de bloc par le registre de
.za :
Domain Name:
sab.co.za
Registrant:
The South African Breweries Limited
Email: domains@sabmiller.com
Tel: +27.118818414
Fax: +27.118818136
Registrant's Address:
P.O.Box 782178
2196 Sandton Sandown
ZA
Registrar:
Ascio
Relevant Dates:
Registration Date: 1997-05-06
Renewal Date: 2015-05-06
Domain Status:
Registered until renewal date
Mais il faut remarquer qu'on trouve de tout. Comment classer le
résultat du whois de
.jp ?
Domain Information:
a. [Domain Name] YAMAHA.CO.JP
g. [Organization] YAMAHA Corporation
l. [Organization Type] Corporation
m. [Administrative Contact] HN050JP
n. [Technical Contact] TT9781JP
p. [Name Server] ns1.dhs.jtidc.jp
p. [Name Server] ns2.dhs.jtidc.jp
s. [Signing Key]
[State] Connected (2016/03/31)
[Registered Date]
[Connected Date] 2010/08/02
[Last Update] 2015/04/01 01:12:19 (JST)
À noter également que onze registres envoient l'information autrement
qu'en anglais dans l'alphabet latin (le RFC, comme beaucoup de
documents écrits dans le milieu ICANN, confond langue et écriture et
écrit «
11 registries give local script responses. The WHOIS information
of other registries are all represented in English. »).
Bref, ce RFC illustre bien une des motivations principales du projet RDAP : normaliser la sortie du
serveur, de façon à faciliter les traitements automatiques.
