This article originally appeared in The Domain Name Industry Brief (Volume 18, Issue 3)

Earlier this year, the Internet Engineering Task Force’s (IETF’s) Internet Engineering Steering Group (IESG) announced that several Proposed Standards related to the Registration Data Access Protocol (RDAP), including three that I co-authored, were being promoted to the prestigious designation of Internet Standard. Initially accepted as proposed standards six years ago, RFC 7480, RFC 7481, RFC 9082 and RFC 9083 now comprise the new Standard 95. RDAP allows users to access domain registration data and could one day replace its predecessor the WHOIS protocol. RDAP is designed to address some widely recognized deficiencies in the WHOIS protocol and can help improve the registration data chain of custody.

In the discussion that follows, I’ll look back at the registry data model, given the evolution from WHOIS to the RDAP protocol, and examine how the RDAP protocol can help improve upon the more traditional, WHOIS-based registry models.

Registration Data Directory Services Evolution, Part 1: The WHOIS Protocol

In 1998, Network Solutions was responsible for providing both consumer-facing registrar and back-end registry functions for the legacy .com, .net and .org generic top-level domains (gTLDs). Network Solutions collected information from domain name registrants, used that information to process domain name registration requests, and published both collected data and data derived from processing registration requests (such as expiration dates and status values) in a public-facing directory service known as WHOIS.

From Network Solution’s perspective as the registry, the chain of custody for domain name registration data involved only two parties: the registrant (or their agent) and Network Solutions. With the introduction of a Shared Registration System (SRS) in 1999, multiple registrars began to compete for domain name registration business by using the registry services operated by Network Solutions. The introduction of additional registrars and the separation of registry and registrar functions added parties to the chain of custody of domain name registration data. Information flowed from the registrant, to the registrar, and then to the registry, typically crossing multiple networks and jurisdictions, as depicted in Figure 1.

Registration Data Directory Services Evolution, Part 2: The RDAP Protocol

Over time, new gTLDs and new registries came into existence, new WHOIS services (with different output formats) were launched, and countries adopted new laws and regulations focused on protecting the personal information associated with domain name registration data. As time progressed, it became clear that WHOIS lacked several needed features, such as:

• Standardized command structures
• Output and error structures
• Support for internationalization and localization
• User identification
• Authentication and access control

The IETF made multiple attempts to add features to WHOIS to address some of these issues, but none of them were widely adopted. A possible replacement protocol known as the Internet Registry Information Service (IRIS) was standardized in 2005, but it was not widely adopted. Something else was needed, and the IETF went back to work to produce what became known as RDAP.

RDAP was specified in a series of five IETF Proposed Standard RFC documents, including the following, all of which were published in March 2015:

• RFC 7480, HTTP Usage in the Registration Data Access Protocol (RDAP)
• RFC 7481, Security Services for the Registration Data Access Protocol (RDAP)
• RFC 7482, Registration Data Access Protocol (RDAP) Query Format
• RFC 7483, JSON Responses for the Registration Data Access Protocol (RDAP)
• RFC 7484, Finding the Authoritative Registration Data (RDAP) Service

Only when RDAP was standardized did we start to see broad deployment of a possible WHOIS successor by domain name registries, domain name registrars and address registries.

The broad deployment of RDAP led to RFCs 7480 and 7481 becoming Internet Standard RFCs (part of Internet Standard 95) without modification in March 2021. As operators of registration data directory services implemented and deployed RDAP, they found places in the other specifications where minor corrections and clarifications were needed without changing the protocol itself. RFC 7482 was updated to become Internet Standard RFC 9082, which was published in June 2021. RFC 7483 was updated to become Internet Standard RFC 9083, which was also published in June 2021. All were added to Standard 95. As of the writing of this article, RFC 7484 is in the process of being reviewed and updated for elevation to Internet Standard status.

RDAP Advantages

Operators of registration data directory services who implemented RDAP can take advantage of key features not available in the WHOIS protocol. I’ve highlighted some of these important features in the table below.

Verisign and RDAP

Verisign’s RDAP service, which was originally launched as an experimental implementation several years before gaining widespread adoption, allows users to look up records in the registry database for all registered .com, .net, .name, .cc and .tv domain names. It also supports Internationalized Domain Names (IDNs).

