Registration Data Access Protocol

From ICANNWiki
Jump to navigation Jump to search

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 | edit source]

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 | edit source]

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 | edit source]

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.

Implementation[edit | edit source]

On April 30, 2023, the ICANN Board directed ICANN Org to implement the RDAP Global Amendments, which specify operational requirements for providing RDDS via RDAP and sunset obligations for registries and registrars to use the WHOIS protocol by January 28, 2025. This will improve the WHOIS system by updating the underlying technology with the more secure and capable RDAP, which offers standardized queries, secure access to data, extensibility, differentiated access, support for internationalization of registration data, and the ability to search for objects. The ICANN Board carefully reviewed the proposed changes and is confident that the global amendments will lead to a better registration data query experience for contracted parties and the public.[7]

References[edit | edit source]