WHOIS ou RDAP : que révèle encore un nom de domaine ?

Si votre dernière recherche whois remonte à une dizaine d'années, vous vous souvenez d'un pavé de texte : un nom, une adresse postale, un numéro de téléphone, une adresse e-mail. Refaites l'exercice aujourd'hui : presque tout a disparu. La fiche est plus courte, la moitié des champs indique « REDACTED », et l'outil que vous utilisez ne parle peut-être même plus le protocole WHOIS.

Ce guide explique ce qui a changé, ce que les données d'enregistrement disent encore, et comment lire les deux éléments qui comptent vraiment : les codes de statut et les dates.

Ce qu'une fiche WHOIS affiche encore

Pour un domaine générique classique (.com, .net, .org, .app, etc.), les données publiques contiennent de façon fiable :

le bureau d'enregistrement qui gère le domaine, avec son identifiant IANA ;
les dates de création, de dernière modification et d'expiration ;
un ou plusieurs codes de statut ;
les serveurs de noms vers lesquels le domaine est délégué ;
l'indication d'une signature DNSSEC ou de son absence ;
le contact abuse du bureau d'enregistrement.

Cela suffit pour la plupart des questions opérationnelles. Ce domaine va-t-il bientôt expirer ? Quelle société appeler pour régler le problème ? Les serveurs de noms ont-ils changé la semaine dernière ? Un verrou de transfert est-il en place ?

Ce que la fiche ne contient généralement plus, c'est l'identité du titulaire.

Pourquoi les données du titulaire sont masquées

Jusqu'en mai 2018, les contrats de l'ICANN obligeaient les bureaux d'enregistrement à publier les coordonnées complètes de chaque titulaire d'un gTLD. Avec l'entrée en application du Règlement général sur la protection des données (RGPD), diffuser ce type de données personnelles à quiconque en faisait la demande n'avait plus de base juridique défendable. L'ICANN a réagi par une Spécification temporaire qui autorisait registres et bureaux d'enregistrement à retirer les champs personnels de la sortie publique. La politique définitive qui a suivi (Registration Data Policy) conserve le même principe.

Quelques conséquences pratiques :

Le masquage est souvent appliqué à tout le monde. Beaucoup de bureaux d'enregistrement l'étendent à l'ensemble de leurs clients, car trier les titulaires selon la loi qui les protège est une source d'erreurs.
Les organisations peuvent rester visibles. Une personne morale peut choisir de faire publier sa raison sociale. Certaines le font.
Les services d'anonymisation (privacy, proxy) forment une couche distincte. Ils remplacent les coordonnées du titulaire par les leurs. Ils existaient bien avant 2018 et restent courants.
Une voie existe pour les demandes légitimes. Le bureau d'enregistrement doit permettre de contacter le titulaire sans dévoiler son adresse, en général par un formulaire web ou une adresse relais, et doit examiner les demandes de divulgation émanant par exemple des autorités ou de titulaires de marques.

Aucun outil de recherche ne peut contourner ce masquage, puisque les données sont retirées à la source. Un site qui prétend afficher le « vrai propriétaire » d'un domaine masqué montre soit d'anciennes données aspirées autrefois, soit des suppositions.

Ce qui ne va pas dans le protocole WHOIS

WHOIS date du début des années 1980. Le client ouvre une connexion TCP sur le port 43, envoie un nom de domaine suivi d'un retour à la ligne, et reçoit du texte libre. Le protocole s'arrête là. Les conséquences :

Pas de format standard. Chaque registre invente ses noms de champs et sa mise en page. Les analyseurs cassent sans arrêt.
Pas d'erreurs standard. « Introuvable », « trop de requêtes » et « serveur en panne » ne sont que du texte.
Pas d'internationalisation. Aucun encodage de caractères n'est défini.
Ni chiffrement ni authentification. Tout circule en clair, et il est impossible d'accorder des niveaux d'accès différents selon le demandeur.
Pas de découverte. Les clients doivent tenir à la main la liste des serveurs qui répondent pour chaque TLD.

RDAP, le successeur

Le protocole RDAP (Registration Data Access Protocol) a été normalisé par l'IETF en 2015 pour corriger précisément ces défauts. C'est une API HTTPS qui renvoie du JSON :

Structure définie. Les dates sont des events dotés d'une action telle que registration ou expiration. Les contacts sont des entities avec un rôle (registrar, abuse…). Les statuts proviennent d'une liste fermée.
Vraie gestion des erreurs. Un domaine inexistant renvoie un HTTP 404, une limitation de débit un 429.
Découverte par bootstrap. L'IANA publie un fichier lisible par machine qui associe chaque TLD à l'URL de base de son service RDAP : le client sait toujours où interroger.
Renvois. La réponse du registre peut pointer vers le serveur RDAP du bureau d'enregistrement, qui détient parfois davantage de détails.
Accès différencié possible. Comme tout passe par HTTPS, un serveur peut authentifier le demandeur et renvoyer plus de champs à ceux qui y ont droit.

Un simple curl suffit pour essayer. Voici, en version abrégée, la forme d'une réponse :

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2015-03-02T10:15:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-03-02T10:15:00Z" }
  ],
  "nameservers": [
    { "ldhName": "ns1.example.net" },
    { "ldhName": "ns2.example.net" }
  ],
  "secureDNS": { "delegationSigned": false }
}

L'ICANN impose RDAP aux registres et bureaux d'enregistrement des gTLD depuis août 2019. En janvier 2025, l'obligation contractuelle de maintenir le WHOIS sur le port 43 pour les gTLD a pris fin, ce qui fait de RDAP la source de référence. On continue de dire « faire un whois », et ce n'est pas un problème tant qu'on désigne la tâche : les données, elles, arrivent de plus en plus par RDAP.

