ICANN RDAP erklärt: Der WHOIS-Nachfolger (Leitfaden 2026)

WHOIS wurde nie für die maschinelle Verarbeitung entworfen, und nach zwei Jahrzehnten registrarspezifischer Ausgabeformate und einem Jahrzehnt datenschutzbedingter Schwärzungen taugt es als Datenquelle nicht mehr. Das Registration Data Access Protocol (RDAP) der ICANN ist der standardisierte Nachfolger: dieselben Registrierungsdaten, ausgeliefert als JSON über HTTPS mit einheitlichem Schema. Dieser Leitfaden erklärt, was RDAP ist, was seine Antworten 2026 tatsächlich enthalten (deutlich weniger, als die meisten erwarten), worin es sich auf Protokollebene von WHOIS unterscheidet und wie Sie mit Domaindaten in großem Maßstab arbeiten, wenn Einzelabfragen pro Domain nicht praktikabel sind.

Das Wichtigste in Kürze

• WHOIS wird abgelöst: Das Protokoll liefert Freitext ohne garantierte Struktur, unterscheidet sich von Registrar zu Registrar und kennt weder standardisierte Authentifizierung noch einheitliche Fehlerbehandlung oder Internationalisierung.
• RDAP ist der von der ICANN vorgeschriebene Nachfolger: Definiert in RFC 7480-7484, liefert es JSON über HTTPS mit dokumentiertem Objektmodell, standardisierten HTTP-Statuscodes und einem Bootstrap-Verzeichnis, über das sich der zuständige Server finden lässt.
• Die Struktur ist der eigentliche Gewinn: Registrar, Erstellungs- und Ablaufdatum, Nameserver, Statuscodes und Ereigniseinträge kommen als benannte Felder statt als Text, der per Mustererkennung zerlegt werden muss.
• Kontaktdaten sind weitgehend verschwunden: RDAP-Antworten für gTLDs sind standardmäßig geschwärzt. Namen, E-Mail-Adressen und Telefonnummern von Domaininhabern lassen sich über RDAP nicht in nennenswertem Umfang beschaffen, und kein seriöses Werkzeug ändert daran etwas.
• Einzelabfragen skalieren nicht: RDAP-Server sind ratenbegrenzt. Fragen auf Populationsebene („Wie viele Domains in .de laufen mit WordPress?“) brauchen Bulk-Dateien, keine Abfragen.
• Bulk-Dateien beantworten andere Fragen: Zonendateien und angereicherte Zonensätze liefern Domain, Nameserver, MX, IP und erkanntes CMS über ganze TLDs hinweg — der richtige Input für Marktdimensionierung, Infrastrukturanalysen und den Aufbau eigener Datensätze.

Inhaltsverzeichnis

1. ICANN RDAP: die moderne Grundlage für Domaindaten, und warum WHOIS überholt ist
2. Was RDAP Ihnen nicht liefert: Schwärzung, Rate-Limits und Skalierung
3. Wo Daten auf Domainebene tatsächlich nützlich sind
4. Was WebTrackly bietet: Bulk-Datenpakete zu Domains
5. Datenschema: Was in der CSV steckt
6. Die Katalog-API nutzen
7. Die Dateien lokal verarbeiten
8. Typische Fehler im Umgang mit RDAP-Daten
9. FAQ
10. Fazit

ICANN RDAP: Die moderne Grundlage für Domaindaten und warum WHOIS überholt ist

Das Internet läuft auf Domains, und zu wissen, wem sie gehören, wer sie verwaltet und wann sie registriert wurden, ist die Grundlage für zahllose Aktivitäten im Netz — von der B2B-Leadgenerierung bis zu Ermittlungen im Bereich Cybersicherheit. Jahrzehntelang war WHOIS dafür das zentrale Werkzeug. Doch das klassische WHOIS-Protokoll, entworfen in den Anfangstagen des Internets, ist zum Relikt geworden und wird den Anforderungen des modernen Webs immer weniger gerecht. Seine als Freitext ausgegebene, uneinheitliche Antwort und der zunehmende Datenschutz durch Regelwerke wie die DSGVO machen es notorisch schwer programmatisch auszuwerten und für legitime geschäftliche Zwecke oft unvollständig. Genau deshalb ist der ICANN RDAP overview WHOIS replacement kein bloßes Upgrade, sondern eine Notwendigkeit für alle, die Domain Intelligence ernst nehmen.

