WHOIS lesen: Was Registrar, Erstvergabe und Ablaufdatum verraten

1. Aufbau einer WHOIS- bzw. RDAP-Antwort

Eine klassische WHOIS-Antwort ist Freitext, üblicherweise in englischer Sprache, mit Zeile-für-Zeile-Aufteilung. RDAP — der moderne Nachfolger — liefert stattdessen ein strukturiertes JSON-Dokument. Beide enthalten dieselben Kerninformationen: wer die Domain registriert hat, wer den Verkauf abgewickelt hat, wann sie erstmals vergeben wurde, wann sie ausläuft, und über welche Nameserver sie aufgelöst wird.

Der wichtigste Unterschied liegt in der Struktur: WHOIS muss visuell oder mit regulären Ausdrücken geparst werden, RDAP liefert eindeutig benannte Felder. Für Browser-Tools wie domain-alter.de ist RDAP der Standard, weil viele Registries CORS-Header setzen und Browser-Requests damit erlauben.

Ein typischer RDAP-Response hat die Felder objectClassName, ldhName, status, events, entities und nameservers. WHOIS antwortet stattdessen mit Zeilen wie "Domain Name: example.com" und "Registrar: MarkMonitor Inc.". Wer regelmäßig mit Domain-Daten arbeitet, sollte beide Formate lesen können.

2. Registrar und Registrant — wer ist wer?

Im Whois bzw. RDAP unterscheidet man zwei zentrale Rollen: den Registrar und den Registrant. Der Registrar ist die akkreditierte Stelle, die die Domain technisch vergibt und die Inhaberdaten an die Registry weiterleitet. Typische DE-Registrare sind IONOS, Strato, INWX, Hetzner und dogado. Der Registrant ist der eigentliche Inhaber der Domain — die natürliche oder juristische Person, der die Domain rechtlich zugeordnet ist.

Im RDAP findet sich der Registrar als Entity mit der Rolle "registrar", oft mit einer IANA-Registrar-ID (z.B. 292 für MarkMonitor Inc.). Der Registrant taucht als Entity mit der Rolle "registrant" auf. Beim WHOIS gibt es Felder wie "Registrar:" und "Registrant Organization:" oder "Registrant Name:".

Wichtig zu wissen: bei DSGVO-konformer Maskierung sind die Registrant-Daten oft nicht öffentlich. Stattdessen steht "REDACTED FOR PRIVACY" oder die Daten des Privacy-Services. Die echten Inhaberdaten kann nur die Registry herausgeben — und das nur auf nachvollziehbaren Antrag (z.B. anwaltliche Aufforderung im Rahmen einer Markenrechtsverletzung).

Manche Registrare bieten zusätzlich eine Whois-Privacy-Service-Funktion an: statt der echten Inhaberdaten erscheinen die Daten eines Treuhand-Services. Das ist eine kostenpflichtige Option, die vor allem Privatpersonen vor Spam und Phishing schützt. Bei kommerziellen Domains ist sie weniger üblich, weil das Impressum dann ohnehin die echten Daten offenlegt.

3. Erstvergabe, Ablauf und letzte Änderung

RDAP nennt diese Felder "events". Pro Event gibt es einen eventAction-String und ein eventDate. Die wichtigsten Actions sind "registration" (Erstvergabe), "expiration" (Ablauf) und "last changed" (letzte Änderung). Klassische WHOIS-Antworten haben dafür Felder wie "Creation Date:", "Registry Expiry Date:" und "Updated Date:".

Das Erstvergabe-Datum ist eine harte Zahl: wann wurde die Domain initial registriert? Eine Domain mit Erstvergabe-Datum 1997 hat 28 Jahre Geschichte und entsprechend hohen SEO-Trust. Eine Domain mit Erstvergabe-Datum vor drei Monaten hat keinen aufgebauten Trust und braucht erst Geduld.

Das Ablaufdatum sagt, wann die Domain unregistriert würde, falls niemand verlängert. Bei den meisten Registraren liegt das Renewal-Window in den letzten 30-45 Tagen vor Ablauf, plus 30 Tage Grace Period nach Ablauf für vergessliche Inhaber. Erst nach der Grace Period landet die Domain in der Redemption-Period (Wiederherstellungsfenster), in der nur der Originalinhaber sie zu erhöhten Kosten zurückholen kann. Erst nach der Redemption-Period ist die Domain wieder frei.

