Which Two Related Organizations Are Responsible for Managing the Top-Level Domain Name Space and the Root DNS Name Servers? ICANN and Verisign, Explained

ICANN and Verisign are the two related organizations responsible for managing the top-level domain name space and the root domain name system (DNS) name servers on the Internet. ICANN, the Internet Corporation for Assigned Names and Numbers, sets global naming policy and coordinates the DNS root. Verisign operates the root zone's primary name server, a.root-servers.net, under contract to ICANN, and runs the .com and .net registries. One governs; the other executes part of that governance at the infrastructure level.

That division of labor is the part most short explainers miss. ICANN does not run the root servers itself, and Verisign does not decide what top-level domains exist. The split between policy authority and operational execution is deliberate, and it is what keeps the root zone stable across 13 root server identities, more than 1,500 TLDs, and roughly 360 million registered domain names. The sections below trace how the mechanism actually works, where it breaks, and what operators can do about it.

How policy authority and zone operation split apart

The DNS root is the top of a hierarchical naming tree. A resolver that needs to find any name starts by asking a root server for the delegation of the relevant top-level domain. The root zone file itself contains delegations for every TLD, plus glue records for in-zone name servers. Whoever controls that file controls which TLDs exist and which servers are authoritative for them. That is why the file is treated as a governance artifact, not merely a technical one.

ICANN's role is to coordinate changes to the root zone through its IANA functions. When a new generic TLD is approved, or a country-code TLD changes operators, the change flows through a request, review, and authorization process before it reaches the zone. ICANN publishes the root zone management process and maintains the authoritative root zone database. Policy development happens through ICANN's supporting organizations and advisory committees, not through any single operator.

Verisign's role is narrower but operationally critical. Under a cooperative agreement with the U.S. Department of Commerce and a series of contracts with ICANN, Verisign operates the A-root server and serves as the primary root zone administrator. It generates the root zone file from IANA-authorized changes, signs the zone, and distributes it to the other root server operators. Verisign also runs the .com and .net registries, which together account for a large share of all registered names.

The plain-language version: ICANN decides what the root says, Verisign produces the signed file, and thirteen root server identities publish it.

Quantified context: the scale of the root system

The root server system is often described as 13 servers, but that number is misleading. Thirteen refers to the number of root server identities, labeled A through M, each tied to a specific IP address block for IPv4 and a separate block for IPv6. Each identity is anycast, meaning the same address is announced from many physical locations worldwide. The result is thousands of physical instances behind 13 logical addresses, which keeps latency low and absorbs attack traffic.

The root zone file itself is modest in size but large in consequence. It contains delegations for more than 1,500 top-level domains, including generic TLDs, country-code TLDs, and internationalized domain name variants. Each delegation includes the names and addresses of the TLD's authoritative name servers, plus DNSSEC key material. The zone is regenerated and published on a routine schedule, typically once per day, with emergency changes possible outside that cadence.

DNSSEC coverage at the root is effectively complete. Every TLD delegation in the root zone carries DS records, which means a validating resolver can chain trust from the root down to the TLD and onward. Verisign signs the root zone with a Key Signing Key and Zone Signing Key pair, and the trust anchor is distributed to resolvers through a separate, out-of-band channel. This is the mechanism that makes DNSSEC validation possible at all; without a signed root, no downstream validation can be trusted.

For a sense of scale, ICANN's published statistics on registered domain names put the total in the hundreds of millions, with .com alone accounting for a large fraction. The exact figures change monthly, so treat any single number as a snapshot rather than a fixed property.

Edge cases: where the split creates real friction

The most visible edge case is a TLD change of control. When a country-code TLD operator is replaced, the root zone must be updated with new name server records and DNSSEC keys. The process involves the relevant government, ICANN, and Verisign as zone administrator. Delays or disputes at the policy layer translate directly into stale delegations at the technical layer, which can leave resolvers pointing at servers that no longer hold authoritative data.

A second edge case is emergency revocation. If a TLD's name servers become compromised or unreachable, the root cannot simply delete the delegation without breaking every name under it. The practical response is to update the delegation to new servers, which requires the operator to have standby infrastructure and the policy process to move quickly. The root zone change cadence constrains how fast that can happen.

