JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

The DNS Hierarchy: Root, TLDs, and Zones

The Internet's phone book is far too big for any one book and far too important for any one owner. This guide shows how DNS solves both problems at once with a single elegant idea: a tree of names, sliced into zones and handed out by delegation.

One phone book is impossible

In the previous guide you met the problem and its shape: humans want names like example.com, machines need addresses like 192.168.1.10, and the Domain Name System is the phone book that turns one into the other. But pause on just how big that phone book would have to be. There are hundreds of millions of registered names, billions of devices, and the list changes thousands of times every second as sites move, scale, and disappear. No single file could hold it, no single server could serve it without melting, and — just as important — nobody would agree to let one company own the only copy.

So DNS does not build one phone book at all. It builds a structure — a way of carving the giant problem into millions of tiny, independent pieces, each owned and answered by whoever is responsible for it. The whole of DNS is really just two ideas working together: a hierarchy that organizes every possible name into a tree, and delegation that lets each branch of that tree be handed to a different owner. Master those two words and the rest of this rung — resolvers, records, caching — becomes detail hanging off a frame you already understand.

Reading a name from right to left

Start with a single name and look at it the way DNS does. A domain name like www.example.com is not one blob; it is a path made of labels separated by dots, and the surprise is that it is most significant on the right. Read it right to left and you are walking down a tree from the trunk: first an invisible root, then com, then example, then www. Each dot is a step deeper into a more specific part of the whole DNS namespace — the single global tree that contains every name that can ever exist.

                    (root)            <- the empty label, the trunk
                   /  |   \
                 com  org   uk         <- top-level domains (TLDs)
                 /          \
           example         co           <- second level
            /   \           \
          www   mail        bbc          <- where real hosts live

        www . example . com . (root)
         |       |       |      |
        host  who you   TLD   the empty
              registered      label
The namespace is one tree. A name like www.example.com is a path read right to left: from the unnamed root, down to a top-level domain, down to the part someone registered, down to an individual host.

That trailing dot after com is real, even though you almost never type it. It stands for the root: the empty label at the top of the tree, the common ancestor of every name on the Internet. A name written all the way down to the root, like www.example.com. with that final dot, is called fully qualified — it is unambiguous, a complete path from leaf to trunk. When you leave the dot off, software simply assumes you meant it. So every lookup, no matter how exotic the name, begins conceptually at the same single place: the root.

Root and TLDs: the top of the tree

At the very top sit the root name servers. Their job is deliberately tiny: they do not know where example.com lives, and they were never meant to. The root knows only one thing — for each top-level domain (TLD) like com, org, net, jp, or uk, which servers are in charge of it. Ask the root about www.example.com and it does not answer; it simply says, in effect, 'I do not handle that, but the servers for com do, and here is how to reach them.' That single, narrow answer is what keeps the busiest layer of DNS from drowning.

TLDs come in two broad flavours, and the distinction is worth knowing. Generic TLDs (gTLDs) such as com, org, info, and the newer ones like xyz or app are organized around purpose or theme. Country-code TLDs (ccTLDs) such as uk, de, jp, and tw are two-letter codes tied to a country or territory, usually run by an organization in that place. Below a TLD, the same pattern repeats: the com servers do not know your website's address either; they only know who runs example under com. The tree delegates responsibility one level at a time, all the way down.

Zones and delegation: who actually owns a name

Here is the idea that ties the tree to the real world. A zone is the chunk of the namespace that one administrator actually manages as a single editable unit. It is tempting to think 'domain' and 'zone' are the same thing, but they are not, and the difference is the whole game. A domain is a name and everything conceptually beneath it; a zone is the slice of that domain you are personally responsible for, stopping wherever you hand a sub-part off to somebody else.

That handing-off is delegation, and it is what makes DNS scale and stay decentralized. When the operator of com lets you register example.com, they do not start managing your records for you. Instead, in the com zone, they place a small signpost — a pointer that says 'for anything under example.com, go ask these other servers instead.' Those servers, which you control, become the authoritative name servers for the example.com zone: the single source of truth for that slice. Authoritative means their answer is the real answer, straight from the owner, not a copy someone cached along the way.

So a zone is bounded precisely by its delegations. The com zone holds the signposts for millions of names but the actual records for none of them; your example.com zone holds the real records for www, mail, and the rest — unless you, in turn, delegate, say, eu.example.com to a colleague, at which point that becomes a separate zone with its own owner. The tree of names is thus quietly cut into a patchwork of zones, each a small, self-contained phone book that one party edits and serves, stitched to its neighbours only by these one-way pointers. No central list, no single owner: just a chain of 'go ask them instead' from the root downward.

Following the signposts: a delegation chain

Let us trace how the tree actually answers a question, staying at the level of the hierarchy itself — the full step-by-step resolution, including caching and the resolver's own cleverness, is the very next guide's job. What matters here is to see that each layer answers only for its own zone and then points one step further down. Imagine you want the address behind www.example.com and ask the system to follow the signposts.

  1. Ask a root server about www.example.com. The root does not know it, but it owns the top of the tree, so it replies with a referral: 'I don't have that, but here are the authoritative servers for the com TLD.'
  2. Ask a com server the same question. The com zone holds the delegation for example.com, so it replies with another referral: 'I don't have that either, but example.com is delegated to these name servers — go ask them.'
  3. Ask one of example.com's authoritative name servers. This time the server actually owns the zone that contains www.example.com, so instead of a referral you finally get the real answer: the address itself, marked authoritative.
  4. Three questions, three layers, and at every step the answer was either 'here is the truth' or 'here is who to ask next.' No server ever had to know more than its own zone — that is exactly why the system scales to the whole Internet.

Where registrars fit, and what to carry forward

One practical question remains: how does your example.com end up in the com zone in the first place? You do not phone the operator of com directly. You go through a domain registrar — an accredited company that takes your money and your choice of name and, on your behalf, asks the registry that runs com to add the delegation. Roughly, a registry owns the master list for a TLD; a registrar is a retailer authorized to add and edit entries in it. When you 'buy a domain', you are really renting the exclusive right to control one branch of the tree for a year or two, plus the registry's promise to keep your delegation signpost in place.

It is worth being honest about a subtlety here: registering a name and serving its records are two separate jobs, and they need not be the same company. The registrar gets your delegation written into the TLD zone (the NS records pointing to your name servers); a DNS hosting provider, possibly someone else entirely, actually runs those authoritative name servers and answers queries about your zone. Many people use one company for both and never notice the seam — but they are genuinely different roles, and confusing them is a classic cause of 'I bought the domain, why doesn't anything work yet?'

Step back and the shape is clear. DNS is not a phone book; it is a tree of names, cut into zones, joined by delegation, and rooted in a tiny set of servers that know only how to point downward. That single design buys three things at once: it scales, because every owner manages only their own slice; it stays robust and decentralized, because no one holds the whole thing; and it lets ownership and editing be local. The next guide takes this static map and sets it in motion — the resolver that walks the chain for you, and why it can answer most questions without ever touching the root at all.