Hubbry Logo
DNS root zoneDNS root zoneMain
Open search
DNS root zone
Community hub
DNS root zone
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
DNS root zone
DNS root zone
DNS root zone
View on Wikipedia
from Wikipedia

The DNS root zone is the top-level DNS zone in the hierarchical namespace of the Domain Name System (DNS) of the Internet.

Before October 1, 2016, the root zone had been overseen by the Internet Corporation for Assigned Names and Numbers (ICANN) which delegates the management to a subsidiary acting as the Internet Assigned Numbers Authority (IANA).[1] Distribution services are provided by Verisign. Prior to this, ICANN performed management responsibility under oversight of the National Telecommunications and Information Administration (NTIA), an agency of the United States Department of Commerce.[2] Oversight responsibility transitioned to the global stakeholder community represented within ICANN's governance structures.

A combination of limits in the DNS definition and in certain protocols, namely the practical size of unfragmented User Datagram Protocol[2] (UDP) packets, resulted in a practical maximum of 13 root name server addresses that can be accommodated in DNS name query responses. However the root zone is serviced by several hundred servers at over 130 locations in many countries.[3][4]

Initialization of DNS service

[edit]

The DNS root zone is served by thirteen root server clusters which are authoritative for queries to the top-level domains of the Internet.[5][6] Thus, every name resolution either starts with a query to a root server or uses information that was once obtained from a root server.

The root servers clusters have the official names a.root-servers.net to m.root-servers.net.[6] To resolve these names into addresses, a DNS resolver must first find an authoritative server for the net zone. To avoid this circular dependency, the address of at least one root server must be known for bootstrapping access to the DNS. For this purpose, operating systems or DNS servers or resolver software packages typically include a file with all addresses of the DNS root servers. Even if the IP addresses of some root servers change, at least one is needed to retrieve the current list of all name servers. This address file is called named.cache in the BIND name server reference implementation. The current official version is distributed by ICANN's InterNIC.[7]

With the address of a single functioning root server, all other DNS information may be discovered recursively, and information about any domain name may be found.

Redundancy and diversity

[edit]

The root DNS servers are essential to the function of the Internet, as most Internet services, such as the World Wide Web and email, are based on domain names. The DNS servers are potential points of failure for the entire Internet. For this reason, multiple root servers are distributed worldwide.[8] The DNS packet size of 512 octets limits a DNS response to thirteen addresses, until protocol extensions (see Extension Mechanisms for DNS) lifted this restriction.[9] While it is possible to fit more entries into a packet of this size when using label compression, thirteen was chosen as a reliable limit. Since the introduction of IPv6, the successor Internet Protocol to IPv4, previous practices are being modified and extra space is filled with IPv6 name servers.

The root name servers are hosted in multiple secure sites with high-bandwidth access to accommodate the traffic load. At first, all of these installations were located in the United States; however, the distribution has shifted and this is no longer the case.[10] Usually each DNS server installation at a given site is a cluster of computers with load-balancing routers.[9] A comprehensive list of servers, their locations, and properties is available at https://root-servers.org/. As of 24 June 2023, there were 1708 root servers worldwide.[11]

The modern trend is to use anycast addressing and routing to provide resilience and load balancing across a wide geographic area. For example, the j.root-servers.net server, maintained by Verisign, is represented by 104 (as of January 2016) individual server systems located around the world, which can be queried using anycast addressing.[12]

Management

[edit]

The content of the Internet root zone file is coordinated by a subsidiary of ICANN which performs the Internet Assigned Numbers Authority (IANA) functions. Verisign generates and distributes the zone file to the various root server operators.

In 1997, when the Internet was transferred from U.S. government control to private hands, NTIA exercised stewardship over the root zone. A 1998 Commerce Department document stated the agency was "committed to a transition that will allow the private sector to take leadership for DNS management" by the year 2000, however, no steps to make the transition happen were taken. In March 2014, NTIA announced it would transition its stewardship to a "global stakeholder community".[5]

According to Assistant Secretary of Commerce for Communications and Information, Lawrence E. Strickling, March 2014 was the right time to start a transition of the role to the global Internet community. The move came after pressure in the fallout of revelations that the United States and its allies had engaged in surveillance. The chairman of the board of ICANN denied the two were connected, however, and said the transition process had been ongoing for a long time. ICANN president Fadi Chehadé called the move historic and said that ICANN would move toward multi-stakeholder control. Various prominent figures in Internet history not affiliated with ICANN also applauded the move.[5]

NTIA's announcement did not immediately affect how ICANN performs its role.[5][13] On March 11, 2016, NTIA announced that it had received a proposed plan to transition its stewardship role over the root zone, and would review it in the next 90 days.[14]

The proposal was adopted, and ICANN's renewed contract to perform the IANA function lapsed on September 30, 2016, resulting in the transition of oversight responsibility to the global stakeholder community represented within ICANN's governance structures. As a component of the transition plan,[15] it created a new subsidiary called Public Technical Identifiers (PTI) to perform the IANA functions which include managing the DNS root zone.

Data protection of the root zone

[edit]

Signing of the root zone

[edit]

Since July 2010, the root zone has been signed with a DNSSEC signature,[16] providing a single trust anchor for the Domain Name System that can in turn be used to provide a trust anchor for other public key infrastructure (PKI). The root zone DNSKEY section is re-signed periodically with the root zone key signing key performed in a verifiable manner in front of witnesses in a key signing ceremony.[17][18] The KSK2017 with ID 20326 is valid as of 2020.

ZONEMD record

[edit]

While the root zone file is signed with DNSSEC, some DNS records, such as NS records, are not covered by DNSSEC signatures. To address this weakness, a new DNS Resource Record, called ZONEMD, was introduced in RFC 8976. ZONEMD doesn't replace DNSSEC. ZONEMD and DNSSEC must be used together to ensure the full protection of the DNS root zone file.[19][20]

The ZONEMD deployment for the DNS root zone was completed on December 6, 2023.[21]

DNS over TLS

[edit]

The B-Root DNS servers offer experimental support for DNS over TLS (DoT) on port 853.[22]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

DNS root zone

