RDAP vs WHOIS: Which Protocol to Query in 2026
RDAP replaced the gTLD WHOIS obligation on 28 January 2025, not the protocol. Compare transport, coverage, and when to fall back to port 43.
TL;DR Use RDAP for gTLD domains, IP networks, and ASNs. Fall back to WHOIS when the TLD is missing from IANA's RDAP bootstrap (common for country-code TLDs) or when a server still answers on port 43 and RDAP fails. Public registration data directory services (RDDS) on both protocols hide most gTLD registrant emails. For that, use ICANN's Registration Data Request Service or the sponsoring registrar.
Last updated: September 1, 2026
RDAP vs WHOIS is not a religion. It is a routing problem: which protocol can actually answer for this object, today. The 28 January 2025 headline said WHOIS was sunset. The contract said the obligation to offer it went away for most gTLD registries and registrars. Port 43 still answers for .com, for a long list of ccTLDs, and for operators who never turned it off.
If you need field-by-field output (status codes, RIR blocks, redacted contacts), start with how to read WHOIS and RDAP. This page is the protocol decision.
| You have | Start with | Fall back to WHOIS when |
|---|---|---|
A gTLD domain (.com, .org, .app, …) | RDAP via IANA dns.json | RDAP 404/timeout and the registry still runs port 43 (.com still does) |
.com, .name, or .post | Either. Both are still required. | You already have a port-43 script and you only care about .com |
A ccTLD (.de, .uk, .jp, .io, …) | Check whether the TLD is in dns.json | The label is missing from the bootstrap. Many large ccTLDs still are. |
| An IP or ASN | RIR RDAP (/ip/, /autnum/) | The RIR or NIR still publishes richer WHOIS text, or RDAP search is missing |
| A mixed list of domains, IPs, and ASNs | A client that tries RDAP first per object | Per-row, not per-batch |
| A need for the registrant's name or email | Neither public protocol | RDRS or the registrar's disclosure process |
DNS Buddy's WHOIS Lookup follows that order: RDAP first, WHOIS if RDAP fails. Bulk WHOIS does the same for mixed batches of up to 256 targets.
If you are writing new automation, default to RDAP and keep WHOIS as the escape hatch. If you only ever look up .de or .jp, a port-43 client is still the honest tool. The rest of this page is the why.
On 27 January 2025, ICANN published "Launching RDAP; Sunsetting WHOIS". As of 28 January 2025, RDAP became the definitive source for generic TLD registration data under ICANN contracts.
That is narrower than the blog posts made it sound.
.com, .name, and .post as WHOIS-required exceptions. Verisign asked to keep .com WHOIS with no sunset option in the 2024 .com renewal.Andy Newton at ICANN, writing on the IETF blog in February 2026 from ICANN monthly registry reports, put numbers on the traffic shift: gTLD WHOIS queries went from about 122 billion in January 2025 to about 49 billion in August 2025, while RDAP went from about 7 billion to about 65 billion and overtook WHOIS in June 2025. He also notes that earlier published aggregates had analysis errors, so treat those figures as ICANN's restated series, not a census you can download. The same post cites an internal scan of 74 gTLD registries that shut WHOIS in February 2025, and a later monitor count of 374 gTLDs no longer offering it by September 2025. Hundreds of gTLDs dropping port 43 is not the same as "WHOIS is gone."
| Dimension | WHOIS | RDAP |
|---|---|---|
| Spec | RFC 3912 (2004) | RFC 7480 / 7481 still current; query/response RFC 9082 / 9083; discovery RFC 9224. 7482–7484 are obsolete. |
| Transport | TCP port 43, cleartext | HTTP; servers and clients must support HTTPS |
| Payload | Unstructured text. Field names and order vary by server. | JSON (application/rdap+json) with rdapConformance |
| Errors | Empty body, truncated text, or a dropped socket | HTTP 200 / 404 / 429 / 501, plus Retry-After |
| Discovery | Hard-coded whois servers, referrals in the text | IANA bootstrap JSON, longest-match |
| Internationalization | RFC 3912: no character-set signal | UTF-8; IDN in the path |
| Access control | None in the protocol | Designed in (RFC 7481). Public gTLD output is still redacted. |
| Objects | Whatever that server's text includes | /domain/, /nameserver/, /entity/, /ip/, /autnum/ |
WHOIS wins on muscle memory and on ccTLDs that never published an RDAP URL. RDAP wins anywhere you need to parse the answer, handle an HTTP status, or query an IP and a domain with the same client. The IETF's 2021 status change that made RDAP an Internet Standard explicitly did not retire WHOIS. RFC 9082 even expects some registries to keep WHOIS next to RDAP.
This is the part most comparison pages skip or get wrong. We counted IANA's published files on 1 September 2026. These are directory fields, not live port-43 probes: a whois_server value can be stale after the sunset, and a missing RDAP URL can hide a "stealth" server that was never registered.
https://data.iana.org/TLD/tlds.json, meta.generated = 2026-09-01T18:24:03+00:00:
| Active TLDs | Count | With rdap_base_urls | With whois_server | WHOIS only | Neither |
|---|---|---|---|---|---|
Generic (type: generic) | 1,128 | 1,126 | 636 | 1 (.edu) | 1 (.mil) |
| Country-code | 309 | 74 | 236 | 165 | 70 |
https://data.iana.org/rdap/dns.json, publication = 2026-07-23T02:00:03Z: 1,200 unique TLD labels across 590 service groups. Present in that bootstrap snapshot: com, net, org, uk, au, nl, name, post. Absent: de, jp, cn, io.
Read that table as an operator, not as marketing. Almost every generic TLD IANA marks active already publishes an RDAP base URL. Country-code TLDs do not. .de, .jp, .cn, .io, and .us still list a WHOIS server and no RDAP URL in tlds.json. DENIC's RDAP page calls the service a pilot / test operation and does not guarantee a service level. It is not in the bootstrap, so a vanilla RFC 9224 client will never find it. .uk is the opposite pattern: Nominet is in dns.json, and Nominet still runs WHOIS in parallel until 9 February 2027.
Absence from dns.json means "IANA has no RDAP URL for this TLD," not "this TLD has no RDAP." If your client only speaks bootstrap, you will miss stealth servers. If your client only speaks port 43, you will miss the 491 generic TLDs that list an RDAP base URL and no whois_server in IANA's file.
.com, .net, and .jobs are historically thin: the registry has the domain object (dates, nameservers, status). Contacts live at the registrar. A thick registry (many new gTLDs, .org) stores that contact object at the registry, so one RDAP GET is closer to complete. Thin vs thick is a data-location rule from ICANN's thick WHOIS policy, not a WHOIS quirk.
RDAP copies the same split. A Verisign RDAP response for a .com name often includes a links entry with rel: related and type: application/rdap+json pointing at the registrar. One GET to rdap.verisign.com is not a full record. Follow the related link. If the registrar's RDAP is gone after the sunset and you wanted contact-shaped fields, you will not get them from Verisign's remaining WHOIS either. Public contacts were already redacted.
A 2024 measurement paper (Hölzel et al., PAM / arXiv:2406.02046) found WHOIS and RDAP for the same domain can disagree on registrar IANA ID, dates, or nameservers. Do not assume the two protocols are interchangeable dumps of one database.
GDPR (applicable 25 May 2018) never names WHOIS or RDAP. ICANN's Temporary Specification (17 May 2018) made contracted parties redact personal RDDS fields, on WHOIS and on RDAP, with text substantially like REDACTED FOR PRIVACY. The Registration Data Policy that replaced the Temp Spec became effective 21 August 2025. Same publication rules, better structured redaction in RDAP.
Switching protocols will not un-redact a registrant email. ICANN said this directly in the RDAP FAQs: RDAP is a new way of accessing the same registration data.
For non-public gTLD data, ICANN's January 2025 announcement points at lookup.icann.org first, then RDRS for participating registrars, or the sponsoring registrar's own disclosure process. RDRS is for people with a stated legitimate interest (law enforcement, IP, security, government). It is not an API key you add to curl.
RFC 7481 describes authentication and differentiated access as RDAP capabilities. Public developers should not plan on OAuth unlocking the registrant as a normal Lookup user.
RDAP, domain:
# 1. Find the base URL in IANA bootstrap (cache this; RFC 9224 says do not fetch per query)
curl -s https://data.iana.org/rdap/dns.json
# 2. Append the RFC 9082 path
curl -s -H "Accept: application/rdap+json" \
https://rdap.verisign.com/com/v1/domain/example.comRDAP, IP / ASN: use ipv4.json / ipv6.json / asn.json and /ip/ or /autnum/. The five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) all speak RDAP. ARIN's https://rdap.arin.net/registry is a practical starting point; it refers or redirects when the prefix lives in another RIR.
WHOIS:
whois example.com
whois -h whois.verisign-grs.com example.comWhen we look up a domain in DNS Buddy, WhoISLookupService walks the TLD labels against IANA dns.json, calls the matching RDAP server, and if that fails it runs a port-43 WHOIS query (server list synced from whoislist.org). IP and ASN lookups currently send RDAP to ARIN's registry endpoint first, then the same WHOIS fallback. The stored result includes method: "RDAP" or method: "WHOIS" so you can see which path won. That is why a .de domain and a .com domain in the same bulk batch can show different methods without you picking a protocol.
Corporate CI that "randomly" fails WHOIS is often a port-43 egress filter. RDAP on 443 survives that. A ccTLD missing from dns.json fails the other way: RDAP never starts, WHOIS might.
For incident work on a fleet, this sits next to the DNS tools for DevOps workflow: identify the registrar and expiry on the domain, then the RIR and abuse mailbox on the IP.
Take three objects you might paste into a bulk box during an incident.
example.com is a gTLD. IANA dns.json has com. RDAP at Verisign returns JSON with events, nameservers, and status. Follow rel: related if you need the registrar object. WHOIS at whois.verisign-grs.com still answers because .com is a listed exception. Prefer the JSON. Keep port 43 as a debug spare.
example.de is a country-code TLD. On 1 September 2026 it had whois.denic.de and no rdap_base_urls in tlds.json, and de was absent from dns.json. A bootstrap-only RDAP client stops. WHOIS to DENIC is the public path. DENIC's RDAP pilot is not something RFC 9224 will discover for you.
8.8.8.8 is an IP. Domain bootstrap is the wrong file. Use ipv4.json or a RIR RDAP base (/ip/8.8.8.8). Abuse contacts and the allocated prefix come from the RIR, not from Verisign. Mixing that IP with the two domains in one request is why we classify each row (domain, IP, ASN) before choosing a server.
If RDAP returns 429, wait for Retry-After. If it returns 404 on a name you believe is registered, try WHOIS before concluding the name is available. RDAP 404 on an unsupported TLD and RDAP 404 on an unregistered name look the same at the HTTP layer. Our lookup path treats a 404 plus a failed WHOIS as "not found"; a 404 plus a successful WHOIS as "use the WHOIS row."
RDAP JSON is standardized and still annoying. Contacts hide in vcardArray (jCard, RFC 7095). Andy Newton's February 2026 IETF status note flags jCard as hard to use and mentions JSContact as a possible successor. Thin .com needs two GETs. Bootstrap files lag the root: on the day we counted, dns.json was last published 23 July 2026 while tlds.json was generated 1 September 2026. RFC 9224 already warns that a newly delegated TLD may exist before it appears in the bootstrap.
WHOIS text is worse to parse and often richer for a specific ccTLD's local fields. Historical "who owned this in 2016" lives in WHOIS archives, not live RDAP. If your job is OSINT on old registrations, you are not choosing a protocol. You are choosing a database.