Unbound - Authoritative Recursive Caching DNS Server

[rgnldo]

Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. Late 2019, Unbound has been rigorously audited, which means that the code base is more resilient than ever.

To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. In addition, it supports various modern standards that limit the amount of data exchanged with authoritative servers. These standards do not only improve privacy but also help making the DNS more robust. The most important are Query Name Minimisation, the Aggressive Use of DNSSEC-Validated Cache and support for authority zones, which can be used to load a copy of the root zone. [about] [documentation]

For those who want a simplified script-installer unbound_manager (also available on amtm - the Asuswrt-Merlin Terminal Menu) there is another specific thread with support back to the script.

 

[mike37]

THANK YOU! for creating and reminding us of this, ranido!

 

[rgnldo]

@Marin @Delusion @Swistheater @Mutzli rearranged the Unbound installation tip with Stubby. Configuring Stubby servers with IPV6 only will have better results.

 

[DonnyJohnny]

may i know the pro and con of using unbound +stubby over dnsmasq+stubby?

 

[rgnldo]

may i know the pro and con of using unbound +stubby over dnsmasq+stubby?

Dnsmasq is just a DNS query forwarder. Its main function is to organize DHCP distribution and cached DNS query. For embedded devices, ARM7/8 is the right solution. However, nowadays, the use of an authoritative and recursive server is fundamental. Unbound does this. However, there is a way to aggregate in Dnsmasq with Unbound. This is the purpose of this post.

 

[dave14305]

Interesting. So clients point to dnsmasq. dnsmasq points to Unbound. Unbound points to Stubby. Stubby points to the DNS Privacy servers selected in the GUI. Or is that just for TLD queries (.)? The point of Unbound is to do its own recursive lookups, so I’m trying to understand the benefits of Stubby in this setup.

Nice work, even if I don’t fully understand it yet.

 

[rgnldo]

Nice work, even if I don’t fully understand it yet.

Simple. The dnsmasq is modular, allows the delegation of cache function and queries to other software, in this case Unbound. Active Unbound will forward encrypted resolution to Stubby.

 

[dave14305]

Simple. The dnsmasq is modular, allows the delegation of cache function and queries to other software, in this case Unbound. Active Unbound will forward encrypted resolution to Stubby.

How is Unbound doing its own recursive lookups if everything is forwarded to DoT servers (e.g. Quad9, Cloudflare, etc.)?

I read this thread also to try to understand: https://www.reddit.com/r/openwrt/comments/94embn/comment/e3l2bg3

 

[rgnldo]

How is Unbound doing its own recursive lookups if everything is forwarded to DoT servers (e.g. Quad9, Cloudflare, etc.)?

Stubby is set to the 'forward-zone' option, that is, the authoritative and recursive query is active but forwarded in TLS mode via Stubby.

 

[Smokey613]

How CPU intensive is this setup? Will it severely task my 68U if I set this up and what are the benefits over the standard dnsmasq / stubby / DoT setup? Just trying to learn.

 

[dave14305]

ARGS="-c /opt/var/lib/unbound/unbound.conf"

Doesn’t this need to be /opt/etc/unbound/unbound.conf?

Edit: no, the instructions say to create the file in /opt/etc, but the configs all expect /opt/var/lib.

 

[dave14305]

Stubby is set to the 'forward-zone' option, that is, the authoritative and recursive query is active but forwarded in TLS mode via Stubby.

I don't see any evidence that Unbound is still doing its own recursive queries when a forward-zone is set for . (dot). It's just forwarding all queries to the Stubby resolvers who do the recursive queries. I'm not sure I see the benefit of Unbound in this case.

I ran tcpdump without having Stubby enabled and no forward-zone config and watched Unbound send all the needed recursive queries to root servers and NS servers. Then I setup a forward-zone for . (dot) just to point to 9.9.9.9 without DoT. I only saw non-recursive queries going to 9.9.9.9. So Unbound added no value beyond dnsmasq in this scenario, as best I can determine.

How do we make it better?

 

[rgnldo]

I ran tcpdump without having Stubby enabled and no forward-zone config and watched Unbound send all the needed recursive queries to root servers and NS servers. Then I setup a forward-zone for . (dot) just to point to 9.9.9.9 without DoT. I only saw non-recursive queries going to 9.9.9.9. So Unbound added no value beyond dnsmasq in this scenario, as best I can determine.

