Registration Data Access Protocol
The Registration Data Access Protocol (RDAP) is the successor to the Whois protocol. This IETF-developed protocol enables users to access current registration data. The RDAP protocol makes access to data from the WHOIS system more secure. It includes standardized queries, secure access to data, extensibility, differentiated access, support for internationalization of registration data, and enabling search for objects. The scalable technical architecture can accommodate new and future policy-driven functionality requirements. All contracted parties have been required to provide RDDS over RDAP for all gTLD domain names since 26 August 2019.[1] On April 30, 2023, the ICANN Board directed the ICANN Organization to implement the RDAP Global Amendments to the gTLD Registry Agreement (RA), Specification 13, and 2013 Registrar Accreditation Agreement (RAA). The global amendments specify operational requirements for providing Registration Data Directory Services (RDDS) via RDAP and detail the sunset of certain obligations for registries and registrars by 28 January 2025.[2]
Overview edit
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.[3]
RDAP specifications edit
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,[4] 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.[5]
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 edit
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.[6]
| 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 TLDs' deployment of port 43, RDAP, HTTPS, DNSSEC, and DANE.