« No registry RDAP server was identified » : causes et solutions

Si une requête sur un domaine renvoie « no registry RDAP server was identified for this domain », c'est que l'interrogation n'a jamais atteint le moindre registre. Le client RDAP a échoué dès l'étape de bootstrap : il n'a pas réussi à associer le domaine de premier niveau à une URL de base RDAP. Cet article explique pourquoi cela se produit, comment fonctionne le registre bootstrap de l'IANA, comment vérifier vous-même la cause, et que faire lorsqu'un TLD ne dispose réellement d'aucun service RDAP — y compris dans les cas où un jeu de données de fichiers de zone remplace avantageusement les requêtes domaine par domaine.

En bref / Points clés

• Le message signifie que le client RDAP n'a trouvé aucune URL de base pour le TLD du domaine dans le registre bootstrap de l'IANA. Il s'agit d'un échec de résolution, pas d'une réponse « domaine introuvable ».
• Les trois causes habituelles sont : le TLD ne dispose d'aucun service RDAP (cas de la plupart des ccTLD), le client s'appuie sur une copie en cache obsolète du fichier bootstrap, ou la valeur fournie n'est pas un vrai TLD (faute de frappe, nom interne ou simple nom d'hôte).
• Une seule requête suffit à confirmer la cause : récupérez https://data.iana.org/rdap/dns.json et cherchez-y le TLD.
• L'ICANN impose RDAP aux gTLD sous contrat. Les ccTLD échappent à ce contrat : la disponibilité de RDAP y est facultative et inégale ; certains publient du RDAP, d'autres uniquement du WHOIS, d'autres encore rien d'exploitable par une machine.
• Là où RDAP existe mais pas WHOIS, ou l'inverse, une chaîne de repli — bootstrap RDAP, puis le point d'accès documenté par le registre lui-même, puis WHOIS sur le port 43 — résout la plupart des cas.
• Lorsque vous cherchez à savoir ce qui existe dans une zone plutôt qu'à obtenir l'enregistrement d'un domaine précis, les requêtes domaine par domaine sont le mauvais outil, que RDAP soit disponible ou non. Un jeu de données de fichiers de zone liste directement les domaines enregistrés.
• Les fichiers de zone et les jeux de données enrichis vous donnent les domaines et leur infrastructure (serveurs de noms, MX, IP, CMS détecté). Ils ne contiennent aucune coordonnée de titulaire, et aucun jeu de données de ce site n'en contient.

Sommaire

1. Ce que signifie réellement « No Registry RDAP Server Was Identified »
2. Comment le bootstrap RDAP identifie un serveur
3. Diagnostiquer la cause en trois vérifications
4. Les solutions de repli qui fonctionnent quand le bootstrap échoue
5. Quand le véritable objectif est l'énumération, pas la requête unitaire
6. Ce que contiennent réellement les fichiers
7. Le vrai flux de travail : acheter, télécharger, traiter en local
8. Trouver des packages via l'API
9. Erreurs fréquentes et comment les éviter
10. Questions fréquentes
11. Conclusion
12. Ressources associées

Ce que signifie réellement « No Registry RDAP Server Was Identified »

Le message d'erreur « no registry rdap server was identified for this domain » est un obstacle courant, et profondément bloquant, pour quiconque cherche à collecter des informations sur un domaine. Pour en saisir la portée et comprendre la réponse qu'y apporte WebTrackly, il faut d'abord comprendre RDAP lui-même. Le Registration Data Access Protocol (RDAP) est le successeur du vénérable protocole WHOIS ; il a été conçu pour offrir un accès plus structuré, plus sûr et plus normalisé aux données d'enregistrement des domaines. Reposant sur HTTP(S) et sur JSON pour le transfert des données, il est nettement plus exploitable par les machines et plus agréable pour les développeurs que son prédécesseur.

L'ICANN (Internet Corporation for Assigned Names and Numbers) a rendu l'adoption de RDAP obligatoire pour les gTLD (domaines de premier niveau génériques) comme .com, .org, .net et bien d'autres. L'objectif : améliorer l'accès aux données, la confidentialité et l'internationalisation. Mais Internet est vaste et décentralisé. Si les gTLD se conforment globalement à cette exigence, de nombreux ccTLD (domaines de premier niveau nationaux) comme .de (Allemagne) ou .jp (Japon) dépendent de registres différents et présentent des niveaux d'implémentation de RDAP très variables, voire inexistants.

Lorsque vous rencontrez « no registry rdap server was identified for this domain », cela traduit généralement l'une des situations suivantes :