Das letzte-Änderung-Datum ist ein praktischer Hinweis: wenn es gleich dem Erstvergabe-Datum ist, hat die Domain seit Jahren keine technischen Änderungen erfahren. Wenn es aktuell ist, gab es kürzlich einen Transfer, einen Nameserver-Wechsel oder ein DNSSEC-Update.

4. Nameserver-Einträge interpretieren

Jede aktive Domain hat 2-4 Nameserver eingetragen. Diese Server sind autoritativ für die Domain — sie liefern die DNS-Antworten (A-Records, MX-Records, TXT-Records etc.). Im RDAP findet sich der Nameserver-Block als Array nameservers mit ldhName-Feld pro Server. Im WHOIS gibt es "Name Server:" oder "Nserver:" Zeilen.

Aus den Nameservern lässt sich oft der Hosting-Provider erkennen: "ns1.kasserver.com" deutet auf All-Inkl., "dns1.ionos.de" auf IONOS, "ns-cloud-a1.googledomains.com" auf Google Cloud DNS. Bei selbst gehosteten Domains stehen oft die eigenen Nameserver der Brand, z.B. "ns1.akara-solutions.de".

Wichtig: NS-Records sind im DNS auch dann gesetzt, wenn die Domain gar nicht aktiv aufgerufen werden kann (kein A-Record, kein Webserver). Eine geparkte Domain hat fast immer Nameserver — das ist der Grund, warum domain-alter.de bei der Verfügbarkeits-Prüfung NS-Records statt A-Records abfragt. Eine NS-Antwort ist der zuverlässigste Indikator für "Domain ist registriert".

Wechseln Nameserver, dauert die globale DNS-Propagation typisch 24-48 Stunden. Der Grund ist die TTL (Time To Live) der bisherigen NS-Antworten, die in den Resolvern weltweit gecacht ist. Wer einen sauberen NS-Wechsel plant, sollte die TTL vor dem Wechsel auf einen niedrigen Wert (z.B. 300 Sekunden) setzen.

5. Status-Felder verstehen

Sowohl WHOIS als auch RDAP enthalten Status-Codes. Die wichtigsten sind:

• ok / Status: active: normale, aktive Domain ohne Sperren.
• clientTransferProhibited: der Inhaber oder Registrar hat den Transfer auf einen anderen Registrar gesperrt. Bevor ein Transfer möglich ist, muss dieser Status entfernt werden.
• clientDeleteProhibited: die Domain kann nicht gelöscht werden. Schutz gegen versehentliche oder bösgläubige Löschung.
• clientUpdateProhibited: Änderungen an Inhaberdaten oder Nameservern sind gesperrt.
• serverHold: die Registry hält die Domain inaktiv (typisch bei DSGVO-Streitigkeiten oder behördlichen Anordnungen). Die Domain ist registriert, aber nicht aufrufbar.
• pendingDelete: die Domain steht kurz vor der Löschung (typisch in der Redemption-Period).
• pendingTransfer: ein Transfer-Vorgang läuft.

Mehrere Status können gleichzeitig gesetzt sein. Eine seriös konfigurierte Brand-Domain hat typischerweise clientTransferProhibited und clientDeleteProhibited gesetzt — als doppelten Schutz gegen Diebstahl oder versehentliche Löschung.

6. DSGVO-Maskierung und Whois-Privacy

Seit Inkrafttreten der DSGVO 2018 sind viele Whois-Felder bei .eu, .de und anderen europäischen ccTLDs sowie bei gTLDs maskiert. Was öffentlich bleibt: Registrar, Erstvergabe-Datum, Ablaufdatum, Status, Nameserver. Was maskiert oder ganz weggelassen wird: Registrant-Name, Registrant-Adresse, E-Mail des Inhabers, Telefonnummer.

Bei .de sind die Inhaberdaten seit DSGVO komplett maskiert — nur der admin-c bleibt als technischer Kontakt erkennbar. Bei .com und anderen ICANN-gTLDs wird typisch nur der Name maskiert ("REDACTED FOR PRIVACY"), Land und Bundesland können sichtbar bleiben.

Wer als Markeninhaber oder Rechtsabteilung an die echten Inhaberdaten muss, hat zwei Wege: den anonymisierten Kontakt-Kanal des Registrars (E-Mail-Forwarding mit anonymer Adresse) oder einen formalen Antrag bei der Registry mit Berufung auf berechtigtes Interesse. Letzteres ist DSGVO-konform geregelt — eingegangener Antrag plus Markenrechtsnachweis führt typisch zu Datenfreigabe binnen 7-14 Tagen.

