WHOIS vs. RDAP: The Future of Domain Directory Services

Why domain directory services matter

Every registered domain name has a record behind it: who the registrar is, when the name was created, when it expires, which name servers it delegates to and which status codes currently lock or restrict it. Security teams use this data to investigate phishing, brand owners use it to spot infringing registrations, and administrators use it to check that their own domains will not quietly lapse. For more than three decades the tool for reading that record was WHOIS. Today it is being replaced by RDAP, the Registration Data Access Protocol.

This guide explains how both protocols work, what changed technically, what ICANN's policy decisions mean in practice, and how to query each one yourself.

How the WHOIS protocol works

WHOIS predates the commercial web. The current specification, RFC 3912 from 2004, is only a few pages long because the protocol itself is minimal: a client opens a TCP connection to port 43, sends a single line of text (usually a domain name) followed by a carriage return and line feed, and the server replies with free-form text before closing the connection.

whois example.com
whois -h whois.verisign-grs.com example.com

That simplicity made WHOIS easy to implement, but it also left major gaps that became painful as the domain industry grew.

The weaknesses of WHOIS

• No standard output format. Each registry and registrar chooses its own field names, date formats and layout. One server prints Registry Expiry Date, another expires, another paid-till. Software has to maintain fragile parsers for hundreds of variants.
• No server discovery. The protocol does not say which server is authoritative for a TLD. Clients rely on hard-coded lists or on referrals embedded in the text output.
• No internationalisation. RFC 3912 does not define a character encoding, so non-ASCII names and contact details are often garbled.
• No authentication or encryption. Traffic is plain text, and there is no way to give different users different levels of access.
• Thin versus thick models. For thin registries such as .com, the registry holds only basic data and the client must follow a referral to the registrar's WHOIS server for the rest.

What RDAP is and how it works

RDAP was developed in the IETF WEIRDS working group as a deliberate successor to WHOIS. Instead of a custom text protocol it uses ordinary HTTPS requests and returns JSON. Queries are RESTful URLs, so any HTTP client, browser or scripting language can use it without special libraries.

The RFCs behind RDAP

Query types

RDAP defines a small set of object paths. The most useful for domain owners are:

• /domain/example.com – registration data for a domain name
• /nameserver/ns1.example.com – information about a name server
• /entity/HANDLE – a registrar, registrant or other contact object
• /ip/192.0.2.0 and /autnum/64496 – IP address blocks and AS numbers, served by the regional internet registries

Bootstrapping: finding the right server

IANA publishes JSON bootstrap files that map each TLD, IP range and AS number range to the base URL of its RDAP service. For domains the file lives at https://data.iana.org/rdap/dns.json. A client reads the TLD from the query, looks it up in the file and sends the request to the listed base URL. This removes the guesswork and hard-coded server lists that WHOIS clients needed.

WHOIS vs RDAP compared

Querying RDAP in practice

Because RDAP is just HTTPS, curl is enough. You can query a registry directly or use a redirect service such as rdap.org, which reads the IANA bootstrap data and forwards you to the authoritative server.

curl -s https://rdap.verisign.com/com/v1/domain/example.com
curl -sL https://rdap.org/domain/example.com

A trimmed response looks like this:

{
  "objectClassName": "domain",
  "ldhName": "EXAMPLE.COM",
  "status": ["client delete prohibited", "client transfer prohibited"],
  "events": [
    {"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"},
    {"eventAction": "expiration", "eventDate": "2026-08-13T04:00:00Z"}
  ],
  "nameservers": [{"ldhName": "A.IANA-SERVERS.NET"}]
}

The events array is the part renewal tracking cares about most: the expiration event is a machine-readable timestamp in ISO 8601 format, so there is no need to guess whether 03/04/2027 means March or April. Status values mirror the EPP status codes defined in RFC 5731, written in lower case with spaces. Contact details appear in entities, traditionally encoded as jCard (RFC 7095); newer deployments are adding JSContact as an alternative.

Handling errors and limits

RDAP servers use normal HTTP semantics. A 404 means the object does not exist at that server, which for a domain usually means it is not registered. A 429 means you are being rate limited, so a well-behaved client backs off and retries later. Redirects (301, 302, 307) are used to send you from one server to another, so always follow them.

ICANN policy and the 2025 WHOIS sunset

ICANN required gTLD registries and registrars to deploy RDAP services from 26 August 2019. For several years both protocols ran in parallel. Following amendments to the registry and registrar agreements, ICANN set 28 January 2025 as the date from which contracted parties are no longer obliged to operate port 43 WHOIS for generic TLDs. From that point, RDAP became the definitive source of registration data for gTLDs such as .com, .net, .org and the new gTLDs.

Some operators still answer port 43 queries voluntarily, but you should not depend on that. Any script or monitoring system that parses WHOIS text for gTLD domains should be migrated to RDAP.

What about country-code TLDs?

ccTLDs are not bound by ICANN contracts and set their own policies. A growing number publish RDAP endpoints in the IANA bootstrap file, but many still offer WHOIS only, and some offer neither publicly. A practical client therefore checks the bootstrap file first and falls back to the ccTLD's WHOIS server when no RDAP base URL is listed.

Privacy, redaction and the GDPR

Since the GDPR took effect in May 2018, most registrant personal data in gTLD records has been redacted. RDAP does not by itself reveal more than WHOIS did; the same policies apply. What RDAP adds is a standard way to express redaction and, in principle, to grant authenticated users such as law enforcement access to fuller records. ICANN's Registration Data Policy, which contracted parties had to implement by 21 August 2025, defines which fields are collected, published or redacted.

For most domain owners, this means a public lookup will show the registrar, dates, name servers and status codes, but not the registrant's name or email. If you need to contact a registrant, the registrar's record usually links to a contact form or abuse address.

Using RDAP for renewal and expiry monitoring

For anyone managing more than a handful of domains, the shift to RDAP is good news. Expiry dates come in a consistent, parseable format, status codes are standardised, and the registrar is identified by its IANA ID. That makes automated monitoring far more reliable than scraping WHOIS text.

1. Resolve the authoritative RDAP server from the IANA bootstrap file.
2. Fetch the domain object and read the expiration event.
3. Check status codes such as client hold, redemption period or pending delete, which signal a problem.
4. Fall back to WHOIS for TLDs without RDAP, and cache results to respect rate limits.

TLDix follows exactly this approach. Its domain WHOIS and RDAP lookup queries RDAP first and falls back to WHOIS where needed, and the hosting lookup uses the IP and ASN side of RDAP to identify who operates the server behind a domain. The documentation explains how tracked domains are checked for upcoming expiry.

Key points to remember

WHOIS served the internet well, but it was never designed for structured data, internationalisation or access control. RDAP fixes those problems by building on HTTPS and JSON, with a clear set of RFCs and an IANA-run discovery mechanism. For generic TLDs the transition is effectively complete, while ccTLDs are moving at their own pace. If you build tools, write new code against RDAP and keep WHOIS only as a fallback; if you simply own domains, the change mostly means more accurate expiry data and fewer surprises.