« No Registry RDAP Server » : comment obtenir malgré tout des données de domaines

Tôt ou tard, tout projet de données de domaines tombe sur le même message : « no registry rdap server was identified for this domain ». Ce n'est pas un bug dans votre script. Cela signifie que l'outil n'a pas trouvé de point d'accès RDAP pour ce TLD, et aucune tentative supplémentaire n'y changera quoi que ce soit. Ce guide explique pourquoi l'erreur survient, quelles portions de l'espace de nommage elle concerne, et comment construire un jeu de données exploitable à partir de fichiers de zone et d'enrichissement en masse plutôt que de requêtes en direct domaine par domaine.

EN BREF / À RETENIR

• L'erreur traduit une lacune du protocole, pas une panne réseau : l'adoption de RDAP est obligatoire pour les gTLD mais facultative pour la plupart des ccTLD ; une large part de l'espace de nommage ne dispose donc tout simplement d'aucun serveur RDAP à interroger.
• Les requêtes en direct ne passent pas à l'échelle : les registres limitent agressivement le débit, masquent les champs du titulaire au titre du RGPD et ne répondent que pour un domaine à la fois. Ce modèle s'effondre bien avant le million de domaines.
• Les fichiers en masse sont l'alternative pragmatique : un fichier de zone liste directement les domaines enregistrés dans un TLD, sans requête individuelle ni dépendance à RDAP.
• WebTrackly distribue des fichiers en masse, pas un service de requêtes : 1 538 packages — 716 fichiers de zone par TLD, 716 ensembles de zones enrichis (NS, MX, IP, CMS détecté), 79 listes de sites par technologie et 27 jeux de données sélectionnés.
• Ampleur de la couverture : 279 944 703 domaines répartis dans les packages de zones, dont 163 422 083 en .com ; le jeu de données de tous les domaines enregistrés compte 272 614 863 lignes.
• Contenu des fichiers : noms de domaine, serveurs de noms, enregistrements MX, IP résolues et CMS détecté lorsque l'information est disponible. Aucune donnée de contact personnelle : ni e-mails, ni numéros de téléphone, ni noms de titulaires.
• La livraison se fait par téléchargement : un CSV dans une archive ZIP, générée au moment de l'achat, à partir de $3.50 par package. Le traitement se fait sur votre machine, avec les outils que vous utilisez déjà.

SOMMAIRE

1. Pourquoi l'erreur « No Registry RDAP Server » survient
2. Cinq usages où les données de domaines en masse font vraiment la différence
3. À quoi ressemblent les fichiers, et ce qui les distingue des requêtes en direct
4. Exploiter les données : acheter, télécharger, traiter en local
5. Erreurs courantes dans l'acquisition de données de domaines
6. Questions fréquentes
7. Conclusion
8. Ressources associées

Pourquoi l'erreur « No Registry RDAP Server » survient

RDAP (Registration Data Access Protocol) est le successeur structuré de WHOIS, fondé sur JSON. Plutôt que d'analyser du texte libre, un client résout le serveur faisant autorité pour un TLD et reçoit une réponse typée. C'est à l'étape de résolution que tout se bloque : le client RDAP consulte le registre d'amorçage de l'IANA et, si le TLD n'y figure pas, il n'a nulle part où envoyer sa requête. C'est précisément ce que signale le message « no registry rdap server was identified for this domain ».

La lacune est structurelle. La ratification RDAP de l'ICANN impose un service RDAP aux registres de gTLD et aux bureaux d'enregistrement accrédités, mais les ccTLD relèvent de politiques nationales et échappent à ce contrat. Beaucoup n'exploitent que WHOIS, certains proposent un formulaire web avec CAPTCHA, d'autres ne publient rien d'exploitable par une machine. Ainsi, le script qui renvoie un objet JSON propre pour example.com renvoie l'erreur RDAP pour une longue traîne de domaines nationaux — et cette traîne n'a rien de marginal.

