DNS Resolver

A DNS resolver is a server that receives a domain query from a device and finds the requested DNS record. It acts as the client’s entry point into the Domain Name System, checking cached data first and contacting other DNS servers when a fresh answer is required.

How a DNS resolver works

When a user enters a domain in a browser, the operating system sends a query to a configured recursive resolver. That server checks its cache for a valid answer. If the record is present and its TTL has not expired, the resolver returns it immediately.

For an uncached query, the resolver follows the DNS hierarchy. It asks a root server where to find the relevant top-level domain server. The top-level domain server refers it to the domain’s authoritative nameserver, which returns the requested record. The resolver sends that answer to the client and caches it for later requests.

Recursive and iterative queries

A client normally sends a recursive query, asking the resolver to return a complete answer or an error. The resolver then uses iterative queries to follow referrals through root, top-level domain, and authoritative servers.

This separation keeps client devices simple. Browsers and operating systems do not need to contact every DNS layer themselves. The resolver performs the lookup, validates responses when supported, and applies caching rules.

DNS resolver caching

Caching improves speed and reduces traffic. The resolver stores records according to their DNS TTL. Repeated requests can use the cached response until the timer expires.

Resolvers also cache negative answers, including responses that a name does not exist. This behavior prevents repeated queries for invalid hostnames but can delay visibility after an administrator creates a previously missing record.

Public, ISP, and local resolvers

Internet providers usually assign resolvers automatically. Organizations may operate internal resolvers to apply local policies and resolve private names. Public services offer an alternative with different performance, privacy, filtering, and security characteristics.

A local stub resolver runs on the user’s device. It forwards queries to a recursive service rather than walking the DNS hierarchy itself. Home routers may also relay queries and maintain a small cache.

Security and privacy

A validating resolver can use DNSSEC to verify that signed DNS data has not been modified. Validation rejects forged responses when the chain of trust is complete, but it does not encrypt the query.

DNS over HTTPS and DNS over TLS encrypt traffic between the client and resolver. They reduce local observation and manipulation but transfer trust to the selected resolver. The resolver can still see the requested names unless additional privacy mechanisms apply.

Common DNS resolver problems

Stale cache entries can return an old address after a DNS change. Resolver filtering can block a domain intentionally, while a temporary upstream failure can produce timeouts or server-failure responses. Incorrect device settings may point to an unavailable resolver.

Compare answers from multiple recursive services and query the authoritative nameservers directly. If authoritative data is correct but one resolver differs, inspect cache lifetime, validation status, filtering policy, and network reachability.

Choosing a DNS resolver

Evaluate reliability, response time, privacy policy, DNSSEC validation, encrypted transport support, logging practices, and filtering behavior. A fast resolver is not sufficient if it produces inconsistent answers or lacks the controls an organization requires.

The Cloudflare DNS overview explains how recursive resolvers interact with root, top-level domain, and authoritative servers. Administrators should monitor resolver health and maintain more than one reachable service to avoid a single point of failure.