„No Registry RDAP Server Was Identified“: Ursachen und Lösungen

Gibt eine Domain-Abfrage „no registry RDAP server was identified for this domain“ zurück, hat die Anfrage nie eine Registry erreicht. Der RDAP-Client ist bereits beim Bootstrap-Schritt gescheitert: Er konnte die Top-Level-Domain der Domain keiner RDAP-Basis-URL zuordnen. Dieser Artikel erklärt, warum das passiert, wie das IANA-Bootstrap-Register funktioniert, wie Sie die Ursache selbst verifizieren und was zu tun ist, wenn eine TLD tatsächlich keinen RDAP-Dienst betreibt – einschließlich der Frage, wann ein Zonendatei-Datensatz der praktische Ersatz für Einzelabfragen pro Domain ist.

Kurzfassung / Die wichtigsten Punkte

• Die Meldung bedeutet, dass der RDAP-Client im IANA-Bootstrap-Register keine Basis-URL für die TLD der Domain gefunden hat. Es handelt sich um einen Auflösungsfehler, nicht um die Antwort „Domain nicht gefunden“.
• Die drei üblichen Ursachen sind: Die TLD hat überhaupt keinen RDAP-Dienst (die meisten ccTLDs), der Client arbeitet mit einer veralteten zwischengespeicherten Kopie der Bootstrap-Datei, oder die Eingabe ist gar keine echte TLD (ein Tippfehler, ein interner Name oder ein bloßer Hostname).
• Sie bestätigen die Ursache mit einer einzigen Anfrage: https://data.iana.org/rdap/dns.json abrufen und dort nach der TLD suchen.
• ICANN schreibt RDAP für vertraglich gebundene gTLDs vor. ccTLDs fallen nicht unter diesen Vertrag, entsprechend freiwillig und uneinheitlich ist die RDAP-Verfügbarkeit dort: Manche bieten RDAP, manche nur WHOIS, manche nichts davon in maschinenlesbarer Form.
• Wo RDAP existiert, WHOIS aber nicht – oder umgekehrt –, löst eine Fallback-Kette die meisten Fälle: erst IANA-Bootstrap, dann der dokumentierte eigene Endpunkt der Registry, dann WHOIS über Port 43.
• Wenn Sie wissen müssen, was in einer Zone existiert, statt den Eintrag zu einer einzelnen Domain zu prüfen, sind Einzelabfragen das falsche Werkzeug – unabhängig vom RDAP-Status. Ein Zonendatei-Datensatz listet die registrierten Domains direkt auf.
• Zonendateien und angereicherte Datensätze liefern Domains und Infrastruktur (Nameserver, MX, IP, erkanntes CMS). Sie enthalten keine Kontaktdaten von Domaininhabern – und kein Datensatz auf dieser Website tut das.

Inhaltsverzeichnis

1. Was „No Registry RDAP Server Was Identified“ tatsächlich bedeutet
2. Wie RDAP-Bootstrap einen Server auflöst
3. Die Ursache in drei Prüfschritten eingrenzen
4. Fallbacks, die funktionieren, wenn das Bootstrap scheitert
5. Wenn das eigentliche Ziel Enumeration ist und keine Einzelabfrage
6. Was tatsächlich in den Dateien steckt
7. Der reale Workflow: kaufen, herunterladen, lokal verarbeiten
8. Pakete über die API finden
9. Häufige Fehler & wie Sie sie vermeiden
10. Häufig gestellte Fragen
11. Fazit
12. Weiterführende Ressourcen

Was „No Registry RDAP Server Was Identified“ tatsächlich bedeutet

Die Fehlermeldung „no registry rdap server was identified for this domain“ ist eine häufige und zugleich massiv störende Hürde für alle, die domainbezogene Informationen sammeln wollen. Um ihre Tragweite und die Lösung von WebTrackly zu verstehen, muss man zunächst RDAP selbst kennen. Das Registration Data Access Protocol (RDAP) ist der Nachfolger des altgedienten WHOIS-Protokolls und wurde entwickelt, um den Zugriff auf Domain-Registrierungsdaten strukturierter, sicherer und standardisierter zu machen. Es setzt auf HTTP(S) auf und überträgt Daten als JSON, was es maschinenlesbarer und entwicklerfreundlicher macht als seinen Vorgänger.

