Access control is the cherry on the RDAP cake

RDAP v. Whois

The Whois protocol is more than 40 years old and seriously outdated. It has no authentication or security features at all, there are no rules on the formatting or contents of queries and responses, and it doesn't support Internationalized Domain Names (IDNs). Over the years, some of those shortcomings have been addressed by workarounds such as 'domain privacy' services, rate limiting and regular expressions, but these are merely makeshift solutions. The system also lacks a complete, up-to-date overview of all domain name information. What's more, its availability will become an issue once the phase-out of Whois begins in 2025. Any gTLD operators that continue to provide Whois services beyond that date will have to ensure that they continue to meet all ICANN's SLA requirements.

RDAP is a modern protocol designed to resolve the drawbacks of Whois as far as possible. The crucial differences between RDAP and Whois are that RDAP is accessed as a web service, and that its structured output data uses the readily readable and processable JSON format.

Another important feature of RDAP is tiered access control. If you're not logged in, you can only see basic data. When you are logged in, the additional information available to you depends on your status. A police force, for example, has greater access rights than a registrar. The rollout of access control will form phase 2 of our RDAP implementation. That will involve adding support to the software, and in due course registering all users and providing them with logins.

Mandatory

We've provided RDAP services for the .amsterdam and .politie domains since 2019, handling the technical administration in house. Because those are generic top-level domains (gTLDs), the services fall under the ICANN regime, in the context of which RDAP was mandatory at that time.

Shortly after introducing those services, we began offering an experimental RDAP service for the .nl zone. Country-code domains (ccTLDs) don't have to follow ICANN's rules, and therefore have much more scope for defining their own policies, guided mainly by RFCs published by the IETF. "Naturally, our implementation was aligned with the relevant RFCs," says Product Owner Martijn Sanders. "We used the leeway allowed by the RFCs to make various adaptations, so that we could also validate our software against ICANN's compliance tool."

RDDS in transition

The current infrastructure of our Registration Data Directory Services (RDDS) clearly illustrates that we're in the midst of a transition. In order to protect confidential information, we previously set up multiple Whois systems, which run in parallel, each protected by its own IP address whitelist. We have in effect created our own tiered access system, where the Whois data accessible to the general public is not the same as that accessible to registrars, for example. We're using the same IP address whitelists to protect our RDAP systems until access control functionality is added.

The RDAP infrastructure also forms the basis for the information currently provided by our Whois systems. The existing Whois servers are merely a Whois front end, which interfaces with the RDAP systems by means of middleware.

"Our main reason for wanting to move ahead with phase 2 of the RDAP implementation is the IP address whitelists," says Sanders. "Reliance on whitelists implies all sorts of restrictions. For example, a user can't log in from any location other than their normal place of work. Keeping the lists up-to-date is also a labour-intensive task, even though we've created a little tool that simplifies the job of updating the firewall settings when an IP address needs to be added or removed."

A million queries a minute

Last spring, the RDAP service for .nl became formally operational, albeit without any access control features. The RDAP services for .politie and .amsterdam have been live since 2019 but will soon be updated with our latest release. "At this stage, our main aim is to see how our RDAP implementation performs," Sanders continues. "That's important because our domain information systems sometimes receive a million queries minute. The high traffic volumes are generated by drop-catchers continually polling existing domain names that are due to be released for re-registration. Drop-catchers are particularly interested in popular names like computer.nl and fietsenwinkel.nl. We try to manage the traffic levels using SLAs and rate limits, but registrars find all sorts of workarounds. One is to send queries from the cloud, and then immediately make a registration from their own system when a domain name is released. However, our firewall will see a flood of queries as a major DDoS attack, and will pull up the drawbridge in response. Unfortunately, when that DDoS filtering mechanism kicks in, the whole service becomes unavailable for a while."

"At the moment, it's very difficult for us to properly control inappropriate use of the systems. Although our RDAP implementation seems capable of handling the high volumes of queries with just the occasional hiccough, the traffic generated by drop-catchers does create problems for other users. With Hello Registry (the new name for Fury), it's possible to set up a separate environment for registering newly released domain names. If we go down that path, drop-catchers won't have any reason to use RDAP to check a domain name's availability, so their activities will have much less impact on our services. Instead of 50 million queries a day, RDAP would have to process no more than 100,000. We're currently considering the best way of realising a set-up like that for .nl domain names."

"The Hello Registry platform has its own RDAP implementation. Next year, we'll decide whether to press ahead with the RDAP software we developed ourselves, or to switch to the Hello Registry RDAP system, and help to refine the functionality of that. Once that decision has been made, we can get to work on RDAP access control."