RDAP, the Registration Data Access Protocol, is the IETF-standard successor to WHOIS. You send an HTTPS GET such as /domain/example.com to the registry's RDAP server and get back JSON with the domain's status codes, registration and expiry dates, nameservers and registrar. The same protocol covers IP address blocks and AS numbers at the regional internet registries.

Not everywhere. For generic TLDs like .com and .org, ICANN made RDAP mandatory in 2019 and dropped the requirement to run WHOIS in January 2025, so RDAP is now the authoritative source there, although many WHOIS servers still answer. Country-code TLDs set their own rules, and some still offer only WHOIS.

Why does RDAP show REDACTED or no owner name?

Since GDPR took effect in 2018, registries and registrars withhold personal contact data in public lookups, and RDAP returns the same reduced record WHOIS does. Access to the full record goes through the registrar or a formal request process, not through a better lookup tool.

Why does an RDAP lookup fail for .de, .jp or .kr?

Those registries don't run an RDAP service listed in IANA's bootstrap (at the time of writing), so there is no server to ask. Their WHOIS services still work. DechoNet looks up .kr domains through KISA's WHOIS service instead.

RDAP vs WHOIS: What RDAP Is and Why It Replaced WHOIS

What RDAP is

RDAP, the Registration Data Access Protocol, is how you ask a registry “who holds this name, and in what state is it?” in a form a program can read. It’s an IETF standard (originally RFCs 7480–7484 from 2015, since updated) designed to replace WHOIS.

The whole idea fits in one request:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq .

That’s an ordinary HTTPS GET, and the answer is JSON with named fields: status, events (registration, expiration, last changed), nameservers, and entities (registrar, contacts). The same protocol, with paths like /ip/192.0.2.1 and /autnum/64496, answers for IP address blocks and AS numbers at the regional internet registries.

WHOIS does a similar job in a much older way: open TCP port 43, send a name, read back free text whose format the server chose.

What a real RDAP answer looks like

Pull out the parts you usually want:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq '{status, events: [.events[] | {(.eventAction): .eventDate}], ns: [.nameservers[].ldhName]}'

The result has this shape (values illustrative):

{
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited"
  ],
  "events": [
    { "registration": "2009-03-14T10:22:05Z" },
    { "expiration": "2027-03-14T10:22:05Z" },
    { "last changed": "2026-02-20T08:01:44Z" },
    { "last update of RDAP database": "2026-10-07T03:15:12Z" }
  ],
  "ns": [ "NS1.DNSHOST.EXAMPLE", "NS2.DNSHOST.EXAMPLE" ]
}

The same data from WHOIS:

$ whois example.com
   Domain Name: EXAMPLE.COM
   Registrar: Example Registrar, Inc.
   Updated Date: 2026-02-20T08:01:44Z
   Creation Date: 2009-03-14T10:22:05Z
   Registry Expiry Date: 2027-03-14T10:22:05Z
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Name Server: NS1.DNSHOST.EXAMPLE

Note the status names. WHOIS prints the EPP code (clientTransferProhibited); RDAP uses a standard lowercase, space-separated form (client transfer prohibited). They mean the same thing. What each status means for the owner is covered in clientHold, pendingDelete and domain expiry.

The RDAP lookup runs this query for you and lays out status, dates, registrar and nameservers without the jq.

How a client finds the right server

WHOIS never solved this cleanly. There’s no standard way to know which WHOIS server holds a TLD, so clients ship hard-coded lists and follow referrals embedded in the text (“Registrar WHOIS Server: …”), and break when either changes.

RDAP fixed it with a bootstrap registry run by IANA: a JSON file mapping each TLD to its RDAP base URL. There are equivalent files for IPv4, IPv6 and AS numbers.

curl -s https://data.iana.org/rdap/dns.json \
  | jq -r '.services[] | select(.[0] | index("dev")) | .[1][]'
https://pubapi.registry.google/rdap/

A client reads the file, finds the base URL for the TLD, and appends domain/<name>. If a TLD isn’t in the file, the registry doesn’t offer RDAP, and that’s the end of the RDAP road for that name. Public redirectors such as rdap.org do the bootstrap lookup and answer with an HTTP redirect to the right server, which is convenient for one-off queries.

The practical differences

	WHOIS	RDAP
Transport	Plain text over TCP port 43	HTTPS
Output	Free text, format differs per server	JSON with standard field names
Finding the server	Hard-coded lists, referrals in the text	IANA bootstrap files
Errors	Free text (“No match for…”), varies	HTTP status codes: 404 not found, 429 rate limited
Status values	EPP codes, sometimes with ICANN links	Standard RDAP status strings
Non-ASCII names	Inconsistent	UTF-8, with both `ldhName` and `unicodeName`
Access control	None	Can authenticate and return more to authorised users
Links between registry and registrar	Text referral	`links` objects pointing at related RDAP records

