Re­gis­tra­tion Data Access Protocol (RDAP) : l’al­ter­na­tive à Whois

À l’origine, il était possible d’iden­ti­fier les pro­prié­taires d’un domaine à l’aide des services Whois, qui s’appuient sur le protocole du même nom. En 2015, l’IETF et l’ICANN ont défini le premier RFC du protocole RADP (Re­gis­tra­tion Data Access Protocol), qui devrait pro­chai­ne­ment devenir le suc­ces­seur du Whois.

Qu’est-ce que le Re­gis­tra­tion Data Access Protocol (RDAP) ?

Le Re­gis­tra­tion Data Access Protocol (RDAP) a été conçu par un groupe de travail de l’Internet En­gi­nee­ring Task Force (IETF). Après une phase de projet de près de quatre ans, la première version du profil de protocole (1.0) a été publiée le 26 juillet 2016, dont les pro­prié­tés et l’ap­pli­ca­tion sont décrites dans divers Request for Comments (RFC 7480-7484 et RFC 8056). Le RDAP apporte la pos­si­bi­lité d’accéder à des in­for­ma­tions sup­plé­men­taires sur les res­sources Internet élé­men­taires comme :

• Le nom de domaine
• L‘adresse IP
• L‘Au­to­no­mous System Number (ASN)

Le RDAP permet également d’accéder aux entrées connexes. Pour cela, l’al­ter­na­tive à Whois fournit la base pour les demandes de ren­seig­ne­ments aux dif­fé­rents bureaux d’en­re­gis­tre­ment de domaine, qui sai­sis­sent dans leurs bases de données des in­for­ma­tions telles que les coor­don­nées du pro­prié­taire du domaine, les coor­don­nées pour tout ad­mi­nis­tra­teur (Admin-C) ou même l’adresse du serveur de noms utilisé.

Pourquoi le RDAP a été développé ?

Dès 1982, l’IETF a publié le protocole Whois afin d’im­plé­men­ter un service de requête pour ce qui à l’époque se nommait ARPANET. Cependant, le fait qu’il soit encore utilisé après plus d’un quart de siècle (aujourd’hui pour les requêtes sur Internet) est depuis longtemps un problème pour de nombreux experts. En effet, la critique la plus virulente est que Whois ne répond plus aux exigences tech­niques actuelles du Web.

Par exemple, le protocole de requête n’est pas capable de tra­vail­ler avec l’encodage et ne prend pas en charge les polices non latines. Un autre in­con­vé­nient majeur est que l’accès aux données du domaine n’a pas lieu via une connexion sécurisée et n’est pas ré­gle­menté. Par exemple, même les uti­li­sa­teurs anonymes peuvent avoir un accès complet et obtenir les adresses postales et emails.

Des projets tels que l’extension Whois++ ou le protocole Denic IRIS (Internet Registry In­for­ma­tion Service) ont apporté des premières amé­lio­ra­tions, mais n’ont pas pu s’imposer comme une des réelles al­ter­na­tives à Whois. Après de longues dis­cus­sions au sein de la com­mu­nauté de l’ICANN sur la nécessité d’un dé­ve­lop­pe­ment plus poussé, le rapport de sécurité SAC 051 du SSAC (Security and Stability Advisory Commitee) de septembre 2011 a donné l’impulsion décisive pour mettre en place le groupe de travail RDAP.

En janvier 2023, l’ICANN (Internet Cor­po­ra­tion for Assigned Names and Numbers) a initié un vote mondial afin de décider si le WHOIS devait être of­fi­ciel­le­ment remplacé par RDAP. Le nombre de votes né­ces­saires a été atteint et la décision a été prise d’imposer of­fi­ciel­le­ment le passage à RDAP : à partir de janvier 2025, les re­gis­traires et bureaux d’en­re­gis­tre­ment DNS ne seront plus obligés de prendre en charge le WHOIS.

Comment fonc­tionne RDAP ?

Pour mettre en œuvre RDAP, il est important de com­prendre comment le protocole fonc­tionne, tant du côté client que du côté serveur. Pour cela, il est utile de consulter les RFC 7480 à 7484, qui décrivent en détail l’im­plé­men­ta­tion de base du protocole. Il existe de plus d’autres RFC décrivant des ex­ten­sions du protocole RDAP. Nous ex­pli­quons ci-dessous le dé­rou­le­ment global du protocole via HTTPS, tel qu’il est décrit dans le RFC 7840.

Rôle du client :

L’im­plé­men­ta­tion de RDAP du côté client n’est pas du tout complexe. RDAP est basé sur HTTP et utilise donc les méthodes de requête HTTP pour trans­mettre les données. Les clients peuvent envoyer des requêtes au serveur à l’aide des méthodes GET et HEAD. Les requêtes GET et HEAD doivent être ac­com­pag­nées d’un en-tête « Accept » qui spécifie les types de fichiers JSON acceptés par le client.

Rôle du serveur :

Côté serveur, l’im­plé­men­ta­tion est un peu plus complexe, car le serveur doit gérer divers scénarios spé­ci­fiques. En cas de réussite de la requête, le serveur doit renvoyer les données demandées dans le format requis tout en indiquant le code d’état HTTP 200 (OK). Pour les requêtes GET, le serveur doit trans­mettre les données du pro­prié­taire demandées, tandis que pour les requêtes HEAD, il doit signaler si des données sont dis­po­nibles pour ce domaine.