A third edge case involves the DNSSEC key rollover. The root zone's Key Signing Key must be rotated periodically, and a botched rollover can cause validating resolvers to reject the entire root. The 2018 root KSK rollover was preceded by years of preparation precisely because the failure mode is global. Operators who hard-coded the old trust anchor or skipped resolver updates faced validation failures.

A counterintuitive detail worth flagging: Verisign's operation of the A-root and its role as primary zone administrator are contractual, not inherent. The arrangement could change if ICANN renegotiated the root zone management arrangements, although the practical barriers to such a change are substantial. Do not assume the current division is permanent.

Misconceptions that mislead operators

The most common misconception is that ICANN operates the root servers. It does not. ICANN coordinates the IANA functions and sets policy, but the physical root server instances are operated by a set of organizations under a formal root server operator agreement. Verisign is one of them, and it happens to hold the A-root and the primary zone administrator role, but the other twelve identities are run by separate organizations, including universities, research networks, and military operators.

A second misconception is that Verisign controls .com pricing. Verisign sets wholesale registry fees under a contract with ICANN and subject to certain caps and approval processes, but retail prices are set by registrars. The distinction matters for anyone modeling domain costs: the registry fee is a floor, not the price you pay.

A third misconception is that the root zone is updated in real time. It is not. Changes are published on a schedule, and resolvers cache root delegations for a time-to-live defined in the zone. A new TLD or a changed delegation can take hours to propagate, and negative caching can extend that. Plan for a lag, not an instant switch.

A fourth misconception is that the 13-server limit is a technical ceiling. It is a historical artifact of UDP packet size and early operational conventions. Anycast and IPv6 have made the geographic distribution far more important than the identity count, which is why the community has repeatedly debated whether to add more identities or rely on more anycast instances per identity.

Red-flag warnings for operators:

Do not hard-code a single root server IP; use multiple identities across IPv4 and IPv6. Do not assume a TLD delegation change is instant; build in propagation and cache-expiry time. Do not skip resolver updates during a DNSSEC rollover; validation failures are global. Do not treat registry wholesale fees as retail prices; the registrar layer adds cost. Do not assume the current ICANN-Verisign arrangement is fixed; contracts and agreements change.

Comparison: governance vs. operation

The table makes the separation explicit. ICANN and Verisign are related not because they do the same work but because the work is chained: policy authorization, then zone production, then distribution. The other root operators sit at the distribution layer and have no policy authority.

Timeline: how the arrangement took shape

The timeline shows that the current arrangement is the product of a specific sequence of events, not a design handed down whole. The IANA stewardship transition in 2016 moved policy authority further from U.S. government oversight, but it did not change the operational split between ICANN and Verisign.

Practical actions for operators and architects

If you run resolvers or depend on DNS for critical services, the practical implications are concrete.

Run validating resolvers and keep DNSSEC trust anchors current; a stale anchor breaks validation for every domain. Configure resolvers to use multiple root server identities across both IPv4 and IPv6; do not rely on a single address. Monitor root zone changes that affect TLDs you depend on, and test delegation changes in a staging resolver first. Budget for propagation lag when planning TLD or registrar migrations; allow at least a day for cache expiry. Separate registry wholesale costs from registrar retail costs when modeling budgets; the layers are distinct. Track ICANN and Verisign contract renewals and policy consultations; they can change operational assumptions.

The thresholds that matter most are cache TTLs and rollover windows. Root zone delegations carry TTLs that typically range from hours to a day, so a change can take that long to be seen by a well-behaved resolver. DNSSEC rollover preparation windows are measured in years, not weeks, because a trust anchor change must propagate to every validating resolver. Reconcile those two time scales explicitly: zone changes are fast relative to trust anchor changes, and confusing them leads to outages.

Limitations and what this article does not establish

This explainer describes stable mechanisms and the division of responsibility between ICANN and Verisign. It does not provide current registration statistics, fee schedules, or contract terms, because those change and require authoritative, dated sources. It also does not cover every root server operator or every IANA function in detail. For decisions with financial or operational consequences, verify current terms directly with ICANN, Verisign, and your registrar, and consult a qualified professional where the stakes justify it.