For a human reading one record, the difference is cosmetic. For anything automated, such as expiry monitoring, a domain inventory, or abuse triage, it’s the difference between a parser per registry and one parser for all of them.

One case where the difference matters to humans too: in a thin registry such as .com, the registry holds only the core record. The registrar holds the rest. The registry’s RDAP answer usually includes a link to the registrar’s RDAP server, which may carry the registrar’s abuse contact and more detail.

Why WHOIS is being retired for gTLDs

For generic TLDs (.com, .net, .org, .shop and the rest), the rules come from ICANN’s contracts with registries and registrars. ICANN required them to run RDAP from 2019 and, from January 2025, no longer requires them to run WHOIS. RDAP is now the authoritative source for gTLD registration data.

In practice many WHOIS servers are still up, and whois on the command line still works for most .com names. But it’s on borrowed time, nobody is obliged to keep its output stable, and new tooling should be built on RDAP.

Country-code TLDs (.de, .uk, .kr, .jp, …) aren’t bound by those contracts. Each registry decides for itself.

Where RDAP isn’t available

Some large ccTLD registries don’t publish an RDAP service in the IANA bootstrap. At the time of writing, .de and .jp are examples we see regularly at DechoNet: a lookup through a redirector comes back 404 because there is no server to redirect to. Their WHOIS services still work, so use whois or the registry’s own web lookup for those.

.kr is a special case. The Korean registry, KISA, offers registration data through a WHOIS service, and DechoNet’s RDAP lookup uses that for .kr names. The result looks the same in the tool, but the dates and statuses come from KISA’s WHOIS rather than from RDAP.

If an RDAP lookup fails, it helps to know which of these you’re looking at:

404 from the registry’s own server: the registry has no record of the name. It’s unregistered, or already deleted.
404 from a redirector, or no bootstrap entry: the TLD has no RDAP service. Try WHOIS.
403 or 429: blocked or rate limited. Some registries refuse requests without a User-Agent or from certain cloud ranges. Retry later or from another network.

Privacy: why the owner is “REDACTED”

Since the EU’s GDPR took effect in 2018, registries and registrars withhold personal data of registrants from public lookups. That applies equally to WHOIS and RDAP, so switching protocols won’t show you more. You’ll typically see the registrar, the dates, the statuses and the nameservers, while the registrant’s name, address, phone and email are redacted or replaced by a privacy service’s details or a contact form. Organisations sometimes still appear.

RDAP was designed with tiered access in mind: a server can authenticate a requester and return more fields. That’s possible in the protocol. Whether you get anything more depends on the registry’s or registrar’s policy and on having a legitimate reason. If you need the real registrant, say for a trademark dispute or an abuse case, the route is a request to the registrar, through its abuse or disclosure process. Ask the registrar which process applies.

IP addresses and AS numbers: ARIN, RIPE and the rest

All five regional internet registries (AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC) run RDAP for IP blocks and AS numbers. For an address in ARIN’s region:

curl -s https://rdap.arin.net/registry/ip/8.8.8.8 | jq '{handle, name, startAddress, endAddress}'

The WHOIS equivalent is whois -h whois.arin.net 8.8.8.8, and it still works. The advantage of RDAP is the same as for domains: one JSON shape across all five registries, and the bootstrap files tell you which registry holds a block. For a quick look at who announces an address and from which network, the ASN lookup and reverse DNS are usually more useful than the registration record itself.

Reading RDAP data without getting misled

A few things trip people up:

The registry’s expiry date can run ahead of reality. At many gTLD registries a domain is automatically renewed at the registry level the moment it expires, and the expiration event moves a year forward, even if the owner never paid the registrar. The registrar may still delete it during the grace period. If a domain looks renewed but the site has gone dark, check the status values and the nameservers, not just the date.
RDAP nameservers aren’t proof of what DNS serves. RDAP shows the delegation the registry has on file. Compare it with what the TLD’s servers and the domain’s own servers return using a DNS lookup; a mismatch is covered in nameserver mismatch.
“last update of RDAP database” is when the registry refreshed its RDAP data, not when the domain changed. The domain’s own change is the last changed event.
Status values describe locks and states, not health. client transfer prohibited is a normal, healthy lock. client hold and pending delete mean the domain is out of service or about to be.

Which to use

For scripts, monitoring and anything you’ll run more than once: RDAP. It’s structured, it tells you where to ask, and for gTLDs it’s the authoritative source.

For a TLD without RDAP: WHOIS, or the registry’s own lookup page, and accept that you’ll be parsing text.

For a quick look by hand at any domain: the RDAP lookup picks the right source per TLD (RDAP where it exists, KISA WHOIS for .kr) and shows status codes alongside the dates, which is where most real problems show up first.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.