What is the DNS hierarchy explained simply?

Sajjad
DNS
10 Oct, 2026

The DNS hierarchy is the tree-shaped structure that organises every domain name on the internet. At the very top is the root, written as a single dot. Below it are top-level domains (TLDs) such as .com, .org and .uk. Below those are second-level domains such as example.com, and below those are subdomains such as www.example.com or api.eu.example.com. Each level only knows about the level directly beneath it and hands off, or delegates, responsibility for the rest. That's what lets millions of independent organisations run their own part of DNS while the whole system still behaves like one global directory.

If you've ever wondered why domain names read from right to left, why a registrar can change your nameservers, or how a resolver finds an answer with no central database, the hierarchy is the answer. This article walks through each level of the tree, who operates it, how delegation ties the levels together, how a lookup moves down the tree, and how to see the hierarchy for yourself with dig.

Reading a Domain Name From Right to Left

A domain name is a list of labels separated by dots. The hierarchy runs from right to left, so the most general part is at the end and the most specific part is at the start.

Take api.eu.example.co.uk. and split it up:

Label	Level	What it is
`.` (the trailing dot)	Root	The top of the tree
`uk`	Top-level domain	The country-code TLD for the United Kingdom
`co`	Second level	A public category under `.uk` for companies
`example`	Third level	The domain an organisation registered
`eu`	Fourth level	A subdomain created by the domain owner
`api`	Fifth level	A further subdomain

The trailing dot is usually hidden. Browsers and most tools add it for you, but in zone files and dig output you'll see it, because it marks a name as fully qualified, meaning it's anchored at the root.

DNS also sets size limits on names:

Each label can be up to 63 characters long.
A full name can be up to 255 bytes in its wire format, which works out to 253 characters when written out normally.
Labels are compared without regard to case, so Example.COM and example.com are the same name.

Level 1: The Root

The root zone sits at the top of the tree. It doesn't contain any website addresses. Its only job is to say which nameservers are responsible for each TLD.

The root zone is managed by IANA, a function of ICANN, and is served by 13 named root server identities, a.root-servers.net through m.root-servers.net, run by 12 different organisations. Each of those 13 names is not a single machine. They use anycast, which lets many servers in different countries share the same IP address, so in practice there are well over a thousand root server instances worldwide.

You can list the root servers with dig:

dig . NS +short

a.root-servers.net.
b.root-servers.net.
c.root-servers.net.
d.root-servers.net.
e.root-servers.net.
f.root-servers.net.
g.root-servers.net.
h.root-servers.net.
i.root-servers.net.
j.root-servers.net.
k.root-servers.net.
l.root-servers.net.
m.root-servers.net.

Every recursive resolver ships with a small file called the root hints, listing the IP addresses of these servers. It's the one fixed starting point the whole system needs.

Level 2: Top-Level Domains

The next level holds the TLDs, the last label of any domain name. There are well over a thousand of them, grouped into a few broad categories:

Generic TLDs (gTLDs): Long-standing ones such as .com, .net and .org, plus newer ones such as .app, .dev, .shop and .london.
Country-code TLDs (ccTLDs): Two-letter codes for countries and territories, such as .uk, .de, .jp and .io.
Sponsored TLDs: Restricted to particular communities, such as .gov, .edu and .museum.
Infrastructure TLD: .arpa, used for technical purposes such as reverse DNS lookups.

Each TLD is run by a registry. Verisign operates .com and .net, Nominet operates .uk, and so on. The registry runs the TLD's nameservers, and those servers know which nameservers are responsible for every domain registered under that TLD.

dig com. NS +short

a.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.
...
m.gtld-servers.net.

Some ccTLDs add an extra public layer. In .uk, people can register directly under .uk or under categories like .co.uk and .org.uk. That's why example.co.uk is a registered domain even though it has three labels.

Level 3: Registered Domains

The level below a TLD (or below a public category like .co.uk) is where most organisations live. When you register example.com, you're asking the .com registry, through a registrar, to add a delegation for example.com that points to the nameservers you choose.

From then on, your chosen DNS provider runs the authoritative nameservers for example.com. They hold your zone: the actual A, AAAA, MX, TXT and other records.

dig example.com NS +short

ns1.example.net.
ns2.example.net.

This is the most important boundary in the hierarchy for most people. Above it, the registry and registrar control things. Below it, you do.

Level 4 and Below: Subdomains

Anything to the left of your registered domain is a subdomain that you control entirely. You can create www, mail, shop, api.eu and as many others as you like, simply by adding records to your zone:

$ORIGIN example.com.
@        3600  IN  A      192.0.2.10
www      3600  IN  A      192.0.2.10
shop     3600  IN  CNAME  shops.example.net.
api.eu   3600  IN  A      198.51.100.40

You don't need anyone's permission and nothing changes at the registry. If you want a team or a third party to manage a subdomain on its own servers, you can delegate it further, which is the same mechanism the root and TLDs use.

Delegation: How the Levels Connect

The glue that holds the hierarchy together is delegation. A parent zone doesn't store its children's records. Instead, it stores NS records that say "for this part of the tree, ask these servers".

The root zone contains NS records for com., pointing to the .com servers.
The .com zone contains NS records for example.com., pointing to your DNS provider.
Your zone can contain NS records for dev.example.com., pointing to a different set of servers if you want.

