Unbound DNS Resolver on Turris

Software SW tweaks
, , ,
#1

Why?

  • We experienced small but repeated issues with the pre-installed Knot DNS resolver.
  • Adding custom configurations can be daunting, if you are not familiar Knot configuration syntax.
  • I use the Unbound resolver in various other projects since many years, so I am more familiar with it then Knot.
  • I run secondary (unbound) resolvers in my networks and like their setup to be as similar as possible
  • I like to use DNSSEC in local private domains and in domains where the upstream doesn’t provide it.
  • I like to hold a copy of the root-zone in my resolvers for better speed and privacy.
  • Unbound is already nicely integrated in TurrisOS (as is Knot).
  • Unbound is already nicely integrated in the AdBlock package (as is Knot).

How?

opkg update
opkg install unbound unbound-anchor unbound-control-setup

Open /etc/config/resolver with your preferred editor and change the following line:

From: option prefered_resolver 'kresd'
To: option prefered_resolver 'unbound'

Save the file and restart the TurrisOS resolver service:

/etc/init.d/resolver restart

Note: Don’t enable the unbound service, don’t start, stop or restart the unbound service. Always use /etc/init.d/resolver for that, or you might loose the excellent TurrisOS integration.

Customizing

Most common and important options are set in the config resolver 'unbound' section of /etc/config/resolver

If that is not enough for you, you find the section config resolver 'unbound_includes' at the bottom of the file.

config resolver 'unbound_includes'
    list include_path '/etc/unbound/unbound.conf.d/*.conf'

Drop your custom config files in that directory.

Alternative Upstream Resolvers

Unbound, as configured by the resolver-package on TurrisOS, will use the upstream DNS provider you choose in reForis → Network Settings → DNS.

Root-Zone

/etc/unbound/unbound.conf.d/root-zone.conf

# =========================================================
# Auth Zone for the Internet root zone "."
# See RFC 8806 - Running a Root Server Local to a Resolver
# https://www.rfc-editor.org/rfc/rfc8806.html
# =========================================================
auth-zone:
    name: "."
    master: "b.root-servers.net"
    master: "c.root-servers.net"
    master: "d.root-servers.net"
    master: "f.root-servers.net"
    master: "g.root-servers.net"
    master: "k.root-servers.net"
    url: https://www.internic.net/domain/root.zone
    fallback-enabled: yes
    for-downstream: no
    for-upstream: yes
    zonefile: "/var/etc/unbound/root.zone"

References:

1 Like
#2

Thanks!

Immediately configured it as you described. Getting two errors on start, but it seems to work:

root@turris:~# /etc/init.d/resolver restart
Called /etc/init.d/unbound stop
set dhcp script
Check generated config /var/etc/unbound/unbound.conf:
Error relocating /usr/sbin/unbound-checkconf: if_is_dnscrypt: symbol not found
Error relocating /usr/sbin/unbound-checkconf: if_is_pp2: symbol not found
Called /etc/init.d/unbound start
set dhcp script
Called /etc/resolver/dhcp_host_domain_ng.py

But the real issue is this one:

root@turris:~# unbound-control dump_cache
Segmentation fault

I’m used to dumping and loading my cache when playing around with the settings as it is flushed on every restart. Any Idea how to fix this?

EDIT:

Seems to be generally broken as other commands fail as well:

root@turris:~# unbound-control stats
Segmentation fault

root@turris:~# unbound-control status
Segmentation fault
#3

Just out of curiosity, what do you mean by this? (if it gets longer, I suppose I could split it into a separate topic or something)

And of course, if you haven’t reported those repeated issues with “Knot Resolver”, I’d be interested in at least a quick summary. Oh yeah, it’s common not to use the correct name for the project, but I’m used to it… it’s probably not very intuitive.

1 Like
#4

The local root zone part also does not seem to work:

root@turris:~# less /var/etc/unbound/root.zone
less: can't open '/var/etc/unbound/root.zone': No such file or directory
#5

Just upgraded to Turris OS 6.0.2 and that fixed all my above mentioned issues.

#6

This deserves a small reply, at least from me.

It is true that Unbound can be used, and it is integrated with Turris OS, but that’s not going to be forever. We need to go to history. Why is that?

From the beginning of the Turris routers, we have been using Unbound as the default DNS resolver for blue Turris 1.x routers, but with newer routers, such as Turris Omnia, Turris MOX, we are using Knot Resolver by default. This results that we are maintaining and testing two DNS resolvers (unbound only on Turris 1.x routers), which is time-consuming, and we are in the process of using only Knot Resolver whenever possible.

So, I think it is good to remind that using any different DNS resolvers is out of the scope of our support, and we are not testing Unbound on Turris Omnia routers. It might break anytime once we remove the Unbound integration.

  • We experienced small but repeated issues with the pre-installed Knot DNS resolver.

Were they discussed or reported somewhere to be able to look at those mentioned issues?

#7

Yes, Knot is feature-incomplete on Turris devices. See Resolve local hostnames with custom DNS - #5 by vcunat

#8

We got NXDOMAIN replies where there shouldn’t be any at least three or four times a day,
This happens in users browsers and can be seen in the routers log, especially during update checks.
While there can be a number of reasons why this can happen, it doesn’t happen with unbound.
Clicking the Try Again button in the browser usually solves the issue. So it is a minor issue and hard to analyze or debug for end users or router admins. I also vaguely remember seeing reports by other users, maybe while there where reporting other issues, but its definitely something you see from time to time in the logs.

I also want to emphasize, that this was not meant to be rant against or for any particular resolver.
I am aware that both of them emerged because of the many issues with a popular “industry standard” solution which I will leave “unamed” here. I know they work closely together along with other projects and have come a long way to improve one of the most critical parts of the Internet to the much better quality we have today.

Okay, I was surprised to see both of them so well integrated, now I understand why.

The motivation for this post was mostly, because it is currently very well integrated but not well documented.

It would be longer, but I don’t think it warrants a post here, it goes way beyond the scope of a “home-router”… But in short, we have authoritative DNS servers and each network of my Omnias has its own domain or subdomain. We heavily rely on DNSSEC for SSHFP, TLSA, etc. We therefore use unbound also on the client side along with DNSSEC-Trigger.
Some of our upstream domain providers and some of our ISPs (for rdns) don’t have DNSSEC. For those I use trust-anchors in Unbound. This is also possible with Knot resolver (i.e. kresd) and I did it once in one network. But its just harder for me, then with Unbound. I use unbound on OpenWrt since Attitude Adjustment and on Ubuntu since Trusty. Okay that was not so short.