Summary

  • New gTLD growth, portfolios of hundreds and frequent DNSSEC updates changed the workload RZMS had to support.
  • The rebuild added request-specific approval thresholds, concurrent requests, an API and separately evolving technical checks; those options also left TLD managers responsible for sound policy and account continuity.

Analysis

More requests changed the shape of the work

The old RZMS was not a failed system. It had automated stages of root-zone administration, improved processing accuracy and reduced handling time, while giving TLD managers a self-service portal for common tasks. The pressure came from a different workload: the new-gTLD program expanded the number of delegations, some organizations now managed portfolios in the hundreds, and DNSSEC signing-key updates arrived more often than the original design anticipated.

In May 2022, Davies said ICANN’s Engineering and Information Technology team had decided to rebuild the platform as a modular system. A small cross-functional team worked on the project over several years. His account describes the rationale and operating choices; it does not claim he was the system’s sole developer. The question was how to let the service absorb new request patterns without tying every change to one fixed workflow.

A rebuild was a change in operating assumptions

The first RZMS had already made root-zone administration faster and more accurate by automating parts of the process and giving TLD managers a self-service portal. Its limits emerged as the environment changed. The new-gTLD program increased the number of delegations; some organizations managed portfolios of hundreds; and frequent DNSSEC signing-key updates created request patterns the older design had not anticipated. Davies described the rebuild as an Engineering and IT decision, carried out by a small cross-functional team. His account sets out the operating choices; it does not make him the system’s sole builder.

That background matters. The redesign was not just a stronger password screen attached to a static service. It changed the way a TLD manager could map organizational roles onto actions. The maintained IANA changelog records the initial authorization model’s ability to name more than two approvers and set thresholds by request type. It also lists a preliminary API and support for concurrent requests. Davies’s 2022 post says technical conformance testing moved to a separate system, allowing those checks to evolve without being entangled with the request-management interface.

The model distributes control across three boundaries. A public record identifies how to contact the manager. An individual account identifies who signed in. The manager’s authorization policy determines which of its representatives may approve which class of change, and how many approvals are needed. None of those facts alone establishes that a proposed change is substantively correct. IANA describes its role as receiving and processing root-zone requests, recording technical delegation data and publishing the related registry; the root-zone overview distinguishes that registry from the separate DNS root-zone data file.

Security has a calendar and a recovery path

Multi-factor authentication did not arrive with the 2022 rebuild. Davies said it was deferred because a global system must work for users in every country and for customers who might not log in for years. The timing is revealing: a control can be technically stronger and still fail if it locks out the people needed to restore service.

An independent 2022 Root Zone Update Process Study reported that 82 percent of its survey respondents considered the existing security measures sufficient, while 18 percent described potential weaknesses; some in the latter group recommended MFA. Those figures describe that study’s respondents, not every TLD manager or a present-day risk assessment. The study also discussed the process then being open to requests from people beyond a fixed list of designated contacts. Davies cited the study while explaining why the team did not make traditional MFA an immediate blanket requirement.

The next stage came later. In January 2025, Davies announced MFA and identity verification as opt-in features. The current IANA identity-verification guidance, last revised in July 2026, now says verification is required to turn on MFA or use the RZMS API, but is not mandatory for other uses. The API itself is limited to actions a user is authorized to take; an Operational Test and Evaluation environment lets customers test integrations without changing production.

Recovery explains part of the identity requirement, but it brings a privacy cost. IANA says a third-party vendor holds submitted ID and selfie images for no more than seven days. IANA retains the user’s legal name, date of birth and verification outcome while the account remains active. That is a more precise account than saying either that the documents stay with IANA or that no personal data are retained.

Scale moves responsibility downstream

Configurable thresholds and concurrent requests make the service more adaptable, but the software cannot choose a sensible approval policy for every organization. A TLD manager must keep its roster current, decide how many people should approve each request type and preserve a recovery path for users who may sign in only occasionally. Too few approvers create a continuity bottleneck; too many can make routine maintenance wait on coordination.

The API extends that control surface to programmatic workflows, but it does not bypass a user’s permissions. IANA’s separate Operational Test and Evaluation environment lets managers test integrations before production. Technical conformance checks likewise remain distinct from authorization: a technically valid configuration does not itself authorize a request, and an approval does not replace technical review or implementation.

That boundary matters because RZMS is one part of root-zone operations. IANA assigns TLD managers, records technical delegation data and publishes the Root Zone Database; the database is distinct from the DNS root-zone file. The June 2026 changelog lists RZMS version 3.6.1. The rebuild’s lasting contribution is an adaptable workflow, not a guarantee that every organization will configure it well. Its performance now depends on whether local approval rules, account recovery and technical testing keep pace with the workload they were built to handle.

Sources