„No Registry RDAP Server“: So kommen Sie trotzdem an Domaindaten

Früher oder später stößt jedes Domaindaten-Projekt auf dieselbe Meldung: „no registry rdap server was identified for this domain.“ Das ist kein Fehler in Ihrem Skript. Es bedeutet, dass die Tools keinen RDAP-Endpunkt für diese TLD ermitteln konnten – und kein noch so hartnäckiger Wiederholungsversuch wird daran etwas ändern. Dieser Leitfaden erklärt, warum der Fehler auftritt, welche Teile des Domain-Namensraums betroffen sind und wie Sie aus Zonendateien und Bulk-Anreicherung einen brauchbaren Datensatz aufbauen – statt aus Live-Abfragen für jede einzelne Domain.

KURZFASSUNG / DIE WICHTIGSTEN PUNKTE

• Der Fehler ist eine Protokolllücke, kein Netzwerkproblem: Für gTLDs ist RDAP verpflichtend, für die meisten ccTLDs jedoch optional. Ein großer Teil des Namensraums verfügt daher überhaupt nicht über einen RDAP-Server, den man abfragen könnte.
• Live-Abfragen skalieren nicht: Registries drosseln aggressiv, schwärzen Inhaberdaten aufgrund der DSGVO und beantworten immer nur eine Domain pro Anfrage. Dieses Modell bricht lange vor der ersten Million Domains zusammen.
• Bulk-Dateien sind die praktikable Alternative: Zonendateien listen die registrierten Domains einer TLD direkt auf – ohne Abfrage pro Domain und ohne RDAP-Abhängigkeit.
• WebTrackly liefert Bulk-Dateien, keinen Abfragedienst: 1,538 Pakete – 716 TLD-Zonendateien, 716 angereicherte Zonensätze (NS, MX, IP, erkanntes CMS), 79 Technologie-/CMS-Sitelisten und 27 kuratierte Datensätze.
• Umfang der Abdeckung: 285,582,781 Domains in den Zonenpaketen, davon 163,422,083 in .com; der Datensatz aller registrierten Domains umfasst 272,614,863 Zeilen.
• Inhalt der Dateien: Domainnamen, Nameserver, MX-Records, aufgelöste IPs und – sofern verfügbar – das erkannte CMS. Personenbezogene Kontaktdaten sind nicht enthalten: keine E-Mail-Adressen, keine Telefonnummern, keine Inhabernamen.
• Auslieferung erfolgt als Download: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Die Verarbeitung findet auf Ihrer Maschine statt, mit den Werkzeugen, die Sie ohnehin nutzen.

INHALTSVERZEICHNIS

1. Warum „No Registry RDAP Server“ auftritt
2. Fünf Aufgaben, für die Bulk-Domaindaten wirklich taugen
3. Wie die Dateien aussehen und wie sie sich zu Live-Abfragen verhalten
4. Arbeiten mit den Daten: kaufen, herunterladen, lokal verarbeiten
5. Typische Fehler bei der Beschaffung von Domaindaten
6. Häufig gestellte Fragen
7. Fazit
8. Weiterführende Ressourcen

Warum „No Registry RDAP Server“ auftritt

RDAP (Registration Data Access Protocol) ist der strukturierte, JSON-basierte Nachfolger von WHOIS. Statt Freitext zu parsen, ermittelt ein Client den autoritativen Server für eine TLD und erhält eine typisierte Antwort. Genau bei dieser Ermittlung bricht der Vorgang ab: Ein RDAP-Client fragt das IANA-Bootstrap-Register ab, und wenn die TLD dort keinen Eintrag hat, weiß der Client nicht, wohin er die Anfrage senden soll. Genau das meldet „no registry rdap server was identified for this domain“.

Die Lücke ist strukturell bedingt. Die RDAP-Ratifizierung der ICANN verpflichtet gTLD-Registries und akkreditierte Registrare zum Betrieb eines RDAP-Dienstes, ccTLDs unterliegen dagegen nationaler Politik und fallen nicht unter diesen Vertrag. Viele betreiben ausschließlich WHOIS, manche ein Webformular mit CAPTCHA, manche veröffentlichen überhaupt nichts maschinenlesbar. Dasselbe Skript, das für example.com ein sauberes JSON-Objekt zurückgibt, liefert deshalb für einen langen Schwanz an Länderdomains den RDAP-Fehler – und dieser Schwanz ist alles andere als klein.