Wichtig für Tool-Bauer: die Verfügbarkeit von WHOIS- bzw. RDAP-Daten variiert pro TLD. DENIC liefert RDAP, aber ohne CORS-Header — Browser-Tools können nicht direkt anfragen, brauchen einen Server-Proxy. Verisign (für .com/.net) setzt CORS-Header und ist Browser-direkt nutzbar. Bei kleinen ccTLDs ist RDAP gar nicht verfügbar, dort bleibt nur klassisches WHOIS auf Port 43.

7. Praxis: Eine vollständige RDAP-Antwort durchgegangen

Eine echte RDAP-Antwort für google.com sieht in den Kern-Feldern etwa so aus (gekürzt):

{
  "objectClassName": "domain",
  "handle": "2138514_DOMAIN_COM-VRSN",
  "ldhName": "google.com",
  "status": ["client delete prohibited", "client transfer prohibited", "client update prohibited"],
  "entities": [
    {
      "objectClassName": "entity",
      "handle": "292",
      "roles": ["registrar"],
      "vcardArray": ["vcard", [
        ["version", {}, "text", "4.0"],
        ["fn", {}, "text", "MarkMonitor Inc."]
      ]]
    }
  ],
  "events": [
    { "eventAction": "registration", "eventDate": "1997-09-15T04:00:00Z" },
    { "eventAction": "expiration", "eventDate": "2028-09-14T04:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2024-09-09T15:22:32Z" }
  ],
  "nameservers": [
    { "ldhName": "NS1.GOOGLE.COM" },
    { "ldhName": "NS2.GOOGLE.COM" }
  ]
}

Aus dieser Antwort lassen sich sofort mehrere wichtige Aussagen ableiten: die Domain ist seit September 1997 registriert (28 Jahre Trust-Aufbau), wird über MarkMonitor verwaltet (klassischer Premium-Brand-Registrar), läuft bis September 2028 (Renewal in vier Jahren) und ist gegen Transfer, Delete und Update gesperrt (höchste Sicherheits-Stufe). Die Nameserver bestätigen ein selbst-betriebenes DNS bei Google.

Bei einer typischen Brand-Domain einer kleinen Firma sieht das oft simpler aus: Registrar IONOS oder Strato, Erstvergabe vor 5-10 Jahren, Status "ok", Nameserver beim Hosting-Provider. Was fehlt, ist oft die Transfer-Sperre — ein Indikator für mangelnde Domain-Hardening. Wer sich um die eigene Brand-Domain ernsthaft sorgt, sollte clientTransferProhibited setzen lassen.

8. Häufige Statusprobleme und Diagnose

Drei Statusprobleme treten in der Praxis besonders oft auf:

Problem 1: pendingDelete oder redemptionPeriod. Die Domain läuft demnächst aus oder ist gerade ausgelaufen. Wer als Inhaber dieses Status sieht, hat noch eine Chance — innerhalb der Redemption-Period (typisch 30 Tage nach Ablauf) kann die Domain vom Original-Registrar gegen erhöhte Gebühren (50-150 USD) wiederhergestellt werden. Nach Ablauf der Redemption ist sie wieder frei.

Problem 2: serverHold. Die Registry hat die Domain inaktiv gesetzt. Mögliche Gründe: ungeklärte DSGVO-Streitigkeiten, behördliche Anordnungen, Verstoß gegen Registry-AGB. Die Domain bleibt registriert, ist aber im DNS nicht aufrufbar. Klärung erfordert direkten Kontakt mit der Registry, oft mit anwaltlicher Begleitung.

Problem 3: Nameserver-Wechsel mit DNS-Propagation. Nach einem Wechsel der Nameserver dauert es 24-48 Stunden, bis die globale Propagation abgeschlossen ist. Während dieser Zeit antworten manche Resolver mit der alten, manche mit der neuen Konfiguration. Wer die Domain in dieser Zeit aufruft, kann unterschiedliche Ergebnisse sehen. Lösung: vor dem Wechsel TTL der bestehenden NS-Records auf 300 Sekunden senken, eine Woche warten, dann wechseln. So minimiert man die Übergangszeit auf wenige Minuten.

Quellen

• ICANN RDAP-Spezifikation
• RFC 7480: HTTP Usage in RDAP
• DENIC-Whois-Service
• ICANN Lookup Tool