The DNS Hierarchy

Why this matters: the hierarchy is the answer to "how does one system hold every name on the internet without any node holding all of them?" It is a textbook example of scaling through delegation, and it is why DNS still works at a scale nobody designed for in 1983.

Key takeaway

DNS is not a single server. It is a vast infrastructure of name servers organized in a hierarchy, where each tier knows only enough to point you at the next one. No server knows every name; every server knows who to ask.

The four types of server

Tier	Role	Where it lives	What it returns
DNS resolver	Initiates the query sequence on the client's behalf	The user's network — ISP or local network	The final answer, often from its own cache
Root name server	Entry point of the hierarchy	Globally distributed	The TLD servers for the relevant suffix
TLD name server	Maintains addresses of authoritative servers per domain	Per top-level domain	The organization's authoritative name servers
Authoritative name server	The final destination — holds the real records	Operated by (or for) the organization	The actual IP address

Spelled out:

DNS resolver — initiates the query sequence. Resolvers typically sit within the user's network (ISP or local network) and often cache results locally to answer future queries, serving as the default server for users.
Root-level name servers — the entry point. They direct requests to the appropriate top-level domain servers. A request for educative.io prompts the root server to return a list of .io TLD servers.
Top-level domain (TLD) name servers — these maintain the IP addresses of authoritative name servers, providing the querying party with the location of the organization's specific servers.
Authoritative name servers — the final destination. These belong to the organization and provide the actual IP addresses for the requested web or application servers.

Visually the hierarchy forms a tree, starting from the root domain at the top and branching out to subdomains.

Names are read right to left

DNS names are processed from right to left, unlike UNIX file paths which go left to right. Resolving educative.io, the resolver first looks up .io, then educative.

UNIX path:   /home/user/docs      ->  read left to right
DNS name:    educative.io         ->  read RIGHT to LEFT

              educative . io
                  ^        ^
                  2nd      1st

There is an implicit trailing dot — educative.io. — representing the root. It is almost always omitted, but it is why the root is the true starting point of every lookup.

How delegation actually works

The NS record from the previous lesson is the mechanism. Each tier holds NS records pointing at the tier below:

Server	Knows	Does NOT know
Root	The name servers for every TLD (.com, .io, .edu)	Anything about educative.io
.io TLD	The authoritative servers for every .io domain	The IP of any particular host
educative.io authoritative	Every record inside educative.io	Anything outside its own zone

Each tier stores a small amount of information and delegates the rest. The total system holds every name on the internet; no participant holds more than a manageable slice.

Key takeaway

The hierarchy scales because responsibility is divided rather than replicated: root servers direct traffic, TLD servers filter by domain type, and authoritative servers hold the actual records. Each tier's job is small, and the tree is only as deep as the name.

Interview signal by level

Level	What a strong answer sounds like
L4	"There are root servers and authoritative servers."
L5	Walks the tiers: "resolver, root, TLD, authoritative — each one points to the next until you get an A record."
Staff+	Explains why it scales: "delegation via NS records means each tier holds a small slice and adding a domain touches one TLD server. Right-to-left resolution is what makes that possible — the root never needs to know a single hostname."

Next: who does the walking — the client, or the servers?