Comment vérifier un nom de domaine, étape par étape

Vérifier un nom de domaine recouvre quatre opérations distinctes : savoir s’il est libre, savoir qui le détient et jusqu’à quand, contrôler sa configuration DNS, et s’assurer qu’il n’imite pas une marque existante. Pour les trois premières, la source de vérité est le registre du TLD interrogé en WHOIS (port 43) ou en RDAP, jamais une simple résolution DNS.

« Vérifier » recouvre quatre questions qui n’ont pas la même réponse

Selon le contexte, la même phrase désigne des opérations qui n’utilisent ni les mêmes outils ni les mêmes sources. Un acheteur veut savoir si le nom est libre. Un juriste veut le titulaire. Un administrateur dont le site vient de tomber veut savoir où la chaîne casse. Et quelqu’un qui a reçu un mail douteux veut savoir si le domaine ressemble à une marque connue sans en être une.

Confondre ces quatre questions produit des erreurs classiques : conclure qu’un domaine est libre parce qu’aucun site ne s’affiche, ou chercher une panne DNS alors que le domaine est simplement impayé.

• Disponibilité à l’enregistrement : registre du TLD, via RDAP ou WHOIS
• Titulaire, dates de création et d’expiration, verrous de transfert : RDAP ou WHOIS également
• Délégation et configuration (NS, MX, SPF, certificat) : dig et openssl
• Légitimité du nom lui-même (imitation, punycode, antériorité de marque) : bases de marques et décodage IDN

Disponibilité : interroger le registre, pas le DNS

L’erreur la plus fréquente consiste à faire un dig et à lire NXDOMAIN comme « le domaine est libre ». Un domaine enregistré mais sans serveurs de noms déclarés n’apparaît pas dans la zone du TLD : la réponse est bien NXDOMAIN, alors que le nom est pris depuis des années. Le DNS répond à la question « ce nom est-il délégué », pas « ce nom est-il enregistré ».

La réponse fiable vient du registre. WHOIS reste disponible sur le port 43 (RFC 3912) mais renvoie du texte libre dont le format change d’un registre à l’autre. RDAP, défini par les RFC 9082 et 9083, renvoie du JSON avec des champs stables et un code HTTP exploitable : 404 quand le domaine n’est pas enregistré, 200 quand il l’est. Le serveur RDAP à interroger pour chaque extension se trouve dans le fichier de bootstrap de l’IANA (data.iana.org/rdap/dns.json, RFC 7484). Depuis le 28 janvier 2025, les acteurs des gTLD ne sont plus tenus par l’ICANN de maintenir un service WHOIS : RDAP est devenu le service de référence.

Deux limites à garder en tête. Un 404 ne signifie pas « achetable » : les noms réservés par le registre, les noms premium et les noms sous procédure renvoient la même chose qu’un nom totalement libre. Et les serveurs WHOIS appliquent des quotas ; l’AFNIC coupe une adresse IP qui enchaîne les requêtes, et la réponse vide qui en résulte ressemble beaucoup à un « no match ». Vérifier ne réserve rien, par ailleurs : entre la requête et le paiement, le nom peut partir.

• whois exemple.fr : réponse brute du registre, lisible mais non structurée
• curl -s https://rdap.nic.fr/domain/exemple.fr : réponse JSON de l’AFNIC, champs stables
• curl -sL -o /dev/null -w '%{http_code}' https://rdap.org/domain/exemple.fr : redirection vers le bon serveur RDAP, le code final tranche

Lire un WHOIS ou un RDAP sans se tromper

Trois blocs d’information méritent votre attention. Les dates, d’abord : en RDAP elles sont dans le tableau events, avec les eventAction registration, expiration et last changed. Le bureau d’enregistrement ensuite, identifié par son nom et son numéro IANA, qui vous dit à qui écrire pour un transfert ou une restauration. Les statuts EPP enfin, souvent ignorés alors qu’ils expliquent la majorité des situations bloquées.

Le titulaire, lui, est rarement visible. Depuis l’entrée en application du RGPD en mai 2018, les données personnelles des personnes physiques sont masquées, remplacées par une mention du type REDACTED FOR PRIVACY. Sur .fr, l’AFNIC applique une diffusion restreinte aux personnes physiques et publie les coordonnées des personnes morales ; passer par le formulaire de l’AFNIC est alors la seule voie pour joindre un titulaire particulier. Un WHOIS masqué n’est donc pas un indice de dissimulation, c’est le comportement par défaut.

Statut EPP	Signification	Conséquence pratique
ok / active	Aucun verrou posé	Rien à signaler, transfert possible
clientTransferProhibited	Verrou posé par le bureau d’enregistrement	Le transfert échoue tant que le verrou n’est pas levé ; c’est une protection normale
clientHold ou serverHold	Le domaine est retiré de la zone du TLD	Plus aucune résolution : site et messagerie tombent alors que le domaine est toujours enregistré
autoRenewPeriod	Renouvellement automatique appliqué, jusqu’à 45 jours	Le domaine répond encore mais la facture peut ne pas être réglée
redemptionPeriod	Période de rachat après expiration, 30 jours	Restauration possible auprès du bureau d’enregistrement, avec des frais élevés
pendingDelete	Suppression engagée, 5 jours	Plus de restauration possible, le nom sera libéré à l’issue du délai

