WHOIS vs. RDAP: So funktionieren ICANN-Domaindaten (Leitfaden 2026)

Jede Domain hinterlässt eine Registrierungsspur, und seit vierzig Jahren liest man diese Spur über WHOIS. Das Nachfolgeprotokoll der ICANN, RDAP, beantwortet dieselben Fragen über eine moderne REST-Schnittstelle mit strukturiertem JSON. Beide sind darauf ausgelegt, jeweils eine einzelne Domain abzufragen — und damit genau falsch geschnitten für Recherche, Marktdimensionierung oder Infrastrukturanalysen über Millionen von Namen hinweg. Dieser Leitfaden erklärt, worin sich die beiden Protokolle tatsächlich unterscheiden, wo sie jeweils an ihre Grenzen stoßen und was Massendateien mit Domaindaten leisten, wozu ein Abfrageprotokoll nie in der Lage sein wird.

TL;DR / Die wichtigsten Punkte

• WHOIS ist ein Klartextprotokoll auf Port 43: kein Schema, keine standardisierten Feldnamen, keine einheitlichen Datumsformate. Jede Registry und jeder Registrar formatiert die Ausgabe etwas anders — Parsing im großen Maßstab bedeutet also, pro Quelle einen eigenen Parser zu pflegen.
• RDAP ist der von der ICANN vorgeschriebene Nachfolger: RESTful, ausschließlich über HTTPS, JSON-Antworten, standardisierte Fehlercodes, Internationalisierung und Verweise zwischen Servern. Das löst das Parsing-Problem, nicht das Zugriffsproblem.
• Keines der beiden Protokolle ist eine Massendatenquelle: Beide sind konstruktionsbedingt ratenbegrenzt. Wer Millionen von Domains über WHOIS oder RDAP abfragt, wird gedrosselt und blockiert — und keine Registry unterstützt diesen Anwendungsfall.
• Die DSGVO-Schwärzung gilt für beide: Seit 2018 sind Name, E-Mail-Adresse und Anschrift des Inhabers in den öffentlichen Antworten für die meisten Domains geschwärzt oder durch einen Proxy ersetzt. Öffentliches WHOIS/RDAP ist keine Kontaktdatenbank.
• Keines der Protokolle sagt etwas darüber aus, womit eine Website betrieben wird: CMS, Webserver, CDN, Mail-Anbieter und IP liegen außerhalb des Registrierungseintrags. Diese Informationen stammen aus der DNS-Auflösung und aus HTTP-Fingerprinting, nicht aus der Registry.
• WebTrackly verkauft die Massendatenebene: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.
• Die Analyse machen Sie selbst: Die Dateien sind Input für Ihr eigenes Tooling. Es gibt keinen Query-Builder im Browser, keine Abfrage einzelner Domains und keine Kontaktdaten.

Inhaltsverzeichnis

1. WHOIS verstehen: das Protokoll der ersten Stunde
2. RDAP im Überblick: der moderne Standard
3. WHOIS vs. RDAP im direkten Vergleich
4. Wo beide Protokolle aufhören
5. Was Massendateien mit Domaindaten enthalten
6. Ein Paket kaufen und verarbeiten
7. Automatisieren mit der Katalog-API
8. Typische Fehler bei der Beschaffung von Domaindaten & wie Sie sie vermeiden
9. Häufig gestellte Fragen (FAQ)
10. Weiterführende Ressourcen

WHOIS verstehen: das Protokoll der ersten Stunde

WHOIS ist ein Anfrage-Antwort-Protokoll, mit dem sich Datenbanken abfragen lassen, in denen die registrierten Inhaber einer Internet-Ressource hinterlegt sind — eines Domainnamens, eines IP-Adressblocks oder einer Autonomous-System-Nummer. Es entstand in der Frühzeit des Internets und wurde Anfang der 1980er-Jahre von der IETF standardisiert. Sein Zweck war ein Verzeichnisdienst: Jeder sollte herausfinden können, wer für eine Ressource verantwortlich ist — vor allem für die Fehlersuche im Netz und für den Umgang mit Missbrauch.

Der Aufbau ist bewusst schlicht. Ein WHOIS-Eintrag ist ein Klartextblock, der über TCP-Port 43 zurückgegeben wird. Ein Client verbindet sich mit dem WHOIS-Server des zuständigen Registrars oder der Registry, schickt den Domainnamen und erhält einen Textblock zurück.

