WHOIS nom de domaine : trouver le propriétaire et lire la fiche

Qu'est-ce qu'un WHOIS nom de domaine ?

Un WHOIS nom de domaine est une requête envoyée à la base publique d'enregistrement d'un nom de domaine. Tout domaine déposé sous une extension générique comme .com, .net ou .org possède une fiche tenue par son registre et par son bureau d'enregistrement (registrar), et la partie publique de cette fiche est consultable par n'importe qui. La requête renvoie le registrar, la date de création du domaine, sa date d'expiration, les serveurs de noms qu'il utilise et une série de codes de statut qui indiquent s'il est verrouillé, suspendu ou sur le point d'être supprimé.

Le nom vient de la commande Unix d'origine. En 1982, la RFC 812 décrivait le service NICNAME/WHOIS d'ARPANET sur le port TCP 43, que l'on interrogeait en tapant whois suivi d'un nom ; la RFC 3912 est la spécification actuelle de ce protocole en texte brut. Le mot est resté alors que le protocole sous-jacent a changé : depuis le 28 janvier 2025, l'ICANN n'impose plus aux registres et aux registrars de gTLD de faire tourner un WHOIS sur le port 43 (sauf pour .com, .name et .post), et les mêmes données sont servies via RDAP, une API JSON. La plupart des outils, dont l'outil WHOIS Lookup de DNS Robot, interrogent RDAP en premier et continuent d'appeler le résultat une fiche WHOIS.

Ce qu'un WHOIS ne renvoie généralement plus, c'est le nom, l'adresse et l'e-mail du titulaire. Depuis l'entrée en application du RGPD (GDPR) en mai 2018, les registrars masquent par défaut les données de contact personnelles, partout dans le monde. La suite de ce guide vous montre ce qui reste visible, comment le lire, et comment joindre un propriétaire quand les champs de contact affichent REDACTED FOR PRIVACY.

Ce que contient une fiche WHOIS

Voici une vraie fiche de registre pour example.com, récupérée le 27 octobre 2026 avec la commande whois sous macOS. Toutes les fiches de gTLD ont la même structure : une fois que vous savez lire celle-ci, vous savez toutes les lire :

Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.iana.org
Registrar URL: http://res-dom.iana.org
Updated Date: 2026-08-14T08:01:43Z
Creation Date: 1995-08-14T04:00:00Z
Registry Expiry Date: 2027-08-13T04:00:00Z
Registrar: RESERVED-Internet Assigned Numbers Authority
Registrar IANA ID: 376
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: ELLIOTT.NS.CLOUDFLARE.COM
Name Server: HERA.NS.CLOUDFLARE.COM
DNSSEC: signedDelegation
DNSSEC DS Data: 2371 13 2 C988EC423E3880EB8DD8A46FE06CA230EE23F35B578D64E78B29C3E1C83D245A
>>> Last update of whois database: 2026-10-26T19:13:27Z <<<

La fiche se divise en cinq blocs, et chacun répond à une question différente :

• Identité — Domain Name et Registry Domain ID. L'identifiant est la clé interne du registre et ne change jamais, même quand le domaine change de mains.
• Registrar — la société à qui le propriétaire paie son domaine. Registrar IANA ID est le numéro unique du registrar dans la liste des registrars de l'IANA ; Registrar WHOIS Server indique où se trouvent les champs de contact, car pour .com et .net le registre lui-même ne stocke aucun contact.
• Dates — Creation Date, Updated Date et Registry Expiry Date. Les trois sont en UTC. La date de création est celle que remonte un vérificateur d'âge de domaine.
• Statut — un ou plusieurs codes de statut EPP. C'est la partie la plus utile de la fiche, et la plus mal interprétée ; elle a sa propre section plus bas.
• Délégation — les serveurs de noms et l'indicateur DNSSEC. C'est le pont entre le WHOIS et le DNS : changez les serveurs de noms ici et tous les enregistrements DNS du domaine suivent.

Comment faire une recherche WHOIS

Il existe trois façons de lancer une requête, et elles renvoient les mêmes données de fond. Choisissez selon la fréquence de vos recherches et selon que vous voulez ou non la sortie brute.

Méthode 1 : utiliser un outil WHOIS en ligne

