WHOIS vs. RDAP: Die Zukunft der Domain-Abfragen

Warum Domain-Verzeichnisdienste wichtig sind

Hinter jeder registrierten Domain steht ein Datensatz: bei welchem Registrar sie liegt, wann sie angelegt wurde, wann sie abläuft, an welche Nameserver sie delegiert ist und welche Statuscodes sie sperren oder einschränken. Sicherheitsteams nutzen diese Daten zur Untersuchung von Phishing, Markeninhaber zum Aufspüren rechtsverletzender Registrierungen und Administratoren, um sicherzugehen, dass die eigenen Domains nicht unbemerkt auslaufen. Über drei Jahrzehnte lang war WHOIS das Werkzeug dafür. Heute wird es durch RDAP abgelöst, das Registration Data Access Protocol.

Dieser Leitfaden erklärt, wie beide Protokolle funktionieren, was sich technisch geändert hat, was die Entscheidungen der ICANN praktisch bedeuten und wie Sie beide selbst abfragen können.

So funktioniert das WHOIS-Protokoll

WHOIS ist älter als das kommerzielle Web. Die aktuelle Spezifikation, RFC 3912 aus dem Jahr 2004, umfasst nur wenige Seiten, weil das Protokoll denkbar einfach ist: Der Client baut eine TCP-Verbindung zu Port 43 auf, sendet eine einzelne Textzeile (meist den Domainnamen), und der Server antwortet mit Freitext und schließt die Verbindung.

whois beispiel.de
whois -h whois.verisign-grs.com example.com

Diese Schlichtheit machte WHOIS leicht implementierbar, hinterließ aber erhebliche Lücken, die mit dem Wachstum der Domainbranche immer deutlicher wurden.

Die Schwächen von WHOIS

• Kein einheitliches Ausgabeformat. Jede Registry und jeder Registrar wählt eigene Feldnamen, Datumsformate und Layouts. Der eine schreibt Registry Expiry Date, der nächste expires, ein dritter paid-till. Software muss fehleranfällige Parser für Hunderte Varianten pflegen.
• Keine Server-Ermittlung. Das Protokoll legt nicht fest, welcher Server für eine Endung zuständig ist. Clients verlassen sich auf fest hinterlegte Listen oder auf Verweise im Antworttext.
• Keine Internationalisierung. RFC 3912 definiert keine Zeichenkodierung, daher erscheinen Umlaute und andere Nicht-ASCII-Zeichen häufig verstümmelt.
• Keine Authentifizierung, keine Verschlüsselung. Der Datenverkehr läuft im Klartext, und unterschiedliche Zugriffsstufen für verschiedene Nutzer sind nicht möglich.
• Thin- und Thick-Modell. Bei Thin-Registries wie .com speichert die Registry nur Basisdaten; für den Rest muss der Client einem Verweis zum WHOIS-Server des Registrars folgen.

Was RDAP ist und wie es funktioniert

RDAP wurde in der IETF-Arbeitsgruppe WEIRDS gezielt als Nachfolger von WHOIS entwickelt. Statt eines eigenen Textprotokolls nutzt es gewöhnliche HTTPS-Anfragen und liefert JSON. Abfragen sind REST-artige URLs, sodass jeder HTTP-Client, jeder Browser und jede Skriptsprache RDAP ohne spezielle Bibliotheken verwenden kann.

Die RFCs hinter RDAP

Abfragetypen

RDAP definiert eine überschaubare Zahl von Objektpfaden. Für Domaininhaber sind diese am wichtigsten:

• /domain/beispiel.de – Registrierungsdaten einer Domain
• /nameserver/ns1.beispiel.de – Informationen zu einem Nameserver
• /entity/HANDLE – Registrar, Inhaber oder ein anderes Kontaktobjekt
• /ip/192.0.2.0 und /autnum/64496 – IP-Netze und AS-Nummern, bereitgestellt von den regionalen Internet-Registries

