WHOIS Is Dead, Long Live RDAP

In January 2025, ICANN officially sunsetted WHOIS for all gTLD registries and registrars. The protocol that powered domain lookups since 1982 is now deprecated. Its replacement — RDAP — has been mandatory since that date.

If you’ve ever parsed a WHOIS response, you know why it had to go. If you haven’t, consider yourself lucky.

WHOIS: What It Was

WHOIS was a plain-text protocol running on TCP port 43, formalized in RFC 3912. The entire exchange looked like this:

Client opens TCP connection to port 43
Client sends: "example.com\r\n"
Server sends: plain text response (no standard format)
Server closes connection

That’s the whole protocol. No encryption. No authentication. No structured format. The server dumps a blob of text and hangs up.

The response was human-readable but machine-hostile. Every registry and registrar formatted theirs differently. Parsing required per-server regex patterns — “No match for” vs “NOT FOUND” vs “Domain not found” vs an empty response all meant the same thing. There was no standard way to know.

The referral system made it worse. Thin registries (like Verisign for .com) only returned basic data and a pointer to the registrar’s own WHOIS server. Getting full registration details required two separate TCP connections: one to the registry, one to the registrar.

Why It Died

Six problems converged:

1. No standard format — every server formatted differently, requiring per-server parsing logic
2. No standard errors — “not found” expressed a dozen different ways
3. Plaintext TCP — anyone on the network path could see what domains you were looking up
4. No authentication — IP-based rate limiting was the only protection
5. Referral chains — two TCP connections for one lookup on thin registries
6. GDPR — the kill shot. WHOIS was designed to publish registrant names, addresses, phone numbers, and emails. The EU’s General Data Protection Regulation (2018) made that illegal for EU data subjects. The response was mass redaction — inconsistent, messy, and legally uncertain.

ICANN had been pushing RDAP since the RFCs landed in 2015. GDPR forced the timeline. By January 2025, all gTLD operators were required to support RDAP. WHOIS port 43 isn’t turned off yet — Verisign still runs whois.verisign-grs.com — but it’s legacy. The ~189 country-code TLDs (.uk, .de, .jp) still rely on WHOIS because ICANN’s mandate doesn’t apply to them. That’s the last holdout.

RDAP: What Replaced It

Registration Data Access Protocol. HTTPS transport, JSON responses. Defined across six RFCs:

A query is a single HTTPS GET:

GET https://rdap.verisign.com/com/v1/domain/example.com
Accept: application/rdap+json

The response is structured JSON — dates in ISO 8601, status codes from a defined vocabulary, entities with roles, nameservers as objects. HTTP 404 means the domain isn’t in the registry database (available). HTTP 200 means it’s taken. HTTP 429 means you’re rate-limited. No guessing.

RDAP was designed with GDPR in mind. Privacy is built into the spec through role-based redaction — registries can omit personal data by default and only reveal it to authenticated, authorized parties via OAuth 2.0 or API keys.

The Comparison

This is the table that matters. Three ways to look up domain information, each with different tradeoffs:

The takeaway: DNS is fastest but only tells you if something resolves. WHOIS has the widest coverage but is a parsing nightmare. RDAP gives you everything WHOIS did in a format you can actually use — at the cost of being slower and not yet universal.

Bootstrap: Finding the Right Server

RDAP has no single server. Each TLD has its own RDAP endpoint. To find the right one, you consult the IANA bootstrap file:

https://data.iana.org/rdap/dns.json

This JSON file maps TLDs to RDAP server URLs. It currently contains 447 service entries. The structure is an array of [tld_list, url_list] pairs:

[
  [["com", "net"], ["https://rdap.verisign.com/com/v1/"]],
  [["uk"], ["https://rdap.nominet.uk/uk/"]],
  [["google", "youtube"], ["https://pubapi.registry.google/rdap/"]]
]

Match your TLD against the entries (longest label-wise match wins), then construct the query URL: {base_url}domain/{domain_name}. Cache the file locally with a 24-hour TTL.

If you don’t want to maintain the bootstrap logic, rdap.org acts as a redirect service — query https://rdap.org/domain/{name} and it 302-redirects to the authoritative server. But it has strict rate limits (10 requests per 10 seconds) and adds a round-trip, so direct bootstrap is better for anything beyond casual lookups.

Quick Examples

WHOIS (legacy, but still works):

# Raw WHOIS query over TCP
whois example.com

# Or with netcat, to see exactly what happens
echo "example.com" | nc whois.verisign-grs.com 43

RDAP (the modern way):

# Direct query to Verisign's RDAP server
curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | python3 -m json.tool

# Via rdap.org redirect (follows 302 automatically)
curl -sL https://rdap.org/domain/example.com \
  | python3 -m json.tool

# Check if a domain is available (HTTP 404 = available)
curl -s -o /dev/null -w "%{http_code}" \
  https://rdap.verisign.com/com/v1/domain/thisdomainprobablydoesnotexist.com
# Returns: 404

The difference is stark. WHOIS gives you a wall of text you need to regex apart. RDAP gives you json.loads() and you’re done.

What This Means Going Forward

WHOIS isn’t fully dead yet — the servers are still running and ~189 ccTLDs depend on it exclusively. But for .com, .net, .org, and every other gTLD, RDAP is the authoritative source. New tooling should target RDAP first with WHOIS as a ccTLD fallback.

The structured format also opens doors that WHOIS never could: proper error handling, authenticated access for legitimate use cases, and machine-readable responses that don’t break when a registry changes their text formatting. Forty years of “just dump some text on port 43” is finally over.