RDAP, das Registration Data Access Protocol, entstand bei der Internet Engineering Task Force (IETF) und der ICANN als standardisierte Lösung der nächsten Generation. Anders als bei WHOIS, wo ein Mensch die unterschiedlichen Ausgabeformate von Hunderten Registraren interpretieren muss, liefert RDAP maschinenlesbare, strukturierte Daten, üblicherweise im JSON-Format. Eine Abfrage gibt ein klar definiertes Objekt zurück: das Domain-Handle, ein events-Array mit Zeitstempeln zu Registrierung, Ablauf und letzter Änderung, ein nameservers-Array, ein status-Array mit standardisierten, aus EPP abgeleiteten Werten sowie ein entities-Array, das den Registrar und alle Kontakte beschreibt, die die Registry veröffentlicht. Jedes Feld hat einen Namen, einen Typ und einen festen Platz im Schema — genau das, was WHOIS nie hatte.

Entscheidend ist der Maßstab. Weltweit sind Hunderte Millionen Domainnamen registriert; schon tausend WHOIS-Einträge manuell zu prüfen, ist unpraktikabel. Automatisierung mit WHOIS bedeutet, Parser für Hunderte einzigartiger Ausgabeformate zu schreiben und zu pflegen — ein Dauerkampf gegen Inkonsistenz und stille Formatänderungen. Die Datenschutzregulierung hat das Problem verschärft: Nach Inkrafttreten der DSGVO begannen Registrare, die Kontaktfelder der Domaininhaber in der WHOIS-Ausgabe routinemäßig zu schwärzen oder zu maskieren, und dieselbe Schwärzung setzt sich in RDAP fort. Praktisch heißt das: WHOIS hat den Rest seines Werts als Kontaktquelle verloren, während seine Parsing-Probleme unverändert geblieben sind.

RDAP adressiert diese Punkte direkt. Es bietet einen einheitlichen Mechanismus für Abfrage und Antwort und damit eine standardisierte Struktur für Domainregistrierungsdaten, unabhängig von Registrar oder Top-Level-Domain (TLD). Dazu gehören Angaben zur Domain, zu ihrem Registrar, Erstellungs- und Ablaufdatum, Nameservern und häufig auch stärker strukturierte Kontaktinformationen (soweit rechtlich zulässig) oder zumindest organisatorische Kennungen. Statt etwa eine „registrant email“ aus einem Textblock zu extrahieren, der mal mit „Admin Contact“, mal mit „Registrant Email“ und mal mit „Contact Email“ überschrieben ist, stellt RDAP für diese Attribute eigene JSON-Felder bereit — die Datenextraktion wird präzise und verlässlich.

Ein Beispiel aus der Praxis: Ein B2B-SaaS-Anbieter für Website-Sicherheit möchte potenzielle Kunden identifizieren, die veraltete, weniger sichere Hosting-Umgebungen betreiben. Mit klassischem WHOIS müsste er Tausende Einträge scrapen, Hosting-Anbieter manuell aus den (oft verschleierten) Nameserver-Angaben ableiten und anschließend versuchen, überhaupt Kontaktdaten zu finden — gegen die Schwärzung an jeder Stelle. Der Prozess ist langsam, fehleranfällig und liefert Leads von geringer Qualität.

RDAP löst das Formatproblem, und nur das Formatproblem. Es liefert verlässliche, vergleichbare technische Metadaten: welcher Registrar eine Domain betreut, wann sie erstellt wurde und wann sie abläuft, an welche Nameserver sie delegiert ist und welche administrativen Statuscodes gelten. Das ist für Infrastrukturanalysen wirklich nützlich, ebenso für die Beobachtung von Marktanteilen bei Registraren und DNS-Anbietern und für das Aufspüren von Domains, deren Registrierungs- oder Delegationsmuster auffällig ist. Was RDAP nicht leistet: Es stellt das Inhaberverzeichnis, das es vor 2018 gab, nicht wieder her. Jeder Workflow, der davon ausgeht, dass RDAP eine Kontaktperson zurückgibt, beruht auf einer falschen Annahme und scheitert bei der überwiegenden Mehrheit der gTLD-Domains.

Der Umstieg auf RDAP ist Branchenstandard und in RFCs wie RFC 7480, 7481, 7482, 7483 und 7484 dokumentiert. Diese definieren Protokoll, Abfrage- und Antwortstruktur sowie Sicherheitsaspekte und schaffen damit eine robuste, zukunftssichere Grundlage für den Zugriff auf Domaindaten. Mit RDAP bewegen sich ICANN und die Internet-Community hin zu einer sichereren, effizienteren und maschinenfreundlicheren Art, Registrierungsdaten abzufragen und zu erhalten — wesentlich für Stabilität und Nutzen des Internets. Für Unternehmen bedeutet das den Wechsel von einem manuellen, von Vermutungen geprägten Vorgehen zu einer datengetriebenen, automatisierten Strategie, um den Zielmarkt zu identifizieren und anzusprechen. WebTrackly legt diese Möglichkeiten direkt in Ihre Hand und macht aus rohen RDAP-Daten belastbare Erkenntnisse für Ihre Vertriebs-, Marketing- und Datenteams.