View on Grokipedia
from Grokipedia
The DNS root zone is the highest level in the (DNS) hierarchy, consisting of the authoritative database that delegates to all top-level domains (TLDs), such as .com and country-code domains like .uk, enabling the resolution of domain names to IP addresses across the . It holds referral records pointing to the name servers of TLD registries, forming the foundational without which DNS queries could not propagate downward to specific domains. This zone ensures a single, unique root for the global DNS, a design principle rooted in the system's technical architecture to maintain consistency and prevent fragmentation in name resolution. Management of the root zone falls to the (IANA), which assigns TLD operators, processes change requests, and maintains the root zone database containing technical and administrative details for each delegation. serves as the root zone maintainer, compiling the zone file from IANA inputs, applying cryptographic signatures for DNSSEC validation, and publishing updates at least daily to ensure timely propagation. The zone's authoritative data is distributed via 13 clusters, operated by 12 independent organizations including , , and national entities, with routing deploying instances across hundreds of global locations for and load balancing. Introduced in the early DNS specifications from the ARPANET era and evolved through decades of incremental enhancements, the root zone underpins the Internet's stability by handling billions of queries daily without centralized failure points, though it has faced distributed denial-of-service attacks that operators mitigate through extensive anycast infrastructure. DNSSEC implementation, including key signing keys managed by IANA, adds cryptographic trust anchors to verify root zone integrity against tampering. This system's resilience has supported the expansion to over 1,500 TLDs while preserving a unified namespace essential for universal interoperability.

Overview

Definition and Fundamental Role

The DNS root zone represents the uppermost echelon of the (DNS) hierarchical namespace, containing the authoritative delegation records for all top-level domains (TLDs), such as generic TLDs including .com and sponsored TLDs like .edu, as well as country-code TLDs like .uk and .jp. These records specify the name servers operated by TLD registries, ensuring a unified global directory of domain authorities. The zone itself is a discrete DNS resource record set, distributed via a root zone file that lists the IP addresses and hostnames of authoritative root name servers to initiate resolution . In its fundamental role, the root zone anchors the entire DNS resolution by responding to queries for TLDs with referrals to the corresponding TLD name servers, thereby enabling recursive resolvers—such as those in operating systems and applications—to traverse the downward toward final authoritative answers. This mechanism maintains the causal and lookup efficiency across the , where a single root query per resolution session suffices to access any , preventing fragmentation of the . Managed through precise change requests and cryptographic validation via DNSSEC, the root zone's stability directly underpins the scalability and reliability of domain-to-IP mapping for billions of daily queries, as disruptions here would cascade failures throughout subordinate zones. Its design as a minimal, high-authority layer reflects first-principles for distributed systems, prioritizing redundancy over centralization to mitigate single points of failure.

Contents and Hierarchical Structure

