Wie Domain-Verfügbarkeitsprüfungen funktionieren: Cache, WHOIS und RDAP

Warum liefern zwei Domain-Checker unterschiedliche Ergebnisse? Cache, WHOIS und RDAP erklärt. Was 'verfügbar' wirklich bedeutet, bevor Sie eine Domain registrieren.

Sie suchen eine Domain in zwei verschiedenen Tools. Das eine sagt "verfügbar". Das andere sagt "vergeben". Beide haben Recht (sie fragen unterschiedliche Datenquellen mit unterschiedlichen Aktualisierungsfrequenzen ab. Das passiert öfter als die meisten denken, und das Verständnis dahinter hilft, das richtige Werkzeug für die jeweilige Situation zu wählen. Dieser Artikel erklärt die drei Hauptmechanismen für Domain-Verfügbarkeitsprüfungen, warum Ergebnisse abweichen, und was "verfügbar" wirklich garantiert) weniger als Sie vielleicht erwarten.

Die drei Mechanismen der Verfügbarkeitsprüfung

Mechanismus 1: der proprietäre Cache des Registrars

Große Registrare wie IONOS oder Namecheap pflegen eigene Datenbanken registrierter Domains, die periodisch mit dem offiziellen Registry synchronisiert werden. Wenn Sie auf deren Website suchen, befragen Sie deren Cache, nicht das Registry direkt.

Der Vorteil ist Geschwindigkeit: ihr Cache ist lokal, Antworten kommen nahezu sofort. Der Nachteil ist Aktualität. Eine Domain, die vor zehn Minuten registriert wurde, kann im Cache eines Registrars noch als "verfügbar" erscheinen, wenn deren Sync noch nicht gelaufen ist. Umgekehrt kann eine vor zwei Stunden abgelaufene Domain noch als "vergeben" erscheinen.

Registrar-Caches haben auch einen Geschäftszweck: Sie zeigen Domains oft als "verfügbar zu diesem Preis" an, wenn sie tatsächlich Premium- oder reservierte Domains sind, das ist nicht dasselbe wie zum Standardtarif frei registrierbar.

Mechanismus 2: WHOIS

WHOIS (RFC 3912) fragt den WHOIS-Server des Registrys oder Registrars direkt ab, ohne lokalen Cache. Die Daten sind frischer als ein proprietärer Cache, aber das Protokoll hat erhebliche Probleme.

Das praktischste: WHOIS hat kein standardisiertes Antwortformat. Verisigns WHOIS-Ausgabe für .com sieht völlig anders aus als AFNICs Ausgabe für .fr, die wieder anders ist als DENICs Ausgabe für .de. Jeder Parser, der WHOIS-Antworten verarbeitet, muss Dutzende verschiedener Formate handhaben, und scheitert regelmäßig bei Randfällen.

Registries begrenzen auch WHOIS-Anfragen. Bei Massenabfragen stoßen Sie schnell an Limits.

Mechanismus 3: RDAP

RDAP (Registration Data Access Protocol, RFC 7480/7483) ist der moderne Nachfolger von WHOIS. Es ist eine REST-API, die JSON-Antworten mit standardisierter Struktur zurückgibt, das löst das Parsing-Problem vollständig.

Das Verfügbarkeitssignal ist einfach: Existiert eine Domain im Registry, gibt RDAP HTTP 200 mit den Domain-Daten zurück. Existiert die Domain nicht (bedeutet sie ist frei zu registrieren) gibt RDAP HTTP 404 zurück. Kein Parsing nötig. Keine Mehrdeutigkeit.

RDAP-Daten kommen direkt vom autoritativen Registry. Für .com ist das Verisign, für .de ist das DENIC. Keine Zwischenschicht zwischen der Anfrage und der Wahrheitsquelle.

Die Einschränkung: RDAP ist nicht universell. Die meisten gTLDs (.com, .net, .org, .io, .app, und die meisten neuen gTLDs) unterstützen es. Aber ein großer Teil der ccTLDs (besonders in Asien, Afrika und Osteuropa) bietet noch nur WHOIS.

Warum verschiedene Tools verschiedene Ergebnisse liefern

Die Ergebnisdivergenz hat vier Quellen:

Verschiedene Datenquellen: Ein Tool, das RDAP abfragt, und ein Tool, das einen Registrar-Cache abfragt, sehen in Echtzeit verschiedene Dinge. Keines ist falsch, sie lesen verschiedene Datenbanken.
Propagationsverzögerung: Nach der Registrierung einer Domain braucht das Registry einige Minuten zur Datenaktualisierung. In diesem Fenster können manche Checker noch "verfügbar" zeigen.
Interpretationsunterschiede: Manche Tools definieren "verfügbar" unterschiedlich. Eine Domain in redemptionPeriod ist technisch registriert, kann aber weder übertragen noch genutzt werden, manche Checker sagen "vergeben", andere "läuft ab".
Premium- und reservierte Domains: Viele Checker unterscheiden nicht zwischen einer frei verfügbaren Domain, einer Premium-Domain (verfügbar zu höherem Preis), und einer reservierten Domain (überhaupt nicht zur Standardregistrierung verfügbar).

Was "verfügbar" wirklich bedeutet

Ein Checker, der "verfügbar" zeigt, garantiert nicht, dass die Domain beim Klick auf "kaufen" registrierbar sein wird.

Zwischen der Prüfung und dem Registrierungsversuch:

Jemand anderes könnte sie in den Sekunden zwischen Suche und Kauf registrieren.
Die Domain könnte in einer Grace Period sein, die ein bestimmter Checker nicht anzeigt.
Es könnte eine Premium-Domain zu deutlich höherem Preis sein.
Das Registry könnte sie auf einer Reservierungsliste platziert haben.

Für wirklich verfügbare Domains (HTTP 404 von RDAP ohne besonderen Status) ist das Fenster üblicherweise kurz. Sekunden bis wenige Minuten. Bei Domains in Übergangsphase (Redemption, Pending Delete) kann die Lücke zwischen "erscheint als verfügbar" und "jetzt registrierbar" erheblich sein.

Wie Domain Sentinel Verfügbarkeitsprüfungen durchführt

Domain Sentinel fragt zuerst RDAP für alle TLDs ab, die es unterstützen. Die Anfrage geht direkt an das Registry, kein Zwischencache. Für ccTLDs ohne RDAP fällt es auf WHOIS zurück.

Für die Lookup-Schnittstelle bedeutet das: Das angezeigte Ergebnis ist so frisch wie möglich, angesichts der Aktualisierungslatenz des Registrys selbst (typischerweise Sekunden bis wenige Minuten nach einem Registrierungs- oder Löschungsereignis).

Beim Watchlist-Monitoring pollt Domain Sentinel jede Domain in regelmäßigen Abständen und verfolgt Statusübergänge. Wenn eine Domain von pendingDelete zu 404 wechselt (gelöscht und verfügbar), wird ein Alert ausgelöst.

Grenzen des RDAP-Ansatzes

Manche Registries drosseln RDAP-Anfragen, was Prüfungen für sehr große Portfolios verlangsamen kann. ccTLDs ohne RDAP haben via WHOIS etwas längere Antwortzeiten, und WHOIS-Parsing liefert für ungewöhnliche Registrar-Formate gelegentlich falsche Ablaufdaten.

Eigenen Checker aufbauen: die öffentlichen APIs

Für Entwickler, die Verfügbarkeit direkt abfragen möchten:

# Universeller Proxy via rdap.org (leitet automatisch zum richtigen Registry)
curl -s https://rdap.org/domain/example.com
# HTTP 200 = Domain existiert (registriert)
# HTTP 404 = Domain existiert nicht (verfügbar)

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

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

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

Die IANA-Bootstrap-Datei unter https://data.iana.org/rdap/dns.json ordnet jeden TLD seinem RDAP-Endpunkt zu. Das ist die maßgebliche Liste, welche TLDs RDAP unterstützen und wo ihre Server stehen.

Kein Checker garantiert, dass eine Domain in 30 Sekunden verfügbar ist. Der praktische Ansatz: RDAP direkt abfragen (oder ein Tool verwenden, das das tut), schnell handeln, wenn Sie etwas Gewünschtes finden, und alles, was Sie nicht sofort registrieren können, zur Watchlist hinzufügen.