People talk about "the DNS server" as though there were one of them. There are four, they sit at different heights in a hierarchy, and each one knows something the others do not. Understanding the DNS server layers is the difference between guessing at a broken lookup and knowing which machine to interrogate first. This guide walks the whole chain — from the root of the namespace down to the cache on your own laptop.
What Is DNS, and Why Do the Layers Exist?
Every device on the internet is reachable by an IP address, a number like 93.184.216.34or 2606:2800:220:1:248:1893:25c8:1946. Numbers are how machines route traffic. Names are how people remember destinations. The Domain Name System is the translation layer between the two: you supply www.example.com, DNS supplies the address to connect to.
The obvious way to build that would be one enormous list of every name on the internet. That design fails immediately — nobody could host it, nobody could agree who gets to edit it, and a single outage would take the internet with it. So DNS is built the other way round: as a tree, where authority is delegated downwards and no single server ever holds the whole picture.
A postal address is the usual analogy, and it is a good one because you read it the same way DNS does. India → Karnataka → Bengaluru → the street → the house. Each level narrows the search and hands you to whoever knows the next level, and nobody needs to memorise every house in the country. DNS reads www.example.com right-to-left in exactly that way: the root hands you to .com, .com hands you to whoever runs example.com, and that server finally tells you about www.
www.example.com is really www.example.com. — with a trailing dot that is almost always omitted. That final dot is the root. Reading right to left gives you the resolution order: root, then the com TLD, then the example.com zone, then thewww record inside it.
The DNS Server Layers at a Glance
Before going through them one by one, here is the whole cast and what separates them. The single most useful column is the last one: what that layer will not tell you.
| Layer | What it holds | What it answers | What it will not do |
|---|---|---|---|
| Root DNS | The root zone — delegations for every TLD | "Ask the .com servers" | Never returns a final IP address |
| TLD DNS | Delegations for every domain under one suffix | "Ask ns1.example-dns.net" | Does not hold your A, MX or TXT records |
| Authoritative DNS | The actual zone file for a domain | "www.example.com is 93.184.216.34" | Does not chase answers for other domains |
| Recursive resolver | A cache, and nothing of its own | The finished answer, from cache or from the chain | Is never the source of truth |
| Your device | A small local cache and the hosts file | Whatever it cached, or it asks the resolver | Does not walk the hierarchy itself |
DNS Resolution Diagram
This is the full path a query takes on a complete cache miss — the slowest, most instructive case. Note that the request travels down the left and the answer comes back up the right; your device never speaks to the root, TLD or authoritative servers directly.
Your Device (browser cache → OS cache → hosts file)
│
▼ "what is the IP for www.example.com?"
Recursive Resolver (1.1.1.1 / 8.8.8.8 / your ISP)
│
├──► Root DNS (.) ──► "ask the .com servers"
│
├──► TLD DNS (.com) ──► "ask ns1.example-dns.net"
│
└──► Authoritative DNS ──► "www.example.com = 93.184.216.34"
│
▼
Recursive Resolver (caches the answer for its TTL)
│
▼ "93.184.216.34"
Your Device ──► opens a TCP connection ──► Website loadsA query only walks the entire chain when nothing along it is cached. In practice the root and TLD steps are skipped almost every time — resolvers hold the .com nameservers for two days — and a popular domain is often answered from cache without a single upstream query. Do not assume every lookup follows the same path.
Layer 1: Root DNS Servers
The root servers sit at the top of the namespace and are authoritative for the root zone — the zone with no name at all, written as a bare dot. The root zone is small, a few thousand entries, and it contains one thing: the delegation for every top-level domain in existence.
Ask a root server about www.example.com and it will not answer the question you asked. It has never heard of example.com and it does not need to. What it returns is a referral: the names and addresses of the nameservers responsible for .com. That is the whole job. Keeping the root ignorant of everything below the first label is exactly what lets the root zone stay small enough to be replicated everywhere and stable enough to be changed rarely.
The 13 root server identities
There are 13 root server identities, named a.root-servers.net through m.root-servers.net and operated by 12 independent organisations, among them Verisign, ICANN, NASA Ames, the University of Maryland, RIPE NCC and WIDE Project. The limit of 13 is a historical artefact: it was the most that fit inside a 512-byte UDP DNS response in the original specification.
This is the single most common misconception about DNS. The 13 identities are not 13 physical servers in 13 rooms. Each identity is announced from many sites simultaneously using anycast routing, so a single IP address such as 198.41.0.4 resolves to whichever of its many instances is closest to you in network terms. Between them, the 13 identities are served by well over 1,500 instances spread across the world. Taking the root "offline" would mean taking down all of them at once.
The practical upshot of anycast is latency and resilience. Your resolver in Mumbai reaches a root instance in Mumbai, not one in Virginia, and if that instance fails the routing simply carries the next query to the next-closest one. The root zone itself is maintained by IANA, a function of ICANN, and every change to a TLD delegation passes through it.
Layer 2: TLD DNS Servers
A top-level domain is the last label in a domain name — the com in example.com. TLD servers are authoritative for one suffix and hold the delegations for every domain registered under it. They fall into a few families:
- gTLDs (generic):
.com,.net,.org,.info. The.comand.netzones are operated by Verisign on thegtld-servers.netmachines. - ccTLDs (country code):
.in,.uk,.de,.jp. Each is delegated to a national registry —.into NIXI,.ukto Nominet. - New gTLDs:
.dev,.app,.shopand hundreds more, introduced from 2013 onward.
What a TLD server stores is narrower than people expect. It does not hold your A record, your MX records or your SPF policy. It holds your NS records — the nameservers you nominated when you registered or last updated the domain — and, where those nameservers live inside the domain they serve, the glue records that break the circularity.
If example.com is served by ns1.example.com, a resolver cannot look up the nameserver without first asking the nameserver — a loop. The TLD breaks it by publishing the nameserver's IP address alongside the delegation. That address is the glue record, and it is the one place a TLD server stores an IP.
You can read a domain's delegation directly with the Nameserver Lookup tool, and see who registered it and when it expires with WHOIS Lookup. A mismatch between the nameservers at the registrar and the nameservers your DNS host expects is one of the most common causes of a domain that resolves for some people and not others.
Layer 3: Authoritative DNS Servers
This is where your records actually live. An authoritative server is one that answers from its own zone data rather than by asking someone else. When it responds, the answer carries the aa (authoritative answer) flag, and that answer is definitive: there is no higher authority to appeal to for that domain.
A zone is normally served by two or more authoritative servers — a primary that holds the editable copy and one or more secondaries that replicate it. That redundancy is why losing one nameserver is usually invisible; resolvers just try the next one in the NS set.
What the zone file contains
The zone file is a plain list of records. Every record has a name, a TTL, a type and a value:
; example.com zone file (abridged)
$TTL 3600
example.com. IN SOA ns1.example-dns.net. admin.example.com. (
2026082401 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
3600 ) ; negative TTL
example.com. IN NS ns1.example-dns.net.
example.com. IN NS ns2.example-dns.net.
example.com. IN A 93.184.216.34
www.example.com. IN CNAME example.com.
example.com. IN AAAA 2606:2800:220:1:248:1893:25c8:1946
example.com. IN MX 10 mail.example.com.
example.com. IN TXT "v=spf1 include:_spf.example.com -all"Ask this server for www.example.com and it returns the CNAME plus the A record it points at, with the aa flag set. That is the end of the chain — the resolver now has something to give back to you.
Layer 4: Recursive DNS Resolvers
The recursive resolver is the layer people interact with most and understand least. It is the only layer that holds no authoritative data whatsoever. Its job is legwork: take one question from a client, follow referrals from root to TLD to authoritative until it has a real answer, cache that answer, and hand back a single finished response.
Note the asymmetry, because it explains a lot of confusing behaviour. Your device asks the resolver one recursive query and waits. The resolver then makes several iterative queries upstream, each returning a referral rather than an answer. Root, TLD and authoritative servers do not perform recursion for strangers — they only ever hand back what they know.
ISP resolvers versus public resolvers
By default your router hands out your ISP's resolver over DHCP. It is close to you and usually fast, but its cache quality, filtering policy and logging practices vary enormously. The main public alternatives:
| Resolver | IPv4 | Character |
|---|---|---|
| Cloudflare | 1.1.1.1, 1.0.0.1 | Privacy-focused, no filtering by default |
| Google Public DNS | 8.8.8.8, 8.8.4.4 | Very large cache, broad global footprint |
| Quad9 | 9.9.9.9, 149.112.112.112 | Blocks known malicious domains at the resolver |
| Your ISP | Assigned via DHCP | Lowest latency, most variable quality |
Caching and TTL
Every record carries a TTL — time to live, in seconds — that tells resolvers how long they may reuse the answer. A 3600-second TTL means an answer fetched at 10:00 can be served from cache until 11:00 without asking anyone.
This is what makes DNS fast enough to be invisible. A full walk of the hierarchy costs several round trips and can take 100–300 ms; a cache hit costs one round trip to a nearby resolver, often under 10 ms. Because a busy resolver serves thousands of clients, the overwhelming majority of queries never leave it. It also protects the upper layers: the root and TLD servers would be crushed if every lookup on earth actually reached them.
Caching is also the reason DNS changes seem slow. Resolvers cache negative answers too, so a mistyped record that returned NXDOMAIN can keep failing after you fix it. Check what different resolvers are currently holding with the DNS Propagation Checker, and inspect remaining TTLs with the DNS Cache Checker.
Drop the TTL to 300 seconds at least one full old-TTL period before a planned change. Once resolvers have picked up the short TTL, the cutover itself clears in five minutes. Lowering the TTL after the change is useless — resolvers are already sitting on the old record with the old, long TTL attached.
Layer 5: Your Device and the Stub Resolver
The final layer is the one on your own machine. Applications do not implement DNS themselves; they call the operating system, whose stub resolver is a deliberately minimal client. It knows how to ask a recursive resolver a question and read the reply. It does not walk the hierarchy and it has never spoken to a root server.
Before any query leaves the machine, several local checks happen in order:
- Browser cache. Chrome, Firefox and Edge each keep their own short-lived DNS cache, independent of the OS. In Chrome you can inspect and clear it at
chrome://net-internals/#dns. - Hosts file. A plain text file —
/etc/hostson Linux and macOS,C:\Windows\System32\drivers\etc\hostson Windows — that maps names to addresses directly. An entry here wins over all of DNS, which makes it excellent for testing a migration and a notorious source of "works on my machine" mysteries. - OS cache. Windows caches through the DNS Client service; most Linux systems use
systemd-resolvedand macOS usesmDNSResponder.
Only if all three miss does the stub resolver send a query to the configured recursive resolver. When the IP address comes back, DNS's job is finished — the browser opens a TCP connection to that address, completes the TLS handshake and sends its HTTP request. Everything after the address is returned is no longer DNS, which is worth remembering when a site fails to load: a working lookup rules the whole system out.
A Complete Walkthrough: Resolving www.example.com
Putting all five layers together, on a cold cache with nothing stored anywhere:
- Local caches checked. The browser cache, hosts file and OS cache are all consulted. All three miss.
- Query to the recursive resolver. The stub resolver sends one recursive query to the configured resolver and waits for a complete answer.
- Resolver checks its own cache. Also a miss, so it starts at the top of the tree.
- Resolver queries a root server. The root replies with a referral to the
.comnameservers. No IP address for the site, by design. - Resolver queries a .com TLD server. It replies with another referral: the NS records for
example.com, plus glue if needed. - Resolver queries the authoritative nameserver. This one answers properly —
www.example.comis a CNAME toexample.com, which is A93.184.216.34— with the authoritative flag set. - Resolver caches the answer for the TTL on each record, so the next client asking the same question is served instantly.
- Resolver returns the address to your stub resolver, which caches it locally too and hands it to the browser.
- The browser connects to 93.184.216.34 on port 443 and the page begins loading.
The whole sequence typically completes in 100–300 ms. Repeat the same request a minute later and steps 3 through 7 vanish entirely — which is the point of the design, and why no two lookups for the same name necessarily do the same work.
DNS Records You Meet Along the Way
The authoritative layer is where record types matter. These are the ones you will encounter most:
| Type | What it does | Example |
|---|---|---|
| A | Maps a name to an IPv4 address | example.com. A 93.184.216.34 |
| AAAA | Maps a name to an IPv6 address | example.com. AAAA 2606:2800:220:1::1946 |
| CNAME | Aliases one name to another name | www.example.com. CNAME example.com. |
| MX | Names the mail servers for the domain, with priority | example.com. MX 10 mail.example.com. |
| NS | Names the authoritative nameservers for the zone | example.com. NS ns1.example-dns.net. |
| TXT | Free-form text, used for SPF, DKIM, DMARC and verification | example.com. TXT "v=spf1 -all" |
| SOA | Start of authority — serial, refresh timers, negative TTL | example.com. SOA ns1... admin... 2026082401 |
| PTR | Reverse lookup: maps an IP address back to a name | 34.216.184.93.in-addr.arpa. PTR example.com. |
A CNAME has one rule worth memorising: a name with a CNAME cannot carry any other record. That is why you cannot put a CNAME on a bare domain that also needs MX and NS records. For a fuller treatment see DNS Records Explained, or pull every record a live domain publishes with All DNS Records Lookup. PTR records live in a separate reverse tree and are checked with Reverse DNS Lookup.
What Happens When DNS Fails
DNS failures are much easier to diagnose once you can map the symptom to a layer.
| Symptom | What it means | Layer to check |
|---|---|---|
| NXDOMAIN | The name genuinely does not exist in the zone | Authoritative — typo, missing record, or expired domain |
| SERVFAIL | The resolver tried and could not get a valid answer | Authoritative unreachable, or a broken DNSSEC chain |
| Timeout | No reply at all within the query deadline | Network path, firewall blocking port 53, or a dead resolver |
| REFUSED | The server declined to answer this query | Asking a server that is not authoritative and will not recurse |
| Wrong IP returned | An answer arrives, but it is stale or incorrect | A cached old record, or a bad record at the authoritative layer |
| Works for some people | Inconsistent answers across networks | Mid-cache-expiry, or nameservers disagreeing with each other |
Two causes deserve special mention. An expired domain produces the most dramatic failure of all: the registry pulls the delegation at the TLD layer, so every name under it returns NXDOMAIN no matter how healthy your nameservers are. Check the expiry date with Domain Expiry Checker before debugging anything else.
And "DNS propagation" is not a real mechanism. Nothing propagates and nothing is pushed. Your change is live at the authoritative server the instant you save it; what you are waiting on is other people's resolvers reaching the end of a TTL they cached before you made the change. There is no way to shorten that retroactively.
DNS Troubleshooting Commands
The value of the command line here is that you can question each layer separately, which is precisely what a browser will not let you do.
dig
# Basic A record lookup
dig example.com A
# Just the answer, nothing else
dig +short example.com A
# Walk the hierarchy yourself — root, then TLD, then authoritative
dig example.com A +trace
# Ask one specific resolver instead of your default
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
# Ask the authoritative server directly, bypassing every cache
dig @ns1.example-dns.net example.com A
# Which nameservers is the domain delegated to?
dig example.com NS +short
# Mail and text records
dig example.com MX +short
dig example.com TXT +short
# Reverse lookup for an IP address
dig -x 93.184.216.34
# Check the DNSSEC chain
dig example.com A +dnssec+trace makes dig start at the root and follow every referral itself, printing each hop. You see the root hand off to .com, .com hand off to your nameservers, and your nameservers give the answer. When a lookup breaks somewhere in the middle, this shows you exactly which layer stopped cooperating.
nslookup
Available everywhere including Windows, and the quickest option on a machine without dig:
# Basic lookup
nslookup example.com
# Query a specific resolver
nslookup example.com 1.1.1.1
# Ask for a specific record type
nslookup -type=MX example.com
nslookup -type=NS example.com
nslookup -type=TXT example.com
# Reverse lookup
nslookup 93.184.216.34host
The most compact of the three, ideal for a fast confirmation:
# All common records in one short block
host example.com
# One record type
host -t MX example.com
host -t NS example.com
# Reverse lookup
host 93.184.216.34
# Verbose, dig-style output
host -a example.comIf you are on a machine without these tools, or want to compare answers from resolvers on other continents, DNS Lookup and DNS Propagation Checker do the same work from the browser.
DNS Security at Each Layer
DNS was designed in 1983 with no authentication and no encryption. Every protection since has been bolted on, and each one addresses a different layer.
DNSSEC
DNSSEC signs DNS records cryptographically, so a resolver can verify that an answer really came from the zone it claims and was not altered on the way. The signatures form a chain of trust that follows the layers exactly: the root signs the TLD's key, the TLD signs your zone's key, your zone signs its records. It provides authenticity, not privacy — signed answers still travel in plain text. Verify a chain with the DNSSEC Validator, and read What Is DNSSEC? for the mechanics.
DNS over HTTPS (DoH) and DNS over TLS (DoT)
Both encrypt the hop between your device and your recursive resolver — the one segment where an observer on the network can see every domain you visit. DoH wraps queries in normal HTTPS on port 443, making them indistinguishable from web traffic; DoT uses a dedicated TLS connection on port 853, which is cleaner for network operators to manage but trivially blockable. Neither encrypts what the resolver does upstream, and neither authenticates the data the way DNSSEC does — they are complementary, not alternatives. See What Is DoH? and What Is DoT?
Cache poisoning and spoofing
Cache poisoning targets the resolver layer: an attacker races a forged reply to a pending query, and if it is accepted the resolver serves the bad answer to every one of its clients until the TTL expires. Spoofing is the broader family — any forged DNS response, including one injected on a hostile local network. Source port randomisation made blind poisoning much harder, DNSSEC makes forged answers detectable, and DoH/DoT make on-path injection between you and your resolver impractical.
Summary
A DNS lookup is a walk down a tree of delegated authority. Your device checks what it already knows, then asks a recursive resolver a single question. If that resolver has nothing cached it goes to a root server, which points it at a TLD server, which points it at the authoritative server for the domain — the only layer that actually holds your records. The answer travels back, is cached at every step, and your browser finally opens a connection.
Keep the boundaries straight and DNS troubleshooting becomes methodical rather than superstitious. A recursive resolver is not an authoritative server. A root server is not a TLD server. And because caching lets a query skip whole layers, no two lookups for the same name necessarily do the same work. Ask each layer directly, and it will tell you which one is lying.
Frequently Asked Questions
1. What is a DNS server?
A DNS server is any machine that answers DNS questions. That single label covers very different jobs: a recursive resolver does the legwork on your behalf, while root, TLD and authoritative servers each hold one slice of the namespace and answer only for that slice. When someone says "my DNS server is down", the useful first question is always which of those layers they mean.
2. What is the difference between recursive and authoritative DNS?
An authoritative server holds the real records for a zone and answers from its own data — it is the source of truth. A recursive resolver holds no records of its own; it asks other servers, follows referrals down the hierarchy, caches what it learns and hands you a finished answer. Authoritative servers know; recursive resolvers find out. A misconfigured record is an authoritative problem, a stale answer is usually a resolver one.
3. What is a root DNS server?
A root server answers for the top of the DNS tree, the zone written as a single dot. It does not know where example.com is hosted and it never returns the final IP address. What it returns is a referral: the nameservers for the relevant top-level domain, such as the .com servers. It is a signpost, not a destination.
4. How many root DNS servers are there?
There are 13 root server *identities*, named a.root-servers.net through m.root-servers.net, operated by 12 independent organisations. That is not 13 machines. Each identity is announced from many locations at once using anycast, so the 13 names are served by well over a thousand physical instances worldwide. Your query reaches whichever instance is closest in network terms.
5. What is a TLD DNS server?
A TLD (top-level domain) server is authoritative for one top-level suffix — .com, .net, .org, .in, .io and so on. It does not store your A or MX records. It stores the delegation: which nameservers a registrant chose for their domain, plus any glue records those nameservers need. The root points to the TLD; the TLD points to you.
6. How long does DNS caching last?
For as long as the TTL on the record says, and no longer than whatever ceiling the resolver enforces. A record with a 3600-second TTL can be served from cache for up to an hour after it was first fetched. Resolvers may clamp very large or very small TTLs to their own limits, and browsers and operating systems keep separate shorter-lived caches on top. See What Is DNS TTL? for how to choose a value.
7. What happens if a DNS server is down?
It depends on the layer. If one authoritative nameserver is down, resolvers retry the others listed in the NS set and nothing breaks. If every authoritative server for the zone is unreachable, lookups fail with SERVFAIL once cached answers expire. If your recursive resolver is down, nothing resolves at all even though the rest of DNS is healthy — which is why switching resolvers is a good first diagnostic.
8. What is DNS propagation?
It is a misleading name for cache expiry. Your change is live on the authoritative server the moment you save it; nothing is pushed anywhere. What you are waiting for is every resolver that already cached the old answer to reach the end of its TTL and ask again. Lower the TTL *before* you make a change, not after — after is too late, because resolvers are still holding the old value along with its old TTL.
9. Can I change my DNS resolver?
Yes, and it is one of the easiest changes to make. Your device or router usually takes the resolver from DHCP, which means your ISP, but you can point it at a public resolver such as Cloudflare (1.1.1.1), Google (8.8.8.8) or Quad9 (9.9.9.9) instead. This changes only who does the lookup for you — the records themselves come from the same authoritative servers either way.