WHOIS Is Dead, Long Live RDAP Markdown source

---
title: "WHOIS Is Dead, Long Live RDAP"
description: "ICANN sunsetted WHOIS in January 2025. RDAP replaced it — structured JSON over HTTPS instead of plaintext over TCP. Here's what changed and why it matters."
kind: note
maturity: budding
confidence: high
origin: ai-drafted
author: "Agent"
directedBy: "krow"
tags: [dns, networking]
published: 2026-03-28
modified: 2026-03-28
wordCount: 1303
readingTime: 6
series: "domain-infrastructure" (#2)
prerequisites: [dns-resolution-full-picture]
related: [dns-resolution-full-picture, bot-detection-2026, aimd-rate-limiting]
url: https://krowdev.com/note/whois-dead-long-live-rdap/
---
## Agent Context

- Canonical: https://krowdev.com/note/whois-dead-long-live-rdap/
- Markdown: https://krowdev.com/note/whois-dead-long-live-rdap.md
- Full corpus: https://krowdev.com/llms-full.txt
- Kind: note
- Maturity: budding
- Confidence: high
- Origin: ai-drafted
- Author: Agent
- Directed by: krow
- Published: 2026-03-28
- Modified: 2026-03-28
- Words: 1303 (6 min read)
- Tags: dns, networking
- Series: domain-infrastructure (#2)
- Prerequisites: dns-resolution-full-picture
- Related: dns-resolution-full-picture, bot-detection-2026, aimd-rate-limiting
- Content map:
  - h2: WHOIS: What It Was
  - h2: Why It Died
  - h2: RDAP: What Replaced It
  - h2: The Comparison
  - h2: Bootstrap: Finding the Right Server
  - h2: Quick Examples
  - h2: What This Means Going Forward
  - h2: Sources
- Crawl policy: same canonical content is exposed through HTML, Markdown, and llms-full; no crawler-specific content gate.

In January 2025, ICANN officially sunsetted WHOIS for all gTLD registries and registrars. The protocol that powered [domain registration](/note/domain-registration-icann-to-browser/) 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:

| RFC | What it covers |
|-----|---------------|
| 7480 | HTTP usage in RDAP |
| 7481 | Security services |
| 7482 | Query format |
| 9083 | JSON response format (current) |
| 9224 | Bootstrap — finding the right server |

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:

| Aspect | RDAP | WHOIS (port 43) | DNS / DoH |
|--------|------|-----------------|-----------|
| **Format** | Structured JSON (RFC 9083) | Unstructured text, varies by server | Wire format / JSON (DoH) |
| **Transport** | HTTPS (port 443, encrypted) | Plaintext TCP (port 43) | HTTPS (DoH) or UDP (port 53) |
| **Coverage** | ~77% of TLDs (growing) | Being sunsetted, still ~100% | All resolvable domains |
| **Rate limits** | Per-registry, undocumented, strict | Per-server, undocumented, IP-based | Very generous (Cloudflare/Google) |
| **Data richness** | Full: registrar, dates, status, NS, DNSSEC, entities | Same data, harder to parse | Existence only ([NXDOMAIN / NOERROR](/guide/dns-resolution-full-picture/)) |
| **Authentication** | Optional (OAuth 2.0, API keys, certs) | None | None |
| **Privacy** | GDPR-compliant by design (role-based redaction) | Pre-GDPR design, inconsistent redaction | N/A (no personal data) |
| **Error handling** | HTTP 404 = not found, 429 = rate limited | Varies: "No match", empty, connection refused | RCODE 3 = NXDOMAIN |
| **Parsing** | `json.loads()` | Per-server regex | Standard format |
| **Speed (typical)** | 500ms -- 3s | 200ms -- 2s | 30ms -- 100ms |
| **Best for** | Authoritative confirmation, rich data | ccTLD fallback (~189 without RDAP) | Fast pre-screening |

The takeaway: [DNS resolution](/guide/dns-resolution-full-picture/) 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:

```json
[
  [["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):

```bash
# 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):

```bash
# 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. If you're checking availability at scale, a [DNS pre-screen](/guide/dns-resolution-full-picture/) filters out the obvious "taken" domains before you hit RDAP rate limits.

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. At scale, RDAP queries are HTTPS requests — subject to the same [TLS fingerprinting](/note/tls-fingerprinting-curl-cffi/) and rate limiting that any HTTP client faces. Forty years of "just dump some text on port 43" is finally over.

## Sources

- [RFC 3912 — WHOIS Protocol Specification](https://datatracker.ietf.org/doc/html/rfc3912)
- [RFC 7480 — HTTP Usage in the Registration Data Access Protocol (RDAP)](https://datatracker.ietf.org/doc/html/rfc7480)
- [RFC 7481 — Security Services for the Registration Data Access Protocol](https://datatracker.ietf.org/doc/html/rfc7481)
- [RFC 7482 — Registration Data Access Protocol (RDAP) Query Format](https://datatracker.ietf.org/doc/html/rfc7482)
- [RFC 9083 — JSON Responses for the Registration Data Access Protocol](https://datatracker.ietf.org/doc/html/rfc9083)
- [RFC 9224 — Finding the Authoritative Registration Data Access Protocol (RDAP) Service](https://datatracker.ietf.org/doc/html/rfc9224)
- [IANA RDAP Bootstrap File (dns.json)](https://data.iana.org/rdap/dns.json)