RDAP: the protocol that replaced WHOIS and how to use it

For decades WHOIS was the way to find out who owns a domain, when it was registered and when it expires. It was designed for the early internet, and its limits are now obvious. Its replacement is RDAP, the Registration Data Access Protocol, which is now the authoritative source for international gTLDs. Here is what RDAP is, how it differs from WHOIS and how to use it in practice.

Why WHOIS aged badly

Classic WHOIS runs on port 43: the client sends a name and the server returns free-form text. There is no single format, so every registry names fields differently and writes dates its own way, and reliable parsing needs a separate parser per zone. It is also unencrypted, cannot authenticate users or tier access, and handles non-Latin scripts poorly, which became a real problem once privacy rules required control over which fields are shown to whom.

How RDAP works

RDAP was standardised by the IETF in a series of RFCs and uses ordinary web technology: queries are HTTPS URLs and responses are JSON with a fixed structure. Status, nameservers and registration and expiry dates always sit in the same fields, easy to read from any language.

# old way: plain-text WHOIS (port 43)
whois example.com

# new way: RDAP (HTTPS + JSON)
curl -sL https://rdap.org/domain/example.com | jq .

RDAP also has a bootstrap mechanism: IANA publishes a list mapping each zone to its RDAP server, so clients can work out where to send a query. Services such as rdap.org use that list to redirect you, and you can read it yourself.

# find the RDAP server for .com in the IANA list
curl -s https://data.iana.org/rdap/dns.json \
  | jq -r '.services[] | select(.[0] | index("com")) | .[1][0]'

# is a zone listed (empty output = no RDAP published)
curl -s https://data.iana.org/rdap/dns.json \
  | jq -r '.services[] | select(.[0] | index("uz")) | .[1][0]'

WHOIS vs RDAP

Pulling useful data from the JSON

A full RDAP response is long, but jq makes it easy to keep only what you need, such as status, nameservers and event dates:

# status, nameservers and key dates
curl -sL https://rdap.org/domain/example.com \
  | jq '{status, ns: [.nameservers[].ldhName], events: [.events[] | {eventAction, eventDate}]}'

For example, a small Tashkent web studio that maintains dozens of client sites used to check expiry dates by hand every month, because WHOIS output came in different formats. With RDAP one short script returns every international domain's expiry date in the same shape, and the studio reminds clients well before renewal.

#!/bin/sh
# print expiry dates of client domains
for d in example.com example.net; do
  exp=$(curl -sL "https://rdap.org/domain/$d" \
    | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate')
  echo "$d  $exp"
done

Personal data and redacted fields

RDAP responses often omit the registrant's name, address and phone. That is deliberate: under privacy rules many registries and providers remove or redact those fields in public output. The protocol can serve different amounts of data to different users, but full access normally requires a legitimate legal basis and a separate process. For owners this means less spam and fraud. In the sayt.uz cabinet you can view your domain details and manage WHOIS privacy, and for proof of ownership rely on the official cabinet data rather than a public RDAP answer.

Country-code zones and .uz

The RDAP mandate applies mainly to gTLDs under ICANN contracts, where RDAP became the authoritative source from early 2025. Country-code zones set their own policy, so some already run RDAP while others still offer only WHOIS. The .uz zone does have an RDAP server listed by IANA, so the second command above returns a server address for .uz, and .uz domains can be queried the same way as international ones.

curl -sL https://rdap.org/domain/example.uz | jq '{status, events}'

# show the HTTP status code (404 = domain not found)
curl -sL -o /dev/null -w "%{http_code}\n" https://rdap.org/domain/example.uz

For an unregistered name the server normally answers with HTTP 404, which makes this a quick availability check, though the final check before buying should still be your provider's search page. For other country-code zones check the IANA list first; if a zone is absent, use its WHOIS service or your domain provider's cabinet.