RDAP-Protokoll erklärt: Domain-Daten ohne WHOIS-Parsing abfragen

RDAP (Registration Data Access Protocol) ist der standardisierte Nachfolger von WHOIS, unter ICANN-Aufsicht entwickelt und in den RFC 7480 bis 7484 definiert (veröffentlicht 2015). Während WHOIS ein Klartextprotokoll aus dem Jahr 1982 ohne standardisiertes Ausgabeformat ist, ist RDAP eine REST-API, die JSON zurückgibt. Dieser eine Unterschied eliminiert eine ganze Kategorie von Problemen: fragile Parser, inkonsistente Feldnamen, mehrdeutige Datumsformate und keine programmatische Möglichkeit, "Domain existiert nicht" von "WHOIS-Server ist ausgefallen" zu unterscheiden. Dieser Artikel erklärt, wie RDAP funktioniert, wie man es abfragt, was Antworten enthalten, und wo Grenzen bestehen.

Hintergrund: warum RDAP WHOIS ersetzt hat

WHOIS stammt von 1982 (RFC 812, später RFC 954, dann RFC 3912). Für ein Protokoll, das 40 Jahre überdauert hat, ist das bemerkenswert, aber es wurde für ein viel kleineres Internet mit anderen Vertrauensannahmen entwickelt. Probleme häuften sich an:

• Kein standardisiertes Antwortformat, jedes Registry und jeder Registrar konnte die Ausgabe frei gestalten
• Keine JSON-Unterstützung, also erforderten WHOIS-basierte Anwendungen fragile Text-Parser
• Keine Authentifizierungs- oder Zugangskontrollmechanismen
• Keine Internationalisierung. Domain-Namen mit Nicht-ASCII-Zeichen wurden inkonsistent behandelt
• Rate-Limiting von jedem Server unterschiedlich implementiert (oder gar nicht)

ICANN hat 2019 den Übergang zu RDAP für alle akkreditierten gTLD-Registries vorgeschrieben. Heute unterstützen alle großen gTLD-Registries RDAP: Verisign (.com, .net), PIR (.org), und die Registries für .io, .app, .dev, .xyz, .co, und die überwiegende Mehrheit der seit 2013 eingeführten neuen gTLDs. Viele ccTLDs haben es ebenfalls eingeführt (AFNIC (.fr) und DENIC (.de) gehören zu den wichtigen Adoptoren) aber erhebliche Lücken bleiben, besonders in Asien und Afrika.

RDAP-Protokollarchitektur

Drei Komponenten bilden die RDAP-Infrastruktur:

• Autoritative Registries: Organisationen, die die kanonischen Domain-Daten pflegen. Verisign für .com, PIR für .org, AFNIC für .fr, DENIC für .de.
• IANA RDAP Bootstrap: eine von der IANA gepflegte JSON-Datei (https://data.iana.org/rdap/dns.json), die jeden TLD zur URL seines RDAP-Servers zuordnet.
• rdap.org: ein öffentlicher Proxy-Dienst der IANA, der Abfragen für beliebige Domains akzeptiert und automatisch an den zuständigen Registry-Server weiterleitet.

RDAP unterstützt mehrere Abfragetypen:

Abfragetyp	Pfadformat
Domain	/domain/<name>
IP-Adresse	/ip/<adresse>
Nameserver	/nameserver/<hostname>
Registrar/Registrant-Entität	/entity/<handle>

Die RFCs, die RDAP definieren

• RFC 7480: HTTP-Nutzung in RDAP
• RFC 7481: Sicherheitsdienste für RDAP
• RFC 7482: Abfrageformat
• RFC 7483: JSON-Antwortformat
• RFC 7484: RDAP-Dienste finden (Bootstrap-Mechanismus)

RDAP manuell abfragen

Grundlegende Abfragen mit curl

# Prüfen ob eine Domain existiert (200 = registriert, 404 = verfügbar)
curl -s https://rdap.org/domain/example.com

# Nur Statuscodes abrufen
curl -s https://rdap.org/domain/example.com | jq '.status'

# Ablaufdatum abrufen
curl -s https://rdap.org/domain/example.com | jq '.events[] | select(.eventAction=="expiration") | .eventDate'

# Nameserver abrufen
curl -s https://rdap.org/domain/example.com | jq '[.nameservers[].ldhName]'

Eine 404-Antwort bedeutet, die Domain existiert nicht im Registry, sie ist registrierbar. Eine 200-Antwort gibt den vollständigen Domain-Datensatz zurück.

Registry-Endpunkte direkt abfragen

Direkte Registry-Abfragen sind schneller als der Umweg über rdap.org:

# Verisign für .com (schneller, kein Proxy)
curl -s "https://rdap.verisign.com/com/v1/domain/example.com"

# PIR für .org
curl -s "https://rdap.publicinterestregistry.org/rdap/domain/example.org"

# DENIC für .de
curl -s "https://rdap.denic.de/domain/example.de"

Struktur einer RDAP-Antwort

Hier ein kommentiertes Beispiel auf Basis von example.com:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited"
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "1995-08-14T04:00:00Z"
    },
    {
      "eventAction": "expiration",
      "eventDate": "2026-08-13T04:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2023-08-14T07:01:40Z"
    }
  ],
  "nameservers": [
    { "ldhName": "a.iana-servers.net" },
    { "ldhName": "b.iana-servers.net" }
  ],
  "entities": [
    {
      "roles": ["registrar"],
      "vcardArray": ["vcard", [["fn", {}, "text", "IANA"]]]
    }
  ],
  "links": [
    {
      "rel": "self",
      "href": "https://rdap.verisign.com/com/v1/domain/example.com"
    }
  ]
}

