Ushering in the Next Generation of Root Zone Management

A little over 10 years ago, the Internet Corporation for Assigned Names and Numbers (ICANN) helped launch the Root Zone Management System (RZMS), a suite of interrelated components that modernized the management of the Domain Name System (DNS) root zone. Some of the improvements it brought included automating many phases of processing, which improved processing accuracy and reduced processing times. Another improvement was launching a self-service portal that allows managers of top-level domains (TLDs) to perform common tasks by themselves.

RZMS's origins date back to the early 2000s. While it has fulfilled its objective well, over time our needs have grown and some of the designs built into the original system have constrained our ability to evolve the platform moving forward. The advent of the New Generic Top-Level Domain (gTLD) Program significantly grew the number of TLDs in the root zone, which also changed how some of our customers work. Some organizations are now involved in managing hundreds of TLDs and need new tools to help them streamline management of their portfolios. We also see new kinds of requests that didn't exist before, like frequent updates to the signing keys for TLDs.

The ICANN organization's Engineering and Information Technology team, which develops the RZMS, took the decision to rebuild the entire platform from the ground up, to create a modern modular system that would be more adaptable to future needs. A small cross-functional project team has spent the last few years building this system, and we are now getting close to its realization and launch.

In addition to replicating all the existing functionality on a modern architecture, we've made some key changes to the system in this initial release that will provide meaningful improvements to our customers. The most notable are:

• A new contact model that identifies the people who are authorized to interact with the Internet Assigned Numbers Authority (IANA) separately from the administrative and technical contacts that are published for the general community. By distinguishing these functions, we provide significant flexibility for TLD managers to configure their roles and responsibilities in a way tailored to their organizational needs. TLD managers can also customize the number of approvals needed for each type of change request, and which representatives are authorized to approve different types of requests.
• The new model also provides important security outcomes by issuing individuals with their own accounts. We will require users of our system to log in with their credentials to approve requests, rather than our previous practice of sometimes allowing approvals by only clicking a link in an email.
• Conformance testing of TLD infrastructure, the "technical check" process, has been separated into its own independent system. Decoupling technical checks from the RZMS will allow us to evolve the technical checks (like adding new tests to identify additional problematic TLD configurations), as well as introduce performance optimizations so that tests can run faster.
• A preliminary application programming interface, which will allow TLD managers to build or use tools to programmatically communicate with our system. The initial features focus on bulk updates, so that organizations managing many TLDs can perform operations on multiple TLDs efficiently.

One of the decisions we've taken for the new contact model is to limit accounts to individuals. This means each person using the system will have their own unique username and password, rather than a shared password used by multiple people. Each TLD manager will be able to create as many accounts as needed for their representatives, and the public records (like those that appear in the WHOIS records) may continue to be role based instead of being tied to any one individual.

Future Functionality

While we think these features address the most pressing improvements our customers are asking for, we know there is more to be done. We've had to make some choices on what new functions to focus on to get this iteration of the platform finished and launched, and which to defer for later in our development road map.

One piece of deferred functionality of particular interest is multifactor authentication. We recognize there is a growing desire from some of our customers for such a feature, but we need to make sure we implement it in a careful and considered way that strengthens the security of the root zone. Multifactor authentication has many important considerations, including making sure that it works for people in any country of the world, and works for customers that we may not hear from for many years.

Part of our consideration in deferring this work and considering it more carefully is the Draft Root Zone Update Process Study. In this study, the third-party reviewer does not recommend adding traditional multifactor authentication to the root zone, and notes that some of the unique protections we have in our process already provide protections that multifactor authentication is intended to add. We think there can be a role for more multifactor authentication options in the future and expect future dialogues to properly target our work in this area.

This study identified a number of other areas for potential improvements to the root zone update process, and we'll be studying the final report more closely to inform our future work. For example, a common area of feedback reviewers received was to improve the way technical checks are performed so that detected issues that are minor don't unduly delay processing. We've been exploring ways of grading issues on severity and allowing TLD managers to dismiss potential issues by themselves when the issue is likely to have a minor impact, which should improve this greatly.

Next Steps

In preparation for this new system, IANA will be performing direct outreach to many of our customers to speak to them about the impact of the system. One of the biggest preparations is identifying how to migrate from the old contact model to the new one in a way that doesn't inconvenience anyone.

In cases where some TLDs have many different accounts, we will be looking for ways to help consolidate them under a single username and password for each individual. This includes where we may have multiple email addresses on file for the same person, working out which addresses to consolidate.

Another of the improvements to the new contact model will include tidying up the format of the postal address fields in our database. We expect to reach out to TLDs to clarify their addresses.

Beyond this discussion on rolling out the new version with our customers, we are looking forward to gathering your feedback on how the system works, and to incorporate that feedback into future releases on a regular basis.