How do we make it better?

I don't know how you are diagnosing. In my tests everything is working as proposed. Remember that Unbound is not fully active.
I generally use unbount-control

unbound-control -c /opt/var/lib/unbound/unbound.conf stats_noreset | grep total.num

and iftop

iftop -n -P -i lo

 

[dave14305]

Unbound works fine, but it is only functioning as a forwarding resolver, not a recursive resolver with this config. It’s no better than dnsmasq in this case. I’ve always understood the value of Unbound to be that you can bypass any upstream recursive resolvers.

I suppose we’re not understanding each other well. Maybe someone else will comment based on their experience. I’m happy to learn what I might be missing here.

I did setup Unbound to use TLS and DNSSEC to Quad9 as an experiment, only running dig locally on my router with logging enabled in unbound. Very different behavior when a forward zone is configured versus not.

 

[rgnldo]

I did setup Unbound to use TLS and DNSSEC to Quad9 as an experiment, only running dig locally on my router with logging enabled in unbound. Very different behavior when a forward zone is configured versus not.

Note that Unbound will bring recursive and root server features to dnsmasq. When you enable the forwader-zone function unbound ignores resolution by your ISP, assuming another resolver. In this case, stubby is the name resolver with TLS transport. Simple. You may not set fowader-zone, but the resolution will be trafficked QUERY by your ISP.

 

[rgnldo]

Unbound is a validating, recursive, and caching DNS resolver.
Unbound is developed and currently maintained by NLnet Labs, a non-profit, public benefit foundation.
It is based on the ideas and algorithms taken from a Java prototype developed by Verisign Labs, Nominet, Kirei, and ep.net.
Unbound was released to the public in May 2008 under the BSD Licensing model which allows its use in other products without any major restrictions.

In this article, we'll discuss ten (10) reasons to use Unbound as a validating, recursive, and caching DNS service part of your Core Network Services (CNS) Infrastructure.

1. Lightweight - Unbound was originally developed in C based from a Java prototype. Its authors wrote the source code to be very modular in design, and to be very lightweight. They wanted to design a solution that would be the smallest possible that would achieve the minimal requirements as a validator, resolver, and caching server. In addition to meeting these requirements, they wanted the server to achieve very high-performance. Unbound's minimalistic design will be a recurring theme throughout the rest of this article.
2. Easy to configure - Unbound is very easy to configure. It is configured through a configuration file that is quite like YAML (Yet Another Markup Language). There are not a great number of configuration directives needed to set up Unbound since the service has a relatively simple and single role.
   
   Example 1 - minimal configuration for caching-only DNS
   
   # unbound.conf for a local subnet.
   server:
   interface: 192.168.1.10
   interface: FD00:2216:9203:2::4
   access-control: 192.168.0.0/16 allow
   access-control: ::1 allow
   verbosity: 1
   
   Example 2 - enabling DNSSEC validation
   
   server:
   # chroot disabled here as example, to make pathnames work
   chroot: ""
   directory: "/etc/unbound"
   
   # trust anchors. In separate files, to be updated from cron.
   trust-anchor-file: "/etc/unbound/anchors/root.anchor"
   # ... more trust anchors
   trust-anchor-file: "/etc/unbound/anchors/br.anchor"
   trust-anchor-file: "/etc/unbound/anchors/se.anchor"
   trust-anchor-file: "/etc/unbound/anchors/bg.anchor"
   trust-anchor-file: "/etc/unbound/anchors/pr.anchor"
   
   As you can see, it's quite easy to set up and configure Unbound.
   
   
3. High performance - Unbound's lightweight code structure, simple and modular design contribute to making Unbound an extremely high-performing recursive name server. Initial benchmark testing has shown Unbound to offer up to 2x the performance over other name servers (with or without DNSSEC Validation enabled). Unbound essentially has two (2) modes of operation:
   
   Threaded mode - uses the Libevent cross compiled wrapper library for added scalability
   Forked mode - allows Unbound to operate unthreaded and forks separate processes
   
   