Was RDAP Ihnen nicht liefert: Schwärzung, Rate-Limits und Skalierung

Es lohnt sich, die Grenzen des Protokolls klar zu benennen, denn viele Veröffentlichungen zu RDAP stellen sie stillschweigend zu großzügig dar.

• Kontaktdaten der Domaininhaber sind standardmäßig geschwärzt. Nach der Registrierungsdaten-Policy der ICANN lassen gTLD-RDAP-Antworten die Kontaktdaten von Inhaber, administrativem und technischem Ansprechpartner für die Allgemeinheit weg oder maskieren sie. Eine typische Antwort enthält eine Registrar-Entität mit Abuse-Kontakt und eine Inhaber-Entität, deren vCard-Felder entfernt oder durch eine Proxy-Adresse ersetzt sind. Es gibt keine öffentliche Stufe, die die zugrunde liegenden Werte zurückgibt; ihr Abruf erfordert einen akkreditierten, zweckgebundenen Auskunftsantrag, der im Einzelfall bearbeitet wird.
• Die Abdeckung ist über die TLDs hinweg uneinheitlich. Für gTLDs ist RDAP verpflichtend. Viele ccTLD-Registries betreiben es freiwillig, manche mit reduziertem Feldumfang, und einige bieten weiterhin nur WHOIS oder ein Webformular. Das Bootstrap-Verzeichnis der IANA sagt Ihnen, welcher Server für eine TLD zuständig ist, aber nicht, was dieser Server zu veröffentlichen bereit ist.
• Rate-Limits machen Massenabfragen unmöglich. Die RDAP-Endpunkte von Registries und Registraren sind gegen automatisiertes Abgreifen geschützt. Sequenzielle Abfragen in Millionenhöhe sind keine unterstützte Nutzung des Protokolls; der Versuch führt zu Drosselung oder Sperrung. Das ist eine bewusste Designentscheidung und kein Hindernis, das man umgehen sollte.
• Antworten beschreiben die Registrierung, nicht die Website. RDAP weiß nicht, welches CMS eine Website betreibt, welches CDN davor sitzt oder ob sie überhaupt auflöst. Diese Informationen stammen aus DNS- und HTTP-Beobachtung und sind ein eigenständiges Problem der Datenerhebung.

Diese Grenzen entscheiden darüber, welche Fragen sich per Abfrage beantworten lassen und welche einen Bulk-Datensatz erfordern. „Welcher Registrar betreut diese eine Domain und wann läuft sie ab?“ ist eine Abfrage. „Wie viele Domains in dieser Zone delegieren an Cloudflare-Nameserver?“ ist eine Datensatzfrage — und keine Menge an Abfragen macht daraus eine Einzelabfrage.

Wo Daten auf Domainebene tatsächlich nützlich sind

Strukturierte Registrierungs- und Infrastrukturdaten tragen ein engeres, aber belastbareres Spektrum an Anwendungsfällen, als das Marketing rund um Domain Intelligence üblicherweise nahelegt. Die folgenden drei arbeiten mit dem, was tatsächlich verfügbar ist: technische Metadaten zu Domains, nicht Informationen über die Menschen dahinter.

Angriffsfläche und Infrastrukturanalyse

Zielgruppe: Anbieter von Cybersicherheitsdiensten, Penetrationstest-Firmen, Incident-Response-Teams, Threat-Intelligence-Analysten.

Problem: Organisationen zu identifizieren, die potenziell verwundbare oder veraltete Infrastruktur betreiben, ist ein manueller, zeitraubender Prozess. Klassische WHOIS-Daten sind zu uneinheitlich und zu häufig geschwärzt, um Domains sinnvoll auf ihren Technologie-Stack oder auf risikoträchtige Registrar-Muster abzubilden. Angriffsflächen sind riesig, und Ziele mit bestimmten, ausnutzbaren Konfigurationen proaktiv zu erkennen, ist ebenso wichtig wie schwierig.

Was die Daten leisten: Dateien auf Zonenebene erlauben einem Security-Team, die Domains einer TLD vollständig aufzulisten, ihre Delegations- und Mail-Infrastruktur aufzulösen und erkannte CMS-Plattformen gegen bekannte verwundbare Versionen abzugleichen. Wer mit einer vollständigen Zone statt mit einer Stichprobe arbeitet, hat einen echten Nenner: Sie können sagen, wie viele Domains einer Zone einen bestimmten Nameserver-Betreiber oder Mail-Anbieter nutzen, statt nur, wie viele in der zufällig erhobenen Stichprobe auftauchten. RDAP ergänzt anschließend die Registrierungsmetadaten pro Domain für die kleinere Auswahl, die aus dieser Analyse hervorgeht — ein Volumen, das das Protokoll problemlos bedienen kann.

