WHOIS und RDAP: Was eine Whois-Abfrage heute noch zeigt

Wer zuletzt vor zehn Jahren eine Whois-Abfrage gemacht hat, erinnert sich an eine Textwand mit Name, Anschrift, Telefonnummer und E-Mail-Adresse. Heute ist davon das meiste verschwunden: Der Datensatz ist kürzer, in der Hälfte der Felder steht „REDACTED“, und das Werkzeug, das Sie benutzen, spricht womöglich gar nicht mehr das WHOIS-Protokoll.

Dieser Leitfaden erklärt, was sich geändert hat, was Registrierungsdaten weiterhin verraten und wie Sie die Teile lesen, auf die es ankommt: Statuscodes und Datumsangaben.

Was ein WHOIS-Eintrag weiterhin zeigt

Die öffentlichen Registrierungsdaten einer typischen generischen Top-Level-Domain (.com, .net, .org, .app und so weiter) enthalten zuverlässig:

den Registrar, der die Domain verwaltet, samt IANA-ID
das Datum der Registrierung, der letzten Änderung und des Ablaufs
einen oder mehrere Statuscodes
die Nameserver, an die die Domain delegiert ist
die Angabe, ob die Domain mit DNSSEC signiert ist
den Abuse-Kontakt des Registrars

Damit lassen sich die meisten betrieblichen Fragen beantworten. Läuft diese Domain bald ab? Welches Unternehmen muss ich anrufen, um das zu beheben? Wurden die Nameserver letzte Woche geändert? Ist eine Transfersperre gesetzt?

Was in der Regel fehlt, ist die Identität des Domaininhabers.

Warum die Inhaberdaten geschwärzt sind

Bis Mai 2018 verpflichteten die ICANN-Verträge die Registrare, für jeden Inhaber einer gTLD-Domain die vollständigen Kontaktdaten zu veröffentlichen. Mit dem Wirksamwerden der Datenschutz-Grundverordnung (DSGVO) gab es keine tragfähige Rechtsgrundlage mehr dafür, personenbezogene Daten dieser Art an jeden herauszugeben, der danach fragt. ICANN reagierte mit einer „Temporary Specification“, die es Registries und Registraren erlaubte, personenbezogene Felder aus der öffentlichen Ausgabe herauszuhalten. Die dauerhafte Registration Data Policy, die darauf folgte, hält an diesem Grundsatz fest.

Daraus ergeben sich einige praktische Folgen:

Geschwärzt wird oft weltweit. Viele Registrare wenden die Schwärzung auf alle Kunden an, weil es fehleranfällig ist, Inhaber danach zu sortieren, welches Datenschutzrecht für sie gilt.
Organisationen können weiterhin erscheinen. Eine juristische Person kann sich dafür entscheiden, ihren Organisationsnamen veröffentlichen zu lassen. Manche tun das.
Privacy- und Proxy-Dienste sind eine eigene Ebene. Sie ersetzen die Daten des Inhabers durch die des Dienstes. Es gab sie lange vor 2018, und sie sind nach wie vor verbreitet.
Für berechtigte Anfragen gibt es einen Weg. Registrare müssen eine Möglichkeit anbieten, den Inhaber zu erreichen, ohne dessen Adresse offenzulegen (meist ein Webformular oder eine Weiterleitungsadresse), und sie müssen Auskunftsersuchen etwa von Strafverfolgungsbehörden oder Markeninhabern prüfen.

Kein Abfragewerkzeug kann die Schwärzung umgehen, denn die Daten werden an der Quelle entfernt. Eine Website, die behauptet, den „echten Inhaber“ einer geschwärzten Domain zu zeigen, präsentiert entweder alte, abgegriffene Daten oder rät.

Was am WHOIS-Protokoll nicht stimmt

WHOIS stammt aus den frühen 1980er-Jahren. Ein Client öffnet eine TCP-Verbindung zu Port 43, sendet einen Domainnamen mit Zeilenumbruch und erhält Freitext zurück. Das ist das gesamte Protokoll. Die Folgen:

