DNS Architecture and Hierarchy

The DNS namespace is a tree. Understanding the tree is most of what you need to understand about how DNS works.

The Tree Structure

DNS names are hierarchical, read right to left. api.github.com. breaks down like this:

.                    ← root
└── com.             ← top-level domain (TLD)
    └── github.      ← second-level domain
        └── api.     ← subdomain (hostname)

That trailing dot in api.github.com. is real — it's the root label. Most clients and tools omit it, but it's always there conceptually. When you see it in a zone file, it's not a typo.

The hierarchy isn't just organizational. It's also administrative. Each level in the tree is a delegation boundary — authority for a subtree is delegated to a specific set of nameservers, who are then responsible for that zone and can further delegate pieces of it downward.

The Players

Root Servers

The root is where every resolution journey starts (or rather, where it would start if caching didn't short-circuit most of it). Root servers answer queries about TLDs — they'll tell you which nameservers are authoritative for .com, .org, .de, .eu, and so on.

There are 13 root server names: a.root-servers.net through m.root-servers.net. This is not 13 physical machines. It's 13 IP addresses (actually, 13 IPv4 addresses and 13 IPv6 addresses), each of which is anycast to hundreds of physical instances distributed around the world. As of early 2025, there are over 1,700 root server instances globally.

The "13" limit is a technical artifact of the original DNS design. A DNS response needed to fit in a single 512-byte UDP packet (more on this in lesson 5). The root hints file — the list of root server addresses that resolvers bootstrap from — had to fit in that constraint. 13 was the maximum that fit.

You can see the root server list yourself:

dig . NS

# Response includes:
;; ANSWER SECTION:
.    518400    IN    NS    a.root-servers.net.
.    518400    IN    NS    b.root-servers.net.
.    518400    IN    NS    c.root-servers.net.
# ... and so on through m.

TLD Servers

Below root are the TLD nameservers. There are two main categories:

Generic TLDs (gTLDs): .com, .org, .net, .info, .biz, and the roughly 1,200 new gTLDs introduced after ICANN's 2012 expansion round (.tech, .online, .app, .io, and many others).

Country Code TLDs (ccTLDs): .de, .fr, .uk, .eu, .ma, .lu — two-letter codes assigned to countries and territories per ISO 3166-1.

.com is operated by Verisign. .org by Public Interest Registry. .lu by RESTENA. Each TLD operator runs their own nameserver infrastructure and maintains the registry of second-level domains registered under that TLD.

Query the TLD nameservers directly:

dig com. NS

# Shows you Verisign's nameservers for .com
;; ANSWER SECTION:
com.    172800    IN    NS    a.gtld-servers.net.
com.    172800    IN    NS    b.gtld-servers.net.
# ... through j.gtld-servers.net

Authoritative Nameservers

These are the servers that actually hold your zone data. When you register a domain and set NS records, you're pointing to authoritative nameservers. When the TLD registry gets a query for your domain, it delegates to those nameservers.

For github.com, that's currently NS67.DOMAINCONTROL.COM and NS68.DOMAINCONTROL.COM (GoDaddy's nameservers). You can check:

dig github.com NS +short
# ns-1622.awsdns-10.co.uk.
# ns-1283.awsdns-32.org.
# ns-421.awsdns-52.com.
# ns-692.awsdns-22.net.

(GitHub uses AWS Route 53 for DNS — four nameservers across four different TLDs, which is good practice for resilience.)

Authoritative nameservers give definitive answers for their zones. When you get a response with the aa (Authoritative Answer) flag set, you're hearing it from the source.

Resolvers

Resolvers are the client-side of DNS. When your browser needs to look up api.github.com, it asks a resolver. The resolver does the work of traversing the hierarchy, collecting referrals, following delegations, and returning an answer. Then it caches that answer.

Most users' DNS resolver is either their ISP's resolver or a public one (8.8.8.8 for Google, 1.1.1.1 for Cloudflare, 9.9.9.9 for Quad9). On your machine, /etc/resolv.conf shows which resolver you're configured to use.

Resolvers are sometimes called "recursive resolvers" — the name refers to the recursive query process they perform on your behalf. As a client, you send one query. The resolver does 3-10 queries (root, TLD, authoritative) and returns you the final answer.

The Delegation Model

Delegation is the mechanism that makes DNS scale. A parent zone delegates authority for a subdomain by including NS records pointing to the child zone's nameservers, plus "glue" A records with the IP addresses of those nameservers (needed when the nameserver hostname is within the delegated zone itself — otherwise you'd have a chicken-and-egg problem).

Example: the .com zone doesn't store GitHub's A records. It stores a delegation:

github.com.    172800    IN    NS    ns-1622.awsdns-10.co.uk.
github.com.    172800    IN    NS    ns-1283.awsdns-32.org.
# etc.

This is a referral. A resolver following this delegation will go ask those nameservers directly for the actual records.

Walking the Hierarchy with `dig +trace`

The +trace flag is one of the most useful debugging tools in your DNS toolkit. It makes dig perform the entire resolution process iteratively from root, showing every step:

dig +trace github.com A

Output (abbreviated):

.    518400    IN    NS    a.root-servers.net.
# ... (root server list)
;; Received 228 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

com.    172800    IN    NS    a.gtld-servers.net.
# ... (com TLD nameservers)
;; Received 492 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

github.com.    172800    IN    NS    ns-1622.awsdns-10.co.uk.
# ... (github's nameservers)
;; Received 672 bytes from 192.5.6.30#53(a.gtld-servers.net) in 15 ms

github.com.    60    IN    A    140.82.121.4
;; Received 76 bytes from 205.251.194.206#53(ns-421.awsdns-52.com) in 11 ms

Three hops: root to .com, .com to github.com's nameservers, github.com's nameservers to the answer. Each step shows you exactly which server responded and how long it took.

Run this a few times against different domains. You'll quickly develop intuition for what a normal resolution looks like — and what a broken one looks like.

Why the Hierarchy Is Brilliant

It scales. There's no single database of all domain names. The responsibility is split across thousands of independently operated servers. No single authority can become a bottleneck for the entire namespace.

It's resilient. Each zone can have multiple authoritative nameservers. The TLDs have massively redundant infrastructure. Root servers are anycast to hundreds of locations. The system survives individual server failures routinely.

It enables independent administration. GitHub manages github.com. AWS manages amazonaws.com. You manage yourdomain.com. No coordination required beyond the initial delegation.

Why It's Occasionally Maddening

That same independence means delegation failures cascade. If your registrar sets the wrong NS records in the TLD zone, your domain vanishes from the internet even though your nameservers are healthy. If your nameserver is unreachable, every query for your zone times out or returns SERVFAIL. The failure mode is "entire domain stops working," not "one thing is slow."

Caching at every layer means problems take time to appear and take time to disappear. A bad record cached at a resolver with a 24-hour TTL will keep serving wrong answers for 24 hours after you fix it. This is not a bug — it's the performance trade-off built into the design.

And the 13-root-server constraint, while solved technically with anycast, occasionally causes confusion. People see 13 servers and think "single points of failure." They're not. But you have to understand the anycast architecture to know that.

Key Takeaways

DNS is a tree. Names are hierarchical, read right to left, with the root at the top.
The hierarchy maps to administrative delegation: root → TLD → authoritative nameserver → zone data.
The "13 root servers" are 13 anycast addresses served by 1,700+ physical instances worldwide.
Resolvers do the recursive work on behalf of clients; authoritative servers hold the actual zone data.
dig +trace shows every step of the resolution path. Use it.

Up Next

You know the structure. Now let's look at what actually lives in those zones: DNS record types and what each one does in practice.