Was die Daten nicht leisten: Sie sagen Ihnen nicht, wen Sie in diesen Organisationen ansprechen sollen. Eine Outreach-Liste aufzubauen ist eine separate Aufgabe, die sich auf Informationen stützen muss, die diese Organisationen selbst veröffentlichen — und die ein Domain-Datensatz nicht liefert.

Marktdimensionierung für SaaS-Gründer und Produktteams

Zielgruppe: SaaS-Gründer, Produktmanager, Marktforscher, Venture-Capital-Investoren.

Problem: Eine neue SaaS-Produktidee zu validieren erfordert tiefes Marktverständnis: Wer sind die potenziellen Kunden, welche Technologien setzen sie heute ein und wie groß ist der adressierbare Markt? Anekdotische Evidenz oder allgemeine Branchenberichte reichen dafür nicht. Gründer brauchen granulare Daten zu Technologieeinsatz und zugrunde liegender Infrastruktur.

Was die Daten leisten: Zählen. Wenn Ihr Produkt auf WordPress-Sites zielt, ist die Größe der adressierbaren Population eine zählbare Größe statt einer Schätzung: Über die hier abgedeckten Zonen hinweg werden 21.639.326 Domains als WordPress und 567.680 als Joomla erkannt. Ist Ihr Produkt regional ausgerichtet, lassen sich mit den Dateien pro Zone die Zahlen auf die relevanten TLDs eingrenzen. Der Vergleich von Zahlen über Zonen hinweg oder zwischen Snapshots verschiedener Zeitpunkte zeigt, wo eine Plattform gewinnt oder verliert — ein weitaus stärkerer Input für einen Business Case als das veröffentlichte Marktanteilsdiagramm eines Anbieters.

So gehen Sie vor: Nehmen Sie den angereicherten Satz für die relevanten Zonen, zählen Sie die Zeilen nach erkanntem CMS und nach Nameserver-Betreiber, und wiederholen Sie das mit einem späteren Snapshot, wenn Sie einen Trend statt einer Momentaufnahme brauchen.

Datensätze für Analyse und maschinelles Lernen aufbauen

Zielgruppe: Data Scientists, Data Engineers, Forschende, Business-Intelligence-Analysten.

Problem: Der Aufbau umfassender Datensätze für großangelegte Analysen, Machine-Learning-Modelle oder Trendprognosen scheitert häufig an uneinheitlichen Datenquellen. Klassische WHOIS-Daten sind unstrukturiert, erfordern aufwendige Bereinigung und Parsing und bieten selten die Konsistenz, die robuste Datenpipelines brauchen. Verschiedene Datenpunkte aus unterschiedlichen Webquellen zu integrieren ist komplex und zeitaufwendig.

Was die Daten leisten: einen stabilen, spaltenorientierten Ausgangspunkt. Jede angereicherte Datei pro Zone ist eine CSV mit einer Zeile pro Domain und einem festen Satz an Spalten, die sich ohne Parsing-Schritt direkt in pandas, DuckDB, ClickHouse oder ein Data Warehouse laden lässt. Domain, Nameserver, MX, IP und erkanntes CMS sind alle als Merkmale nutzbar: Konzentration von Hosting- und Mail-Anbietern, Delegationsmuster und Plattformwahl sind aussagekräftige Signale für Klassifikationsaufgaben wie das Trennen geparkter Domains von aktiven Sites oder das Clustern von Domains nach Infrastrukturbetreiber. Wo eine Registry Registrierungsdaten veröffentlicht, sind diese enthalten und geben dem Datensatz eine zeitliche Dimension.

Einschränkungen, die Sie einplanen sollten: Die Erkennung ist beobachtend und hinkt der Realität bei kürzlich geänderten Sites hinterher; eine in einer Zonendatei enthaltene Domain ist registriert, liefert aber nicht zwingend Inhalte aus; und ein fehlender MX-Eintrag bedeutet, dass für diesen Namen keine Mail konfiguriert ist — nicht, dass die Organisation keine Mail nutzt.

Was WebTrackly bietet: Bulk-Datenpakete zu Domains

WebTrackly ist ein Katalog herunterladbarer Domaindaten, keine Suchoberfläche und keine Kontaktdatenbank. Der Katalog umfasst 1.538 Pakete in vier Gruppen.

Die Abdeckung über diese Zonen hinweg beträgt 285.582.781 Domains. Die größte einzelne Zone ist .com mit 163.422.083 Domains. Auf der Technologieseite werden 21.639.326 Domains als WordPress und 567.680 als Joomla erkannt. Der größte kuratierte Datensatz, alle registrierten Domains, enthält 272.614.863 Zeilen.

Die Auslieferung ist bewusst einfach gehalten. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Einmalkäufe beginnen bei $3.50. Für den laufenden Einsatz stehen zwei Abopläne bereit: Pro für $29/Monat umfasst 50 Pakete plus 10 Datensätze und 30.000 API-Aufrufe, Enterprise für $99/Monat umfasst 200 Pakete plus 50 Datensätze und 300.000 API-Aufrufe.