Die ICANN (Internet Corporation for Assigned Names and Numbers) hat die Einführung von RDAP für gTLDs (generische Top-Level-Domains) wie .com, .org, .net und viele weitere verbindlich vorgeschrieben. Ziel sind besserer Datenzugang, mehr Datenschutz und Internationalisierung. Das Internet ist jedoch riesig und dezentral. Während gTLDs die Vorgaben in der Regel erfüllen, werden viele ccTLDs (länderspezifische Top-Level-Domains) wie .de (Deutschland) oder .jp (Japan) von anderen Registries betrieben und setzen RDAP unterschiedlich weit um – manchmal auch gar nicht.

Wenn Ihnen „no registry rdap server was identified for this domain“ begegnet, steckt typischerweise einer dieser Punkte dahinter:

1. TLD nicht unterstützt: Für die betreffende Top-Level-Domain (etwa eine weniger verbreitete ccTLD oder eine sehr neue gTLD) ist schlicht kein RDAP-Server konfiguriert oder dem abfragenden System bekannt. Das ist bei vielen Länder-Registries der Fall, die den Umstieg von WHOIS noch nicht vollzogen haben oder eigene proprietäre Systeme betreiben.
2. Technische Störung/Fehlkonfiguration: Der RDAP-Server der TLD existiert zwar, ist aber vorübergehend nicht erreichbar, falsch konfiguriert oder hat Netzwerkprobleme – die Abfrage schlägt fehl.
3. Domain-Privacy-/Proxy-Dienste: RDAP ist zwar datenschutzfreundlicher ausgelegt, doch manche Domains nutzen Privacy-Dienste, die Inhaberdaten bewusst verschleiern. Das ist zwar kein direkter „no registry RDAP server“-Fehler, aber eine verwandte Hürde beim Zugriff auf verwertbare Daten.
4. Nicht standardkonforme Domain-Namenskonventionen: Manche Nischen- oder interne Domains folgen keiner ICANN-regulierten Struktur und bleiben für Standard-RDAP-Resolver damit unsichtbar.

Die praktische Konsequenz: Sie erhalten überhaupt keine Antwort statt eines verbindlichen „Diese Domain ist nicht registriert“. Beides wird leicht verwechselt und führt zu völlig unterschiedlichen Schlussfolgerungen – ein Bootstrap-Fehler sagt nichts darüber aus, ob die Domain existiert.

Manuelle Umwege sind mühsam und ineffizient. Sie könnten verschiedene WHOIS-Clients ausprobieren, historische Datenarchive durchsuchen oder die Website selbst händisch untersuchen. Das kostet Stunden, liefert oft unvollständige oder veraltete Informationen und ist für Listen mit Hunderten oder Tausenden Domains schlicht nicht skalierbar. Moderne Leadgenerierung und Marktanalyse verlangen Automatisierung und vollständige Daten.

Wie RDAP-Bootstrap einen Server auflöst

RDAP kennt keinen zentralen Server. Jede Registry betreibt einen eigenen, und der Client muss herausfinden, welcher davon für einen bestimmten Namen zuständig ist. Dieser Ermittlungsprozess ist in RFC 7484 definiert und heißt Bootstrapping.

Die IANA veröffentlicht unter https://data.iana.org/rdap/dns.json eine Bootstrap-Datei für Domainnamen. Es handelt sich um ein JSON-Dokument mit einem services-Array. Jeder Eintrag ist ein zweielementiges Array: eine Liste von TLDs und eine Liste der RDAP-Basis-URLs, die sie bedienen. Ein Client, der example.com auflöst, nimmt das äußerst rechte Label – com –, sucht den Service-Eintrag, der es enthält, und setzt gegen die gefundene URL ein GET {base_url}domain/example.com ab.

# 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