1. TLD non pris en charge : le domaine de premier niveau concerné (par exemple un ccTLD peu connu ou un gTLD très récent) n'a tout simplement aucun serveur RDAP configuré ou reconnu par le système interrogateur. Le cas est fréquent chez les registres nationaux qui n'ont pas achevé leur transition depuis WHOIS ou qui exploitent leurs propres systèmes propriétaires.
2. Incident technique ou mauvaise configuration : le serveur RDAP du TLD existe peut-être, mais il est temporairement indisponible, mal configuré ou victime de problèmes réseau, d'où l'échec de la requête.
3. Services de confidentialité ou de proxy : bien que RDAP soit conçu pour mieux respecter la vie privée, certains domaines recourent à des services de protection qui masquent volontairement les données du titulaire. Ce n'est pas directement l'erreur « no registry RDAP server », mais c'est une difficulté connexe dans l'accès à des données exploitables.
4. Conventions de nommage non standard : certains domaines de niche ou internes ne respectent pas les structures encadrées par l'ICANN, ce qui les rend invisibles pour les résolveurs RDAP classiques.

Conséquence pratique : vous n'obtenez aucune réponse, et non une réponse faisant autorité du type « ce domaine n'est pas enregistré ». Les deux sont faciles à confondre et mènent à des conclusions radicalement différentes : un échec de bootstrap ne dit strictement rien sur l'existence ou non du domaine.

Les contournements manuels sont fastidieux et inefficaces. Vous pouvez essayer d'autres clients WHOIS, fouiller des archives de données historiques, voire inspecter les sites à la main. Cela consomme des heures, produit souvent des informations incomplètes ou périmées, et reste totalement inexploitable à l'échelle de centaines ou de milliers de domaines. La génération de leads et l'analyse de marché modernes exigent automatisation et exhaustivité.

Comment le bootstrap RDAP identifie un serveur

RDAP n'a pas de serveur central. Chaque registre exploite le sien, et c'est au client de découvrir lequel fait autorité pour un nom donné. Ce processus de découverte, défini par la RFC 7484, s'appelle le bootstrap.

L'IANA publie un fichier bootstrap pour les noms de domaine à l'adresse https://data.iana.org/rdap/dns.json. C'est un document JSON contenant un tableau services. Chaque entrée est un tableau à deux éléments : une liste de TLD, et une liste d'URL de base RDAP qui les desservent. Pour résoudre example.com, un client prend le label le plus à droite, com, cherche l'entrée de service qui le contient, puis émet GET {base_url}domain/example.com vers l'URL trouvée.

# Inspect the bootstrap file directly
curl -s https://data.iana.org/rdap/dns.json | head -c 400

# Check whether a specific TLD has an RDAP base URL at all
curl -s https://data.iana.org/rdap/dns.json \
  | python3 -c "import json,sys; d=json.load(sys.stdin); t=sys.argv[1]; \
print([s[1] for s in d['services'] if t in s[0]] or 'NO RDAP SERVICE FOR .'+t)" de

Si cette commande affiche NO RDAP SERVICE, l'erreur n'est pas un bug de votre client et aucune tentative supplémentaire n'y changera quoi que ce soit. Le TLD est purement et simplement absent du registre — exactement la situation que décrit le message.

Deux détails supplémentaires comptent. D'abord, le fichier porte un horodatage publication : les clients qui le mettent trop agressivement en cache peuvent ignorer un TLD nouvellement ajouté pendant plusieurs jours. Ensuite, la RFC 7484 impose une correspondance par plus long suffixe de labels : un client qui se contente naïvement du dernier label peut mal traiter les noms situés sous des suffixes à plusieurs labels. Les deux cas produisent le même message visible par l'utilisateur, pour des raisons différentes.

Diagnostiquer la cause en trois vérifications

1. Le suffixe est-il un vrai TLD ? Comparez-le à la liste des TLD de l'IANA disponible sur https://data.iana.org/TLD/tlds-alpha-by-domain.txt. Les noms internes (.local, .internal, .corp), les fautes de frappe et les noms d'hôte transmis avec un préfixe de sous-domaine sont les fausses alertes les plus courantes.
2. Le TLD figure-t-il dans le fichier bootstrap ? Utilisez la commande ci-dessus. Son absence est une réponse définitive : il n'existe aucun serveur RDAP à identifier.
3. La copie de votre client est-elle à jour ? Forcez une nouvelle récupération de dns.json et réessayez. De nombreuses bibliothèques et surcouches en ligne de commande mettent le fichier bootstrap en cache sur disque sans jamais l'expirer. Si une récupération fraîche résout le TLD mais que votre outil échoue toujours, le coupable est le cache.