Der Katalog lässt sich unter /packages/ durchsuchen; Zonendateien finden Sie unter /zones/, technologiebasierte Listen unter /domaindata/ und zonenübergreifende Zusammenstellungen unter /datasets/. Details zu den Plänen stehen auf /pricing/.

Datenschema: Was in der CSV steckt

Ein angereichertes Paket pro Zone entpackt sich zu einer CSV mit einer Zeile pro Domain und den folgenden Spalten.

Reine Zonendatei-Pakete enthalten ausschließlich die Spalte domain. Technologielisten enthalten die Domains, auf denen eine bestimmte Plattform erkannt wurde.

Ebenso wichtig ist, was die Dateien nicht enthalten:

• Keinerlei personenbezogene Kontakte. Keine Namen, keine E-Mail-Adressen, keine Telefonnummern, keine Social-Media-Profile.
• Keine Identitätsdaten zu Domaininhabern. Das Registrierungsdatum ist von der Registry veröffentlichte Metainformation; der Inhaber hinter einer Domain ist nicht Teil dieser Dateien.
• Keine Intent-, Firmografie- oder Unternehmensgrößen-Signale.
• Keine Schätzungen zu Traffic, Rankings oder Umsatz.

Wenn Sie eine Liste von Personen zum Kontaktieren brauchen, sind diese Datensätze der falsche Input — und keine Filter- oder Exportoption ändert daran etwas.

Die Katalog-API nutzen

Die API bedient den Katalog: Sie können damit ermitteln, welche Pakete existieren, deren Metadaten einsehen und Kauf und Download automatisieren. Sie ist kein Endpunkt für Einzelabfragen pro Domain, und es gibt keine Abfrageschnittstelle, die einzelne Domaineinträge zurückgibt. Jede Anfrage trägt ein Bearer-Token.

Die Zonendatei-Pakete auflisten:

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

Die Technologiepakete durchsuchen:

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

Den Detaileintrag zu einem einzelnen Paket abrufen, inklusive Zeilenzahl und aktuellem Preis:

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

Ein typisches Automatisierungsmuster besteht darin, den Katalog auf die Pakete abzufragen, von denen Ihre Pipeline abhängt, die gemeldeten Zeilenzahlen mit dem letzten Import zu vergleichen und einen neuen Download anzustoßen, sobald eine Zone spürbar gewachsen oder geschrumpft ist. Das Kontingent liegt bei 30.000 API-Aufrufen pro Monat bei Pro und 300.000 pro Monat bei Enterprise — reichlich für das Abfragen des Katalogs und weit über dem, was eine geplante Pipeline benötigt. Die vollständige Endpunkt-Dokumentation finden Sie unter /api/.

Die Dateien lokal verarbeiten

Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Da es sich um einfache CSV-Dateien handelt, erledigen Standard-Kommandozeilenwerkzeuge den ersten Durchgang und eine spaltenorientierte Engine alles Weitere.

Entpacken und die Struktur der Daten ansehen:

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

Für eine einzelne Zonendatei reichen grep und awk oft aus:

# domains delegating to Cloudflare name servers
grep -i 'ns.cloudflare.com' com-enriched.csv | wc -l

# domains with Google Workspace mail
grep -i 'aspmx.l.google.com' com-enriched.csv | wc -l

Für alles Analytische laden Sie die CSV in DuckDB. Es liest die Datei an Ort und Stelle, ein Importschritt entfällt:

duckdb -c "
  SELECT cms, count(*) AS domains
  FROM read_csv_auto('com-enriched.csv')
  WHERE cms IS NOT NULL
  GROUP BY cms
  ORDER BY domains DESC
  LIMIT 20;
"

Für wiederholte Abfragen über viele Zonen hinweg ist ClickHouse die bessere Wahl. Legen Sie eine Tabelle mit den sechs Spalten an, laden Sie die CSV-Dateien, und Aggregationen über Hunderte Millionen Zeilen laufen in Sekunden:

clickhouse-client --query "
  CREATE TABLE domains (
    domain String, reg_date Nullable(Date),
    ns String, mx String, ip String, cms String
  ) ENGINE = MergeTree ORDER BY domain"

clickhouse-client --query "INSERT INTO domains FORMAT CSVWithNames" < com-enriched.csv

Ein Hinweis zur Größenordnung: Der Datensatz mit allen registrierten Domains umfasst 272.614.863 Zeilen — rechnen Sie unkomprimiert mit zweistelligen Gigabyte-Beträgen und nutzen Sie einen spaltenorientierten Speicher statt einer Tabellenkalkulation. Einzelne Zonendateien sind deutlich kleiner und lassen sich meist bequem in DuckDB auf einem Laptop öffnen.

