Comment fonctionnent les verificateurs de disponibilité de domaine

Vous cherchez un domaine sur deux outils différents. L'un dit "disponible". L'autre dit "pris". Les deux ont raison, ils interrogent des sources de données différentes avec des fréquences de mise à jour différentes. Cela arrive plus souvent qu'on ne le réalise, et comprendre pourquoi permet de choisir le bon outil selon la situation. Cet article explique les trois mécanismes principaux de vérification de disponibilité, pourquoi les résultats divergent, et ce que "disponible" garantit vraiment (moins que vous ne le pensez).

Les trois mécanismes de vérification de disponibilité

Mécanisme 1 : le cache propriétaire du registrar

Les grands registrars comme GoDaddy ou OVH maintiennent leurs propres bases de données de domaines enregistrés, synchronisées périodiquement avec le registre officiel. Quand vous faites une recherche sur leur site, vous interrogez leur cache, pas le registre directement.

L'avantage est la vitesse : leur cache est local, les réponses sont quasi-instantanées. L'inconvénient est la fraîcheur. Un domaine enregistré il y a dix minutes peut encore apparaître comme "disponible" dans le cache d'un registrar si leur synchronisation n'a pas encore tourné. À l'inverse, un domaine expiré il y a deux heures peut encore apparaître comme "pris" si leur cache ne l'a pas encore purgé.

Les caches de registrars servent aussi un objectif commercial : ils présentent souvent des domaines comme "disponibles à ce prix" alors qu'ils sont en réalité premium ou réservés, ce qui n'est pas la même chose qu'enregistrable au tarif standard.

Mécanisme 2 : WHOIS

WHOIS (RFC 3912) interroge directement le serveur WHOIS du registre ou du registrar, sans passer par un cache local. Les données sont plus fraîches qu'un cache propriétaire, mais le protocole présente des problèmes significatifs.

Le plus pratique : WHOIS n'a aucun format de réponse standardisé. La sortie WHOIS de Verisign pour .com est complètement différente de celle de l'AFNIC pour .fr, qui est différente de celle du DENIC pour .de. Tout parser qui traite des réponses WHOIS doit gérer des dizaines de formats différents, et il se trompe fréquemment sur les cas limites, formats de date inhabituels, caractères non-ASCII, domaines avec des chaînes de statut non standard.

Les registres throttlent aussi les requêtes WHOIS. En cas de vérifications en masse, vous atteignez rapidement les limites de taux.

Mécanisme 3 : RDAP

RDAP (Registration Data Access Protocol, RFC 7480/7483) est le successeur moderne de WHOIS. C'est une API REST qui retourne des réponses JSON avec une structure standardisée, ce qui résout le problème de parsing.

Le signal de disponibilité est simple : si un domaine existe dans le registre, RDAP retourne HTTP 200 avec les données du domaine. Si le domaine n'existe pas (ce qui signifie qu'il est disponible à l'enregistrement) RDAP retourne HTTP 404. Aucun parsing requis. Aucune ambiguïté.

Les données RDAP viennent directement du registre faisant autorité. Pour .com, c'est Verisign. Pour .fr, c'est l'AFNIC. Pas de couche intermédiaire entre la requête et la source de vérité canonique.

La limitation : RDAP n'est pas universel. La plupart des gTLDs (.com, .net, .org, .io, .app, .dev, et la majorité des nouveaux gTLDs) le supportent. Mais une grande partie des ccTLDs (notamment en Asie, Afrique et Europe de l'Est) n'offrent encore que WHOIS.

Pourquoi les outils donnent des résultats différents

La divergence des résultats vient de quatre sources :

• Sources de données différentes : un outil interrogeant RDAP et un outil interrogeant un cache registrar verront des choses différentes en temps réel. Aucun n'a tort, ils lisent des bases de données différentes.
• Délai de propagation : après l'enregistrement d'un domaine, le registre a besoin de quelques minutes pour mettre ses données à jour. Pendant cette fenêtre, certains checkers peuvent encore afficher "disponible".
• Différences d'interprétation : certains outils définissent "disponible" différemment. Un domaine en redemptionPeriod est techniquement enregistré mais ne peut pas être transféré ni utilisé, certains checkers disent "pris", d'autres "en expiration".
• Domaines premium et réservés : beaucoup de checkers ne distinguent pas entre un domaine librement disponible, un domaine premium (disponible à un prix plus élevé), et un domaine réservé (non disponible à l'enregistrement standard).

Ce que "disponible" signifie vraiment

Un checker qui affiche "disponible" ne garantit pas que le domaine sera enregistrable quand vous cliquerez sur "acheter".

Entre la vérification et la tentative d'enregistrement :

• Quelqu'un d'autre peut l'enregistrer dans les secondes entre votre recherche et votre achat.
• Le domaine peut être dans une période de grâce qu'un checker particulier ne remonte pas.
• Il peut s'agir d'un domaine premium à un prix nettement plus élevé.
• Le registre peut l'avoir placé dans une liste réservée.

Pour les domaines vraiment disponibles (HTTP 404 depuis RDAP sans statut particulier), la fenêtre est généralement courte, quelques secondes à quelques minutes. Pour les domaines en transition (redemption, pending delete), l'écart entre "s'affiche comme disponible" et "enregistrable maintenant" peut être significatif.

Comment Domain Sentinel effectue ses vérifications

Domain Sentinel interroge RDAP en priorité pour tous les TLDs qui le supportent. La requête va directement au registre, sans cache intermédiaire. Pour les ccTLDs sans RDAP, il bascule sur WHOIS.

Pour l'interface de lookup, cela signifie que le résultat affiché est aussi frais que possible, compte tenu de la latence de mise à jour du registre lui-même (typiquement quelques secondes à quelques minutes après un enregistrement ou une suppression).

Pour le monitoring watchlist, Domain Sentinel poll chaque domaine à intervalles réguliers et suit les transitions de statut. Quand un domaine passe de pendingDelete à 404 (supprimé et disponible), une alerte se déclenche.

Limites de l'approche RDAP

Certains registres throttlent les requêtes RDAP, ce qui peut ralentir les vérifications pour les très grands portefeuilles. Les ccTLDs sans RDAP ont des temps de réponse légèrement plus longs via WHOIS, et le parsing WHOIS produit parfois des dates d'expiration incorrectes pour des formats de registrar inhabituels.

Construire son propre checker : les API publiques

Pour les développeurs qui veulent interroger la disponibilité directement :

# Proxy universel via rdap.org (route automatiquement vers le bon registre)
curl -s https://rdap.org/domain/example.com
# HTTP 200 = le domaine existe (enregistré)
# HTTP 404 = le domaine n'existe pas (disponible)

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

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

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

Le fichier bootstrap IANA à https://data.iana.org/rdap/dns.json mappe chaque TLD vers son endpoint RDAP. C'est la liste de référence des TLDs qui supportent RDAP et où se trouvent leurs serveurs.

Aucun checker ne garantit qu'un domaine sera disponible dans 30 secondes. L'approche pratique : interroger RDAP directement (ou utiliser un outil qui le fait), agir vite quand vous trouvez ce que vous voulez, et mettre en watchlist tout ce que vous ne pouvez pas enregistrer immédiatement.