Zwei weitere Einschränkungen zählen selbst dann, wenn ein RDAP-Server existiert. Erstens die Ratenbegrenzung: Registries schützen einen Dienst, der für gelegentliche Abfragen gedacht ist, und dauerhafte Massenabfragen führen zur Drosselung oder Sperrung Ihrer IP. Zweitens die Schwärzung: Seit der DSGVO werden Name, E-Mail-Adresse und Postanschrift des Inhabers bei den meisten Domains aus den öffentlichen Antworten entfernt – genau die Felder also, die man üblicherweise extrahieren möchte, stehen schlicht nicht in der Antwort. RDAP eignet sich hervorragend dafür, Status, Datumsangaben und Nameserver einer Domain zu liefern, die Sie ohnehin schon im Blick haben. Als Entdeckungsmechanismus war es nie gedacht.

Entdeckung ist ein anderes Problem mit einer anderen Datenquelle: Zonendateien. Eine Zonendatei ist die registryeigene Liste der delegierten Domains einer TLD samt ihren Nameserver-Records. Sie kommt ohne Abfrage pro Domain aus, ist von Lücken im RDAP-Bootstrap unberührt und liefert als einzige Methode einen echten Nenner statt einer Stichprobe. Lautet Ihre Frage „Welche Domains existieren in dieser TLD, und wie sieht ihre Infrastruktur aus?“, beantwortet eine Zonendatei sie unmittelbar – RDAP niemals, egal wie viele Wiederholungsversuche Sie programmieren.

WebTrackly ist genau um diese Unterscheidung herum gebaut. Der Katalog umfasst 1,538 herunterladbare Pakete: 716 TLD-Zonendateien, 716 angereicherte Sätze zu denselben Zonen mit Nameservern, MX-Records, aufgelösten IPs und erkanntem CMS, 79 nach Technologie gruppierte Sitelisten sowie 27 kuratierte Datensätze. Zusammen decken die Zonenpakete 285,582,781 Domains ab, davon 163,422,083 in .com. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.

Sie brauchen die Domainliste statt einer Einzelabfrage?
Sehen Sie sich den Domaindaten-Katalog an – Zonendateien und angereicherte Zonensätze mit NS, MX, IP und CMS.
Datenbanken durchsuchen → | Preise ansehen →

Fünf Aufgaben, für die Bulk-Domaindaten wirklich taugen

Zonen- und Anreicherungsdaten im Bulk beantworten Fragen auf Populationsebene. Sie zeigen, wie viele Domains existieren, worauf sie laufen und wohin sie auflösen. Sie sagen Ihnen nicht, wen Sie anschreiben sollen – das ist eine andere Datenkategorie und in diesen Dateien nicht enthalten. Die folgenden Anwendungsfälle sind diejenigen, die die Daten tatsächlich tragen.

1. Marktgrößenbestimmung nach Technologie

• Für wen: SaaS-Gründer, Produktmanager und Analysten, die einen adressierbaren Markt beziffern.
• Das Problem: Von Anbietern veröffentlichte Verbreitungszahlen beruhen meist auf einer Top-N-Stichprobe populärer Websites, was Enterprise-Werkzeuge systematisch überschätzt und den langen Schwanz unterschätzt.
• Was Bulk-Daten leisten: Das Feld zur CMS-Erkennung in den angereicherten Zonensätzen und die Technologie-Sitelisten liefern absolute Zahlen gegen einen bekannten Nenner. WordPress erscheint im Katalog auf 21,639,326 Domains, Joomla auf 567,680. Das sind Zählungen über die erfasste Zonenpopulation, keine Hochrechnung aus einer Stichprobe bekannter Websites.
• Richtig interpretieren: Nennen Sie immer den Nenner zusammen mit der Zahl. „21,6 Mio. WordPress-Domains von 279,9 Mio. abgedeckten“ ist eine belastbare Aussage; „WordPress betreibt X % des Webs“ ist es nicht – es sei denn, Sie können exakt sagen, welches Web Sie gemessen haben.

2. Infrastruktur- und Hosting-Analyse