Typische Fehler im Umgang mit RDAP-Daten

RDAP ist leicht abzufragen und ebenso leicht misszuverstehen. Diese Fehler führen am häufigsten zu irreführenden Schlussfolgerungen.

1. Fehler: Zu großes Vertrauen in direkte Kontaktdaten aus rohem RDAP.

   • Was schiefgeht: Viele erwarten von RDAP direkte, ungeschwärzte E-Mail-Adressen und Telefonnummern der Domaininhaber. Wegen Datenschutzvorgaben (etwa der DSGVO) und Registrar-Richtlinien sind diese Informationen häufig geschwärzt, über einen Proxy geführt (z. B. [email protected]) oder schlicht nicht direkt über RDAP verfügbar. Wer sich allein auf rohes RDAP für Kontaktdaten verlässt, erhält extrem schlechte oder leere Lead-Listen.
   • Warum: Die Temporary Specification der ICANN für gTLD-Registrierungsdaten und diverse nationale Datenschutzgesetze schreiben den Schutz personenbezogener Daten vor. Registrare setzen das um, indem sie Kontaktdaten schwärzen oder maskieren.
   • Die Lösung: Behandeln Sie RDAP als Quelle technischer Metadaten und sonst nichts. Registrar, Datumsangaben, Nameserver und Statuscodes sind verlässlich; Kontaktfelder sind es nicht. Wenn Ihr Projekt Organisationen erreichen muss, muss das aus Informationen kommen, die diese Organisationen selbst veröffentlichen — erhoben auf der Rechtsgrundlage, die für Ihre Jurisdiktion und Ihren Anwendungsfall gilt. Kein Domain-Datenprodukt, auch dieses nicht, liefert Inhaberkontakte, und jeder Anbieter, der behauptet, sie aus RDAP zu extrahieren, beschreibt etwas, das das Protokoll nicht kann.

2. Fehler: Die Feinheiten der RDAP-Statuscodes ignorieren.

   • Was schiefgeht: RDAP liefert detaillierte Statuscodes (z. B. clientDeleteProhibited, serverHold, pendingDelete). Werden sie falsch gedeutet, landen Domains im Fokus, die nicht aktiv sind, in einem Streitfall stecken oder kurz vor dem Ablauf stehen. Eine pendingDelete-Domain mit einem Vertriebsangebot anzusprechen ist zum Beispiel verschwendete Zeit.
   • Warum: Diese Codes geben den aktuellen administrativen Zustand einer Domain an. Sie sind entscheidend, um ihre Verfügbarkeit und Stabilität einzuschätzen.
   • Die Lösung: Lernen Sie das EPP-Statusvokabular, das RDAP übernimmt. clientTransferProhibited ist eine normale Sperre und sagt nichts Negatives über eine Domain aus; serverHold bedeutet, dass die Domain nicht im DNS veröffentlicht wird; pendingDelete bedeutet, dass sie sich im Löschzyklus befindet und bald freigegeben wird; redemptionPeriod bedeutet, dass sie bereits abgelaufen ist, vom Inhaber aber noch wiederhergestellt werden kann. Entscheiden Sie ausdrücklich, welche Status Ihre Analyse einschließt, und dokumentieren Sie diese Entscheidung zusammen mit den Ergebnissen, damit die Zahlen reproduzierbar bleiben.

3. Fehler: Annehmen, dass Daten überall und sofort aktuell sind.

   • Was schiefgeht: Der Glaube, alle RDAP-Daten seien in Echtzeit und würden bei allen Registraren gleichzeitig aktualisiert. RDAP ist zwar für den programmatischen Zugriff gemacht, doch Registrare haben unterschiedliche Aktualisierungszyklen, und es kann zu Verzögerungen bei der Propagierung kommen.
   • Warum: Domainregistrierungsdaten laufen über mehrere Parteien (Inhaber, Registrar, Registry). Aktualisierungen erreichen das gesamte Ökosystem nicht immer sofort.
   • Die Lösung: Behandeln Sie jeden Datensatz und jede Abfrage als Snapshot mit Zeitstempel und speichern Sie diesen Zeitstempel mit den Daten. Bulk-Dateien spiegeln den Zustand einer Zone zum Zeitpunkt der Exporterzeugung; RDAP spiegelt den Zustand einer Domain zum Zeitpunkt der Abfrage. Keines von beidem ist ein Live-Feed. Für Trendanalysen ist das eher ein Vorteil als eine Einschränkung, denn erst der Vergleich datierter Snapshots macht einen Trend überhaupt messbar.

