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.
-
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. 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.
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.