Si le serveur sait où trouver les données demandées mais ne les détient pas, il doit répondre avec l’un des codes de statut 301, 302, 303 ou 307. L’URL où se trouvent les données est alors renvoyée via l’en-tête HTTP « Location ».

Dans le cas où le serveur ne peut pas sa­tis­faire la demande parce que les données demandées ne sont pas dis­po­nibles, il doit renvoyer le code de statut 404 (Not Found). Si les données demandées sont dis­po­nibles mais que le serveur choisit de ne pas répondre pour d’autres raisons, il doit utiliser un code de statut cor­res­pon­dant à la plage 400. Les requêtes contenant des erreurs, qui ne peuvent donc pas être con­si­dé­rées comme des requêtes RDAP valides, doivent être traitées avec un code d’état 400 (Bad Request). Dans ce dernier cas, des in­for­ma­tions sup­plé­men­taires peuvent être incluses dans le corps de l’entité HTTP.

Pour des in­for­ma­tions plus précises sur le fonc­tion­ne­ment, la sécurité et les pos­si­bi­li­tés d’extension du protocole, vous pouvez vous adresser aux RFC cor­res­pon­dants :

• RFC 7840 : fonc­tion­ne­ment HTTP
• RFC 7841 : sécurité
• RFC 7842 : format de requête
• RFC 7843 : réponses JSON
• RFC 7844 : trouver un serveur qui fait autorité

Quelles sont les dif­fé­rences entre le Re­gis­tra­tion Data Access Protocol et Whois ?

RDAP s’avère être à bien des égards une version améliorée de Whois. Le groupe de travail de l’IETF a sé­rieu­se­ment pris en con­si­dé­ra­tion les points faibles de l’ancien protocole et s’est donc concentré sur la sécurité, la struc­tu­ra­tion et l’in­ter­na­tio­na­li­sa­tion dans le dé­ve­lop­pe­ment du nouveau protocole de requête. L’al­ter­na­tive à Whois se ca­rac­té­rise ainsi par les in­no­va­tions suivantes :

• Sé­man­tique struc­tu­rée des requêtes et des réponses (y compris les messages d’erreur stan­dar­di­sés)
• Accès sécurisé aux coor­don­nées demandées (par exemple via HTTPS)
• Évo­lu­ti­vité (par exemple, pos­si­bi­lité d’ajouter des éléments en aval)
• Mécanisme d’amorçage ou « Boots­trap­ping » (per­met­tant d’iden­ti­fier le serveur DNS faisant autorité pour une requête)
• Trans­mis­sion stan­dar­di­sée des requêtes
• Basé Web (HTTP) et com­pa­tible REST
• Con­ver­sion simple des données de sortie
• Pos­si­bi­lité d’accorder un accès dif­fé­ren­cié aux données de contact

Le Re­gis­tra­tion Data Access Protocol s’avère donc beaucoup plus flexible que son pré­dé­ces­seur sur beaucoup de points : alors que Whois est lié à TCP et au port TCP spé­ci­fique (43) en tant que protocole textuel, le RDAP utilise lui la norme Web HTTP ou HTTPS pour le transfert de données. Toutes les données sont livrées dans un format JSON stan­dar­disé et lisible par une machine. De cette façon, l’al­ter­na­tive à Whois offre d’une part une plus grande liberté dans la ré­cu­pé­ra­tion des données et d’autre part simplifie la pro­gram­ma­tion des services de requête qui peuvent com­mu­ni­quer avec dif­fé­rents bureaux d’en­re­gis­tre­ment et produire les données demandées dans dif­fé­rentes langues.

L’option de dif­fé­ren­cia­tion des droits d’accès encore en dis­cus­sion

Une des nouvelles fonctions im­por­tantes qui a été im­plé­men­tée dans le Re­gis­tra­tion Data Access Protocol est sans aucun doute la pos­si­bi­lité de définir dif­fé­rents droits d’accès pour chaque groupe d’uti­li­sa­teur. De cette façon, le registre peut contrôler en détail qui peut accéder à certaines données. Par exemple, il est con­ce­vable d’accorder un accès limité aux uti­li­sa­teurs anonymes alors que les uti­li­sa­teurs au­then­ti­fiés peuvent vi­sua­li­ser l’ensemble complet des données. À ce niveau, cependant, de nom­breuses personnes res­pon­sables estiment qu’une cla­ri­fi­ca­tion s’impose.

Il y a notamment la question de savoir comment traiter avec les en­quê­teurs et pro­cu­reurs, par exemple, qui sou­hai­tent souvent garder l’anonymat tout en réclamant un accès total. De plus, il n’existe aucune directive per­met­tant de dé­ter­mi­ner si, dans un tel accès, l’accès aux données du nom de domaine peut être accordé au-delà des fron­tières na­tio­nales. En attendant, la pro­tec­tion des données des uti­li­sa­teurs et la confiance des opé­ra­teurs qui en­re­gistrent leur nom de domaine sont pri­mor­diales. En effet, la nouvelle tech­no­lo­gie du RDAP n’a pas pour but d’altérer cette confiance. Plusieurs registres ont déposé des recours contre la date limite de mise en œuvre obli­ga­toire de l’ICANN à la fin 2016. L’or­ga­ni­sa­tion prévoit de faire appliquer l’al­ter­na­tive à Whois par le biais de contrats avec les bureaux d’en­re­gis­tre­ments et les four­nis­seurs.