Menées dans cet ordre, ces trois vérifications distinguent un problème de saisie d'un problème de client et d'une véritable lacune du registre — et chacun appelle un correctif différent.

Les solutions de repli qui fonctionnent quand le bootstrap échoue

Le Registry Agreement de l'ICANN et l'obligation liée au Registration Data Access Protocol s'appliquent aux gTLD. Les opérateurs de ccTLD ne sont pas parties à cet accord : leurs politiques en matière de données d'enregistrement sont définies au niveau national. C'est pourquoi .com, .org, .app et les gTLD récents se résolvent sans accroc, alors qu'une longue traîne de zones nationales échoue.

Voici une chaîne de repli qui couvre la plupart des cas réels :

1. Bootstrap IANA. La voie standard ; commencez par elle.
2. Le point d'accès RDAP documenté par le registre. Certains registres exploitent RDAP sans figurer dans le fichier bootstrap. Les pages TLD de l'IANA, à l'adresse https://www.iana.org/domains/root/db/<tld>.html, indiquent l'organisme gestionnaire et son service de données d'enregistrement.
3. WHOIS sur le port 43. Interrogez whois.iana.org sur le TLD lui-même pour connaître l'hôte WHOIS faisant autorité, puis interrogez cet hôte sur le domaine. La sortie est du texte non structuré : prévoyez une analyse syntaxique propre à chaque registre.
4. Le DNS comme test d'existence. Une requête NS ne remplace pas les données d'enregistrement, mais un jeu d'enregistrements NS délégué constitue un indice fort que le domaine est enregistré — souvent le seul fait dont vous aviez réellement besoin.

# Find the authoritative WHOIS host for a ccTLD, then query the domain
whois -h whois.iana.org de
whois -h whois.denic.de example.de

# Existence check via delegation
dig +short NS example.de

Aucune de ces méthodes ne restitue les coordonnées du titulaire. La plupart des registres les masquent par principe, et RDAP a précisément été conçu pour rendre ce masquage explicite, non pour exposer davantage de données.

Quand le véritable objectif est l'énumération, pas la requête unitaire

Une large part du trafic qui aboutit à cette erreur ne cherche pas à interroger un seul domaine. Elle cherche à répondre à une question de population : quels domaines existent dans ce TLD, lesquels utilisent tel CMS, lesquels pointent vers tel fournisseur de messagerie. RDAP domaine par domaine est un piètre instrument pour cela, même là où il fonctionne : il faudrait une requête par nom, et les registres appliquent des limites de débit en conséquence.

Pour ce type de question, la source de vérité est le fichier de zone, pas l'enregistrement d'inscription. Un fichier de zone liste les noms délégués d'un TLD. Il ne contient aucune information sur les titulaires — c'est précisément ce qui permet de le publier en masse.

WebTrackly distribue ces données sous la forme d'un catalogue de 1 538 packages :

• 716 fichiers de zone TLD — la liste des domaines délégués pour chaque zone couverte.
• 716 jeux enrichis par zone — les mêmes domaines, accompagnés des serveurs de noms, des enregistrements MX, de l'IP résolue et du CMS détecté.
• 79 listes de sites par CMS ou technologie — par exemple WordPress avec 21 639 326 domaines et Joomla avec 567 680.
• 27 jeux de données curatés — dont le jeu de tous les domaines enregistrés, fort de 272 614 863 lignes.

La couverture totale sur l'ensemble des zones atteint 285 582 781 domaines, dont 163 422 083 pour le seul .com. Parcourez le catalogue sur /packages/, les zones sur /zones/ et les jeux curatés sur /datasets/.

Ce que contiennent réellement les fichiers

Le format de téléchargement dépend du package et figure sur la page produit. Les colonnes dépendent du type de package :

• Fichiers de zone : le nom de domaine et, lorsque le registre la publie, la date d'enregistrement. Beaucoup de registres ne la publient pas ; le champ reste alors vide plutôt que d'être deviné.
• Jeux enrichis par zone : domaine, serveurs de noms (ns), serveurs de messagerie (mx), adresse IP résolue et CMS détecté lorsqu'il est identifiable.
• Listes technologies et CMS : les domaines sur lesquels la technologie a été détectée.

Ce que les fichiers ne contiennent pas, dans aucun package, mérite d'être énoncé tout aussi clairement :

• Aucun nom de titulaire, aucune adresse postale, adresse e-mail ni numéro de téléphone.
• Aucune fiche d'entreprise, intitulé de poste ni identifiant personnel.
• Aucun signal d'intention, de trafic ou de chiffre d'affaires.
• Aucune requête interactive domaine par domaine — le produit consiste en fichiers en masse, pas en une interface d'interrogation nom par nom.