Deux contraintes supplémentaires pèsent même lorsqu'un serveur RDAP existe. D'abord les limites de débit : les registres protègent un service conçu pour des consultations ponctuelles, et une interrogation en masse soutenue fait rapidement brider ou bloquer votre IP. Ensuite le masquage : depuis le RGPD, le nom, l'e-mail et l'adresse postale du titulaire sont retirés des réponses publiques pour la plupart des domaines ; les champs que l'on espère généralement extraire n'y figurent tout simplement pas. RDAP excelle à vous donner le statut, les dates et les serveurs de noms d'un domaine qui vous intéresse déjà. Il n'a jamais été conçu comme un mécanisme de découverte.

La découverte est un problème différent, qui appelle une source différente : les fichiers de zone. Un fichier de zone, c'est la liste tenue par le registre lui-même des domaines délégués dans un TLD, accompagnée de leurs enregistrements de serveurs de noms. Il ne nécessite aucune requête par domaine, n'est pas affecté par les lacunes d'amorçage RDAP, et constitue la seule méthode qui fournisse un véritable dénominateur plutôt qu'un échantillon. Si votre question est « quels domaines existent dans ce TLD, et quelle est leur infrastructure », un fichier de zone y répond directement ; RDAP n'y répondra jamais, quel que soit le nombre de tentatives que vous programmez.

WebTrackly est bâti autour de cette distinction. Le catalogue compte 1 538 packages téléchargeables : 716 fichiers de zone par TLD, 716 ensembles enrichis couvrant les mêmes zones avec serveurs de noms, enregistrements MX, IP résolues et CMS détecté, 79 listes de sites regroupées par technologie et 27 jeux de données sélectionnés. Ensemble, les packages de zones couvrent 279 944 703 domaines, dont 163 422 083 en .com. Rien n'est interrogé en direct au moment de la demande : vous achetez un package, téléchargez un ZIP et travaillez sur le CSV qu'il contient.

Besoin de la liste des domaines plutôt que d'une requête isolée ?
Parcourez le catalogue de données de domaines — fichiers de zone et ensembles de zones enrichis avec NS, MX, IP et CMS.
Parcourir les bases → | Voir les tarifs →

Cinq usages où les données de domaines en masse font vraiment la différence

Les données de zone et d'enrichissement en masse répondent à des questions de population. Elles vous disent combien de domaines existent, sur quoi ils tournent et où ils résolvent. Elles ne vous disent pas à qui écrire : c'est une autre catégorie de données, absente de ces fichiers. Les cas d'usage ci-dessous sont ceux que ces données servent réellement.

1. Dimensionner un marché par technologie

• Pour qui : fondateurs de SaaS, responsables produit et analystes qui évaluent un marché adressable.
• Le problème : les chiffres d'adoption publiés par les éditeurs proviennent généralement d'un échantillon des N sites les plus populaires, ce qui surestime systématiquement les outils d'entreprise et sous-estime la longue traîne.
• L'apport des données en masse : le champ de détection du CMS dans les ensembles de zones enrichis et les listes de sites par technologie fournissent des comptages absolus rapportés à un dénominateur connu. WordPress apparaît sur 21 639 326 domaines du catalogue ; Joomla sur 607 765. Ce sont des comptages sur la population de zones explorée, non une extrapolation à partir d'un échantillon de sites célèbres.
• Comment les lire : indiquez toujours le dénominateur à côté du comptage. « 21,6 M de domaines WordPress sur 279,9 M couverts » est une affirmation défendable ; « WordPress fait tourner X % du web » ne l'est pas, sauf à préciser exactement quel web vous avez mesuré.

2. Analyse de l'infrastructure et de l'hébergement

• Pour qui : hébergeurs, fournisseurs de CDN, analystes d'infrastructure.
• Le problème : les parts de marché de l'hébergement relèvent surtout de la conjecture, puisque personne ne publie son nombre de clients.
• L'apport des données en masse : les ensembles enrichis contiennent le serveur de noms et l'IP résolue de chaque domaine. Regrouper par suffixe NS approxime le fournisseur DNS ; associer les IP aux AS annonceurs approxime le réseau d'hébergement. Les deux se comptent directement sur une zone entière.
• Une réserve à énoncer : un CDN placé devant une origine masque l'IP de celle-ci. Traitez les parts d'hébergement déduites des IP comme une mesure de la périphérie, non de l'emplacement physique du serveur.

