RDAP löst WHOIS ab: Domain-Daten sicher überwachen

Von WHOIS zu RDAP: Was sich technisch geändert hat

WHOIS entstand in den frühen Tagen des Internets als schlichter Abfragedienst über Port 43: Man schickt einen Domainnamen, zurück kommt ein Block aus Freitext. Das Format war nie streng standardisiert - jede Registry und jeder Registrar formatierte die Antwort etwas anders, mal mit dem Feld „Registry Expiry Date“, mal mit „paid-till“, mal mit „Expiration Date“. Für Menschen war das lesbar, für Maschinen ein ständiges Ratespiel. Genau hier setzt RDAP an.

RDAP liefert dieselben Informationen über eine moderne, klar definierte Schnittstelle: Abfragen laufen als HTTPS-Anfrage nach einem einheitlichen Muster (RFC 9082), die Antwort ist strukturiertes JSON mit fest benannten Feldern (RFC 9083), und welcher Server für welche Endung zuständig ist, steht in einer zentralen Bootstrap-Datei der IANA (RFC 9224). Damit lassen sich Ablaufdatum, Status, Nameserver und Kontaktverweise eindeutig auslesen, ohne Freitext zu zerlegen. RDAP unterstützt zudem Internationalisierung, verschlüsselten Zugriff und - anders als das offene WHOIS - abgestufte Zugriffsrechte auf sensible Daten (ICANN).

# RDAP: HTTPS-Abfrage nach RFC 9082 statt WHOIS über Port 43
curl -s https://<rdap-basis-url>/domain/ihre-domain.example

# Strukturierte Antwort (Auszug, RFC 9083):
# "status": ["clientTransferProhibited"]
# "events": [{ "eventAction": "expiration", "eventDate": "2027-03-14T09:00:00Z" }]
# "nameservers": ["NS1.EXAMPLE.NET", "NS2.EXAMPLE.NET"]
# "secureDNS": { "delegationSigned": true }

Der Stichtag 28. Januar 2025 - und die drei Ausnahmen

Die Abschaltung kam nicht über Nacht: Sie war das Ende einer 18-monatigen Übergangsfrist nach einer Vertragsänderung der ICANN (ICANN). Seit dem 28. Januar 2025 sind gTLD-Registries und Registrare nicht mehr verpflichtet, WHOIS über Port 43 oder das Web anzubieten - RDAP ist an dessen Stelle Pflicht (ICANN). Drei Endungen bilden eine ausdrückliche Ausnahme und dürfen WHOIS weiter betreiben: .com, .name und .post (ICANN). Für die überwältigende Mehrheit der generischen und neuen Endungen gilt jedoch: Wer dort noch WHOIS abfragt, verlässt sich auf einen Dienst, den der Betreiber abschalten darf - und vielfach bereits abgeschaltet hat.

Die Registries haben von diesem Recht schnell Gebrauch gemacht. Bereits im Februar 2025 hatten laut einer ICANN-Erreichbarkeitsprüfung 74 gTLD-Registries ihren WHOIS-Dienst eingestellt (ICANN); bis September 2025 boten nach Daten des TLD RDAP Monitor bereits 374 gTLDs kein WHOIS mehr an (TLD RDAP Monitor). Ein Ablauf-Check, der stur Port 43 anspricht, bekommt bei diesen Endungen entweder eine Fehlermeldung oder - schlimmer - eine veraltete Antwort aus einem Zwischenspeicher. Wer sicherstellen will, dass eine Domain nicht unbemerkt ausläuft, darf sich auf diese Quelle nicht mehr verlassen.

Die Lücke: RDAP-Abdeckung liegt erst bei rund 77 Prozent

So klar die Richtung ist, so unfertig ist der Übergang. Über alle Top-Level-Domains hinweg lag die RDAP-Abdeckung im September 2025 bei rund 77 %, gegenüber 74,8 % im Februar 2025 (TLD RDAP Monitor). Der Durchschnitt verdeckt allerdings eine große Spreizung: Bei den generischen Endungen ist die Umstellung praktisch abgeschlossen, weil die ICANN-Vorgaben dort greifen. Bei den Länderendungen (ccTLDs) dagegen hatten im September 2025 erst 34,2 % RDAP im Angebot - nach 29,4 % im Februar (TLD RDAP Monitor). ccTLDs wie .de, .fr oder .it unterliegen nicht den ICANN-Verträgen und entscheiden selbst über ihren Fahrplan.