Ouvrez l'outil WHOIS Lookup de DNS Robot, saisissez un domaine (une URL ou une adresse e-mail collée fonctionne aussi : l'outil en extrait le domaine enregistré) et appuyez sur Entrée. L'outil interroge le serveur RDAP du registre lui-même (celui de la liste de l'IANA, plus des registres comme DENIC qui font tourner RDAP en dehors de cette liste), puis la fiche du registrar pour les champs de contact ; pour les TLD sans RDAP, soit environ deux extensions nationales sur trois (.jp, .ru, .it et .eu notamment), il interroge à la place le serveur port 43 du registre. Vous obtenez le registrar avec son contact abuse, les dates de création, de mise à jour et d'expiration, les codes de statut traduits en clair, les serveurs de noms, l'état DNSSEC et l'âge du domaine.

ICANN Lookup est l'alternative officielle. Elle fait autorité pour tous les gTLD, mais ne couvre que les extensions nationales dont le registre fait tourner RDAP, et elle n'offre ni historique, ni traitement par lot, ni lien vers les données DNS. Les sites des registrars comme GoDaddy et Namecheap proposent eux aussi des pages WHOIS qui lisent les mêmes fiches publiques : elles fonctionnent, mais elles sont conçues pour vous vendre le domaine s'il est libre.

Méthode 2 : la commande whois (macOS, Linux, Windows)

macOS embarque un client whois, et les distributions Linux en proposent un. Il parle le WHOIS du port 43, suit automatiquement les redirections vers le registrar et affiche chaque fiche à la suite (macOS commence par l'IANA, vous en obtenez donc trois) :

# Basic lookup (follows registry -> registrar referral)
whois example.com

# Query one specific server and skip the referral
whois -h whois.verisign-grs.com example.com

# Only the lines you usually care about
whois example.com | grep -iE 'Registrar:|Creation Date|Expiry|Domain Status|Name Server'

# Debian/Ubuntu: install if missing
sudo apt install whois

Windows n'a pas de whois intégré. Les deux options propres sont l'outil maison de Microsoft, Sysinternals, et une requête RDAP avec le curl livré avec Windows 10 et 11 :

Windows : whois de Sysinternals ou curl

Téléchargez whois.exe depuis la suite Sysinternals et placez-le dans votre PATH. -v suit la redirection vers le registrar, et un serveur précis se place après le domaine (whois example.com whois.verisign-grs.com) plutôt qu'après -h. Si vous préférez ne rien installer, interrogez directement le serveur RDAP et laissez PowerShell mettre en forme le JSON :

# Sysinternals whois (after download)
whois -v example.com

# No install: query RDAP and pretty-print the JSON
curl.exe -sL -H "Accept: application/rdap+json" https://rdap.org/domain/example.com | ConvertFrom-Json | Select-Object ldhName, status, events, nameservers

Méthode 3 : interroger RDAP directement (pour vos scripts)

Si vous avez besoin des données WHOIS dans un script, laissez tomber le format texte et appelez RDAP. La réponse est du JSON au schéma fixe : vous extrayez les champs sans la moindre expression régulière. Le registre du .com répond sur rdap.verisign.com ; pour toute autre extension, rdap.org retrouve le bon serveur dans le fichier de bootstrap de l'IANA et vous y redirige :

# Registry record for a .com, straight from Verisign
curl -s -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com | jq '{status, events, nameservers: [.nameservers[].ldhName]}'

# Any TLD: let rdap.org find the authoritative server
curl -sL https://rdap.org/domain/example.org | jq '.events'

# Output of the first command (trimmed: Verisign also returns a "last update of RDAP database" event)
{
  "status": ["client delete prohibited", "client transfer prohibited", "client update prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-08-13T04:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2026-08-14T08:01:43Z" }
  ],
  "nameservers": ["ELLIOTT.NS.CLOUDFLARE.COM", "HERA.NS.CLOUDFLARE.COM"]
}

Le tableau links d'une réponse de registre contient un lien related vers le serveur RDAP du registrar. Suivez-le et vous obtenez les objets de contact, masqués ou non. C'est exactement ce qu'un bon outil web fait pour vous en une seule requête. Si vous construisez quelque chose là-dessus, la méthode en six étapes décrite dans comment tester un point d'entrée d'API publique s'applique aux serveurs RDAP comme à n'importe quelle autre API JSON.

Comment lire les résultats (champ par champ)

