What is the Registration Data Access Protocol (RDAP)?
Until now the holder of a domain 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 established the first RFC of the RDAP (Registration Data Access Protocol) protocol to be the main successor to Whois.
What is the Registration Data Access Protocol (RDAP)?¶
The concept of the Registration Data Access Protocol (RDAP) came from a work group from the Internet Engineering 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, whose characteristics and applications are outlined in the various Requests for Comments (RFC 7480-7484 and RFC 8056). RDAP offers the possibility of accessing further information on basic internet resources, including
- Domain names
- IP addresses or
- Autonomous System Numbers (ASNs)
as well as other related articles. For this reason, the Whois alternative provides the basis for sending queries to the various domain registries. 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 administrator.
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 requirements 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 connection and is unregulated. Even anonymous users get full access and can get their hands on e-mail and postal addresses.
Projects like the Whois++ extension or the IRIS (Internet Registry Information Service) Denic Protocol managed to deliver some improvements, however failed to establish themselves as a solid alternative to Whois. After a long time and many discussions within the ICANN community later on the necessity of further development, in September 2011 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 January 2023, ICANN launched a global vote to decide whether to officially replace WHOIS with RDAP. The required number of votes was reached, and the decision was made to officially enforce the switch to RDAP. As of January 2025, DNS registries and registrars will no longer be required to support WHOIS.
How does RDAP work?¶
In order to implement RDAP, it is important to first understand 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 implementation of the protocol is described in detail. In addition, there are further RFCs where RDAP protocol extensions are described. In the following section, we roughly explain how the protocol works via HTTPS as described in RFC 7840.
To facilitate the implementation of the protocol for developers, ICANN has provided an RDAP Implementation Guide.
The client’s tasks:
Implementing 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:
Implementation is a bit more complex on the server side, since the server has to cover quite a few special cases. If the request is successful, 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 appropriate status code from the 400 range. Requests that contain errors and therefore cannot be understood as RDAP requests should be answered with the status code 400 (Bad Request). In this case, additional information can be sent in the HTTP entity body.
For more detailed information about the process as well as security and extension possibilities of the protocol you can refer to the corresponding 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 Authoritative Registration Data
What makes the Registration Data Access Protocol different?¶
In many ways, the RDAP has turned out to be an improved version of Whois. The IEFT working group has concentrated on the old protocol’s weaknesses, meaning that it has focused heavily on the likes of security, structuring, and internationalization for the new query protocol. As a result, several new features emerged, including:
- Structured request and answer semantics (including standardized error messages)
- Secure access to the requested contact details (e.g. via HTTPS)
- Expandability (e.g. addition of output elements)
- “Bootstrapping” mechanism (supported by the search for a suitable authoritative DNS server)
- Standardized forwarding of queries
- Web-based (HTTP) and REST compliant
- Uncomplicated translation of output data
- Possibility of granting differentiated access to contact details
In many aspects, the Registration Data Access Protocol has proven itself to be much more flexible than its predecessor. 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 standardized, 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 communicate with the various registration authorities, while outputting the requested data in different languages.
| RDAP | Whois |
|---|---|
| HTTP-based | text-based |
| Standardized JSON format | No coding schemata |
| Output data is machine-readable and can be translated uncomplicatedly | Output data is in plain data and therefore cannot be further processed automatically |
| Responses are automatically sent to other registries | Responses contain no follow-on registry information |
| Possible to define access rights for different groups | Different types of access to data not possible |
Your very own .ca domain name!
Find your perfect domain name including SSL and a personal consultant!
Option for different types of access – still a topic for discussion¶
Without a doubt one of the most important new functions that was implemented in the Registration Data Access Protocol is the possibility to come up with different access rights for individual user groups. This allows the registrar to regulate in detail who gets to see what information. This allows anonymous users to only enjoy limited access, while authorized users can view the entire data set. This is an aspect where many people see a need for crucial clarification requirements.
One of the questions it raises, among others, is what to do about criminal prosecutors, who wish to remain anonymous while simultaneously enjoying full access rights. Furthermore, 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 protection 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 compromised by the new RDAP request technology. At the end of 2016, a number of registries appealed against the implementation period imposed by the ICANN, and this has meant that the organization has decided to establish contracts for RDAP with registrars and domain providers.
Related articles
What is cybersquatting?
Have you tried to register your brand’s domain, only to find it’s already taken? You might be dealing with cybersquatting, a malicious practice that violates name or trademark rights, often leading to legal disputes. We’ll explain cybersquatters’ tactics, discuss cybersquatting examples and types of cybersquatting, and reveal how you can protect yourself.
Owner, Admin-C, and Tech-C: requirements in domain registration
Admin-C, Tech-C, and Zone-C – these roles are all related to domain registration. They represent the important points of contact in domain operations, and their contact details can be found on every Whois entry. But what do these positions actually involve? Who are they filled by? And what rights do the Admin-C, Tech-C, and Zone-C really have?