Gibt dieser Befehl NO RDAP SERVICE aus, ist der Fehler kein Bug in Ihrem Client, und kein noch so häufiges Wiederholen ändert daran etwas. Die TLD fehlt im Register schlicht – genau der Zustand, den die Meldung beschreibt.

Zwei weitere Details sind wichtig. Erstens trägt die Datei einen publication-Zeitstempel; Clients, die sie aggressiv zwischenspeichern, können eine neu hinzugefügte TLD tagelang verpassen. Zweitens schreibt RFC 7484 ein Longest-Match auf Label-Ebene vor – ein Client, der naiv nur das letzte Label vergleicht, kann Namen unter mehrteiligen Suffixen falsch behandeln. Beides führt aus unterschiedlichen Gründen zur selben sichtbaren Meldung.

Die Ursache in drei Prüfschritten eingrenzen

1. Ist das Suffix überhaupt eine echte TLD? Gleichen Sie es mit der IANA-TLD-Liste unter https://data.iana.org/TLD/tlds-alpha-by-domain.txt ab. Interne Namen (.local, .internal, .corp), Tippfehler und Hostnamen, die samt Subdomain-Präfix übergeben werden, sind die häufigsten Fehlalarme.
2. Steht die TLD in der Bootstrap-Datei? Nutzen Sie den Befehl von oben. Fehlt sie, ist das die endgültige Antwort: Es gibt keinen RDAP-Server, der identifiziert werden könnte.
3. Ist die Kopie Ihres Clients aktuell? Erzwingen Sie einen frischen Abruf von dns.json und wiederholen Sie die Abfrage. Viele Bibliotheken und CLI-Wrapper legen die Bootstrap-Datei auf der Festplatte ab und lassen sie nie verfallen. Löst ein frischer Abruf die TLD auf, Ihr Werkzeug aber nicht, liegt es am Cache.

Diese drei Prüfungen in dieser Reihenfolge trennen ein Eingabeproblem von einem Client-Problem und von einer echten Lücke aufseiten der Registry – und jede Ursache hat eine andere Lösung.

Fallbacks, die funktionieren, wenn das Bootstrap scheitert

Das Registry Agreement der ICANN und die darin verankerte RDAP-Pflicht gelten für gTLDs. ccTLD-Betreiber sind nicht Vertragspartei, ihre Richtlinien für Registrierungsdaten werden national festgelegt. Deshalb lösen .com, .org, .app und die neueren gTLDs sauber auf, während ein langer Schwanz an Länderzonen das nicht tut.

Eine Fallback-Kette, die die meisten Praxisfälle abdeckt:

1. IANA-Bootstrap. Der Standardweg; nutzen Sie ihn zuerst.
2. Der dokumentierte eigene RDAP-Endpunkt der Registry. Manche Registries betreiben RDAP, sind aber nicht in der Bootstrap-Datei gelistet. Die TLD-Seiten der IANA unter https://www.iana.org/domains/root/db/<tld>.html nennen die trägerführende Organisation und ihren Dienst für Registrierungsdaten.
3. WHOIS über Port 43. Fragen Sie whois.iana.org nach der TLD selbst, um den zuständigen WHOIS-Host zu ermitteln, und fragen Sie diesen Host anschließend nach der Domain. Die Ausgabe ist unstrukturierter Text – kalkulieren Sie Parsing-Aufwand pro Registry ein.
4. DNS als Existenzprüfung. Eine NS-Abfrage ersetzt keine Registrierungsdaten, aber ein delegiertes NS-Record-Set ist ein starker Hinweis darauf, dass die Domain registriert ist – und oft ist genau das die einzige Information, die Sie wirklich brauchten.

# 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

Keiner dieser Wege stellt Kontaktdaten von Domaininhabern wieder her. Die meisten Registries schwärzen sie per Richtlinie, und RDAP wurde konzipiert, um diese Schwärzung explizit zu machen – nicht, um mehr davon offenzulegen.

Wenn das eigentliche Ziel Enumeration ist und keine Einzelabfrage