La plupart des gens lancent une requête pour répondre à l'une de ces quatre questions. Voici où se trouve la réponse dans la fiche.

Le domaine est-il pris ? Si une fiche revient, oui. Un domaine enregistré a toujours une Creation Date. Si le registre renvoie No match for domain ou si RDAP renvoie un HTTP 404, le nom est libre — ou réservé par le registre, ce qui est fréquent pour les mots courts et les mots du dictionnaire. Utilisez un vérificateur de disponibilité de domaine pour distinguer les deux cas, car il contrôle aussi par le DNS.

Quand expire-t-il, et va-t-il retomber dans le domaine public ? Lisez la date d'expiration, puis les codes de statut. Un domaine en autoRenewPeriod ou en redemptionPeriod n'a pas été libéré : son propriétaire peut encore le renouveler ou le restaurer. Seul pendingDelete signifie qu'il va être remis en circulation, et cela prend en général cinq jours de plus. La section sur le cycle de vie, plus bas, déroule toute la chronologie. Ne vous fiez pas à la seule date du registre : quand un domaine gTLD expire, le registre le renouvelle automatiquement pour un an, si bien que Registry Expiry Date peut déjà afficher l'année suivante alors que la fiche du registrar (Registrar Registration Expiration Date) montre encore le jour où le propriétaire a cessé de payer. Quand les deux divergent, ce sont les codes de statut qui disent si le domaine tombe.

Qui le gère ? Registrar désigne la société à contacter, et le Registrar Abuse Contact Email ainsi que le téléphone restent publics même quand tout le reste est masqué. C'est voulu : la Registration Data Policy de l'ICANN impose que ces champs restent accessibles.

A-t-il changé récemment ? Updated Date bouge à chaque modification poussée par le registrar : un renouvellement, un changement de serveurs de noms, un verrou ajouté ou retiré. Un domaine qui a changé de serveurs de noms la semaine dernière et qui expire le mois prochain n'a pas du tout le même profil de risque qu'un domaine intouché depuis 2015. Si les serveurs de noms ont changé, un NS lookup montre où le DNS est désormais hébergé.

Les codes de statut de domaine (EPP) expliqués

Les codes de statut sont la ligne la plus précieuse d'une fiche WHOIS, et la plus mal lue. Ils sont définis par le protocole EPP et chaque code a un sens fixe publié par l'ICANN. Un code qui commence par client a été posé par le registrar, en général à la demande du propriétaire ; un code qui commence par server a été posé par le registre, et lui seul peut le retirer.

Le schéma à retenir : clientTransferProhibited + clientUpdateProhibited + clientDeleteProhibited, c'est sain et sans histoire. Un domaine qui ne résout soudain plus du tout et qui affiche clientHold a besoin que son propriétaire consulte sa boîte mail, pas son DNS. Et si vous guettez un domaine que quelqu'un a laissé expirer, rien avant pendingDelete ne mérite votre attention.

Pourquoi le WHOIS affiche « REDACTED FOR PRIVACY »

Jusqu'en 2018, la fiche WHOIS d'un .com affichait généralement le nom complet du titulaire, son adresse postale, son téléphone et son e-mail. Les registrars vendaient le WHOIS privacy en option : un service mandataire remplaçait alors ces champs par les siens. Puis le RGPD (GDPR) européen est entré en application le 25 mai 2018, le même jour qu'une Temporary Specification adoptée une semaine plus tôt par l'ICANN, et les registrars se sont mis à masquer les données personnelles de tout le monde plutôt que d'essayer de décider qui relevait du texte. Cette règle provisoire a été remplacée par la Registration Data Policy de l'ICANN, pleinement applicable depuis le 21 août 2025 : les registrars doivent masquer les données personnelles là où la loi sur la vie privée l'exige, et peuvent aussi les masquer pour tous les autres.

Voici ce que la fiche RDAP de cloudflare.com, au niveau du registrar, renvoie aujourd'hui pour son titulaire (abrégée) :

{
  "objectClassName": "entity",
  "roles": ["registrant"],
  "vcardArray": ["vcard", [
    ["fn",  {}, "text", "DATA REDACTED"],
    ["org", {"type": "work"}, "text", "DATA REDACTED"],
    ["adr", {"cc": "US", "type": "work"}, "text",
      ["", "", ["DATA REDACTED", "DATA REDACTED"], "DATA REDACTED", "CA", "DATA REDACTED", ""]],
    ["contact-uri", {}, "uri", "https://domaincontact.registrar.cloudflare.com/cloudflare.com"]
  ]],
  "remarks": [{ "title": "REDACTED FOR PRIVACY",
                "description": ["Some of the data in this object has been removed"] }]
}

