How domain availability checkers work: cache, WHOIS, and RDAP

You search for a domain on two different tools. One says "available." The other says "taken." Both are right, they're querying different data sources with different update frequencies. This happens more than most people realize, and understanding why helps you choose the right tool for your situation. This article explains the three main mechanisms domain availability checkers use, why their results diverge, and what "available" actually guarantees (less than you might think).

The three mechanisms for checking domain availability

Mechanism 1: the registrar's proprietary cache

Large registrars like GoDaddy and Namecheap maintain their own databases of registered domains, synchronized periodically with the official registry. When you search on their site, you're querying their cache, not the registry directly.

The advantage is speed: their cache is local, so responses are near-instant. The disadvantage is freshness. A domain registered ten minutes ago might still show as "available" in a registrar's cache if their sync hasn't run yet. Conversely, a domain that expired two hours ago might still show as "taken" if their cache hasn't cleared it. These gaps are typically short (minutes to a few hours) but they exist.

Registrar caches also serve a business purpose: they often show domains as "available with this price" when they're actually premium or reserved, which isn't the same as freely registrable at standard pricing.

Mechanism 2: WHOIS

WHOIS (RFC 3912) queries the WHOIS server of the registry or registrar directly, without going through a local cache. The data is fresher than a proprietary cache, but the protocol has significant problems.

The most practical issue: WHOIS has no standardized response format. Verisign's WHOIS output for .com looks completely different from AFNIC's output for .fr, which looks different from DENIC's output for .de. Every parser that processes WHOIS responses has to handle dozens of different formats, and it frequently gets things wrong for edge cases, unusual date formats, non-ASCII characters, domains with non-standard status strings.

Registries also rate-limit WHOIS queries. If you're running bulk checks, you'll hit limits quickly, and the behavior when limits are reached varies by registry.

Mechanism 3: RDAP

RDAP (Registration Data Access Protocol, RFC 7480/7483) is the modern replacement for WHOIS. It's a REST API that returns JSON responses with a standardized structure. That solves the parsing problem completely.

The core availability signal is simple: if a domain exists in the registry, RDAP returns HTTP 200 with the domain's data. If the domain doesn't exist (meaning it's available to register) RDAP returns HTTP 404. No parsing required. No ambiguity.

RDAP data comes directly from the authoritative registry. For .com, that's Verisign. For .fr, that's AFNIC. There's no intermediate layer between the query and the canonical source of truth.

The limitation: RDAP isn't universal. Most gTLDs (.com, .net, .org, .io, .app, .dev, .xyz, and most new gTLDs) support it. But a large share of ccTLDs (especially in regions like Asia, Africa, and Eastern Europe) still only offer WHOIS.

Why different tools give different results

The divergence in results comes from four sources:

• Different data sources: a tool querying RDAP and a tool querying a registrar cache will see different things in real time. Neither is wrong, they're reading different databases.
• Propagation delay: after a domain is registered, the registry needs a few minutes to update its data. During that window, some checkers may still show "available."
• Interpretation differences: some tools define "available" differently. A domain in redemptionPeriod is technically registered but can't be transferred or used, some checkers call it "taken," others call it "expiring."
• Premium and reserved domains: many checkers don't distinguish between a freely available domain, a premium domain (available at a higher price), and a reserved domain (not available for standard registration at all).

What "available" actually means

A domain checker showing "available" does not guarantee the domain will be registerable when you click "buy."

Between the check and the registration attempt:

• Someone else might register it in the seconds between your search and your purchase.
• The domain might be in a grace period that a particular checker doesn't surface.
• It might be a premium domain at a significantly higher price than standard registration.
• The registry might have placed it in a reserved list.

For truly available domains (HTTP 404 from RDAP with no special status), the window is usually short, seconds to a few minutes. But for domains in transition (redemption, pending delete), the gap between "shows as available" and "registerable right now" can be significant.

How Domain Sentinel handles availability checks

Domain Sentinel queries RDAP first for all TLDs that support it. The query goes directly to the registry, no intermediate cache. For ccTLDs without RDAP, it falls back to WHOIS.

For the lookup interface, this means the result you see is as fresh as possible, given the registry's own update latency (typically seconds to a few minutes after a registration or deletion event).

For watchlist monitoring, Domain Sentinel polls each domain at regular intervals and tracks status transitions. When a domain moves from pendingDelete to 404 (deleted and available), an alert fires.

Limits of the RDAP approach

Some registries throttle RDAP queries, which can slow down verification for very large portfolios. ccTLDs without RDAP have slightly longer response times through WHOIS, and WHOIS parsing occasionally produces incorrect expiration dates for unusual registrar formats.

Building your own availability checker: the public APIs

For developers who want to query availability directly:

# Universal proxy via rdap.org (routes to the correct registry automatically)
curl -s https://rdap.org/domain/example.com
# HTTP 200 = domain exists (registered)
# HTTP 404 = domain doesn't exist (available)

# Get just the status codes
curl -s https://rdap.org/domain/example.com | jq '.status'

# Direct Verisign endpoint for .com (faster, no proxy)
curl -s "https://rdap.verisign.com/com/v1/domain/example.com"

# AFNIC for .fr
curl -s "https://rdap.nic.fr/domain/example.fr"

The IANA bootstrap file at https://data.iana.org/rdap/dns.json maps each TLD to its RDAP endpoint. That's the authoritative list of which TLDs have RDAP and where their servers are.

No checker guarantees a domain will be available in 30 seconds. The practical approach: query RDAP directly (or use a tool that does), act quickly when you find something you want, and add to a watchlist anything you can't register immediately.