RDAP versus WHOIS for domain registration data

WHOIS is a very small protocol. A client opens a TCP connection to port 43, sends one line of text, and reads until the server closes the connection. The specification says the reply is meant to be human readable, and it defines no field layout and no way to declare the character set ¹. Two registries can describe the same fact in different words, so every consumer ends up writing one parser per server.

RDAP keeps the idea (ask a registry about a registered object) and replaces the transport and the format. Queries are ordinary HTTP GET requests, clients and servers must support HTTPS, the reply carries an RDAP JSON media type, and a server with no matching record answers 404 ². Rate limiting is a plain 429 ². Those are the same status codes the rest of your stack already handles.

There is no single RDAP server. IANA publishes a bootstrap file for domain names at data.iana.org/rdap/dns.json, and RFC 9224 defines how to use it ⁵. The file holds a version, a publication timestamp and a services array. Each service is a pair: a list of labels, then a list of base URLs ⁵⁶. When we read the live file its publication field was 2026-09-30T23:00:03Z, and its first entries pair a country code label with a single base URL ⁶.

The client matches the queried name against the labels from right to left and takes the most specific match. If a service lists both HTTPS and HTTP URLs, the secure one is tried first ⁵. RFC 9224 replaces RFC 7484, which described the same bootstrap idea ⁷. A top-level domain with no entry has no published RDAP service, so a client cannot look it up this way.

The domain object class in RFC 9083 (which replaces RFC 7483) carries a name in letters, digits and hyphens, an array of status strings, a list of events and a list of entities ⁴. Each event has an action and a date. The registered actions we rely on are registration, last changed and expiration ⁴. An entity has roles, and the registrar role names the authority responsible for the registration in the registry. Contact details inside an entity use jCard, where the name member is required but may be empty if the name is missing or redacted ⁴.

Our domain age lookup downloads the IANA file, keeps it in memory for a day, and uses the last label of the domain to pick the registry server. It lowercases the name, converts an internationalized name to punycode, and drops a leading www. It has no public suffix list, so a deeper subdomain is queried as written and comes back not found with a hint to look up the registered domain.

• A registry 404 returns not found, and a top-level domain with no RDAP service also returns not found with that reason.
• A rate limit, an outage or a network failure returns unavailable, never not found, so a registry problem is not cached as an unregistered domain.
• It tries each listed server for the label, secure URLs first.

The request below uses the same body the docs use. The reply shown after it is a captured example from our test run for example.com, which is a reserved domain.

1curl -X POST https://YOUR_API_HOST/v1/domain-age \
2  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"domain":"example.com"}'

1{
2  "domain": "example.com",
3  "registered": true,
4  "created_at": "1995-08-14T04:00:00.000Z",
5  "age_days": 11387,
6  "expires_at": "2027-08-13T04:00:00.000Z",
7  "registrar": "RESERVED-Internet Assigned Numbers Authority",
8  "rdap_server": "https://rdap.verisign.com/com/v1/"
9}

The age is counted from the time the answer was computed, so a cached answer keeps its original number. Registration facts do not say who runs a site or whether it is trustworthy. They tell you how long a name has existed and which registrar holds it, which is a useful input next to other signals. Run one in the browser with the domain age checker, read the RDAP glossary entry, or start from the quickstart.