Wichtige Felder:

• status: das Array der EPP-Statuscodes. Standardisierte Strings, kein Parser-Rätselraten. Siehe die Domain-Statuscode-Referenz für die Bedeutung jedes Status.
• events: die Geschichte der Domain. Das expiration-Ereignis gibt das Ablaufdatum. Das registration-Ereignis gibt das Erstellungsdatum. last changed zeigt, wann der Datensatz zuletzt im Registry geändert wurde.
• nameservers: die autoritativen Nameserver als ldhName (Buchstaben, Ziffern, Bindestriche. ASCII-kompatible Kodierung).
• entities: Registrar- und Registranten-Informationen. Die Registranten-Entität ist oft aus DSGVO-Gründen anonymisiert.
• links: die kanonische URL dieses Datensatzes im autoritativen Registry.

Das events-Array: mehr als ein Ablaufdatum

Das events-Array behebt eine der größten Schwächen von WHOIS. WHOIS liefert typischerweise ein oder zwei Datumsangaben. RDAPs events-Array kann enthalten: Registrierung, Ablauf, letzte Änderung, Transfer, letzte RDAP-Datenbankaktualisierung. Dieser historische Kontext ermöglicht Domain Sentinel die Erkennung von Datensatzänderungen, der last changed-Zeitstempel aktualisiert sich, wenn sich ein beliebiges Feld im Registry-Datensatz ändert.

RDAP-Abdeckung: welche TLDs werden unterstützt?

Aktueller Stand der RDAP-Einführung:

• Vollständig unterstützt: alle ICANN-akkreditierten gTLDs, .com, .net, .org, .io, .app, .dev, .xyz, .co, .ai, .me und hunderte neuer gTLDs
• Unterstützt (wichtige ccTLDs): .fr (AFNIC), .de (DENIC), .uk (Nominet), .nl (SIDN), .be (DNS Belgium), .eu (EURid)
• Noch nicht unterstützt: .ru, .cn, .jp, .br, viele afrikanische und asiatische ccTLDs, diese bleiben WHOIS-only

Die IANA-Bootstrap-Datei ist die maßgebliche Referenz. Wenn ein TLD in https://data.iana.org/rdap/dns.json erscheint, unterstützt er RDAP.

WHOIS-Fallback wenn RDAP nicht verfügbar

Domain Sentinel fällt für TLDs ohne RDAP automatisch auf WHOIS zurück. Die Daten sind weniger strukturiert (Feldnamen und Datumsformate variieren je nach Registry) und Parsing liefert gelegentlich falsche Ergebnisse für ungewöhnliche Registrar-Konfigurationen. Das Ablaufdatum ist meist noch extrahierbar, aber Statuscodes erscheinen als roher WHOIS-Text statt als standardisierte EPP-Strings.

RDAP und DSGVO

Seit 2018 hat die DSGVO-Konformität verändert, was RDAP für natürliche Personen mit EU-Wohnsitz als Domain-Registranten exponiert. Was Sie immer erhalten: Registrar-Informationen, Nameserver, EPP-Status, alle Ereignisdaten. Was Sie oft nicht erhalten: Registranten-Name, E-Mail, Telefon, Postanschrift, diese können durch Platzhalter wie "Redacted for Privacy" ersetzt oder einfach weggelassen werden.

Für juristische Personen (Unternehmen) ist die Situation anders. Unternehmensregistranten-Daten sind in der Regel noch in RDAP-Antworten vorhanden, wobei die Praktiken je nach Registrar variieren.

Domain Sentinel für RDAP-Lookups ohne Code

Wer keine curl-Befehle ausführen möchte, nutzt Domain Sentinels Web-Interface: Es fragt RDAP für beliebige Domains ab und zeigt die Ergebnisse lesbar an. Status in Klartext übersetzt, Ablaufdatum mit verbleibenden Tagen hervorgehoben, Ereignisverlauf, Nameserver, Registrar. Ein Klick auf "Add to watchlist" richtet die kontinuierliche Überwachung ein.

RDAP ist die öffentliche Infrastruktur, die zuverlässiges, programmatisches Domain-Monitoring ermöglicht, deshalb fragt Domain Sentinel Registries direkt ab, anstatt auf Drittanbieter-Datenquellen zu setzen.