Kein einheitliches Format. Jede Registry erfindet eigene Feldnamen und ein eigenes Layout. Parser gehen ständig kaputt.
Keine einheitlichen Fehlermeldungen. „Nicht gefunden“, „Abfragelimit erreicht“ und „Server defekt“ sind allesamt nur Text.
Keine Internationalisierung. Eine Zeichenkodierung ist nicht festgelegt.
Weder Verschlüsselung noch Authentifizierung. Alles läuft im Klartext, und es gibt keine Möglichkeit, verschiedenen Nutzern unterschiedliche Zugriffsstufen zu geben.
Keine automatische Ermittlung des Servers. Clients brauchen eine von Hand gepflegte Liste, welcher Server für welche TLD antwortet.

RDAP: der Nachfolger

Das Registration Data Access Protocol (RDAP) wurde 2015 von der IETF standardisiert, um genau diese Probleme zu lösen. Es ist eine HTTPS-API, die JSON zurückgibt:

Festgelegte Struktur. Datumsangaben sind events mit einer Aktion wie registration oder expiration. Kontakte sind entities mit Rollen wie registrar oder abuse. Statuswerte stammen aus einer festen Liste.
Echte Fehlerbehandlung. Eine Domain, die nicht existiert, liefert HTTP 404. Bei überschrittenem Abfragelimit kommt 429.
Bootstrap-Verfahren. IANA veröffentlicht eine maschinenlesbare Datei, die jeder TLD ihre RDAP-Basis-URL zuordnet. Clients wissen also immer, wo sie fragen müssen.
Verweise. Die Antwort der Registry kann auf den RDAP-Server des Registrars verweisen, der möglicherweise mehr Details kennt.
Raum für abgestuften Zugriff. Weil RDAP über HTTPS läuft, kann ein Server den Anfragenden authentifizieren und Berechtigten mehr Felder liefern.

Ausprobieren lässt sich das mit nichts weiter als curl. Eine Antwort sieht, stark gekürzt, so aus:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2015-03-02T10:15:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-03-02T10:15:00Z" }
  ],
  "nameservers": [
    { "ldhName": "ns1.example.net" },
    { "ldhName": "ns2.example.net" }
  ],
  "secureDNS": { "delegationSigned": false }
}

ICANN verpflichtet gTLD-Registries und -Registrare seit August 2019 zum Betrieb von RDAP. Im Januar 2025 endete die vertragliche Pflicht, für gTLDs weiterhin WHOIS auf Port 43 zu betreiben. Damit ist RDAP die maßgebliche Quelle. Man sagt weiterhin „Whois-Abfrage“, und als Name für die Aufgabe ist das auch in Ordnung, aber die Daten kommen zunehmend über RDAP.

Bei den länderspezifischen Endungen (ccTLDs) sieht es anders aus, denn sie legen ihre Regeln selbst fest. Viele betreiben RDAP, manche nur WHOIS oder ein Webformular, und einige veröffentlichen sehr wenig. Bei .de etwa enthält die öffentliche Abfrage der DENIC keine Inhaberdaten.

Statuscodes richtig lesen

Statuscodes stammen aus EPP, dem Protokoll zwischen Registrar und Registry. RDAP schreibt sie mit Leerzeichen („client transfer prohibited“), die WHOIS-Ausgabe in camelCase. Das Präfix verrät, wer den Code gesetzt hat: client steht für den Registrar, server für die Registry. Eine Übersicht finden Sie im Glossar unter EPP-Statuscodes.

Alltägliche Codes

ok / active: keine Einschränkungen, nichts ist gesperrt.
clientTransferProhibited: Transfersperre des Registrars. Bei eigenen Domains normal und erwünscht.
clientUpdateProhibited, clientDeleteProhibited: Sperren des Registrars gegen Änderungen oder Löschung. Häufig bei wertvollen Namen.
serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited: Sperren auf Registry-Ebene. Zu sehen bei Registry-Lock-Produkten und während Streitverfahren.

Codes, bei denen die Domain nicht mehr auflöst

clientHold: Der Registrar hat die Domain aus der Zone genommen. Typische Ursachen: unbezahlte Verlängerung, nicht bestätigte Kontakt-E-Mail-Adresse, Missbrauchsbearbeitung.
serverHold: Die Registry hat dasselbe getan. Meist geht es um eine rechtliche Frage oder einen Richtlinienverstoß.
inactive: Es sind keine Nameserver eingetragen, also gibt es nichts zu veröffentlichen.