3. Recherche sur l'infrastructure de messagerie

• Pour qui : équipes délivrabilité, chercheurs en sécurité e-mail, analystes anti-abus.
• Le problème : des questions comme « quelle part de ce TLD utilise Google Workspace plutôt que Microsoft 365 ou une messagerie auto-hébergée ? » n'ont aucune réponse publique.
• L'apport des données en masse : les enregistrements MX figurent dans les ensembles de zones enrichis. Classer les noms d'hôtes MX par motif de fournisseur transforme la zone entière en une distribution que vous pouvez représenter graphiquement ; rejouer l'exercice sur un instantané ultérieur met en évidence les migrations entre fournisseurs.
• Ce que cela ne donne pas : un enregistrement MX est une cible de routage du courrier, pas une boîte aux lettres. Ces fichiers ne contiennent aucune adresse.

4. Recherche en sécurité et mesure de la surface d'attaque

• Pour qui : chercheurs en sécurité, équipes CERT, analystes en renseignement sur les menaces.
• Le problème : une reconnaissance qui dépend de RDAP ou WHOIS en direct cale immédiatement : les limites de débit et l'erreur de serveur RDAP absent rendent impossible la couverture d'une zone complète.
• L'apport des données en masse : partez de la liste de zone plutôt que de requêtes. Filtrez en local la population qui vous intéresse (un CMS, un serveur de noms, une plage d'IP), puis dirigez vos propres outils de scan ou de vérification vers ce sous-ensemble. La liste de domaines est l'entrée de votre analyse, pas l'analyse elle-même.
• Note de responsabilité : tout test actif doit rester dans un périmètre pour lequel vous êtes autorisé. Une liste de domaines téléchargeable ne constitue pas une autorisation.

5. Construire et maintenir votre propre jeu de données

• Pour qui : ingénieurs et scientifiques des données qui ont besoin d'une table de référence au niveau du domaine.
• Le problème : développer son propre crawler pour couvrir une zone entière suppose résolveurs, tentatives de reprise, stockage, déduplication et maintenance permanente — un chantier considérable avant même d'avoir répondu à la moindre question.
• L'apport des données en masse : un package de zone est déjà un CSV plat, une ligne par domaine. Chargez-le dans DuckDB, ClickHouse ou Postgres, joignez-le à vos tables internes, et retéléchargez un instantané récent lorsque vous avez besoin d'un différentiel. Chaque package est généré au moment de l'achat : un nouvel achat vous fournit donc un instantané actuel à comparer au précédent.
• Remarque pratique : conservez et datez chaque instantané téléchargé. L'évolution dans le temps est ce que ces données produisent de plus précieux, et vous ne pouvez la calculer que si vous avez gardé le fichier antérieur.

À quoi ressemblent les fichiers, et ce qui les distingue des requêtes en direct

Deux points méritent d'être précisés concrètement : la forme des données que vous recevez, et ce qui la différencie du résultat d'une requête RDAP ou WHOIS en direct.

Tableau 1 : exemples de lignes d'un package de zone enrichi

Chaque package est un CSV placé dans une archive ZIP. Un package de fichier de zone contient la liste des domaines ; un package enrichi y ajoute les colonnes de résolution et de détection présentées ci-dessous. Les champs sont renseignés lorsque l'information a pu être déterminée, et laissés vides sinon.

Voilà l'intégralité du contenu. Aucune colonne de contact, aucune colonne d'entreprise, aucune colonne de titulaire : les données d'enregistrement personnelles sont masquées à la source pour la plupart des domaines, et ces packages ne cherchent pas à les reconstituer. Si votre processus part du principe qu'une adresse e-mail accompagnera le domaine, c'est le moment de le repenser.

Tableau 2 : fichiers en masse, requêtes RDAP/WHOIS en direct et scanners en direct

