At IETF90 tech staff from the RIR and ccTLD/gTLD communities held an all-day RDAP interop test. RDAP is the protocol and data specification in JSON which hopefully can replace WHOIS in the long term. It’s much more amenable to scripted services, and can exploit the REST concept.
Tom Harrison from APNIC demonstrated the APNIC/RIPE code, which is on github. This RDAP code is a part of the RIPE NCC architected WHOIS server written in Java. There are slightly diverged versions of the WHOIS part, depending on which of these two RIR communities service you access. However for RDAP strenuous efforts are being made to get back to a common definition and implementation of the protocol. If you want to explore, the APNIC code is available here and an example service can be reached from here.
This system as a whole is designed to encompass Internet Number Resource (INR), and domain-name WHOIS services, in one defined protocol. This has a huge potential to solve the problem of “who did what” and “who has what” which plagues reading WHOIS data: there are so many fragmented data sources and formats, its almost impossible to write a world-scale solution.
RDAP will mean that a well written single client can learn the data structures for both domain names and INR easily. The protocol also includes a “bootstrapping” registry function for IANA, which solves the information discover question: where do I go to learn about this resource has also plagued the WHOIS space.
WHOIS is one of the oldest Internet protocol specifications still in use. It was defined in RFC812, which is like other core definitions in the Internet Protocol suite an RFC brought into the IETF from before its existence. It underwent two subsequent revisions before finalizing in RFC3912. Its a free form protocol that simply says “whatever you get from the client is the key” -and runs directly over TCP. It is very hard to find content-distribution networks that will support an arbitrary TCP protocol. Consequently WHOIS is almost impossible to deploy in commercially managed content-distribution services worldwide, and it tends to be a centralized service for anyone who operates one, reflecting only their particular corner of the information space.
RDAP explicitly chose HTTP and HTTPS as its transport. This means it can achieve world-scale deployment via existing commercial CDN products trivially. Clients are equally easy to write because the JSON data presentation can be wrapped up with CSS or Javascript to make the entire client a web application downloaded to a browser.
JSON is a smart choice for the data in RDAP. It’s very of-the-moment so there is no shortage of skilled coders and good code to use, for development of clients and servers. It’s easy to prototype in, rapid to deploy, and since its directly supported in JavaScript it can be embedded in web browsers trivially, as well as in scripting languages like Perl and Python. With multiple implementations a problem with a new protocol is how closely everyone followed the documented standard. To help mitigate this, there is a test suite published at https://github.com/APNIC-net/rdap-conformance.
As well as the RIPE/APNIC staff testing code, LACNIC, ARIN, CNNIC (who tested a service targeting both DNS names and Internet Number Resources) and Viagenie (who wrote an RDAP test framework) were involved, along with JPRS. A few remaining issues around minor and strange corner-cases, such as error returns, were explored and will be resolved soon. They need to be: the working group has been told it has to complete its deliverables by the next IETF, and will then close.
An “interop” report is available here.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.