{"id":4259,"date":"2026-11-03T13:47:00","date_gmt":"2026-11-03T13:47:00","guid":{"rendered":"https:\/\/www.ucartz.com\/blog\/dns-root-servers\/"},"modified":"2026-11-09T22:04:56","modified_gmt":"2026-11-09T22:04:56","slug":"dns-root-servers","status":"publish","type":"post","link":"https:\/\/www.ucartz.com\/blog\/dns-root-servers\/","title":{"rendered":"What Are DNS Root Servers? How the Top of DNS Works"},"content":{"rendered":"\n

The DNS root servers are the name servers for the root zone, the very top of the Domain Name System. They do not know the IP address of your website. They know which servers are responsible for each top-level domain, such as .com, .org or .in, and they point resolvers there. There are 13 root server names, a.root-servers.net<\/code> to m.root-servers.net<\/code>, run by 12 independent organisations, and each name is served by many copies around the world through anycast.<\/p>\n\n\n\n

\"Terminal
The root zone lists the 13 root server names (a to m), and a root server hands out the .com name servers instead of answering itself<\/figcaption><\/figure>\n\n\n\n

Where the root fits in a DNS lookup<\/h2>\n\n\n\n

A DNS name is read from right to left. www.ucartz.com.<\/code> ends in an invisible dot, and that dot is the root. When a resolver has nothing cached, it asks a root server first, then the servers for the top-level domain, then the domain’s own nameservers. You can watch the whole chain with dig +trace<\/code>. This is our run from a Debian 13 container with dig 9.20.29, trimmed to the important lines:<\/p>\n\n\n\n

$ dig +trace +nodnssec www.ucartz.com A\n.            508216  IN  NS  a.root-servers.net.\n.            508216  IN  NS  b.root-servers.net.\n...          (13 root servers)\ncom.         172800  IN  NS  a.gtld-servers.net.\n...\n;; Received 839 bytes from 192.203.230.10#53(e.root-servers.net) in 58 ms\nucartz.com.  172800  IN  NS  todd.ns.cloudflare.com.\nucartz.com.  172800  IN  NS  liz.ns.cloudflare.com.\n;; Received 358 bytes from 192.12.94.30#53(e.gtld-servers.net) in 274 ms\nwww.ucartz.com.  300  IN  A  104.21.24.238\nwww.ucartz.com.  300  IN  A  172.67.221.9<\/code><\/pre>\n\n\n\n
Read it in three steps. The root server (E, in this run) did not answer the question; it replied with the list of .com servers. A .com server replied with the domain’s nameservers. Only those nameservers returned the actual address. The root server’s job is that first referral and nothing more.<\/p>\n\n\n\n
Ask a root server directly and you see the same thing. The reply has no answer, only a referral, and no ra<\/code> (recursion available) flag, because root servers do not look names up for you:<\/p>\n\n\n\n
$ dig @a.root-servers.net www.ucartz.com A +norec\n;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27\n;; AUTHORITY SECTION:\ncom.   172800  IN  NS  l.gtld-servers.net.\ncom.   172800  IN  NS  j.gtld-servers.net.\n...<\/code><\/pre>\n\n\n\n
That is also why you cannot use a root server as your computer’s DNS server. You need a recursive resolver, such as your ISP’s, a public one, or one you run yourself.<\/p>\n\n\n\n
The 13 root servers and who runs them<\/h2>\n\n\n\n
This is the list published by IANA<\/a>. Two letters, A and J, belong to the same operator, which is why 13 names come from 12 organisations.<\/p>\n\n\n\n
Root server<\/th>IPv4 address<\/th>Operator<\/th><\/tr><\/thead>
a.root-servers.net<\/td>198.41.0.4<\/td>Verisign, Inc.<\/td><\/tr>
b.root-servers.net<\/td>170.247.170.2<\/td>University of Southern California, Information Sciences Institute<\/td><\/tr>
c.root-servers.net<\/td>192.33.4.12<\/td>Cogent Communications<\/td><\/tr>
d.root-servers.net<\/td>199.7.91.13<\/td>University of Maryland<\/td><\/tr>
e.root-servers.net<\/td>192.203.230.10<\/td>NASA (Ames Research Center)<\/td><\/tr>
f.root-servers.net<\/td>192.5.5.241<\/td>Internet Systems Consortium, Inc.<\/td><\/tr>
g.root-servers.net<\/td>192.112.36.4<\/td>US Department of Defense (NIC)<\/td><\/tr>
h.root-servers.net<\/td>198.97.190.53<\/td>US Army (Research Lab)<\/td><\/tr>
i.root-servers.net<\/td>192.36.148.17<\/td>Netnod<\/td><\/tr>
j.root-servers.net<\/td>192.58.128.30<\/td>Verisign, Inc.<\/td><\/tr>
k.root-servers.net<\/td>193.0.14.129<\/td>RIPE NCC<\/td><\/tr>
l.root-servers.net<\/td>199.7.83.42<\/td>ICANN<\/td><\/tr>
m.root-servers.net<\/td>202.12.27.33<\/td>WIDE Project<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Each server also has an IPv6 address. RFC 7720<\/a> sets the ground rules for all of them: they must answer over IPv4 and IPv6, over UDP and TCP, and must support DNSSEC and EDNS(0).<\/p>\n\n\n\n
Why only 13, and why that is not really true<\/h2>\n\n\n\n
The number comes from an old size limit. The RSSAC FAQ<\/a> (ICANN’s Root Server System Advisory Committee) explains that RFC 1035 restricted DNS messages over UDP to 512 bytes, and adding more root server names would have made the answer listing them bigger than that. So the list stopped at 13 names.<\/p>\n\n\n\n
The number of machines is a different matter. Each name is served with anycast<\/strong>: the same IP address is announced from many locations, and the internet’s routing sends your query to a nearby one. The root server operators’ shared site, root-servers.org, lists more than 2,000 operational instances. You can ask a root server which instance answered you with a special query in the CHAOS class:<\/p>\n\n\n\n
$ for s in a k l f; do echo -n \"$s: \"; dig @$s.root-servers.net id.server CH TXT +short; done\na: \"nnn1-jptyo-2\"\nk: \"ns1.in-mai.k.ripe.net\"\nl: \"in-jai-aa\"\nf: \"MAA.cf.f.root-servers.org\"<\/code><\/pre>\n\n\n\n
Each reply is the operator’s own label for the machine that answered, not one central server. Run the same loop from another country and you will most likely get different labels. This is also what makes the root hard to take down: an attack on one address is spread over many sites, and a resolver that gets no reply from one root server simply tries another.<\/p>\n\n\n\n
How a resolver finds the root servers<\/h2>\n\n\n\n
A resolver cannot look up the root servers without already knowing one of them, so every resolver ships with a small file called the root hints<\/strong>. IANA publishes it on its root files page<\/a>, describing it as the names and IP addresses of the root zone’s name servers, “so the software can bootstrap the DNS resolution process”. On Debian 13 it comes in the dns-root-data<\/code> package:<\/p>\n\n\n\n
$ grep -v '^;' \/usr\/share\/dns\/root.hints | head -3\n.                        3600000      NS    A.ROOT-SERVERS.NET.\nA.ROOT-SERVERS.NET.      3600000      A     198.41.0.4\nA.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30<\/code><\/pre>\n\n\n\n
The hints are only a starting point. RFC 8109<\/a> calls the next step priming<\/strong>: the resolver asks one of those addresses for the current list of root servers and then treats that answer like any other DNS data in its cache. So an outdated hints file still works, as long as at least one of its addresses answers. The root’s NS records carry a TTL of 518400 seconds, six days, so a busy resolver refreshes that list about every six days.<\/p>\n\n\n\n
Who controls the root zone?<\/h2>\n\n\n\n
The root servers publish the root zone; they do not decide what goes in it. According to IANA<\/a>, its root zone work includes assigning managers for top-level domains, recording their technical delegation data in the root zone and publishing the Root Zone Database, the authoritative record of every top-level domain and the organisation that manages it. The IANA functions are provided by Public Technical Identifiers, an affiliate of ICANN. Every root server then serves the same copy. You can see the current version in the SOA record, whose serial number is a date plus a two-digit counter:<\/p>\n\n\n\n
$ dig @a.root-servers.net . SOA +norec +noall +answer\n.  86400  IN  SOA  a.root-servers.net. nstld.verisign-grs.com. 2026092901 1800 900 604800 86400<\/code><\/pre>\n\n\n\n
The root zone is signed with DNSSEC, and validating resolvers carry the root’s key as their trust anchor; Debian’s dns-root-data<\/code> package describes itself as “DNS root hints and DNSSEC trust anchor”. If you want to know what a top-level domain is and how to choose one, read What Is a TLD?<\/a><\/p>\n\n\n\n
Do root servers see every DNS query?<\/h2>\n\n\n\n
No. The RSSAC FAQ says most queries are handled by recursive resolvers from data they already have in their caches, without any contact with a root server. The TTLs explain why. In the trace above, the .com referral had a TTL of 172800 seconds, so a resolver that has looked up any .com name recently does not ask the root about .com again for up to two days. A root server mostly hears from a resolver after a restart, when a referral has expired, or when someone looks up a top-level domain the resolver has not seen recently.<\/p>\n\n\n\n
Running a copy of the root on your own resolver<\/h2>\n\n\n\n
If you run your own resolver, you can skip the root servers entirely. RFC 8806<\/a> describes keeping a full, DNSSEC-validated copy of the root zone on the resolver itself, which cuts round trips, keeps working if remote root servers are under attack and stops outsiders from observing those queries. The RFC only allows this copy to serve the resolver on the same machine, not other systems.<\/p>\n\n\n\n
BIND calls this a mirror zone<\/strong>. The BIND reference manual<\/a> says the root’s primary servers are built into named<\/code>, so one line in the configuration of a recursive BIND server is enough:<\/p>\n\n\n\n
zone \".\" { type mirror; };<\/code><\/pre>\n\n\n\n
We added it to BIND 9.20.29 on Debian 13. Seconds after starting, the log showed the transfer and rndc<\/code> confirmed a validated copy:<\/p>\n\n\n\n
zone .\/IN: transferred serial 2026092901\nzone .\/IN: mirror zone is now in use\n\n$ rndc zonestatus .\nname: .\ntype: mirror\nserial: 2026092901\nnodes: 7365\nsecure: yes<\/code><\/pre>\n\n\n\n
According to the manual, BIND validates the whole zone with DNSSEC on every transfer, answers from the mirror with the ad<\/code> flag but without aa<\/code>, and falls back to normal recursion if no valid copy is available. It needs recursion enabled, so it is for resolvers only.<\/p>\n\n\n\n
Quick answers<\/h2>\n\n\n\n