Typische WHOIS-Einträge enthalten:

• Inhaberdaten: Name, Organisation, Anschrift, E-Mail-Adresse und Telefonnummer des Domaininhabers — heute für die meisten Domains geschwärzt.
• Administrativer Kontakt: die Stelle, die für administrative Fragen zuständig ist.
• Technischer Kontakt: die Stelle, die für technische Fragen zuständig ist.
• Registrar-Angaben: das Unternehmen, über das die Domain registriert wurde.
• Registrierungsdaten: Anlagedatum, letztes Änderungsdatum, Ablaufdatum.
• Nameserver: die autoritativen DNS-Server der Domain.
• Domain-Status: EPP-Statuscodes wie clientTransferProhibited oder pendingDelete.

Der ursprüngliche Wert von WHOIS lag in Transparenz und Verantwortlichkeit. Wurde über eine Website Missbrauch betrieben oder trat eine technische Störung auf, führte WHOIS zur verantwortlichen Stelle. Für die Wettbewerbsrecherche lieferte es die Basisfakten: Registrierungsdatum, Registrar und Nameserver.

Die Nachteile wiegen heute schwerer. Der größte ist das fehlende Schema. Jeder Registrar und jede Registry formatiert die Ausgabe anders — abweichende Feldbezeichnungen, Datumsformate und Abschnittsreihenfolgen inklusive. Automatisiertes Parsing verlangt deshalb reguläre Ausdrücke und Sonderlogik je Quelle; ein Parser, der gegen die Ausgabe eines Registrars geschrieben wurde, scheitert regelmäßig an der eines anderen.

Die zweite Einschränkung ist das Rate-Limiting. WHOIS-Server sind für Einzelabfragen ausgelegt, nicht für die Massenextraktion. Wer Tausende oder Millionen Domains abfragt, landet bei Drosselung, IP-Sperren oder CAPTCHA-Seiten. Hinzu kommt, dass die Daten altern: Inhaber ziehen um, ändern Adressen, lassen Angaben veralten — und Registrare erzwingen Aktualisierungen nicht konsequent.

Die entscheidende Zäsur für alle, die WHOIS als Kontaktquelle nutzen wollten, kam 2018 mit der DSGVO. Um konform zu bleiben, verpflichtete die ICANN die Registrare, personenbezogene Daten betroffener Inhaber aus der öffentlichen WHOIS-Ausgabe zu schwärzen. Bei den meisten Domains stehen heute anstelle von Name, E-Mail-Adresse und Telefonnummer des Inhabers „REDACTED FOR PRIVACY“ oder die Weiterleitungsadresse eines Privacy-Dienstes. Öffentliches WHOIS sollte als Quelle technischer und registrierungsbezogener Fakten gelten, nicht personenbezogener.

RDAP im Überblick: der moderne Standard

Angesichts der uneinheitlichen WHOIS-Ausgabe und des wachsenden Bedarfs an Zugriffskontrollen trieb die ICANN die Entwicklung von RDAP voran, dem Registration Data Access Protocol. RDAP wurde als standardisierter, sicherer und erweiterbarer Ersatz konzipiert. Die ICANN übernahm es 2017; Registrys und Registrare setzen es seitdem schrittweise um.

Entscheidend ist der architektonische Unterschied. Statt Klartext auf Port 43 ist RDAP ein RESTful Web Service, der strukturierte Daten zurückgibt, in der Regel JSON. Damit entfällt das Parsing-Problem: Mit einem definierten Schema kann ein automatisiertes System ein Feld über seinen Namen auslesen, statt einen Textblock per Mustererkennung zu zerlegen.

Die wichtigsten Vorteile von RDAP gegenüber WHOIS:

• Standardisiertes Datenformat: Die JSON-Ausgabe ist maschinenlesbar und lässt sich direkt in Pipelines einbinden.
• Sicherheitsfunktionen: RDAP läuft über HTTPS und unterstützt Authentifizierung und Autorisierung — akkreditierte Anfragende können also grundsätzlich vollständigere Antworten erhalten als anonyme.
• Internationalisierung: saubere Unterstützung für internationalisierte Domainnamen und mehrsprachige Kontaktdaten.
• Fehlerbehandlung: standardisierte HTTP-Statuscodes und Fehlerobjekte, sodass Clients „nicht gefunden“ von „Rate-Limit erreicht“ und „Serverfehler“ unterscheiden können.
• Verweise: Eine RDAP-Antwort kann den Client auf den autoritativen Server für das jeweilige Objekt verweisen, was registryübergreifende Abfragen handhabbar macht.

