RDAP protocol explained: query domain data without parsing WHOIS

RDAP (Registration Data Access Protocol) is the standardized successor to WHOIS, developed under ICANN's oversight and defined in RFC 7480 through RFC 7484 (published 2015). Where WHOIS is a plain-text protocol from 1982 with no standardized output format, RDAP is a REST API that returns JSON. That single difference eliminates an entire category of problems: fragile parsers, inconsistent field names, ambiguous date formats, and no programmatic way to distinguish between "domain doesn't exist" and "WHOIS server is down." This article explains how RDAP works, how to query it, what responses contain, and where it falls short.

Context: why RDAP replaced WHOIS

WHOIS dates to 1982 (RFC 812, later revised as RFC 954 and then RFC 3912). For a protocol that survived 40 years, it's remarkable, but it was designed for a much smaller internet with different trust assumptions. The problems accumulated over time:

• No standardized response format, every registry and registrar could format output however they chose
• No JSON support, so building applications on WHOIS required fragile text parsers
• No authentication or access control mechanisms
• No internationalization, domain names with non-ASCII characters weren't handled consistently
• Rate limiting implemented differently (or not at all) by each server

ICANN mandated the transition to RDAP for all accredited gTLD registries in 2019. Today, all major gTLD registries support RDAP: Verisign (.com, .net), PIR (.org), and the registries for .io, .app, .dev, .xyz, .co, and the vast majority of new gTLDs launched since 2013. Many ccTLDs have also adopted it (AFNIC (.fr) and DENIC (.de) are among the notable adopters) but significant coverage gaps remain, particularly in Asia and Africa.

RDAP protocol architecture

Three components make up the RDAP infrastructure:

• Authoritative registries: the organizations that maintain canonical domain data. Verisign for .com, PIR for .org, AFNIC for .fr, etc.
• IANA RDAP Bootstrap: a JSON file maintained by IANA (https://data.iana.org/rdap/dns.json) that maps each TLD to the URL of its RDAP server. This is how clients find the right server for any given TLD.
• rdap.org: a public proxy service maintained by IANA that accepts queries for any domain and routes them to the appropriate registry server automatically. Useful for quick lookups without consulting the bootstrap file.

RDAP supports several query types beyond domain lookups:

Query type	Path format
Domain	/domain/<name>
IP address	/ip/<address>
Nameserver	/nameserver/<hostname>
Registrar/registrant entity	/entity/<handle>

The RFCs that define RDAP

• RFC 7480: HTTP usage in RDAP
• RFC 7481: Security services for RDAP
• RFC 7482: Query format
• RFC 7483: JSON response format
• RFC 7484: Finding RDAP services (the bootstrap mechanism)

Querying RDAP manually

Basic queries with curl

# Check if a domain exists (200 = registered, 404 = available)
curl -s https://rdap.org/domain/example.com

# Get just the status codes
curl -s https://rdap.org/domain/example.com | jq '.status'

# Get the expiration date
curl -s https://rdap.org/domain/example.com | jq '.events[] | select(.eventAction=="expiration") | .eventDate'

# Get nameservers
curl -s https://rdap.org/domain/example.com | jq '[.nameservers[].ldhName]'

A 404 response means the domain doesn't exist in the registry, it's available to register. A 200 response returns the full domain record. Some registries return a 302 redirect to their own endpoint when queried via rdap.org.

Querying registry endpoints directly

Going directly to the registry is faster than routing through rdap.org:

# Verisign for .com (faster, no proxy)
curl -s "https://rdap.verisign.com/com/v1/domain/example.com"

# PIR for .org
curl -s "https://rdap.publicinterestregistry.org/rdap/domain/example.org"

# AFNIC for .fr
curl -s "https://rdap.nic.fr/domain/example.fr"

Structure of an RDAP response

Here's an annotated example based on example.com:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited"
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "1995-08-14T04:00:00Z"
    },
    {
      "eventAction": "expiration",
      "eventDate": "2026-08-13T04:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2023-08-14T07:01:40Z"
    }
  ],
  "nameservers": [
    { "ldhName": "a.iana-servers.net" },
    { "ldhName": "b.iana-servers.net" }
  ],
  "entities": [
    {
      "roles": ["registrar"],
      "vcardArray": ["vcard", [["fn", {}, "text", "IANA"]]]
    }
  ],
  "links": [
    {
      "rel": "self",
      "href": "https://rdap.verisign.com/com/v1/domain/example.com"
    }
  ]
}

Key fields:

• status: the array of EPP status codes. These are standardized strings, no parsing guesswork. See the domain status codes reference for what each means.
• events: the history of the domain. The expiration event gives the expiration date. The registration event gives the creation date. The last changed event tells you when the record was last modified at the registry.
• nameservers: the authoritative nameservers as ldhName (letters, digits, hyphens. ASCII-compatible encoding).
• entities: registrar and registrant information. The registrant entity is often redacted for GDPR reasons.
• links: the canonical URL for this record in the authoritative registry.

The events array: richer than a single expiration date

The events array is one of WHOIS's biggest limitations made right. WHOIS typically gives you one or two dates. RDAP's events array can contain: registration, expiration, last changed, transfer, last update of RDAP database. This historical context is what allows Domain Sentinel to detect when a domain's record was changed, the last changed timestamp updates whenever any field in the registry's record changes.

RDAP coverage: which TLDs are supported

Current state of RDAP adoption:

• Fully supported: all ICANN-accredited gTLDs, .com, .net, .org, .io, .app, .dev, .xyz, .co, .ai, .me, and several hundred new gTLDs
• Supported (notable ccTLDs): .fr (AFNIC), .de (DENIC), .uk (Nominet), .nl (SIDN), .be (DNS Belgium), .eu (EURid)
• Not yet supported: .ru, .cn, .jp, .br, many African and Asian ccTLDs, these remain WHOIS-only

The IANA bootstrap file is the authoritative reference. If a TLD appears in https://data.iana.org/rdap/dns.json, it supports RDAP.

WHOIS fallback when RDAP isn't available

Domain Sentinel automatically falls back to WHOIS for TLDs without RDAP. The data is less structured (field names and date formats vary by registry) and parsing occasionally produces incorrect results for unusual registrar configurations. The expiration date is still usually extractable, but status codes are presented as raw WHOIS text rather than standardized EPP strings.

RDAP and GDPR

Since 2018, GDPR compliance has changed what RDAP exposes for domain registrants who are natural persons in the EU. What you consistently get regardless of GDPR: registrar information, nameservers, EPP statuses, all event dates. What you often don't get: registrant name, registrant email, registrant phone, registrant postal address, these may be replaced with a placeholder like "Redacted for Privacy" or simply omitted.

For legal entities (companies), the situation is different. Company registrant data is generally still present in RDAP responses, though practices vary by registrar.

This matters for brand protection and competitive monitoring: you'll always see the operational domain data (statuses, nameservers, dates) but may not see who owns the domain if privacy is active.

Using Domain Sentinel for RDAP lookups without code

For anyone who doesn't want to run curl commands, Domain Sentinel provides a web interface that queries RDAP for any domain and displays the results in readable form: statuses translated to plain language, expiration date highlighted with days remaining, events history, nameservers, and registrar. Clicking "Add to watchlist" sets up continuous monitoring from that point.

RDAP is the public infrastructure that makes reliable, programmatic domain monitoring possible. It's why Domain Sentinel queries registries directly rather than depending on third-party data sources. For a detailed comparison of RDAP and WHOIS across multiple dimensions, the article on whois-vs-rdap covers that topic specifically.