La politique est précise sur ce qui reste public. Ces champs doivent toujours être publiés pour un domaine en gTLD : le nom de domaine, le nom du registrar et son IANA ID, l'URL du registrar, l'e-mail et le téléphone abuse du registrar, la date de création, la date d'expiration, les serveurs de noms et les codes de statut. Le masquage n'est d'ailleurs jamais total : la politique impose de publier la région/l'État et le pays du titulaire, ainsi que le nom de l'organisation quand le titulaire a accepté de le publier. Une fiche masquée peut donc quand même vous apprendre que le propriétaire est en Californie ou en Bavière. Dans la fiche ci-dessus, ce sont CA et US, plus un lien contact-uri vers le formulaire de contact de Cloudflare.

La différence pratique entre privacy et masquage : un service WHOIS privacy payant continue de faire suivre les messages envoyés à son adresse mandataire, alors que le simple masquage supprime l'e-mail et le remplace par un lien vers un formulaire de contact ou par une adresse de redirection anonymisée, selon le registrar. Dans les deux cas, un tiers dispose d'un moyen d'écrire au propriétaire sans apprendre qui il est.

Comment trouver le propriétaire d'un nom de domaine quand le WHOIS est masqué

Le masquage a fermé la porte d'entrée, mais un domaine laisse des empreintes partout ailleurs. Déroulez cette liste dans l'ordre : chaque étape prend une minute.

• Lisez ce qui n'est pas masqué. La région/l'État et le pays sont toujours publiés, et l'organisation aussi quand le titulaire a donné son accord. Le registrar lui-même restreint le champ des possibles : un domaine chez MarkMonitor ou CSC appartient à un grand groupe ; un domaine chez Cloudflare Registrar est plutôt le fait d'un développeur ou d'une startup.
• Passez par le relais de contact du registrar. Tout registrar doit vous offrir un moyen de joindre le titulaire : une adresse anonymisée du type abc123@contact.gandi.net, ou un formulaire web accessible depuis la sortie WHOIS. Les messages légitimes sont transmis.
• Regardez le certificat SSL. Les certificats à validation d'organisation (OV) et à validation étendue (EV) portent la raison sociale dans le champ Subject. Passez le domaine dans un SSL checker et lisez la chaîne de certification ; le guide sur les chaînes de certificats SSL montre où se situe l'organisation.
• Fouillez le DNS. Le champ RNAME de l'enregistrement SOA est l'e-mail de l'administrateur de la zone, avec le @ remplacé par un point. Les enregistrements TXT révèlent le fournisseur de messagerie, les jetons de vérification Google, Microsoft et Facebook, et parfois un nom d'entreprise en clair. Un DNS lookup sur SOA et TXT prend quelques secondes, et un subdomain finder fait remonter des noms d'hôtes comme mail., crm. ou jira. qui trahissent les outils utilisés par une société.
• Consultez l'historique WHOIS. Les fiches antérieures à mai 2018 étaient publiques et plusieurs services commerciaux les ont archivées. Un domaine déposé bien avant cette date a souvent une fiche historique non masquée qui donne le titulaire d'origine, sauf s'il utilisait déjà un service de privacy à l'époque.
• Faites un WHOIS inversé. Si vous disposez d'un élément connu (un nom de société ou un e-mail resté visible), les services de WHOIS inversé cherchent tous les domaines qui l'ont un jour déclaré. C'est cher, mais c'est ainsi que les équipes de protection de marque cartographient le portefeuille d'un cybersquatteur.
• Déposez une demande formelle. Pour un besoin juridique — litige de marque, phishing, fraude —, le Registration Data Request Service (RDRS) de l'ICANN achemine une demande de divulgation vers le registrar. Il ne fonctionne que pour les gTLD et seulement avec les registrars participants. Pendant son projet pilote de deux ans (du 28 novembre 2023 au 30 novembre 2025), il a traité plus de 3 700 demandes, dont 26 % ont été acceptées et 55 % refusées (ICANN) ; l'ICANN le maintient en service pendant que la communauté décide de la suite.

