When people talk about “DNS,” they usually picture recursive resolvers, authoritative servers, and records on the internet. But the first DNS decisions happen much closer to the user.
Every DNS lookup starts inside the device itself. The component responsible for that work is the stub resolver. It runs on endpoints like laptops, phones, servers, and containers, and it decides if, when, and how a DNS query ever leaves the device.
Understanding stub resolvers explains why DNS behavior often differs between operating systems, networks, and applications.
What a stub resolver is
A stub resolver is the DNS client built into an operating system or runtime environment. Its job is to accept name resolution requests from applications and turn them into DNS queries sent to configured upstream resolvers.
It is called a “stub” because it does not perform full recursive resolution. It does not walk the DNS hierarchy or talk to root servers. Some applications embed their own full recursive resolvers, but when they do, they are no longer acting as stub resolvers.
Where stub resolvers live
Stub resolvers exist at multiple layers:
- Operating system resolvers such as 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 entirely for some or all queries. Modern browsers may implement their own asynchronous DNS resolution logic or encrypted DNS transports rather than relying on the operating system.
This layering matters because more than one stub resolver may be involved in a single lookup. An application might apply its own rules before handing a query to the OS, which then applies additional logic before sending anything upstream.
What happens before a query leaves the device
Before a DNS query is sent to the network, the stub resolver typically evaluates several questions.
Is the name handled locally?
Some names never leave the device at all.
Examples include localhost, host-specific or interface-specific names such as names bound to a local network interface, and multicast or link-local namespaces such as .local on many systems. These are often resolved using local tables or multicast mechanisms instead of unicast DNS.
Is the name eligible for DNS?
Stub resolvers may apply search domains, suffix rules, or name qualification logic. A short name like printer might be expanded into printer.office.example before any query is sent.
If multiple expansions are possible, the stub resolver may try them in sequence, sometimes generating several DNS queries for a single application request.
Is there a cached answer?
Most stub resolvers maintain a local cache. This cache is usually small and short lived, but it can prevent repeated queries from leaving the device.
Negative caching also matters. A recent failure may be cached and suppress further queries for a period of time.
Stub resolver caches typically do not behave like recursive resolver caches. Many impose minimum or maximum cache lifetimes, ignore very short TTLs, or cap how long an answer can be retained regardless of the authoritative TTL. This behavior varies by operating system and implementation and is often poorly documented.
As a result, changing a record’s TTL does not reliably predict when an endpoint will re-query DNS.
Which protocol should be used?
Modern stub resolvers may choose between plain DNS over UDP or TCP, DNS over TLS (DoT), or DNS over HTTPS (DoH). The selection may depend on OS configuration, application preferences, network policy, or hardcoded defaults. This behavior is often partially documented and partially inferred from observation.
Which upstream resolver should receive the query?
If multiple resolvers are configured, the stub resolver decides which one to use and when to fail over. The selection algorithm varies significantly by operating system and version.
Some resolvers race queries. Others try them sequentially. Some mark resolvers as temporarily unhealthy.
Stub resolvers are policy engines
A useful mental model is to treat the stub resolver as a policy engine, not a simple 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, many decisions have already been made and cannot be reversed upstream.
Why stub resolvers differ so much
Stub resolver behavior is shaped by operating system design goals.
Desktop operating systems tend to prioritize user experience and fast fallback. Server oriented systems often favor predictability and standards compliance. Mobile platforms emphasize battery life and privacy.
There is no single “correct” behavior, and much of the logic is not fully specified in standards. As a result, real world behavior must often be learned through testing and observation.
Why this matters
Many DNS surprises are actually stub resolver behavior. Examples include queries appearing to bypass configured resolvers, inconsistent results between applications on the same device, unexpected use of encrypted DNS, and resolution working on one network but not another.
When debugging DNS, starting at the recursive resolver is often too late. The correct starting point is the stub resolver 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 endpoints, apply policy, and shape DNS traffic before it ever leaves the device.
Understanding their role explains why DNS behavior varies by OS, application, and environment, and why upstream resolvers only see part of the decision process.