• Für wen: Hosting-Anbieter, CDN-Anbieter, Infrastrukturanalysten.
• Das Problem: Marktanteile im Hosting sind weitgehend Spekulation, weil niemand Kundenzahlen veröffentlicht.
• Was Bulk-Daten leisten: Die angereicherten Sätze führen Nameserver und aufgelöste IP je Domain. Eine Gruppierung nach NS-Suffix nähert den DNS-Anbieter an; die Zuordnung von IPs zu den ankündigenden ASNs nähert das Hosting-Netz an. Beides lässt sich über eine komplette Zone hinweg direkt auszählen.
• Ein wichtiger Vorbehalt: Ein CDN vor dem Origin verdeckt dessen IP. Behandeln Sie aus IPs abgeleitete Hosting-Anteile als Maß für die Edge, nicht dafür, wo der Server physisch steht.

3. Untersuchung der Mail-Infrastruktur

• Für wen: Deliverability-Teams, E-Mail-Sicherheitsforscher, Anti-Abuse-Analysten.
• Das Problem: Fragen wie „Welcher Anteil dieser TLD nutzt Google Workspace, welcher Microsoft 365, welcher selbst gehostete Mail?“ haben keine öffentliche Antwort.
• Was Bulk-Daten leisten: MX-Records sind in den angereicherten Zonensätzen enthalten. Klassifiziert man MX-Hostnamen nach Anbietermustern, wird die gesamte Zone zu einer auswertbaren Verteilung – und ein erneuter Durchlauf auf einem späteren Snapshot zeigt Wanderungen zwischen Anbietern.
• Was Sie nicht bekommen: Ein MX-Record ist ein Routingziel für Mail, kein Postfach. In diesen Dateien stehen keine Adressen.

4. Sicherheitsforschung und Messung der Angriffsfläche

• Für wen: Sicherheitsforscher, CERT-Teams, Threat-Intelligence-Analysten.
• Das Problem: Aufklärung, die auf Live-RDAP oder WHOIS beruht, bleibt sofort stecken – Ratenbegrenzungen und der Fehler wegen fehlendem RDAP-Server machen eine vollständige Zonenabdeckung unmöglich.
• Was Bulk-Daten leisten: Beginnen Sie mit der Zonenliste statt mit Abfragen. Filtern Sie lokal auf die Population, die Sie interessiert (ein CMS, ein Nameserver, ein IP-Bereich), und richten Sie dann Ihre eigenen Scan- oder Prüfwerkzeuge auf diese Teilmenge. Die Domainliste ist der Input für Ihre Analyse, nicht die Analyse selbst.
• Hinweis zur Verantwortung: Aktive Tests müssen sich stets im Rahmen dessen bewegen, wozu Sie autorisiert sind. Eine herunterladbare Domainliste ist keine Autorisierung.

5. Aufbau und Pflege eines eigenen Datensatzes

• Für wen: Data Engineers und Data Scientists, die eine Basistabelle auf Domainebene benötigen.
• Das Problem: Ein eigener Crawler mit Zonenabdeckung bedeutet Resolver, Wiederholungslogik, Speicher, Deduplizierung und laufende Wartung – ein umfangreiches Projekt, bevor auch nur eine einzige Frage beantwortet ist.
• Was Bulk-Daten leisten: Ein Zonenpaket ist bereits eine flache CSV mit einer Zeile pro Domain. Laden Sie sie in DuckDB, ClickHouse oder Postgres, verknüpfen Sie sie mit Ihren internen Tabellen und laden Sie einen frischen Snapshot herunter, wenn Sie einen Vergleich brauchen. Jedes Paket wird zum Kaufzeitpunkt erzeugt, ein erneuter Kauf liefert Ihnen also einen aktuellen Snapshot zum Abgleich mit dem letzten.
• Praxistipp: Bewahren Sie jeden heruntergeladenen Snapshot auf und versehen Sie ihn mit einem Datum. Veränderung über die Zeit ist das Wertvollste, was diese Daten hergeben – und berechnen lässt sie sich nur, wenn Sie die ältere Datei behalten haben.

Wie die Dateien aussehen und wie sie sich zu Live-Abfragen verhalten

Zwei Dinge verdienen es, konkret benannt zu werden: die Struktur der Daten, die Sie erhalten, und der Unterschied zu dem, was eine Live-Abfrage per RDAP oder WHOIS zurückgibt.

Tabelle 1: Beispielzeilen aus einem angereicherten Zonenpaket

Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Ein Zonendatei-Paket enthält die Domainliste; ein angereichertes Paket ergänzt die unten gezeigten Auflösungs- und Erkennungsspalten. Felder sind gefüllt, sofern sie ermittelt werden konnten, und ansonsten leer.

