Unbound

A focused role in your infrastructure

Unbound is a recursive, caching DNS resolver. It follows the DNS hierarchy to find answers on behalf of clients, validates DNSSEC-signed data and caches the results. It can also forward queries to other resolvers, or work in a fleet behind a load balancer.

This makes Unbound suitable for several roles: a resolver for a local network, a component of a router or security appliance, an enterprise DNS service, or part of a service-provider resolver infrastructure. Applications can use its resolution and validation capabilities directly through libunbound.

Unbound’s support for local data and policy allows it to answer private names and adapt responses to operational requirements. Its primary purpose remains recursive resolution. Publishing authoritative zones and managing their signatures are separate roles, served by other software.

Performance beyond queries per second

A resolver’s performance depends on more than how many queries it can answer in a controlled test. Cache contents, DNSSEC validation, upstream response times, traffic patterns and configuration all affect the resources required to answer a request.

Unbound is multi-threaded and caches DNS data and validation-related information to avoid repeating work unnecessarily. Operators can adjust thread counts, cache sizes and other resource limits to suit their systems.

Caching is particularly important. An answer available locally can be returned without waiting for an authoritative server. An uncached query may require several exchanges with servers beyond the operator’s control. Optional prefetching refreshes frequently requested records before they expire, helping keep useful data available in the cache.

Independent testing, including CZ.NIC’s resolver benchmarks, provides useful evidence of performance under specified conditions. Such results should be read alongside the tested versions, hardware, configuration and workload. They are a starting point for evaluation, rather than a prediction of every deployment.

For production planning, the important questions include throughput and latency, but also memory use, behaviour during traffic spikes and the capacity left when resolution becomes more expensive.

Handling an unreliable and sometimes hostile Internet

A recursive resolver communicates with servers it does not control. Some are unavailable or misconfigured. Others may deliberately return misleading answers or attempt to make the resolver perform excessive work.

Unbound applies checks throughout the resolution process. Responses are examined before data is accepted into the cache, and DNSSEC validation verifies signed data against a chain of trust. Checks on relevance and consistency help prevent unrelated or inappropriate records from influencing later answers.

Validation itself must also be tightly controlled. An attacker can construct data that requires disproportionate effort to process, including combinations of DNSSEC keys, signatures and denial-of-existence records. Unbound includes limits on validation work and mechanisms for managing outstanding queries and overloaded request queues.

Resilience also means handling ordinary failures. Servers time out, network paths break and upstream services become temporarily unavailable. Unbound provides configurable retry behaviour and features such as serving stale data, which can preserve useful answers when fresh data cannot be retrieved.

These mechanisms involve trade-offs between freshness, availability, resource consumption and response time. Unbound exposes controls so that operators can make those choices for their environment.

A practical starting point, with room to adapt

Unbound provides defaults intended to support normal validating resolution without requiring operators to assemble a configuration from scratch. Features such as QNAME minimisation reduce the query information disclosed to servers along the resolution path.

A deployment still needs an appropriate configuration for its environment. Listening interfaces, client access, trust-anchor management and operating-system packaging all deserve attention. A local resolver and a service intended for a wider network have different requirements.

Beyond that starting point, Unbound supports more specialised arrangements:

• Privacy and transport: encrypted DNS services for clients and supported encrypted forwarding options.
• Local resolution: private names, local answers and forwarding or stub configurations for selected domains.
• Policy enforcement: client-specific behaviour, tags, views and Response Policy Zones.
• Operational visibility: statistics, logging, remote control and optional detailed traffic reporting through dnstap.

These capabilities allow the same resolver to serve different operational needs without requiring every deployment to use every feature.

The documentation covers configuration, performance tuning, monitoring and policy mechanisms in detail.

From network appliances to large-scale deployments

Unbound runs in environments with very different constraints. A network appliance may have limited memory and processing capacity. An enterprise may need internal resolution, selective forwarding and integration with security policies. A large resolver deployment may prioritise concurrency, automation and predictable behaviour under sustained load.

The common requirement is dependable resolution under the operator’s control. Unbound’s configuration options and library interface allow it to be integrated into a larger system as well as operated as a standalone service.

Public operational reports provide useful examples. At DNS-OARC, Microsoft described deploying dual-stack recursive DNS using Unbound and Windows DNS Server in its internal resolver infrastructure. The presentation also covered production experience with serving stale data described in RFC 8767.

Such reports are valuable because they describe deployment decisions and operational experience, rather than only listing supported features. They also illustrate why availability, failure handling and interoperability deserve as much attention as peak throughput.

Standards informed by implementation experience

DNS depends on independently developed systems agreeing on how to interpret and exchange data. Standards support that interoperability, but implementing them on the public Internet also exposes ambiguities, unexpected interactions and operational constraints.

NLnet Labs engineers contribute to the development of DNS standards as well as their implementation. Examples include QNAME minimisation, DNS Cookies and ECDSA support in DNSSEC. These address different needs: limiting unnecessary disclosure, improving resistance to certain forms of abuse and supporting efficient cryptographic validation.

This work also addresses barriers to deploying DNSSEC. NLnet Labs engineers co-author the IETF DNSOP working group’s dry-run DNSSEC proposal, which would allow operators to test validation before making it mandatory for a previously unsigned zone. Participating resolvers would report validation failures without turning those failures into service interruptions for ordinary users during the test phase. Experimental implementation work in Unbound helps explore the proposal in practice. The work is still in development, and the test phase does not provide the full protection of enforced DNSSEC validation.

Unbound’s RFC Compliance reference documents its standards support. Individual capabilities may be enabled by default, optional or dependent on configuration; the corresponding documentation explains their use.

Continuous maintenance and security work

A mature resolver is not finished software. Changes elsewhere on the Internet, new deployment patterns and new research continually expose opportunities to improve its behaviour.

Unbound’s maintenance includes regression testing, fuzzing, review of external reports and investigation of problems encountered by operators. Work on demanding policy workloads, including large RPZ datasets, is one example of how operational experience informs development.

Security research now also includes tools assisted by large language models. These provide another source of test cases and findings that require technical assessment. The important outcome is not the number of reports received, or a low or high CVE count in isolation. It is understanding the impact, correcting the underlying behaviour and helping operators deploy the appropriate updates. Release notes and security advisories provide the record of those changes.

Operating Unbound with confidence

Unbound’s source code and functionality are available under the BSD 3-Clause licence. Operators can evaluate it, inspect its implementation and adapt it to their infrastructure without a separate enterprise edition.

The documentation provides installation guidance, operational explanations and configuration references. The NLnet Labs community forum provides a place to discuss deployments, report unexpected behaviour and learn from other users.

For organisations that rely on Unbound as part of critical infrastructure, professional support and consultancy provide direct access to the development team. Support agreements combine service-level commitments, assistance and early security vulnerability notices under non-disclosure.

That relationship supports both the organisation operating Unbound and the continued engineering behind it.