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.
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; for the wider picture of where this fits in a full lookup, see how DNS actually works, and for the transport that carries every step of it, whether DNS uses TCP or UDP.
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.
What are the root servers, exactly?
The root sits at the very top of this hierarchy, and it is smaller and stranger than most people picture. There are thirteen root server identities, named simply A through M, operated by twelve independent organisations around the world, among them Verisign, ICANN, the University of Maryland, NASA, the US Army Research Lab, and Europe's RIPE NCC.
Those thirteen names are not thirteen machines. Each identity is mirrored across hundreds of physical servers spread across the globe using a routing trick called anycast, so the “root server” your resolver reaches is almost always a nearby copy a few milliseconds away, not a single box in one country.
And they hold almost nothing. The root knows only where each top-level domain's servers live, .com, .org, the country codes, a tiny list that rarely changes. It never resolves your full request or sees where you end up; it simply points the resolver one step down and steps out of the way.
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. That is a question an operator should be able to answer in public: ours is answered in the server infrastructure and transparency report, which names every component in the query path and what it keeps.
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. There are really two questions here, and they have different answers: what your device was told to use, and which machine actually ends up asking the authoritative server. Both are one command.
1. What your device was told
On Linux, if the system runs systemd-resolved:
$ resolvectl status # or: cat /etc/resolv.confOn Windows the equivalent is a PowerShell cmdlet, and its output makes a point the Linux one hides. DNS servers are set per network interface, not per machine:
PS> Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize
InterfaceAlias InterfaceIndex AddressFamily ServerAddresses
-------------- -------------- ------------- ---------------
Ethernet 19 IPv4 {}
Tailscale 38 IPv4 {}
Подключение по локальной...9 16 IPv4 {}
Подключение по локально...10 9 IPv4 {}
Беспроводная сеть 15 IPv4 {194.180.189.33}
Сетевое подключение Bluetooth 10 IPv4 {}
Loopback Pseudo-Interface 1 1 IPv4 {}Seven interfaces, one resolver. Only the wireless adapter has a DNS server set; everything else is empty and will use whatever the network hands out. This is why “my DNS is set to X” is frequently wrong in practice - plug in an Ethernet cable and the answer changes, because a different interface now carries the traffic. Interface names appear in the machine's display language, which is why the ones above are not in English.
2. Which resolver the authoritative server actually sees
This is the more interesting question, and the answer is usually not the address you configured. Akamai runs a name that reports back who asked for it:
$ dig @194.180.189.33 whoami.ds.akahelp.net TXT +short
"ns" "109.200.195.201"The address we asked was 194.180.189.33. The address Akamai saw was 109.200.195.201. Both are correct, and the gap between them is the thing this whole page is about: a resolver you talk to is not necessarily the resolver that walks the tree. This one forwards to an upstream, so the machine that finally asks the authoritative server belongs to the upstream, not to us. Your query went device to resolver to upstream to authoritative, and only the first hop is the address you configured.
3. Check the TTL, or you may be reading a stranger's lookup
Here is the trap, and it is easy to fall into because the command looks like it reports on you. Run the same lookup at the wrong moment and you get this instead:
$ dig @194.180.189.33 whoami.ds.akahelp.net TXT +noall +answer
whoami.ds.akahelp.net. 140 IN TXT "ip" "194.180.188.52"
whoami.ds.akahelp.net. 140 IN TXT "ns" "162.159.96.100"
whoami.ds.akahelp.net. 140 IN TXT "ecs" "194.180.188.0/24/24"A different upstream, an extra address, and a client subnet that looks alarmingly like a privacy leak. None of it describes the person who ran the command. The giveaway is the TTL: 140 and falling means this answer was already sitting in a cache, so it describes whoever put it there.
We checked that properly rather than assuming it. Two machines on different networks, one in Finland and one elsewhere, ran the lookup about a minute apart. Both got byte-identical values, and the two TTLs differed by exactly the number of seconds between the runs - a single cache entry, counting down, being read by two strangers. Neither of them is 194.180.188.52.
Wait for the entry to expire and ask again, and the honest answer appears: one line, "ns" "109.200.195.201", with no ecs and no ip at all. No client subnet is attached to the query on its way out - not by this resolver, and not by the unbound and dnscrypt-proxy stages behind it. What looked like a leak was someone else's cached lookup wearing our address.
So the rule for any “who is my resolver” lookup: run it with +noall +answer and read the TTL first. A number well below the record's maximum means you are looking at a cached answer and it may not be about you at all. This is the same reasoning the leak test uses a uniquely named subdomain for: a name nobody has asked for before cannot be answered from anyone's cache.
Your resolver and your IP address reveal different things; the IP and fingerprint page shows what a site sees of you directly, and EDNS Client Subnet explains the field that caused the false alarm above.
See your resolver for yourself
One lookup tells you which server is really answering for you.
Run the DNS leak test