Le protocole RDAP marque un tournant pour l’accès aux données d’enregistrement des noms de domaine, remplaçant l’ancien service Whois. Cette mutation répond à des besoins concrets de structuration, d’internationalisation et de gestion des accès.
L’officialisation du basculement par ICANN début 2025 a accéléré les déploiements chez registres et registrars. Ces éléments appellent un repérage synthétique avant d’aborder les aspects techniques, pratiques et réglementaires.
A retenir :
- Accès structuré et normalisé aux données d’enregistrement au format JSON
- Contrôle d’accès granulaire et traçabilité conforme aux règles RGPD
- Fichier bootstrap centralisé pour l’indexation des serveurs RDAP
- Meilleure internationalisation et prise en charge des caractères non latins
Pourquoi RDAP remplace Whois dans l’écosystème des registres
Après ces repères, l’obsolescence du WHOIS apparaît clairement sur le plan technique et juridique. Le service Whois ne proposait ni format structuré ni mécanisme centralisé pour localiser les serveurs.
Le RDAP a été spécifié en 2015 à travers une série de RFC publiées par l’IETF, pour moderniser l’accès aux données. Selon l’IETF, ces RFC définissent précisément le format des requêtes et des réponses en JSON.
Fonctionnalité
Whois
RDAP
Format de réponse
Texte libre non structuré
JSON structuré et normalisé
Localisation serveur
Aucune méthode standard
Bootstrap IANA en JSON pour chaque TLD
Contrôle d’accès
Absence de gestion native
Mécanismes d’accès différencié et authentification
Internationalisation
Support limité des jeux de caractères
Prise en charge des polices non latines
Transport
Port 43 en clair
HTTP/HTTPS sécurisé
Avantages techniques :
- Réponses machine-readable facilitant l’automatisation
- Découverte centralisée des serveurs via bootstrap
- Contrôles d’accès adaptés aux exigences réglementaires
- Meilleure compatibilité avec noms IDN
« J’ai piloté la mise en place de RDAP chez notre registrar, et la normalisation a réduit les incidents d’intégration avec les outils tiers. »
Anne N.
Ce constat technique conduit naturellement à détailler les mécanismes de requêtes et de réponse du protocole RDAP. Comprendre ces mécanismes prépare l’examen des types d’objets et des formats JSON qui suivent.
Limites historiques du WHOIS pour l’internationalisation
Ce constat d’obsolescence met en lumière les contraintes du WHOIS face à l’internationalisation et aux formats modernes. Le WHOIS peinait à gérer correctement les jeux de caractères non latins et l’encodage.
Le passage au RDAP améliore la recherche globale parmi registrars et registres, plutôt que l’interrogation locale limitée du WHOIS. Selon l’AFNIC, cette meilleure harmonisation facilite les réponses pour les TLD nationaux et gTLD.
Principes fondateurs et conformité RGPD
Le RDAP intègre dès l’origine des principes de contrôle d’accès et de traçabilité pour respecter le RGPD. Les accès peuvent être différenciés entre anonymes et utilisateurs authentifiés.
Pour les registries comme AFNIC ou EURid, l’enjeu principal reste la conciliation entre transparence et protection des données personnelles. Ce point ouvre la nécessité de vérifier les formats et les types de requêtes.
Fonctionnement technique du RDAP et formats JSON
Comprendre ces mécanismes impose d’examiner précisément les formats de requêtes et les types d’objets traités par RDAP. Les requêtes s’effectuent via des URLs HTTP/HTTPS et retournent des objets JSON normalisés.
Selon RDAP.org, les requêtes suivent un schéma clair et les réponses contiennent des champs communs tels que objectClassName et events. Cette uniformité facilite l’intégration côté registrars.
Requête
Usage
domain/{nom_de_domaine}
Identification et métadonnées du domaine
ip/{adresse_ip}
Identification d’une adresse IPv4 ou IPv6
autnum/{ASN}
Identification d’un système autonome
nameserver/{serveur_de_nom}
Identification d’un serveur de noms DNS
entity/{id}
Identification d’une entité de contact
help
Accès à l’aide et profil de requêtes
Requêtes principales :
- domain/{nom_de_domaine} pour les recherches de domaines
- ip/{adresse_ip} pour les ressources réseaux
- entity/{id} pour contacts et organisations
- help pour le profil et la documentation
Les réponses JSON incluent des blocs communs tels que entities, events et status pour toutes les requêtes. Selon Andy Newton et Scott Hollenbeck, ces champs sont définis par la RFC 7483 pour assurer l’interopérabilité.
Un tutoriel visuel facilite la prise en main par les équipes techniques, en montrant des exemples curl et des retours JSON. Cet angle technique conduit naturellement aux impacts concrets pour registrars et utilisateurs finaux.
« L’adoption de RDAP chez notre équipe a rendu l’automatisation des requêtes beaucoup plus fiable qu’avec Whois. »
Marc N.
Structure des réponses et champs communs
Ce rappel sur les requêtes invite à détailler les champs présents dans chaque réponse RDAP et leurs usages. Les champs events et entities permettent la traçabilité des opérations liées à un objet.
Les registres doivent donc exposer des réponses conformes, tout en renseignant des notices légales et les statuts des objets. Selon l’ICANN, cette conformité est un prérequis contractuel pour les gTLD.
Outils et commandes pour interroger un serveur RDAP
Les opérateurs peuvent utiliser des clients RDAP ou des requêtes curl vers les serveurs publiés dans le bootstrap IANA. La commande curl renvoie un JSON directement exploitable par scripts et outils d’analyse.
Des clients CLI et bibliothèques existent pour intégrer RDAP dans les workflows des registrars et des services d’abuse. Cette disponibilité logicielle prépare l’adoption à grande échelle par les acteurs du marché.
Conséquences pour registrars, registres et utilisateurs
Une fois le protocole maîtrisé, viennent les conséquences pratiques pour registrars et registres, ainsi que les effets pour les utilisateurs finaux et les autorités. Les impacts concernent l’opérationnel, la conformité et les outils métiers.
Selon Gavin Brown, l’apparition de serveurs « Stealth RDAP » rend partielle la visibilité pour certains TLD, ce qui soulève des questions d’harmonisation à l’échelle globale. Les registries et registrars doivent adapter leurs politiques.
Acteurs majeurs comme Gandi, OVH, Verisign, Netim, BookMyName, Donuts et Nominet ont des implications différentes selon leurs catalogues et leurs obligations contractuelles. L’opérationnel varie selon la taille et la juridiction.
Impacts opérationnels :
- Mise en conformité des API et des réponses JSON
- Authentification et gestion des droits d’accès différenciés
- Surveillance des serveurs Stealth et complétude des registres
- Formation des équipes techniques et juridiques
« En tant que responsable technique, j’ai dû revoir les scripts d’abuse pour consommer des JSON RDAP standardisés. »
Léa N.
Sur la dimension vie privée, le RDAP facilite l’application des règles locales et du RGPD grâce à des accès restreints et traçables. Les utilisateurs bénéficient d’une meilleure clarté sur qui accède à quelles données.
Pour les enquêteurs et administrateurs réseau, RDAP conserve l’intérêt du Whois en offrant des réponses complètes sous une forme exploitable par machines. Selon ICANN, la migration vise à maintenir cette utilité tout en renforçant la conformité.
« À mon avis, la normalisation RDAP simplifiera la coopération entre registres et forces de l’ordre pour les enquêtes techniques. »
Paul N.
Ces implications pratiques confirment que la migration vers RDAP est un changement de fond, plus qu’un simple remplacement technique. L’adaptation des outils et des pratiques déterminera l’efficacité opérationnelle sur le long terme.
Source : ICANN, « Actualités de l’ICANN : lancement du RDAP en remplacement du WHOIS », ICANN, 27 janvier 2025 ; Andy Newton et Scott Hollenbeck, « Registration Data Access Protocol (RDAP) Query Format », IETF, mars 2015 ; Gavin Brown, « Stealth RDAP », PDF, juin 2024.