Pour les extensions nationales (ccTLD), c'est une autre histoire : chacune fixe sa propre politique. Beaucoup proposent RDAP, certaines n'offrent encore qu'un WHOIS ou un formulaire web, et quelques-unes ne publient presque rien. Le .fr, par exemple, est géré par l'Afnic, qui applique ses propres règles de publication.

Comment lire les codes de statut

Les codes de statut viennent d'EPP, le protocole qu'utilisent bureaux d'enregistrement et registres pour communiquer. RDAP les écrit avec des espaces (« client transfer prohibited »), la sortie WHOIS en camelCase. Le préfixe indique qui a posé le code : client désigne le bureau d'enregistrement, server le registre.

Les codes du quotidien

ok / active : aucune restriction, rien n'est verrouillé.
clientTransferProhibited : verrou de transfert posé par le bureau d'enregistrement. Normal, et souhaitable sur vos propres domaines.
clientUpdateProhibited, clientDeleteProhibited : verrous du bureau d'enregistrement contre les modifications ou la suppression. Fréquents sur les noms de valeur.
serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited : verrous posés au niveau du registre. On les rencontre avec les offres de « registry lock » et pendant les litiges.

Les codes qui signifient que le domaine ne répond plus

clientHold : le bureau d'enregistrement a retiré le domaine de la zone. Causes habituelles : renouvellement impayé, adresse e-mail de contact non vérifiée, traitement d'un abus.
serverHold : même chose, mais décidée par le registre. Généralement une question juridique ou réglementaire.
inactive : aucun serveur de noms n'est défini, il n'y a donc rien à publier.

Les codes du cycle de vie

addPeriod : domaine tout juste enregistré. Le bureau d'enregistrement peut encore le supprimer contre remboursement, en général dans les cinq jours.
autoRenewPeriod : le registre a renouvelé le domaine automatiquement à l'échéance. Le bureau d'enregistrement peut encore annuler l'opération, typiquement pendant 45 jours au plus.
transferPeriod, renewPeriod : courts délais de grâce après un transfert ou un renouvellement explicite.
pendingTransfer : un transfert vers un autre bureau d'enregistrement est en cours.
redemptionPeriod : le domaine a été supprimé. L'ancien titulaire peut le restaurer, en général sous 30 jours et moyennant des frais conséquents.
pendingDelete : la restauration n'est plus possible. Au bout de cinq jours environ, le nom est libéré.

Les durées exactes varient selon le TLD et le bureau d'enregistrement, et les ccTLD ont souvent un cycle de vie entièrement différent. Considérez ces chiffres comme le schéma courant des gTLD, pas comme une promesse.

Date d'expiration : celle du registre ou celle du bureau d'enregistrement ?

C'est ici que beaucoup se font piéger.

Lorsqu'un domaine gTLD atteint sa date d'expiration, la plupart des registres ne le suppriment pas. Ils le renouvellent automatiquement pour un an, facturent le bureau d'enregistrement et placent le nom en autoRenewPeriod. Si le client ne paie jamais, le bureau d'enregistrement supprime le domaine pendant le délai de grâce et récupère la somme.

Pendant cette fenêtre, la fiche publique peut donc afficher une expiration dans un an pour un domaine dont le titulaire n'a rien payé et dont le site est déjà remplacé par une page de parking. La date est exacte du point de vue du registre. Ce n'est simplement pas celle qui régit votre relation avec votre bureau d'enregistrement.

Certaines fiches exposent les deux valeurs :

Registry Expiry Date: 2027-03-02T10:15:00Z
Registrar Registration Expiration Date: 2026-03-02T10:15:00Z

Quand elles diffèrent, c'est la date du bureau d'enregistrement qui décide si votre service reste en ligne. Trois règles pratiques :

Renouvelez les domaines importants bien avant l'échéance, pas pendant les délais de grâce.
Lisez toujours les dates avec les codes de statut. Une expiration lointaine accompagnée de autoRenewPeriod veut dire « pas encore payé », pas « tranquille ».
Si vous espérez enregistrer un nom en fin de vie, sachez que le titulaire actuel peut normalement le récupérer jusqu'au dernier jour de redemptionPeriod. Le déroulé complet est décrit dans que se passe-t-il quand un nom de domaine expire.

L'âge du domaine

La date de création sert souvent d'indice approximatif de l'ancienneté d'un domaine. Une réserve toutefois : si un nom a été supprimé puis enregistré de nouveau, la date de création repart de zéro. Elle indique quand l'enregistrement actuel a commencé, pas quand le nom a été utilisé pour la première fois.

Erreurs fréquentes

Croire qu'un outil payant « débloque » les données masquées : elles ne sont plus publiées du tout.
Lire la date d'expiration du registre comme la preuve que tout est payé.
Prendre clientTransferProhibited pour une anomalie alors que c'est le verrou normal ; pour le lever proprement, voyez comment transférer un nom de domaine.
Supposer qu'un ccTLD publie les mêmes champs et suit le même cycle de vie qu'un .com.
Interpréter une requête en échec comme « domaine libre ». Une absence de réponse signifie seulement que la vérification n'a pas pu être faite.

Vérifiez avec OrbitProbe

La recherche WHOIS d'OrbitProbe interroge directement RDAP et affiche le bureau d'enregistrement, les dates, les codes de statut, les serveurs de noms et l'état DNSSEC, avec le serveur source et l'heure de la requête. Les champs masqués sont indiqués comme tels. Si vous gérez plusieurs domaines, le portefeuille de l'espace de travail regroupe leurs dates d'expiration dans une seule liste et envoie des rappels de renouvellement.