Home / Blogs

Where Do Old Protocols Go To Die?

In Ripley Scott’s classic 1982 science fiction film Blade Runner, replicant Roy Batty (portrayed by Rutger Hauer) delivers this soliloquy:

“I’ve…seen things you people wouldn’t believe… Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those… moments… will be lost in time, like (cough) tears… in… rain. Time… to die.”

The WHOIS protocol was first published as RFC 812 in March 1982—almost 33 years ago. It was designed for use in a simpler time when the community of Internet users was much smaller. WHOIS eventually became the default registration data directory for the Domain Name System (DNS). As interest in domain names and the DNS has grown over time, attempts have been made to add new features to WHOIS. None of these attempts have been successful, and to this day we struggle with trying to make WHOIS do things it was never designed to do.

In 2013, ICANN chartered an Expert Working Group (EWG) to challenge our assumptions and recommend a new approach to registration data management. The EWG delivered its final report at ICANN-50 in June, 2014. A key component of the group’s recommendation was to abandon WHOIS and focus instead on a new protocol that was being designed from the ground-up to address the deficiencies of WHOIS. That protocol is known as the Registration Data Access Protocol, or RDAP.

On Jan. 1, 2015, the Internet Engineering Steering Group (IESG) announced their approval of a number of Internet-Draft documents that specify RDAP for publication as Proposed Standard RFCs. This is important because it’s another step in the direction of addressing the many issues associated with the WHOIS protocol, including:

  • lack of standardized command structures,
  • lack of standardized output and error structures,
  • lack of support for internationalization and localization, and
  • lack of support for user identification, authentication, and access control

In 2010 and 2011 the Internet address registries (ARIN, RIPE, etc.) started to experiment with serving registration data over a RESTful web interface. Their efforts led to the formation of the Web Extensible Internet Registration Data Service (WEIRDS) working group in the Internet Engineering Task Force (IETF) in April 2012. The WEIRDS working group assumed responsibility for the development of a standard web interface and protocol for access to registration data, which became RDAP. RDAP includes five core protocol specifications (links go to the approved Internet-Draft documents):

  1. Finding the Authoritative Registration Data (RDAP) Service
  2. Registration Data Access Protocol Query Format
  3. JSON Responses for the Registration Data Access Protocol (RDAP)
  4. HTTP usage in the Registration Data Access Protocol (RDAP)
  5. Security Services for the Registration Data Access Protocol

The working group also published a document titled "Registration Data Access Protocol Object Inventory Analysis" to survey the data elements published by the community of WHOIS operators. We wanted to do our best to capture information about the data elements exposed by WHOIS server operators. This document will be published as an Informational RFC.

All of the working group documents are now in the RFC Editor’s queue for RFC publication. RFC documents should be published within a few months.

Most interestingly, ICANN has included provisions in recent contracts that require registries and registrars to implement RDAP. This is the text from the 2013 Registrar Accreditation Agreement:

“Following the publication by the IETF of a Proposed Standard, Draft Standard or Internet Standard and any revisions thereto (as specified in RFC 2026) relating to the web-based directory service as specified in the IETF Web Extensible Internet Registration Data Service working group, Registrar shall implement the directory service specified in any such standard (or any revision thereto) no later than 135 days after such implementation is requested by ICANN.”

...and this is the text from the

2013 new gTLD registry agreement


“Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty—five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.”

Roy Batty knew when his time had come. There comes a time for outdated Internet protocols to “die”, too, but the path to the old protocol burial ground isn’t well marked. Over the next few years there is going to be a lot of interim development and discussion about if, how, and when RDAP can be developed, deployed, and operated—and how the “time to die” soliloquy for WHOIS might ultimately be written.

By Scott Hollenbeck, Fellow at Verisign

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix


Sponsored byVerisign


Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC