Le protocole RDAP explique : interroger les données de domaine en JSON

RDAP (Registration Data Access Protocol) est le successeur standardisé de WHOIS, développé sous l'égide de l'ICANN et défini dans les RFC 7480 à 7484 (publiées en 2015). Là où WHOIS est un protocole en texte brut datant de 1982 sans format de sortie standardisé, RDAP est une API REST qui retourne du JSON. Cette différence unique élimine toute une catégorie de problèmes : parsers fragiles, noms de champs incohérents, formats de dates ambigus, impossibilité de distinguer programmatiquement "le domaine n'existe pas" de "le serveur WHOIS est en panne". Cet article explique comment RDAP fonctionne, comment l'interroger, ce que les réponses contiennent, et où il reste limité.

Contexte : pourquoi RDAP a remplacé WHOIS

WHOIS date de 1982 (RFC 812, puis RFC 954, puis RFC 3912). Pour un protocole qui a survécu 40 ans, c'est remarquable, mais il a été conçu pour un internet beaucoup plus petit avec des hypothèses de confiance différentes. Les problèmes se sont accumulés :

• Aucun format de réponse standardisé, chaque registre et registrar pouvait formater la sortie comme bon leur semblait
• Pas de support JSON, donc construire des applications sur WHOIS nécessitait des parsers textuels fragiles
• Pas de mécanismes d'authentification ou de contrôle d'accès
• Pas d'internationalisation, les noms de domaine avec des caractères non-ASCII n'étaient pas gérés de façon cohérente
• Limitation de taux implémentée différemment (ou pas du tout) par chaque serveur

L'ICANN a mandaté la transition vers RDAP pour tous les registres gTLD accrédités en 2019. Aujourd'hui, tous les grands registres gTLD supportent RDAP : Verisign (.com, .net), PIR (.org), et les registres pour .io, .app, .dev, .xyz, .co, et la grande majorité des nouveaux gTLDs lancés depuis 2013. De nombreux ccTLDs l'ont également adopté (l'AFNIC (.fr) et le DENIC (.de) sont parmi les adopteurs notables) mais des lacunes importantes subsistent, notamment en Asie et en Afrique.

Architecture du protocole RDAP

Trois composants constituent l'infrastructure RDAP :

• Les registres autoritaires : les organisations qui maintiennent les données canoniques. Verisign pour .com, PIR pour .org, l'AFNIC pour .fr, etc.
• IANA RDAP Bootstrap : un fichier JSON maintenu par l'IANA (https://data.iana.org/rdap/dns.json) qui mappe chaque TLD vers l'URL de son serveur RDAP. C'est ainsi que les clients trouvent le bon serveur pour n'importe quel TLD.
• rdap.org : un service proxy public maintenu par l'IANA qui accepte des requêtes pour n'importe quel domaine et les route automatiquement vers le serveur de registre approprié. Utile pour des lookups rapides sans consulter le fichier bootstrap.

RDAP supporte plusieurs types de requêtes au-delà des lookups de domaines :

Type de requête	Format du chemin
Domaine	/domain/<nom>
Adresse IP	/ip/<adresse>
Nameserver	/nameserver/<hostname>
Entité (registrar/registrant)	/entity/<handle>

Les RFC qui définissent RDAP

• RFC 7480 : usage HTTP dans RDAP
• RFC 7481 : services de sécurité pour RDAP
• RFC 7482 : format des requêtes
• RFC 7483 : format des réponses JSON
• RFC 7484 : trouver les services RDAP (le mécanisme bootstrap)

Interroger RDAP manuellement

Requêtes de base avec curl

# Vérifier si un domaine existe (200 = enregistré, 404 = disponible)
curl -s https://rdap.org/domain/example.com

# Récupérer seulement les codes de statut
curl -s https://rdap.org/domain/example.com | jq '.status'

# Récupérer la date d'expiration
curl -s https://rdap.org/domain/example.com | jq '.events[] | select(.eventAction=="expiration") | .eventDate'

# Récupérer les nameservers
curl -s https://rdap.org/domain/example.com | jq '[.nameservers[].ldhName]'

Une réponse 404 signifie que le domaine n'existe pas dans le registre, il est disponible à l'enregistrement. Une réponse 200 retourne l'enregistrement complet du domaine. Certains registres retournent une redirection 302 vers leur propre endpoint quand interrogés via rdap.org.

Interroger les endpoints de registre directement

Aller directement au registre est plus rapide que passer par rdap.org :

# Verisign pour .com (plus rapide, sans proxy)
curl -s "https://rdap.verisign.com/com/v1/domain/example.com"

# PIR pour .org
curl -s "https://rdap.publicinterestregistry.org/rdap/domain/example.org"

