A DNS resolver, or recursive resolver, is the server that does the work of finding an answer for a client. It starts at the root servers, follows referrals to the TLD and then to the domain's authoritative nameservers, and caches the result for the record's TTL.
Why it matters
Your visitors never talk to your nameservers directly; they talk to a resolver run by their ISP, employer or a public service such as Google (8.8.8.8) or Cloudflare (1.1.1.1). That is why two people can see different answers for the same name: they use different resolvers with different caches. Resolvers also validate DNSSEC signatures, and a broken signature makes them return SERVFAIL.
The "stub resolver" built into an operating system or browser is a small client that simply forwards queries to the recursive resolver.
Example
$ dig @1.1.1.1 example.com A +short
203.0.113.10
$ dig @8.8.8.8 example.com A +short
203.0.113.10Asking specific resolvers shows what that part of the internet currently sees.
Common mistakes
- Debugging with only the local resolver. Compare several public ones and the authoritative server.
- Confusing resolver and nameserver: one asks, the other answers authoritatively.
- Forgetting local caches such as
systemd-resolved, the OS or the browser. - Blaming the domain for SERVFAIL when the resolver is the broken part.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.