Fundamentals 24 min read

Can the US Pull the Plug on .cn Domains? A Deep Dive into DNS Root Servers

The article explains how DNS works, why there are only 13 logical root servers, how anycast and mirror servers provide resilience, recounts historical cases of domain shutdowns, examines US control over root zones, and discusses mitigation strategies for protecting national domains.

ITPUB
ITPUB
ITPUB
Can the US Pull the Plug on .cn Domains? A Deep Dive into DNS Root Servers

Background and concerns

Since the United States announced the “Clean Network” initiative, analysts have warned that the U.S. could potentially influence the global DNS root servers and block national top‑level domains (TLDs) such as .cn . Historical precedents include the removal of Iraq’s .iq domain during the 2003 Iraq war and the temporary suspension of Libya’s .ly domain in 2004, demonstrating that root‑zone manipulation is technically feasible.

DNS basics

DNS translates human‑readable domain names into IP addresses. A resolver (often called a local DNS or LDNS) follows a hierarchical query process: it first contacts a root server, then a TLD server, and finally the authoritative server that holds the specific record (A, NS, CNAME, etc.).

Root server architecture

Because DNS messages are limited to 512 bytes (RFC 1035) to avoid IP fragmentation, only 13 logical root server IP addresses can be listed in the root‑hints file. These logical servers are identified as A.root‑servers.net through M.root‑servers.net . In practice each logical server is a set of physically distributed machines; as of August 2020 there were 1 097 physical root instances worldwide.

All root servers use anycast routing: a single IP address is advertised from many locations, and traffic is directed to the nearest operational instance. This provides low latency and redundancy—if some instances fail, others continue to answer queries.

Root zone file management

The root zone file, which contains delegations for every TLD, is maintained by ICANN under the IANA function. Historically the U.S. government oversaw IANA, but since October 2016 ICANN operates as an independent non‑profit. The primary root (A) is operated by Verisign in the United States; the remaining 12 roots are run by separate organizations.

China’s root mirrors

China operates numerous root‑server mirrors (e.g., F, I, J, K, L) that receive the same root‑zone data and share the global root IP addresses. These mirrors are deployed by entities such as China Telecom, CNNIC, China Unicom, and the Beijing‑based ZDNS research center. Key milestones:

2003 – First Chinese mirror (F) introduced by China Telecom.

2005 – I‑root mirror established by CNNIC.

2006 – J‑root mirror and .COM/.NET TLD mirrors launched by China Unicom in cooperation with Verisign.

2014 – L‑root mirror added by Century Internet in partnership with ICANN.

2019 – Ministry of Industry and Information Technology approved six mirrors (F, I, K, L) with identifiers JX0001F … JX0006L, plus additional J and K mirrors (JX0011J, JX0012K, JX0010K).

These mirrors are integrated into the anycast network, so DNS queries from within China are typically routed to domestic mirror instances rather than to the U.S.‑based primary roots.

Potential U.S. actions and impact on .cn

If the U.S. government were to alter the root zone file—e.g., delete the .cn delegations—global resolvers would eventually lose the ability to resolve .cn domains after their caches expire. Chinese mirrors, however, could retain the original .cn records locally, allowing domestic users to continue accessing .cn sites while the rest of the world would experience resolution failures.

Mitigation strategies

Maintain independent copies of the root zone file and operate emergency root servers within China.

Deploy scripts that re‑inject .cn records into the local mirror immediately after each synchronization with the global root.

Establish a separate national root infrastructure that does not depend on the global root hierarchy.

These measures reduce reliance on the global root and ensure continuity of .cn resolution even if the global root is altered.

Anycast explanation

Anycast assigns a single IP address to a set of geographically dispersed servers. When a client sends a packet to that IP, the Internet routing system delivers it to the nearest server based on routing metrics such as hop count, latency, or link capacity. This design provides both performance benefits and resilience: if one anycast node fails, traffic automatically shifts to the next nearest node.

Root zone file inspection

The root zone file can be downloaded from the IANA website:

https://www.iana.org/domains/root/files

The file is ~2.2 MiB and contains over 20 000 lines, including a few dozen lines for the .cn delegation. Removing those lines would propagate the change to all synchronized roots, causing global .cn resolution to break after cache expiration.

How DNS resolution works (step‑by‑step example)

The client asks the local resolver for www.example.com.

If the resolver has no cached answer, it queries one of the 13 root IPs (pre‑configured in the root‑hints file).

The root server returns NS records for the .com TLD.

The resolver queries a .com TLD server, which returns NS records for example.com.

The resolver finally queries the authoritative server for example.com, receiving the A record (IP address) and returns it to the client.

In practice, caches at the browser, OS, and resolver levels often eliminate the need to start from the root for most queries.

References

https://www.iana.org/domains/root/files

https://root-servers.org

https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-11

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

DNSnetwork securityAnycastRoot ServersInternet Governance
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.