4. Fehler: Rate-Limits und Fair-Use-Regeln missachten.

   • Was schiefgeht: Wer RDAP-Server direkt oder über die API einer Plattform aggressiv abfragt, ohne Rate-Limits zu beachten, riskiert IP-Sperren, temporäre Blockaden oder Leistungseinbußen. Das gilt besonders beim Versuch, rohes RDAP zu scrapen.
   • Warum: RDAP-Server sind wie jede öffentliche API gegen Missbrauch geschützt. Auch die API von WebTrackly hat Rate-Limits, um faire Nutzung für alle Kunden sicherzustellen.
   • Die Lösung: Versuchen Sie keine Massenaufzählung über RDAP. Setzen Sie Abfragen dort ein, wo Sie aktuelle, autoritative Details zu einer bestimmten Domain brauchen, implementieren Sie dabei exponentielles Backoff und respektieren Sie Retry-After-Header — und nutzen Sie für alles auf Populationsebene Bulk-Dateien. Eine Zone über Einzelabfragen zu rekonstruieren ist langsamer und unvollständiger, als die Zone herunterzuladen.

5. Fehler: „Registrar“ und „Hosting-Anbieter“ verwechseln.

   • Was schiefgeht: Die Instanz, bei der die Domain registriert ist (Registrar, aus RDAP), wird mit der Instanz verwechselt, die die Inhalte der Website hostet (Hosting-Anbieter, ermittelt über DNS-/IP-Abfragen). Eine bei GoDaddy registrierte Domain kann auf AWS gehostet sein und umgekehrt.
   • Warum: Das sind unterschiedliche Dienste. Ein Registrar verwaltet den Domainnamen selbst, ein Hosting-Anbieter liefert die Website-Dateien aus.
   • Die Lösung: Halten Sie beide Attribute in getrennten Spalten und leiten Sie nie das eine aus dem anderen ab. Der Registrar kommt aus RDAP. Hosting- und Mail-Anbieter werden aus den Spalten für Nameserver, MX und IP einer Bulk-Datei abgeleitet. Eine Zonendatei zeigt Ihnen zum Beispiel, dass eine Domain an Cloudflare-Nameserver delegiert ist, während ihr A-Record auf einen völlig anderen Anbieter zeigt — genau die Unterscheidung, die verloren geht, wenn beide Konzepte vermischt werden.

6. Fehler: Rechtliche und ethische Compliance ignorieren (DSGVO, CCPA, Nutzungsbedingungen).

   • Was schiefgeht: Extrahierte Daten, insbesondere Kontaktdaten, werden ohne Rücksicht auf Datenschutzvorgaben oder die Nutzungsbedingungen der Datenanbieter verwendet. Das kann zu rechtlichen Sanktionen, Reputationsschäden und Kontosperrungen führen.
   • Warum: Datenschutzgesetze sind streng. Selbst wenn Daten öffentlich verfügbar sind, müssen Erhebung und Nutzung Vorgaben wie DSGVO und CCPA entsprechen.
   • Die Lösung: Wissen Sie, welches Rechtsregime für die Daten gilt, die Sie halten. Domain, Nameserver, MX, IP und erkanntes CMS sind technische Attribute von Infrastruktur, keine personenbezogenen Daten identifizierbarer Personen — deshalb ist der Umgang mit Bulk-Domaindateien vergleichsweise unkompliziert. In dem Moment, in dem Sie sie mit Informationen über Personen verknüpfen, verarbeiten Sie personenbezogene Daten, und DSGVO, CCPA und vergleichbare Regime greifen in vollem Umfang. Halten Sie diese Grenze in Ihrer eigenen Pipeline sichtbar, statt sie erst bei einem Audit zu entdecken.

Wer diese Fehler vermeidet, hält RDAP-basierte Analysen belastbar: korrekt in dem, was das Protokoll berichtet, transparent in dem, was es auslässt, und ehrlich in Bezug auf den Unterschied zwischen einem Snapshot und einer Live-Sicht.

FAQ

F: Was genau ist RDAP und worin unterscheidet es sich von WHOIS?
A: RDAP (Registration Data Access Protocol) ist der moderne, standardisierte Nachfolger des veralteten WHOIS-Protokolls. Der entscheidende Unterschied: RDAP liefert strukturierte, maschinenlesbare Daten (üblicherweise als JSON), während WHOIS Freitext ausgibt, dessen Form je nach Registrar stark variiert. Dieses strukturierte Format macht RDAP-Daten deutlich einfacher zu parsen, zu analysieren und in automatisierte Systeme einzubinden. RDAP bietet zudem verbesserte Sicherheitsmerkmale und Unterstützung für Internationalisierung und ist damit für programmatischen Zugriff und globale Domain Intelligence überlegen.

