A DNS resolver is the component of the Domain Name System that finds the answer to a DNS query on behalf of a client, typically by turning a domain name into an IP address. In DNS terminology the word covers both the small stub resolver built into every operating system and the recursive resolver that does the actual lookup work by querying authoritative name servers and caching what it learns.
Every web request, email delivery and API call usually begins with a resolver lookup. Its speed, correctness and privacy settings therefore shape the experience of all applications on a device or network, even though users rarely see it.
How a DNS resolver answers a query
Resolution starts when an application asks the operating system for an address. The stub resolver checks its local cache and hosts file, then sends a query with the recursion desired flag to a configured recursive resolver, usually over UDP port 53.
If the recursive resolver has no cached answer, it walks the DNS hierarchy. It asks a root server, which refers it to the servers of the top-level domain, which in turn refer it to the authoritative servers of the domain. The final answer is returned to the client and stored in cache for the record’s TTL.
| Step | Queried server | Response |
|---|---|---|
| 1 | Root server | Referral to the .org name servers |
| 2 | .org TLD server | Referral to the example.org name servers |
| 3 | Authoritative server for example.org | A or AAAA record for shop.example.org |
| 4 | Recursive resolver to client | Answer plus remaining TTL |
In practice the root and TLD referrals are almost always cached, so most lookups need one network round trip or none. A cached answer typically returns in about a millisecond on the local network, while an uncached lookup can take tens to hundreds of milliseconds.
Types of DNS resolvers
Resolvers differ in how much of the lookup they perform themselves and where they run. The table summarizes the roles found in real networks.
| Type | What it does | Where it runs |
|---|---|---|
| Stub resolver | Sends queries to a recursive resolver, minimal cache | Operating system or application |
| Recursive resolver | Performs the full lookup and caches results | ISP, enterprise, public DNS service |
| Forwarder | Passes queries to another resolver, often with a cache | Home router, branch office |
| Validating resolver | Checks DNSSEC signatures before answering | Recursive resolvers with validation enabled |
| Browser built-in resolver | Encrypted lookups independent of system settings | Some browsers |
The difference from an authoritative DNS server is fundamental: the authoritative server holds the zone data and answers only for its own domains, while a resolver holds no zone data and answers for any name by asking others.
Caching, TTL and negative answers
Caching is what makes DNS scale. Each record carries a time to live (TTL) in seconds, set by the zone owner, and a resolver may reuse the record until it expires. Common TTLs range from 60 seconds for records that change often to 86,400 seconds (one day) for stable ones.
Resolvers also cache failures. A negative answer such as NXDOMAIN is kept for a period derived from the zone’s SOA record, which protects authoritative servers from repeated queries but can delay the visibility of newly created names. Many resolvers can serve stale answers briefly when authoritative servers are unreachable.
| Setting | Short value | Long value |
|---|---|---|
| Record TTL | Fast changes, more queries | Fewer queries, slower changes |
| Negative cache time | New names visible quickly | Fewer repeated failed lookups |
| Resolver maximum TTL cap | Fresher data | Better hit rate |
Encrypted DNS and resolver privacy
Classic DNS travels in plain text, so anyone on the path can read and alter queries. Encrypted transports protect the connection between client and resolver, though the resolver operator still sees every query.
| Transport | Port | Main property |
|---|---|---|
| Classic DNS | 53 over UDP or TCP | Universal, unencrypted |
| DNS over TLS (DoT) | 853 over TCP | Encrypted, easy to identify and filter |
| DNS over HTTPS (DoH) | 443 | Encrypted, blends with web traffic |
| DNS over QUIC (DoQ) | 853 over UDP | Encrypted, low latency, no head-of-line blocking |
Recursive resolvers can further reduce exposure with QNAME minimization, sending each upstream server only the part of the name it needs. Choosing a resolver is ultimately a trust decision, because it sees the browsing pattern of every client that uses it.
Common resolver problems
Many outages blamed on websites are in fact resolver issues. Typical symptoms and causes include the following.
- Old address after a migration: cached records live until their TTL expires; lower the TTL days before planned changes.
- SERVFAIL for one domain only: often a DNSSEC validation failure caused by expired signatures at the domain.
- Slow first page loads: a distant or overloaded resolver adds latency to every uncached lookup.
- Different answers on different networks: split-horizon DNS, filtering policies or geographic routing based on the resolver location.
- Cache poisoning risk: resolvers without source port randomization or DNSSEC validation are easier to spoof.
Explained without jargon
Computers find each other by numbers, but people type names. A DNS resolver is the helper that looks up the number for a name, much like an assistant who checks a phone directory for you.
A good assistant also remembers recent answers, so the next time you ask for the same name, the reply comes back almost instantly instead of requiring another search.
A typical use case
A company with 400 employees moves its intranet to a new hosting provider over a weekend. Two weeks earlier, the administrator lowers the TTL of the intranet record from one day to five minutes, so that resolvers will not keep the old address for long.
The office runs its own recursive resolver with DNSSEC validation and a large cache, and laptops outside the office use encrypted DNS to the same service. On Saturday the record is switched to the new address. Within five minutes all clients reach the new server, and after a stable week the TTL is raised again. The migration causes no visible downtime for staff.