RDAP: The Modern WHOIS Replacement

## Why WHOIS Needed a Replacement WHOIS is a protocol from 1982. It returns unstructured plain text, has no authentication, no rate limiting standard, no privacy controls, and no consistent field names across registrars and registries. Scraping WHOIS data at scale is trivially easy; interpreting it programmatically is notoriously unreliable because every registrar formats output differently. GDPR's arrival in 2018 forced a crisis. Registrars could no longer publish full personal contact data publicly. WHOIS had no mechanism to show redacted data to the general public while providing full data to authorized parties (law enforcement, IP rights holders, security researchers). The old protocol simply could not adapt. RDAP (Registration Data Access Protocol) — Registration Data Access Protocol — was standardized in RFC 7480–7484 and RFC 9083. ICANN mandated RDAP support for all gTLD registrars and registries. It solves every structural problem with WHOIS while maintaining backward semantic compatibility. ## RDAP Architecture RDAP is a REST API over HTTPS. Responses are structured JSON. Because it is HTTPS, transport is encrypted by default. Because it is REST, it is trivially consumable by any modern programming language without custom parsers. The IANA maintains a bootstrap registry that maps TLDs to their authoritative RDAP servers. When you query RDAP for `example.com`, a compliant client first checks IANA's bootstrap file to find the correct `.com` RDAP endpoint, then queries that endpoint. Bootstrap file: `https://data.iana.org/rdap/dns.json` RDAP base URLs: - `.com` / `.net`: `https://rdap.verisign.com/com/v1/` - `.org`: `https://rdap.publicinterestregistry.org/rdap/` - `.io`: `https://rdap.nic.io/` ## Querying RDAP ```bash # Simple domain lookup curl https://rdap.verisign.com/com/v1/domain/example.com | jq . # Using rdap CLI tool rdap example.com # IP address lookup (RDAP also covers IP and ASN registration data) curl https://rdap.arin.net/registry/ip/8.8.8.8 | jq . # Nameserver lookup curl https://rdap.verisign.com/com/v1/nameserver/ns1.example.com | jq . ``` ## JSON Response Structure An RDAP domain response for `example.com` looks like this (simplified): ```json { "objectClassName": "domain", "ldhName": "example.com", "handle": "2336799_DOMAIN_COM-VRSN", "status": ["client delete prohibited", "client transfer prohibited"], "nameservers": [ {"objectClassName": "nameserver", "ldhName": "a.iana-servers.net"}, {"objectClassName": "nameserver", "ldhName": "b.iana-servers.net"} ], "secureDNS": { "delegationSigned": false }, "events": [ {"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"}, {"eventAction": "last changed", "eventDate": "2023-08-14T07:01:31Z"}, {"eventAction": "expiration", "eventDate": "2024-08-13T04:00:00Z"} ], "entities": [ { "objectClassName": "entity", "roles": ["registrar"], "publicIds": [{"type": "IANA Registrar ID", "identifier": "376"}], "vcardArray": ["vcard", [["fn", {}, "text", "RESERVED-Internet Assigned Numbers Authority"]]] } ], "links": [ {"rel": "self", "href": "https://rdap.verisign.com/com/v1/domain/example.com"} ], "rdapConformance": ["rdap_level_0", "icann_rdap_response_profile_0"] } ``` Field names are standardized. `ldhName` is "letters, digits, hyphens" — the ASCII form of the domain. `handle` is the registry object ID. `entities` contains contacts (registrant, admin, tech, billing, registrar) with roles explicitly labeled. ## Access Levels and Tiered Access RDAP's major structural advance is **tiered access**. The response a client receives depends on who is asking: - **Unauthenticated**: Basic registration data, redacted contacts (compliance with GDPR and privacy regulations) - **Authenticated (registrar)**: Full registrant contact data for domains in their portfolio - **Authenticated (special purpose)**: Law enforcement, security researchers, IP rights holders may apply to registries for expanded access under ICANN's SSAD (System for Standardized Access/Disclosure) framework Authentication uses standard HTTP mechanisms — OAuth 2.0 bearer tokens or HTTP Basic Auth depending on the registry implementation. This is impossible with the plain TCP WHOIS protocol. ## Searching in RDAP Unlike WHOIS, RDAP supports search queries (where the registry exposes them): ```bash # Search domains by registrant name (if registry supports it) curl "https://rdap.example-registry.com/domains?fn=John+Doe" # Search nameservers by IP curl "https://rdap.verisign.com/com/v1/nameservers?ip=192.0.2.1" ``` Search support is optional and varies by registry. Verisign exposes nameserver IP searches for `.com`; other registries may expose domain searches for authenticated parties. ## RDAP and DNSSEC Data RDAP's `secureDNS` object exposes DNSSEC delegation status. If a domain is signed and has DS records at the parent, `delegationSigned` will be `true` and the `dsData` array will contain the DS record details (key tag, algorithm, digest type, digest). This makes RDAP the canonical API for programmatically checking DNSSEC deployment status across large domain portfolios. ```json "secureDNS": { "delegationSigned": true, "dsData": [ { "keyTag": 2371, "algorithm": 13, "digestType": 2, "digest": "1F987C..." } ] } ``` ## RDAP vs. WHOIS: Summary | Dimension | WHOIS | RDAP | |---|---|---| | Protocol | TCP port 43, plain text | HTTPS REST, JSON | | Structure | Unstructured text | Defined JSON schema | | Authentication | None | Standard HTTP auth | | Privacy tiers | None | Full tiered access model | | Internationalization | ASCII only | Full Unicode | | Machine-readable | Difficult | Native | | Mandatory for gTLDs | Yes (legacy) | Yes (since 2019) | For the underlying provisioning protocol that creates and updates domain objects, see EPP Protocol: How Registrars Communicate. For DNS Propagation visibility that RDAP tracks via nameserver records, see Anycast DNS: How Global DNS Networks Work. WHOIS Lookup Tool