Contrôler un domaine que vous gérez déjà

Diagnostiquez de haut en bas : registre, puis délégation dans la zone du TLD, puis contenu de la zone chez l’hébergeur DNS. dig +trace part de la racine et montre précisément l’étage où la chaîne casse, ce qu’un dig ordinaire vers un résolveur public ne dira pas.

Cas de panne typique, et il revient souvent : un site inaccessible, aucune réponse DNS, une équipe qui cherche pendant une heure du côté de l’hébergeur. Le WHOIS affiche clientHold et une date d’expiration dépassée de quatre jours. Ce n’est pas une panne technique, c’est une carte bancaire expirée chez le bureau d’enregistrement. Regarder les statuts EPP en premier fait gagner ce temps-là.

Prévoyez aussi le délai de cache. La délégation NS d’un .com est servie avec un TTL de 172800 secondes, soit 48 heures, et une réponse négative reste en cache selon la règle du RFC 2308 (le plus petit du champ minimum du SOA et du TTL de cet enregistrement), ce qui donne de l’ordre du quart d’heure sur les grands TLD. Une modification qui « ne passe pas » est le plus souvent une modification déjà faite, pas encore expirée côté résolveur.

• dig +trace exemple.fr : suit la délégation depuis la racine, sans passer par un cache
• dig +short NS exemple.fr @8.8.8.8 : ce que voit un résolveur public, cache compris
• dig +short MX exemple.fr puis dig +short TXT exemple.fr : messagerie et SPF, les deux causes habituelles de mails rejetés après une migration
• echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null | openssl x509 -noout -dates : dates de validité du certificat réellement servi

Vérifier un domaine avant de lui faire confiance ou de l’acheter

Un nom qui s’affiche correctement à l’écran peut contenir des caractères non latins. Le domaine xn--80ak6aa92e.com s’écrit avec un a cyrillique et se rend visuellement comme apple.com dans les navigateurs qui n’appliquent pas de règle de mélange d’alphabets. Le préfixe xn-- (RFC 3492) est le signal : si le WHOIS ou l’URL décodée le fait apparaître, le nom n’est pas celui que vous croyez lire. Un simple idn -u ou python3 -c "import idna; print(idna.decode('xn--80ak6aa92e'))" tranche.

Pour un domaine reçu par mail, la date de création dans le RDAP vaut un premier tri. Un nom enregistré il y a quelques jours qui demande un paiement mérite un traitement différent d’un nom déposé en 2011. C’est un indice, pas une preuve : les fraudeurs rachètent aussi des domaines anciens.

Avant un achat, deux vérifications s’ajoutent. La disponibilité technique ne donne aucun droit d’usage : un nom libre au registre peut reproduire une marque déposée, consultable dans la base de l’INPI pour la France ou eSearch pour l’EUIPO, et l’exploiter vous expose à une procédure SYRELI pour les .fr ou UDRP pour les gTLD. Le passé du nom compte aussi s’il s’agit d’un domaine expiré : l’archive web montre ce qui y était publié, et les listes de blocage antispam indiquent s’il a servi à des envois massifs. Aucun outil public ne dit de manière fiable si un domaine a été sanctionné par un moteur de recherche ; ces contrôles donnent des faisceaux d’indices, pas une réponse binaire.

Questions fréquentes

Le WHOIS dit que le domaine est libre, mais le site s’affiche. Pourquoi ?

Trois causes possibles. Vous avez interrogé le serveur WHOIS d’une autre extension, votre requête a été limitée en débit et la réponse vide ressemble à un « no match », ou le registre pratique un WHOIS allégé qui renvoie vers celui du bureau d’enregistrement. Rejouez la vérification en RDAP : le code HTTP, 200 ou 404, ne laisse pas place à l’interprétation.

Un domaine expiré est-il disponible tout de suite ?

Non. Sur un gTLD, la date d’expiration est suivie d’une période de renouvellement automatique pouvant aller jusqu’à 45 jours, puis d’une période de rachat de 30 jours, puis de 5 jours de pendingDelete. Le nom peut donc rester indisponible près de trois mois après la date affichée, et le titulaire d’origine reste prioritaire pendant presque toute cette durée.

Comment savoir qui détient un domaine en .fr ?

Interrogez rdap.nic.fr ou whois.nic.fr. Si le titulaire est une personne morale, ses coordonnées sont publiées. S’il s’agit d’une personne physique, l’AFNIC applique la diffusion restreinte : les champs sont masqués et le contact passe par le formulaire prévu par l’AFNIC.

Vérifier un nom le réserve-t-il ?

Aucunement. Une requête WHOIS ou RDAP est une consultation en lecture. Tant que l’enregistrement n’est pas payé et confirmé par le registre, le nom reste disponible pour n’importe qui.

dig ne renvoie plus rien sur mon domaine, que regarder en premier ?

Le WHOIS, avant l’hébergeur DNS. Cherchez un statut clientHold ou serverHold et comparez la date d’expiration à la date du jour. Si les deux sont normaux, passez à dig +trace pour voir si la délégation NS existe encore dans la zone du TLD.

À lire aussi

commande dig · certificat ssl · codes statut http · cloudflare dns 1 1 1 1

Testez vos connaissances