Ces approches sont complémentaires, pas substituables. RDAP reste l'outil adapté lorsque vous avez besoin du statut faisant autorité d'un domaine précis. Un scanner en direct est l'outil adapté lorsqu'il vous faut, sur-le-champ, une empreinte technologique détaillée d'un site. Les fichiers en masse sont l'outil adapté lorsque la question porte sur une population — et ce sont les seuls des trois à être immunisés contre le problème du serveur RDAP absent, puisqu'ils n'effectuent jamais la moindre requête.

Exploiter les données : acheter, télécharger, traiter en local

Il n'y a pas d'interface de recherche pour filtrer, ni de requête côté serveur à exécuter. Le principe est le suivant : choisir un package, l'acheter, télécharger le ZIP et filtrer sur votre propre machine.

Étape 1 : trouver le package

Parcourez /zones/ pour les fichiers de zone par TLD et les ensembles de zones enrichis, /datasets/ pour les collections sélectionnées, et /packages/ pour le catalogue complet, listes de sites par technologie comprises. Chaque fiche indique le nombre de lignes avant l'achat : vous savez donc quelle volumétrie vous achetez.

Étape 2 : acheter et télécharger

Les packages démarrent à $3.50 et se téléchargent immédiatement. Le fichier est exporté au moment de l'achat : l'instantané reflète donc l'état du catalogue à cet instant, et non une compilation obsolète. Les formules par abonnement couvrent les usages récurrents : Pro à $29/month inclut 50 packages et 10 jeux de données avec 30 000 appels API ; Enterprise à $99/month inclut 200 packages et 50 jeux de données avec 300 000 appels API. Le détail figure sur /pricing/.

Étape 3 : décompresser et inspecter

unzip com-enriched.zip
head -3 com-enriched.csv
wc -l com-enriched.csv

Étape 4 : filtrer en ligne de commande pour les coupes rapides

# domains whose detected CMS is WordPress
awk -F',' '$5 == "WordPress"' com-enriched.csv > wordpress.csv

# domains on Google Workspace mail
grep -i 'google.com' com-enriched.csv | cut -d',' -f1 > gsuite-domains.txt

# name server distribution, top 20
cut -d',' -f2 com-enriched.csv | sort | uniq -c | sort -rn | head -20

Étape 5 : passer à un moteur colonnaire pour tout traitement analytique

Dès lors que vous joignez des fichiers ou agrégez des centaines de millions de lignes, passez à DuckDB ou ClickHouse. DuckDB lit le CSV directement, sans étape d'import :

-- CMS distribution across the zone
SELECT cms, count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE cms IS NOT NULL
GROUP BY cms
ORDER BY domains DESC;

-- domains present in this month's snapshot but not last month's
SELECT n.domain
FROM read_csv_auto('com-2026-07.csv') n
LEFT JOIN read_csv_auto('com-2026-06.csv') o USING (domain)
WHERE o.domain IS NULL;

Cette seconde requête mérite d'en faire une habitude. Un instantané isolé décrit un état ; deux instantanés décrivent une évolution, et c'est dans l'évolution que réside le signal.

Étape 6 : automatiser l'accès au catalogue via l'API

L'API expose le catalogue de packages — ce qui existe, ce que cela coûte, combien de lignes chacun contient — afin que vous puissiez scripter la découverte et les téléchargements. Ce n'est pas un point d'accès de requête sur un domaine.

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

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

# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

La référence complète des points d'accès se trouve sur /api/. Un schéma courant consiste à programmer une tâche qui liste les packages que vous suivez, vérifie si une compilation plus récente est disponible, la télécharge et la charge dans votre entrepôt à côté de l'instantané précédent.

Erreurs courantes dans l'acquisition de données de domaines