The DNS root zone, situated at the apex of the represented by the empty ".", contains that define its own authority and delegate to top-level domains (TLDs). It begins with a single Start of Authority (, which specifies the primary authoritative (typically a.root-servers.net), the responsible party (often nstld.verisign-grs.com), a for versioning (e.g., incrementing daily as 2025102601), and timing parameters such as refresh (1800 seconds), retry (900 seconds), expire (604800 seconds), and minimum TTL (86400 seconds). These parameters govern zone transfers and caching behaviors for secondary root servers. Following the SOA are 13 Name Server (NS) records designating the logical root name servers, from a.root-servers.net to m.root-servers.net, each with a TTL of 518400 seconds. To facilitate resolution, these include glue records: A records for IPv4 addresses (e.g., 198.41.0.4 for a.root-servers.net) and AAAA records for IPv6 (e.g., 2001:503:ba3e::2:30), both with extended TTLs up to 3600000 seconds to minimize query loads on the root. The majority of the zone—over 1,500 entries as of early 2025—consists of delegations to TLDs, encompassing generic TLDs (gTLDs) like .com and country-code TLDs (ccTLDs) like .us. Each TLD features 2 to 13 NS records pointing to its authoritative servers (e.g., a.gtld-servers.net for .com), with glue A and AAAA records for any server hostnames subordinate to the TLD (e.g., ns1.nic.example. resolved via 192.0.2.1) to prevent circular resolution dependencies during initial queries. DNSSEC integration adds Delegation Signer (DS) records for secured TLDs (e.g., key tag 59875 for .bf), which anchor the chain of trust from the root's Key Signing Key downward, alongside RRSIG records signing other entries, NSEC or NSEC3 for authenticated denial of existence, DNSKEY for zone keys, and ZONEMD for integrity validation. No other record types, such as or TXT, appear in the root zone, as its role is strictly delegative rather than hosting endpoint data. The , distributed by under IANA oversight, totals several megabytes and is signed as a whole, with changes propagated via NOTIFY and AXFR/IXFR mechanisms to the 13 root server operators. In hierarchical terms, the root zone embodies the inverted of the DNS , where the root node branches solely to TLD labels (e.g., com.), creating zone cuts via NS records that shift authority to TLD operators. This delegation enables scalable, distributed management: TLD zones then subdivide into second-level domains (e.g., ), and so on, without the root retaining data below the TLD level. The absence of subdomains under the root ensures minimal content while supporting global resolution , with via deployment across hundreds of physical instances for the 13 logical servers. This design, formalized in RFC 1034 and 1035, prioritizes and load distribution, handling billions of queries daily without central bottlenecks.

Historical Development

Origins in ARPANET and Pre-DNS Systems

The Advanced Research Projects Agency Network (), operational from 1969, initially relied on numeric host identifiers for network addressing, lacking a standardized system for human-readable names. As the network expanded, informal usage emerged among operators, but resolution remained ad hoc, with each host maintaining local mappings or relying on direct knowledge. By the early 1970s, with approximately 45 hosts connected, the need for centralized coordination grew, leading to the establishment of the Network Information Center (NIC) at under Elizabeth Feinler. Hostname resolution in transitioned to a centralized HOSTS.TXT file around 1973-1974, maintained manually by the NIC and distributed weekly via FTP from the SRI host or physical tapes to connected sites. This plain-text file mapped hostnames to 32-bit ARPANET addresses (later IP addresses post-1983 TCP/IP transition), serving as a flat, authoritative directory for the entire network. Initially sufficient for a small community of under 200 hosts through the , the system's scalability faltered as interconnected with other networks, reaching hundreds of entries by the early ; manual updates introduced delays of up to a week, propagation errors, and administrative bottlenecks under single-point NIC control. These limitations of the HOSTS.TXT regime—centralized maintenance, flat , and vulnerability to human error—directly motivated the design of the (DNS) in 1983 by at the University of Southern California's Information Sciences Institute (ISI), with overseeing implementation. DNS introduced a hierarchical to distribute authority, supplanting the monolithic file with delegated zones; the DNS root zone emerged as the apex of this structure, holding delegations to top-level domains (TLDs) like .ARPA (for hosts during transition) and providing a singular point of coordination akin to the NIC's prior role, but enabled for global, automated resolution. Early root functionality was hosted on servers at ISI, marking the root zone's operational inception as evolved into the broader .

Standardization via RFCs and Formal Protocols

The (DNS) was initially proposed through RFC 882, titled "Domain Names - Concepts and Facilities," and RFC 883, "Domain Names - Implementation and Specification," both authored by and published in November 1983. These documents outlined the core architecture of a hierarchical, distributed naming system to replace manual host table maintenance, introducing concepts such as domain names, resource records, name servers, and resolvers, with the root serving as the apex of the tree. They specified the initial protocol mechanics, including message formats for queries and responses over UDP and TCP, and defined the root domain's role in delegating authority to top-level domains via NS records. These 1983 RFCs were obsoleted and refined in November 1987 by RFC 1034, "Domain Names - Concepts and Facilities," and RFC 1035, "Domain Names - Implementation and Specification," which established the enduring standards for DNS operation. RFC 1034 formalized the as a tree-structured rooted at an unnamed node (conventionally denoted by a trailing dot), where the root zone holds authoritative delegations to top-level domains through glue records for their name servers. RFC 1035 detailed the protocol implementation, including the binary wire format for DNS messages (with fixed headers and variable-length question, answer, , and additional sections), query types (e.g., A for IPv4 addresses), and error codes, ensuring interoperable resolution starting from root servers. These specifications mandated that root servers maintain a cache or of TLD delegations, enabling recursive resolution without centralized control. The RFCs emphasized decentralization and , requiring multiple root server instances to distribute load and provide , with protocols for iterative queries where resolvers contact root servers to obtain TLD referrals. Formal handling, such as NXDOMAIN for non-existent domains and SERVFAIL for server failures, was defined to maintain protocol robustness. Subsequent RFCs built upon this foundation for root-specific operations, such as RFC 7720 (2015), which describes the external protocol interface for root name servers, confirming the 1987 standards' ongoing relevance while addressing deployment requirements like addressing for global . These documents, developed through the (IETF) process, transitioned DNS from experimental mechanisms to a standardized , with the root zone's structure remaining integral to global name resolution stability.

Operational Initialization and Early Deployment

The first , designated A.ROOT-SERVERS.NET, was established in 1984 at the University of Southern California's Information Sciences Institute (ISI) by and to test DNS software implementations and facilitate protocol development following the publication of RFC 882 and RFC 883. This single-server setup initially served as the authoritative source for the root zone, with Postel manually maintaining the zone file and distributing updates via email or file transfers to early experimenters. Operational initialization emphasized reliability testing in the environment, where DNS queries were routed to this ISI-hosted server to resolve initial domain hierarchies replacing the centralized hosts.txt file. Early deployment accelerated in 1985, as DNS transitioned from experimental status to production use under Postel's guidance at ISI, which functioned as the de facto (IANA). The root zone was expanded to include the first generic top-level domains (gTLDs)—.com, .edu, .gov, .mil, .org, and .net—delegated in January 1985, enabling the registration of domains such as symbolics.com on January 1, 1985, marking the initial operational rollout of hierarchical name resolution across hosts. Additional root servers were incrementally added, including instances at and other U.S.-based sites, to provide basic redundancy; by late 1985, the system supported limited global queries with zone updates coordinated manually by Postel. This phase relied on UNIX-based implementations like the Berkeley Internet Name Domain (BIND), first developed in 1984 at UC Berkeley, which handled root zone serving on early hardware. Deployment challenges included ensuring compatibility with legacy resolvers and managing load on the nascent infrastructure, with the root zone file remaining small—containing fewer than 10 TLD delegations by mid-1985. Postel's centralized role extended to approving delegations on a case-by-case basis, prioritizing academic, , and commercial entities, which laid the groundwork for scalable operations without formal structures at the time. By , the root server constellation had grown to seven logical instances, primarily U.S.-operated, reflecting cautious expansion to mitigate single points of failure while the user base remained under 10,000 hosts.

Technical Architecture

Root Name Servers and Logical/Physical Instances

The DNS root zone is authoritatively served by 13 logical name servers, identified as A through M, which collectively hold the complete root zone data and respond to queries directing resolvers to (TLD) servers. These logical servers share a fixed set of 13 IPv4 addresses and corresponding addresses, with hostnames such as a.-servers.net for the A server. Each logical server is operated by one of 12 independent organizations, ensuring decentralized management and avoiding single points of control; Verisign, Inc. uniquely operates both A and J. The operators include government agencies, academic institutions, non-profits, and commercial entities, reflecting the system's origins in diverse U.S. networks while incorporating international participants for broader resilience.
LetterHostnameOperator
Aa.root-servers.netVerisign, Inc.
Bb.root-servers.net
Cc.root-servers.net
Dd.root-servers.netUniversity of Maryland
Ee.root-servers.net ()
Ff.root-servers.netInternet Systems Consortium, Inc.
Gg.root-servers.netU.S. Department of Defense (NIC)
Hh.root-servers.netU.S. Army (Research Lab)
Ii.root-servers.netNetnod
Jj.root-servers.netVerisign, Inc.
Kk.root-servers.net
Ll.root-servers.net
Mm.root-servers.netWIDE Project
Physically, the 13 logical servers are deployed across nearly 2,000 instances globally as of October 2025, leveraging IP routing where multiple servers advertise the same IP prefix via BGP, directing queries to the nearest instance based on . This deployment, pioneered by operators like ISC for F-root in the late 1990s and widely adopted since, multiplies effective capacity— for example, ISC alone maintains 368 sites—while distributing load to mitigate latency, congestion, and targeted disruptions such as DDoS attacks. Instances are sited in centers and exchange points across continents, with operators like the University of deploying 231 sites for D-root, enabling sub-50ms query responses in most regions and failover without client reconfiguration. The physical proliferation stems from causal necessities of scale: limits would bottleneck the trillions of daily root queries, whereas empirically sustains query volumes exceeding 1.5 million per second per logical server without proportional hardware escalation.

Mechanisms for Redundancy and Global Diversity

The DNS root server system achieves through the deployment of 13 logical root servers (labeled A through M), each managed by one of 12 independent operators, with operating both A and J. These logical servers are replicated across thousands of physical instances, enabling such that failure of any single instance does not disrupt service, as traffic is automatically rerouted via (BGP) announcements. Operators implement internal measures, including load balancing, power supplies, and diverse network connections at each site, to maintain even during localized outages or maintenance. Global diversity is facilitated primarily by IP anycast, a routing technique where the same IP address for a logical root server is advertised from multiple geographic locations, directing client queries to the nearest available instance based on . This deployment spans over 130 countries across all inhabited continents, with operators like maintaining instances in sites such as (56 instances) and the University of Maryland contributing 231 sites in College Park, . As of , 2025, the comprises 1,999 physical instances operated collaboratively by these organizations, ensuring no single geographic region or dominates query handling. Further enhancing resilience, operators employ technological diversity in operating systems (e.g., various distributions), name server software (e.g., , ), hardware platforms, and upstream network providers, reducing vulnerability to common-mode failures from software bugs, vendor-specific flaws, or targeted attacks. This multi-vendor, multi-path approach, combined with anycast's inherent load distribution, supports amid rising query volumes, which exceeded billions daily by the mid-2010s, without compromising response times or introducing central points of failure.

Query Resolution Process and Scalability Challenges

The DNS query resolution process involving the root zone commences when a recursive resolver, unable to answer a client query from its cache, initiates an iterative query to a root name server for a domain lacking TLD delegation information. The root name server, authoritative for the root zone, responds with a non-authoritative answer containing the NS records and corresponding A or AAAA glue records for the relevant TLD's name servers, as defined in the root zone file; it does not resolve further into the domain hierarchy. This referral directs the resolver to query the TLD servers next, completing the initial delegation step in the hierarchical resolution chain. Root servers handle primarily TLD referral queries rather than direct root zone lookups, which are infrequent and typically limited to root domain verification or testing; iterative resolution ensures efficiency by avoiding recursion at the root level, minimizing load on these entry-point servers. Query selection among the 13 logical root servers occurs via , where the resolver's network paths to identical IP prefixes determine the nearest physical instance, enhancing latency and without altering the logical . Scalability challenges arise from the root zone's role as the DNS , subjecting servers to aggregate global query volumes exceeding 84 billion per day as of , following protocol optimizations that reduced by over 41% through improved client-side caching and query minimization. Approximately 72% of these queries consist of junk , including misconfigurations, scanning attempts, or legacy device errors from large ISPs and IoT networks, amplifying operational strain and vulnerability to DDoS attacks that exploit UDP-based queries for reflection. To counter these pressures, root operators have deployed over 1,400 physical instances across 200+ global sites using anycast, enabling load distribution and redundancy, while upgrading hardware for higher packet processing rates and implementing traffic filtering to discard invalid queries. Persistent issues include monitoring distributed anycast endpoints for synchronization, as glitches in inter-server communication—such as a 2024 incident desynchronizing one root operator—can propagate resolution failures, and the finite 13-letter labeling limits further logical expansion without protocol changes. Ongoing ICANN-coordinated studies emphasize rate-of-change scaling for zone updates and abuse mitigation to sustain performance amid projected query growth.

Governance and Administration

IANA Responsibilities in Zone Maintenance

The (IANA), operated by the Public Technical Identifiers (PTI) under , holds primary responsibility for the administrative coordination and oversight of the DNS zone, ensuring its accuracy, stability, and global consistency. This includes verifying and recording delegations of top-level domains (TLDs), both generic (gTLDs) like .com and country-code (ccTLDs) like .uk, by assigning and updating operator details such as nameservers and administrative contacts. IANA maintains the Root Zone Database as the authoritative public record of these delegations, which serves as the basis for compiling the zone file distributed to the 13 root server clusters. IANA processes change requests for root zone modifications through a structured verification protocol, initiated by TLD sponsors or operators via an online portal or standardized templates. Requests undergo identity verification, confirmation of operational authority, and technical validation to prevent unauthorized alterations, with implementation directed to only after approval. For new delegations or transfers, IANA evaluates compliance with established criteria, including evidence of operator readiness and absence of disputes, before authorizing updates; as of , this process handles an average of several dozen changes annually, reflecting controlled evolution of the zone's approximately 1,500 TLD entries. In coordination with under the Root Zone Maintainer Agreement (effective since September 28, 2016, and amended October 20, 2024), IANA directs the compilation of the root incorporating approved changes, while executes technical tasks such as cryptographic signing and propagation to root server operators. IANA also monitors zone integrity post-deployment and provides essential artifacts like root hints for resolver bootstrapping and DNSSEC trust anchors, with recent enhancements in January 2025 introducing and streamlined identity checks to bolster security in change handling. These functions prioritize operational reliability, drawing on empirical monitoring data to minimize disruptions in a processing billions of queries daily.

ICANN Oversight and Verisign's Maintainer Role

The exercises oversight of the DNS root zone primarily through its execution of functions, which involve evaluating and authorizing changes to the zone's content, such as the delegation or redelegation of top-level domains (TLDs). This oversight ensures adherence to established policies for root zone stability, including verification of sponsor qualifications for new generic TLDs and coordination with TLD registries and sponsors for zone updates. 's Root Zone Management System (RZMS) facilitates the policy-side processing of change requests, authenticating them before forwarding technical instructions to the operational maintainer. Verisign serves as the exclusive Root Zone Maintainer under the Root Zone Maintainer Agreement (RZMA) with ICANN, a role renewed on October 20, 2024, for an eight-year term to sustain the DNS's foundational infrastructure. In this capacity, Verisign operates its proprietary RZMS to receive authenticated change submissions from ICANN, compile the authoritative , apply cryptographic signing with DNSSEC zone signing keys (ZSKs) generated during quarterly key signing ceremonies, and disseminate the updated, signed file to the 13 root server operator clusters. Verisign's technical responsibilities extend to maintaining distribution channels for the root zone hints file, which legacy resolvers use for initial root server discovery, thereby supporting amid evolving DNS protocols. This division of labor— handling policy-directed changes and executing operational maintenance—minimizes single points of failure while enforcing procedural checks, such as dual authentication of submissions to prevent unauthorized alterations. further bolsters root zone integrity by operating root servers 'a' (verisign.com) and 'j' (a.root-servers.net), contributing to the deployment of over 1,000 physical instances globally for and load distribution. The RZMA stipulates performance metrics, including timelines not exceeding 24 hours for zone updates, to uphold the root zone's role as the DNS hierarchy's apex.

U.S. Government Stewardship and the 2016 IANA Transition

The U.S. Department of Commerce's (NTIA) exercised stewardship over the (IANA) functions, including coordination of the DNS root zone, through successive contracts with the (ICANN) from 2000 until 2016. Under this arrangement, NTIA performed a final authorization step for root zone changes: after ICANN's IANA Functions Operator proposed modifications (such as adding or updating top-level domains) and prepared the updated , NTIA reviewed and approved the revision to the authoritative records before implementation, ensuring stability and compliance with policy. This oversight stemmed from the U.S. government's historical role in development via and subsequent privatization efforts, formalized in the 1998 between NTIA and ICANN, which evolved into biennial contracts for IANA performance. In March 2014, NTIA initiated a process to transition its role to the global multistakeholder , announcing its intent to let the IANA functions expire upon successful completion of an independent proposal for post-transition governance, provided it met five principles: preserving Internet stability, supporting competition and private sector-led development, ensuring multistakeholder accountability, avoiding government-led or intergovernmental control, and maintaining U.S. principles like and of expression. The effort involved separate but coordinated work streams from , numbering, and protocol parameter communities, culminating in a unified proposal submitted to NTIA on March 10, 2016, which established Public Technical Identifiers (PTI) as an affiliate to handle IANA functions and introduced accountability mechanisms like the Customer Standing Committee for root zone stakeholders. NTIA verified the proposal's completeness and alignment with its principles, announcing approval on June 9, 2016, after confirming it would not substitute one form of oversight for another but enhance bottom-up coordination. The transition executed on September 30, 2016, when the contract expired, eliminating NTIA's root zone authorization step effective October 1, 2016, and shifting final authority to PTI in coordination with under existing cooperative agreements. This change maintained operational continuity—no immediate root zone alterations occurred during the —while critics, including some U.S. lawmakers, argued it risked ceding influence to international actors potentially less aligned with democratic norms, though proponents emphasized empirical stability post-transition with no disruptions to DNS resolution.

Security Protocols

DNSSEC Deployment and Root Zone Cryptographic Signing

The (DNSSEC) were deployed in the DNS root zone to provide cryptographic authentication of data origin and integrity, preventing attacks such as through digital signatures on resource records. This deployment established the root as the apex of the DNSSEC , with resolvers configured to validate signatures starting from a pre-installed representing the root's Key Signing Key (KSK). Initial test signings occurred in December 2009 by and , but full operational deployment followed the publication of the root on July 15, 2010, after coordination with root server operators and a testing period documented in a May 2010 NTIA report confirming minimal disruptions. Cryptographic signing of the root zone employs asymmetric cryptography, initially using 1024-bit RSA keys with hashing, upgraded over time for enhanced security: the Zone Signing Key (ZSK) migrated to 2048-bit RSA/SHA-256 by 2016, while the KSK remains at 2048-bit RSA with periodic rollovers to mitigate long-term key compromise risks. The ZSK, rotated every three months to limit exposure, signs the root zone's resource records (primarily NS and DS records for top-level domains), producing RRSIG records; the KSK then signs the DNSKEY set containing both keys, ensuring verifiable delegation to child zones. and signing occur in secure, air-gapped ceremonies held quarterly since 2010, conducted in redundant facilities—one in , and another in —to generate Key Signing Requests (KSRs) bundling multiple ZSKs for resilience against single-point failures. These ceremonies involve tamper-evident modules (HSMs), randomized processes to prevent deterministic attacks, and multi-party computation with observers from government, industry, and to without revealing private keys. As of October 2025, DNSSEC signing remains active in the root zone, with a 2024-2026 KSK rollover in progress: a successor KSK (KSK-2024) was prepublished in the root zone on January 11, 2025, allowing resolvers to build dual s ahead of the primary KSK (KSK-2010) retirement planned for 2026, following lessons from the incomplete 2018 rollover where only 14% of resolvers updated promptly. IANA maintains the files, distributed via RFC 5011 for automatic updates in validating resolvers, ensuring during transitions. Deployment challenges included early validation failures due to unsigned parent DS records in some TLDs and the need for global resolver updates, but root-level signing has achieved near-universal coverage among authoritative servers.

ZONEMD for Data Integrity Verification

ZONEMD (Zone Message Digest) is a DNS resource record type specified in RFC 8976, published in February 2021, that enables cryptographic verification of the integrity of an entire DNS zone's data as stored at rest. The record contains a message digest computed over the canonicalized zone contents, allowing recipients—such as recursive resolvers—to confirm that the received zone data matches the authoritative version without alterations from tampering, transmission errors, or corruption. When paired with DNSSEC signatures, ZONEMD also authenticates the origin of the zone data, providing end-to-end assurance from the zone publisher to the verifier. In the DNS root zone, ZONEMD records are published at the zone apex (.) and signed using the root zone's Zone Signing Key (ZSK). The digest is generated using a specified hash algorithm, with the initial root deployment employing SHA-384 (scheme 1, algorithm 2) for robust . Zone content is serialized in a canonical wire format, excluding the ZONEMD records themselves to avoid self-referential issues, and the resulting digest is included in the ZONEMD RRset. This setup permits automated verification by software that fetches the root hints file or zone data from mirrors like ftp.internic.net, where ZONEMD appears in native presentation format alongside standard root zone files. Deployment of ZONEMD in the root zone occurred on September 20, 2023, following a brief delay from the initial target of September 13 due to a minor operational testing issue; this marked the first new record type added to the root in 13 years. , as the root zone maintainer, computed and incorporated the ZONEMD records into the signed zone, with ICANN's IANA functions operator handling distribution updates. Root server operators endorsed the addition after confirming no adverse impacts on operations, recommending two months' advance notice for synchronization. Post-deployment, resolvers supporting ZONEMD validation—such as updated versions of Recursor—can fetch the root zone, retrieve the ZONEMD records via DNS queries, recompute the digest over the received data, and compare it against the published value, rejecting mismatches. This mechanism addresses gaps in traditional DNSSEC, which verifies individual records but not the completeness or wholeness of a zone transfer or file download. By enabling bulk verification of the root zone's approximately 1,500 delegations and other entries, ZONEMD enhances resilience against supply-chain attacks, mirror compromises, or inadvertent modifications during global distribution to over 1,300 root server instances. Initial advice from root server operators urged implementers to enable ZONEMD by default for locally cached root data, promoting widespread adoption without mandating changes to query protocols. Future extensions may include additional hash schemes for post-quantum , though current root ZONEMD relies on classical algorithms.

Integration with DNS over TLS and Post-Quantum Considerations

The DNS root servers have progressively adopted support for (DoT), which encrypts DNS queries using TLS to mitigate and tampering risks during resolution from recursive resolvers to root instances. As of 2023, operators such as USC/ISI for the L-root server implemented experimental DoT capabilities, predating the formal standardization in RFC 9539, enabling secure TCP-based queries on port 853. Similarly, the root server operators' collective statement acknowledges DoT (per RFCs 7858 and 8094) as a viable mechanism, though deployment remains operator-specific and not universally mandated, given that root queries constitute a small fraction of total DNS traffic handled primarily by recursive resolvers. This integration does not alter the root zone's content or signing but enhances transport-layer security for direct or root accesses, aligning with broader efforts to encrypt upstream DNS paths without disrupting hierarchical resolution. Post-quantum considerations for the DNS root zone center on the vulnerability of current DNSSEC algorithms, such as ECDSA (used in the root's KSK-2018), to quantum attacks via algorithms like Shor's, which could forge signatures and undermine zone integrity. The root's long key lifetimes—exemplified by the initial KSK rollout in 2010 and first rollover in 2018 after eight years—necessitate proactive migration to NIST-standardized (PQC) signatures, such as or , to maintain cryptographic agility. ICANN's May 2024 Root Zone Algorithm Rollover Study evaluates feasibility, recommending dual-signature strategies during transitions to accommodate larger PQC keys and signatures, which could double zone size and impact propagation times, while ensuring through pre-published DS records. , as root zone maintainer, advocates for ecosystem-wide testing of PQC in DNSSEC, noting that retrofitting requires protocol adaptations for larger data and diverse algorithm support to avoid validation failures during global rollovers. ICANN assessments indicate sufficient lead time—potentially decades before viable quantum threats— for adopting PQC, prioritizing diversity in classical and quantum-resistant algorithms to hedge against unforeseen weaknesses. These measures preserve the root's role as a amid evolving computational threats, without immediate changes to zone administration.

Controversies and Critical Perspectives

Risks of Centralization and Systemic Vulnerabilities

The management of the DNS root zone, involving verification by IANA and maintenance and distribution by under oversight, introduces centralized dependencies that constitute potential single points of failure, even as the root server instances themselves are distributed via across hundreds of global sites. A 2022 study on the root zone update process identified such points in resource access and dependencies, recommending redundancies like diversified personnel and automated checks to mitigate risks of disruption during zone changes. of these core entities—through insider threats, , or technical breaches—could enable unauthorized alterations to the root , leading to widespread resolution failures or partition of the namespace, as the root serves as the foundational for the entire DNS hierarchy. Systemic vulnerabilities stem from this architecture's reliance on trusted central processes, including the biannual DNSSEC root key signing ceremonies, where cryptographic keys are generated and signed in secure facilities to protect zone integrity. A failure in , such as during the 2018 Key Signing Key rollover, risked invalidating root signatures and causing validating resolvers to reject DNS responses, potentially disrupting for non-validating systems after a 48-hour TTL expiration. While no full root compromise has occurred, the centralized trust model exposes the system to internal risks like tampering or —such as coercive deletion of top-level domains—and external threats including DoS attacks that could saturate management channels, amplifying impacts across the global DNS due to the root's universal role. Critics, including analyses from the Electronic Frontier Foundation, argue that the 2016 IANA stewardship transition from U.S. oversight failed to decentralize core control points, preserving vulnerabilities to policy-driven abuses like TLD removals under pressure, while multi-stakeholder governance offers limited safeguards against capture. Academic proposals, such as permissioned blockchain architectures like TD-Root, aim to distribute root management to tolerate up to one-third malicious nodes via consensus mechanisms, reducing single points of failure while maintaining compatibility with existing resolvers, though adoption remains theoretical due to coordination challenges. Current mitigations—DNSSEC signing, TSIG for transfers, diverse software implementations, and route monitoring via partial RPKI deployment—enhance resilience but do not eliminate the inherent risks of centralized authority in a system underpinning global connectivity.

Geopolitical Disputes over Control and Sovereignty

Geopolitical tensions surrounding the DNS root zone have primarily arisen from clashes between the model led by and demands by authoritarian governments for greater state control, often framed as enhancing national sovereignty. At the World Conference on International Telecommunications (WCIT) in , organized by the (ITU), , , and allies proposed amendments to the International Telecommunication Regulations that would extend ITU oversight to internet naming, addressing, and DNS functions, aiming to shift authority from private entities to intergovernmental bodies. The and like-minded nations rejected these proposals, leading to a fragmented outcome where 55 countries, including and , signed the revised ITRs while 89 others, including the , members, and many developing nations, declined, preserving ICANN's role in root zone management. This event highlighted causal links between government-led models and potential for content controls, as evidenced by subsequent national firewalls in proponent states. Following the 2016 IANA stewardship transition, which ended formal contractual oversight, disputes intensified as enacted its "Sovereign Internet" law on July 1, 2019, mandating a national DNS system operational by , 2021, to enable isolation from the global during perceived threats. The law requires internet service providers to route traffic through state-monitored gateways and install equipment for rapid disconnection, tested successfully in isolated drills on 11-12, 2022, demonstrating feasibility of splintering from ICANN's . has pursued parallel efforts, including 2012 IETF proposals for DNS fragmentation along national borders and deployments of ICANN-affiliated server instances in (2014 and 2019), while exploring blockchain-based alternatives that could bypass the global . These initiatives reflect a to assert digital sovereignty, prioritizing state security over universal , though empirical data shows such systems enable — blocked over 1 million domains annually by 2023 under related laws—without enhancing technical stability. A stark illustration occurred amid Russia's 2022 invasion of , when Ukrainian officials requested on February 28 that revoke Russia's ccTLDs (.ru, .рф, .su) from the zone to disrupt military communications. CEO Göran Marby rejected the plea on March 2, citing the organization's bylaws prohibiting unilateral actions based on geopolitical conflicts and the risk of eroding DNS neutrality, which underpins global trust in the system. This decision preserved integrity but fueled accusations of insufficient accountability, with critics arguing the multistakeholder model inadequately counters adversarial states' manipulation attempts, such as Russia's promotion of backup roots with allies like and since 2017. Ongoing risks include proliferation of alternate roots, which could fragment resolution—potentially affecting 4.9 billion users by enabling parallel namespaces incompatible with the authoritative zone—though no major schism has materialized due to economic interdependence and technical reliance on 's 1,500+ server instances.

Debates on Governance: Stability of U.S.-Influenced Model vs. Multilateral Alternatives

The of the DNS root zone has sparked ongoing debates between advocates of the multistakeholder model, historically shaped by U.S. influence through and IANA, and proponents of multilateral under bodies like the (ITU) or frameworks. Following the 2016 IANA functions transition, which formally ended U.S. contractual oversight of , the multistakeholder approach—emphasizing input from governments, , , and technical experts—has been credited with maintaining operational stability without introducing new points of geopolitical friction. Critics of this model, however, argue it perpetuates informal U.S. leverage, potentially undermining global , while multilateral alternatives are promoted as more equitable representations of state interests. Empirical evidence supports the stability of the U.S.-influenced multistakeholder framework, which has overseen the DNS zone since its in the without systemic disruptions or politicized changes to top-level domains. Under this model, root zone changes occur predictably via coordinated processes between , , and IANA, with over 1,500 delegations and updates processed annually by 2021, streamlining operations post-transition and enhancing predictability. Proponents, including U.S. policymakers and technical communities, contend that private-sector involvement fosters and resilience, as evidenced by the absence of root-level failures amid exponential growth from 16 root servers in 1994 to over 1,300 instances worldwide by 2023. In contrast, shifting to government-dominated control risks introducing veto powers from authoritarian regimes, potentially fragmenting the or enabling content-based manipulations, as warned in analyses of historical U.S. . Multilateral alternatives gained prominence through proposals from and , notably at the 2012 World Conference on International (WCIT-12), where leaked drafts sought ITU oversight of numbering, addressing, and domain names, framing the as a state-coordinated system rather than a decentralized network. advocated transferring authority over core resources to national governments under UN auspices, while resubmitted sovereignty-focused language emphasizing state control over addressing systems. These efforts, supported by allies like and , aimed to counter perceived U.S. monopoly but were rejected by 55 nations, including the U.S. and much of the , highlighting divisions over whether equates to enhanced representation or heightened risk of top-down regulation. Critics of argue it would erode the DNS root's neutrality, citing proposals like China's 2020 ITU submission for enhanced government roles in and Russia's 2017 push for a "sovereign " with potential fragmentation. Such models, per ional assessments, could slow decision-making—evident in ITU's protracted treaty negotiations—and invite , as authoritarian states hold disproportionate sway in intergovernmental forums. The 2022 ITU Plenipotentiary Conference underscored this tension, where open- advocates blocked and China's bids for expanded ITU authority over DNS-related functions. Ongoing discourse, as in EU-U.S. dialogues, weighs the multistakeholder model's proven scalability against multilateral calls for "," with empirical stability under —zero root zone outages from politicization since —contrasting theoretical equity gains from state-led systems that have yet to demonstrate comparable reliability. While post-transition reforms bolstered accountability via mechanisms like the Empowered Community, skeptics from non-Western states persist in viewing residual U.S. technical influence—through firms like —as a stability liability, though no verified backdoor controls have emerged. This underscores causal trade-offs: decentralized governance prioritizes operational resilience over formal equity, averting the capture risks inherent in aggregating state vetoes.

References

  1. https://www.iana.org/domains/root
  2. https://www.icann.org/root-server-system-en
  3. https://datatracker.ietf.org/doc/html/rfc2826
  4. https://www.icann.org/en/stewardship-implementation/root-zone-maintainer-agreement-rzma
  5. https://www.iana.org/domains/root/servers
  6. https://itp.cdn.icann.org/en/files/root-server-system-advisory-committee-rssac-publications/rssac-023-17jun20-en.pdf
  7. https://www.iana.org/domains/root/db
  8. https://www.iana.org/domains/root/files
  9. https://labs.apnic.net/index.php/the-root-of-the-dns/
  10. https://www.internic.net/domain/root.zone
  11. https://www.ietf.org/rfc/rfc1035.txt
  12. https://blog.apnic.net/2025/03/18/the-root-of-the-dns-2/
  13. https://www.icann.org/en/tlds/report-root-zone-glue-handling-nov09-en.pdf
  14. https://www.iana.org/go/rfc9718
  15. https://www.ietf.org/rfc/rfc1034.txt
  16. https://nap.nationalacademies.org/read/11258/chapter/4
  17. https://retrocomputing.stackexchange.com/questions/30357/did-arpanet-hosts-have-some-kind-of-name-resolving-before-1974
  18. https://www.isi.edu/news/972810/and-the-dns-was-born/
  19. https://kumojin.com/en/dns-basics/
  20. https://www.oreilly.com/library/view/dns-on-windows/0596005628/ch01s02s01.html
  21. https://www.rfc-editor.org/rfc/rfc882.html
  22. https://datatracker.ietf.org/doc/html/rfc1034
  23. https://datatracker.ietf.org/doc/html/rfc1035
  24. https://datatracker.ietf.org/doc/html/rfc7720
  25. https://www.iana.org/reports/2002/pro-report-06may02.html
  26. https://www.iana.org/reports/2001/museum-report-30oct01.html
  27. https://www.icdsoft.com/blog/ten-interesting-domain-related-facts/
  28. https://www.cloudns.net/blog/dns-history-creation-first/
  29. https://home.uchicago.edu/~mferzige/ccTLDs.pdf
  30. https://itp.cdn.icann.org/en/files/root-server-system-advisory-committee-rssac-publications/rssac-023-04nov16-en.pdf
  31. https://root-servers.org/
  32. https://www.root-servers.org/
  33. https://root-servers.org/media/news/Threat_Mitigation_For_the_Root_Server_System.pdf
  34. https://root-servers.org/media/news/2025-External_Diversity_Report.pdf
  35. https://www.cloudflare.com/learning/dns/what-is-dns/
  36. https://www.nslookup.io/learning/what-is-the-dns-root-zone/
  37. https://basila.medium.com/dns-deep-dive-618169c7139f
  38. https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traffic/
  39. https://pulse.internetsociety.org/blog/more-than-70-of-dns-root-queries-are-junk
  40. https://www.icann.org/resources/pages/root-scaling-study-tor-2009-05-05-en
  41. https://arstechnica.com/security/2024/05/dns-glitch-that-threatened-internet-stability-fixed-cause-remains-unclear/
  42. https://www.iana.org/domains/root/help
  43. https://www.icann.org/en/system/files/files/root-zone-process-study-08jul22-en.pdf
  44. https://www.iana.org/performance/root-maintainer
  45. https://www.icann.org/en/blogs/details/ushering-in-the-next-generation-of-root-zone-management-19-05-2022-en
  46. https://blog.verisign.com/security/root-zone-maintainer-service-agreement-renewal/
  47. https://domainincite.com/30488-verisign-gets-eight-more-years-running-the-root
  48. https://blog.verisign.com/security/verisign-dns-key-signing-ceremony/
  49. https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0
  50. https://www.verisign.com/about-us/
  51. https://www.nro.net/internet-governance/iana/iana-stewardship-transition/stewardship-transition-archive/ntia-contract/
  52. https://www.ntia.gov/other-publication/q-and-iana-stewardship-transition-0
  53. https://www.internetsociety.org/ianatimeline/
  54. https://www.icann.org/stewardship
  55. https://www.icann.org/en/announcements/details/stewardship-of-iana-functions-transitions-to-global-internet-community-as-contract-with-us-government-ends-1-10-2016-en
  56. https://www.lawfaremedia.org/article/iana-transition-five
  57. https://www.icann.org/en/announcements/details/dnssec-deployment-in-root-zone-of-dns-begins-at-icann-27-1-2010-en
  58. https://www.iana.org/dnssec/files
  59. https://www.ripe.net/ripe/mail/archives/ncc-announce/2009-December/000348.html
  60. https://www.ntia.gov/sites/default/files/publications/dnssec_05282010_0_0.pdf
  61. https://www.internetsociety.org/resources/doc/2016/state-of-dnssec-deployment-2016/
  62. https://www.cloudflare.com/learning/dns/dnssec/root-signing-ceremony/
  63. https://www.icann.org/fr/announcements/details/icanns-first-dnssec-key-ceremony-for-the-root-zone-7-6-2010-en
  64. https://www.iana.org/dnssec/ceremonies
  65. https://www.internetsociety.org/blog/2015/11/my-view-of-the-dnssec-root-key-signing-ceremony/
  66. https://blog.verisign.com/security/2024-2026-root-zone-ksk-rollover-initial-observations/
  67. https://www.icann.org/en/announcements/details/icann-publishes-new-dnssec-trust-anchor-to-prepare-for-2026-15-08-2024-en
  68. https://datatracker.ietf.org/doc/rfc9718/
  69. https://www.verisign.com/news-insights/dnssec/
  70. https://www.rfc-editor.org/rfc/rfc8976.html
  71. https://blog.verisign.com/security/root-zone-zonemd/
  72. https://indico.dns-oarc.net/event/47/contributions/1011/attachments/972/1820/zonemd-root-deployment.pdf
  73. https://lists.dns-oarc.net/pipermail/dns-operations/2023-September/022286.html
  74. https://www.icann.org/en/system/files/correspondence/bryce-to-wessels-21dec22-en.pdf
  75. https://root-servers.org/media/news/2022-08-Statement_on_ZONEMD.pdf
  76. https://blog.powerdns.com/2022/11/15/powerdns-recursor-zonemd-the-missing-validation
  77. https://www.icann.org/en/blogs/details/a-new-data-protection-mechanism-for-the-root-zone-15-08-2023-en
  78. http://b.root-servers.org/research/tls.html
  79. https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf
  80. https://conferences.sigcomm.org/sigcomm/2021/files/papers/3431832.3431838.pdf
  81. https://www.icann.org/en/system/files/files/root-zone-algorithm-rollover-study-23may24-en.pdf
  82. https://www.icann.org/en/announcements/details/root-zone-dnssec-algorithm-rollover-study-issues-final-report-23-05-2024-en
  83. https://blog.verisign.com/security/post-quantum-dnssec-preparation/
  84. https://www.icann.org/en/system/files/files/octo-031-22apr24-en.pdf
  85. https://www.icann.org/en/announcements/details/icann-public-comment-proceeding-root-zone-update-process-study-14-03-2022-en
  86. https://www.sciencedirect.com/science/article/abs/pii/S0167739X19312762
  87. https://www.iana.org/dnssec/procedures/ksk-operator/ksk-dps-20201104.html
  88. https://blog.cloudflare.com/its-hard-to-change-the-keys-to-the-internet-and-it-involves-destroying-hsms/
  89. https://www.eff.org/deeplinks/2016/09/oversight-transition-isnt-giving-away-internet-wont-fix-icanns-problems
  90. https://arstechnica.com/tech-policy/2012/12/authoritarian-regimes-push-for-larger-itu-role-in-dns-system/
  91. https://mrunalmanage.wpcomstaging.com/2012/12/diplomacy-wcit-conference-dubai-itu-why-failed-internet-censorship-icann-dns-explained.html
  92. https://dgap.org/en/research/publications/deciphering-russias-sovereign-internet-law
  93. https://www.internetsociety.org/resources/internet-fragmentation/russias-national-dns/
  94. https://flashpoint.io/blog/russian-runet-sovereign-internet/
  95. https://www.aspistrategist.org.au/putins-quest-to-disconnect-russia-from-the-global-internet/
  96. https://domainincite.com/9474-china-proposes-to-split-up-the-dns
  97. https://www.icann.org/en/announcements/details/first-icann-managed-root-server-instance-installed-in-shanghai-3-9-2019-en
  98. https://freedomhouse.org/country/russia/freedom-net/2024
  99. https://www.icann.org/en/system/files/correspondence/fedorov-to-marby-28feb22-en.pdf
  100. https://www.icann.org/en/system/files/correspondence/marby-to-fedorov-02mar22-en.pdf
  101. https://www.freiheit.org/taiwan/icann-rejects-ukraines-request-block-russian-internet-domains
  102. https://www.theregister.com/2017/12/01/russia_own_internet/
  103. https://www.internetgovernance.org/2020/02/26/the-knake-mueller-wager-will-china-form-an-alternate-dns-root/
  104. https://www.internetgovernance.org/2016/04/07/alternate-dns-roots-and-the-abominable-snowman-of-sovereignty/
  105. https://www.icann.org/en/blogs/details/reflecting-on-ianas-post-transition-operations-21-10-2021-en
  106. https://scholarship.law.umn.edu/cgi/viewcontent.cgi?article=1122&context=mjil
  107. https://www.congress.gov/crs_external_products/R/PDF/R42351/R42351.56.pdf
  108. https://www.rstreet.org/commentary/domain-name-not-resolved-breaking-down-the-debate-over-the-icann-transition/
  109. https://www.zdnet.com/article/wcit-12-leak-shows-russia-china-others-seek-to-define-government-controlled-internet/
  110. https://www.cnet.com/tech/tech-industry/russia-demands-broad-un-role-in-net-governance-leak-reveals/
  111. https://www.bloomberg.com/news/articles/2012-12-12/china-russia-resubmit-proposal-to-get-web-control
  112. https://www.euractiv.com/news/china-russia-prepare-new-push-for-state-controlled-internet/
  113. https://itp.cdn.icann.org/en/files/government-engagement-ge/ge-011-06-06-2022-en.pdf
  114. https://circleid.com/posts/20171215_closer_look_at_why_russia_wants_an_independent_internet
  115. https://republicanpolicy.house.gov/sites/evo-subsites/republicanpolicy.house.gov/files/evo-media-document/Reject%2520Authoritarian%2520Internet%2520Control.pdf
  116. https://www.wired.com/story/itu-2022-vote-russia-china-open-internet/
  117. https://www.chathamhouse.org/sites/default/files/publications/research/2019-11-14-EU-US-Relations-Internet-Governance2.pdf
  118. https://journals.sagepub.com/doi/full/10.1177/02683962211054513
  119. https://www.icann.org/en/system/files/files/ig-ecosystem-report-23may14-en.pdf
  120. https://www.brookings.edu/articles/u-s-government-should-not-reverse-course-on-internet-governance-transition/
Add your contribution
Related Hubs
User Avatar
No comments yet.