Bootstrap: den richtigen Server finden

Die IANA veröffentlicht Bootstrap-Dateien im JSON-Format, die jeder Endung, jedem IP-Bereich und jedem AS-Nummernbereich die Basis-URL des zuständigen RDAP-Dienstes zuordnen. Für Domains liegt die Datei unter https://data.iana.org/rdap/dns.json. Der Client liest die Endung aus der Anfrage, sucht sie in der Datei und schickt die Anfrage an die angegebene Adresse. Rätselraten und fest verdrahtete Serverlisten, wie WHOIS-Clients sie brauchten, entfallen damit.

WHOIS und RDAP im direkten Vergleich

Wann welches Protokoll?

Für einen schnellen Blick auf eine Domain in der Kommandozeile ist das klassische whois noch praktisch, bei gTLDs müssen Sie inzwischen aber mit unvollständigen oder leeren Antworten rechnen. Für Automatisierung, Monitoring und Reporting ist RDAP immer die bessere Wahl: Die Antwortstruktur ist bei allen Betreibern gleich, Datumsfelder haben ein einheitliches Format, und Fehler werden klar über HTTP-Statuscodes gemeldet. WHOIS bleibt die Rückfalloption für Endungen ohne RDAP-Dienst.

RDAP in der Praxis abfragen

Da RDAP schlicht HTTPS ist, genügt curl. Sie können eine Registry direkt abfragen oder einen Weiterleitungsdienst wie rdap.org nutzen, der die IANA-Bootstrap-Daten auswertet und Sie zum zuständigen Server weiterleitet.

curl -s https://rdap.verisign.com/com/v1/domain/example.com
curl -sL https://rdap.org/domain/example.com

Eine gekürzte Antwort sieht so aus:

{
  "objectClassName": "domain",
  "ldhName": "EXAMPLE.COM",
  "status": ["client delete prohibited", "client transfer prohibited"],
  "events": [
    {"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"},
    {"eventAction": "expiration", "eventDate": "2026-08-13T04:00:00Z"}
  ],
  "nameservers": [{"ldhName": "A.IANA-SERVERS.NET"}]
}

Für die Überwachung von Verlängerungen ist das Array events am wichtigsten: Das Ereignis expiration ist ein maschinenlesbarer Zeitstempel im ISO-8601-Format – ob 03/04/2027 nun März oder April bedeutet, muss niemand mehr raten. Die Statuswerte entsprechen den in RFC 5731 definierten EPP-Statuscodes, kleingeschrieben und mit Leerzeichen. Kontaktdaten stehen unter entities, klassisch im jCard-Format (RFC 7095); neuere Implementierungen ergänzen JSContact als Alternative.

Fehler und Abfragelimits

RDAP-Server folgen der üblichen HTTP-Semantik. Ein 404 bedeutet, dass das Objekt auf diesem Server nicht existiert – bei einer Domain heißt das meist, dass sie nicht registriert ist. Ein 429 signalisiert ein Rate-Limit; ein sauber programmierter Client wartet und versucht es später erneut. Weiterleitungen (301, 302, 307) verweisen von einem Server auf einen anderen, daher sollten Sie ihnen immer folgen.

ICANN-Vorgaben und das WHOIS-Aus 2025

Die ICANN verpflichtete gTLD-Registries und Registrare ab dem 26. August 2019 zum Betrieb von RDAP-Diensten. Einige Jahre liefen beide Protokolle parallel. Nach Änderungen an den Registry- und Registrarverträgen legte die ICANN den 28. Januar 2025 als Stichtag fest, ab dem Vertragspartner für generische Endungen keinen WHOIS-Dienst auf Port 43 mehr betreiben müssen. Seitdem ist RDAP die maßgebliche Quelle für Registrierungsdaten von .com, .net, .org und den neuen gTLDs.

Manche Betreiber beantworten Port-43-Anfragen freiwillig weiter, verlassen sollten Sie sich darauf aber nicht. Skripte und Monitoring-Systeme, die WHOIS-Text für gTLD-Domains auswerten, sollten auf RDAP umgestellt werden.

