What is a DNS resolver and what does it do?

Sajjad
DNS
10 Oct, 2026

A DNS resolver is the server (or piece of software) that answers DNS questions on behalf of your devices. When your laptop wants the IP address for www.example.com, it doesn't go and find it itself. It asks a resolver, and the resolver does the legwork: it checks its cache, and if the answer isn't there, it queries the root, TLD and authoritative name servers in turn, validates the result, stores it for later, and hands the final answer back to you. Your ISP, your company, your router or a public service such as 1.1.1.1, 8.8.8.8 or 9.9.9.9 is almost certainly acting as your resolver right now.

Resolvers sit quietly in the middle of every connection you make, and the one you use affects your speed, privacy and security. In this article you'll learn the different kinds of resolver, what a recursive resolver actually does step by step, the extra jobs modern resolvers take on, how to find out which resolver you're using, and how to configure one yourself with systemd-resolved and Unbound.

Resolvers vs Authoritative Name Servers

DNS has two sides, and the distinction matters:

Authoritative name servers hold the official records for a domain. They answer only for the zones they're responsible for and never go looking for anything else.
Resolvers hold no records of their own. They answer questions about any domain by asking the authoritative servers and caching what they learn.

A useful analogy is a library. Authoritative servers are the publishers who print the books. The resolver is the librarian who knows how to find any book, fetches it for you, and keeps popular ones on the front desk so the next person doesn't have to wait.

When you query a resolver with dig, you can tell which side answered by looking at the flags:

dig @1.1.1.1 example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5648
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

The ra flag (recursion available) shows this server is a resolver willing to do recursion for you. The absence of the aa flag (authoritative answer) shows the data came from its cache or its own lookups rather than from the domain's own servers.

The Different Types of Resolver

The word "resolver" covers several roles. A single lookup often passes through more than one of them.

Type	What it does	Example
Stub resolver	A minimal DNS client that sends queries to a configured server and accepts the answer. It doesn't do recursion.	The resolver library in Windows, macOS, Linux, Android and iOS
Forwarding resolver	Receives queries and passes them on to another resolver, often caching answers along the way.	A home router, `dnsmasq`, `systemd-resolved`
Recursive resolver	Receives a query and finds the full answer itself by querying root, TLD and authoritative servers.	ISP resolvers, Unbound, BIND, Knot Resolver, public DNS services
Caching-only resolver	A recursive resolver that hosts no zones and exists purely to resolve and cache.	Most standalone Unbound installations

A typical home lookup goes: your laptop's stub resolver asks your router, which forwards to your ISP's recursive resolver, which does the actual recursion. In an office, the chain might be stub resolver, then the company's internal DNS server, then a recursive resolver at the edge of the network.

What a Recursive Resolver Does, Step by Step

Here's what happens inside a recursive resolver when it receives a query for www.example.com with type A.

Check the cache: If it already has a valid A record for www.example.com, it returns it immediately. This is the most common outcome on a busy resolver.
Find the closest known starting point: If the record isn't cached, the resolver looks for the most specific delegation it does have. If it already knows the name servers for example.com, it can go straight there. If it only knows about .com, it starts there. If it knows nothing, it starts at the root.
Query and follow referrals: Each server it asks either gives the answer or a referral to servers further down the tree. The resolver follows referrals until it reaches an authoritative server for the name.
Resolve name server addresses if needed: Referrals list name servers by name. If the parent zone didn't include their IP addresses (glue), the resolver has to look those up first, which can trigger lookups of their own.
Follow CNAMEs: If the answer is a CNAME pointing to another name, the resolver repeats the process for that target.
Validate: If DNSSEC validation is enabled, the resolver checks the signatures all the way up to the root's trust anchor.
Cache and reply: It stores every record it learned for the length of its TTL and sends the answer back to the client.

Starting from the root is relatively rare in practice. A resolver serving thousands of users will have the root and popular TLD delegations in its cache almost permanently, so most cache misses only need one or two queries.

More Than Just Lookups: What Modern Resolvers Do