Mit dem Vorstoß zu RDAP verfolgt die ICANN einen einheitlichen, nachvollziehbaren Zugang zu Registrierungsdaten. Wer Registrierungseinträge programmatisch abfragt, gewinnt mit RDAP klar an Zuverlässigkeit gegenüber dem Vorgänger.

Am Inhalt des Eintrags ändert RDAP nichts. Es unterliegt denselben Datenschutzvorgaben wie WHOIS: Personenbezogene Daten bleiben in öffentlichen Antworten geschwärzt. Die Abfrage ist sauberer, die Kontaktfelder sind aber weiterhin Proxys oder Platzhalter. Auch die Abdeckung ist ungleichmäßig — nicht jede Registry und nicht jeder Registrar hat den RDAP-Rollout abgeschlossen, sodass manche Domains nur über WHOIS erreichbar sind. Und der Inhalt bleibt, was er war: Registrierungsdaten. Nichts über die eingesetzte Technologie, das Hosting oder die Inhalte der Website.

WHOIS vs. RDAP im direkten Vergleich

Wo beide Protokolle aufhören

Bei allen Unterschieden beantworten WHOIS und RDAP genau eine Frage: Was steht im Registry-Eintrag zu diesem Namen? Ganze Fragekategorien fallen damit von vornherein heraus.

1. Keine Technologieerkennung. Der Registrierungseintrag verrät, wer eine Domain registriert hat, nicht welche Software die Website betreibt. CMS, E-Commerce-Plattform, Webserver und JavaScript-Bibliotheken ermittelt man, indem man die Website abruft — nicht über die Registry.
2. Keine nutzbaren Kontaktdaten. DSGVO und vergleichbare Regelwerke haben die Inhaberdaten aus öffentlichen Antworten entfernt. Akkreditierte Zugänge gibt es für Strafverfolgung und Rechteinhaber; ein Allzweckkanal ist das nicht.
3. Kein Blick auf die Infrastruktur. Über die Nameserver hinaus sagen die Protokolle nichts über die aufgelöste IP, das Hosting-Netz, das CDN vor dem Origin oder den Mail-Anbieter hinter den MX-Einträgen.
4. Keine Aggregation. Selbst mit dem sauberen JSON von RDAP bedeutet die Abdeckung von Millionen Namen, Abfragen über Hunderte Server hinweg zu orchestrieren — jeder mit eigenen Rate-Limits und eigener Verfügbarkeit. Das ist ein Infrastrukturprojekt, keine Abfrage.
5. Keine Aktualitätsgarantie im großen Maßstab. Die Protokolle kennen keinen Mechanismus, der Ihnen sagt, was sich seit dem letzten Durchlauf geändert hat. Änderungen zu erkennen heißt, alles erneut abzufragen.
6. Kein Blick auf die Gesamtheit. Sie können WHOIS oder RDAP nicht fragen, „wie viele .de-Domains existieren“ oder „welche Domains lösen auf dieses Netz auf“. Beantwortet werden nur Fragen zu einzelnen Namen.

Genau diese Fragen beantworten Massendateien mit Domaindaten — denn eine Datei ist eine Grundgesamtheit, keine Abfrage.

Sie arbeiten mit Domaindaten im großen Maßstab?
Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.
Katalog durchsuchen → | Preise ansehen →

Was Massendateien mit Domaindaten enthalten

Der Katalog von WebTrackly ist in drei Gruppen gegliedert:

• Zonendateien nach TLD — 716 Pakete für .com, .net, .de, .org und Hunderte weitere. Allein das .com-Paket enthält 163,422,083 Domains. Siehe Zonendateien nach TLD.
• Technologie- und CMS-Listen — 79 Pakete mit Domains, gruppiert nach der jeweils erkannten Plattform. Das WordPress-Paket enthält 21,639,326 Domains. Siehe Domain Data.
• Kuratierte Datensätze — 27 Pakete, darunter der Datensatz aller registrierten Domains mit 272,614,863 Zeilen. Siehe Datasets.

Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Die Datei entsteht im Moment des Kaufs und bildet damit den Stand der Quelldaten an diesem Tag ab — nicht einen zwischengespeicherten Snapshot aus einem früheren Crawl. Die Preise beginnen bei $3.50 pro Paket; die Abostufen finden Sie unter Pricing.

