What is the Re­gis­tra­tion Data Access Protocol (RDAP)?

Until now a domain holder could be found with the help of Whois services, which is based on the protocol of the same name. However, in 2015, the IETF and ICANN es­tab­lished the first RFC of the RDAP (Re­gis­tra­tion Data Access Protocol) protocol to be the main successor to Whois.

What is the Re­gis­tra­tion Data Access Protocol (RDAP)?

The concept of the Re­gis­tra­tion Data Access Protocol (RDAP) came from a work group from the Internet En­gin­eer­ing Task Force (IETF). After a project phase of nearly four years, the first version of the protocol profile (1.0) appeared on 26 July 2016. Its char­ac­ter­ist­ics and ap­plic­a­tions are outlined in the various Requests for Comments (RFC 7480-7484 and RFC 8056). RDAP offers the pos­sib­il­ity of accessing further in­form­a­tion on basic internet resources, including

• Domain names
• IP addresses or
• Autonom­ous System Numbers (ASNs)

as well as other related articles. For this reason, the Whois al­tern­at­ive provides the basis for sending queries to the various domain re­gis­tries. This includes providing your database with, for example, contact details for the domain owners, contact details for any admins (Admin C), or even the address of the name server being used, including that of the ad­min­is­trat­or.

Why was RDAP developed?

Back in 1982 the IETF published the Whois protocol with the aim of having a request service for what at that time was called ARPANET. The fact that it is still in use a quarter of a century later, now for online queries, is something that has been a thorn in the side of many experts. Nowadays the main criticism directed at Whois is that it no longer meets the technical re­quire­ments of the internet.

One of the main problems is that the Whois protocol is incapable of working with coding, and therefore offers no support for non-Latin text. Another major downside is that access to the domain data does not take place via a secure con­nec­tion and is un­reg­u­lated. Even anonymous users get full access and can get their hands on email and postal addresses.

Projects like the Whois++ extension or the IRIS (Internet Registry In­form­a­tion Service) Denic Protocol managed to deliver some im­prove­ments, but they failed, however, to establish them­selves as a solid al­tern­at­ive to Whois. After a long time and many dis­cus­sions within the ICANN community about the necessity offurther de­vel­op­ment**, the Security and Stability Advisory Committee (SSAC) with its SAC 501 security report gave the decisive push to bring the RDAP working group to life in September 2011.

In January 2023, ICANN launched a global vote to decide whether to of­fi­cially replace WHOIS with RDAP. The required number of votes was reached, and the decision was made to of­fi­cially enforce the switch to RDAP. As of January 2025, DNS re­gis­tries and re­gis­trars will no longer be required to support WHOIS.

How does RDAP work?

In order to implement RDAP, it is important to first un­der­stand how the protocol works, both on the client and server side. For this, it is worth taking a look at RFCs 7480 to 7484, where a minimal im­ple­ment­a­tion of the protocol is described in detail. In addition, there are further RFCs where RDAP protocol ex­ten­sions are described. In the following section, we roughly explain how the protocol works via HTTPS as described in RFC 7840.

The client’s tasks:

Im­ple­ment­ing RDAP on the client side is not complex at all. RDAP is built on HTTP, and therefore uses the already existing HTTP methods to transfer data. Clients can make requests to the server using the GET and HEAD methods. Both GET and HEAD requests should include an ‘Accept’ header that specifies which types of JSON files are accepted by the client.

The server’s tasks:

Im­ple­ment­a­tion is a bit more complex on the server side, since the server has to cover quite a few special cases. If the request is suc­cess­ful, the server should return the requested data in the requested format with HTTP status code 200 (OK). On GET requests the server should respond with the requested owner data, and on HEAD requests it should indicate whether it has data available for this domain.

If it knows where the requested data is, but does not have it itself, it should respond with one of the status codes 301, 302, 303, or 307. The URL where the data can be found is then sent under the HTTP header ‘Location’.

If the server cannot process the request because the requested data is not available, it should respond with the status code 404 (Not Found). If the requested data does exist, but the server does not want to respond for some other reason, it should respond with an ap­pro­pri­ate status code from the 400 range. Requests that contain errors and therefore cannot be un­der­stood as RDAP requests should be answered with the status code 400 (Bad Request). In this case, ad­di­tion­al in­form­a­tion can be sent in the HTTP entity body.

For more detailed in­form­a­tion about the process as well as security and extension pos­sib­il­it­ies of the protocol you can refer to the cor­res­pond­ing RFCs. These are linked below.

• RFC 7840: HTTP Usage
• RFC 7841: Security Services
• RFC 7842: Query Format
• RFC 7843: JSON Responses
• RFC 7844: Finding the Au­thor­it­at­ive Re­gis­tra­tion Data

What makes the Re­gis­tra­tion Data Access Protocol different?

In many ways, the RDAP has turned out to be an improved version of Whois. The IEFT working group has con­cen­trated on the old protocol’s weak­nesses, meaning that it has focused heavily on the likes of security, struc­tur­ing, and in­ter­na­tion­al­isa­tion for the new query protocol. As a result, several new features emerged, including:

• Struc­tured request and answer semantics (including stand­ard­ised error messages)
• Secure access to the requested contact details (e.g. via HTTPS)
• Ex­pand­ab­il­ity (e.g. addition of output elements)
• ‘Boot­strap­ping’ mechanism (supported by the search for a suitable au­thor­it­at­ive DNS server)
• Stand­ard­ised query for­ward­ing
• Web-based (HTTP) and REST compliant
• Un­com­plic­ated trans­la­tion of output data
• Pos­sib­il­ity of granting dif­fer­en­ti­ated access to contact details

In many aspects, the Re­gis­tra­tion Data Access Protocol has proven itself to be much more flexible than its pre­de­cessor. While Whois, as a text-based protocol, relies on TCP and the specific TCP port (43), RDAP uses the web standard HTTP, or even HTTPS. This means that all data is delivered in a stand­ard­ised, machine-readable JSON format. This means that on the one hand, the RDAP allows for more freedom when it comes to data queries, while also making it easier to program query services that can com­mu­nic­ate with the various re­gis­tra­tion au­thor­it­ies, while out­put­ting the requested data in different languages.

Option for different types of access – still a topic for dis­cus­sion

Without a doubt one of the most important new functions that was im­ple­men­ted in the Re­gis­tra­tion Data Access Protocol is the pos­sib­il­ity to come up with different access rights for in­di­vidu­al user groups. This allows the registrar to regulate in detail who gets to see what in­form­a­tion. This allows anonymous users to only enjoy limited access, while au­thor­ised users can view the entire data set. This is an aspect where many people see a need for crucial cla­ri­fic­a­tion re­quire­ments.

One of the questions it raises, among others, is what to do about criminal pro­sec­utors, who wish to remain anonymous while sim­ul­tan­eously enjoying full access rights. Fur­ther­more, there are no guidelines regarding whether in such a case access to the domain data may also be granted to those outside of a country’s borders. Above all, the priority is the pro­tec­tion of user data and the trust in the website operator who registers the domain that comes with this. And in no way should this trust be com­prom­ised by the new RDAP request tech­no­logy. At the end of 2016, a number of re­gis­tries appealed against the im­ple­ment­a­tion period imposed by ICANN, and this has meant that the or­gan­isa­tion has decided to establish contracts for RDAP with re­gis­trars and domain providers.