whois
WHOIS Is Effectively Dead. Here Is What RDAP Actually Returns
Plain-text WHOIS on port 43 has been replaced by RDAP: JSON over HTTPS, standardized fields, and GDPR redaction. What changed, what you still get, and what every EPP status code actually means for your domain.
If you last looked up a domain by telnetting to port 43, the tool you’re thinking of doesn’t exist anymore — ICANN pulled the plug on the WHOIS requirement for gTLDs in January 2025. What replaced it is a structured JSON protocol with an entirely different data model, and the change is bigger than a format swap: what’s actually public about a domain changed too.
The old protocol: unstructured text on port 43
WHOIS, as specified in RFC 3912, is about as simple as a protocol gets: open a TCP socket to port 43, send a domain name and a newline, get back whatever text the server feels like sending, connection closes. That’s the entire spec. There’s no schema, no required fields, no authentication, and no character encoding guarantee.
In practice that meant every registry formatted its response differently:
Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.example-registrar.com
Updated Date: 2026-01-14T10:22:31Z
Creation Date: 1995-08-14T04:00:00Z
Registry Expiry Date: 2027-08-13T04:00:00Z
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: NS1.EXAMPLE-DNS.COM
Name Server: NS2.EXAMPLE-DNS.COMThat’s a fairly clean thin record. Plenty of registries wrapped fields differently, used different date formats, or returned nothing machine-parseable at all — you were writing a regex against prose, and the regex broke the next time the registry tweaked their template. There was no i18n story either: WHOIS predates the assumption that a registrant’s name might not fit in ASCII. And because the protocol has no access-control concept, every field a registry chose to publish was public to anyone who could open a socket — which is exactly the problem that eventually forced a rewrite.
RDAP: the same lookup, actually structured
RDAP (Registration Data Access Protocol) is a REST API: HTTPS requests, JSON responses, defined by RFC 7480–7484 and RFC 9082/9083. The same domain above comes back as:
{
"objectClassName": "domain",
"ldhName": "EXAMPLE.COM",
"status": ["client transfer prohibited"],
"events": [
{ "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
{ "eventAction": "expiration", "eventDate": "2027-08-13T04:00:00Z" },
{ "eventAction": "last changed", "eventDate": "2026-01-14T10:22:31Z" }
],
"nameservers": [
{ "ldhName": "NS1.EXAMPLE-DNS.COM" },
{ "ldhName": "NS2.EXAMPLE-DNS.COM" }
],
"entities": [
{ "roles": ["registrar"], "vcardArray": ["vcard", [["fn", {}, "text", "Example Registrar, LLC"]]] }
]
}Same underlying facts, but now every field has a name, a type, and a spec that says what it means. Three things RDAP adds that WHOIS structurally couldn’t:
- Standardized objects.
domain,entity,nameserver, andip networklookups all follow the same JSON structure regardless of which registry answers. - Internationalization. Fields are UTF-8, and RDAP defines a proper way to carry both an ASCII (
ldhName) and a Unicode (unicodeName) form of internationalized domain names. - Differentiated access. RDAP has a real concept of “this field is redacted for this requester.” WHOIS could only send the whole blob or nothing.
- Discoverability via bootstrap. IANA publishes bootstrap registry files (per RFC 7484, at
data.iana.org/rdap/) mapping every TLD — and every allocated IP block and AS number range — to the RDAP server responsible for it. A client reads the bootstrap file once and knows exactly which server to query for.com,.de, or a given/24, instead of hardcoding a WHOIS server list that goes stale.
The actual ICANN deadlines
Two dates get conflated a lot, and they’re different:
| Date | What happened |
|---|---|
| August 26, 2019 | ICANN’s deadline for all gTLD registries and registrars to have RDAP running, per the gTLD RDAP Profile — but WHOIS (port 43) still had to stay up alongside it. |
| January 28, 2025 | The WHOIS requirement was formally sunset for gTLDs. The ICANN Board approved the RDAP Global Amendments to the base Registry Agreement and the Registrar Accreditation Agreement in April 2023, setting the sunset for 18 months after the amendments took effect — landing on January 28, 2025. |
So for a five-and-a-half-year window, gTLD registries ran both protocols side by side. Since January 2025, RDAP is the only required lookup for gTLDs; a registrar can still run a WHOIS server voluntarily, but nothing in the ICANN contracts makes them.
What GDPR did to the data
The other half of the story isn’t the protocol, it’s what’s in it. When GDPR took effect in May 2018, ICANN adopted the Temporary Specification for gTLD Registration Data, and the practical effect has stuck ever since: most registrant contact fields are redacted by default for individual registrants.
What you can still reliably pull from a gTLD RDAP record:
| Field | Still public? |
|---|---|
| Registrar name / IANA ID | Yes |
| Creation, expiration, last-updated dates | Yes |
| Nameservers | Yes |
| Domain status (EPP codes) | Yes |
| Registrar abuse contact email/phone | Yes — ICANN requires this specifically |
| Registrant name, organization | Usually redacted (REDACTED FOR PRIVACY) |
| Registrant email, phone, street address | Usually redacted |
Organizations, legal entities, and registrants in some jurisdictions outside GDPR’s reach sometimes still show full contact data — it depends on the registrar’s policy, not the protocol. If you need to reach a domain owner, the reliable path now is the registrar abuse contact, not the registrant record.
EPP status codes, decoded
This is the part of a WHOIS/RDAP record most people skim past, and it’s the most actionable part. Every domain carries one or more EPP status codes (RFC 5731 §2.3), and the prefix tells you who set it and who can remove it:
client*— set by your registrar. You (the registrant) control these through your registrar account or support.server*— set by the registry itself, one level up. Only the registry can remove these, usually for legal, dispute, or policy reasons — your registrar can’t touch them.
| Status | Set by | What it means | What to do |
|---|---|---|---|
ok | registry | Normal state, nothing pending or restricted | Nothing |
inactive | registry | No nameservers delegated; domain doesn’t resolve | Add nameservers if you want it live |
clientTransferProhibited | registrar | Transfer to another registrar blocked | Must be lifted in your registrar account before an outbound transfer will work |
clientDeleteProhibited | registrar | Deletion blocked | Ask your registrar to remove it before deleting |
clientUpdateProhibited | registrar | Contact/nameserver changes blocked | Ask your registrar to remove it before editing DNS or WHOIS contacts |
clientHold | registrar | Nameservers withheld from the zone — domain does not resolve | Contact your registrar; often unpaid invoice or unverified contact info |
serverHold | registry | Registry pulled it from the zone — does not resolve | Serious: usually a UDRP dispute, court order, or registry-level abuse action. Registrar can’t fix it |
serverTransferProhibited | registry | Transfer blocked at the registry level | Legal dispute or registry policy; only the registry lifts it |
pendingDelete | registry | Past redemption, queued for release | Nothing left to do — it drops for public registration within days |
redemptionPeriod | registry | Expired, deleted, but still restorable | Restore now through your registrar — it gets expensive and time-limited |
autoRenewPeriod | registry | Registry auto-renewed at expiry; registrar grace window to reverse it if unpaid | Pay the renewal, or let it lapse into expiration on purpose |
addPeriod | registry | Registered in the last few days (add grace period) | Informational — lets registrars void accidental new registrations for a refund |
If a status doesn’t match anything above, RDAP will often still show it verbatim (registries occasionally define their own) — check that registry’s documentation rather than assuming it’s one of the standard set.
The domain lifecycle, in days
Expiry doesn’t mean “gone tomorrow.” A gTLD domain moves through a fixed sequence of grace periods before it’s released, and the EPP status field is literally how you can see which stage it’s in:
| Stage | Typical length | Status you’ll see |
|---|---|---|
| Active, renewed normally | — | ok |
| Expired, registry auto-renews it | up to 45 days | autoRenewPeriod |
| Deleted, but restorable for a fee | ~30 days | redemptionPeriod |
| Queued for final release | ~5 days | pendingDelete |
| Dropped, open for anyone to register | — | (no longer in RDAP) |
That’s roughly an 80-day runway from expiration to drop under standard gTLD policy — but every one of those windows is a registry-set maximum, not a universal constant. Registries can and do choose shorter grace periods, and ccTLDs aren’t bound by ICANN’s numbers at all; some drop domains within days of expiry with no redemption step. Treat the table as “what you’ll typically see on a .com,” not a promise.
IP and ASN lookups go to a different directory entirely
RDAP isn’t only for domains. Query an IP address or an AS number and you’re not talking to a domain registry at all — you’re talking to one of the five Regional Internet Registries: ARIN (North America), RIPE NCC (Europe/Middle East/Central Asia), APNIC (Asia-Pacific), LACNIC (Latin America), or AFRINIC (Africa). Each one is bootstrapped the same way domains are, via IANA’s RDAP bootstrap files, so a client can route an IP query to the right RIR automatically.
What comes back is structurally different from a domain record: you get the allocated network range (a CIDR block, not a single host), the organization it was assigned to, and an abuse contact for that block — which is the address you actually want when you’re chasing down the source of malicious traffic. Subnet Calculator is the companion tool for working out which addresses fall inside the range an RIR hands back, and What Is My IP shows the address you’d be querying from.
The honest gap: not every ccTLD has caught up
RDAP’s mandate only ever applied to gTLDs and the RIRs. Country-code TLDs are under no ICANN obligation to run it at all, and adoption is real but incomplete — recent measurements put ccTLD RDAP deployment at roughly 60%, up from about half a year earlier, which means something like four in ten ccTLDs still don’t publish an RDAP endpoint. For those, you’re back to the registry’s own legacy WHOIS server or, in some cases, a web form on the registry’s site with no programmatic lookup at all. If a .io or a smaller ccTLD comes back empty from an RDAP client, that’s usually why — not a bug in the client.
Look one up
Query it directly rather than trusting a cached WHOIS mirror: the WHOIS Lookup tool queries the live public RDAP directory and shows the registrar, dates, nameservers, and status codes above with the client/server distinction called out. Worth saying plainly: a WHOIS/RDAP lookup is inherently a server-side query — the name you type has to be sent to a directory service somewhere — and our tool asks the public RDAP endpoint on your behalf without logging what you searched.
Pair it with DNS Lookup to see what the domain’s records actually resolve to — the two often disagree in informative ways, like a domain with clientHold set (won’t resolve) that still returns clean RDAP data, or see DNS record types explained for what each record type in that result means. And if you’ve just changed nameservers and the two disagree, that’s resolver caching, not “propagation” — here’s what you’re actually waiting for. For the certificate a domain is actually serving, the X.509 Decoder picks up where RDAP’s registration data leaves off.