Ein Großteil des Traffics, der auf diesem Fehler landet, will gar keine einzelne Domain abfragen. Er will eine Mengenfrage beantworten: Welche Domains existieren in dieser TLD, welche davon laufen auf einem bestimmten CMS, welche verweisen auf einen bestimmten Mail-Provider. RDAP pro Domain ist dafür selbst dort ein schlechtes Instrument, wo es funktioniert – Sie bräuchten eine Anfrage pro Namen, und Registries drosseln entsprechend.

Für diese Klasse von Fragen ist die Zonendatei die Quelle der Wahrheit, nicht der Registrierungseintrag. Eine Zonendatei listet die delegierten Namen einer TLD auf. Sie enthält keinerlei Inhaberinformationen – genau deshalb darf sie überhaupt als Massendatei veröffentlicht werden.

WebTrackly stellt diese Daten als Katalog mit 1.538 Paketen bereit:

• 716 TLD-Zonendateien – die Liste der delegierten Domains für jede abgedeckte Zone.
• 716 angereicherte Zonen-Datensätze – dieselben Domains, ergänzt um Nameserver, MX-Records, aufgelöste IP und erkanntes CMS.
• 79 Site-Listen nach CMS oder Technologie – zum Beispiel WordPress mit 21.639.326 Domains und Joomla mit 567.680.
• 27 kuratierte Datensätze – darunter der Datensatz aller registrierten Domains mit 272.614.863 Zeilen.

Die Abdeckung über alle Zonen hinweg umfasst 285.582.781 Domains, davon allein 163.422.083 auf .com. Den Katalog finden Sie unter /packages/, die Zonen unter /zones/ und die kuratierten Datensätze unter /datasets/.

Was tatsächlich in den Dateien steckt

Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Die Spalten hängen vom Pakettyp ab:

• Zonendateien: der Domainname sowie das Registrierungsdatum, sofern die Registry es veröffentlicht. Viele tun das nicht – dann bleibt das Feld leer, statt geschätzt zu werden.
• Angereicherte Zonen-Datensätze: Domain, Nameserver (ns), Mailserver (mx), aufgelöste IP-Adresse und erkanntes CMS, sofern eines identifizierbar ist.
• Technologie- und CMS-Listen: die Domains, auf denen die jeweilige Technologie erkannt wurde.

Ebenso wichtig ist die klare Ansage, was die Dateien in keinem Paket enthalten:

• Keine Namen, Postanschriften, E-Mail-Adressen oder Telefonnummern von Domaininhabern.
• Keine Firmendaten, Jobtitel oder personenbezogenen Kennungen.
• Keine Signale zu Kaufabsicht, Traffic oder Umsatz.
• Keine interaktive Einzelabfrage pro Domain – das Produkt sind Massendateien, keine Abfrageschnittstelle für einzelne Namen.

Wenn Ihr Workflow auf Inhaberkontakte angewiesen ist: Diese Daten liefern sie nicht – und RDAP tut es für die überwältigende Mehrheit der Domains ebenso wenig, da Schwärzung über alle gTLDs hinweg inzwischen der Standard ist.

Der reale Workflow: kaufen, herunterladen, lokal verarbeiten

1. Paket auswählen. Wählen Sie die Zone, Technologieliste oder den kuratierten Datensatz, der zu Ihrer Frage passt. Die Preise starten bei $3.50 für einen Einmalkauf; siehe /pricing/.
2. Kaufen. Der Export wird im Moment des Kaufs frisch erzeugt – die Datei bildet also den Katalogstand zu diesem Zeitpunkt ab und nicht einen vorgefertigten Snapshot unbekannten Alters.
3. Herunterladen. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.
4. Lokal verarbeiten. Die Dateien sind groß genug, dass eine Tabellenkalkulation das falsche Werkzeug ist. Zum Filtern genügen Unix-Werkzeuge; für Joins und Aggregationen nehmen Sie eine eingebettete Analyse-Engine.

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;