Here's what a delegation of a subdomain looks like inside your own zone file:

; Delegate dev.example.com to a separate set of nameservers
dev      86400  IN  NS  ns1.dev.example.com.
dev      86400  IN  NS  ns2.dev.example.com.

; Glue: addresses for nameservers that live inside the delegated zone
ns1.dev  86400  IN  A   203.0.113.53
ns2.dev  86400  IN  A   203.0.113.54

After this, the servers at 203.0.113.53 and 203.0.113.54 are authoritative for everything under dev.example.com. Your own nameservers simply refer queries to them.

Domains Versus Zones

Delegation is why a domain and a zone aren't always the same thing. The domain example.com includes every name beneath it. The zone example.com includes only the part you serve yourself. If you delegate dev.example.com, it's still part of your domain but now lives in its own zone, run by other servers.

How a Lookup Walks Down the Tree

When a recursive resolver needs an answer it hasn't cached, it starts at the top and follows delegations downwards:

Ask a root server for www.example.com. The root doesn't know, but replies with the .com nameservers. This is called a referral.
Ask a .com server. It doesn't know either, but refers the resolver to the nameservers for example.com.
Ask an example.com nameserver. This server is authoritative, so it returns the actual record.
Cache everything learned along the way, so the next lookup for anything under .com or example.com can skip steps.

You can watch this happen with dig +trace, which performs the same walk itself instead of relying on a resolver's cache:

dig +trace www.example.com A

.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 6 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
;; Received 1173 bytes from 198.41.0.4#53(a.root-servers.net) in 19 ms

example.com.		172800	IN	NS	ns1.example.net.
example.com.		172800	IN	NS	ns2.example.net.
;; Received 140 bytes from 192.12.94.30#53(e.gtld-servers.net) in 24 ms

www.example.com.	3600	IN	A	192.0.2.10
;; Received 60 bytes from 198.51.100.53#53(ns1.example.net) in 15 ms

Each block corresponds to one level of the hierarchy. The output has been shortened for readability; real output includes every NS record and, for signed zones, DNSSEC records too.

Caching Keeps the Top Quiet

If every lookup on the internet went through all those steps, the root and TLD servers would be overwhelmed. In practice, resolvers cache the root's referrals for days and the TLD referrals for a day or two, so most lookups jump straight to step 3. The hierarchy defines where answers come from, while caching makes it fast.

Who Controls What

The hierarchy also maps onto a chain of responsibility, which matters when something goes wrong or when you want to make a change.

Level	Example	Who operates it	What you can change
Root	`.`	IANA/ICANN, with 12 root server operators	Nothing
TLD	`com.`	The registry, such as Verisign	Nothing directly
Registered domain delegation	`example.com.` in the `.com` zone	The registry, updated by your registrar	Nameservers and DS records, via your registrar
Your zone	`example.com.`	You, through your DNS provider	All records
Delegated subdomain	`dev.example.com.`	Whoever runs those nameservers	Their records

This explains a common point of confusion. Changing your nameservers is done at your registrar, because those NS records live in the TLD zone. Changing a website's IP address is done at your DNS provider, because that record lives in your zone. If your registrar also hosts your DNS, both happen in one dashboard, but they're still two different levels of the tree.

Why DNS Uses a Hierarchy

A tree with delegation was a deliberate design choice, and it brings several benefits:

Scalability: No single server needs to know every name. Each server only knows its own zone and where to send people for the levels below.
Decentralised control: Registries, companies and individuals each manage their own parts without coordinating with one another.
Fault isolation: A failure in one zone, such as an outage at a DNS provider, affects only the domains hosted there, not the rest of the internet.
Unique names: Because each parent controls which children exist, the same name can't be registered twice in the same place.
Chains of trust: DNSSEC follows the same hierarchy, with each parent vouching for its child's keys, starting from a trust anchor at the root.

FAQ: DNS Hierarchy

The root zone, written as a single dot. It lists the nameservers for every top-level domain and is served by 13 named root server identities, each made up of many anycast instances around the world.

Technically, www is a subdomain of the registered domain. It's simply a name the domain owner chose to create, and it can point anywhere, including to a different server from the bare domain.

The TLD is the last label of a name, such as .com or .uk. The second-level domain is the label directly to its left, such as example in example.com, which is usually the part people register.

The .uk registry created public categories such as co.uk and org.uk beneath the TLD. Domains registered under them, like example.co.uk, sit one level lower in the tree but behave the same as any other registered domain.

No. Resolvers cache the root's answers for days and TLD answers for a day or two, so almost all lookups skip the root entirely. Root servers mostly handle cache refreshes and queries for names that don't exist.

Yes. You can add as many subdomains as you like by creating records in your zone, and you can delegate any subdomain to different nameservers by adding NS records for it.

Conclusion

The DNS hierarchy is a tree that starts at the root, branches into top-level domains, then into registered domains, and finally into whatever subdomains their owners create. Each level delegates the levels below it using NS records, so no single server has to know everything, and each organisation controls only its own branch.

Knowing the hierarchy makes everyday DNS tasks easier to reason about. Nameserver changes happen at the registrar because they live in the TLD's zone, record changes happen at your DNS provider because they live in yours, and a dig +trace shows you exactly which level is answering. With that mental model in place, most DNS behaviour stops being surprising.