Resolvers have taken on many extra responsibilities over the years. Not every resolver does all of these, but most good ones do several.

Caching

Caching is the reason resolvers exist in the first place. A large resolver typically answers the vast majority of queries straight from memory. It also caches negative answers, such as "this name doesn't exist", so a burst of queries for a typo doesn't hammer the authoritative servers.

DNSSEC Validation

A validating resolver checks DNSSEC signatures before passing answers on. If validation fails, it returns SERVFAIL rather than a possibly forged answer. When validation succeeds, it sets the ad (authenticated data) flag in the response:

dig @9.9.9.9 example.com A +dnssec +noall +comments | grep flags

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Validation is only as trustworthy as the path between you and the resolver. That's why encrypted DNS and running a validating resolver on your own network are both popular.

Privacy Features

QNAME minimisation (RFC 9156): Instead of sending the full name www.example.com to the root and .com servers, the resolver only reveals as much as each server needs, such as example.com to the .com servers. Unbound, BIND and the large public resolvers support it.
Encrypted transport: Many resolvers accept queries over DNS over TLS (port 853) or DNS over HTTPS (port 443), which hides your queries from the local network.

Resilience

Serve-stale (RFC 8767): If the authoritative servers for a domain become unreachable, the resolver can keep serving recently expired answers for a while rather than failing outright.
Prefetching: Popular records are refreshed just before they expire, so users don't experience the delay of a cache miss.
Server selection: Resolvers track how quickly each authoritative server responds and prefer the faster ones.

Filtering and Policy

Many resolvers can block or rewrite answers for certain domains, for example to stop malware, enforce parental controls or apply corporate policy. In BIND and other servers this is often done with Response Policy Zones (RPZ).

EDNS Client Subnet

Some public resolvers send a truncated version of your IP address to authoritative servers using EDNS Client Subnet, so CDNs can pick a server near you. Others deliberately don't, for privacy reasons. This choice can affect which CDN edge you're sent to.

Which Resolver Are You Using?

There are two questions here: which resolver your device is configured to talk to, and which recursive resolver actually ends up querying the internet on your behalf.

Your Configured Resolver

On Linux with systemd-resolved:

resolvectl status

Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53 198.51.100.53

On these systems /etc/resolv.conf usually points to 127.0.0.53, a local stub listener run by systemd-resolved, which then forwards to the servers shown above.

On macOS:

scutil --dns | grep nameserver | sort -u

  nameserver[0] : 192.0.2.53

On Windows PowerShell:

Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object ServerAddresses

InterfaceAlias               Interface Address ServerAddresses
                             Index     Family
--------------               --------- ------- ---------------
Wi-Fi                               12 IPv4    {192.0.2.53}

The Resolver That Talks to the Internet

If your device points at your router, the router is just forwarding. To find the recursive resolver that's really doing the work, query a special name whose authoritative server replies with the IP address the query came from:

dig whoami.akamai.net +short

198.51.100.200

Google offers a similar service that returns the address as a TXT record:

dig TXT o-o.myaddr.l.google.com +short

"198.51.100.200"

If the address belongs to your ISP, that's your resolver. If it belongs to Cloudflare, Google or Quad9, your router or device is configured to use a public resolver.

Choosing a Resolver

There's no single best resolver for everyone, but these are the things worth weighing:

Speed: A resolver close to you on the network, with a well-populated cache, is fastest. Your ISP's resolver is often quick for this reason.
Privacy: Consider the operator's logging policy and whether it supports encrypted DNS.
Security: Prefer a resolver that validates DNSSEC. Some also block known malicious domains.
CDN accuracy: Resolvers far from you, or ones that don't send client subnet information, may cause CDNs to pick a less optimal edge server.
Control: Running your own resolver gives you full control over caching, logging and filtering.

Running Your Own Resolver With Unbound

Unbound is a fast, validating, recursive and caching resolver that's easy to run on a server, a Raspberry Pi or even a laptop. On Debian or Ubuntu:

sudo apt update
sudo apt install unbound