F: Bekomme ich über RDAP Namen, E-Mail-Adressen oder Telefonnummern von Domaininhabern?
A: Nein, jedenfalls nicht in nennenswertem Umfang. gTLD-RDAP-Antworten sind nach ICANN-Policy standardmäßig geschwärzt, und die meisten Registries geben für die Kontaktfelder des Inhabers einen Proxy oder einen leeren Wert zurück. Auskunft gibt es nur über ein akkreditiertes, zweckgebundenes Antragsverfahren, das im Einzelfall bearbeitet wird. Auch die Datensätze von WebTrackly enthalten keine personenbezogenen Kontakte: Domain, Registrierungsdatum (wo veröffentlicht), Nameserver, MX, IP und erkanntes CMS sind der vollständige Umfang dessen, was die Dateien enthalten.

F: Bietet WebTrackly eine Einzelabfrage pro Domain oder eine Suchoberfläche?
A: Nein. Das Produkt ist ein Katalog herunterladbarer Pakete. Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Es gibt keine Oberfläche, um eine einzelne Domain abzufragen, und keine gefilterte Suche über die zugrunde liegenden Zeilen; gefiltert wird auf Ihrer Seite, nach dem Download.

F: Welche Formate und Lieferwege gibt es?
A: Das Downloadformat hängt vom Paket ab und wird auf der Produktseite angegeben. Der Export wird im Moment des Kaufs erzeugt und spiegelt damit den aktuellen Datenstand statt einer vorgefertigten Datei unbekannten Alters. Die API gibt Katalog-Metadaten als JSON zurück.

F: Wie groß sind die Datensätze?
A: Die Abdeckung beträgt 285.582.781 Domains über 716 Zonen. Allein die .com-Zone macht 163.422.083 Domains aus. Der Datensatz mit allen registrierten Domains enthält 272.614.863 Zeilen. Technologielisten sind kleiner und fokussierter: 21.639.326 Domains für WordPress, 567.680 für Joomla.

F: Was macht die Katalog-API?
A: Sie stellt den Paketkatalog bereit. GET /api/v1/packages/?type=zone listet Zonenpakete auf, GET /api/v1/packages/?type=technology&q=wordpress durchsucht Technologiepakete, und GET /api/v1/packages/{slug}/ gibt den Detaileintrag zu einem Paket zurück. Anfragen werden mit einem Authorization: Bearer YOUR_API_KEY-Header authentifiziert. Die Kontingente liegen bei 30.000 Aufrufen pro Monat bei Pro und 300.000 bei Enterprise.

F: Was kostet das?
A: Einmalige Paketkäufe beginnen bei $3.50. Für den laufenden Einsatz gibt es zwei Pläne: Pro für $29/Monat mit 50 Paketen plus 10 Datensätzen und 30.000 API-Aufrufen sowie Enterprise für $99/Monat mit 200 Paketen plus 50 Datensätzen und 300.000 API-Aufrufen. Details finden Sie auf der Preisseite.

F: Wie lade ich eine so große Datei am besten?
A: Entpacken Sie sie und werten Sie sie mit einer spaltenorientierten Engine aus. DuckDB liest CSV an Ort und Stelle und bewältigt eine einzelne Zonendatei bequem auf einem Laptop; ClickHouse ist die bessere Wahl, wenn Sie wiederholte Aggregationen über viele Zonen oder die vollständige zonenübergreifende Zusammenstellung brauchen. Tabellenkalkulationen sind bei diesen Zeilenzahlen keine realistische Option.

Fazit

Der Wechsel von WHOIS zu RDAP ist eine echte Verbesserung, aber eine eng begrenzte. Er löst das Formatproblem: Registrierungsmetadaten kommen jetzt als JSON mit dokumentiertem Schema, standardisierter HTTP-Semantik und einem Bootstrap-Verzeichnis, das Ihnen sagt, wo Sie fragen müssen. Er löst nicht das Zugangsproblem — und sollte es nie. Die Kontaktdaten der Domaininhaber wurden per Richtlinie aus den öffentlichen Registrierungsdaten entfernt, und RDAP bildet diese Entscheidung getreu ab.

In der Praxis heißt das: Domaindaten sind technische Daten. Registrar, Datumsangaben, Nameserver, Mail-Konfiguration, aufgelöste Adressen und erkannte Plattformen sind real, vergleichbar und in großem Maßstab verfügbar. Fragen, die in diesen Begriffen gestellt sind, lassen sich präzise beantworten. Fragen, die ein Verzeichnis von Domaininhabern voraussetzen, lassen sich überhaupt nicht beantworten — mit keinem Werkzeug.

Wenn Ihre Arbeit Antworten auf Populationsebene zur Domaininfrastruktur braucht, sind Bulk-Dateien der praktikable Weg: Wählen Sie die Zone, Technologieliste oder Zusammenstellung, die Sie brauchen, aus dem Paketkatalog, laden Sie die CSV herunter und analysieren Sie sie lokal mit Werkzeugen, die Sie ohnehin beherrschen.

Weiterführende Ressourcen

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