RDAP vs WHOIS: der komplette Leitfaden zur Umstellung (EPP-Codes, DSGVO, Domain-Sperren)
Von CaptainDNS
Veröffentlicht am 17. März 2026
- WHOIS (Port 43) ist seit dem 28. Januar 2025 für gTLDs nicht mehr verpflichtend. 374 TLDs haben es bereits abgeschaltet.
- RDAP (RFC 9082/9083) ist der Nachfolger: strukturierte JSON-Antworten, natives HTTPS, differenzierte Zugriffssteuerung kompatibel mit der DSGVO.
- Die EPP-Codes (wie
clientTransferProhibited) zeigen den Schutzstatus Ihrer Domain an. Eine Domain ohne Transfer-Sperre ist anfällig für Diebstahl. - Prüfen Sie Ihre kritischen Domains mit einem RDAP-Tool: EPP-Status, Ablaufdaten, aktive Sperren.
Im Jahr 2025 ist eine WHOIS-Serverabfrage vergleichbar mit dem Versand eines Faxes: Das Protokoll funktioniert noch, gehört aber einer anderen Epoche an. Seit dem 28. Januar 2025 verlangt die ICANN von gTLD-Registries nicht mehr, einen WHOIS-Dienst auf Port 43 zu betreiben. RDAP (Registration Data Access Protocol) ist fortan das einzige Pflichtprotokoll für den Zugriff auf Domain-Registrierungsdaten.
Dieser Leitfaden behandelt die vollständige Umstellung: warum WHOIS ersetzt wurde, wie RDAP funktioniert, was die in den Ergebnissen angezeigten EPP-Codes bedeuten, wie die DSGVO den Zugang zu Kontaktdaten verändert hat und welche Sperren Sie zum Schutz Ihrer Domains aktivieren sollten.
Testen Sie Ihre Domains jetzt
WHOIS: 40 Jahre Dienst, dann der Ruhestand
Von RFC 812 (1982) bis zum offiziellen Ende (2025)
WHOIS wurde 1982 durch RFC 812 formalisiert, zu einer Zeit, als das Internet nur einige Hundert Hosts zählte. Das Protokoll ist minimalistisch: Der Client öffnet eine TCP-Verbindung auf Port 43, sendet einen Domainnamen im Klartext und erhält eine Antwort in freiem Textformat. Kein standardisiertes Format, keine Verschlüsselung, keine Authentifizierung.
40 Jahre lang erfüllte WHOIS seinen Zweck: die Verantwortlichen einer Domain zu identifizieren. Doch seine technischen Einschränkungen wurden zu kritischen Problemen, je größer das Internet wurde.
ICANN-Zeitplan für das WHOIS-Sunset
Die ICANN plante die Umstellung über mehrere Jahre:
- 2015: Veröffentlichung der RFCs 7480 bis 7484 (erste RDAP-Version)
- 2019: Pflicht für alle gTLD-Registries, RDAP parallel zu WHOIS zu unterstützen
- 2023: Veröffentlichung der RFCs 9082, 9083 und 9224 (konsolidierte RDAP-Version)
- 28. Januar 2025: Ende der WHOIS-Pflicht auf Port 43 für gTLDs
- Februar 2025: 74 gTLD-Registries schalten ihren WHOIS-Dienst im Monat nach dem Sunset ab
- Juni 2025: Das RDAP-Abfragevolumen übertrifft erstmals das von WHOIS
- September 2025: 374 gTLDs haben WHOIS abgeschaltet
- Januar 2026: Die ICANN entzieht dem Registrar Brennercom die Akkreditierung wegen Nichtimplementierung von RDAP, ein Präzedenzfall, der bestätigt, dass RDAP-Konformität nicht optional ist
Das Tempo der Umstellung ist eindeutig: Im Januar 2025 verarbeiteten die gTLD-Registries rund 122 Milliarden WHOIS-Abfragen pro Monat gegenüber 7 Milliarden über RDAP. Im August 2025 war WHOIS auf 49 Milliarden gefallen (Rückgang um 60 %), während RDAP 65 Milliarden erreichte. Die Trendwende erfolgte im Juni 2025.
Der Status variiert je nach TLD-Typ. Für gTLDs ist RDAP obligatorisch und WHOIS fakultativ. Für ccTLDs (.fr, .de, .uk) bleibt die Migration freiwillig, da diese Registries nicht den ICANN-Verträgen unterliegen. Rund 60 % der ccTLDs haben RDAP bereitgestellt (ein Anstieg von 12 % seit Januar 2025), aber einige Schwergewichte wie .de, .cn und .jp bieten noch keinen RDAP-Dienst an.
Warum musste WHOIS ersetzt werden?
Fünf strukturelle Probleme machten WHOIS ungeeignet:
- Kein standardisiertes Format: Jede Registry liefert die Daten in einem anderen Format. Das Parsen von WHOIS-Antworten erfordert registerspezifischen Code.
- Keine Verschlüsselung: Anfragen und Antworten werden im Klartext über Port 43 übertragen. Jeder Netzwerkzwischenpunkt kann sie mitlesen.
- Keine Authentifizierung: Es ist unmöglich, einen Sicherheitsforscher von einem Spammer zu unterscheiden. Alle erhalten dieselben Daten.
- Nicht DSGVO-kompatibel: WHOIS legt standardmäßig die personenbezogenen Daten des Inhabers offen (Name, Adresse, E-Mail, Telefon). Die DSGVO verbietet diese Verbreitung ohne Rechtsgrundlage.
- Keine Internationalisierung: WHOIS unterstützt kein Unicode. Internationalisierte Domainnamen (IDN) und Nicht-ASCII-Kontakte sind problematisch.
RDAP: der moderne Nachfolger
Wie funktioniert RDAP? (IANA-Bootstrap, HTTP-Abfrage, JSON-Antwort)
RDAP beruht auf drei Komponenten:
1. Der IANA-Bootstrap: Wie findet man den richtigen Server?
Im Gegensatz zu WHOIS, wo man den Server jeder Registry kennen muss, verwendet RDAP ein zentrales Register der IANA (RFC 9224). Diese JSON-Datei listet für jede TLD die URL des entsprechenden RDAP-Servers auf. Der RDAP-Client konsultiert diese Datei, identifiziert den Server für die gesuchte TLD und sendet die Abfrage.
2. Die HTTP-Abfrage: eine einfache URL
GET https://rdap.verisign.com/com/v1/domain/captaindns.com
Kein binäres Protokoll, kein exotischer Port. Es handelt sich um eine Standard-HTTPS-Anfrage, kompatibel mit jedem Browser, HTTP-Client oder Automatisierungstool.
3. Die JSON-Antwort: strukturierte Daten
Der Server gibt ein nach RFC 9083 normiertes JSON-Objekt zurück. Jedes Feld hat einen definierten Namen, einen präzisen Typ und eine dokumentierte Semantik. Kein Parsen von Freitext mehr nötig.
Vergleich WHOIS vs RDAP
| Kriterium | WHOIS | RDAP |
|---|---|---|
| Protokoll | TCP Port 43, Klartext | HTTPS, strukturiertes JSON |
| Verschlüsselung | Keine | Natives TLS |
| Antwortformat | Freitext, nicht standardisiert | Normiertes JSON (RFC 9083) |
| Authentifizierung | Keine | OAuth 2.0, differenzierte Zugriffe |
| Internationalisierung | Eingeschränkt (ASCII) | Vollständiges Unicode (IDN unterstützt) |
| Servererkennung | Manuell (je TLD hartcodiert) | Automatisch (IANA-Bootstrap, RFC 9224) |
| DSGVO-Konformität | Ohne Proxy unmöglich | Nativ (selektive Schwärzung) |
| ICANN-Status (gTLD) | Optional seit 01/2025 | Obligatorisch |
In der Praxis: dieselbe Abfrage bei WHOIS und RDAP
Um den Unterschied greifbar zu machen, sehen Sie hier, was beide Protokolle für captaindns.com zurückliefern.
WHOIS-Antwort (Klartext, Port 43):
Domain Name: CAPTAINDNS.COM
Registry Domain ID: 2925482234_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.infomaniak.com
Registrar URL: http://www.infomaniak.com
Updated Date: 2025-09-11T08:32:12Z
Creation Date: 2025-09-08T06:06:37Z
Registry Expiry Date: 2026-09-08T06:06:37Z
Registrar: Infomaniak Network SA
Domain Status: clientTransferProhibited
Name Server: CHELSEA.NS.CLOUDFLARE.COM
Name Server: HAL.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Jede Registry formatiert diese Antwort anders. Kein gemeinsames Schema, keine Garantie für die Reihenfolge oder die Feldnamen.
RDAP-Antwort (strukturiertes JSON, HTTPS):
{
"objectClassName": "domain",
"ldhName": "CAPTAINDNS.COM",
"status": ["client transfer prohibited"],
"events": [
{ "eventAction": "registration", "eventDate": "2025-09-08T06:06:37Z" },
{ "eventAction": "expiration", "eventDate": "2026-09-08T06:06:37Z" },
{ "eventAction": "last changed", "eventDate": "2025-09-11T08:32:12Z" }
],
"nameservers": [
{ "ldhName": "CHELSEA.NS.CLOUDFLARE.COM" },
{ "ldhName": "HAL.NS.CLOUDFLARE.COM" }
],
"secureDNS": { "delegationSigned": false },
"rdapConformance": [
"rdap_level_0",
"icann_rdap_technical_implementation_guide_1",
"icann_rdap_response_profile_1"
]
}
Dieselben Daten, aber in einem vorhersehbaren, typisierten und von jeder JSON-Bibliothek analysierbaren Format. Das Feld rdapConformance gibt an, welche ICANN-Profile der Server einhält, eine Information, die bei WHOIS nicht existierte. Testen Sie es selbst mit dem RDAP Lookup.
Thin- vs. Thick-Registries: Warum zwei Abfragen für .com?
Bei einigen TLDs wie .com sind die Registrierungsdaten auf zwei Ebenen verteilt:
- Die Registry (Verisign für .com) speichert die Minimaldaten: Domainname, Nameserver, Daten, EPP-Status. Es handelt sich um eine Thin Registry.
- Der Registrar (der Wiederverkäufer: OVHcloud, Gandi, GoDaddy usw.) speichert die vollständigen Daten: Inhaberkontakt, Rechnungsinformationen, administrative Details.
Wenn Sie RDAP für eine .com-Domain abfragen, liefert die Verisign-Registry die Basisdaten und fügt einen Link zum RDAP-Server des Registrars für die vollständigen Daten bei. Ein vollständiger RDAP-Client folgt diesem Link automatisch.
Andere TLDs wie .fr (AFNIC) sind Thick Registries: Alle Daten sind auf Ebene der Registry zentralisiert. Eine einzige Abfrage genügt.
Kennzahlen 2025
- 374 gTLDs haben WHOIS auf Port 43 abgeschaltet
- 65 Milliarden RDAP-Abfragen pro Monat, verarbeitet von gTLD-Registries (August 2025)
- 100 Milliarden monatliche RDAP-Abfragen über alle Registries hinweg (gTLDs, RIRs, IANA-Bootstrap)
- 60 % der ccTLDs haben einen RDAP-Server bereitgestellt (gegenüber 48 % im Januar 2025)
- 100 % der gTLD-Registries sind zur RDAP-Unterstützung verpflichtet
RDAP-Abdeckung nach TLD-Typ
Alle gTLDs unterstützen RDAP, doch die ccTLD-Abdeckung ist ungleichmäßig. Nationale Registries sind nicht an ICANN-Verträge gebunden und migrieren in ihrem eigenen Tempo.
| ccTLD | Land | RDAP | Registrierte Domains (geschätzt) |
|---|---|---|---|
| .uk | Vereinigtes Königreich | Ja (seit 2022) | 10,5 Mio. |
| .fr | Frankreich | Ja (seit 2022) | 4 Mio. |
| .nl | Niederlande | Ja (seit 2024) | 6,2 Mio. |
| .br | Brasilien | Ja (seit 2017, Vorreiter) | 5 Mio. |
| .au | Australien | Ja (seit 2026) | 4,3 Mio. |
| .de | Deutschland | Nein (nur WHOIS) | 17,4 Mio. |
| .cn | China | Nein (nur WHOIS) | 20 Mio. |
| .eu | Europäische Union | Nein (nur WHOIS) | 3,6 Mio. |
| .jp | Japan | Nein (nur WHOIS) | 1,7 Mio. |
| .ru | Russland | Nein (nur WHOIS) | 5 Mio. |
| .us | Vereinigte Staaten | Nein (nur WHOIS) | 1,8 Mio. |
Für ccTLDs ohne RDAP bleibt WHOIS auf Port 43 als Fallback. Wenn Sie ein Multi-TLD-Portfolio verwalten, müssen Ihre Tools beide Protokolle parallel unterstützen.
Ratenbegrenzung und automatisierte Abfragen
Da RDAP-Server einfache HTTPS-APIs sind, implementieren sie Ratenbegrenzung, um Missbrauch (massives Scraping, Massendatenabfrage) zu verhindern. Ein Client, der den zulässigen Schwellenwert überschreitet, erhält eine HTTP-429-Antwort (Too Many Requests).
Best Practices für automatisierte Abfragen:
- Beachten Sie den
Retry-After-Header: Wenn der Server eine 429-Antwort zurückgibt, kann er einen Header mit der Wartezeit vor dem nächsten Versuch enthalten - Implementieren Sie exponentielles Backoff: Erhöhen Sie die Wartezeit zwischen den Versuchen (1 s, 2 s, 4 s, 8 s) mit einer Zufallskomponente, um synchronisierte Abfragebursts zu vermeiden
- Begrenzen Sie Ihren Durchsatz: Die meisten Server tolerieren ein bis zwei Abfragen pro Sekunde. Einige, wie Cloudflare, begrenzen auf 10 Abfragen pro 10-Sekunden-Intervall
- Cachen Sie die Ergebnisse: RDAP-Daten ändern sich selten. Ein Cache von einigen Stunden reduziert die Serverlast und beschleunigt Ihre Verarbeitung
EPP-Codes: die Statuswerte Ihrer Domain verstehen
Die RDAP-Ergebnisse enthalten EPP-Statuscodes (Extensible Provisioning Protocol). Diese Codes zeigen den aktuellen Zustand Ihrer Domain an: Ist sie gegen Transfer geschützt? Wartet sie auf Löschung? Wurde sie von der Registry gesperrt?
Zwei Präfixe unterscheiden die Herkunft des Status:
- client: Vom Registrar (Ihrem Wiederverkäufer) gesetzt, änderbar über Ihre Verwaltungsoberfläche
- server: Von der Registry (Verisign, AFNIC usw.) gesetzt, nur durch die Registry änderbar
Schutzcodes (positiv)
Diese Codes zeigen an, dass Schutzmaßnahmen auf Ihrer Domain aktiv sind. Ihr Vorhandensein ist wünschenswert.
| EPP-Code | Bedeutung | Warum das wichtig ist |
|---|---|---|
clientTransferProhibited | Transfer durch den Registrar gesperrt | Verhindert Domain-Diebstahl durch unautorisierten Transfer |
serverTransferProhibited | Transfer durch die Registry gesperrt | Zusätzlicher Schutz, oft mit einem Registry Lock verbunden |
clientDeleteProhibited | Löschung durch den Registrar gesperrt | Verhindert versehentliche oder böswillige Löschung |
serverDeleteProhibited | Löschung durch die Registry gesperrt | Schutz auf Registry-Ebene gegen Löschung |
clientUpdateProhibited | Änderung durch den Registrar gesperrt | Verhindert unautorisierte Änderung der Nameserver |
serverUpdateProhibited | Änderung durch die Registry gesperrt | Registry-Schutz gegen DNS-Änderungen |
Warnungscodes (kritisch)
Diese Codes signalisieren ein Problem oder eine dringend erforderliche Maßnahme.
| EPP-Code | Bedeutung | Erforderliche Maßnahme |
|---|---|---|
redemptionPeriod | Domain gelöscht, in der Karenzfrist (30 Tage) | Kontaktieren Sie umgehend Ihren Registrar zur Wiederherstellung |
pendingDelete | Endgültige Löschung steht unmittelbar bevor (5 Tage) | Letzte Chance zur Rettung, kontaktieren Sie die Registry |
serverHold | DNS-Auflösung durch die Registry ausgesetzt | Die Domain wird nicht mehr aufgelöst. Prüfen Sie die Verpflichtungen gegenüber der Registry |
clientHold | DNS-Auflösung durch den Registrar ausgesetzt | Häufig verbunden mit offenen Rechnungen oder ausstehender Identitätsprüfung |
Übergangscodes (informativ)
Diese Codes zeigen einen laufenden Vorgang an. Sie sind temporär.
| EPP-Code | Bedeutung | Typische Dauer |
|---|---|---|
pendingTransfer | Transfer zu einem anderen Registrar läuft | 5 Tage (Genehmigungszeitraum) |
pendingCreate | Registrierung wird verarbeitet | Einige Minuten bis einige Stunden |
pendingRenew | Verlängerung wird verarbeitet | Einige Minuten |
pendingUpdate | DNS-Änderung wird verarbeitet | Einige Minuten |
addPeriod | Karenzfrist nach Registrierung (Löschung mit Erstattung möglich) | 5 Tage |
renewPeriod | Karenzfrist nach Verlängerung | 5 Tage |
transferPeriod | Karenzfrist nach Transfer | 5 Tage |
autoRenewPeriod | Domain automatisch verlängert, Stornierung möglich | 30 bis 45 Tage |
Vollständige Tabelle der EPP-Codes
Der Status ok (oder active) ist der Standardstatus: Er zeigt an, dass keine Einschränkung oder Operation aktiv ist. Dieser Status verschwindet, sobald ein anderer Schutz- oder Einschränkungscode aktiviert wird.
Eine korrekt geschützte Domain zeigt mindestens clientTransferProhibited an. Eine kritische Domain (Marke, Hauptwebsite) sollte zusätzlich clientDeleteProhibited und clientUpdateProhibited aufweisen.
Domain-Sperren: der unverzichtbare Schutz
Die 3 Sperrstufen
Stufe 1: Registrar-Sperre (Transfer Lock)
Das ist die Basissperre, aktivierbar über die Oberfläche Ihres Registrars. Sie setzt den Status clientTransferProhibited und verhindert den Transfer der Domain zu einem anderen Registrar ohne Ihre ausdrückliche Genehmigung.
Kosten: bei den meisten Registraren kostenlos. Es gibt keinen Grund, sie nicht zu aktivieren.
Stufe 2: Registrar-Vollsperre
Zusätzlich zum Transfer Lock werden clientDeleteProhibited und clientUpdateProhibited hinzugefügt. Die Domain kann weder transferiert noch gelöscht noch geändert (Nameserver, Kontakte) werden, ohne die Sperren manuell zu deaktivieren.
Kosten: in der Regel kostenlos, aber nicht immer standardmäßig aktiviert.
Stufe 3: Registry Lock
Die Registry selbst sperrt die Domain mit den Status serverTransferProhibited, serverDeleteProhibited und serverUpdateProhibited. Jede Änderung erfordert ein manuelles Verfahren bei der Registry, oft mit Identitätsprüfung.
Kosten: kostenpflichtig (50 bis 300 EUR/Jahr je nach TLD und Registrar). Reserviert für kritische Domains: Marken, E-Commerce-Websites, Infrastruktur.
Sperren mit dem RDAP Lookup prüfen
Um den Status Ihrer Sperren zu prüfen, fragen Sie Ihre Domain über ein RDAP-Tool ab. Die zurückgegebenen EPP-Status zeigen sofort an, welche Sperren aktiv sind:
clientTransferProhibitedsichtbar: Transfer-Sperre aktivclientDeleteProhibitedsichtbar: Lösch-Sperre aktivclientUpdateProhibitedsichtbar: Änderungs-Sperre aktiv- Keiner dieser Status, nur
ok: kein aktiver Schutz
Was tun, wenn keine Sperre aktiv ist?
Wenn Ihre Domain nur den Status ok ohne Schutzcode anzeigt:
- Melden Sie sich bei der Oberfläche Ihres Registrars an
- Suchen Sie die Option Transfersperre, Transfer Lock oder Domain Lock
- Aktivieren Sie sie sofort
- Für kritische Domains aktivieren Sie zusätzlich die Lösch- und Änderungssperre, falls verfügbar
- Prüfen Sie erneut per RDAP, dass der Status
clientTransferProhibitederscheint
Eine Domain ohne Transfer-Sperre kann von einem Dritten transferiert werden, der den Autorisierungscode (Authcode) erhält. Domain-Diebstahl bleibt eine reale Bedrohung, und jüngste Vorfälle bestätigen dies.
Praxisfall: die massive Übernahme bei der Migration von Google Domains zu Squarespace (2024)
Im Juli 2024 verursachte die Übernahme der Google-Domains durch Squarespace einen der bestdokumentierten Domain-Hijacking-Vorfälle des Jahres. Zwischen dem 9. und 12. Juli übernahmen Angreifer die Kontrolle über Domains großer Kryptounternehmen: Celer Network, Compound Finance, Pendle Finance und Unstoppable Domains, unter anderem.
Die Schwachstelle: Squarespace hatte rund 10 Millionen Domainnamen von Google Domains migriert, jedoch ohne E-Mail-Verifizierung bei der Kontoerstellung zu verlangen. Die Angreifer konnten Konten mit den E-Mail-Adressen der migrierten Domains erstellen, bevor die rechtmäßigen Inhaber dies taten. Einmal eingeloggt, änderten sie die DNS-Einträge, um den Datenverkehr auf Phishing-Seiten umzuleiten.
Die Multi-Faktor-Authentifizierung war bei den migrierten Konten nicht standardmäßig aktiviert, und die Plattform bot weder Audit-Protokolle noch E-Mail-Benachrichtigungen für Kontoaktionen.
Dieser Vorfall verdeutlicht, warum EPP-Sperren essenziell sind. Eine Domain mit aktivem clientUpdateProhibited hätte ihre Nameserver nicht ändern lassen können, selbst nach einer Kontokompromittierung. EPP-Schutzmaßnahmen wirken als Sicherheitsnetz, unabhängig von der Sicherheit des Registrar-Kontos.
WHOIS, RDAP und DSGVO: Welche Daten bleiben sichtbar?
Vor der DSGVO (2018)
Vor Mai 2018 gab eine WHOIS-Abfrage sämtliche Inhaberdaten ohne Einschränkung zurück:
- Vollständiger Name und Organisation
- Vollständige Postanschrift
- E-Mail, Telefon, Fax
- Administrative und technische Kontakte
Diese Daten wurden massiv missbraucht: gezielter Spam, Phishing, Identitätsdiebstahl, Belästigung von Inhabern. Die von Registraren verkauften WHOIS-Privacy-Dienste waren die einzige Gegenmaßnahme.
Nach der DSGVO: selektive Schwärzung vs. vollständige Maskierung
Die DSGVO (Datenschutz-Grundverordnung), anwendbar seit Mai 2018, erzwang einen radikalen Wandel. Personenbezogene Daten dürfen nicht mehr ohne Rechtsgrundlage verbreitet werden. Registries und Registrare haben zwei Ansätze gewählt:
Selektive Schwärzung: Personenbezogene Daten (Name, Adresse, E-Mail, Telefon) werden maskiert oder durch generische Angaben ersetzt (REDACTED FOR PRIVACY). Technische Daten (Nameserver, Daten, EPP-Status) bleiben sichtbar.
Vollständige Maskierung: Einige Registries geben ein absolutes Minimum an Informationen zurück. Nur Domainname, Daten und Status werden offengelegt.
In der Praxis liefert eine RDAP-Abfrage im Jahr 2026 typischerweise:
| Daten | Sichtbar? |
|---|---|
| Domainname | Ja |
| Registrar | Ja |
| Daten (Erstellung, Ablauf, Aktualisierung) | Ja |
| EPP-Status | Ja |
| Nameserver | Ja |
| Name des Inhabers | Nein (maskiert) |
| Adresse des Inhabers | Nein (maskiert) |
| E-Mail des Inhabers | Nein (maskiert oder Relay-Adresse) |
| Telefon des Inhabers | Nein (maskiert) |
Differenzierter RDAP-Zugriff (anonym, authentifiziert, privilegiert)
RDAP integriert nativ ein differenziertes Zugriffssystem, das WHOIS nicht bieten konnte:
Anonymer Zugriff: Nur öffentliche Daten (Domainname, Daten, Status, Nameserver). Das ist es, was eine Standard-RDAP-Abfrage zurückgibt.
Authentifizierter Zugriff: Über ein OAuth-2.0-Token kann ein identifizierter Benutzer auf zusätzliche Daten zugreifen. Beispielsweise kann der Inhaber einer Domain seine eigenen vollständigen Informationen einsehen.
Privilegierter Zugriff: Vorbehalten für Strafverfolgungsbehörden, Organisationen zum Schutz des geistigen Eigentums und akkreditierte Cybersicherheitsteams.
SSAD und RDRS: Hin zu einem standardisierten Zugang zu nicht-öffentlichen Daten
Die ICANN entwickelte das SSAD (System for Standardized Access/Disclosure) zur Formalisierung des Zugangs zu nicht-öffentlichen Domain-Daten. Das Projekt, hervorgegangen aus dem EPDP-Phase-2-Prozess, umfasst 18 voneinander abhängige Empfehlungen: Akkreditierung der Anfragenden, Abfragekriterien, Antwortanforderungen, Protokollierung und Service-Level.
In der Praxis wurde das SSAD nie in seiner ursprünglichen Form umgesetzt. Die operative Bewertung vom Januar 2022 offenbarte unverhältnismäßige Kosten und Komplexität. Die ICANN startete daraufhin den RDRS (Registration Data Request Service) als Übergangssystem. Seit dessen Einführung wurden mehr als 13.000 individuelle Anfragendenkonten im RDRS erstellt, die rund 3.600 Anfragen zur Offenlegung nicht-öffentlicher Daten an gTLD-Registrare stellten.
Im Oktober 2025 verlängerte der ICANN-Vorstand den RDRS bis Dezember 2027. In diesem Zeitraum verbessert die ICANN die Benutzeroberfläche und entwickelt ein dediziertes Authentifizierungsprotokoll für Strafverfolgungsbehörden. Der RDRS bleibt ein Übergangssystem: Die ICANN-Community debattiert weiterhin über seine Weiterentwicklung zu einem permanenten Modell, sei es das ursprüngliche SSAD oder ein vereinfachter Nachfolger.
Dieses Modell löst den grundlegenden Konflikt zwischen Transparenz und Datenschutz: Die Daten existieren weiterhin in den Datenbanken der Registries, aber der Zugriff hängt vom Berechtigungsniveau des Anfragenden ab.
Für Cybersicherheitsteams erschwert diese Einschränkung die Ermittlungen zu bösartigen Domains. Die Identifizierung des Inhabers einer Phishing-Domain erfordert nun eine formelle Anfrage beim Registrar mit rechtlicher Begründung. Die Bearbeitungszeit variiert von einigen Stunden bis zu mehreren Wochen, je nach Registrar und Gerichtsbarkeit.
Für Markeninhaber ist der Schutz verstärkt: Ihre Kontaktdaten sind nicht mehr für bösartige Akteure einsehbar. Im Gegenzug stützt sich die Überwachung missbräuchlicher Domainregistrierungen (Typosquatting, Homoglyphe) stärker auf technische Daten (Daten, Nameserver, Registrar) als auf Kontaktdaten.
🎯 Empfohlener Aktionsplan
1. Prüfen Sie Ihre Domains
Fragen Sie jede kritische Domain über ein RDAP-Tool ab. Prüfen Sie die EPP-Status, die Ablaufdaten und die Nameserver. Identifizieren Sie Domains ohne Schutz (nur Status ok). Priorität für Domains, die Traffic, E-Mail oder eine Marke tragen.
2. Transfer-Sperren aktivieren
Für jede Domain ohne clientTransferProhibited aktivieren Sie die Transfersperre in der Oberfläche Ihres Registrars. Für kritische Domains (Marke, Hauptwebsite, E-Mail) fügen Sie clientDeleteProhibited und clientUpdateProhibited hinzu. Der Vorgang dauert weniger als 2 Minuten und die Sperre ist sofort wirksam.
3. DNSSEC konfigurieren
RDAP zeigt den DNSSEC-Status Ihrer Domain an. Wenn die Angabe unsigned oder das Fehlen von DNSSEC-Daten erscheint, aktivieren Sie die Zonensignierung. DNSSEC schützt die Integrität Ihrer DNS-Einträge und ist eine Voraussetzung für DANE (Authentifizierung von TLS-Zertifikaten über DNS). Prüfen Sie mit dem DNSSEC-Checker, dass die Vertrauenskette von der DNS-Wurzel bis zu Ihrer Zone vollständig ist.
4. Ihre WHOIS-Skripte aktualisieren
Wenn Sie Skripte oder Tools verwenden, die WHOIS auf Port 43 abfragen, migrieren Sie diese auf RDAP. RDAP-Bibliotheken gibt es für alle gängigen Sprachen (Python: rdap, Go: openrdap, JavaScript: rdap-client). Das JSON-Format ist einfacher zu parsen als der WHOIS-Freitext. Verwenden Sie den IANA-Bootstrap zur automatischen Ermittlung des RDAP-Servers jeder TLD, anstatt eine statische Serverliste zu pflegen. Überprüfen Sie, dass Ihre Abfragen die richtigen Server ansprechen, indem Sie den DNS Lookup zur Bestätigung der Domainauflösung verwenden.
5. Regelmäßiges Audit planen
EPP-Status, Ablaufdaten und DNS-Konfigurationen ändern sich. Planen Sie eine vierteljährliche Überprüfung Ihrer kritischen Domains. Stellen Sie sicher, dass die Transfer-Sperren weiterhin aktiv sind (einige Registrare deaktivieren sie vorübergehend bei Wartungsarbeiten), dass DNSSEC funktionsfähig ist und dass die Ablaufdaten ausreichend Puffer bieten.
❓ FAQ - Häufig gestellte Fragen
FAQ
Was ist der Unterschied zwischen WHOIS und RDAP?
WHOIS verwendet TCP-Port 43 und liefert nicht standardisierten Klartext ohne Verschlüsselung oder Authentifizierung. RDAP verwendet HTTPS und liefert strukturiertes JSON (RFC 9083) mit nativer TLS-Verschlüsselung und Unterstützung für differenzierte Zugriffe über OAuth 2.0. RDAP ist seit Januar 2025 der offizielle Nachfolger von WHOIS für gTLDs.
Funktioniert WHOIS im Jahr 2026 noch?
Für einige TLDs, ja. Die ICANN verpflichtet gTLD-Registries seit dem 28. Januar 2025 nicht mehr zur Bereitstellung von WHOIS, verbietet es aber auch nicht. 374 gTLDs haben es bereits abgeschaltet. ccTLDs (.fr, .de, .uk) unterliegen nicht den ICANN-Regeln und können WHOIS unbegrenzt betreiben. In der Praxis sollten Sie damit rechnen, dass WHOIS schrittweise verschwindet.
Was bedeutet der EPP-Code clientTransferProhibited?
Dieser Code zeigt an, dass der Registrar eine Transfersperre auf die Domain aktiviert hat. Solange dieser Status aktiv ist, kann kein Transfer zu einem anderen Registrar eingeleitet werden. Es ist der Basisschutz gegen Domain-Diebstahl. Jeder Inhaber sollte ihn auf seinen Domains aktivieren.
Meine Domain zeigt nur den Status ok an. Ist das normal?
Der Status ok bedeutet, dass keine Einschränkung aktiv ist. Die Domain kann ohne Hindernis transferiert, geändert oder gelöscht werden. Wenn es sich um eine wichtige Domain handelt, aktivieren Sie umgehend die Transfersperre (clientTransferProhibited) über Ihren Registrar, um sie zu schützen.
Kann man die Daten des Domaininhabers noch einsehen?
Bei anonymem Zugriff nein. Seit der DSGVO (2018) werden personenbezogene Daten des Inhabers (Name, Adresse, E-Mail, Telefon) in WHOIS- und RDAP-Antworten maskiert. Nur technische Daten bleiben sichtbar: Domainname, Registrar, Daten, EPP-Status, Nameserver. Ein authentifizierter oder privilegierter Zugriff kann je nach Berechtigungsniveau weitere Daten offenlegen.
Was ist der Registry Lock und was kostet er?
Der Registry Lock ist eine Sperre auf Ebene der Registry (Verisign, AFNIC usw.) mit den Status serverTransferProhibited, serverDeleteProhibited und serverUpdateProhibited. Jede Änderung erfordert ein manuelles Verfahren mit Identitätsprüfung. Die Kosten variieren von 50 bis 300 EUR/Jahr je nach TLD und Registrar. Er wird für Markendomains und Websites mit hohem Stellenwert empfohlen.
Wie migriere ich meine WHOIS-Skripte auf RDAP?
Ersetzen Sie die TCP-Port-43-Abfragen durch HTTPS-Anfragen an die RDAP-Server. Verwenden Sie den IANA-Bootstrap (RFC 9224) zur automatischen Erkennung des RDAP-Servers jeder TLD. Die JSON-Antworten sind einfacher zu parsen als der WHOIS-Freitext. RDAP-Bibliotheken gibt es für Python, Go, JavaScript, Ruby und die meisten gängigen Sprachen.
Zeigt RDAP die DNSSEC-Informationen einer Domain an?
Ja. Die RDAP-Antwort enthält die Daten zur sicheren Delegation (Secure DNS), wenn DNSSEC auf der Domain aktiv ist: Algorithmus, Digest-Typ und DS-Fingerprint. Wenn die Domain kein DNSSEC hat, fehlt dieser Abschnitt oder er zeigt an, dass die Zone nicht signiert ist.
Vergleichstabellen herunterladen
Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.
📖 Glossar
- WHOIS: Protokoll zur Abfrage von Domain-Registrierungsdaten (RFC 3912), das TCP-Port 43 verwendet. Wird derzeit durch RDAP ersetzt.
- RDAP: Registration Data Access Protocol (RFC 9082/9083). Nachfolger von WHOIS, basierend auf HTTPS und JSON, mit nativer Verschlüsselung und differenzierter Zugriffssteuerung.
- EPP: Extensible Provisioning Protocol (RFC 5730). Protokoll zwischen Registraren und Registries zur Verwaltung von Domains. Die EPP-Statuscodes zeigen den Zustand einer Domain an.
- IANA-Bootstrap: Zentralisierte JSON-Datei (RFC 9224), die jede TLD der URL ihres RDAP-Servers zuordnet. Ermöglicht die automatische Erkennung des richtigen Servers.
- Registry: Organisation, die eine TLD verwaltet. Verisign für .com, AFNIC für .fr. Speichert die Zonendaten und Domain-Registrierungen.
- Registrar: Akkreditierter Wiederverkäufer, der Domainnamen im Auftrag der Inhaber verkauft und verwaltet. OVHcloud, Gandi, GoDaddy sind Registrare.
- Transfer Lock: Sperre, die den Transfer einer Domain zu einem anderen Registrar verhindert. Entspricht dem EPP-Status
clientTransferProhibited. - Registry Lock: Sperre auf Ebene der Registry mit manueller Verifizierung. Status
serverTransferProhibited,serverDeleteProhibited,serverUpdateProhibited. - Thin Registry: Registry, die nur Minimaldaten speichert (Name, NS, Daten, Status). Die vollständigen Daten liegen beim Registrar. Beispiel: .com.
- Thick Registry: Registry, die alle Daten zentralisiert, einschließlich der Inhaberkontakte. Beispiel: .fr.
- Redemption Period: 30-tägige Karenzfrist nach der Löschung einer Domain, in der der Inhaber sie gegen Gebühr wiederherstellen kann.
- DSGVO: Datenschutz-Grundverordnung. Europäische Verordnung zum Schutz personenbezogener Daten, die die Maskierung von Kontaktdaten in WHOIS und RDAP ausgelöst hat.
📚 Verwandte RDAP- und Domain-Management-Leitfäden
- RDAP vs WHOIS: Komplettanleitung zur Umstellung 2025 (dieser Artikel)
- Lebenszyklus eines Domainnamens: Ablauf, Schutz und Best Practices: die 7 Phasen, Risiken und konkrete Schutzmaßnahmen.
