DNS glossary

What is a DNS stub resolver?

A DNS stub resolver is a client-side software component that sends DNS queries on behalf of applications and returns the answers. It does not walk the DNS hierarchy itself, but forwards each query to a configured recursive resolver and relies on that server to do the work.

Let's simplify your DDI
Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

A DNS stub resolver is a client-side software component that forwards DNS queries from applications to a configured recursive resolver without performing iterative lookups itself, relying entirely on the resolver's response. Because every networked device includes a stub resolver and its configuration affects all application name lookups, misconfigurations—such as unreachable resolver addresses, stale caches, or incorrect search suffixes—cause intermittent failures, slow page loads, and application timeouts even when network connectivity is healthy. Operations teams manage stub behavior indirectly through DHCP distribution and endpoint management tools, while also facing security considerations around unencrypted DNS traffic and the potential for applications to override resolver settings with encrypted transports like DNS over TLS or DNS over HTTPS.

  • A stub resolver caches results locally and may check a hosts file before querying the recursive resolver, reducing lookup latency for repeated name resolutions on the same device.
  • When the first configured resolver is unreachable, the stub resolver waits for a timeout before attempting the next server in its list, causing multi-second delays that vary inconsistently across devices depending on the operating system.
  • DNS over TLS and DNS over HTTPS can protect stub-to-resolver communication through encryption, but they may redirect resolution away from resolvers the organization monitors if applications configure their own encrypted transport settings.

DNS stub resolver at a glance

AttributeValue
CategoryDNS client component
Defined inRFC 1034 and RFC 1035, which describe the resolver role; RFC 9499 defines the stub resolver term
Protocol and portDNS over UDP and TCP on port 53 by default
OSI layerApplication layer
Primary useForwarding application name lookups to a recursive resolver
Related termsRecursive resolver, DNS resolver, DNS caching, DHCP, DNS over HTTPS, DNS over TLS

How DNS stub resolver works

A stub resolver sits between applications on a device and a recursive resolver. It performs no iterative lookups of its own, so its work is limited to passing queries along and handing back results.

  1. Application requests a name: An application calls a system library function, such as getaddrinfo, to look up a host name.
  2. Local sources are checked: The stub resolver may first consult a hosts file or a local cache and answer immediately if it finds a match.
  3. Query is sent to a recursive resolver: If there is no local answer, the stub sends a DNS query with the recursion desired flag set to the resolver address it has been configured with. That address is often learned through DHCP or set by hand.
  4. Answer is returned: The recursive resolver does the full lookup and replies. The stub passes the addresses or the error code back to the application and may cache the result for the record's time to live.

If the first configured resolver does not respond, the stub typically retries or tries the next one in its list. Many stubs can also use encrypted transports such as DNS over TLS or DNS over HTTPS to reach the recursive resolver.

Why DNS stub resolver matters in enterprise networks

Every networked device has a stub resolver, so the way it is configured affects each connection an application makes by name. Because the stub depends entirely on the resolver addresses it is given, wrong or unreachable settings cause slow page loads, failed logins and application timeouts even when the network itself is healthy.

Operations teams usually control stub behavior indirectly. Resolver addresses and search domains are distributed through DHCP, and client settings can be pushed by endpoint management tools. Inconsistent search suffixes, stale local caches and lists that include unreachable servers are common causes of intermittent lookup failures that are hard to trace.

The stub is also a security boundary. Classic DNS between the stub and the resolver on port 53 is unencrypted, so anyone on the path can observe or alter queries. DNS over TLS, defined in RFC 7858, and DNS over HTTPS, defined in RFC 8484, protect that hop, but they can also move resolution away from the resolvers an organization monitors if applications set their own.

DNS stub resolver vs Recursive DNS server

A stub resolver only forwards queries from a client and caches at most locally, while a recursive DNS server performs the full lookup by querying other servers on the client's behalf. What is Recursive DNS server?

AttributeDNS stub resolverRecursive DNS server
LocationRuns on the client device as part of the operating system or an applicationRuns as a network service, often at the enterprise or an ISP
Lookup methodSends a single query with recursion desired set and waits for the answerFollows referrals from root to authoritative servers
Cache scopeServes one device, if it caches at allServes many clients from a shared cache
Configuration sourceResolver addresses set manually or learned through DHCPRoot hints or forwarders set by the administrator

Common DNS stub resolver issues

If the first configured resolver is down, the stub waits for a timeout before trying the next one, so users see multi-second delays on every lookup. Failover timing varies by operating system, which makes the symptom inconsistent across devices.

Short names are expanded using the configured search domains, so a lookup may generate several failed queries before one succeeds. A wrong suffix list can also resolve a short name to an unintended host.

A local cache can keep returning an old address after a record is changed, even though the recursive resolver already has the new one. Flushing the client cache clears the symptom, which points to the stub rather than the server.

When a VPN client changes resolver settings, internal names may fail off the VPN or public names may go to the internal resolver. Mixed resolver lists in which only some servers know internal zones produce intermittent failures.

A wrong DNS server option in a DHCP scope gives every client in that subnet the same bad resolver address. Failures then appear across many devices at once while IP connectivity still works.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

Talk to us

DNS stub resolver FAQ

Related terms

Article

Recursive DNS server

Responsible for providing the proper IP address of the intended domain name to the requesting host; the first servers contacted as the result of a request.

Learn more
Article

Caching DNS server

A server that handles recursive requests from clients.

Learn more
Article

DNS query / DNS request

Demand for information sent from a user’s computer (DNS client) to a DNS server.

Learn more
Article

Recursive query

A kind of query in which the DNS server will do all the job of fetching the answer and giving it back to you; the DNS server might also query other DNS servers on your behalf.

Learn more
Article

DHCP (Dynamic Host Configuration Protocol)

The standard mechanism to dynamically assign IP addresses within a network.

Learn more
Article

Forwarding DNS Server

A DNS server on a network that forwards DNS queries for external DNS names to DNS servers outside that network.

Learn more
Article

DNS server

Also called a DNS nameserver, it stores DNS records and responds to and resolves DNS queries from devices. Learn More

Learn more
Article

Time to Live (TTL)

A setting for each DNS record that specifies how long a resolver is supposed to cache the DNS query before it expires.

Learn more
Browse the full glossary