Diese Felder erwarten Sie

Die Spalten hängen vom Pakettyp ab — eine Zonendatei ist schmal, eine Technologieliste führt die Erkennungs- und Auflösungsfelder mit. Die folgende Tabelle zeigt die Struktur der Daten, nicht die Zusage, dass jede Spalte in jedem Paket vorkommt.

Was nicht in den Dateien steht: Personennamen, E-Mail-Adressen, Telefonnummern, Firmografiedaten oder Verhaltens- und Intent-Signale. WebTrackly verkauft Domaindaten. Alles, was die Menschen hinter einer Domain betrifft, liegt außerhalb des Angebots — als Produktentscheidung wie als Compliance-Entscheidung.

Ein Paket kaufen und verarbeiten

Der Ablauf ist bewusst kurz — es gibt keinen Query-Builder zu erlernen, denn die Analyse findet auf Ihrer Maschine mit Ihren eigenen Werkzeugen statt.

1. Paket finden. Durchsuchen Sie den Katalog oder gehen Sie direkt zu /zones/ für TLD-Zonendateien, /domaindata/ für Technologielisten oder /datasets/ für kuratierte Datensätze. Jeder Eintrag zeigt die Zeilenzahl, sodass Sie den Umfang schon vor dem Kauf kennen.
2. Kaufen. Einzelkäufe beginnen bei $3.50. Abos (Pro für $29/month, Enterprise für $99/month) enthalten ein monatliches Kontingent an Paketen und Datensätzen sowie API-Kontingent; Details auf der Preisseite.
3. Herunterladen. Das ZIP wird auf Anforderung erzeugt und steht unmittelbar nach der Zahlung bereit.
4. Lokal verarbeiten. Entpacken und die CSV mit den Werkzeugen bearbeiten, die Sie ohnehin einsetzen.

Bei einer Datei mit einigen Hundert Millionen Zeilen schlagen Kommandozeilen-Werkzeuge und eine spaltenorientierte Engine jede Tabellenkalkulation um Längen:

unzip com-zone.zip
wc -l com-zone.csv

# filter rows by name server with plain grep
grep -i 'cloudflare' com-zone.csv > cloudflare-hosted.csv

# or query the CSV directly with DuckDB, no import step
duckdb -c "SELECT ns, count(*) AS n FROM 'com-zone.csv' GROUP BY ns ORDER BY n DESC LIMIT 20"

Für wiederkehrende Auswertungen laden Sie die Daten einmalig per Bulk-Copy in PostgreSQL oder ClickHouse und indizieren die Spalten, nach denen Sie filtern. Zwei Pakete zu verbinden — etwa eine Technologieliste mit einer Zonendatei — ist ein einfacher Join über die Spalte domain.

Automatisieren mit der Katalog-API

Die Abopläne enthalten API-Zugriff, um den Katalog zu durchsuchen und Paket-Metadaten programmatisch abzurufen. Pro umfasst 30,000 Aufrufe pro Monat, Enterprise 300,000. Die API ist eine Katalogschnittstelle: Sie listet und beschreibt Pakete und Datensätze. Sie ist kein Dienst für Abfragen einzelner Domains.

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

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

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

Die vollständige Endpunkt-Referenz, inklusive der Endpunkte für Datensätze und Konto, finden Sie auf der API-Dokumentationsseite.

Typische Fehler bei der Beschaffung von Domaindaten & wie Sie sie vermeiden

Wer mit whois vs rdap icann-Daten in realistischem Umfang arbeitet, stolpert immer wieder über dieselbe Handvoll Fehler. Diese hier lohnt es sich zu vermeiden.

1. WHOIS oder RDAP als Massenquelle behandeln

   • Was schiefgeht: ein Skript, das eine Liste mit einer Million Domains durchläuft und jede einzeln über WHOIS oder RDAP abfragt.
   • Warum es schiefgeht: Beide Protokolle sind je Quelle ratenbegrenzt, und keine Registry unterstützt dieses Muster. Sie werden innerhalb von Minuten gedrosselt, und der Durchlauf dauert länger, als die Daten gültig bleiben.
   • Die Lösung: Beginnen Sie mit einer Massendatei, die die Grundgesamtheit bereits enthält, und heben Sie sich Einzelabfragen für die kleine Teilmenge auf, bei der Sie den aktuellen Registry-Eintrag wirklich brauchen.

