A domain name is not one flat label. It is a chain of responsibility, written left to right but ranked right to left, ending in a dot most people never see.
Understand that one idea, that a name is a hierarchy ending in a hidden dot, and the rest of DNS stops looking like magic and starts looking like a filing system.
A name is built in layers
Take www.example.com. We read it left to right, but DNS reads the authority of it right to left. At the very end sits an invisible dot, the root. To its left, com is the top-level domain. Then example is the registered domain, the part someone actually bought. And www is a host inside it, one machine the owner chose to name. Each dot is a boundary between one level of responsibility and the next.
This matters because it is exactly how the answer gets found. No single place knows the whole map. The root only knows where the top-level domains are. com only knows where each .com domain's servers are. The domain's own server is the only one that knows its real addresses. The lookup follows that chain down, one handoff at a time. We trace that full walk, and who runs each step, in what a DNS resolver is; here the point is simply that the name itself is the map.
Where your question actually goes
Most lookups never reach the root at all. Before any of that walking happens, your device checks a cascade of caches, each one a chance to answer instantly. It only falls to the next step on a miss. When a question does go out, it travels on port 53, over UDP unless the answer is too big to fit.
-
1
The browser and app cache
Your browser keeps recent answers in memory for a short while. Reload a site you just visited and the name may never leave the program at all.
-
2
The operating system (the stub resolver)
A small client built into your OS holds its own cache and is what actually sends the query out. If it has the answer, it replies without touching the network.
-
3
The router on your network
Many home routers run a small forwarding resolver with a cache of their own, and quietly decide which resolver upstream your questions are handed to. A common, easy-to-overlook step.
-
4
The recursive resolver
The one that does the real work: it serves the answer from its large cache, or, on a miss, walks the hierarchy from the root down to find it. This is the resolver you are actually choosing when you set a DNS server, and the one encrypted DNS protects the link to.
-
5
The walk, only when nobody has it
Root, then top-level domain, then the domain's own nameserver. A privacy-minded resolver tells each level only the next label it needs, a habit called QNAME minimisation. The address comes back, the resolver caches it for the record's lifetime, and the next person to ask skips the whole journey.
How long each cache holds an answer is set by the record's TTL, the dial covered in DNS caching and TTL. Caching is the reason a system that could involve servers on three continents still feels instant.
Watch the walk happen
Step 5 is the only part of that list you can watch from the outside, and one command does it. dig +trace refuses to let a resolver do the work: it starts at the root and asks each level itself, printing every handoff. dig comes from the dnsutils or bind-utils package. The real output is 47 lines, mostly server names and signatures, so here it is with the repetitive blocks folded:
$ dig +trace example.com A
. 3600 IN NS a.root-servers.net.
... (all thirteen root servers listed)
;; Received 553 bytes from 100.100.100.100#53 in 0 ms
com. 172800 IN NS l.gtld-servers.net.
... (thirteen .com servers, plus a DS record)
;; Received 1171 bytes from 193.0.14.129#53(k.root-servers.net) in 224 ms
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.
;; Received 506 bytes from 192.41.162.30#53(l.gtld-servers.net) in 37 ms
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Received 179 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 1 msRead the ;; Received ... from lines and the whole hierarchy is there in order: a root server hands over the thirteen .com servers, one of those hands over the two nameservers for example.com, and one of those finally returns an address. Three questions to three different organisations, 262 milliseconds of network time, for a name your browser then resolves in nothing at all for the rest of the day.
Two details worth noticing. The first block came from 100.100.100.100, this machine's own configured resolver, because even +trace has to ask somebody where the root servers are before it can begin. And example.com is served by Cloudflare's nameservers, which is worth checking rather than assuming: who runs a domain's DNS changes, and the trace tells you today's answer.
The same walk, one question at a time
If the trace is too much at once, ask the three servers yourself. +norecurse stops them from being helpful, so each replies with exactly what it knows and nothing more:
$ dig @198.41.0.4 example.com A +norecurse +noall +authority +comments # a.root-servers.net
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
com. 172800 IN NS l.gtld-servers.net.
$ dig @192.41.162.30 example.com A +norecurse +noall +authority +comments # l.gtld-servers.net
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 13
example.com. 172800 IN NS hera.ns.cloudflare.com.
$ dig @hera.ns.cloudflare.com example.com A +norecurse +noall +answer +comments
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
example.com. 300 IN A 104.20.23.154The first two answer ANSWER: 0. They are not being unhelpful; they genuinely do not hold the record, and a referral is the only honest reply they have. Only the last one sets the aa flag - authoritative answer - which is a nameserver saying "this is my domain and this is the record". That flag is the end of the chain the diagram at the top of this page describes.
And the caching that skips all of it
Almost no lookup does any of the above, and the TTL shows why. Ask the source, then ask a public resolver, then ask it again a few seconds later:
$ dig @hera.ns.cloudflare.com example.com A +noall +answer # the source
example.com. 300 IN A 104.20.23.154
$ dig @1.1.1.1 example.com A +noall +answer # a cache
example.com. 66 IN A 172.66.147.243
$ dig @1.1.1.1 example.com A +noall +answer # same cache, 7 seconds later
example.com. 60 IN A 172.66.147.243The authoritative server always says 300, because that is the lifetime the domain publishes. The public resolver said 66, then 60 seven seconds later: it is not looking anything up, it is reading from memory and telling you how much longer that copy is good for. When it hits zero the next question triggers the walk again, and everybody else gets the cached copy for the following five minutes.
The same walk on Windows
Windows has no +trace, so the walk has to be done by hand, and nslookup is the tool that can do it. -norecurse is the counterpart of dig's +norecurse, and a referral is printed under the heading Served by:
PS> nslookup -norecurse -type=A example.com 198.41.0.4
... (a block of in-addr.arpa records: nslookup trying to name the server)
Name: example.com
Served by:
- l.gtld-servers.net
192.41.162.30
com
... (the other twelve .com servers)
PS> nslookup -norecurse -type=A example.com 192.41.162.30
Name: example.com
Served by:
- hera.ns.cloudflare.com
- elliott.ns.cloudflare.comTwo things to expect. Each run is preceded by a block of records that has nothing to do with your question - that is nslookup trying to turn the server's address into a name by asking that same server, and being handed a referral for its trouble. And the labels around the answer are translated into the machine's display language, so yours may not read as they do here. The records themselves are identical to dig's.
"Authoritative" is decided above, not claimed below
Doing it by hand turns up something a trace never shows you. Ask example.com's old nameservers directly and they still answer - authoritatively, with a completely different set of addresses:
$ dig @hera.ns.cloudflare.com example.com A +norecurse +noall +answer # delegated
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
$ dig @a.iana-servers.net example.com A +norecurse +noall +answer # not delegated
example.com. 300 IN A 23.192.228.80
example.com. 300 IN A 23.215.0.136
... (six addresses, none of them the two above)
$ dig @192.41.162.30 example.com NS +norecurse +noall +authority # who .com names
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.Both servers set the aa flag. Both are certain. They disagree about the addresses, and they even disagree about who the nameservers are: the Cloudflare pair publish themselves, the iana-servers pair publish themselves. Nothing in either answer can settle it.
What settles it is the level above. .com delegates the name to the Cloudflare pair, so that is where every resolver in the world goes, and the other set is answering questions nobody asks it. This is the practical meaning of the hierarchy: authority is granted by the parent, never asserted by the server holding the records. It is also why typing a nameserver you remember from documentation can hand you a confidently wrong answer - and why the trace, which follows the delegation instead of your memory, is the honest way to look.
What actually comes back
The answer is a small record. "An address" is the common case, but a name can carry several kinds of record, each answering a different question about the domain.
| Record | Answers the question |
|---|---|
| A | What is the IPv4 address for this name? |
| AAAA | What is the IPv6 address for this name? |
| CNAME | This name is an alias; go look up that other name instead. |
| NS | Which nameservers are authoritative for this domain? |
| MX | Which servers receive email for this domain? |
| TXT | Arbitrary text, used for things like domain verification and email anti-spoofing. |
The A and AAAA records are what your browser needs to open a connection. The rest keep the wider system, mail, aliases, delegation, running.
DNS is step one, not the whole trip
It is worth being clear about where DNS stops. The lookup hands your device an address and then bows out. Everything after, opening the connection, the TLS handshake that encrypts it, requesting the actual page, comes next and has nothing to do with DNS. DNS is the phone book, not the phone call. It finds the number; it does not place the call or carry the conversation.
That is also why "encrypted DNS" and "HTTPS" are not the same thing and do not replace each other. HTTPS protects the conversation once it is underway. DNS encryption protects the lookup that happens just before it, the part HTTPS never touches.
The thing the original design left out
DNS was built in a smaller, more trusting era, and it shows in two gaps. First, the lookups were sent in the clear, so anyone on the path, your network, your provider, could read the name of every site you opened. That is the privacy gap, and it is the one this whole service exists to close: encrypted DNS wraps the link between you and your resolver so the question can no longer be read. The detail of what that does and does not hide is in what your ISP can still see, the same resolver's power to block or censor a name is its own guide, and the transports that do the wrapping are compared in DoH vs DoT vs DNSCrypt vs DoQ.
Second, an answer carried no proof of where it came from, so a forged reply could be slipped in and believed. That is the authenticity gap, addressed by DNSSEC, which signs records so a fake fails the check, and it is exactly the weakness exploited in DNS spoofing and cache poisoning. Put plainly: the original DNS reliably finds the answer, and modern DNS adds the two things it forgot, keeping the question private and proving the answer is real.
See the lookup, then close the two gaps
Point your device at a resolver that encrypts the lookup so it cannot be read, and validates DNSSEC so a forged answer cannot reach you. The first step of every connection, done right.
Set up encrypted, validating DNSGo deeper on the parts: what a resolver is, caching and TTL, or DNSSEC.