DNS Resolver

A DNS resolver receives queries from clients and finds the correct IP address or DNS record by contacting other DNS servers on their behalf. It is the entry point most applications use into the DNS system, and it hides the complexity of walking the global name hierarchy from each individual program.

Two kinds of resolvers exist in practice. A *stub resolver* lives inside the operating system or application library and simply forwards every query to a configured upstream — typically read from /etc/resolv.conf, DHCP or a manual setting. A *recursive resolver*, sometimes called a full-service resolver, is the upstream itself: it walks root → TLD → authoritative server and returns one finished answer. Most operators run dedicated recursive DNS servers — Unbound, BIND, Knot Resolver — while end systems just speak to them as stubs.

To keep latency and traffic down, every resolver maintains a cache keyed by name and record type and respects the TTL on each answer. Negative answers (NXDOMAIN, empty NODATA) are also cached, bounded by the SOA minimum field, which is why DNS propagation of a brand-new name can lag behind its actual publication. Validating resolvers also perform DNSSEC checks, returning SERVFAIL rather than unsigned data when a chain of trust is broken.

Public examples include Cloudflare 1.1.1.1, Google 8.8.8.8 and Quad9 9.9.9.9. ISPs typically run their own resolvers and hand them out via DHCP, while enterprise networks often deploy internal resolvers that combine public root traversal with split-horizon answers for private zones. Resolvers also retrieve MX, PTR, SPF, DKIM and DMARC records used by mail flow, which is why an outage of the recursive layer breaks far more than just web browsing.