Registration Data Access Protocol (RDAP): die Whois-Alternative
Ursprünglich konnten Sie Inhaberinnen und Inhaber einer Domain mithilfe von Whois-Diensten ermitteln, die sich auf das gleichnamige Protokoll stützen. 2015 definierten IETF und ICANN jedoch die ersten RFCs des Protokolls RDAP (Registration Data Access Protocol), das die Whois-Nachfolge eher heute als morgen antreten soll.
Was ist das Registration Data Access Protocol (RDAP)?
Das Registration Data Access Protocol (RDAP) wurde von einer Arbeitsgruppe der Internet Engineering Task Force (IETF) konzipiert. Nach einer knapp vierjährigen Projektphase erschien am 26. Juli 2016 die erste Version des Protokollprofils (1.0), dessen Eigenschaften und Anwendung in verschiedenen Requests for Comments (RFC 7480-7484 und RFC 8056) beschrieben sind. RDAP bietet die Möglichkeit, weiterführende Informationen zu elementaren Internetressourcen wie
- Domain-Namen,
- IP-Adressen oder
- Autonomous System Numbers (ASNs)
sowie verwandten Einträge zu erhalten. Zu diesem Zweck liefert die Whois-Alternative die Basis, um entsprechende Anfragen an die verschiedenen Domain-Registrare zu stellen, die Informationen wie zum Beispiel die Kontaktdaten der Domain-Inhaberinnen und -Inhaber, die Kontaktdaten der Admins (Admin-C) oder die Adresse des verwendeten Nameservers inklusive verwaltende Person in ihren Datenbanken führen.
Warum wurde RDAP entwickelt?
Bereits im Jahr 1982 publizierte die IETF das Protokoll Whois, um einen Abfrage-Service für das damalige ARPANET zu realisieren. Dass es auch nach über einem Vierteljahrhundert (mittlerweile für die Abfrage im Internet) immer noch im Einsatz ist, ist vielen Experten jedoch schon lange ein Dorn im Auge. Der entscheidende Kritikpunkt ist, dass Whois den heutigen technischen Ansprüchen von Internet und Web nicht mehr gerecht wird.
Dabei geht es beispielsweise um die Problematik, dass das Abfrage-Protokoll sich nicht um die Kodierung kümmert und daher keine Unterstützung für nicht-lateinische Schriften bietet (was z. B. deutsche Umlaute ausschließt). Ebenso schwer wiegt die Tatsache, dass der Zugriff auf die Domain-Daten weder über eine gesicherte Verbindung stattfindet, noch regulierbar ist – auch anonyme Nutzerinnen und Nutzer erhalten vollen Zugriff, um zum Beispiel Mail- und Adressdaten abzugreifen.
Projekte wie die Erweiterung Whois++ oder das Denic-Protokoll IRIS (Internet Registry Information Service) lieferten erste Verbesserungsansätze, konnten sich als dauerhafte Whois-Alternative aber nicht durchsetzen. Nachdem lange Zeit auch in der ICANN-Community Diskussionen um die Notwendigkeit der Weiterentwicklung geführt wurden, gab der Sicherheits-Bericht SAC 051 des Security and Stability Advisory Committee (SSAC) im September 2011 den entscheidenden Anstoß, die RDAP-Arbeitsgruppe ins Leben zu rufen.
Im Januar 2023 startete ICANN eine globale Abstimmung, um zu entscheiden, ob WHOIS offiziell durch RDAP ersetzt werden soll. Die notwendige Anzahl an Stimmen wurde erreicht, und die Entscheidung ist gefallen, den Umstieg auf RDAP offiziell durchzusetzen. Ab dem Januar 2025 ist es für DNS-Registries und -Registrars nicht mehr erforderlich, WHOIS zu unterstützen.
Wie funktioniert RDAP?
Für eine Implementierung von RDAP ist es wichtig erstmal verstanden zu haben, wie das Protokoll funktioniert – sowohl auf Client- als auch auf Server-Seite. Dafür lohnt sich ein Blick in den RFCs 7480 bis 7484, wo eine minimale Implementierung des Protokolls ausführlich beschrieben wird. Darüber hinaus gibt es weitere RFCs, worin Erweiterungen des RDAP-Protokolls beschrieben werden. Folgend erklären wir den groben Ablauf des Protokolls über HTTPS, wie er im RFC 7840 beschrieben wird.
Um die Implementierung des Protokolls für Entwicklerinnen und Entwickler zu erleichtern hat ICANN einen RDAP Implementation Guide bereitgestellt.
Aufgaben des Clients:
Die Implementierung von RDAP auf der Client-Seite ist gar nicht komplex. RDAP baut auf HTTP auf, und nutzt dementsprechend die bereits existierenden HTTP-Methoden um Daten zu übermitteln. Clients können mittels den GET- und HEAD-Methoden Anfragen an den Server stellen. Sowohl bei GET- als auch bei HEAD-Anfragen soll ein „Accept“-Header mitgeliefert werden, der spezifiziert, welche Arten von JSON-Dateien vom Client akzeptiert werden.
Aufgaben des Servers:
Auf der Server-Seite ist die Implementierung etwas komplexer, da der Server etliche Spezialfälle abdecken muss. Im Falle einer gelungenen Anfrage soll der Server die angefragten Daten im verlangten Format mit dem HTTP-Statuscode 200 (OK) zurückschicken. Auf GET-Anfragen soll der Server mit den verlangten Inhaberdaten antworten, und auf HEAD-Anfragen soll er angeben, ob er Daten zu dieser Domain zur Verfügung hat.
Falls er weiß, wo die verlangten Daten sind, aber diese nicht selbst zur Verfügung hat, soll er mit ein von den Statuscodes 301, 302, 303, oder 307 antworten. Die URL, unter der die Daten zu finden sind, wird dann unter dem HTTP-Header „Location“ mitgeschickt.
Kann der Server die Anfrage nicht bearbeiten, weil die angeforderten Daten nicht vorhanden sind, soll er mit dem Statuscode 404 (Not Found) antworten. Falls die angeforderten Daten doch vorhanden sind, aber der Server aus einem anderen Grund nicht antworten möchte, soll er mit einem entsprechenden Statuscode aus dem 400er-Bereich antworten. Anfragen, die Fehler enthalten und somit nicht als RDAP-Anfragen verstanden werden können, sollen mit dem Statuscode 400 (Bad Request) beantwortet werden. In diesem Fall können, zusätzliche Informationen im HTTP Entity Body mitgeschickt werden.
Für genauere Informationen zum Ablauf sowie Sicherheit und Erweiterungsmöglichkeiten des Protokolls können Sie sich an den entsprechenden RFCs wenden. Diese sind in folgender Liste verlinkt.
- RFC 7840: HTTP-Ablauf
- RFC 7841: Sicherheitsdienste
- RFC 7842: Anfrageformat
- RFC 7843: JSON-Antworten
- RFC 7844: autoritativen Server finden
Was unterscheidet das Registration Data Access Protocol von Whois?
RDAP erweist sich in vielerlei Hinsicht als verbesserte Version von Whois. Die IETF-Arbeitsgruppe hat sich intensiv mit den Schwachstellen des alten Protokolls auseinandergesetzt und sich bei der Entwicklung des neuen Abfrage-Protokolls daher vor allem auf die Punkte Sicherheit, Strukturierung und Internationalisierung konzentriert. So zeichnet sich die Whois-Alternative durch folgende Neuerungen aus:
- Strukturierte Abfrage- und Antwort-Semantik (inklusive standardisierter Fehlermeldungen)
- Sicherer Zugriff auf die angefragten Kontaktdaten (z. B. via HTTPS)
- Erweiterbarkeit (z. B. Hinzufügen von Ausgabeelementen)
- „Bootstrapping“-Mechanismus (unterstützt bei der Suche nach dem geeigneten autoritativen DNS-Server)
- Standardisierte Weiterleitung der Abfragen
- Webbasiert (HTTP) und REST-konform
- Unkomplizierte Übersetzung der Ausgabedaten
- Möglichkeit, differenzierten Zugriff auf die Kontaktdaten zu gewähren
Das Registration Data Access Protocol erweist sich also in vielen Punkten als deutlich flexibler als sein Vorgänger: Während Whois als textbasiertes Protokoll an TCP und den spezifischen TCP-Port (43) gebunden ist, nutzt RDAP für die Datenübertragung den Web-Standard HTTP bzw. HTTPS. Dabei werden sämtliche Daten in einem standardisierten, maschinenlesbaren JSON-Format ausgeliefert. Auf diese Weise gewährt die Whois-Alternative einerseits mehr Freiheiten bei der Datenabfrage und vereinfacht es andererseits, Abfrage-Services zu programmieren, die mit den unterschiedlichen Registrierungsstellen kommunizieren und die abgefragten Daten in verschiedenen Sprachen ausgeben können.
| RDAP | Whois |
|---|---|
| HTTP-basiert | textbasiert |
| Standardisiertes JSON-Format | Keine Codier-Schemata |
| Ausgabedaten sind maschinenlesbar und unkompliziert übersetzbar | Ausgabedaten sind im Klartext und können daher nicht ohne Weiteres maschinell verarbeitet werden |
| Antworten leiten automatisch an andere Registrierungsstellen weiter | Antworten enthalten keine weiterführenden Register-Informationen |
| Möglichkeit, Zugriffsrechte für verschiedene Gruppen zu definieren | Differenzierter Zugriff auf Daten nicht möglich |
- Inklusive 1 SSL-Wildcard-Zertifikat pro Vertrag
- Inklusive Domain Lock
- Inklusive Domain Connect für einfache DNS-Einrichtung
Option für differenzierte Zugriffsrechte sorgt noch für Gesprächsstoff
Eine der wichtigsten neuen Funktionen, die in das Registration Data Access Protocol implementiert wurde, ist ohne Zweifel die Möglichkeit, verschiedene Zugriffsrechte für einzelne Nutzergruppen festlegen zu können. Auf diese Weise kann die Registrierungsstelle im Detail regeln, wer welche Daten zu Gesicht bekommt. So ist zum Beispiel denkbar, anonymen Usern limitierten Zugriff zu gewähren, während authentifizierte Benutzerinnen und Benutzer den kompletten Datensatz einsehen können. An dieser Stelle sehen viele Verantwortliche jedoch entscheidenden Klärungsbedarf.
Unter anderem steht die Frage im Raum, wie zum Beispiel mit Personen in der Strafverfolgung umgegangen werden soll, die anonym bleiben und dennoch die vollen Zugriffsmöglichkeiten haben wollen. Ferner gibt es keine Richtlinien dazu, ob in einem solchen Fall auch die Einsicht in die Domain-Daten über Ländergrenzen hinaus gewährt werden darf. Über allem steht derweil der Schutz der Nutzerdaten und damit verbunden das Vertrauen der Betreibenden, die ihre Domain registrieren. Und dieses Vertrauen soll auf keinen Fall unter der neuen RDAP-Abfrage-Technik leiden. Nachdem verschiedene Registries Ende 2016 Berufung gegen die auferlegte Umsetzungsfrist der ICANN eingelegt haben, plant die Organisation, die Whois-Alternative durch Verträge mit den Registrierungsstellen und Domain-Anbietern durchzusetzen.