Lange Zeit war das WHOIS-Protokoll der unangefochtene Standard, um herauszufinden, wem eine Domain gehört. Doch die Tage des alten Systems sind gezählt. Bereits 2015 legten die IETF und die ICANN den Grundstein für eine zeitgemäße Nachfolge: das Registration Data Access Protocol (RDAP). Was als technische Evolution begann, ist Pflicht geworden – der Übergang von der alten „Telefonbuch-Abfrage“ hin zu einem modernen, datenschutzkonformen Protokoll.
Der Status Quo: Was ist eigentlich WHOIS?
Um das Internet navigierbar zu machen, verwaltet die ICANN (Internet Corporation for Assigned Names and Numbers) die riesigen Namensräume der Domains und die zugehörigen IP-Adressen. Ein zentraler Bestandteil dieser Verwaltung ist die Verknüpfung von technischen Daten (DNS, IP) mit den realen Eigentümern.
Registriert eine Person oder ein Unternehmen eine Domain, landen die entsprechenden Kontaktdaten über den Registrar in einer Datenbank. Genau hier setzte WHOIS an: Es fungierte als öffentliches Register, das Transparenz schaffen soll. Primär ging es darum, die Rechtmäßigkeit einer Registrierung zu prüfen und bei technischen Problemen oder Rechtsverletzungen einen Ansprechpartner greifbar zu haben.
Ein klassischer WHOIS-Datensatz enthielt in der Regel:
- Den Domainnamen und den zuständigen Registrar
- Informationen zu den Nameservern
- Wichtige Zeitstempel (Registrierung, letzte Änderung, Ablaufdatum)
- Status-Codes der Domain (z. B.
ActiveoderLocked) - Kontaktdaten für administrative (Admin-C) und technische (Tech-C) Belange
- Informationen zum Domaininhaber (Owner)
Das Problem: WHOIS stammte aus einer anderen Zeit. Insbesondere seit Einführung der DSGVO (GDPR) in Europa waren die meisten dieser Daten öffentlich nicht mehr einsehbar oder stark anonymisiert („REDACTED FOR PRIVACY“), was den ursprünglichen Nutzen des Protokolls stark eingeschränkt hat.
Der Nachfolger: Was ist das Registration Data Access Protocol (RDAP)?
RDAP ist die Antwort der Internet-Community auf die veraltete Infrastruktur von WHOIS. Entwickelt von einer Arbeitsgruppe der IETF (Internet Engineering Task Force), wurde die Version 1.0 des Protokolls im Juli 2016 veröffentlicht (dokumentiert u. a. in RFC 7480 bis RFC 7484).
Im Kern ist RDAP ein Protokoll, das Zugriff auf Registrierungsdaten von Internetressourcen gewährt. Dazu gehören nicht nur Domain-Namen, sondern auch IP-Adressen und Autonome Systemnummern (ASNs). RDAP modernisierte die Art und Weise, wie Abfragen an Domain-Registrare gestellt werden, um Daten über Inhaber, Admins oder Nameserver-Betreiber zu erhalten. Es bildet die technische Brücke zwischen dem Anfragenden und den Datenbanken der Registrare.
Warum war die Entwicklung von RDAP notwendig?
Das WHOIS-Protokoll ist ein Relikt aus den Kindertagen des Internets. Die IETF veröffentlichte es bereits 1982 für das damalige ARPANET. Dass eine Technologie über 40 Jahre später noch fast unverändert im Einsatz war, grenzt in der IT-Welt an ein Wunder – war aber auch ein massives Sicherheitsrisiko.
Die Hauptkritikpunkte an WHOIS:
- Fehlende Standardisierung: WHOIS war ein textbasiertes Protokoll ohne strikte Formatvorgaben. Das Parsen der Daten war fehleranfällig.
- Keine Internationalisierung: Es gab keine native Unterstützung für nicht-lateinische Zeichen (keine Umlaute, keine chinesischen Schriftzeichen etc.), da die Kodierung nicht definiert war.
- Sicherheitsmängel: WHOIS-Abfragen liefen unverschlüsselt. Zudem gab es keine Möglichkeit, den Zugriff granular zu steuern – entweder waren alle Daten öffentlich oder keine. Das erleichterte Datendiebstahl und Spam massiv.
Nach gescheiterten Modernisierungsversuchen (wie WHOIS++ oder IRIS) gab ein Sicherheitsbericht des SSAC im Jahr 2011 den finalen Anstoß für RDAP. Wichtiger Meilenstein: Im Januar 2023 entschied die globale ICANN-Community per Abstimmung, WHOIS offiziell in den Ruhestand zu schicken. Im Januar 2025 entfiel für Registries und Registrare die Pflicht, WHOIS zu unterstützen. RDAP wurde damit zum verbindlichen Standard.
Deep Dive: Wie funktioniert RDAP technisch?
Den Grundstein für jede RDAP-Struktur legen die RFCs 7480 bis 7484. In diesen Dokumenten wird detailliert definiert, wie eine Minimalimplementierung des Protokolls auszusehen hat. Wer über die Standardfunktionen hinausgehen möchte, findet in ergänzenden RFCs zudem zahlreiche Erweiterungsmöglichkeiten, um das Protokoll an spezifische Anforderungen anzupassen.
Ein zentraler Aspekt ist die Kommunikation über das gesicherte Hypertext-Übertragungsprotokoll. Im Folgenden skizzieren wir den systematischen Ablauf einer RDAP-Abfrage über HTTPS, basierend auf den Richtlinien des RFC 7480.
Wer RDAP implementieren möchte, muss das Zusammenspiel von Client und Server verstehen. Im Gegensatz zum simplen TCP-Stream von WHOIS setzt RDAP auf moderne Web-Standards.
Für Entwickler und Entwicklerinnen bietet die ICANN hierzu einen detaillierten RDAP Implementation Guide an.
Die Client-Seite
Für Clients ist RDAP sehr komfortabel. Da das Protokoll auf HTTP/HTTPS aufsetzt, werden gewöhnliche RESTful-Methoden genutzt. Ein Client sendet eine Anfrage per GET oder HEAD. Wichtig dabei ist der Accept-Header, der dem Server signalisiert, dass eine Antwort im JSON-Format erwartet wird.
Die Server-Seite
Der Server übernimmt die schwere Arbeit. Er muss verschiedene Szenarien abdecken und mit standardisierten HTTP-Statuscodes antworten:
- 200 OK: Die Daten wurden gefunden und werden als JSON zurückgesendet.
- 3xx (Redirection): Der Server kennt die Daten nicht, weiß aber, welcher andere Server zuständig ist (z. B. Weiterleitung von der Registry zum Registrar). Die Ziel-URL steht im Location-Header.
- 404 Not Found: Die Ressource existiert nicht.
- 400 Bad Request: Die Anfrage war fehlerhaft.
Für Entwickler und Administratoren, die tiefer in die Materie eintauchen möchten, ist die technische Dokumentation der Internet Engineering Task Force (IETF) die primäre Quelle. In den sogenannten Request for Comments (RFCs) sind nicht nur die Sicherheitsstandards festgeschrieben, sondern auch die exakten Formate für Abfragen und Antworten definiert.
Die folgende Übersicht bündelt die essenziellen Referenzen für eine regelkonforme Integration und zeigt auf, welche Dokumente für Sicherheit und Skalierbarkeit entscheidend sind:
- RFC 7480: Nutzung von HTTP für RDAP – Definiert den technischen Ablauf der Kommunikation über das Hypertext-Übertragungsprotokoll.
- RFC 7481: Sicherheitsmechanismen – Beschreibt die Implementierung von Sicherheitsdiensten zum Schutz der Datenabfrage.
- RFC 7482: Syntax der Suchanfragen – Legt fest, wie Abfragen (Queries) strukturiert sein müssen, um vom Server korrekt verarbeitet zu werden.
- RFC 7483: JSON-Datenformate – Spezifiziert die Repräsentation der Antwortdaten im JSON-Format für eine optimale Interoperabilität.
- RFC 7484: Lokalisierung autoritativer Quellen – Erläutert das Verfahren, um den jeweils zuständigen Server für eine spezifische Anfrage zu identifizieren.
Ein korrekt implementierter RDAP-Client sollte diese Standards strikt befolgen, um eine nahtlose Kommunikation mit den verschiedenen Registry-Systemen weltweit zu gewährleisten.
Der Vergleich: RDAP vs. WHOIS
RDAP war nicht nur ein Update, es war eine komplette Neuarchitektur. Die Entwickler hatten sich auf Sicherheit, Struktur und Internationalisierung fokussiert und dabei einige Schwachstellen des alten Protokoll ausgemerzt. Hier die wichtigsten Unterschiede im Überblick:
- Technologie: WHOIS nutzte Port 43 und lieferte rohen Text. RDAP nutzt HTTPS und liefert strukturiertes JSON.
- Verarbeitbarkeit: WHOIS-Daten waren für Menschen lesbar, aber für Maschinen schwer zu interpretieren („Textsalat“). RDAP liefert maschinenlesbare Daten, die sich leicht in Anwendungen integrieren und übersetzen lassen.
- Vernetzung: WHOIS war oft eine Sackgasse. RDAP leitet Anfragen intelligent an die zuständige Stelle weiter (Referral-System).
- Zugriffskontrolle: Während WHOIS oft nur „Alles oder Nichts“ kannte, erlaubt RDAP differenzierte Zugriffsrechte (Tiered Access).
| Merkmal | WHOIS | RDAP |
| Protokoll-Basis | Textbasiert (TCP Port 43) | Webstandard (HTTPS / REST) |
| Datenformat | Unstrukturierter Text | Standardisiertes JSON |
| Sprachunterstützung | Eingeschränkt (oft nur ASCII) | Vollständige UTF-8 Unterstützung |
| Automatisierung | Fehleranfällig beim Parsen | Ideal für APIs und Software |
| Datenschutz | Keine granulare Kontrolle | Differenzierter Zugriff möglich |
Datenschutz und „Tiered Access“: Die große Kontroverse
Das wohl mächtigste Feature von RDAP ist der sogenannte Tiered Access (abgestufter Zugriff). Registries können nun genau steuern, wer welche Daten sieht.
- Öffentlicher Zugriff: Anonyme Nutzer sehen nur Basisdaten (ähnlich wie beim heutigen DSGVO-konformen WHOIS).
- Autorisierter Zugriff: Verifizierte Nutzer (z. B. Rechteinhaber, Sicherheitsfirmen) könnten nach einem Login vollen Zugriff auf die Kontaktdaten erhalten.
Dieses Feature sorgt jedoch auch für Diskussionen. Es ist noch nicht abschließend geklärt, wie beispielsweise Strafverfolgungsbehörden Zugriff erhalten, wenn sie anonym bleiben müssen oder wie der grenzüberschreitende Datenzugriff geregelt wird.
Das Ziel ist klar: Das Vertrauen der Domain-Inhaber in den Schutz ihrer Daten muss gewahrt bleiben, ohne die legitime Bekämpfung von Cyberkriminalität unmöglich zu machen. Trotz dieser offenen Fragen ist der Weg vorgezeichnet: Die ICANN wird RDAP über vertragliche Bindungen mit den Registraren als den neuen, sicheren Standard durchsetzen.
Fazit
Der Abschied von WHOIS war mehr als nur eine technische Modernisierung – er war ein notwendiger Schritt in ein sichereres Internetzeitalter. Mit RDAP wurde der jahrzehntealte Konflikt zwischen der Transparenz von Domain-Daten und dem Schutz der Privatsphäre (DSGVO) endlich technologisch lösbar.
Während WHOIS wie ein staubiges Telefonbuch aus den 80ern wirkte, liefert RDAP die flexible, verschlüsselte und maschinenlesbare Infrastruktur, die das moderne Web benötigt. Auch wenn Detailfragen zu den Zugriffsrechten noch diskutiert werden, ist die Richtung klar: Spätestens seit 2025 gehörte die Zukunft dem strukturierten Datenaustausch via RDAP. Für Domain-Inhaber und Administratoren bedeutete das langfristig mehr Sicherheit und eine verlässlichere Datenverwaltung.
FAQ - Häufig gestellte Fragen
Müssen Endnutzer spezielle Software installieren, um RDAP zu nutzen?
Nein, in der Regel nicht. Da RDAP auf dem HTTP-Protokoll basiert, können Abfragen theoretisch direkt über die Adresszeile eines Webbrowsers getätigt werden (z. B. https://rdap.example.org/domain/beispiel.de). Für Endanwender haben Domain-Registrare und Lookup-Dienste ihre Webinterfaces im Hintergrund auf RDAP umgestellt, sodass sich an der gewohnten Benutzeroberfläche optisch meist nichts ändert. Für Administratoren gibt es jedoch spezielle Kommandozeilen-Tools (wie rdap statt whois), die installiert werden können.
Was passiert mit alten Skripten, die auf Port 43 (WHOIS) zugreifen?
Skripte, die automatisiert den Port 43 abfragen und versuchen, den Rückgabetext via „Screen Scraping“ zu analysieren (Regex etc.), werden nach der endgültigen Abschaltung der WHOIS-Dienste nicht mehr funktionieren. Entwickler und Systemadministratoren müssen diese Tools umschreiben, damit sie stattdessen die JSON-Antworten der RDAP-Schnittstellen verarbeiten. Da JSON ein standardisiertes Format ist, sind diese neuen Skripte jedoch deutlich robuster und wartungsärmer als ihre Vorgänger.
Wie geht RDAP mit „Rate Limiting“ (Abfragebegrenzungen) um?
Beim alten WHOIS-Protokoll war das Blockieren von IP-Adressen oft willkürlich und undurchsichtig, wenn zu viele Anfragen gestellt wurden. RDAP nutzt hierfür standardisierte HTTP-Mechanismen. Wenn ein Nutzer zu viele Anfragen sendet, antwortet der Server mit dem Statuscode 429 Too Many Requests. Oft wird im Header sogar mitgesendet, wann eine erneute Anfrage erlaubt ist (Retry-After). Dies ermöglicht es Clients, ihre Abfragen intelligent zu drosseln, statt einfach blockiert zu werden.
Vereinfacht RDAP das Melden von Missbrauch (Abuse Reporting)?
Ja, deutlich. Im Gegensatz zu WHOIS, wo Abuse-Kontaktadressen oft irgendwo im Freitext versteckt waren, definiert RDAP strukturierte Felder speziell für Missbrauchsmeldungen. Sicherheitsforscher und Behörden können diese Felder automatisiert auslesen, um Spam, Phishing oder Malware (wie Ransomware, Trojaner, Spyware, etc.) schneller an die zuständige Stelle zu melden, ohne den Text manuell durchsuchen zu müssen.
Gilt RDAP auch für „New gTLDs“ (neue generische Top-Level-Domains)?
Ja. Tatsächlich sind Betreiber von neuen gTLDs (wie .shop, .berlin, .app) schon länger vertraglich dazu verpflichtet, RDAP anzubieten. Die große Umstellung betrifft nun vor allem die „alten“ Schwergewichte (Legacy TLDs) wie .com, .net oder .org, die nun nachziehen und das System flächendeckend zum Standard machen.
Kann RDAP dabei helfen, gefälschte Daten zu erkennen?
Indirekt ja. Da RDAP die Validierung von Datenformaten (z. B. E-Mail-Syntax oder Telefonnummern-Formate) durch die JSON-Struktur erleichtert, können Registrare theoretisch schon bei der Eingabe oder Ausgabe strengere Prüfmechanismen anwenden. Zudem erlaubt die digitale Signatur von RDAP-Antworten sicherzustellen, dass die angezeigten Daten tatsächlich von der autoritativen Quelle stammen und nicht auf dem Weg zum Empfänger manipuliert („Man-in-the-Middle“-Angriff) wurden.