1. Prendre les requêtes en direct pour une source de données en masse.

   • Ce qui dérape : limites de débit, délais dépassés et erreur de serveur RDAP absent transforment un traitement de 500 000 domaines en script qui ne se termine jamais et produit des résultats partiels auxquels vous ne pouvez pas vous fier.
   • Pourquoi : RDAP et WHOIS sont des protocoles conçus domaine par domaine, avec un niveau de service pensé pour cet usage. L'usage en masse est hors périmètre par construction.
   • La solution : récupérez la population depuis un fichier de zone, puis réservez les requêtes au petit sous-ensemble pour lequel vous avez réellement besoin d'un statut faisant autorité.

2. Attendre des coordonnées dans des données de domaines.

   • Ce qui dérape : un pipeline est conçu autour d'une colonne e-mail qui n'arrive jamais, et le projet s'enlise à la dernière étape.
   • Pourquoi : depuis le RGPD, les champs de contact du titulaire sont masqués dans les réponses publiques WHOIS et RDAP pour la plupart des domaines. Les jeux de données de domaines en masse, y compris ceux-ci, contiennent des attributs d'infrastructure et non des données personnelles.
   • La solution : décidez d'emblée s'il vous faut un jeu de données au niveau du domaine ou un jeu de données de contacts. Ce sont deux produits distincts, avec des fondements juridiques distincts ; ne comptez pas sur l'un pour obtenir l'autre.

3. Travailler à partir d'un seul instantané.

   • Ce qui dérape : vous pouvez décrire l'état actuel mais démontrer aucune tendance — ce qui est pourtant la question réellement posée la plupart du temps.
   • Pourquoi : mesurer une évolution suppose deux observations. Un seul fichier ne peut produire aucun écart.
   • La solution : archivez et datez chaque téléchargement. Comparer deux instantanés révèle les nouveaux enregistrements, les domaines abandonnés et les migrations entre hébergeurs ou fournisseurs de messagerie.

4. Prendre la détection de CMS pour une certitude.

   • Ce qui dérape : une analyse avance un chiffre précis qu'un concurrent contredit avec une méthode de détection légèrement différente.
   • Pourquoi : la détection repose sur des empreintes. Les front-ends découplés, la mise en cache agressive et les transformations opérées par les CDN masquent la plateforme sous-jacente, et un champ CMS vide signifie « non détecté », pas « aucun CMS ».
   • La solution : indiquez le taux de détection à côté de chaque part de marché, et précisez explicitement que les chiffres décrivent des installations détectées.

5. Supposer qu'une IP de résolution identifie l'hébergeur.

   • Ce qui dérape : les parts de marché de l'hébergement ressortent dominées par une poignée de réseaux de CDN.
   • Pourquoi : lorsqu'un site est placé derrière un CDN ou un proxy inverse, l'enregistrement A publié appartient au réseau de périphérie, pas au serveur d'origine.
   • La solution : distinguez « fournisseur de périphérie/CDN » et « hébergeur d'origine » dans votre modèle, et utilisez les données de serveurs de noms comme second signal indépendant.

6. Sous-exploiter les enregistrements NS et MX.

   • Ce qui dérape : l'analyse s'arrête au champ CMS et les colonnes les plus riches restent inexploitées.
   • Pourquoi : NS et MX sont peu coûteux à analyser et remarquablement stables — les organisations changent de CMS bien plus souvent que de fournisseur DNS ou de messagerie.
   • La solution : établissez une fois pour toutes des règles de classification des fournisseurs à partir des noms d'hôtes NS et MX, puis réutilisez-les sur chaque zone que vous téléchargez.

Questions fréquentes

Q : Pourquoi l'erreur « no registry rdap server was identified for this domain » n'apparaît-elle que pour certains TLD ?
R : le service RDAP est contractuellement obligatoire pour les gTLD mais facultatif pour les ccTLD, qui relèvent de politiques nationales. Si un TLD n'a pas d'entrée dans le registre d'amorçage de l'IANA, le client RDAP ne peut pas déterminer où envoyer la requête et signale exactement cette erreur. C'est une lacune d'adoption du protocole, pas un défaut de votre client.