2. Kontaktdaten aus Registrierungseinträgen erwarten

   • Was schiefgeht: ein Outreach-Prozess, der auf den E-Mail-Adressen der Domaininhaber aufbaut.
   • Warum es schiefgeht: Diese Felder sind seit 2018 bei den meisten Domains geschwärzt oder durch einen Proxy ersetzt. Der Plan scheitert an den Daten, nicht an der Umsetzung.
   • Die Lösung: Nutzen Sie Domaindaten für das, was sie sind — eine Landkarte aus Namen, Infrastruktur und Technologie — und beziehen Sie Kontaktdaten über Kanäle, bei denen Einwilligung und Herkunft dokumentiert sind.

3. Einen Parser je Registrar bauen und das Pipeline nennen

   • Was schiefgeht: regexbasiertes WHOIS-Parsing, das bei den getesteten Registraren funktioniert und den Rest still und leise verstümmelt.
   • Warum es schiefgeht: WHOIS hat kein Schema. Feldbezeichnungen, Datumsformate und Abschnittsreihenfolgen variieren — und ändern sich ohne Ankündigung.
   • Die Lösung: Bevorzugen Sie RDAP, wo die Registry es unterstützt, denn das JSON-Schema ist stabil. Wenn Sie eine ganze TLD brauchen, nehmen Sie die Zonendatei, statt sie Name für Name zu rekonstruieren.

4. Übersehen, wie schnell die Daten altern

   • Was schiefgeht: eine Datei aus dem Vorjahr für die diesjährige Analyse wiederverwenden.
   • Warum es schiefgeht: Domains laufen ab, wechseln den Hoster, tauschen das CMS und ziehen hinter CDNs — laufend. Schlussfolgerungen aus einer veralteten Grundgesamtheit beschreiben ein Web, das es nicht mehr gibt.
   • Die Lösung: Laden Sie neu herunter, wenn die Analyse zählt. WebTrackly erzeugt die Datei beim Kauf, ein frischer Download ist also ein frischer Auszug und keine zwischengespeicherte Kopie.

5. Den Aufwand für die eigene Erhebungsschicht unterschätzen

   • Was schiefgeht: die Entscheidung, das Web selbst zu crawlen und zu fingerprinten, weil die einzelnen Schritte simpel aussehen.
   • Warum es schiefgeht: Auflösung im großen Maßstab, Retry-Logik, Pflege der Fingerprints, Storage und die Planung von Re-Crawls sind eine dauerhafte Engineering-Verpflichtung, kein Sprint.
   • Die Lösung: Kaufen Sie die Grundgesamtheit als Datei, wo Sie Abdeckung brauchen, und bauen Sie nur dort selbst, wo Ihre Anforderungen wirklich von dem abweichen, was es fertig gibt.

6. Hunderte Millionen Zeilen in das falsche Werkzeug laden

   • Was schiefgeht: eine mehrere Gigabyte große CSV in einer Tabellenkalkulation öffnen oder sie in einer Skriptsprache Zeile für Zeile durchlaufen.
   • Warum es schiefgeht: Die Zeilenzahlen gehen hier in die Hunderte Millionen. Werkzeuge, die alles im Arbeitsspeicher halten, kommen nie ans Ziel.
   • Die Lösung: Streamen Sie. Kommandozeilen-Filter, DuckDB direkt auf der CSV oder ein Bulk-Load in einen spaltenorientierten Store bewältigen diese Größe problemlos.

7. Die rechtliche Prüfung des Erhobenen überspringen

   • Was schiefgeht: annehmen, dass jede Nutzung erlaubt ist, nur weil Daten öffentlich erreichbar sind.
   • Warum es schiefgeht: DSGVO, CCPA und die Nutzungsbedingungen der Registrys beschränken, wie Registrierungsdaten verarbeitet und weiterveröffentlicht werden dürfen — unabhängig davon, wie sie beschafft wurden.
   • Die Lösung: Halten Sie personenbezogene Daten komplett aus der Pipeline heraus. Domainnamen, DNS-Einträge, IPs und Technologie-Fingerprints identifizieren keine Personen; Inhaberdaten schon.

Häufig gestellte Fragen (FAQ)

