Why Are There Only 13 Root Nameserver Groups Worldwide?

1. The Hard Protocol Constraint: 512 Bytes

1.1 IPv4 MTU and unfragmented UDP

Early ARPANET / IPv4 networks mandated a minimum MTU of 576 bytes. Every host had to be able to receive packets of this size, or even basic reachability couldn't be guaranteed (RFC 791).

Total Length is the length of the datagram, measured in octets,
including internet header and data.  This field allows the length of
a datagram to be up to 65,535 octets.  Such long datagrams are
impractical for most hosts and networks.  All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments).  It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

• 576-byte total length − typical 20-byte IP header − 8-byte UDP header ≈ 548 bytes usable (with IP options the header can reach 60 bytes, leaving less)
• RFC 1035 § 4.2.1 settled on the more conservative power of two, 512 bytes, as the hard ceiling for DNS over UDP — safe even when the IP header carries full options
• If a UDP response exceeds 512 bytes, it must be truncated with the TC flag set, forcing the client to fall back to TCP — and the TCP three-way handshake multiplies first-resolution latency

In other words, "the full root server list must fit in a single 512-byte UDP packet" — otherwise every root query worldwide would have to go over TCP, which would have been close to catastrophic on 1980s hardware.

1.2 Byte layout of the DNS message

The full response structure for a query of the NS records for . (the server returns all root NS records plus glue A records):

Header   (12 bytes)

Total length formula:

Substituting the 512-byte limit:

In theory this allows up to 15 groups, but headroom is needed for DNSSEC signatures, the EDNS0 OPT pseudo-record, and field padding, so it settled at 13 groups — RFC 2010 (1996) laid out the operational criteria for root servers, and the count has not changed since M-root came online the following year.

1.3 Test it yourself — <code>dig +noedns -t ns .</code> returns roughly 490–510 bytes

That's the theory. Now let's actually query a root server with dig and see how large the real response is:

$ dig +noedns -t ns .

; <<>> DiG 9.10.6 <<>> +noedns -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35973
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                                IN      NS

;; ANSWER SECTION:
.                       430502  IN      NS      a.root-servers.net.
.                       430502  IN      NS      b.root-servers.net.
…  (共 13 条 NS, c ~ l 略)
.                       430502  IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     516909  IN      A       198.41.0.4
b.root-servers.net.     562547  IN      A       170.247.170.2
…  (13 条 A 胶水记录全部塞进来了)
m.root-servers.net.     516941  IN      A       202.12.27.33
a.root-servers.net.     516930  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     562547  IN      AAAA    2801:1b8:10::b
↑ AAAA 只塞下 2 条 — 包已经到顶了

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE  rcvd: 492

The key line at the end — a total response of roughly 490–510 bytes, comfortably under 512 (the exact figure depends on which root you ask and how many IPv6 glue records come back) — matches the byte budget above. Note the +noedns flag: dig sends EDNS0 by default, which returns well over 800 bytes. That is precisely why 512 bytes stopped being a hard limit once EDNS0 became universal — but 13 was already locked in by then.

2. Where Does 13 Come From? A Brief History

This number wasn't fixed from the start. The root server count went through several expansions; after M-root (WIDE, Japan) came online in 1997 it never changed again:

Once locked at 13, the letter names A through M never change — only hardware gets upgraded and anycast mirrors get added. The Internet's root hint file (named.root) has long been baked into the code of billions of recursive resolvers and stub clients; changing a single number would mean upgrading the entire Internet.

3. But Are There Really Only 13 Machines Worldwide?

No. This is the most common misconception. "13 root server groups" refers to 13 NS names (a–m.root-servers.net), each mapping to one IPv4 and one IPv6 address — not 13 physical machines.

Behind each IP is an anycast cluster — the same IP address is announced via BGP simultaneously by hundreds of datacenters worldwide, and a user's DNS query is routed to the nearest mirror by RTT. When a root server "goes down," it usually just means one city's mirror is under maintenance — global resolution is unaffected.

Status of the 13 Root Server Groups in 2024

Mainland China (Beijing, Shanghai, Shenzhen, Guangzhou, Hefei, and more) hosts anycast mirror nodes for several root servers including F / I / J / K / L; measured RTT to root servers from within China is typically under 20ms.

4. After EDNS0, 512 Bytes Stopped Being a Real Limit

You might ask: DNS packets of 4KB or more are common these days, so why not just "break past 13"?

• EDNS0 (RFC 2671 in 1999, currently RFC 6891) — negotiates a larger UDP payload (commonly 4096 bytes), supported by every modern resolver
• DNSSEC mandates EDNS0, since signature data alone far exceeds 512 bytes
• TCP fallback — modern TCP three-way handshakes plus TLS / cookies are already cheap

But the root server list is now a network-wide consensus: every recursive resolver on earth hardcodes these 13 groups in its hint file (named.root), and behind those resolvers sit billions of endpoints. The incentive to change is zero, and the risk is a fractured global Internet, so this number will almost certainly stay 13 forever.

In short: "13 groups" became physically obsolete long ago, but is engineering-wise impossible to overturn.

5. Key Takeaways

1. Historical reason: the 512-byte DNS-over-UDP limit → a mathematical ceiling of 15 groups → 13 chosen with headroom, fixed once M-root came online in 1997
2. Protocol inertia: upgrading the hint files on billions of endpoints is impractical, so it never changes
3. Real capacity: 1395+ anycast mirror nodes, making single-point failure risk near zero
4. Reachable from China: multiple root servers including F / I / J / K / L have mirrors in mainland China, with measured RTT < 20ms