WHOIS ou RDAP : ce qui a changé en 2025

RDAP (Registration Data Access Protocol) a été conçu par l'IETF pour corriger tout ce qui n'allait pas dans le WHOIS du port 43, et c'est ce que votre outil de recherche utilise réellement aujourd'hui. Les différences comptent dès que vous exploitez les données :

Deux conséquences pratiques. D'abord, si l'un de vos scripts analyse la sortie texte de whois, il vit en sursis : hors .com, .name et .post, les registres et les registrars peuvent éteindre leur service sur le port 43 à tout moment, et certains l'ont déjà fait. Le whois.nic.google de Google Registry, qui servait .app et .dev, ne résout même plus, et le serveur WHOIS du registrar GoDaddy répond à chaque requête par « This WHOIS server is being retired. Please use our RDAP service instead. » (les deux constatés le 27 octobre 2026).

Ensuite, le bootstrap RDAP règle le problème que le WHOIS n'a jamais résolu : pour example.museum, un client télécharge une fois data.iana.org/rdap/dns.json, y trouve l'entrée museum et interroge le serveur faisant autorité sans la moindre connaissance codée en dur. Le basculement se voit dans le trafic : les rapports mensuels de l'ICANN montrent les requêtes RDAP sur les gTLD passer d'environ 7 milliards par mois en janvier 2025 à 65 milliards en août 2025, devançant le WHOIS du port 43 dès juin 2025 (APNIC).

Extensions nationales : chaque registre fait à sa façon

Les règles de l'ICANN ne lient que les gTLD. Les extensions nationales (.fr, .de, .uk, .br, .jp et environ 300 autres) fixent leurs propres règles, et un WHOIS sur un ccTLD peut aussi bien renvoyer une identité complète et vérifiée que presque rien. Voici ce qu'une requête publique a renvoyé auprès de huit registres le 27 octobre 2026 :

À l'autre bout de l'échelle, voici toute la réponse de DENIC sur le port 43 pour example.de :

% The DENIC whois service on port 43 doesn't disclose any information concerning
% the domain holder, general request and abuse contact.
% This information can be obtained through use of our web-based whois service
% available at the DENIC website:
% https://webwhois.denic.de/?lang=en

Domain: example.de
Nserver: ns1078.ui-dns.biz
Nserver: ns1078.ui-dns.com
Nserver: ns1078.ui-dns.de
Nserver: ns1078.ui-dns.org
Status: connect
Changed: 2018-08-10T05:24:12+02:00

Aucun registrar, aucune date de création ou d'expiration, aucun propriétaire, et le vocabulaire de statut (connect) est celui de DENIC plutôt que celui d'EPP.

WHOIS d'adresse IP : à qui appartient une IP