F: Was ist der praktische Unterschied zwischen WHOIS und RDAP?
A: WHOIS liefert unstrukturierten Text über Port 43 und verlangt je Registrar einen eigenen Parser. RDAP liefert JSON über HTTPS nach einem definierten Schema, unterstützt Authentifizierung, verwendet Standard-HTTP-Fehlercodes und kann einen Client an den autoritativen Server verweisen. Für die programmatische Nutzung ist RDAP klar einfacher zu handhaben. Für beide gelten dieselbe Datenschutz-Schwärzung und dieselben Rate-Limits.

F: Bekomme ich über eines der Protokolle E-Mail-Adressen oder Telefonnummern der Inhaber?
A: Bei den meisten Domains nicht. Seit dem Inkrafttreten der DSGVO im Jahr 2018 verpflichtet die ICANN die Registrare, personenbezogene Daten aus öffentlichen WHOIS- und RDAP-Antworten zu schwärzen. Akkreditierte Zugangswege existieren für bestimmte Stellen wie die Strafverfolgung. WebTrackly verkauft keinerlei Kontaktdaten.

F: Bietet WebTrackly eine Abfrage für einzelne Domains an?
A: Nein. Das Produkt sind Massendateien. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Eine Suchoberfläche für einzelne Domains gibt es nicht.

F: In welchem Format kommen die Downloads, und wie aktuell sind sie?
A: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Die Datei wird zum Kaufzeitpunkt erzeugt und nicht aus einem vorgefertigten Snapshot ausgeliefert.

F: Wie groß ist der Katalog?
A: 1,538 Pakete: 716 TLD-Zonendateien, 79 Technologie- und CMS-Listen sowie 27 kuratierte Datensätze. Zur Größenordnung: Das .com-Zonenpaket enthält 163,422,083 Domains, das WordPress-Paket 21,639,326 und der Datensatz aller registrierten Domains 272,614,863 Zeilen.

F: Was kostet das?
A: Einmalkäufe einzelner Pakete beginnen bei $3.50. Pro kostet $29/month und enthält 50 Pakete, 10 Datensätze und 30,000 API-Aufrufe. Enterprise kostet $99/month mit 200 Paketen, 50 Datensätzen und 300,000 API-Aufrufen. Die aktuellen Konditionen finden Sie auf der Preisseite.

F: Gibt es eine API?
A: Ja, für den Katalog. Die API listet Pakete und Datensätze auf und gibt deren Metadaten zurück, authentifiziert per Bearer-Token. Siehe die API-Dokumentation. Abfragen einzelner Domains führt sie nicht aus.

F: Wie verarbeite ich am besten eine Datei mit Hunderten Millionen Zeilen?
A: Streamen statt laden. Standard-Kommandozeilenwerkzeuge erledigen Filtern und Zählen; DuckDB fragt eine CSV direkt ab, ganz ohne Importschritt; für wiederkehrende Auswertungen laden Sie die Daten per Bulk-Load in PostgreSQL oder ClickHouse und indizieren die Spalten, nach denen Sie filtern.

Fazit

WHOIS und RDAP erledigen genau das, wofür sie gebaut wurden: Sie sagen Ihnen, was eine Registry zu einem einzelnen Namen verzeichnet. RDAP tut das mit Schema, über HTTPS und mit echter Fehlerbehandlung — ein echter Fortschritt, auf den jeder Code umsteigen sollte, der Registrierungsdaten abfragt. Was keines der beiden Protokolle je liefern wird, ist eine Grundgesamtheit. Es sind Abfragen: konstruktionsbedingt ratenbegrenzt, per Regulierung von personenbezogenen Daten befreit und stumm zu allem, was nach der Auflösung passiert.

Wenn die Frage eine ganze TLD, eine ganze Plattform oder ein ganzes Segment des Webs betrifft, ist der richtige Input eine Datei. Genau das veröffentlicht WebTrackly: Zonendateien, Technologielisten und kuratierte Datensätze, als CSV, beim Kauf erzeugt — für die Analyse mit Ihren eigenen Werkzeugen.

Starten Sie mit dem Katalog.
Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben.
Pakete durchsuchen → | Preise ansehen →

Weiterführende Ressourcen

• Paketkatalog — 1,538 herunterladbare Domain-Datenbanken
• Zonendateien nach TLD — .com, .net, .de und 700+ weitere
• Domain Data — Domainlisten nach CMS und Technologie
• Kuratierte Datensätze — alle registrierten Domains, MX-Server, E-Commerce
• Pricing — Einmalkäufe ab $3.50