Mehr ist es nicht. Es gibt keine Kontaktspalte, keine Firmenspalte und keine Inhaberspalte, denn personenbezogene Registrierungsdaten werden bei den meisten Domains bereits an der Quelle geschwärzt, und diese Pakete versuchen nicht, sie zu rekonstruieren. Wenn Ihr Workflow davon ausgeht, dass zur Domain eine E-Mail-Adresse mitgeliefert wird, ist jetzt der Zeitpunkt, den Workflow neu zu entwerfen.

Tabelle 2: Bulk-Dateien im Vergleich zu Live-RDAP/WHOIS und Live-Scannern

Das sind Ergänzungen, keine Alternativen zueinander. RDAP bleibt das richtige Werkzeug, wenn Sie den autoritativen Status einer bestimmten Domain brauchen. Ein Live-Scanner ist das richtige Werkzeug, wenn Sie jetzt sofort einen tiefen Technologie-Fingerabdruck einer einzelnen Website benötigen. Bulk-Dateien sind das richtige Werkzeug, wenn die Frage eine Population betrifft – und sie sind die einzige der drei Optionen, die gegen das Problem des fehlenden RDAP-Servers immun ist, weil sie nie eine Abfrage ausführen.

Arbeiten mit den Daten: kaufen, herunterladen, lokal verarbeiten

Es gibt keine Suchoberfläche zum Filtern und keine serverseitige Abfrage. Der Ablauf lautet: Paket auswählen, kaufen, ZIP herunterladen und auf der eigenen Maschine filtern.

Schritt 1: Das passende Paket finden

Unter /zones/ finden Sie TLD-Zonendateien und angereicherte Zonensätze, unter /datasets/ die kuratierten Sammlungen und unter /packages/ den vollständigen Katalog samt der technologiespezifischen Sitelisten. Jeder Eintrag nennt die Zeilenzahl bereits vor dem Kauf, Sie wissen also, welchen Umfang Sie erwerben.

Schritt 2: Kaufen und herunterladen

Pakete beginnen bei $3.50 und stehen sofort zum Download bereit. Die Datei wird beim Kauf frisch exportiert, der Snapshot bildet also den Katalogstand in genau diesem Moment ab und nicht einen veralteten Build. Für den laufenden Einsatz gibt es Abonnements: Pro für $29/month enthält 50 Pakete und 10 Datensätze mit 30,000 API-Aufrufen, Enterprise für $99/month umfasst 200 Pakete und 50 Datensätze mit 300,000 API-Aufrufen. Details finden Sie unter /pricing/.

Schritt 3: Entpacken und sichten

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

Schritt 4: Für schnelle Auswertungen mit Kommandozeilenwerkzeugen filtern

# 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

Schritt 5: Für alles Analytische eine spaltenorientierte Engine nutzen

Sobald Sie Dateien verknüpfen oder Hunderte Millionen Zeilen aggregieren, wechseln Sie zu DuckDB oder ClickHouse. DuckDB liest die CSV direkt, ganz ohne Importschritt:

-- 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;

Die zweite Abfrage ist die, aus der Sie sich eine Gewohnheit machen sollten. Ein einzelner Snapshot beschreibt einen Zustand; zwei Snapshots beschreiben eine Veränderung – und im Wandel liegt das Signal.

Schritt 6: Katalogzugriff über die API automatisieren

Die API stellt den Paketkatalog bereit – was es gibt, was es kostet, wie viele Zeilen es enthält –, sodass Sie Suche und Downloads skripten können. Ein Endpunkt für Domainabfragen ist sie nicht.

# 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/"

Die vollständige Endpunktreferenz steht unter /api/. Ein verbreitetes Muster ist ein geplanter Job, der die von Ihnen beobachteten Pakete auflistet, prüft, ob ein neuerer Build vorliegt, ihn herunterlädt und ihn neben dem vorherigen Snapshot in Ihr Warehouse lädt.

Typische Fehler bei der Beschaffung von Domaindaten

1. Live-Abfragen als Bulk-Datenquelle behandeln.

   • Was schiefgeht: Ratenbegrenzungen, Timeouts und der Fehler wegen fehlendem RDAP-Server machen aus einem Job über 500,000 Domains ein Skript, das nie fertig wird und Teilergebnisse liefert, denen Sie nicht trauen können.
   • Warum: RDAP und WHOIS sind Protokolle für einzelne Domains, mit entsprechend zugeschnittenen Diensterwartungen. Massennutzung liegt konstruktionsbedingt außerhalb ihres Zwecks.
   • Die Lösung: Holen Sie sich die Population aus einer Zonendatei und nutzen Sie Abfragen nur für die kleine Teilmenge, bei der Sie den autoritativen Status je Domain wirklich benötigen.