Codes des Lebenszyklus

addPeriod: gerade registriert. Der Registrar kann die Domain noch gegen Erstattung löschen, meist innerhalb von fünf Tagen.
autoRenewPeriod: Die Registry hat die Domain zum Ablauf automatisch verlängert. Der Registrar kann das noch rückgängig machen, typischerweise bis zu 45 Tage lang.
transferPeriod, renewPeriod: kurze Karenzfristen nach einem Transfer oder einer ausdrücklichen Verlängerung.
pendingTransfer: Ein Transfer zu einem anderen Registrar läuft.
redemptionPeriod: Die Domain wurde gelöscht. Der bisherige Inhaber kann sie wiederherstellen lassen, meist innerhalb von 30 Tagen und gegen eine beträchtliche Gebühr.
pendingDelete: Eine Wiederherstellung ist nicht mehr möglich. Nach etwa fünf Tagen wird der Name freigegeben.

Die genauen Fristen hängen von TLD und Registrar ab, und ccTLDs haben oft einen völlig anderen Lebenszyklus. Verstehen Sie die Zahlen oben als das übliche gTLD-Muster, nicht als Zusage.

Ablaufdatum: Registry gegen Registrar

An dieser Stelle lassen sich viele täuschen.

Erreicht eine gTLD-Domain ihr Ablaufdatum, wird sie von den meisten Registries nicht gelöscht. Die Registry verlängert sie automatisch um ein Jahr, stellt dem Registrar die Gebühr in Rechnung und versetzt die Domain in autoRenewPeriod. Zahlt der Kunde nie, löscht der Registrar die Domain innerhalb der Karenzfrist und bekommt die Gebühr zurück.

In diesem Zeitfenster kann der öffentliche Datensatz ein Ablaufdatum in einem Jahr ausweisen, obwohl der Inhaber nicht bezahlt hat und statt der Website längst eine Parking-Seite erscheint. Aus Sicht der Registry ist das Datum korrekt. Es ist nur nicht das Datum, das Ihr Verhältnis zu Ihrem Registrar bestimmt.

Manche Datensätze zeigen beide Werte:

Registry Expiry Date: 2027-03-02T10:15:00Z
Registrar Registration Expiration Date: 2026-03-02T10:15:00Z

Weichen sie voneinander ab, entscheidet das Datum des Registrars darüber, ob Ihr Dienst erreichbar bleibt. Drei Faustregeln:

Verlängern Sie wichtige Domains deutlich vor dem Ablaufdatum, nicht erst in der Karenzfrist.
Lesen Sie Datum und Statuscodes zusammen. Ein fernes Ablaufdatum plus autoRenewPeriod heißt „noch nicht bezahlt“, nicht „in Sicherheit“.
Wenn Sie darauf hoffen, einen auslaufenden Namen zu registrieren: Der aktuelle Inhaber kann ihn normalerweise bis zum Ende der redemptionPeriod zurückholen. Die Phasen im Einzelnen beschreibt der Beitrag Domain abgelaufen: Fristen und Redemption Period.

Domain-Alter

Das Registrierungsdatum dient oft als grober Hinweis darauf, wie etabliert eine Domain ist. Einen Vorbehalt sollten Sie im Kopf behalten: Wurde ein Name gelöscht und neu registriert, beginnt das Datum von vorn. Es sagt Ihnen, wann die aktuelle Registrierung begonnen hat, nicht, wann der Name zum ersten Mal genutzt wurde.

Mit OrbitProbe prüfen

Die Whois-Abfrage von OrbitProbe fragt RDAP direkt ab und zeigt Registrar, Datumsangaben, Statuscodes, Nameserver und DNSSEC-Status, dazu den Quellserver und den Zeitpunkt der Abfrage. Geschwärzte Felder werden als geschwärzt angezeigt. Wenn Sie mehrere Domains verwalten, führt das Portfolio im Workspace deren Ablaufdaten in einer Liste und erinnert an die Verlängerung. Wer einen Anbieterwechsel plant, findet die Schritte unter Domain umziehen.