RDAP : le WHOIS en JSON, et comment l'interroger avec curl

Quand on veut savoir à qui appartient un nom de domaine, quand il expire ou quels serveurs de noms il utilise, on pense à WHOIS. Le protocole date de 1982, il renvoie du texte libre dont chaque registre a sa propre mise en forme, et il faut un parseur sur mesure par extension. Son successeur s'appelle RDAP : les mêmes informations, en JSON, au-dessus de HTTPS. Voici comment l'interroger avec un simple curl, ce que contiennent les réponses, et les pièges à connaître.

Pourquoi WHOIS ne suffit plus #

WHOIS (RFC 3912) ouvre une connexion TCP sur le port 43, envoie un nom et reçoit du texte. Cela pose plusieurs problèmes :

• aucun format commun : les champs, les libellés et même les dates changent d'un registre à l'autre ;
• pas de chiffrement et pas de contrôle d'accès standardisé ;
• pas de moyen fiable de savoir quel serveur interroger pour une extension donnée ;
• peu de prise en charge des caractères non latins.

RDAP (Registration Data Access Protocol) reprend le même rôle avec les outils du web : requêtes HTTPS, réponses JSON, codes de retour HTTP, authentification possible. Il est normalisé par les RFC 7480 à 7484, mises à jour par les RFC 9082 et 9083 pour le format des requêtes et des réponses, et par la RFC 9224 pour la découverte des serveurs.

La première requête #

Prenons example.com, interrogé directement chez le registre de .com :

curl -s -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com

La réponse est un objet JSON. Les champs qui comptent :

• ldhName : le nom du domaine, en ASCII ;
• status : les statuts du domaine. Pour example.com : client delete prohibited, client transfer prohibited et client update prohibited, c'est-à-dire un domaine verrouillé chez son bureau d'enregistrement ;
• events : les dates. On y trouve registration (le 14 août 1995), expiration (le 13 août 2027) et last changed. Un dernier évènement, last update of RDAP database, indique la fraîcheur de la base du registre, pas celle du domaine ;
• nameservers : les serveurs de noms déclarés au registre ;
• secureDNS : l'état DNSSEC. Pour example.com, delegationSigned vaut true et l'enregistrement DS est fourni (algorithme 13, ECDSA P-256) ;
• entities : les contacts et le bureau d'enregistrement, avec des rôles (registrar, registrant, technical…), souvent expurgés ;
• rdapConformance et notices : les extensions respectées et les mentions légales.

Avec jq, on extrait l'essentiel en une ligne :

curl -s -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com |
jq -r '"expiration: " + (.events[] | select(.eventAction=="expiration").eventDate),
       "ns: " + ([.nameservers[].ldhName] | join(" ")),
       "dnssec: " + (.secureDNS.delegationSigned | tostring)'

Résultat obtenu le jour de la rédaction :

expiration: 2027-08-13T04:00:00Z
ns: ELLIOTT.NS.CLOUDFLARE.COM HERA.NS.CLOUDFLARE.COM
dnssec: true

Quel serveur interroger ? Le fichier « bootstrap » de l'IANA #

Il n'y a pas un serveur RDAP unique : chaque registre exploite le sien. L'IANA publie la correspondance extension → serveur dans un fichier JSON :

curl -s https://data.iana.org/rdap/dns.json | jq '.services | length'

Au 30 septembre 2026, ce fichier décrit 592 services couvrant 1 203 extensions. Deux conséquences pratiques. Les outils sérieux téléchargent ce fichier et le mettent en cache. Et pour un test rapide, le redirecteur rdap.org fait le travail à votre place, en répondant par une redirection HTTP 302 vers le bon registre :

curl -sL -H 'Accept: application/rdap+json' https://rdap.org/domain/example.org

(l'option -L suit la redirection ; ici, vers le serveur du registre de .org). C'est pratique, mais c'est un intermédiaire de plus, à ne pas mettre dans un système critique.

Les codes de retour #

C'est l'un des vrais avantages sur WHOIS : le résultat se lit dans le code HTTP, pas en cherchant une phrase dans du texte.

• 200 : le domaine existe et la réponse est dans le corps ;
• 404 : le domaine n'existe pas dans ce registre. C'est la façon la plus propre de tester la disponibilité d'un nom (avec la réserve que « absent du registre » n'est pas toujours « achetable » : certains noms sont réservés) ;
• 429 : trop de requêtes, il faut ralentir ;
• 403 / 401 : accès restreint, réservé à certains usages ou comptes.

