Full RDAP service soon mandatory for generic top-level domains
Current Whois infrastructure likely to be replaced by RDAP within a few years
It now looks as if support for the Registration Data Access Protocol (RDAP) will be made mandatory for all generic top-level domains (gTLDs) in 2025. At that point, the requirement to support Whois will be dropped. The switch is part of the new Registry Agreement (RA) and Registrar Accreditation Agreement (RAA), which ICANN is in the process of finalising.
All domain name information systems are now expected to switch to RDAP over the next few years. Because the old Whois protocol has no added value that would justify running parallel systems, migration to RDAP is likely to spell the end of the road for the current Whois infrastructure.
Urgent
Information about domain names, such as name server details and registrant data, is published via Registration Data Directory Services. Such services have traditionally been accessed using the unstructured Whois protocol. However, a more modern protocol called RDAP is now available, which provides a framework for the retrieval of structured data.
All gTLDs have been obliged to operate an RDAP server since 2019. However, the plan is now to require gTLDs to support a full RDAP service to replace the existing Whois. Strict service level requirements will be introduced covering parameters such as availability, response times and data validity. At the same time, the current requirement to provide a full Whois service will be dropped.
Major commercial registries are expected to be the first to switch off their Whois systems. The rational being that operating a parallel Whois service will become an unnecessary cost item with no added value. The expectation is therefore that the Whois infrastructure will be dismantled after 2025. Consequently, there's now an urgent need to enable RDAP for all zones.
ccTLDs to follow at their own pace
SIDN enables RDAP for .amsterdam and .politieAlthough the registries for country-code domains (ccTLDs) aren't part of the ICANN regime – we're governed mainly by the IETF's RFCs – the ccTLD registries do often follow where ICANN leads, albeit at their own pace.
Because we act as the technical operator of the .amsterdam and .politie domains – gTLDs that do fall under ICANN's auspices – we introduced preliminary RDAP services for the 2 zones 3 years ago. For the .nl domain, RDAP beta is now available at rdap.sidn.nl.
RDAP service launch
The upcoming requirement to offer a full RDAP service, combined with the probable break-up of the Whois infrastructure, mean that registries, registrars and others who have built Whois-based applications will have to convert them to RDAP in the next couple of years.
The situation has given us a strong incentive to get an RDAP service for the .nl zone up and running. "We've recently completed implementation of the service, which went live this week," says Pim Pastoors, Product Manager at SIDN. "We've been using RDAP internally for a while, so we were already familiar with the technology."
Our current Whois service
Our Whois lookup service for the .nl zone is a good example of a bespoke application that needs converting to RDAP. It may be that we retain the name Whois, so that functionally speaking the service remains available. In that scenario, only the underlying technology would change.
Whether we ultimately do or don't retain the name, the upcoming moves have no immediate implications for our Whois service. "At the moment, there still isn't much interest in the RDAP services we offer for .amsterdam and .politie," says Pastoors. "And registries and registrars have several years yet to convert their applications. We won't be phasing out our Whois service until RDAP is in general use and Whois is clearly in decline. In the meantime, we'll be keeping a close eye on how the 2 services develop."
Drawback of Whois
In case you're not familiar with RDAP: the protocol is defined in RFCs 7480/7481/9082/9083/9224. It's an upgraded successor to Whois, which addresses the older protocol's drawbacks:
The Whois protocol is very simple (too simple, in fact): it has no security or authentication features at all, includes no rules on the formatting or contents of queries and responses, and doesn't support Internationalized Domain Names (IDNs). The Whois protocol is 40 years old, having been specified back in 1982.
No one has a complete, up-to-date overview of all domain name registration data. Some Whois servers are 'thick', meaning they have all the information about their domains, while others are 'thin': they merely refer enquirers to the registrar's (authoritative) server.
For third parties, the most useful information available from the Whois is the contact data. However, that data is also particularly vulnerable to abuse. That issue has been provisionally resolved by the introduction of 'domain privacy' services (where contact information is replaced by the registrar's details) and/or by rate limiting, i.e. imposing traffic caps.
The Whois protocol includes no rules on response data structure, resulting in a proliferation of minor structural and (text) formatting conventions. Even name server information can be provided in various forms. Consequently, Whois output requires human interpretation; computers can handle it only with great difficulty (scraping).
A modern protocol
RDAP is a modern protocol designed to resolve the drawbacks of Whois. Whereas Whois is a very rudimentary protocol based on the old finger principles, the RDAP protocol defines a webservice based on a RESTful interface. An RDAP server can therefore be queried via a (public) web API using the same commands used in HTTP (GET, PUT, DELETE, etc).
Another crucial difference is that an RDAP response consists of data structured in the modern, readily legible and processable JSON format, whereas Whois uses XML format, which is suitable only for machine-to-machine data exchange.
Before defining the JSON-format data fields for RDAP, the protocol's developers analysed all the information types currently provided by Whois servers. On the basis of the findings, a data format was devised to meet the needs of both domain name registries and internet number registries (RIRs and LIRs). RFC 7485 describes the methodology and findings of the inventory. Details of all RDAP response objects and data structures can be found in RFC 9083. However, that document is intended primarily for programmers; for a more accessible summary, see the RDAP JSON register maintained by IANA.
The following is the (textual) output of an RDAP information request regarding the domain sidn.nl, which can be accessed via: https://rdap.sidn.nl/domain/sidn.nl.
{
"rdapConformance": [
"icann_rdap_response_profile_0"
],
"objectClassName": "domain",
"notices": [
{
"title": "Copyright notice",
"description": [
"Auteursrechtvoorbehoud: Niets uit deze publicatie mag zonder voorafgaande uitdrukkelijke toestemming van SIDN worden verveelvoudigd, openbaar gemaakt, worden opgeslagen in een gegevensbestand of worden overgezonden, in welke vorm dan ook, elektronisch, mechanisch, door middel van opname of anderszins. Voor registrars geldt dit voorbehoud onverkort, behoudens redelijkerwijs noodzakelijke verveelvoudigingen of openbaarmakingen ten behoeve van de werkzaamheden van registrars, zoals vermeld in de 'Algemene voorwaarden voor registrars'. Elk gebruik van deze informatie voor commerciële of reclamedoeleinden of soortgelijke activiteiten, is expliciet verboden en tegen overtreding van dat verbod zal worden opgetreden. Stichting Internet Domeinregistratie Nederland (SIDN) verzoekt te worden geïnformeerd bij constatering van dergelijke activiteiten of enig vermoeden daarvan. © Stichting Internet Domeinregistratie Nederland (SIDN) Auteurswet, geschriftenbescherming (art. 10 lid 1 sub 1).",
"Copyright notice: No part of this publication may be reproduced, published, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without prior permission of the Foundation for Internet Domain Registration in the Netherlands (SIDN). These restrictions apply equally to registrars, except in that reproductions and publications are permitted insofar as they are reasonable, necessary and solely in the context of the registration activities referred to in the General Terms and Conditions for .nl Registrars. Any use of this material for advertising, targeting commercial offers or similar activities is explicitly forbidden and liable to result in legal action. Anyone who is aware or suspects that such activities are taking place is asked to inform the Foundation for Internet Domain Registration in the Netherlands. © The Foundation for Internet Domain Registration in the Netherlands (SIDN) Dutch Copyright Act, protection of authors' rights (Section 10, subsection 1, clause 1)."
]
},
{
"description": [
"Administratie door: SIDN",
"Record maintained by: SIDN"
]
}
],
"lang": "nl-NL",
"events": [
{
"eventAction": "registration",
"eventDate": "1999-11-18T12:47:20Z"
},
{
"eventAction": "last changed",
"eventDate": "2021-10-14T09:55:57Z"
},
{
"eventAction": "last update of RDAP database",
"eventDate": "2022-12-22T11:51:17Z"
}
],
"status": [
"locked"
],
"ldhName": "sidn.nl",
"secureDNS": {
"delegationSigned": true,
"dsData": [
{
"keyTag": 62949,
"algorithm": 13,
"digestType": 2,
"digest": "FBF66B8D019C1EEC2779B7DBFBFF090CA0F3704DCBD8D76AA80974186F110E91"
}
]
},
"entities": [
{
"objectClassName": "entity",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
""
],
[
"email",
{},
"text",
"support@sidn.nl"
]
]
],
"roles": [
"administrative"
]
},
{
"objectClassName": "entity",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
""
],
[
"email",
{},
"text",
"support@sidn.nl"
]
]
],
"roles": [
"technical"
]
},
{
"objectClassName": "entity",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"Stichting Internet Domeinregistratie Nederland"
],
[
"adr",
{},
"text",
[
"",
"",
"Meander 501",
"ARNHEM",
"",
"6825MD",
"NL"
]
]
]
],
"roles": [
"registrant"
]
},
{
"objectClassName": "entity",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"Stichting Internet Domeinregistratie Nederland"
],
[
"adr",
{},
"text",
[
"",
"",
"Meander 501",
"Arnhem",
"",
"6825MD",
"NL"
]
]
]
],
"entities": [
{
"objectClassName": "entity",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
""
],
[
"tel",
{
"type": "voice"
},
"text",
"+31.263525555"
],
[
"email",
{},
"text",
"abuse@sidn.nl"
]
]
],
"roles": [
"abuse"
]
}
],
"roles": [
"registrar"
]
}
],
"nameservers": [
{
"ldhName": "ns5.sidn.nl",
"unicodeName": "ns5.sidn.nl",
"ipAddresses": {
"v4": [
"145.40.68.55"
],
"v6": [
"2604:1380:4601:6300:0:0:0:1"
]
}
},
{
"ldhName": "ns3.sidn.nl",
"unicodeName": "ns3.sidn.nl",
"ipAddresses": {
"v4": [
"194.0.30.2"
],
"v6": [
"2001:678:34:0:194:0:30:2"
]
}
},
{
"ldhName": "ns4.sidn.nl",
"unicodeName": "ns4.sidn.nl",
"ipAddresses": {
"v6": [
"2001:7b8:62b:1:0:d4ff:fe72:786c"
],
"v4": [
"212.114.120.108"
]
}
}
]
}
Authentication
The final major problem with the existing directory services is that contact information can no longer be made public, because it's liable to be used for spam and cold-calling, and its publication is at odds with privacy law (GDPR). However, there are various situations where privacy-sensitive information may reasonably be made available to certain stakeholders. That's the case, for example, in the context of research, domain name/address block trading, abuse prevention and legal proceedings.
RDAP accordingly requires users to log in. An RDAP service operator can then release different types of information to authenticated users on the basis of their roles. So, for example, a police force or relevant government agency can be permitted access to contact information linked to domain names and IP addresses.
"Work on implementation of the authentication system is still in progress," says Pastoors. "It may be that you'll need to log in on a website, and that your RDAP request, complete with your credentials, is then forwarded to the appropriate authoritative RDAP server."
"That's still some way off, though. We've all got a few years yet to migrate our existing services to RDAP, after which we can start building on the new infrastructure."