RDAP
The Registration Data Access Protocol (RDAP) is the successor to the Whois protocol. This IETF-developed protocol enables users to access current registration data.
Overview
RDAP delivers registration data like Whois, but unlike Whois, it can support internationalization and secure, differentiated access. The gTLD RDAP Profile, developed by ICANN, registries, and registrars, meets the requirements of the Temporary Specification for gTLD Registration Data.[1]
RDAP specifications
RDAP encompasses a set of uniform patterns for querying registration data using a RESTful web service that is implemented using the Hypertext Transfer Protocol (HTTP). RFC 7482 identified deficiencies of the Whois protocol and outlined how RDAP is meant to address the lack of:
- Standardized command structures:
- To develop an RDAP client, configure it to send HTTP requests to https://rdap.org/<type>/<object>, where <type> is the object type and <object> is the object identifier;
- Standardized output and error structures:
- HTTP Status Codes include
- 302 – occurs when RDAP.org knows of an RDAP service that is authoritative for the requested resource
- 400 – occurs when RDAP.org receives an invalid request
- 404 – occurs when RDAP.org doesn’t know of an RDAP service that is authoritative for the requested resource
- 429 – occurs if you have exceeded the rate limits
- 500 – occurs when RDAP.org is broken in some way
- 504 – occurs if RDAP.org needs to refresh the IANA bootstrap registry, but cannot;
- and
- Support for internationalization, localization, user identification, authentication, and access control.
RDAP is specified as a suite Internet Request for Comments (RFC) documents.
- RFC 7480 – HTTP Usage in the Registration Data Access Protocol (RDAP)
- RFC 7481 – Security Services for the Registration Data Access Protocol (RDAP)
- RFC 7482 – Registration Data Access Protocol (RDAP) Query Format
- RFC 7483 – JSON Responses for the Registration Data Access Protocol (RDAP)
- RFC 7484 – Finding the Authoritative Registration Data (RDAP) Service
- RFC 7485 – Inventory and Analysis of WHOIS Registration Objects
The IETF purposefully avoided encompassing all of the methods employed in Whois and other RESTful web services used by RIRs and registries. IETF expects all registries to continue maintaining Whois and other RESTful web services based on their constituencies’ needs. RDAP is able to accommodate custom extensions,[2] and its reliance on HTTP means it can accommodate mechanisms for servers to authenticate clients and for clients to authenticate servers. RFC 7481 describes such RDAP-supported authentication mechanisms.[3]
The intent of RDAP is limited to offering a searchable directory of:
- networks by IP address,
- autonomous system numbers by number,
- reverse DNS metadata by domain,
- nameservers by name,
- registrars by name; and
- contacts information by identifier.
RDAP vs Whois
On the APNIC blog, George Michaelson asked whether RDAP is ready to replace Whois and summarized the pros and cons of the two registration data delivery services.[4]
| Aspects | RDAP | WHOIS |
|---|---|---|
| data representation | machine-readable | generally read-only |
| authentification | differentiated access | |
| query | Structured request and response semantics | |
| scripts | ASCII and non-ASCII | ASCII |
| time frame | RFC in 2015, implemented in 2019 | RFC in 1982 – present |
| distribution | TCP/Port 43 | HTTP/HTTPS |
| multilanguage model | UTF-8 | none |
| IRRs | RPKI signed data model | RPSL model |
| Programming language | JSON | |
| directory | Bootstrap | |
| deployment | 100% at the RIR-level, but not ready for public listing services | 100% |
For more information, visit Gavin Brown's dashboard, which is keeping track of [[TLD]s' deployment of port 43, RDAP, HTTPS, DNSSEC, and DANE.