Tautik Agrahari

07 SEPT 2025 · 5 MIN READ

13 Root Name Servers - The Foundation of the Internet

#networking

Why do we need root name servers? Because someone has to be the ultimate starting point when your computer needs to find anything on the internet. It's a chicken-and-egg problem: to find a website, you need DNS, but to find DNS servers, you need... DNS.

what you'll take away

quick pointers so you know what to look for as you read:

  • the root solves a bootstrap problem. you'd need dns to find dns — so the root addresses are hardcoded into every resolver on earth.
  • 13 is a packet constraint, not a machine count. the full list has to fit in a single udp response.
  • anycast turns 13 addresses into hundreds of servers. the same ip announced from many places; routing takes you to the nearest one.
  • root servers are dumb on purpose. they only know who handles each tld — a ~2kb file that changes maybe twice a year.
  • resilience comes from caching plus redundancy. 9 of 13 got ddos'd in 2002 and almost nobody noticed.

The Bootstrap Problem

Here's the challenge: when you want to resolve google.com, your computer needs to ask a DNS server. But how do you find that DNS server's address?

Root name servers solve this by being hardcoded starting points. Every DNS resolver in the world has the same 13 IP addresses burned into its code.

✽ RECALL to resolve a name you need a dns server, but finding a dns server needs dns — how does the system break out of that loop?

by hardcoding the starting point. every resolver ships with the same root server addresses burned in, so there's always somewhere to begin without resolving anything first. the root is the one agreement the whole internet shares.

The Sacred 13

There are exactly 13 root name server identities :

 
a.root-servers.net    198.41.0.4       (VeriSign)
b.root-servers.net    199.9.14.201     (USC)
c.root-servers.net    192.33.4.12      (Cogent)
d.root-servers.net    199.7.91.13      (U of Maryland)
e.root-servers.net    192.203.230.10   (NASA)
f.root-servers.net    192.5.5.241      (ISC)
g.root-servers.net    192.112.36.4     (US DOD)
h.root-servers.net    198.97.190.53    (US Army)
i.root-servers.net    192.36.148.17    (Netnod)
j.root-servers.net    192.58.128.30    (VeriSign)
k.root-servers.net    193.0.14.129     (RIPE NCC)
l.root-servers.net    199.7.83.42      (ICANN)
m.root-servers.net    202.12.27.33     (WIDE Project)

Why exactly 13? Technical limit. The complete list must fit in a single UDP packet (512 bytes), which allows about 13 IPv4 addresses plus protocol overhead.

✽ RECALL what's the actual constraint that caps the number of root server identities?

the full list of root servers must fit inside a single classic udp dns response — one unfragmented packet. that budget holds roughly a dozen ipv4 addresses plus protocol overhead, and that's where the cap comes from. it's a wire-format limit, not a statement about how many machines exist.

Physical vs Logical Reality

13 logical servers = hundreds of physical servers.

Each "root server" is actually hundreds of physical machines distributed globally. They all announce the same IP address using anycast routing. When you contact a.root-servers.net, the internet routes you to the nearest physical server advertising that IP.

[TODO: Write about anycast and link the reference in here]

 
You in New York → Connects to a.root-servers.net in New York
Someone in Tokyo → Connects to a.root-servers.net in Tokyo
(Same logical server, different physical servers)
✽ RECALL how can 13 ip addresses serve every resolver on earth without melting?

because they aren't 13 machines — each identity is hundreds of physical servers worldwide all announcing the same ip via anycast. internet routing delivers your query to the nearest one, so a new york query and a tokyo query hit the "same" address but different hardware. capacity scales by adding instances, not addresses.

What Root Servers Actually Do

Root servers are surprisingly simple. They only know which servers handle each top-level domain (.com, .org, etc.).

When you ask about www.google.com:

  • You: "Where's www.google.com?"
  • Root Server: "I don't know about google.com, but all .com domains are handled by these TLD servers: [list of IPs]. Go ask them."

That's it. They're just a directory of TLD authorities.

✽ RECALL what does a root server actually answer when you ask it for www.google.com?

it doesn't know google.com at all — it replies "all .com domains are handled by these tld servers, go ask them." root servers are just a directory of tld authorities serving a tiny (~2kb) zone file that rarely changes; their whole job is delegation, which is exactly why they can stay simple and fast.

The Root Zone File: 2KB That Controls the Internet

All root servers serve identical data from the root zone file (about 2KB):

 
com.    172800  IN  NS  a.gtld-servers.net.
org.    172800  IN  NS  a0.org.afilias-nst.info.
edu.    172800  IN  NS  a.edu-servers.net.

This tiny file is managed by ICANN and updated rarely - maybe twice per year.

How They Handle Massive Scale

Root servers handle hundreds of billions of queries daily through:

Heavy Caching: Responses are cached for 48 hours. Once your resolver knows where .com servers are, it doesn't ask root servers again for 2 days.

Geographic Distribution: Each logical root server has dozens of physical locations worldwide.

Anycast Load Balancing: Queries automatically go to the nearest, least-loaded server.

Governance and Resilience

12 different organizations operate the servers - no single entity controls them all. This creates natural redundancy where individual outages (which happen regularly) don't affect the internet because:

  • 12 others keep running
  • Everything is heavily cached
  • DNS resolvers try multiple root servers
  • Each "server" is hundreds of physical machines

In 2002, 9 of 13 root servers were attacked by DDoS. Most users never noticed due to caching and redundancy.

✽ RECALL attackers ddos'd most of the root servers in 2002 and users never noticed — why?

layered redundancy. answers are cached for ~48 hours, so resolvers rarely ask the root at all; resolvers automatically retry across the remaining identities; and each identity is hundreds of anycast machines run by 12 independent operators. you'd have to take out nearly everything, everywhere, for longer than the caches last.

The Takeaway

Those 13 IP addresses are among the most important numbers on the internet. They're hardcoded into every DNS resolver and serve as the starting point for every domain lookup.

Every time you type a URL, somewhere in that process your request traces back to these 13 starting points. They don't need to know everything - they just need to know where to send you next.

That's the beauty: 13 simple numbers that make the entire internet's naming system possible.

✽ ❦ ✽

← all posts