WHOIS vs RDAP: what changed and why it matters

RDAP (Registration Data Access Protocol) is the official successor to WHOIS, standardized by the IETF and adopted by the ICANN. Both protocols expose the same domain registration data, registrant details, dates, nameservers, EPP status codes. The difference is in how they do it: RDAP uses HTTPS with structured JSON responses, while WHOIS returns raw text over TCP port 43 with no consistent format. For a human running a one-off lookup, the difference is invisible. For a developer building tooling or automation, it is fundamental.

The core problem with WHOIS

WHOIS has been running since 1982. For four decades, it accumulated a set of design problems that cannot be patched without replacing the protocol:

• No format standard. Every registry formats its response differently. Verisign's .com output looks nothing like RIPE's .eu output or APNIC's response for .au domains. Parsing WHOIS means writing and maintaining fragile, registry-specific regex patterns.
• No authentication. The protocol treats every client identically, a bot scraping millions of records gets the same access as a domain administrator checking their own asset. This makes rate limiting and access control impossible to implement properly.
• Rate limiting is ad hoc. Each operator implements it differently: some block after 10 requests per minute, others after 5, some after 1. There is no standard for how a blocked client should behave or how long to wait.
• No internationalization. Non-ASCII characters in registrant names or addresses routinely corrupt WHOIS output.
• No GDPR-compatible access control. WHOIS was designed to show everything to everyone. When GDPR arrived in 2018, it became impossible to differentiate what a registrar could show to the public versus an accredited third party versus a law enforcement agency, the protocol does not support that concept.
• TCP port 43, not HTTPS. No encryption, no certificates, no standard error codes.

What RDAP brings to the table

RDAP addresses each of these problems:

• Standardized JSON format (RFC 7483): Every RDAP server returns the same field structure, regardless of the registry. No parsing guesswork.
• HTTPS transport: Encryption, standard HTTP status codes, caching headers, and all the infrastructure the web already relies on.
• Differentiated access control: RDAP supports authentication and role-based field visibility. A registrar can show full registrant data to accredited parties while returning redacted fields to the public.
• Native Unicode support: Registrant names in Arabic, Chinese, or Cyrillic come through cleanly.
• Standardized bootstrapping: A client can automatically find the correct RDAP server for any TLD by consulting the IANA bootstrap file at https://data.iana.org/rdap/dns.json. No static table to maintain.
• Relational links: The JSON response includes href links to related entities (registrar, registrant), making it possible to follow relationships programmatically.

WHOIS vs RDAP side-by-side

Criterion	WHOIS	RDAP
Response format	Plain text (variable)	JSON (RFC 7483)
Transport	TCP port 43	HTTPS
Authentication	None	Optional (OAuth)
Standardized format	No	Yes
Unicode support	Limited	Full
Rate limiting	Ad hoc per operator	Standardized (HTTP 429 + Retry-After)
Access control	No	Yes
ICANN adoption	Legacy	Required for gTLDs since 2019

A real example: same domain, two protocols

Here is what querying github.com looks like through each protocol.

WHOIS output (Verisign, port 43):

Domain Name: GITHUB.COM
Registry Domain ID: 1264983250_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Registrar URL: http://www.markmonitor.com
Updated Date: 2022-09-07T09:10:44Z
Creation Date: 2007-10-09T18:20:50Z
Registry Expiry Date: 2024-10-09T18:20:50Z
Registrar: MarkMonitor Inc.
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: DNS1.P08.NSONE.NET
Name Server: DNS2.P08.NSONE.NET

RDAP response (rdap.verisign.com, JSON):

{
  "ldhName": "github.com",
  "handle": "1264983250_DOMAIN_COM-VRSN",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2007-10-09T18:20:50Z" },
    { "eventAction": "expiration",   "eventDate": "2024-10-09T18:20:50Z" },
    { "eventAction": "last changed", "eventDate": "2022-09-07T09:10:44Z" }
  ],
  "nameservers": [
    { "ldhName": "dns1.p08.nsone.net" },
    { "ldhName": "dns2.p08.nsone.net" }
  ],
  "entities": [
    {
      "roles": ["registrar"],
      "vcardArray": ["vcard", [["fn", {}, "text", "MarkMonitor Inc."]]]
    }
  ]
}

In the WHOIS output, extracting the expiry date requires parsing a line that starts with Registry Expiry Date:, and that field name changes between registries (some use Expiration Date, others Registrar Registration Expiration Date). In the RDAP response, it is always events[?(@.eventAction=="expiration")].eventDate. One predictable JSON path, every time.

Is WHOIS going away?

Not immediately. WHOIS is still accessible on the majority of registries, and many operators will keep it running for compatibility. But the direction is clear: ICANN has required all gTLD registries to support RDAP since 2019, and the number of ccTLDs with RDAP endpoints grows every year. Tools built today should query RDAP first and fall back to WHOIS only if RDAP is unavailable for a given TLD. That is exactly what Domain Sentinel does.

What this means for developers

If you are building anything that touches domain registration data, a few practical conclusions:

• Do not write WHOIS text parsers. The maintenance cost is real and the reliability is poor. Use RDAP.
• Use the IANA bootstrap to find the correct RDAP server per TLD automatically: curl https://data.iana.org/rdap/dns.json. No static mapping table needed.
• A single RDAP query looks like this: curl https://rdap.verisign.com/com/v1/domain/github.com
• Handle HTTP 429 responses properly. RDAP servers return a Retry-After header when rate-limited, respect it or get your IP banned.
• Domain Sentinel exposes an API that abstracts RDAP bootstrapping, rate limiting, and WHOIS fallback. If you need domain data in production without building that infrastructure yourself, it is the faster path.

Domain Sentinel queries RDAP first, with automatic fallback to WHOIS for TLDs not yet migrated.

Test a live RDAP lookup on any domain directly in Domain Sentinel, the response is parsed, annotated, and monitored automatically.