DNS Root Servers

Websitehttps://www.iana.org/domains/root/servers
CategoryLive Runtime Lookups

The 13 DNS root server clusters, labeled A through M and operated by 12 independent organizations, form the top of the DNS hierarchy. Every domain name resolution on the internet ultimately traces back to these root servers, which direct resolvers to the authoritative nameservers for each top-level domain. We perform recursive DNS resolution starting from these root servers on dns.ninja and robtex.com.

Source:DNS Root Servers

What are DNS Root Servers?

The Domain Name System is a hierarchical, distributed naming system. When a DNS resolver needs to look up a domain like www.example.com, it follows a chain of authority: the root servers know which nameservers handle .com, those nameservers know which nameservers handle example.com, and those nameservers return the final answer.

The 13 root server identities (a.root-servers.net through m.root-servers.net) are operated by:

  • A - Verisign
  • B - USC Information Sciences Institute
  • C - Cogent Communications
  • D - University of Maryland
  • E - NASA Ames Research Center
  • F - Internet Systems Consortium (ISC)
  • G - US Defense Information Systems Agency
  • H - US Army Research Lab
  • I - Netnod (Sweden)
  • J - Verisign
  • K - RIPE NCC
  • L - ICANN
  • M - WIDE Project (Japan)

Despite the name "13 servers," each root server identity is actually a cluster of many physical servers distributed globally using anycast routing. The total number of root server instances exceeds 1,500, deployed across hundreds of locations on every continent. Anycast ensures that DNS queries are automatically routed to the nearest instance, providing low latency and resilience against localized failures.

The root zone file, which all root servers serve, contains delegation records (NS and associated A/AAAA glue records) for approximately 1,500 top-level domains including generic TLDs (.com, .org, .net), country-code TLDs (.uk, .de, .jp), and newer TLDs (.app, .dev, .xyz). IANA maintains the root zone, with changes coordinated through ICANN's processes.

How We Use This Data

On dns.ninja and robtex.com, we perform full recursive DNS resolution starting from the root servers. Rather than simply querying a local caching resolver that returns a pre-cached answer, our DNS lookup tools walk the full delegation chain: root server, TLD nameserver, authoritative nameserver.

This recursive approach provides several advantages for our users:

  • Transparency - You can see exactly which servers were queried at each level of the hierarchy, revealing the full delegation path
  • Freshness - Querying authoritative servers directly bypasses caching, showing the current state of DNS rather than potentially stale cached records
  • Delegation analysis - By starting at the root, we can identify misconfigured delegations, lame delegations (nameservers that do not answer for a domain), and inconsistencies between parent and child zones

Our recursive resolver queries root servers for TLD delegations, then follows the chain down to the authoritative nameservers for the domain being looked up. The entire delegation path is displayed to the user, making DNS resolution transparent rather than opaque.

FAQ

Why are there exactly 13 root server identities and not more?
The limitation comes from the original DNS protocol design. A DNS response must fit within a single UDP packet (originally 512 bytes). The root server list, including both names and IP addresses, must fit within this constraint. Thirteen identities with both IPv4 and IPv6 addresses is close to the maximum that fits. In practice, anycast means these 13 identities represent over 1,500 physical servers, so the "13" is a naming convention, not a capacity limit.
What happens if all root servers go down?
A simultaneous failure of all root server instances globally is essentially impossible due to anycast distribution across hundreds of locations and the operational independence of the 12 operating organizations. However, even if it hypothetically occurred, the internet would not immediately break. DNS resolvers cache root server responses, and most queries are answered from cache without ever reaching a root server. It would take hours to days before the effects became widely noticeable, as cached TLD delegations expired.
How does querying root servers differ from using a public resolver like 8.8.8.8?
Public resolvers like Google's 8.8.8.8 or Cloudflare's 1.1.1.1 are recursive caching resolvers that do the root-to-authoritative resolution on your behalf and cache the results. When you query them, you get a cached answer without seeing the delegation chain. Our approach queries each level of the hierarchy independently, showing you the full resolution path. This is slower but provides complete visibility into how DNS actually works for a given domain.