Q : WebTrackly effectue-t-il des requêtes RDAP ou WHOIS à ma place ?
R : non. WebTrackly distribue des fichiers en masse préparés à l'avance. Vous achetez un package, téléchargez un ZIP contenant un CSV et le traitez vous-même. Il n'existe aucun service de requête domaine par domaine.

Q : Que contient exactement un package ?
R : les packages de fichiers de zone contiennent la liste des domaines d'un TLD. Les packages de zones enrichis y ajoutent les serveurs de noms, les enregistrements MX, les IP résolues et le CMS détecté lorsque ces éléments ont pu être déterminés. Les packages par technologie sont des listes de sites sur lesquels un CMS ou une technologie donnée a été détecté. Les jeux de données sélectionnés sont des compilations multi-zones, la plus vaste étant celle de tous les domaines enregistrés, avec 272 614 863 lignes.

Q : Les adresses e-mail ou numéros de téléphone sont-ils inclus ?
R : non. Les packages ne contiennent que des attributs de domaine et d'infrastructure. Aucun fichier ne comporte de coordonnées personnelles ou d'entreprise.

Q : Quelle est l'ampleur de la couverture ?
R : 1 538 packages au total — 716 fichiers de zone, 716 ensembles de zones enrichis, 79 listes de sites par technologie et 27 jeux de données sélectionnés. Les packages de zones couvrent ensemble 279 944 703 domaines, dont 163 422 083 en .com. WordPress est détecté sur 21 639 326 domaines et Joomla sur 607 765.

Q : Les données sont-elles à jour ?
R : chaque package est exporté au moment de l'achat : vous recevez donc la compilation courante, et non un fichier préparé des mois auparavant. Pour suivre l'évolution, rachetez le même package plus tard et comparez les deux instantanés.

Q : À quoi sert l'API ?
R : elle expose le catalogue. GET /api/v1/packages/?type=zone liste les packages de zones, ?type=technology&q=wordpress filtre les packages par technologie selon un mot-clé, et /api/v1/packages/{slug}/ renvoie le détail d'un package. L'authentification se fait par jeton bearer. L'API n'accepte pas un nom de domaine en entrée pour en retourner les caractéristiques.

Q : Combien cela coûte-t-il ?
R : les packages individuels démarrent à $3.50 en achat unique. Pro coûte $29/month pour 50 packages et 10 jeux de données avec 30 000 appels API ; Enterprise coûte $99/month pour 200 packages et 50 jeux de données avec 300 000 appels API. Voir /pricing/.

Q : Quelle différence avec BuiltWith ou Wappalyzer ?
R : ces outils réalisent une empreinte approfondie de sites individuels et constituent le meilleur choix pour analyser une propriété en détail. Les packages en masse couvrent des zones entières avec une profondeur moindre par domaine, ce qu'exigent précisément les questions de population. Ils répondent à des questions différentes.

Conclusion

« No registry rdap server was identified for this domain » est une caractéristique permanente de l'espace de nommage, pas une panne passagère. La couverture RDAP est inégale par construction, les champs du titulaire sont masqués, et des protocoles conçus domaine par domaine ne peuvent pas répondre à des questions de population, quelle que soit la façon dont on les scripte.

La réponse pragmatique consiste à changer de source de données plutôt que de logique de reprise. Les fichiers de zone et les ensembles de zones enrichis vous donnent la liste des domaines, leurs serveurs de noms, leur routage de courrier, leurs adresses résolues et, lorsque c'est détectable, leur CMS — sous forme de CSV plat que vous traitez en local avec grep, DuckDB ou ClickHouse. Ils ne contiennent aucune donnée de contact, et le savoir dès le départ est précisément ce qui évite à un projet d'échouer à la dernière étape.

Parcourir le catalogue de données de domaines →

Ressources associées

• Catalogue des packages — 1 538 bases de domaines téléchargeables
• Fichiers de zone par TLD — .com, .net, .de et plus de 700 autres
• Jeux de données sélectionnés — tous les domaines enregistrés, serveurs MX, e-commerce
• Documentation de l'API — accès au catalogue avec un jeton bearer
• Tarifs — achats uniques à partir de $3.50