The Limitations of 1980s Port 43 WHOIS
For over 40 years, internet domain ownership data was retrieved using the legacy WHOIS protocol (RFC 3912), running over raw TCP Port 43. Legacy WHOIS suffered from fatal structural flaws:
- No standardized machine-readable output: Every registrar formatted plain-text responses differently.
- No native internationalization or Unicode support for non-Latin script domain names.
- No granular role-based access control or native encryption (no HTTPS).
Enter RDAP: Standardized RESTful JSON for Domains
The Internet Engineering Task Force (IETF) and ICANN designed the Registration Data Access Protocol (RDAP) (RFC 7480, RFC 9083). RDAP queries registries over standard HTTPS, returning clean, deterministic JSON data payloads.
How TLDRadar Leverages RDAP for Instant Availability
Our availability engine queries authoritative registry RDAP endpoints directly using IANA's bootstrap mapping registry. When you search for a domain:
- HTTP 404: Confirms the name is completely unregistered and available for immediate purchase.
- HTTP 200 with objectClassName "domain": Proves the domain is actively registered.
- HTTP 429: Indicates registry rate limiting, triggering intelligent backoff retry cycles.
Why WHOIS Had to Be Replaced
WHOIS dates from an era when the internet was small enough that a single text-based directory made sense. It ran over port 43, returned free-form text with no defined structure, had no standard for internationalised characters, and provided no authentication mechanism whatsoever — every query returned the same data to everyone.
Each of these became a serious problem. Unstructured output meant every consumer wrote fragile parsers against registry-specific formats. No internationalisation meant non-Latin registrant data was mangled. No access differentiation meant that once GDPR made blanket publication of personal data untenable, the only available response was to redact fields for everybody.
What RDAP Changes
RDAP, specified across RFCs 7480 through 7484, is a straightforward HTTPS API returning structured JSON. The improvements are concrete:
- Machine-readable responses. Consistent JSON objects with defined fields, so a single parser works across every compliant registry.
- Standard HTTP semantics. A registered domain returns 200 with a domain object; an unregistered one returns 404. Status is unambiguous.
- Full Unicode support for internationalised domain names and non-Latin registrant data.
- Differentiated access. Because it is HTTPS, RDAP supports authentication — enabling redacted public responses alongside authorised access for parties with a legitimate legal basis, rather than one output for everyone.
- Bootstrap discovery. IANA publishes a machine-readable registry mapping every TLD to its authoritative RDAP service, so a client can find the correct server for any extension without a hardcoded list.
ICANN required gTLD registries and registrars to operate RDAP services from 2019, and the legacy WHOIS requirement was formally sunset in January 2025, making RDAP the authoritative mechanism for gTLD registration data.
Reading an RDAP Response
Two fields carry most of the meaning. objectClassName identifies what was returned — domain for a registration, error for a problem. The status array carries EPP status codes describing the domain's actual state:
clientTransferProhibited— registrar lock is on. Normal and protective.clientHold— the registrar has removed the domain from the zone; it will not resolve.redemptionPeriod— expired and recoverable only by the original owner, for a fee.pendingDelete— queued for release and unrecoverable.serverTransferProhibited— locked at the registry level rather than by the registrar.
These codes are why RDAP is genuinely better for availability checking than any scraped page: a domain in redemptionPeriod looks unregistered on many lookup sites but cannot actually be registered by you.
How This Site Uses It
TLDRadar queries RDAP directly from your browser rather than through a server. Every RDAP service sends permissive CORS headers, including on the 404 that signals availability, so the check runs from your own connection straight to the authoritative registry.
The rule we apply is deliberately conservative: a domain is reported available only on an explicit registry 404. A rate limit, a declined query, a network failure, or a TLD that publishes no RDAP service all resolve to Unverified, and unverified names are hidden from the available view rather than shown optimistically. Telling you a name is free when it is not wastes your time at checkout, so the system is built to fail toward silence.
Frequently Asked Questions
Is WHOIS completely gone?
Many registries still operate WHOIS endpoints for compatibility, but RDAP is the authoritative and contractually required interface for gTLDs. New tooling should target RDAP exclusively.
Why do some TLDs return no data?
Country-code registries set their own policy and are not bound by ICANN's gTLD requirements. Some publish no RDAP service at all, which is why certain extensions can never be conclusively verified here.
Does RDAP show me the owner's name?
Usually not. Post-GDPR policy redacts personal contact data from public responses. See our WHOIS privacy guide for what remains visible.