Und die länderspezifischen Endungen?

ccTLDs wie .de, .at oder .ch unterliegen nicht den ICANN-Verträgen und legen ihre Regeln selbst fest. Immer mehr von ihnen veröffentlichen RDAP-Dienste in der IANA-Bootstrap-Datei, viele bieten aber weiterhin nur WHOIS an, einige gar keinen öffentlichen Dienst. Ein praxistauglicher Client prüft daher zuerst die Bootstrap-Datei und greift auf den WHOIS-Server der ccTLD zurück, wenn dort keine RDAP-Adresse hinterlegt ist.

Datenschutz, Schwärzung und DSGVO

Seit Inkrafttreten der DSGVO im Mai 2018 sind die meisten personenbezogenen Inhaberdaten in gTLD-Datensätzen geschwärzt. RDAP gibt von sich aus nicht mehr preis als WHOIS; es gelten dieselben Richtlinien. Neu ist, dass RDAP Schwärzungen standardisiert kennzeichnen und grundsätzlich authentifizierten Nutzern wie Strafverfolgungsbehörden Zugriff auf vollständigere Daten gewähren kann. Die Registration Data Policy der ICANN, die Vertragspartner bis zum 21. August 2025 umsetzen mussten, regelt, welche Felder erhoben, veröffentlicht oder geschwärzt werden.

Für die meisten Domaininhaber heißt das: Eine öffentliche Abfrage zeigt Registrar, Daten, Nameserver und Statuscodes, aber weder Namen noch E-Mail-Adresse des Inhabers. Wer den Inhaber kontaktieren muss, findet im Datensatz des Registrars meist einen Link zu einem Kontaktformular oder eine Abuse-Adresse.

RDAP für die Überwachung von Ablaufdaten nutzen

Für alle, die mehr als eine Handvoll Domains verwalten, ist der Umstieg auf RDAP eine gute Nachricht. Ablaufdaten kommen in einem einheitlichen, auswertbaren Format, Statuscodes sind standardisiert, und der Registrar ist über seine IANA-ID eindeutig identifiziert. Automatisches Monitoring wird dadurch weit zuverlässiger als das Auslesen von WHOIS-Text.

1. Den autoritativen RDAP-Server über die IANA-Bootstrap-Datei ermitteln.
2. Das Domain-Objekt abrufen und das Ereignis expiration auslesen.
3. Statuscodes wie client hold, redemption period oder pending delete prüfen, die auf ein Problem hinweisen.
4. Für Endungen ohne RDAP auf WHOIS zurückfallen und Ergebnisse zwischenspeichern, um Rate-Limits einzuhalten.

TLDix arbeitet genau nach diesem Prinzip. Die WHOIS- und RDAP-Domainabfrage versucht zuerst RDAP und weicht bei Bedarf auf WHOIS aus, die Hosting-Abfrage nutzt die IP- und ASN-Seite von RDAP, um den Betreiber des Servers hinter einer Domain zu ermitteln. Wie überwachte Domains auf anstehende Abläufe geprüft werden, beschreibt die Dokumentation.

Das Wichtigste in Kürze

WHOIS hat dem Internet lange gute Dienste geleistet, wurde aber nie für strukturierte Daten, Internationalisierung oder Zugriffskontrolle entworfen. RDAP löst diese Probleme auf Basis von HTTPS und JSON, mit klar definierten RFCs und einem von der IANA betriebenen Ermittlungsmechanismus. Bei generischen Endungen ist der Wechsel faktisch abgeschlossen, die ccTLDs ziehen in eigenem Tempo nach. Wer Werkzeuge entwickelt, sollte neuen Code für RDAP schreiben und WHOIS nur als Rückfalloption behalten. Für Domaininhaber bedeutet der Wandel vor allem genauere Ablaufdaten und weniger Überraschungen.