Si votre processus repose sur les coordonnées des titulaires, ces données ne les fournissent pas — et RDAP non plus pour la grande majorité des domaines, le masquage étant désormais la règle par défaut sur les gTLD.

Le vrai flux de travail : acheter, télécharger, traiter en local

1. Choisissez un package. Sélectionnez la zone, la liste technologique ou le jeu de données curaté qui correspond à votre question. Les tarifs démarrent à $3.50 pour un achat unique ; voir /pricing/.
2. Achetez-le. L'export est généré au moment même de l'achat : le fichier reflète donc l'état du catalogue à cet instant, et non un instantané préconstruit d'âge inconnu.
3. Téléchargez. Le format de téléchargement dépend du package et figure sur la page produit.
4. Traitez en local. Les fichiers sont assez volumineux pour qu'un tableur soit le mauvais outil. Les utilitaires Unix se chargent du filtrage ; un moteur analytique embarqué gère les jointures et les agrégations.

unzip -o zone_example.zip -d ./data

# Count rows and inspect the header
wc -l ./data/*.csv
head -3 ./data/*.csv

# Filter by a nameserver operator without loading the file into memory
grep -F ',ns1.example-dns.net,' ./data/enriched.csv > ./data/subset.csv

-- DuckDB reads the CSV directly; no import step, no server
SELECT mx, count(*) AS domains
FROM read_csv_auto('./data/enriched.csv')
WHERE cms = 'WordPress'
GROUP BY mx
ORDER BY domains DESC
LIMIT 25;

Pour des analyses répétées sur plusieurs zones, charger les CSV dans ClickHouse et les interroger comme une table unique vaut le temps d'installation. Pour une question ponctuelle sur une seule zone, DuckDB directement sur le CSV mène plus vite à la réponse.

Trouver des packages via l'API

L'API expose le catalogue : elle vous indique quels packages existent et ce que chacun couvre. Ce n'est pas un point d'accès de recherche de domaines, et il n'existe aucune requête domaine par domaine. L'authentification se fait par jeton bearer.

# List zone-file packages
curl -s "https://webtrackly.com/api/v1/packages/?type=zone" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Search technology packages
curl -s "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Fetch details for one package
curl -s "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

Les abonnements incluent des quotas d'appels API : Pro à $29/mois couvre 50 packages et 10 jeux de données avec 30 000 appels API ; Enterprise à $99/mois couvre 200 packages et 50 jeux de données avec 300 000 appels API. La documentation complète est disponible sur /api/.

Erreurs fréquentes et comment les éviter

1. Interpréter l'échec de bootstrap comme « le domaine n'existe pas ».

   • Ce qui cloche : un pipeline marque des noms comme non enregistrés parce que l'appel RDAP a échoué, et la logique en aval agit sur cette base.
   • Le correctif : traitez l'échec de bootstrap comme un résultat indéterminé, doté de son propre code de statut, distinct d'une réponse négative faisant autorité. Confirmez l'existence séparément par une vérification de délégation DNS.

2. Mettre le fichier bootstrap en cache indéfiniment.

   • Ce qui cloche : un TLD qui a obtenu la prise en charge de RDAP il y a des mois échoue toujours localement parce que le dns.json en cache lui est antérieur.
   • Le correctif : rafraîchissez le fichier selon une planification et respectez son champ publication. Une actualisation quotidienne suffit.

3. Bâtir une stratégie ccTLD sur RDAP seul.

   • Ce qui cloche : les hypothèses de couverture calquées sur le comportement des gTLD s'effondrent sur les zones nationales, créant des trous silencieux dans le jeu de données.
   • Le correctif : tenez une cartographie explicite, TLD par TLD, du protocole disponible — RDAP, WHOIS ou aucun — et routez les requêtes en conséquence, plutôt que de réessayer un protocole qui n'a jamais été proposé.

4. Utiliser des requêtes domaine par domaine pour répondre à des questions de population.

   • Ce qui cloche : des millions de requêtes séquentielles, des limites de débit, des adresses sources bloquées et des semaines d'exécution pour une réponse qu'un seul fichier fournit.
   • Le correctif : utilisez des données au niveau de la zone quand la question porte sur une zone, et réservez les requêtes domaine par domaine au petit nombre de noms qui exigent réellement un enregistrement d'inscription à jour.

5. Attendre des coordonnées de titulaires de l'une de ces sources.

   • Ce qui cloche : un projet est cadré autour de données de contact que ni les politiques de masquage ni les formats de données en masse ne fournissent, et il s'enlise dès que cela devient évident.
   • Le correctif : cadrez votre projet sur ce qui est réellement publié — le domaine, sa délégation, son infrastructure de messagerie et d'hébergement, et sa pile logicielle détectée.

6. Analyser le texte WHOIS comme s'il s'agissait d'un format unique.

   • Ce qui cloche : un parseur écrit pour la sortie d'un registre attribue silencieusement les mauvais champs sur celle d'un autre, puisque WHOIS sur le port 43 n'a aucun schéma.
   • Le correctif : privilégiez le JSON de RDAP partout où il existe, et traitez le format de chaque serveur WHOIS comme une cible d'analyse distincte, avec ses propres tests.

Questions fréquentes

Q : Cette erreur signifie-t-elle que le domaine n'est pas enregistré ?
R : Non. Elle signifie que le client n'a pas pu déterminer quel serveur RDAP interroger. Après cette erreur, le statut d'enregistrement du domaine est inconnu, et non négatif. Une requête DNS sur les enregistrements NS du domaine est un moyen rapide et indépendant de vérifier s'il est délégué.

Q : Pourquoi tant de ccTLD échouent-ils ?
R : L'obligation RDAP de l'ICANN découle du Registry Agreement applicable aux gTLD, auquel les opérateurs de ccTLD ne sont pas parties. Leurs services de données d'enregistrement relèvent de politiques nationales : certains publient du RDAP, d'autres uniquement du WHOIS sur le port 43, d'autres encore rien d'exploitable par une machine.

Q : Puis-je corriger le problème en changeant de client RDAP ?
R : Seulement si la cause était un cache obsolète ou une mauvaise implémentation de la correspondance par plus long suffixe. Si le TLD est absent de dns.json, tout client conforme échouera de la même manière.

Q : Que contiennent les packages WebTrackly ?
R : Le format de téléchargement dépend du package et figure sur la page produit. Les packages de zone listent les domaines d'un TLD, ainsi que la date d'enregistrement lorsque le registre la publie. Les packages enrichis y ajoutent les serveurs de noms, les enregistrements MX, l'IP résolue et le CMS détecté. Les packages technologiques listent les domaines sur lesquels une technologie donnée a été détectée.

Q : Les fichiers contiennent-ils des e-mails ou des numéros de téléphone de titulaires ?
R : Non. Aucun package ne contient de données de contact personnelles, quelles qu'elles soient, et il n'existe aucune interface de requête domaine par domaine. Les données décrivent les domaines et leur infrastructure.

Q : Quel est le degré de fraîcheur d'un fichier téléchargé ?
R : L'export est généré au moment de l'achat à partir des données actuelles du catalogue : vous ne téléchargez donc pas une archive préconstruite d'âge inconnu.

Q : Quelle est la tarification ?
R : Les achats de packages à l'unité démarrent à $3.50. Les abonnements sont Pro à $29/mois (50 packages et 10 jeux de données, 30 000 appels API) et Enterprise à $99/mois (200 packages et 50 jeux de données, 300 000 appels API). Les détails figurent sur /pricing/.

Q : Que permet de faire l'API ?
R : Elle expose le catalogue de packages — lister et filtrer les packages par type, les rechercher, et récupérer le détail d'un package via son slug. Elle n'effectue aucune requête sur les domaines.

Conclusion

« No registry RDAP server was identified for this domain » est un échec de résolution au niveau du bootstrap, avec trois causes ordinaires : une valeur saisie qui n'est pas un vrai TLD, un fichier bootstrap en cache périmé, ou un TLD dépourvu de service RDAP. Une seule requête vers https://data.iana.org/rdap/dns.json vous dit laquelle des trois vous concerne, et chacune appelle un correctif propre : corriger la saisie, rafraîchir le cache, ou se rabattre sur l'hôte WHOIS documenté par le registre.

Si l'objectif de départ n'était pas un enregistrement d'inscription isolé mais un inventaire de ce qui existe dans une zone, le protocole était le mauvais instrument dès le début. Un jeu de données de fichiers de zone répond directement à cette question, en un seul fichier, avec les domaines et leur infrastructure — et sans les coordonnées de titulaires que ni RDAP ni les données en masse ne vous donneront.

Vous travaillez avec des données au niveau de la zone ?
Le format de téléchargement dépend du package et figure sur la page produit.
Parcourir les packages → | Voir les tarifs →

Ressources associées

• Catalogue de packages — plus de 1 500 bases de domaines téléchargeables
• Fichiers de zone par TLD — .com, .net, .de et plus de 700 autres
• Jeux de données curatés — tous les domaines enregistrés, serveurs MX, e-commerce
• Tarifs — achats à l'unité à partir de $3.50