RDAP vs WHOIS: What Changed?

WHOIS has one job and does it badly: it opens a TCP connection to port 43, sends a string, and returns whatever text the operator felt like formatting. RDAP does the same job over HTTPS and returns JSON with defined member names. If you have ever written a regex to pull an expiry date out of WHOIS output and watched it break on the next registry, RDAP is the fix.

What is actually wrong with WHOIS?

The protocol specification is about two pages long and defines essentially nothing beyond "connect, send a line, read text until close". Everything a consumer needs is left to the operator, which produces a specific set of recurring problems:

• No response format. Field names, ordering, indentation, and capitalisation vary by registry and by registrar. gTLDs converged on a broadly common key-value layout, but ccTLDs did not, and plenty return prose.
• No character encoding. The specification predates any internationalisation requirement, so non-ASCII registrant data is returned in whatever encoding the server chose, with no way to know which.
• No error semantics. "Not found" and "rate limited" and "your query was malformed" all arrive as ordinary text on a successful connection. Your parser cannot tell a real negative from a failure.
• No transport security. Port 43 is plaintext. Queries and answers are trivially observable.
• Manual referrals. For thin registries like .com, the registry response only names the sponsoring registrar; getting fuller data means reading the Registrar WHOIS Server line and issuing a second query yourself.
• Undocumented rate limits. You discover them by being throttled.

A concrete example of the referral problem — the registry response tells you where to go next, but nothing follows the pointer for you:

whois -h whois.verisign-grs.com "domain github.com"

#    Registry Domain ID: 1264983250_DOMAIN_COM-VRSN
#    Registrar WHOIS Server: whois.markmonitor.com
#    Registry Expiry Date: 2026-10-09T18:20:50Z
#    Registrar: MarkMonitor Inc.
#    Name Server: NS-1283.AWSDNS-32.ORG

# Nothing about the registrant. That lives at the registrar,
# and you have to issue the second query yourself.

What does RDAP do differently?

RDAP is a set of IETF specifications defining an HTTPS API over the same registration data. Queries are ordinary URLs, responses are JSON with named members, and failures come back as real HTTP status codes — 404 for a name that does not exist, 429 when you are rate limited, 200 with a body when there is data. That alone removes most of the parsing guesswork.

curl -sS -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com | jq '.events'

# [
#   { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
#   { "eventAction": "expiration",   "eventDate": "2027-08-13T04:00:00Z" },
#   { "eventAction": "last changed", "eventDate": "2026-08-14T08:01:43Z" },
#   { "eventAction": "last update of RDAP database",
#     "eventDate": "2026-08-31T21:40:08Z" }
# ]

Note the last event: RDAP tells you how fresh its own answer is, which WHOIS generally does not. Dates are ISO-8601 with an explicit timezone, so no locale-dependent parsing is required.

You do not need to know the endpoint

IANA publishes a bootstrap registry mapping every TLD to its RDAP base URL. You can consume it yourself, or use the public rdap.org redirector, which reads the same file and 302s you to the right registry.

# Which server handles .uk?
curl -sS https://data.iana.org/rdap/dns.json \
  | jq -r '.services[] | select(.[0][] == "uk") | .[1][]'
# https://rdap.nominet.uk/uk/

# Or just follow the redirect:
curl -sSL https://rdap.org/domain/example.com | jq -r '.ldhName, .status[]'
# EXAMPLE.COM
# client delete prohibited
# client transfer prohibited
# client update prohibited

Referrals are machine-followable

Where WHOIS buries the registrar server in a text line, RDAP puts it in a typed links array with a related relation. A client can walk from registry to registrar without any string handling.

curl -sSL https://rdap.org/domain/cloudflare.com | jq -r '.links[] | "\(.rel) \(.href)"'

# self     https://rdap.verisign.com/com/v1/domain/cloudflare.com
# related  https://rdap.cloudflare.com/rdap/v1/domain/CLOUDFLARE.COM

It carries data WHOIS never structured well

DNSSEC delegation is a good example. In WHOIS it is a single DNSSEC: signedDelegation line at best; in RDAP it is a secureDNS object with the actual DS records, which you can compare against what the parent zone publishes.

curl -sSL https://rdap.org/domain/example.com | jq '.secureDNS'

# {
#   "delegationSigned": true,
#   "dsData": [
#     { "keyTag": 2371, "algorithm": 13, "digestType": 2, "digest": "C988EC..." }
#   ]
# }

Cross-check that against live resolution with the DNSSEC Checker, and compare the RDAP nameservers array against the delegation actually in use via the NS Record Lookup. A mismatch between what the registry has recorded and what resolvers see is a real and easily missed failure mode.

Why is so much registrant data missing from both?

That is not an RDAP change. Since GDPR came into effect, ICANN policy has required gTLD registries and registrars to withhold most personal registrant data from public responses. WHOIS handles this by printing REDACTED FOR PRIVACY or omitting the field; RDAP can express it explicitly, with a redacted member naming which fields were removed and why. Either way the underlying data is gone from the public answer.

What remains public is the operational core, and for support work that is nearly all you need: dates, status codes, sponsoring registrar, registrar abuse contact, and nameservers. Chasing the human behind a domain now generally means a formal disclosure request, not a lookup.

So is WHOIS dead?

For gTLDs it is being retired — ICANN has been moving registries and registrars off the requirement to operate port-43 WHOIS in favour of RDAP, and some have already switched theirs off. Elsewhere it is very much alive, and there are still cases where it is the only option.

The pragmatic answer for a support desk: query RDAP first, fall back to WHOIS when the TLD has no RDAP service. That is exactly what our WHOIS Lookup and Domain Age Checker do behind the scenes, so you get consistent fields regardless of which protocol answered.

If what you are actually chasing is a renewal deadline rather than ownership, When Does My Domain Expire? walks through the registry-versus-registrar date difference and the grace, redemption, and deletion phases that follow.

And if you are using either protocol to debug a resolution failure rather than a registration question, remember that registration data and live DNS can disagree. The registry knows which nameservers are *delegated*; only a query answers what those nameservers actually *serve*. Compare the RDAP nameservers array against a live DNS Lookup, and if a name has stopped resolving entirely, SERVFAIL vs NXDOMAIN tells you which side of that gap the problem sits on.