We at Verisign were pleased not only to see the IETF recognize the importance of RDAP by elevating it to an Internet Standard, but also that the protocol became a requirement for ICANN-accredited registrars and registries as of August 2019. Widespread implementation of the RDAP protocol makes registration data more secure, stable and resilient, and we are hopeful that the community will evolve the prescribed implementation of RDAP such that the full power of this rich protocol will be deployed.

You can learn more in the RDAP Help section of the Verisign website, and access helpful documents such as the RDAP technical implementation guide and the RDAP response profile.

The post Industry Insights: RDAP Becomes Internet Standard appeared first on Verisign Blog.

For more than 30 years, the industry has used a service and protocol named WHOIS to access the data associated with domain name and internet address registration activities.

Do you need to find out who has registered a particular domain name? Use WHOIS.
Do you want to see who an Internet Protocol (IP) address has been allocated to? Use WHOIS.

WHOIS SECURITY CONCERNS

The challenge with WHOIS is that it was designed for use at a time when the community of users and service operators was much smaller and there were fewer concerns about data privacy. Today it’s possible to use WHOIS to collect personally identifiable information (PII), such as physical residence addresses, telephone numbers, and email addresses associated with an individual’s domain name and IP address registration activity. This is a cause for concern in many places where people care about personal privacy, and unfortunately, there’s no easy way to address these concerns using WHOIS because it’s an “all data is available to everyone all the time” service. Thankfully we now have new tools available in the form of the Registration Data Access Protocol (RDAP), which was designed to address the many deficiencies of WHOIS – including the lack of security services needed to provide data privacy.

HOW DO WE SCALE UP?

Like WHOIS, RDAP is a client-server protocol. Clients send a command (such as a query for domain name registration information) to an RDAP server, the server receives and processes the command, and if all is well, the server returns the result of processing the client’s command. Unlike WHOIS, RDAP gives servers the ability to vary the amount of information returned in a response based on the client’s identity and the amount of information they are authorized to see. The core RDAP security service protocol specified in RFC 7481 requires server operators to provide basic client identification and authentication services based on usernames and passwords, but this form of client access is unwieldy when clients have to maintain credentials for thousands of servers and server operators have to maintain credentials for millions of clients. A more scalable solution is needed, and can be obtained in the form of a federated authentication service.

USE ONE CREDENTIAL TO ACCESS ALL SERVICES

What is federated authentication? It’s a form of authentication in which the parties involved in using and providing a service agree to form cooperating units with third-party identity providers to create, manage and use identification credentials. If you’re familiar with how single sign-on services work you already understand the basic idea. If not, imagine a world in which you can take a username and password issued by one service and use it to access another service because the second service uses and trusts the first service to validate your username and password. It’s a great way to reduce the number of usernames and passwords that you have to acquire and remember!

There are several benefits to using a federated authentication system that makes it an obvious candidate for extending the utility of RDAP, including:

1. It allows clients to use one credential to access a multitude of services.
2. It allows server operators to provide access to clients without having to issue or maintain credentials for every individual user.
3. This type of service exists today and is being used to provide privileged client access to websites.
   RDAP is itself a web-service protocol that can be extended to use federated authentication services successfully.

Verisign Labs launched an experimental service in February 2016, to demonstrate the viability of a federated authentication system for RDAP based on a protocol called OpenID Connect.

OpenID Connect is built on top of the OAuth 2.0 protocol. The approach Verisign is taking is documented in an Internet-Draft document titled, “Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect.” The experiment can be accessed from our website at https://rdap.verisignlabs.com/; click the “Help” link on the homepage for instructions.

JOIN THE EXPERIMENT

We currently support both authenticated and unauthenticated RDAP queries for domain registration data associated with the .cc and .tv country code top-level domains (ccTLDs). Feel free to try the service using a query for a domain like “nic.tv.” You can experiment with authenticated access using your Gmail or Hotmail username and password.

• You’ll receive a very limited amount of data in response to an unauthenticated query.
• You’ll receive more data if you provide your access credentials.

We don’t return any PII, but hopefully, you’ll see how it’s possible to return more or less information based on client identity. Knowing who the client is allows the server operator to make access-control decisions based on client identity and associated levels of authorization. This information can be used to prevent disclosure of PII to unauthorized clients.

We started our Verisign Labs experiment to demonstrate the viability of an approach, and so far the news has been good. Here are some of the strides Verisign has made to date:

• The ability to use existing open source software to implement the features of OpenID Connect.
• Implemented our own identity provider (again using existing open source software) to demonstrate how clients can share information about themselves with server operators.
• Successfully integrated an identity provider developed by another ccTLD operator, and we’re currently working with Regional Internet Registry (RIR) operators to participate in the experiment and explore how these services can benefit address registry users and operators.

I’m convinced that the technology we need is available to us. Now we need more experimental implementations to help us explore the policies associated with client authorization and access control. The real benefits of a federation can only be realized when a significant number of like-minded users and operators decide to work together. We will all reap the most benefit from RDAP if we find a way to make it easy to access and use our services across operational boundaries.

GET INVOLVED

It’s important to note that there is a relatively new ICANN working group that was “tasked with analyzing the purpose of collecting, maintaining and providing access to generic top-level domain (gTLD) registration data and considering safeguards for protecting that data; determining if and why a next-generation Registration Directory Service (RDS) is needed to replace WHOIS; and creating policies, and coexistence and implementation guidance to meet those needs.” While this group’s mandate is limited to the services provided by gTLD registrars and registries, there is a very good chance that the work will also provide benefits to the users and operators of ccTLD and RIR RDAP services.

It’s well worth your time to join the group as either an active participant or observer. Additional information can be found on a wiki maintained by the working group.

The post We Need You: Industry Collaboration to Improve Registration Data Services appeared first on Verisign Blog.

In 1905, philosopher George Santayana famously noted, “Those who cannot remember the past are condemned to repeat it.” When past attempts to resolve a challenge have failed, it makes sense to consider different approaches even if they seem controversial or otherwise at odds with maintaining the status quo. Such is the case with the opportunity to make real progress in addressing the many functional issues associated with WHOIS. We need to think differently.

Over the last several years a large number of people have worked diligently to explore real alternatives in both technology and policy. On the technology front, the Internet Engineering Task Force (IETF) published a series of RFC documents in March 2015 that specify the Registration Data Access Protocol (RDAP). In 2013, ICANN formed an Expert Working Group (EWG) on generic Top-Level Domain (gTLD) Directory Services. This group produced its final report in June 2014. Both of these efforts were focused on finding new ways to provide registration data directory services by replacing WHOIS.

CURRENT DEFICIENCIES

Fast forward to October 2015 and ICANN-54. On Wednesday, Oct. 21, a session was held to discuss an ICANN proposal for an RDAP implementation profile for use by generic gTLD registries and registrars. During the session (at approximately 38:16 of the audio transcript) an ICANN staff member described a number of steps that are needed to provide “complete functionality equivalence with WHOIS.” What is the benefit of replacing WHOIS with something that is functionally equivalent – and thus functionally deficient? RFC 7482 describes the following WHOIS protocol deficiencies:

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

RECOMMENDATIONS

The EWG on gTLD Directory Services was formed in February 2013 to “define the purpose of collecting and maintaining gTLD registration data, and consider how to safeguard the data” and to “provide a proposed model for managing gTLD directory services that addresses related data accuracy and access issues, while taking into account safeguards for protecting data.” The group’s final report recommended that “a new approach be taken for registration data access, abandoning entirely anonymous access by everyone to everything in favor of a new paradigm that combines public access to some data with gated access to other data.”

RDAP was designed to address the WHOIS deficiencies and the EWG recommendations, but the proposed profile only provides the benefits of standardized command, output and error structures. The profile does not address internationalization and localization of contact information. The profile also does not include support for RDAP’s user identification, authentication and access control features. These features are needed to provide data privacy by restricting data access to appropriately authorized users. As currently written, the profile continues the practice of exposing personally identifiable information to anyone who asks. With these much-needed features excluded it would be more reasonable to defer implementation until we have clear consensus on the associated policies. No work will have to be undone in the future if we need to develop additional protocol specifications and add features later.

OUR OPPORTUNITY TO ADDRESS THE ISSUES

This issue – the plan to not include support for RDAP’s internationalization and data privacy supporting features – is where the profile is setting our industry up for failure. An RDAP implementation that fails to address the most significant issues with WHOIS turns unsolved WHOIS problems into unsolved RDAP problems, and the history of failure to resolve WHOIS deficiencies repeats itself. I’ve authored an Internet-Draft document that describes one way to address the data privacy problem. There are almost certainly other approaches worth considering. It will take time to consider our options and think through the policy implications associated with data privacy, but that would be time well spent given the evolving nature of data privacy laws and practices in the different legal jurisdictions where gTLD registries and registrars do business. The risk of conflict with these laws and practices needs to be considered to ensure that RDAP implementation, deployment and operation remains a commercially reasonable undertaking.