Für wiederkehrende Auswertungen über mehrere Zonen hinweg lohnt sich der Einrichtungsaufwand, die CSV-Dateien in ClickHouse zu laden und als eine Tabelle abzufragen. Für eine einzelne Frage an eine einzelne Zone kommen Sie mit DuckDB direkt auf der CSV-Datei schneller zur Antwort.

Pakete über die API finden

Die API liefert den Katalog: Sie sagt Ihnen, welche Pakete es gibt und was jedes davon abdeckt. Sie ist kein Endpunkt für die Domainsuche, und eine Abfrage einzelner Domains gibt es nicht. Die Authentifizierung erfolgt per Bearer-Token.

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

Die Abo-Tarife enthalten Kontingente für API-Aufrufe: Pro für $29/Monat umfasst 50 Pakete und 10 Datensätze mit 30.000 API-Aufrufen, Enterprise für $99/Monat umfasst 200 Pakete und 50 Datensätze mit 300.000 API-Aufrufen. Die vollständige Dokumentation finden Sie unter /api/.

Häufige Fehler & wie Sie sie vermeiden

1. Den Bootstrap-Fehler als „Domain existiert nicht“ lesen.

   • Was schiefgeht: Eine Pipeline markiert Namen als nicht registriert, weil der RDAP-Aufruf fehlgeschlagen ist, und die nachgelagerte Logik handelt danach.
   • Die Lösung: Behandeln Sie einen Bootstrap-Fehler als unbekanntes Ergebnis mit eigenem Statuscode, klar getrennt von einer verbindlich negativen Antwort. Prüfen Sie die Existenz separat über eine DNS-Delegationsprüfung.

2. Die Bootstrap-Datei unbegrenzt zwischenspeichern.

   • Was schiefgeht: Eine TLD, die vor Monaten RDAP-Unterstützung erhalten hat, scheitert lokal weiterhin, weil die zwischengespeicherte dns.json älter ist.
   • Die Lösung: Aktualisieren Sie die Datei nach Zeitplan und werten Sie ihr publication-Feld aus. Ein täglicher Refresh genügt.

3. Eine ccTLD-Strategie allein auf RDAP aufbauen.

   • Was schiefgeht: Annahmen zur Abdeckung, die aus dem gTLD-Verhalten abgeleitet sind, tragen bei Länderzonen nicht – im Datenbestand entstehen stille Lücken.
   • Die Lösung: Führen Sie eine explizite Zuordnung pro TLD, welches Protokoll verfügbar ist – RDAP, WHOIS oder keines –, und leiten Sie Abfragen entsprechend, statt ein Protokoll erneut zu versuchen, das nie angeboten wurde.

4. Mengenfragen mit Einzelabfragen pro Domain beantworten.

   • Was schiefgeht: Millionen sequenzieller Anfragen, Rate-Limits, gesperrte Quell-Adressen und wochenlange Laufzeit für etwas, das eine einzige Datei beantwortet.
   • Die Lösung: Nutzen Sie Daten auf Zonenebene, wenn die Frage eine Zone betrifft, und reservieren Sie Einzelabfragen für die kleine Menge an Namen, die wirklich einen aktuellen Registrierungseintrag benötigen.

5. Von diesen Quellen Inhaberkontakte erwarten.

   • Was schiefgeht: Ein Projekt wird um Kontaktdaten herum konzipiert, die Schwärzungsrichtlinien und Massendatenformate nicht liefern – und gerät ins Stocken, sobald das klar wird.
   • Die Lösung: Planen Sie um das, was tatsächlich veröffentlicht wird: die Domain, ihre Delegation, ihre Mail- und Hosting-Infrastruktur und den erkannten Software-Stack.

6. WHOIS-Text parsen, als gäbe es nur ein Format.

   • Was schiefgeht: Ein Parser, der gegen die Ausgabe einer Registry geschrieben wurde, ordnet Felder bei einer anderen still falsch zu, denn WHOIS über Port 43 hat kein Schema.
   • Die Lösung: Bevorzugen Sie überall dort, wo es existiert, das JSON von RDAP, und behandeln Sie das Format jedes WHOIS-Servers als eigenes Parsing-Ziel mit eigenen Tests.

