At an Internet Engineering Task Force (IETF) conference in 2011, I was invited to participate in an informal brainstorming session on Internet routing security.
During the meeting, a researcher showed me one of his web-based tools for diagnosing routing issues. He started his demonstration with “Give me your AS number.” Plugging my Autonomous System Number (ASN) into his browser, the tool came to life with a rich set of data.
Then he said, “It only works for ASNs from ARIN.” I asked why, and he explained that all of the logic was running in the browser using Javascript, not on a back-end system, and ARIN was the only Regional Internet Registry (RIR) with a REST-based Whois service compatible with the program running in his browser. That was true. At that time, ARIN was the only RIR with such a service, and it was a proprietary system designed specifically for ARIN by ARIN.
Fast-forward five years, and now all the RIRs run such a service… the same service: the Registration Data Access Protocol (RDAP).
Why do RIRs run RDAP
RDAP was given official standards status last year by the Internet Engineering Task Force (IETF) and was quickly adopted by all the RIRs. But the IETF didn’t just design RDAP for IP network registrations and ASNs. RDAP was also designed to model the data in Domain Name Registries (DNRs) and has extension mechanisms for other registry types. Extensions have already been defined for ENUM registries (which are DNRs for telephone numbers), and work is beginning on using it for routing registries as well.
Where WHOIS uses a special-use port and protocol, RDAP uses HTTP/HTTPS. Where WHOIS has a myriad of encoding schemes, RDAP uses the well-understood JSON format. Where WHOIS has a data model for every registry, RDAP defines one data model. And where WHOIS has no provisions for authentication, bootstrapping, or internationalization, RDAP has answers for them all.
Of course, this article could describe the technical merits and benefits of each one of those items, but doing so would help obscure a more meaningful point: by adopting one single standard, the effort to create tools which need this data has been made much easier. And it’s those tools, providing solutions for problems unforeseen by the protocol wizards and policy wonks that created RDAP, that can help change how the ‘internals’ of the Internet operate.
Using the WHOIS protocol, software developers have a much more difficult effort with regards to obtaining data from registries. They must craft special code for almost each registry.
By contrast, RDAP is easier because there is one data model. And the programming model is easier too because it is web-based. Software developers do not need to worry about lower-level network connections, which are often unavailable in some constrained programming environments. The web-based, RESTful encoding with JSON employed by RDAP can be accessed with built-in application programming interfaces available on all modern platforms: server, desktop, web, and mobile.
Creating tools for RDAP
Back in 2010 when ARIN first fielded its pilot, web-based, REST service containing Whois data, an analysis of the web logs after a few short months yielded some surprising results: a large number of the queries came from custom programs, many of them being browser-based applications. In other words, people had created tools around the service in a short amount of time.
The same is true of RDAP. Tools making use of it are popping up in all forms. Earlier this year I had a similar experience to the one I mentioned from five years ago. This time, it was the fine folks from APNIC Labs, and this time, their tool (vizAS) worked with any ASN from any RIR because it uses RDAP.
Check out vizAS: a tool for exploring the interconnections between AS numbers within a single economy, and a comparison of the state of interconnections between the IPv4 and IPv6 address families.
As DNRs start to field RDAP services, the opportunity for tooling becomes greater. Network abuse researchers have talked to me about tools that make use of RDAP for both types of data: coordinating observations of network abuse between the registration information of domain names and IP networks.
And some anti-spam researchers have figured out a way to use RDAP to enhance domain reputation scores. As more Top Level Domain (TLD) operators support RDAP, the ability for spammers to hide behind bad domains will become harder (and the TLDs without RDAP service may get bad reputations themselves).
Going forward, it is hard to predict what other tools may surface which use RDAP. But then again, that’s the whole point. RDAP is an enabling technology for network metadata, and the utility it may bring cannot be foreseen but should not be overlooked.
Andy Newton is Chief Engineer at the American Registry for Internet Numbers (ARIN)
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.