4. Supports DNSSEC validation - Unbound was designed to perform DNSSEC validation, a mechanism to protect DNS data, from the ground up. DNSSEC validation is not implemented as a plug-in or bolt-on like some other DNS servers. It was designed integral to Unbound at its inception. This makes Unbound a higher performing solution than the others, because validation code was optimized in Unbound. Additional features for trust anchor management (RFC 5011) are in the works and that will only serve to enhance an already great product.
5. Adds software diversity - Enterprise customers and ISPs can now introduce a proven and reliable alternative to BIND for providing a validating, recursive, caching-only layer of DNS servers with Unbound. Unbound introduces software diversity to the masses. BIND DNS is at the center of what has been termed a "monoculture". Software diversity is good for the Internet, and it's good for the ISP and Enterprise too. Software and code diversity allow us to mix different DNS vendor solutions to provide the same or better service. A bug in one vendor's product will not likely be visible in the others.
6. Production-Ready - surfnet.nl announced back in September 2009 that all SURFnet DNS resolvers were DNSSEC capable. Their implementation of DNSSEC validation relied on the Unbound DNS server package. Other major carriers and ISPs ( I cannot name for obvious reasons ), are about to deploy Unbound probably for all the same reasons stated in this blog post. If major carriers are starting to put Unbound into service for their customers, it makes sense that it's ready for the enterprise as well.
7. Single-purpose - Because Unbound was coded to be a validating, recursive, and caching resolver, it doesn't suffer from split- or dual personalities that DNS server solutions do. Unbound is, for the most part, a single-purpose server. Since Unbound is not authoritative for data, the code and function becomes simplified. There is no code to support Dynamic DNS updates, or zone transfers, etc. Instead, this single purpose server is best-in-class at what it was coded to support: recursion, validation, and caching resolution.
8. Security - Unbound has not skimped on DNS Security at the expense of simplicity and performance. On the contrary. Unbound is feature-rich with DNS Security with its harden-glue, access control, max randomness for query ID and ports, response scrubbing, case preservation, and Denial of Service or DoS protection features. These are just some of the features that make Unbound one of the most secure DNS server implementations.
9. Manageability - Unbound has an extended management command line interface or CLI that provides remote management capabilities, as well as, an extensive set of network monitoring statistics. Unbound-control uses a secure connection from the client to the server running Unbound using Secure Sockets Layer or SSL. Commands are sent from the client and responses from the server are displayed as output. An additional CLI called, unbound-control-setup, is provided to assist in the OpenSSL shared keys and configuration directives for getting unbound-control operational. The statistics output can be used to "feed" known capacity planning tools such as Munin, or Cacti for graphing many of the different baseline and extended statistics that Unbound tracks.
10. Portable solution - Unbound has been ported to run on a wide range of hardware OS platforms, including Linux, BSD, Solaris SPARC and X86, MacOS/X, and Windows. Windows 32-bit pre-compiled binary packages are available directly from NLnet Labs, or you can download the source package and compile it yourself.

https://info.menandmice.com/blog/bid/37244/10-Reasons-to-use-Unbound-DNS

 

[rgnldo]

not a recursive resolver with this config. It’s no better than dnsmasq in this case

As we are debating, let's go:
I organized a virtual machine with Debian and installed Pi-hole. It is an adblock solution with dnsmasq. But the Pi-hole development team allows for the inclusion of Unbound. And look, Pi-hole has a very advanced dnsmasq API, FTLDNS. In my tests, I didn't make any big gains there.
https://docs.pi-hole.net/guides/unbound/

 

[dave14305]

https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/

Forward Zone Options
There may be multiple forward-zone: clauses. Each with a name: and zero
or more hostnames or IP addresses. For the forward zone this list of
nameservers is used to forward the queries to. The servers listed as
forward-host: and forward-addr: have to handle further recursion for
the query. Thus, those servers are not authority servers, but are
(just like unbound is) recursive servers too; unbound does not perform
recursion itself for the forward zone, it lets the remote server do it.
Class IN is assumed. CNAMEs are chased by unbound itself, asking the
remote server for every name in the indirection chain, to protect the
local cache from illegal indirect referenced items. A forward-zone
entry with name "." and a forward-addr target will forward all queries
to that other server (unless it can answer from the cache).

 

[rgnldo]

https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/

That's right. Forwad zone are query redirection. Try configuring DNSSEC without configuring a Forward Zone that supports DNSSEC validation.

 

[rgnldo]

The Forward-Zone option aims to bypass ISP upstream servers, which do not always have DNSSEC support. If you manually configure DNS in the WAN section with DNSSEC support, you do not need to configure Forward-Zone. Just this.