On October 1, 2016, the contract between the U.S. Department of Commerce’s National Telecommunications and Information Administration (NTIA) and ICANN expired, and the IANA stewardship transition took effect. A domain lookup that day returned the same kind of information as the day before. The arrangements behind that information had changed: Public Technical Identifiers (PTI), a nonprofit ICANN affiliate, began performing the IANA functions under new service expectations and community oversight.
The transition is sometimes described as “the U.S. handing over the Internet.” That phrase suggests a transfer of ownership. The Internet was not owned by the U.S. government. What ended was NTIA’s contractual stewardship role over the IANA functions.
IANA coordinates three sets of Internet identifiers
The Internet Assigned Numbers Authority (IANA) coordinates identifiers that networks and devices need to work together. Its responsibilities cover domain names, number resources, and protocol parameters.
For domain names, IANA coordinates changes to the DNS root zone and maintains data about top-level-domain delegations. For number resources, it coordinates IP address and autonomous system number resources through the Regional Internet Registries. For protocol parameters, it maintains registries used by Internet standards. IANA’s overview describes these areas.
ICANN was already performing the IANA functions under contract before 2016. After the transition, PTI became the separate entity performing them on ICANN’s behalf. The staff processing requests continued in their roles; the organizational and accountability arrangements changed. ICANN’s overview of post-transition IANA explains the structure.
The diagram below shows how PTI, ICANN, the technical communities, and the review bodies fit into the post-transition structure.
Routine root-zone changes followed a new approval path
The DNS root zone contains delegation records for top-level domains and technical information that directs queries to the nameservers responsible for them. It is one part of the domain system behind an individual domain lookup.
Before the transition, NTIA authorization was required for changes to the root-zone management environment, including routine edits to the zone’s contents. Afterward, routine content changes no longer needed that separate approval. Requests still had to be authenticated and checked. PTI validates them and sends approved changes to Verisign, the Root Zone Maintainer, for publication. ICANN’s study of the root-zone update process describes the steps.
Major architectural changes have a separate review path. The Root Zone Evolution Review Committee (RZERC) coordinates input from relevant organizations and recommends to the ICANN Board whether proposed changes to the root-zone architecture and related systems should proceed. Routine TLD updates do not go through this committee. ICANN’s RZERC page outlines its role.
ICANN later reported that removing NTIA’s authorization step made routine root-zone changes more predictable and timely for top-level-domain managers. Its review of IANA’s post-transition operations discusses the effect.
For WhoAPI, the root zone is one layer behind the domain information people look up. It records which TLDs are delegated and where queries for them go. Registration details come from other sources, such as WHOIS or RDAP services. In our article on .web’s 14-year path to the DNS root, we followed one example of the steps before a new TLD is delegated.
The community gained ways to review performance
The transition introduced measurable service expectations for the IANA naming function. For the naming function, the Customer Standing Committee (CSC) reviews PTI’s performance reports and publishes its findings.
The CSC can seek remedial action when performance falls short. If problems remain unresolved, it can escalate them to the Country Code Names Supporting Organization (ccNSO) and the Generic Names Supporting Organization (GNSO). ICANN’s CSC overview describes the committee’s responsibilities.
The Empowered Community gained formal powers involving ICANN’s budgets, bylaws, and Board directors. These powers give the community a role in certain major decisions, alongside the CSC’s operational review of IANA’s naming service.
The change to root-zone approvals is easier to see than these accountability measures. The measures matter when service falls short: they give the communities relying on IANA a way to review performance and escalate unresolved problems.
The DNS still depends on coordination
The 2026 root-zone Key Signing Key (KSK) rollover shows the coordination involved in maintaining DNS infrastructure. The first rollover took place in 2018. On October 11, 2026, a successor key began signing the root zone. ICANN reported no signs of widespread disruption, while continuing to assess reports of issues affecting a limited number of systems. Resolver operators and technical partners had prepared for the change. ICANN’s KSK rollover page tracks the latest status.
Conclusion
A decade later, the lookup still looks the same. The oversight behind IANA’s naming function has changed: PTI performs the function under defined service expectations, and the communities that rely on it can review performance and escalate unresolved problems.
