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"
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
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.
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?
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.