WHOIS vs RDAP : ce qui a changé et pourquoi c'est important

RDAP (Registration Data Access Protocol) est le successeur officiel de WHOIS, standardisé par l'IETF et adopté par l'ICANN. Les deux protocoles exposent les mêmes données d'enregistrement, coordonnées du registrant, dates, nameservers, codes EPP. La différence réside dans la façon dont ils le font : RDAP utilise HTTPS avec des réponses JSON structurées, alors que WHOIS renvoie du texte brut sur le port TCP 43 sans format cohérent. Pour un humain qui fait une recherche ponctuelle, la différence est invisible. Pour un développeur qui construit des outils ou de l'automatisation, elle est fondamentale.

Le problème fondamental de WHOIS

WHOIS tourne depuis 1982. En quatre décennies, il a accumulé des défauts de conception impossibles à corriger sans remplacer le protocole :

• Pas de format standard. Chaque registre formate sa réponse différemment. La sortie Verisign pour .com ne ressemble pas à la réponse RIPE pour les domaines européens, ni à celle de l'Afnic pour .fr. Parser WHOIS, c'est écrire et maintenir des expressions régulières fragiles, spécifiques à chaque registre.
• Pas d'authentification. Le protocole traite chaque client de façon identique, un bot qui aspire des millions d'enregistrements a le même accès qu'un administrateur qui vérifie son propre domaine. Impossible d'implémenter correctement un contrôle d'accès.
• Rate limiting artisanal. Chaque opérateur l'implémente à sa façon : certains bloquent après 10 requêtes par minute, d'autres après 5, certains après 1. Pas de standard sur comment un client bloqué doit se comporter.
• Pas d'internationalisation. Les caractères non-ASCII dans les noms ou adresses des registrants corrompent régulièrement la sortie WHOIS.
• Aucune compatibilité native avec le RGPD. WHOIS a été conçu pour tout montrer à tout le monde. Quand le RGPD est arrivé en 2018, il est devenu impossible de différencier ce qu'un registrar pouvait montrer au public, à un tiers accrédité, ou aux forces de l'ordre, le protocole ne supporte pas cette notion.
• Port TCP 43, pas HTTPS. Pas de chiffrement, pas de certificats, pas de codes d'erreur standardisés.

Ce que RDAP apporte concrètement

RDAP résout chacun de ces problèmes :

• Format JSON normalisé (RFC 7483) : chaque serveur RDAP retourne la même structure de champs, quel que soit le registre. Fini le parsing à l'aveugle.
• Transport HTTPS : chiffrement, codes HTTP standard, headers de cache, et toute l'infrastructure web existante.
• Contrôle d'accès différencié : RDAP supporte l'authentification et la visibilité des champs selon le rôle. Un registrar peut montrer les données complètes du registrant à des tiers accrédités et des champs redactés au grand public.
• Support Unicode natif : les noms de registrants en arabe, chinois ou cyrillique passent sans corruption.
• Bootstrapping standardisé : un client peut trouver automatiquement le bon serveur RDAP pour n'importe quel TLD via le fichier bootstrap IANA (https://data.iana.org/rdap/dns.json). Pas de table statique à maintenir.
• Liens relationnels : la réponse JSON inclut des liens href vers les entités liées (registrar, registrant), ce qui permet de suivre les relations programmatiquement.

WHOIS vs RDAP : comparaison directe

Critère	WHOIS	RDAP
Format de réponse	Texte brut (variable)	JSON (RFC 7483)
Transport	TCP port 43	HTTPS
Authentification	Aucune	Optionnelle (OAuth)
Format standardisé	Non	Oui
Support Unicode	Limité	Complet
Rate limiting	Ad hoc selon l'opérateur	Standardisé (HTTP 429 + Retry-After)
Contrôle d'accès	Non	Oui
Adoption ICANN	Legacy	Obligatoire pour les gTLDs depuis 2019

Un exemple concret : même domaine, deux protocoles

Voici ce que donne l'interrogation de github.com via chacun des deux protocoles.

Sortie WHOIS (Verisign, port 43) :

Domain Name: GITHUB.COM
Registry Domain ID: 1264983250_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Updated Date: 2022-09-07T09:10:44Z
Creation Date: 2007-10-09T18:20:50Z
Registry Expiry Date: 2024-10-09T18:20:50Z
Registrar: MarkMonitor Inc.
Domain Status: clientTransferProhibited
Name Server: DNS1.P08.NSONE.NET
Name Server: DNS2.P08.NSONE.NET

Réponse RDAP (rdap.verisign.com, JSON) :

{
  "ldhName": "github.com",
  "handle": "1264983250_DOMAIN_COM-VRSN",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2007-10-09T18:20:50Z" },
    { "eventAction": "expiration",   "eventDate": "2024-10-09T18:20:50Z" },
    { "eventAction": "last changed", "eventDate": "2022-09-07T09:10:44Z" }
  ],
  "nameservers": [
    { "ldhName": "dns1.p08.nsone.net" },
    { "ldhName": "dns2.p08.nsone.net" }
  ],
  "entities": [
    {
      "roles": ["registrar"],
      "vcardArray": ["vcard", [["fn", {}, "text", "MarkMonitor Inc."]]]
    }
  ]
}

Dans la sortie WHOIS, extraire la date d'expiration nécessite de parser une ligne qui commence par Registry Expiry Date:, et ce nom de champ change selon le registre (certains écrivent Expiration Date, d'autres Registrar Registration Expiration Date). Dans la réponse RDAP, c'est toujours events[?(@.eventAction=="expiration")].eventDate. Un chemin JSON prévisible, à chaque fois.

WHOIS va-t-il disparaître ?

Pas dans l'immédiat. WHOIS reste accessible sur la majorité des registres, et beaucoup d'opérateurs le maintiendront pour des raisons de compatibilité. Mais la direction est claire : l'ICANN exige de tous les registres gTLD le support RDAP depuis 2019, et le nombre de ccTLDs avec des endpoints RDAP augmente chaque année. Les outils construits aujourd'hui doivent interroger RDAP en priorité et ne retomber sur WHOIS que si RDAP n'est pas disponible pour un TLD donné. C'est exactement ce que fait Domain Sentinel.

Ce que ça change pour les développeurs

Si vous construisez quoi que ce soit qui touche aux données d'enregistrement de domaines, quelques conclusions pratiques :

• N'écrivez pas de parsers WHOIS texte brut. Le coût de maintenance est réel et la fiabilité médiocre. Utilisez RDAP.
• Utilisez le bootstrap IANA pour trouver automatiquement le bon serveur RDAP par TLD : curl https://data.iana.org/rdap/dns.json.
• Une requête RDAP simple ressemble à ça : curl https://rdap.verisign.com/com/v1/domain/github.com
• Gérez proprement les réponses HTTP 429. Les serveurs RDAP retournent un header Retry-After en cas de rate limiting, respectez-le ou votre IP sera bannie.
• Domain Sentinel expose une API qui abstrait le bootstrapping RDAP, le rate limiting et le fallback WHOIS. Si vous avez besoin de données de domaine en production sans construire cette infrastructure vous-même, c'est le chemin le plus rapide.

Domain Sentinel interroge RDAP en priorité, avec un fallback automatique sur WHOIS pour les TLDs qui n'ont pas encore migré.

Testez une requête RDAP en temps réel sur n'importe quel domaine dans Domain Sentinel, la réponse est parsée, annotée et surveillée automatiquement.