The profile notes that additional protocol specifications are needed to map Extensible Provisioning Protocol (EPP) domain status codes to RDAP status codes, extend RDAP search capabilities and extend RDAP to include events that describe the registrar expiration date and the date of the most recent database update. The proposed profile implementation schedule includes milestones for the availability of these specifications as RFCs in 2016, but as of today only the domain status mappings are described in an Internet-Draft. If we’re going to take the time to develop these features, why should we not take the time to address the internationalization/localization and data privacy features as well? Without these features RDAP produces little more than a JSON-encoding of today’s WHOIS data.

I’m also concerned about the approach being taken to develop the profile itself. The IETF has a long tradition of documenting protocol implementation profiles using the Internet-Draft and Informational RFC publication process. Here are a few recent examples:

• Adobe’s RTMFP Profile for Flash Communication (RFC 7425)
• Suite B Profile for Transport Layer Security (TLS) (RFC 6460)
• Suite B Profile of Certificate Management over CMS (RFC 6403)

The registry industry used the IETF process to develop the RDAP protocol specifications. We should use the same IETF process to document an RDAP implementation profile.

With RDAP we have a historic opportunity to address the most pressing WHOIS deficiencies. If we fail to take advantage of this opportunity we run the risk of RDAP becoming yet another failed attempt to replace WHOIS. ICANN will open a public comment period for their implementation profile proposal within the next few weeks. Be sure to read the proposal and share your opinions. It’s time to take a different approach.

The post As WHOIS Transitions to RDAP, How Do We Avoid the Same Mistakes? appeared first on Verisign Blog.

Benjamin Franklin once said, “By failing to prepare, you are preparing to fail.” As we consider how Internet domain and address registration data is managed and accessed in a post-WHOIS era, and given the long history of failure in addressing the shortcomings of WHOIS, it is extremely important to start preparing now for the eventual replacement of WHOIS. This is the fundamental purpose of the next Registration Operations Workshop (ROW) that is scheduled for Sunday, July 19, 2015, in Prague, Czech Republic.

ROW 2015-2 will take place at the Hilton Prague hotel, the same venue as the 93rd meeting of the Internet Engineering Task Force (IETF-93). The workshop will be dedicated to discussion and planning for development and testing deployments of the Registration Data Access Protocol (RDAP), a recent work product of the IETF that is documented in Request For Comments (RFC) documents 7480, 7481, 7482, 7483, and 7484. RDAP was designed from the beginning to address the many shortcomings of WHOIS, but we have very little experience with early-stage implementations that can be used to inform the policy decisions that need to be made. Additional information about WHOIS and RDAP can be found in my “Where Do Old Protocols Go To Die?” blog post published earlier this year.

RDAP includes a number of features that don’t exist in WHOIS. The new features include service discovery, HTTP transport, client identification and authentication, server redirection, structured queries and responses, internationalization, and access control. Experience gained in not having these features in WHOIS is helpful, but it doesn’t go very far in developing best practices based on operational experience with these new capabilities. We need to start thinking now about how to make the best use of these features to ensure that we can optimize and appropriately manage access to registration data. This workshop will help to start those discussions.

Within the next few weeks, the ROW Secretariat will announce a call for participation that will include a request for discussion topics. Here are some suggestions:

• Software availability: What kind of client and server software is either available now or planned for the near future?
• Test support: Are there any tools available to help me test my software?
• Service discovery and access: How should bootstrapping and redirection work in practice?
• Client identification and authentication: How can clients be identified and authenticated while maintaining personal privacy controls?
• Access control: How can we ensure that access is restricted to authorized clients?
• RDAP functionality: Are there any gaps in RDAP that need to be addressed by extending the protocol?
• Internationalization and localization: How can RDAP be used in a global environment of users and operators?
• Searching: How well does RDAP meet real-world search requirements?

Ongoing conversation about this and other registration operations topics takes place on the regops mailing list. Additional workshop information can be found on the regiops.net web site.

Both in-person and remote participation options will be available. Please suggest a topic for discussion, and join us in Prague to start exploring this great opportunity. Let’s not prepare to fail!

The post How Will Your Registration Data Be Managed in the Future? appeared first on Verisign Blog.

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.

The post Where Do Old Protocols Go To Die? appeared first on Verisign Blog.