2. Kontaktdaten in Domaindaten erwarten.

   • Was schiefgeht: Eine Pipeline wird um eine E-Mail-Spalte herum entworfen, die nie eintrifft, und das Projekt bleibt beim letzten Schritt stehen.
   • Warum: Kontaktfelder des Inhabers werden seit der DSGVO bei den meisten Domains aus öffentlichen WHOIS- und RDAP-Antworten entfernt. Bulk-Domaindatensätze – auch diese – enthalten Infrastrukturmerkmale statt personenbezogener Daten.
   • Die Lösung: Entscheiden Sie von Anfang an, ob Sie einen Datensatz auf Domainebene oder einen Kontaktdatensatz brauchen. Das sind unterschiedliche Produkte mit unterschiedlicher Rechtsgrundlage; gehen Sie nicht davon aus, dass das eine das andere hergibt.

3. Mit einem einzigen Snapshot arbeiten.

   • Was schiefgeht: Sie können den aktuellen Zustand beschreiben, aber keinen Trend zeigen – und genau danach wird meist gefragt.
   • Warum: Veränderung erfordert zwei Beobachtungen. Aus einer einzigen Datei lässt sich keine Differenz bilden.
   • Die Lösung: Archivieren und datieren Sie jeden Download. Der Vergleich zweier Snapshots deckt Neuregistrierungen, aufgegebene Domains und Wechsel zwischen Hosting- oder Mail-Anbietern auf.

4. CMS-Erkennung als Gewissheit lesen.

   • Was schiefgeht: Eine Analyse nennt eine präzise Zahl, der ein Wettbewerber mit leicht abweichender Erkennungsmethode widerspricht.
   • Warum: Die Erkennung beruht auf Fingerabdrücken. Headless-Frontends, aggressives Caching und CDN-Transformationen verbergen die zugrunde liegende Plattform, und ein leeres CMS-Feld bedeutet „nicht erkannt“, nicht „kein CMS“.
   • Die Lösung: Nennen Sie zu jedem Anteil auch die Erkennungsrate und stellen Sie klar, dass die Zahlen erkannte Installationen beschreiben.

5. Annehmen, die auflösende IP identifiziere den Hoster.

   • Was schiefgeht: Zahlen zu Hosting-Marktanteilen werden von einer Handvoll CDN-Netze dominiert.
   • Warum: Sitzt eine Website hinter einem CDN oder Reverse Proxy, gehört der veröffentlichte A-Record dem Edge-Netz und nicht dem Origin-Server.
   • Die Lösung: Trennen Sie in Ihrem Modell „Edge-/CDN-Anbieter“ von „Origin-Hoster“ und nutzen Sie Nameserver-Daten als zweites, unabhängiges Signal.

6. NS- und MX-Records zu wenig nutzen.

   • Was schiefgeht: Die Analyse endet beim CMS-Feld, und die ergiebigsten Spalten bleiben ungenutzt.
   • Warum: NS und MX lassen sich günstig parsen und sind ungewöhnlich stabil – Organisationen wechseln weit häufiger das CMS als ihren DNS- oder Mail-Anbieter.
   • Die Lösung: Erstellen Sie einmal Klassifizierungsregeln für Anbieter anhand von NS- und MX-Hostnamen und wenden Sie sie anschließend auf jede heruntergeladene Zone an.

Häufig gestellte Fragen

F: Warum erhalte ich „no registry rdap server was identified for this domain“ bei manchen TLDs und bei anderen nicht?
A: Ein RDAP-Dienst ist für gTLDs vertraglich vorgeschrieben, für ccTLDs dagegen optional, da diese nationaler Politik unterliegen. Fehlt einer TLD der Eintrag im IANA-Bootstrap-Register, kann ein RDAP-Client nicht bestimmen, wohin er die Abfrage senden soll, und meldet genau diesen Fehler. Es ist eine Lücke in der Protokollverbreitung, kein Defekt Ihres Clients.

F: Führt WebTrackly RDAP- oder WHOIS-Abfragen für mich aus?
A: Nein. WebTrackly liefert vorbereitete Bulk-Dateien. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Einen Abfragedienst pro Domain gibt es nicht.

F: Was steckt konkret in einem Paket?
A: Zonendatei-Pakete enthalten die Domainliste einer TLD. Angereicherte Zonenpakete ergänzen Nameserver, MX-Records, aufgelöste IPs und das erkannte CMS, sofern diese ermittelt werden konnten. Technologiepakete sind Listen von Websites, auf denen ein bestimmtes CMS oder eine bestimmte Technologie erkannt wurde. Kuratierte Datensätze sind zonenübergreifende Zusammenstellungen; der größte umfasst alle registrierten Domains mit 272,614,863 Zeilen.

F: Sind E-Mail-Adressen oder Telefonnummern enthalten?
A: Nein. Die Pakete enthalten ausschließlich Domain- und Infrastrukturmerkmale. In keiner Datei stehen personenbezogene oder unternehmensbezogene Kontaktdaten.

F: Wie groß ist die Abdeckung?
A: Insgesamt 1,538 Pakete – 716 Zonendateien, 716 angereicherte Zonensätze, 79 Technologie-Sitelisten und 27 kuratierte Datensätze. Die Zonenpakete decken zusammen 285,582,781 Domains ab, davon 163,422,083 in .com. WordPress wird auf 21,639,326 Domains erkannt, Joomla auf 567,680.

F: Wie aktuell sind die Daten?
A: Jedes Paket wird im Moment des Kaufs exportiert, Sie erhalten also den aktuellen Build und keine Datei, die Monate zuvor erstellt wurde. Um Veränderungen zu verfolgen, kaufen Sie dasselbe Paket später erneut und vergleichen die beiden Snapshots.

F: Was leistet die API?
A: Sie stellt den Katalog bereit. GET /api/v1/packages/?type=zone listet Zonenpakete auf, ?type=technology&q=wordpress filtert Technologiepakete nach Stichwort, und /api/v1/packages/{slug}/ liefert Details zu einem Paket. Die Authentifizierung erfolgt per Bearer-Token. Die API nimmt keinen Domainnamen entgegen, um Fakten dazu zurückzugeben.

F: Was kostet das?
A: Einzelne Pakete beginnen als Einmalkauf bei $3.50. Pro kostet $29/month für 50 Pakete und 10 Datensätze mit 30,000 API-Aufrufen, Enterprise $99/month für 200 Pakete und 50 Datensätze mit 300,000 API-Aufrufen. Siehe /pricing/.

F: Wie verhält sich das zu BuiltWith oder Wappalyzer?
A: Diese Tools erstellen tiefgehende Fingerabdrücke einzelner Websites und sind die bessere Wahl für die detaillierte Analyse einer einzelnen Property. Bulk-Pakete decken ganze Zonen mit geringerer Tiefe je Domain ab – genau das, was Fragen auf Populationsebene erfordern. Sie beantworten unterschiedliche Fragen.

Fazit

„No registry rdap server was identified for this domain“ ist ein dauerhaftes Merkmal des Namensraums, keine vorübergehende Störung. Die RDAP-Abdeckung ist konstruktionsbedingt ungleichmäßig, Inhaberfelder sind geschwärzt, und Protokolle, die eine Domain nach der anderen bedienen, können Fragen auf Populationsebene nicht beantworten – egal, wie man sie skriptet.

Die praktikable Antwort besteht darin, die Datenquelle zu wechseln statt die Wiederholungslogik. Zonendateien und angereicherte Zonensätze liefern Ihnen die Domainliste, ihre Nameserver, ihr Mail-Routing, ihre aufgelösten Adressen und – sofern erkennbar – ihr CMS, als flache CSV, die Sie lokal mit grep, DuckDB oder ClickHouse verarbeiten. Kontaktdaten enthalten sie nicht, und wer das von Anfang an weiß, bewahrt sein Projekt davor, im letzten Schritt zu scheitern.

Domaindaten-Katalog durchsuchen →

Weiterführende Ressourcen

• Paketkatalog – 1,538 herunterladbare Domain-Datenbanken
• Zonendateien nach TLD – .com, .net, .de und 700+ weitere
• Kuratierte Datensätze – alle registrierten Domains, MX-Server, E-Commerce
• API-Dokumentation – Katalogzugriff per Bearer-Token
• Preise – Einmalkäufe ab $3.50