Der TLD RDAP Monitor, der die Umstellung über mehr als 1.400 Endungen verfolgt (WhoisXML API), macht das Kernproblem sichtbar: Ein Werkzeug, das eine Domain überwachen will, kann sich nicht darauf verlassen, dass entweder WHOIS oder RDAP überall funktioniert. Es braucht beide Wege - RDAP zuerst, WHOIS nur noch als Rückfallebene für die Endungen, die den Wechsel noch nicht vollzogen haben. Genau diese Doppelstrategie unterscheidet ein zukunftsfestes Monitoring von einem Werkzeug, das an einer einzigen, teils abgeschalteten Quelle hängt.

Warum WHOIS-basierte Ablaufchecks falsche Daten liefern

Ein Domain-Ablauf, den niemand bemerkt, ist einer der teuersten und zugleich vermeidbarsten Zwischenfälle im Webbetrieb. Läuft eine Domain aus, sind Website und E-Mail schlagartig offline - und die Wiederbeschaffung kann teuer und langwierig werden. WHOIS-basierte Checks sind aus mehreren Gründen zunehmend unzuverlässig:

• Abgeschalteter Dienst: Bei Endungen ohne WHOIS gibt der Port-43-Server gar keine Antwort mehr - der Check meldet entweder einen Fehler oder wertet das Fehlen fälschlich als „kein Ablauf in Sicht“.
• Veraltete Zwischenspeicher: Manche WHOIS-Antworten stammen aus Caches, deren Ablaufdatum nach einer Verlängerung nicht sofort aktualisiert wird - das Monitoring sieht ein längst überholtes Datum.
• Uneinheitliche Feldnamen: Ohne Standard heißt das Ablaufdatum mal „Registry Expiry Date“, mal „paid-till“, mal steht es gar nicht in der Antwort - ein Parser, der nur ein Feldformat kennt, übersieht die anderen.
• Rate-Limits und Blockaden: WHOIS-Server drosseln automatisierte Abfragen erfahrungsgemäß aggressiv; einige liefern absichtlich reduzierte oder verschleierte Datensätze.
• Fehlende Statussignale: Kritische Zustände wie „redemptionPeriod“ oder „pendingDelete“ tauchen in knappen WHOIS-Antworten oft gar nicht auf - genau die Signale, die eine akute Warnung auslösen müssten.

RDAP räumt diese Fallstricke aus, weil jedes Feld benannt und typisiert ist. Ein Ablaufdatum kommt als „expiration“-Event, ein Sperr- oder Übertragungsschutz als standardisierter Status-Code. Das Monitoring muss nicht mehr raten, sondern kann Signale eindeutig auswerten - die Grundlage jeder belastbaren Domain-Ablauf-Überwachung.

Welche Domain-Signale wirklich zählen

Zuverlässiges Domain-Monitoring beschränkt sich nicht auf ein einzelnes Ablaufdatum. Vier Signalgruppen bestimmen, ob eine Domain sicher, erreichbar und in der eigenen Hand bleibt:

Der Domain-Lebenszyklus: von Ablauf bis Löschung

Wer versteht, was nach dem Ablaufdatum passiert, versteht auch, warum ein frühes Signal so wertvoll ist. Eine gTLD durchläuft nach dem Ablauf mehrere Phasen, in denen die Rückholung immer teurer und unsicherer wird:

1. Auto-Renew-Grace-Period: Direkt nach dem Ablauf räumen viele Registrare eine Kulanzfrist ein, in der sich die Domain unkompliziert verlängern lässt - die ICANN erlaubt hier bis zu 45 Tage, die genaue Länge legt der Registrar fest (ICANN).
2. Redemption Grace Period: Ist die Domain gelöscht, folgt eine 30-tägige Wiederherstellungsfrist („redemptionPeriod“), in der nur der bisherige Inhaber die Domain gegen eine meist deutliche Wiederherstellungsgebühr zurückholen kann (ICANN).
3. Pending Delete: Danach steht die Domain fünf Tage im Status „pendingDelete“ - jetzt ist keine Wiederherstellung mehr möglich, die Domain wird zur Löschung freigegeben (ICANN).
4. Freigabe: Am Ende fällt die Domain zurück in den Pool und kann von Dritten neu registriert werden - inklusive automatisierter Dienste, die begehrte Namen im Sekundentakt abfangen.

Genau diese Übergänge spiegeln sich in den EPP-Status-Codes wider, die RDAP maschinenlesbar ausgibt (ICANN). Ein Monitoring, das die Codes „redemptionPeriod“ oder „pendingDelete“ erkennt, kann sofort eskalieren - während ein WHOIS-Check, der diese Felder gar nicht führt, den Ernstfall verschläft.

WHOIS-Check gegen RDAP-Monitoring

Der Unterschied zwischen einem gelegentlichen manuellen Blick und einer kontinuierlichen Überwachung wird an der Datenquelle besonders deutlich:

Domain-Monitoring per RDAP einrichten

1. Domains inventarisieren: Tragen Sie alle produktiv genutzten Domains zusammen - inklusive selten genutzter Weiterleitungs- und Marken-Domains, die erfahrungsgemäß am ehesten vergessen werden.
2. Quelle festlegen: Prüfen Sie je Endung, ob RDAP verfügbar ist, und nutzen Sie WHOIS nur dort als Rückfall, wo die Endung noch nicht umgestellt hat.
3. Schwellen definieren: Legen Sie Vorwarnstufen fest - etwa 90, 30 und 7 Tage vor Ablauf - und behandeln Sie einen Statuswechsel wie „redemptionPeriod“ als sofortigen Alarm.
4. Signale bündeln: Überwachen Sie Ablauf, Nameserver, EPP-Status und DNSSEC gemeinsam, damit ein einzelner Blick den Domain-Zustand vollständig zeigt.
5. Alarme zustellen: Lassen Sie Warnungen über mehrere Kanäle laufen und dokumentieren Sie den Verlauf über Reports und Statuspages, damit kein Signal im Postfach untergeht.

Domain-Monitoring steht dabei nicht allein: Ein abgelaufenes oder falsch delegiertes Zertifikat wirft dieselbe Art stiller Ausfälle auf wie ein vergessener Domain-Ablauf. Wie kurzlebige Zertifikate die Überwachung verändern, zeigt der Beitrag zu 6-Tage-Zertifikaten im SSL-Monitoring; wie fremde Infrastruktur zum Ausfallrisiko wird, der Beitrag zu Cloud-Ausfällen und fremden Abhängigkeiten. Gemeinsam ergeben Domain-, SSL- und DNS-Überwachung ein Sicherheitsnetz, das die Grundpfeiler der Erreichbarkeit abdeckt.

Domain-Ablauf zuverlässig überwachen - mit XICTRAQ

Das DNS- und Domain-Monitoring von XICTRAQ liest Registrierungsdaten aus RDAP und greift nur dort auf WHOIS zurück, wo eine Endung noch nicht umgestellt hat. So bleibt das Ablaufdatum verlässlich, auch wenn ein Registry seinen WHOIS-Dienst über Nacht abschaltet. Ändern sich Nameserver oder Status-Codes, meldet das Monitoring die Abweichung, statt sie im Freitext untergehen zu lassen.

Statt einmal im Jahr manuell nachzusehen, überwacht XICTRAQ Ihre Domains kontinuierlich und warnt erfahrungsgemäß mit Tagen bis Wochen Vorlauf - kombiniert mit SSL-, DNS- und Uptime-Überwachung in einem Blick. Starten Sie mit dem kostenlosen Test und tragen Sie Ihre wichtigsten Domains ein, oder buchen Sie eine persönliche Demo, um Ablauf-Frühwarnung und Status-Alarme in Aktion zu sehen.