WHOIS vs RDAP: What Changed and How to Query Domain Registration Data
RDAP is the structured, HTTPS-based successor to WHOIS, and ICANN no longer requires gTLD registries and registrars to run WHOIS at all. Here is how the two differ, what data you can still get, and how to query RDAP from a script.
The short comparison
| WHOIS | RDAP | |
|---|---|---|
| Transport | Plain-text TCP, port 43 (RFC 3912) | HTTPS, REST-style URLs |
| Response format | Free text; each registry formats differently | JSON with a defined schema (RFC 9083, previously 7483) |
| Finding the right server | Guess from the TLD or follow referrals by hand | Machine-readable bootstrap files published by IANA |
| Access control | None in the protocol | Authentication and differentiated access are possible |
| Internationalization | Not defined | UTF-8 and IDN handling built in |
| Errors and limits | Ad hoc text messages | HTTP status codes, such as 404 and 429 |
| Standardization | RFC 3912 describes the wire only | RFCs 7480-7484, with 7482, 7483 and 7484 now obsoleted by 9082, 9083 and 9224 |
Practically: WHOIS output is for people to read and scripts to scrape fragilely; RDAP output is for programs to parse.
Timeline and the ICANN requirement
WHOIS dates from the 1980s and was never given a structured data model, which is why parsers needed per-registry rules. The IETF's WEIRDS working group produced RDAP in the 2010s as a replacement. RFCs 7480 to 7484, published in 2015, define HTTP usage, security, query formats, the JSON responses and the bootstrap method for locating the authoritative server. RFCs 9082 and 9083 later replaced the query and response documents, and RFC 9224 replaced the bootstrap specification.
ICANN's gTLD agreements now require registries and registrars to provide RDAP under the gTLD RDAP Profile. Per ICANN's RDAP page, they stopped being required to provide WHOIS services on 28 January 2025, with exceptions for a few extensions (it names .com, .name and .post). Many operators still run port 43 for now, but for gTLDs outside those exceptions nothing obliges them to; ICANN's FAQ does not say whether the exception for .com, .name and .post is permanent, so check it before dropping WHOIS support for those extensions. ICANN's page does not say when RDAP first became mandatory, so check the registry agreement text if you need that date. For scripts, the safe course is to move to RDAP now.
The requirement applies to gTLDs. Country-code TLDs follow their own operators' policies: some run RDAP, some keep WHOIS, some only a web form. Check the operator before assuming either.
What you actually get after privacy redaction
Since the GDPR took effect in 2018, most gTLD registrant details have been redacted by default. A modern lookup therefore returns the parts that do not identify individuals:
- the domain name, registry handle and status codes (for example transfer-prohibited flags);
- registration, last-changed and expiry dates;
- nameservers and DNSSEC data;
- the sponsoring registrar and its IANA ID, plus an abuse contact;
- registrant, administrative and technical contact fields marked as redacted, or pointing to a web form or relay address.
Some data is available only to parties with a legitimate interest, through registrar request processes rather than anonymous queries. Do not rely on the owner's name or email appearing in public results. For domain intelligence the most useful public fields are the dates, status, registrar and nameservers.
A real query
RDAP domain queries are plain GET requests: /domain/<name> on the registry's base URL. For a .com name, the Verisign registry's server answers:
curl -s https://rdap.verisign.com/com/v1/domain/example.comThe response, trimmed to the fields discussed (queried 2026-11-12 for the IANA-reserved example name):
{
"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": "2027-08-13T04:00:00Z"},
{"eventAction": "last changed", "eventDate": "..."}
],
"nameservers": [{"ldhName": "ELLIOTT.NS.CLOUDFLARE.COM"}, ...],
"secureDNS": {"delegationSigned": true, "dsData": [...]},
"entities": [{"roles": ["registrar"], ...}]
}Parsing is direct. The registration date is the events item whose eventAction is registration; with jq: jq '.events[] | select(.eventAction=="registration") | .eventDate'. Status values are EPP status strings; two common ones are pendingDelete and redemptionPeriod, which map onto stages in the domain lifecycle. Note that the registry's own record can be shown beside a separate registrar record: for thin registries such as .com, the registry answers with registry data and refers to the registrar for more.
Not found is meaningful. An RDAP 404 for a name in a TLD normally means the name has no registration at that registry, which is a strong hint that it can be registered. For availability checks, see how to check domain availability; treat RDAP as one source, since premium and reserved names behave differently.
Finding the right server: the IANA bootstrap
There is no single RDAP server for all domains. Clients consult the IANA bootstrap registry for domains at https://data.iana.org/rdap/dns.json. The file has a version, a publication timestamp and a list of services, each mapping one or more TLDs to RDAP base URLs. At the time of checking, the entry for com pointed to https://rdap.verisign.com/com/v1/ and the one for xyz to https://rdap.centralnic.com/xyz/. Equivalent files exist for IP addresses and AS numbers.
The client algorithm is short:
- Take the rightmost label of the name (its TLD).
- Look it up in
dns.json, cached locally and refreshed periodically. - Append
domain/<name>to the base URL and issue the GET. - Follow any redirect and honour HTTP errors.
Public redirector services also exist that forward a request to the right server. They are convenient for manual use but add a dependency and may be rate limited themselves; for production use, read the bootstrap file directly.
Rate limits and good behaviour
RDAP is designed for lookups of individual names, not bulk extraction. Servers limit requests per client address, and when you exceed a limit the standard response is HTTP 429, often with a Retry-After header. Limits differ between operators and are rarely documented precisely, so test conservatively.
- Cache results, since registration dates and nameservers change rarely.
- Send a descriptive User-Agent, and honour 429 and
Retry-After. - Do not use RDAP for discovery across millions of names. Use zone files to list names, then RDAP for the small subset you need to confirm.
- Identify the right endpoint by TLD, not by trying them all.
- Expect different servers to return slightly different fields; code defensively and treat unknown fields as optional.
Which one to use, by situation
| Situation | Pick | Reason |
|---|---|---|
| Checking one gTLD domain by hand | A web RDAP viewer or curl | Structured output, no parsing of text blocks |
| Automated pipeline for gTLDs | RDAP | The required service; stable schema |
| A ccTLD whose registry offers only port 43 | WHOIS, with a per-TLD parser | Nothing else exists; verify the operator's policy and limits |
| Legacy tooling you cannot change quickly | WHOIS today, plan RDAP | Operators may remove port 43 without much notice |
| Finding which names are new | Neither first | Start with zone diffs, then confirm with RDAP |
The old way, for comparison
A classic WHOIS query is a text line sent to a server on TCP port 43, for example whois -h whois.example-registry.net example.com with a placeholder server name. The response begins with a legal notice, then label-and-value lines whose names differ between registries ("Creation Date", "created", "Registered on"). Many servers also throttle by address and answer with a text message, not a status code, so scripts often misread a limit as "no data". The weaknesses of this model are the reason a structured replacement was built.
Common pitfalls
- Treating a redacted field as an error. Placeholder text such as "REDACTED FOR PRIVACY" is a valid answer, not a failure.
- Mixing thin and thick data. Registry and registrar responses can differ; record which server each field came from.
- Using the creation date as proof of age for a re-registered name. A name deleted and registered again gets a new registration date, as explained in typosquatting and lookalike domain triage, where age is one clue among several.
- Forgetting IDNs. Query using the A-label (the
xn--form), since the URL path carries ASCII.
Practical tips for migrating scripts
- Replace regexes over WHOIS text with JSON field access, and write tests with saved responses from several registries.
- Normalise dates to UTC; RDAP uses RFC 3339 timestamps.
- Keep a WHOIS fallback for ccTLDs that have no RDAP, and tag the source of each record.
- Use RDAP creation dates for security triage, for example confirming that a suspicious name really is new, as covered in newly registered domains.
- When filing abuse complaints, take the registrar and abuse contact from the RDAP entities rather than a stale copy.
Sources
- ICANN: RDAP FAQs (RDAP required for gTLDs; WHOIS not required from 28 January 2025, except .com, .name and .post)
- RFC 3912: WHOIS Protocol Specification
- RFC 9083: JSON Responses for RDAP
- RFC 9082: Registration Data Access Protocol Query Format
- RFC 9224: Finding the Authoritative RDAP Service
Frequently asked questions
Is WHOIS being shut down?
Not globally. ICANN stopped requiring gTLD registries and registrars to provide WHOIS on 28 January 2025, with some exceptions named on its RDAP page, and RDAP is the required service. Individual operators may keep port 43 running for a while, and ccTLDs set their own policies.
What is the difference between WHOIS and RDAP?
WHOIS is a plain-text protocol on port 43 whose output format varies by operator. RDAP uses HTTPS and returns standardized JSON, finds the right server through an IANA bootstrap file, and can support authentication and tiered access.
Why does RDAP not show the domain owner's name?
Registrant personal data is redacted by default in most gTLDs because of privacy law such as the GDPR. Public RDAP still returns dates, status codes, nameservers and the registrar. Fuller data may be available through the registrar's request process for legitimate purposes.
How do I find which RDAP server to use for a TLD?
Read the IANA bootstrap file at data.iana.org/rdap/dns.json, find the entry listing your TLD, and use the base URL it gives. Cache the file rather than fetching it for each query.
Can I bulk-download RDAP data for a whole TLD?
No, it is not intended for that and servers rate limit requests. Use zone files for lists of names and RDAP only for per-domain details.
Does a 404 from RDAP mean the domain is available?
It usually means no registration record exists at that registry, which suggests the name may be registrable. Premium, reserved or blocked names can also lack a normal registration, so confirm at a registrar.