La même commande whois fonctionne sur une adresse IP, mais la réponse vient d'une tout autre base. Les noms de domaine sont gérés par des registres et des registrars ; les blocs d'adresses IP, eux, sont alloués par les cinq Regional Internet Registries (ARIN pour l'Amérique du Nord, RIPE NCC pour l'Europe et le Moyen-Orient, APNIC pour l'Asie-Pacifique, LACNIC pour l'Amérique latine et AFRINIC pour l'Afrique). Une fiche WHOIS d'IP vous dit quelle organisation détient le bloc, sa taille, le pays d'attribution et le contact abuse — exactement ce qu'il vous faut quand une adresse attaque votre serveur ou vous envoie du spam.

# Port-43 WHOIS: the client finds the right RIR automatically
whois 1.1.1.1

# RDAP: rdap.org redirects to the right RIR (APNIC here)
curl -sL https://rdap.org/ip/1.1.1.1 | jq '{name, handle, startAddress, endAddress, country, type}'

# Output
{
  "name": "APNIC-LABS",
  "handle": "1.1.1.0 - 1.1.1.255",
  "startAddress": "1.1.1.0",
  "endAddress": "1.1.1.255",
  "country": "AU",
  "type": "ASSIGNED PORTABLE"
}

Une fiche IP ne vous dit jamais quels sites sont hébergés sur l'adresse : une seule IP de cloud peut servir de façade à des milliers de domaines. Elle ne donne pas non plus la position géographique de l'utilisateur, seulement l'endroit où le bloc a été enregistré. Pour une réponse rapide sans ligne de commande, IP Lookup combine les données du RIR avec la géolocalisation, et ASN Lookup montre depuis quel réseau le bloc est annoncé. Pour remonter d'une IP vers un nom d'hôte, utilisez le DNS inversé, qui lit l'enregistrement PTR et non le WHOIS.

Lire les dates d'expiration : le cycle de vie d'un domaine

Les codes de statut ne prennent tout leur sens que replacés dans la chronologie que suit un domaine en gTLD quand son propriétaire arrête de payer. L'Expired Registration Recovery Policy de l'ICANN fixe les minimums, les registres et les registrars ajoutent leurs propres marges, et le parcours est bien plus long que ce que la plupart des gens imaginent :

• About 30 days and again about 7 days before expiry — the registrar must email the owner. A third notice follows within 5 days after expiry.
• Day 0 (expiry) — the registry auto-renews the domain and sets autoRenewPeriod. The registrar has up to 45 days to keep it or delete it. Before deleting it, the registrar must stop it resolving for at least the last 8 days (or from expiry, if it deletes sooner), so the site goes dark; many registrars park it on a page that says the domain has expired.
• Day 1–45 (registrar grace) — the owner can still renew. ICANN only guarantees this while the domain is interrupted (ERRP); how long the registrar allows beyond that, and at what price, is its own policy, and it must publish its post-expiry fees on its website.
• Deletion → redemptionPeriod (30 days) — the registrar deleted it. The owner can still restore it, for a restore fee the registrar must show on its website, on top of the renewal. Nobody else can register it.
• pendingDelete (5 days) — restoration is no longer possible. At the end of this window, at a time the registry does not announce, the name is purged and becomes available.
• Drop — the domain is free to register, and drop-catching services that have been polling the registry compete for it within milliseconds.

Un domaine dont la fiche du registrar affiche une date d'expiration vieille de deux semaines peut donc encore être à 35 à 66 jours environ d'être réellement disponible — et il se peut qu'il ne le soit jamais, puisque le propriétaire peut le récupérer à tout moment jusqu'au pendingDelete. Surveillez la ligne de statut, pas la date d'expiration. Lancer un WHOIS lookup une fois par jour et noter le changement de statut suffit.

À quoi servent vraiment les recherches WHOIS

Au-delà du « ce nom est-il libre ? », quelques usages reviennent sans cesse dans les files de support et dans les équipes sécurité.

Vérifier un site avant de lui faire confiance. Une boutique qui se dit installée depuis dix ans mais dont le domaine a été créé il y a trois semaines vous dit quelque chose. Date de création, registrar et serveurs de noms prennent dix secondes à contrôler et sont impossibles à falsifier dans la fiche du registre.

Dépanner un site qui ne résout plus. Avant de toucher au DNS, vérifiez que le domaine n'est ni expiré ni en clientHold ; si c'est le cas, aucune modification DNS n'y changera quoi que ce soit. Après une migration de serveurs de noms, les lignes Name Server du WHOIS confirment que le registrar a bien appliqué le changement ; les résolveurs peuvent conserver les anciens serveurs de noms en cache jusqu'à 48 heures, soit le TTL des enregistrements de délégation du .com. Un NS lookup montre ce que le monde voit à cet instant.

Acheter un domaine déjà pris. Le WHOIS vous donne le registrar (certains proposent un service de courtage), l'état de verrouillage du domaine, la durée de détention par le propriétaire actuel et sa dérive éventuelle vers l'expiration.

Enquêter sur du phishing ou des abus. Le Registrar Abuse Contact Email est publié précisément pour que vous puissiez signaler un domaine malveillant à la partie capable de le suspendre. Combinez-le avec le contact abuse du WHOIS d'IP pour remonter jusqu'à l'hébergeur.

Auditer votre propre portefeuille. On perd des domaines à cause d'une carte bancaire expirée autant qu'à cause de pirates. Un passage WHOIS trimestriel sur tous vos domaines, dates d'expiration et état des verrous en main, est une assurance bon marché.

Référence des champs WHOIS

Un aide-mémoire pour tous les champs que vous croiserez dans une fiche de gTLD, avec leur équivalent RDAP si vous analysez le JSON :

Si une fiche que vous consultez ne colle pas à ce tableau, vous avez presque à coup sûr affaire à un ccTLD, et c'est la documentation du registre concerné qui fait référence.