Create a configuration file such as /etc/unbound/unbound.conf.d/local-resolver.conf:

server:
    # Listen on localhost and a LAN address
    interface: 127.0.0.1
    interface: 192.0.2.10
    port: 53

    # Only allow queries from trusted networks
    access-control: 127.0.0.0/8 allow
    access-control: 192.0.2.0/24 allow
    access-control: 0.0.0.0/0 refuse

    # Privacy and hardening
    qname-minimisation: yes
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes

    # Performance and resilience
    prefetch: yes
    serve-expired: yes
    msg-cache-size: 64m
    rrset-cache-size: 128m

remote-control:
    control-enable: yes
    control-interface: 127.0.0.1

Debian and Ubuntu packages already enable DNSSEC validation with an automatically maintained root trust anchor, so you don't need to add it yourself. Check the configuration and restart:

sudo unbound-checkconf
sudo systemctl restart unbound

If systemd-resolved is already listening on port 53 on the same machine, either bind Unbound to a specific LAN address only or turn off the resolved stub listener.

Test it:

dig @127.0.0.1 example.com A +noall +answer +stats | grep -E "IN|Query time"

example.com.            300     IN      A       203.0.113.10
;; Query time: 84 msec

Run it again and the query time drops to around 0 ms because the answer is now cached. Unbound's control tool lets you inspect and manage the cache:

sudo unbound-control stats_noreset | grep -E "total.num.queries|total.num.cachehits"
sudo unbound-control flush example.com

Critically, never expose a recursive resolver to the whole internet. Open resolvers are abused in DNS amplification attacks. The access-control lines above make sure only your own networks can use it.

Pointing Your Devices at a Resolver

On a Linux machine using systemd-resolved, set the upstream servers in /etc/systemd/resolved.conf:

[Resolve]
DNS=192.0.2.10
FallbackDNS=
DNSSEC=allow-downgrade

Then restart the service:

sudo systemctl restart systemd-resolved
resolvectl status | grep "DNS Servers"

For a whole home or office network, it's usually easiest to change the DNS server your router hands out through DHCP, so every device picks it up automatically.

FAQ: DNS Resolvers

A resolver is one kind of DNS server. "DNS server" can mean either a resolver, which looks up answers for clients, or an authoritative name server, which holds the records for specific domains. They do very different jobs.

It can make lookups faster, but DNS is usually a small part of total page load time. The biggest gains come when your current resolver is slow, overloaded or far away. Measure before and after with dig's query time rather than relying on reputation.

A forwarder passes queries to another resolver and relies on it to find the answer. A recursive resolver finds the answer itself by querying the root, TLD and authoritative servers directly. Home routers are usually forwarders.

It can see the domain names you look up, though not the full URLs or page contents. Encrypted DNS hides queries from your local network but not from the resolver itself, so choose an operator whose privacy policy you trust.

Your device can't turn names into addresses, so websites and apps fail to connect even though your internet connection works. Configuring a second resolver gives your device somewhere else to go.

SERVFAIL means the resolver couldn't get a usable answer. Common causes are unreachable or misconfigured authoritative servers and failed DNSSEC validation. Try the same query with +cd to skip validation; if that works, DNSSEC is the likely cause.

It's worth it if you want full control over caching, validation, logging or filtering, or you run a network for many devices. For a single home computer, a reputable ISP or public resolver is usually fine.

Conclusion

A DNS resolver is the part of DNS that works for you. It takes your question, finds the right authoritative server by following referrals down from the root, validates and caches the answer, and returns it, usually in a few milliseconds thanks to its cache. Along the way, modern resolvers protect your privacy with QNAME minimisation and encryption, guard against forged answers with DNSSEC, and keep sites reachable with features like serve-stale.

Knowing which resolver you use, and what it does, helps you troubleshoot odd lookups and make informed choices about speed and privacy. Check your current setup with resolvectl, scutil or PowerShell, test the real recursive resolver with whoami.akamai.net, and if you want complete control, a small Unbound installation is an easy and reliable place to start.