RDAP.SS: WHOIS lookup powered by RDAP

#1. What is the RDAP protocol?

RDAP stands for Registration Data Access Protocol.

The IETF developed RDAP as a structured replacement for the traditional WHOIS system.

RDAP provides standardized access to registration data for:

Domains
IP addresses (IPv4 / IPv6)
ASNs (Autonomous System Numbers)

RDAP's original RFC set includes RFC 7480 through RFC 7484. Later documents obsolete and replace parts of the original set: RFC 9082, RFC 9083, and RFC 9224 supersede RFCs 7482, 7483, and 7484 respectively.

#2. RDAP vs. WHOIS: what is different?

The short version:

Feature	WHOIS	RDAP
Transport	Plain TCP text	HTTP API, usually HTTPS
Data format	Unstructured text	Structured JSON
Internationalization	Poor (encoding varies)	Full UTF-8 support
Security	No encryption or auth	HTTPS and optional auth
Distributed lookup	Manual redirection	Built-in `bootstrap` mechanism
Standardization	Inconsistent formats	Uniform, machine-readable schema

In the old WHOIS world, clients connected to port 43, sent a plain-text query, and received whatever the server felt like sending back. For gTLDs, that world is already over: ICANN sunset port-43 WHOIS on January 28, 2025, making RDAP the definitive source for gTLD registration data. Many ccTLDs still run WHOIS, though.

Every registry had its own format. Sometimes the field for the registrant's email was Registrant Email, sometimes Contact Email, and sometimes something much stranger.

Developers had to write endless regex parsers just to extract data that should have been structured in the first place.

(If you have ever tried to parse WHOIS data, you probably still wake up sweating from that nightmare.)

The old WHOIS protocol has a few practical problems:

##2.1 No structure, no standard API

Every registry returns data differently, so automation is painful.

##2.2 No encryption

Port 43 uses plain text, so your ISP can see which domains you are querying. Not great.

##2.3 No access control

WHOIS servers usually see only your IP address. They cannot reliably tell users apart, apply permissions, or enforce identity-based limits.

##2.4 Messy management

Each TLD needs a custom WHOIS server definition because WHOIS has no global bootstrap list like RDAP.

#3. Why RDAP is better for tools

RDAP fixes the worst parts of WHOIS and gives developers something they can parse without inventing a new regex crime scene.

##3.1 Standardized JSON output

RDAP responses are structured JSON objects with clearly defined fields.

For example:

json

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["active"],
  "entities": [...]
}

No regex horror show. Your code gets JSON.

##3.2 A unified API

RDAP runs over HTTP/HTTPS using a RESTful API.

You can make normal GET requests and script lookups in almost any language.

Example:

bash

curl https://rdap.verisign.com/com/v1/domain/example.com

This returns structured data directly from the registry, without scraping.

##3.3 Automatic bootstrap

RDAP clients do not need to know which registry to ask.

They follow IANA's bootstrap data to find the correct RDAP server for each TLD or RIR.

RDAP.org tracks deployment daily. Common gTLDs such as .com, .net, and .org already have RDAP base URLs in the bootstrap data, while many ccTLDs still do not.

For those TLDs, manual configuration or a fallback still matters.

##3.4 Security and privacy

For gTLDs, RDAP runs over HTTPS, which avoids the plaintext leakage that comes with port 43 WHOIS.

Registries can also use OAuth 2.0 or token-based authentication and return different data based on the requester's role, such as public user, registrar, or law enforcement.

That makes it easier to expose public data while keeping restricted registration data behind the right access checks.

##3.5 Extensibility

RDAP supports extensions, allowing registries to add custom fields without breaking compatibility.

Example:

json

"rdapConformance": ["rdap_level_0", "icann_rdap_technical_implementation_guide_0"]

Extensions let registries add fields without replacing the protocol.

#4. Introducing RDAP.SS

I built a small WHOIS lookup site on top of RDAP: RDAP.SS

It uses Next.js, Tailwind CSS, and Redis caching, the usual suspects for a fast web app.

It supports queries in these formats:

Domain → https://rdap.ss/whois/google.com
IPv4 → https://rdap.ss/whois/8.8.8.8
IPv4 CIDR → https://rdap.ss/whois/8.8.8.0/24
IPv6 → https://rdap.ss/whois/2001:4860:4860::8888
IPv6 CIDR → https://rdap.ss/whois/2001:4860::/32
ASN → https://rdap.ss/whois/AS15169

Note: only TLDs with RDAP endpoints can be queried. If a registry does not have an RDAP endpoint yet, the lookup returns an error. Sorry, dot legacy fans.

If you run into a bug or have a feature idea, open an issue on GitHub.