for d in example.com ce-nom-n-existe-pas-12345.com; do
  code=$(curl -s -o /dev/null -w '%{http_code}' \
    -H 'Accept: application/rdap+json' \
    "https://rdap.verisign.com/com/v1/domain/$d")
  echo "$d $code"
  sleep 1
done

Un nom bidon renvoie bien 404 chez le registre de .com, et example.com renvoie 200. Notez le sleep 1 : voir plus bas.

Les registres ne répondent pas tous pareil #

Le format est commun, pas le contenu. En comparant les réponses de deux registres pour cet article :

• le registre de .com fournit des dates complètes (2027-08-13T04:00:00Z), le bloc secureDNS détaillé et peu d'informations sur les contacts ;
• le registre de .fr (rdap.nic.fr) donne des dates sans heure (2001-12-10), des entités avec leur rôle (bureau d'enregistrement, titulaire, contact technique) et un statut simple (active) ; le champ port43 n'y est pas renseigné.

La conséquence pour le code : ne supposez jamais la présence d'un champ, testez-le (en jq : .secureDNS?.delegationSigned // "inconnu"), et normalisez les dates.

Au-delà des domaines : adresses IP et numéros d'AS #

RDAP couvre aussi les ressources réseau, avec la même logique et des fichiers bootstrap séparés (adresses IPv4 et IPv6, numéros d'AS) :

curl -sL -H 'Accept: application/rdap+json' https://rdap.org/ip/193.0.6.139 | jq '{name, country, startAddress, endAddress}'
curl -sL -H 'Accept: application/rdap+json' https://rdap.org/autnum/3333 | jq '{name}'

La première commande renvoie le bloc 193.0.0.0 – 193.0.7.255, enregistré au nom de RIPE-NCC (pays NL) ; la seconde, le nom de l'AS 3333, RIPE-NCC-AS. C'est une alternative propre au « whois -h » pour retrouver le propriétaire d'une plage.

Cas d'usage concrets #

• surveiller les dates d'expiration d'un portefeuille de domaines : un script quotidien qui lit events et envoie une alerte à J-60 ;
• vérifier qu'un domaine est bien signé en DNSSEC, sans passer par dig ;
• comparer les serveurs de noms déclarés au registre avec ceux que renvoie réellement le DNS (une divergence signale souvent une migration inachevée) ;
• tester la disponibilité d'une liste de noms ;
• retrouver le propriétaire d'une plage d'adresses lors d'un incident.

Limites et bonnes pratiques #

• Limitation de débit. Les registres limitent les requêtes et ne documentent pas toujours leurs seuils. Espacez-les, mettez en cache (les réponses changent rarement : quelques heures suffisent) et traitez le code 429 en attendant plutôt qu'en réessayant aussitôt ;
• Pas de requêtes en masse sans accord. RDAP est fait pour des consultations unitaires. Pour analyser des millions de noms, il existe d'autres sources : fichiers de zone, données ouvertes des registres, listes de popularité ;
• Identifiez-vous. Un User-Agent explicite avec un moyen de contact évite d'être confondu avec un robot malveillant
• Les données personnelles sont masquées. Depuis le RGPD, les coordonnées des particuliers sont expurgées. N'attendez pas d'un RDAP un « qui possède ce domaine »
• Vérifiez les conditions d'utilisation du registre avant d'automatiser quoi que ce soit.

WHOIS ou RDAP, en bref #

• Format : texte libre contre JSON structuré.
• Transport : TCP port 43 en clair contre HTTPS.
• Erreurs : message à interpréter contre code HTTP standard (200, 404, 429).
• Découverte du serveur : à deviner contre fichier bootstrap IANA (incomplet, mais publié).
• Couverture : WHOIS reste présent partout, RDAP est obligatoire pour les registres et bureaux d'enregistrement ICANN et progresse chez les autres.

Pour aller plus loin : les RFC 9082 (requêtes), 9083 (réponses JSON) et 9224 (bootstrap), et le fichier https://data.iana.org/rdap/dns.json à lire dans son navigateur.

Les extraits de réponses ci-dessus ont été relevés le 11 octobre 2026 ; les registres modifient régulièrement leurs services, vérifiez avant de vous appuyer sur un champ précis.