What is a DNS resolver, and which one are you using?

What happens when your device looks up a name?

Your operating system does not search the internet for a name itself. It hands the request to a small piece of software called a stub resolver, which is not a nameserver at all. RFC 8499 defines it as a resolver "that cannot perform all resolution itself" and depends on a recursive resolver to do the actual work. The stub resolver's job is to send your query to whichever server is configured in your network settings and hand back the answer, or a cached copy of a recent one.

Stub resolver, recursive resolver, authoritative server: what is the difference?

Three roles show up in every lookup, and the same physical server can play more than one of them:

• Stub resolver. Runs on your device, forwards queries, keeps a small cache, and cannot resolve a name on its own.
• Recursive resolver. Per RFC 8499, "a resolver that acts in recursive mode," meaning it does the full work of chasing an answer through however many servers it takes, then caches and returns the result. This is the role your ISP or a public DNS service fills.
• Authoritative server. RFC 8499 defines it as a server that "knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers." This is the server the domain's own DNS provider runs, and its answer is the one nobody else is copying.

A server that answers with a referral rather than a full answer is acting iteratively; one that keeps working until it has a final answer or a definitive error is acting recursively, which is what "recursive resolver" means in its name.

The path one lookup takes: root, TLD and authoritative hops

A cold lookup, one with nothing cached anywhere, walks a fixed hierarchy. The recursive resolver starts at a root server, one of thirteen named root server identities that IANA lists as a.root-servers.net through m.root-servers.net, and asks it for example.com. The root server does not know the answer; it returns a referral to the servers responsible for the .com top-level domain. The resolver asks one of those and gets a second referral, this time to the authoritative nameservers for example.com itself, the ones the domain's owner configured. Only that last server gives a real answer instead of a pointer to somewhere else. The recursive resolver caches it and hands it back to your stub resolver, which hands it to your browser.

Every hop after the first is skipped whenever a cache along the way already has the answer, which is why the vast majority of everyday lookups never touch a root server at all.

ISP resolver vs public resolver: what actually changes?

The resolver your device uses by default usually comes from DHCP, handed out by your router or your ISP, and it is almost always a recursive resolver doing full lookups on your behalf. What it does with your queries, how large its cache is, and how many locations it runs from is set by whoever operates it and is not something you can see from your side.

Public resolvers exist as an alternative you can point your device at instead: Google Public DNS runs at 8.8.8.8, Cloudflare at 1.1.1.1, and Quad9 at 9.9.9.9. Each publishes its own policy on what it logs and how long it keeps it, each runs its own anycast network so the same address answers from whichever location is closest to you, and Quad9 also blocks known malicious domains by default at the resolver level, which an ISP resolver typically does not. None of that changes what DNS itself can do: a resolver only decides how a lookup is carried out, not what a domain's records say.

Which resolver is your machine using right now?

The resolver you are actually using is a setting, not a guess, and each OS has one command that shows it:

• Windows: ipconfig /all lists "DNS Servers" under each network adapter, in the order they are queried.
• macOS: scutil --dns reports the current DNS configuration, including the nameservers in effect for each network service.
• Linux with systemd-resolved: resolvectl status shows, per its own manual, "the global and per-link DNS settings currently in effect," meaning both the fallback resolver and whatever a specific connection such as Wi-Fi or a VPN has overridden it with.

A VPN, a corporate network or a browser's own secure DNS setting can each substitute a different resolver without changing what the OS command reports, so if the command's answer does not match what you expect, that is the first place to look.

Which resolver answers a query can change the result you see, not just the speed of getting it: a resolver with a stale cache, a regional outage, or a filtering policy of its own can hand back something different from what the authoritative servers would say directly. Run a lookup with the DNS query tool to compare, or if the resolver is answering slowly rather than differently, how to fix a slow DNS lookup covers measuring and changing it. If it is not answering at all, start with DNS server not responding. For the caching behavior behind all of this, see what a DNS cache is. HostTracker has monitored websites since 2004, now watches 500,000+ sites from 300+ checkpoints in 158 cities, and can alert by email, SMS, voice call, Slack, Telegram and more the moment a check that expects a specific IP address sees a different one.

Frequently asked questions

Is my router a DNS resolver?

Often only in a limited sense. Many home routers run a small DNS forwarder: it answers from a tiny cache, but for anything not already cached it passes the query straight to the ISP's resolver rather than doing full recursion itself. RFC 2308 describes this role as a forwarder, "a nameserver used to resolve queries instead of directly using the authoritative nameserver chain."

Does using a public resolver make my browsing faster?

Sometimes, sometimes not. A resolver close to you with a warm cache answers in single digit milliseconds regardless of who operates it. The main variables are how close the resolver's nearest location is to you and how warm its cache already is, not the brand name.

What is the difference between recursion and forwarding?

A resolver doing recursion queries the root, the TLD and the authoritative servers itself, one hop at a time, and caches the final result. A resolver that forwards instead sends the whole question to another resolver and waits for a complete answer, trading the work, and visibility into what you looked up, for whatever that upstream resolver already has cached.

Do all 13 root servers run on 13 machines?

No. There are thirteen named root server identities, but each one is served from many physical machines around the world, so a query routes to a nearby copy rather than crossing an ocean every time.

Can two devices on the same network use different resolvers?

Yes. The router hands out a default through DHCP, but any device can override it in its own network settings, and a VPN or a browser's secure DNS setting can override it again on top of that. The commands above always show what that specific device is using at that moment, not what the network intends.