Häufig gestellte Fragen

F: Bedeutet dieser Fehler, dass die Domain nicht registriert ist?
A: Nein. Er bedeutet, dass der Client nicht ermitteln konnte, welchen RDAP-Server er fragen soll. Nach diesem Fehler ist der Registrierungsstatus der Domain unbekannt, nicht negativ. Eine DNS-Abfrage der NS-Records der Domain ist eine schnelle unabhängige Prüfung, ob sie delegiert ist.

F: Warum scheitern so viele ccTLDs?
A: Die RDAP-Pflicht der ICANN ergibt sich aus dem gTLD Registry Agreement, dem ccTLD-Betreiber nicht beigetreten sind. Ihre Dienste für Registrierungsdaten richten sich nach nationaler Politik – manche bieten RDAP, manche nur WHOIS über Port 43, manche nichts davon in maschinenlesbarer Form.

F: Lässt sich das durch einen Wechsel des RDAP-Clients beheben?
A: Nur wenn ein veralteter Cache oder eine fehlerhafte Longest-Match-Implementierung die Ursache war. Fehlt die TLD in dns.json, scheitert jeder konforme Client auf dieselbe Weise.

F: Was enthalten die WebTrackly-Pakete?
A: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Zonenpakete listen die Domains einer TLD auf, dazu ein Registrierungsdatum, sofern die Registry eines veröffentlicht. Angereicherte Pakete ergänzen Nameserver, MX-Records, aufgelöste IP und erkanntes CMS. Technologiepakete listen die Domains auf, auf denen eine bestimmte Technologie erkannt wurde.

F: Enthalten die Dateien E-Mail-Adressen oder Telefonnummern von Inhabern?
A: Nein. Kein Paket enthält personenbezogene Kontaktdaten irgendeiner Art, und es gibt keine Schnittstelle für Einzelabfragen pro Domain. Die Daten beschreiben Domains und ihre Infrastruktur.

F: Wie aktuell ist eine heruntergeladene Datei?
A: Der Export wird im Moment des Kaufs aus dem aktuellen Katalogbestand erzeugt – Sie laden also kein vorgefertigtes Archiv unbekannten Alters herunter.

F: Wie ist die Preisgestaltung?
A: Einmalkäufe einzelner Pakete beginnen bei $3.50. Die Abos sind Pro für $29/Monat (50 Pakete und 10 Datensätze, 30.000 API-Aufrufe) und Enterprise für $99/Monat (200 Pakete und 50 Datensätze, 300.000 API-Aufrufe). Details finden Sie unter /pricing/.

F: Was kann die API?
A: Sie stellt den Paketkatalog bereit – Pakete nach Typ auflisten und filtern, darin suchen und die Details eines einzelnen Pakets über seinen Slug abrufen. Domainabfragen führt sie nicht durch.

Fazit

„No registry RDAP server was identified for this domain“ ist ein Fehler bei der Bootstrap-Auflösung mit drei alltäglichen Ursachen: eine Eingabe, die keine echte TLD ist, eine veraltete zwischengespeicherte Bootstrap-Datei oder eine TLD ohne RDAP-Dienst. Eine einzige Anfrage an https://data.iana.org/rdap/dns.json zeigt Ihnen, welche der drei vorliegt – und jede hat ihre eigene Lösung: Eingabe korrigieren, Cache aktualisieren oder auf den dokumentierten WHOIS-Host der Registry ausweichen.

Ging es im Kern nie um einen einzelnen Registrierungseintrag, sondern um eine Bestandsaufnahme dessen, was in einer Zone existiert, war das Protokoll von Anfang an das falsche Instrument. Ein Zonendatei-Datensatz beantwortet diese Frage direkt, in einer Datei, mit den Domains und ihrer Infrastruktur – und ohne die Inhaberkontakte, die Ihnen weder RDAP noch Massendaten liefern werden.

Sie arbeiten mit Daten auf Zonenebene?
Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.
Pakete durchsuchen → | Preise ansehen →

Weiterführende Ressourcen

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