Your device asks the resolver; the resolver records the name, fetches the answer, and sends it back. Whichever resolver you use, that list of names passes through it.
A resolver is easy to overlook because you never choose it consciously, yet it occupies the most revealing seat in the whole connection. Understanding what it is makes every other DNS decision clearer.
What a resolver does
Computers reach each other by numeric address, but people use names. A resolver bridges the two. When you open a site, your device hands the name to a resolver and asks for its address. The resolver either already knows the answer, because it looked it up recently and kept it in a short-lived cache, or it goes and finds it, then hands it back so your connection can begin.
Finding an unknown name means walking the naming system from the top, one level at a time. The next section follows that walk with a concrete example.
How DNS knows a name's address
Say you type example.com. Your browser cannot connect to a word; it needs a number, an IP address such as 203.0.113.42 (illustrative here). So the real question is: who decided that example.com lives at that number, and how does a resolver find it?
Nobody guesses it. The mapping is written down in a small DNS record, an A record, that simply pairs a name with an IP. The owner of the domain publishes that record on the domain's authoritative nameserver, the server that holds the official records for example.com. Edit the record there and that becomes the truth everyone gets:
example.com. IN A 203.0.113.42
But your resolver does not start out knowing which server is authoritative for example.com. It finds out by asking down a hierarchy, where each level does not hold the final answer, it only points one step closer:
Each level only knows who to ask next; the domain's own nameserver holds the actual address and hands it back.
In words: the resolver asks a root server, which says “ask the .com servers.” It asks a .com server, which says “ask example.com's nameserver.” It asks that nameserver, which finally answers with the A record, 203.0.113.42. The resolver hands that back to your browser, and the connection begins.
No single level holds the whole answer; the chain from root to top-level domain to the domain's own server is what lets a name nobody has ever requested be found in milliseconds, and why one record published by the owner is enough for the entire internet to reach them. The resolver then keeps that answer in its cache for a set time, the record's TTL, so the next visit skips the walk entirely.
The pieces, by name
Stub resolver
The small client built into your device or operating system. It does not do the legwork itself; it forwards your question to a recursive resolver and waits for the answer.
Recursive resolver
The one that actually finds answers, caches them, and serves them back. This is the resolver people mean in everyday use, and the one you are really choosing when you set a DNS server.
Forwarding resolver
A middleman, often your home router, that takes your query and passes it to a recursive resolver upstream. It is a common, quiet place for lookups to be redirected without you noticing.
Authoritative server
Not a resolver at all, but the source of truth: it holds the real records for a domain and answers the recursive resolver's final question. It sees which resolver asked, not who you are.
What it can, and cannot, see
- The name of every site you look up
- When you looked it up, and how often
- The address the request came from
- Enough, over time, to profile your interests
- The specific page or path on a site
- Anything you type or read once connected
- The contents of encrypted traffic
- Names already answered from a local cache
In short, the resolver sees the front door you walked through, not what you did inside. That is still a revealing record, which is why the resolver you use is worth a deliberate choice.
Who runs the one you use
By default it is your internet provider's resolver, assigned automatically when you connect. You can change it to a public resolver, or run your own. Whichever it is holds that list of names, so the question that matters is who you are comfortable seeing it.
Encryption changes less here than people expect. Encrypted DNS such as DoH or DoT hides your lookups from the network between you and the resolver, but the resolver itself still reads every query, because it has to in order to answer. Encryption and trust are two separate decisions: the guide on DoH vs DoT vs DNSCrypt vs DoQ covers the encryption, and the resolver you point it at is the trust.
Which resolver are you actually using?
It is often not the one you think, because routers, networks, and apps can quietly substitute their own. The way to know for certain is to make a fresh lookup and watch which resolver answers it: that is exactly what the DNS leak test does, and how the DNS leak test works explains why the result is trustworthy.
Your resolver and your IP address reveal different things; the IP and fingerprint check covers what your connection exposes beyond DNS. And when you want to choose a resolver deliberately and reach it over an encrypted protocol, the setup guide has the per-platform steps.
See your resolver for yourself
One lookup tells you which server is really answering for you.
Run the DNS leak test