# AFNIC pour .fr
curl -s "https://rdap.nic.fr/domain/example.fr"

Structure d'une réponse RDAP

Voici un exemple annoté basé sur example.com :

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited"
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "1995-08-14T04:00:00Z"
    },
    {
      "eventAction": "expiration",
      "eventDate": "2026-08-13T04:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2023-08-14T07:01:40Z"
    }
  ],
  "nameservers": [
    { "ldhName": "a.iana-servers.net" },
    { "ldhName": "b.iana-servers.net" }
  ],
  "entities": [
    {
      "roles": ["registrar"],
      "vcardArray": ["vcard", [["fn", {}, "text", "IANA"]]]
    }
  ],
  "links": [
    {
      "rel": "self",
      "href": "https://rdap.verisign.com/com/v1/domain/example.com"
    }
  ]
}

Champs clés :

• status : le tableau des codes de statut EPP. Ce sont des chaînes standardisées, pas de devinette dans le parsing. Voir la référence des codes de statut de domaine pour la signification de chacun.
• events : l'historique du domaine. L'événement expiration donne la date d'expiration. L'événement registration donne la date de création. L'événement last changed indique quand l'enregistrement a été modifié pour la dernière fois au niveau du registre.
• nameservers : les nameservers autoritaires en format ldhName (lettres, chiffres, tirets, encodage compatible ASCII).
• entities : informations sur le registrar et le registrant. L'entité registrant est souvent masquée pour des raisons RGPD.
• links : l'URL canonique pour cet enregistrement dans le registre autoritaire.

Le tableau events : bien plus qu'une simple date d'expiration

Le tableau events est l'une des plus grandes limites de WHOIS corrigées. WHOIS vous donne typiquement une ou deux dates. Le tableau events de RDAP peut contenir : enregistrement, expiration, dernière modification, transfert, dernière mise à jour de la base RDAP. Ce contexte historique est ce qui permet à Domain Sentinel de détecter quand l'enregistrement d'un domaine a changé, l'horodatage last changed se met à jour chaque fois qu'un champ dans l'enregistrement du registre change.

Couverture RDAP : quels TLDs sont supportés?

État actuel de l'adoption RDAP :

• Entièrement supporté : tous les gTLDs accrédités ICANN, .com, .net, .org, .io, .app, .dev, .xyz, .co, .ai, .me, et plusieurs centaines de nouveaux gTLDs
• Supporté (ccTLDs notables) : .fr (AFNIC), .de (DENIC), .uk (Nominet), .nl (SIDN), .be (DNS Belgium), .eu (EURid)
• Non encore supporté : .ru, .cn, .jp, .br, de nombreux ccTLDs africains et asiatiques, ceux-ci restent sur WHOIS uniquement

Le fichier bootstrap IANA est la référence de référence. Si un TLD apparaît dans https://data.iana.org/rdap/dns.json, il supporte RDAP.

Fallback WHOIS quand RDAP n'est pas disponible

Domain Sentinel bascule automatiquement sur WHOIS pour les TLDs sans RDAP. Les données sont moins structurées (noms de champs et formats de dates varient selon le registre) et le parsing produit parfois des résultats incorrects pour des configurations de registrar inhabituelles. La date d'expiration est généralement encore extractible, mais les codes de statut sont présentés en texte WHOIS brut plutôt qu'en chaînes EPP standardisées.

RDAP et RGPD

Depuis 2018, la conformité RGPD a changé ce que RDAP expose pour les registrants de domaine qui sont des personnes physiques dans l'UE. Ce que vous obtenez systématiquement : informations du registrar, nameservers, statuts EPP, toutes les dates d'événements. Ce que vous n'obtenez souvent pas : nom du registrant, email, téléphone, adresse postale, ces champs peuvent être remplacés par un espace réservé comme "Redacted for Privacy" ou simplement omis.

Pour les personnes morales (entreprises), la situation est différente. Les données de registrant d'entreprise sont généralement encore présentes dans les réponses RDAP, bien que les pratiques varient selon le registrar.

Utiliser Domain Sentinel pour les lookups RDAP sans code

Pour ceux qui ne veulent pas exécuter des commandes curl, Domain Sentinel propose une interface web qui interroge RDAP pour n'importe quel domaine et affiche les résultats de façon lisible : statuts traduits en langage courant, date d'expiration mise en évidence avec les jours restants, historique des événements, nameservers, et registrar. Cliquer sur "Add to watchlist" configure la surveillance continue à partir de ce moment.

RDAP est l'infrastructure publique qui rend le monitoring de domaine fiable et programmatique, c'est pourquoi Domain Sentinel interroge les registres directement plutôt que de dépendre de sources de données tierces.