When people talk about “DNS,” they usually picture recursive resolvers, authoritative servers, and records out on the internet. The first DNS decisions happen much closer than that.
Every lookup starts inside the device itself, in the stub resolver: the component on laptops, phones, servers, and containers that decides if, when, and how a DNS query ever leaves the machine. It is also why DNS behavior differs between operating systems, networks, and applications.
The “stub” in stub resolver
A stub resolver is the minimal DNS client built into an operating system, runtime, or application. It accepts name resolution requests and turns them into queries against configured upstream resolvers.
The “stub” is literal: it doesn’t perform recursive resolution, walk the hierarchy, or talk to root servers. It asks a recursive resolver to do that work. (Some applications embed a full recursive resolver of their own, at which point they’ve stopped being stubs.)
Where stub resolvers live
Stub resolvers exist at multiple layers:
- Operating system resolvers such as the Windows DNS Client, macOS mDNSResponder, and systemd-resolved on Linux.
- Language runtimes and libraries like glibc, musl, or custom resolver stacks embedded in applications.
- Browsers and applications that bypass the OS resolver for some or all queries, with their own asynchronous resolution logic or encrypted transports.
The layering means one lookup can pass through more than one stub resolver. An application applies its rules, hands the request to the OS resolver, and the OS applies its own logic before anything touches the network. An application with its own embedded resolver skips the OS path entirely.
What happens before a query leaves the device
Before anything is sent to the network, the stub resolver works through a series of questions.
Is the name handled locally?
Some names are answered without any unicast DNS. localhost and hosts-file entries resolve from local tables with no network traffic at all, while multicast namespaces such as .local are queried over the local link instead of through a DNS server.
Is the name eligible for DNS?
Stub resolvers apply search domains, suffix rules, and name qualification. A short name like printer might become printer.office.example before any query exists, and if several expansions are possible, the stub may try them in sequence, turning one application request into several DNS queries.
Is there a cached answer?
Many stub resolvers keep a small, short-lived local cache, and a recent failure may be cached too, suppressing further queries for a while. Others, glibc among them, keep none at all.
These caches don’t behave like recursive resolver caches. Many impose minimum or maximum lifetimes, ignore very short TTLs, or cap retention regardless of what the authoritative server published. The upshot is that changing a record’s TTL doesn’t reliably predict when an endpoint will actually re-query.
Which protocol should be used?
Modern stubs choose among plain DNS over UDP or TCP, DNS over TLS, and DNS over HTTPS, based on OS configuration, application preference, network policy, or hardcoded defaults.
Which upstream resolver gets the query?
With multiple resolvers configured, the stub decides which to use and when to fail over, and the algorithm varies sharply by OS and version. Some race queries against several resolvers. Some try them in order. Some mark a resolver unhealthy and route around it.
Stub resolvers are policy engines
Treat the stub resolver as a policy engine, not a forwarding component. It enforces:
- Namespace boundaries
- Resolution order
- Caching behavior
- Transport choices
- Retry and timeout behavior
By the time a query reaches a recursive resolver, most of these decisions are made and nothing upstream can reverse them.
Why stub resolvers differ so much
Stub behavior tends to follow each platform’s priorities. Desktop systems favor user experience and fast fallback. Server systems favor predictability and standards compliance. Mobile platforms favor battery life and privacy.
No single behavior is “correct,” and the standards leave much of this logic unspecified. What an OS actually does is frequently established by testing it, not by reading about it.
Why this matters
Many DNS surprises are stub resolver behavior wearing a disguise: queries that bypass the configured resolvers, two applications on one device getting different answers, encrypted DNS appearing where nobody enabled it, resolution that works on one network and fails on another.
When debugging DNS, starting at the recursive resolver is often starting too late. Start at the stub that decided how the query would be formed and where it would go.
Summary
Stub resolvers are the DNS you actually use. They run on every endpoint, apply policy, and shape queries before the network ever sees them. Their differences are why DNS behavior varies by OS, application, and environment, and why the upstream resolver only ever sees the tail end of a decision process that began on the device.