À l’origine, il était possible d’identifier les proprié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 (Registration Data Access Protocol), qui devrait prochainement devenir le successeur du Whois.

Qu’est-ce que le Registration Data Access Protocol (RDAP) ?

Le Registration Data Access Protocol (RDAP) a été conçu par un groupe de travail de l’Internet Engineering 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 propriétés et l’application sont décrites dans divers Request for Comments (RFC 7480-7484 et RFC 8056). Le RDAP apporte la possibilité d’accéder à des informations supplémentaires sur les ressources Internet élémentaires comme :

  • Le nom de domaine
  • L‘adresse IP
  • L‘Autonomous System Number (ASN)

Le RDAP permet également d’accéder aux entrées connexes. Pour cela, l’alternative à Whois fournit la base pour les demandes de renseignements aux différents bureaux d’enregistrement de domaine, qui saisissent dans leurs bases de données des informations telles que les coordonnées du propriétaire du domaine, les coordonnées pour tout administrateur (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’implémenter 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 techniques actuelles du Web.

Par exemple, le protocole de requête n’est pas capable de travailler avec l’encodage et ne prend pas en charge les polices non latines. Un autre inconvé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églementé. Par exemple, même les utilisateurs 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 Information Service) ont apporté des premières améliorations, mais n’ont pas pu s’imposer comme une des réelles alternatives à Whois. Après de longues discussions au sein de la communauté de l’ICANN sur la nécessité d’un développement 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 Corporation for Assigned Names and Numbers) a initié un vote mondial afin de décider si le WHOIS devait être officiellement remplacé par RDAP. Le nombre de votes nécessaires a été atteint et la décision a été prise d’imposer officiellement le passage à RDAP : à partir de janvier 2025, les registraires et bureaux d’enregistrement DNS ne seront plus obligés de prendre en charge le WHOIS.

Comment fonctionne RDAP ?

Pour mettre en œuvre RDAP, il est important de comprendre comment le protocole fonctionne, 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’implémentation de base du protocole. Il existe de plus d’autres RFC décrivant des extensions du protocole RDAP. Nous expliquons ci-dessous le déroulement global du protocole via HTTPS, tel qu’il est décrit dans le RFC 7840.

Conseil

Afin de faciliter la mise en œuvre du protocole pour les développeurs, l’ICANN met à disposition un guide d’implémentation RDAP.

Rôle du client :

L’implémentation 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 transmettre 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 accompagné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’implémentation est un peu plus complexe, car le serveur doit gérer divers scénarios spécifiques. 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 transmettre les données du propriétaire demandées, tandis que pour les requêtes HEAD, il doit signaler si des données sont disponibles 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 satisfaire la demande parce que les données demandées ne sont pas disponibles, il doit renvoyer le code de statut 404 (Not Found). Si les données demandées sont disponibles mais que le serveur choisit de ne pas répondre pour d’autres raisons, il doit utiliser un code de statut correspondant à la plage 400. Les requêtes contenant des erreurs, qui ne peuvent donc pas être considé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 informations supplémentaires peuvent être incluses dans le corps de l’entité HTTP.

Pour des informations plus précises sur le fonctionnement, la sécurité et les possibilités d’extension du protocole, vous pouvez vous adresser aux RFC correspondants :

Quelles sont les différences entre le Registration 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érieusement pris en considération les points faibles de l’ancien protocole et s’est donc concentré sur la sécurité, la structuration et l’internationalisation dans le développement du nouveau protocole de requête. L’alternative à Whois se caractérise ainsi par les innovations suivantes :

  • Sémantique structurée des requêtes et des réponses (y compris les messages d’erreur standardisés)
  • Accès sécurisé aux coordonnées demandées (par exemple via HTTPS)
  • Évolutivité (par exemple, possibilité d’ajouter des éléments en aval)
  • Mécanisme d’amorçage ou « Bootstrapping » (permettant d’identifier le serveur DNS faisant autorité pour une requête)
  • Transmission standardisée des requêtes
  • Basé Web (HTTP) et compatible REST
  • Conversion simple des données de sortie
  • Possibilité d’accorder un accès différencié aux données de contact

Le Registration Data Access Protocol s’avère donc beaucoup plus flexible que son prédécesseur sur beaucoup de points : alors que Whois est lié à TCP et au port TCP spécifique (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 standardisé et lisible par une machine. De cette façon, l’alternative à Whois offre d’une part une plus grande liberté dans la récupération des données et d’autre part simplifie la programmation des services de requête qui peuvent communiquer avec différents bureaux d’enregistrement et produire les données demandées dans différentes langues.

RDAP Whois
Basé sur HTTP Basé sur du texte
Format JSON standardisé Aucun système de codage
Les données de sortie sont lisibles par les machines et facilement traduisibles Les données de sortie sont en texte clair et ne peuvent donc pas être traitées automatiquement sans difficulté
Réponses transmises automatiquement aux autres bureaux d’enregistrement Les réponses ne contiennent pas d’autres informations du registre
Possibilité de définir des droits d’accès pour différents groupes Accès différencié aux données impossible
Nom de domaine
Votre domaine en un clic
  • Domaine .eu ou .fr + éditeur de site gratuit pendant 6 mois
  • 1 certificat SSL Wildcard par contrat
  • Boîte email de 2 Go

L’option de différenciation des droits d’accès encore en discussion

Une des nouvelles fonctions importantes qui a été implémentée dans le Registration Data Access Protocol est sans aucun doute la possibilité de définir différents droits d’accès pour chaque groupe d’utilisateur. De cette façon, le registre peut contrôler en détail qui peut accéder à certaines données. Par exemple, il est concevable d’accorder un accès limité aux utilisateurs anonymes alors que les utilisateurs authentifiés peuvent visualiser l’ensemble complet des données. À ce niveau, cependant, de nombreuses personnes responsables estiment qu’une clarification s’impose.

Il y a notamment la question de savoir comment traiter avec les enquêteurs et procureurs, par exemple, qui souhaitent souvent garder l’anonymat tout en réclamant un accès total. De plus, il n’existe aucune directive permettant de déterminer si, dans un tel accès, l’accès aux données du nom de domaine peut être accordé au-delà des frontières nationales. En attendant, la protection des données des utilisateurs et la confiance des opérateurs qui enregistrent leur nom de domaine sont primordiales. En effet, la nouvelle technologie 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 obligatoire de l’ICANN à la fin 2016. L’organisation prévoit de faire appliquer l’alternative à Whois par le biais de contrats avec les bureaux d’enregistrements et les fournisseurs.

Cet article vous a-t-il été utile ?
Aller au menu principal