DietPi-Software | Unbound: Fixes and enhancements

[Gill-Bates]

Hi There,
I would appreachiate the cloudflare deamon in dietpi. Right now, I have to set it up manually:

https://docs.pi-hole.net/guides/dns-over-https/

Could you incorporate the cloudflare deamon into the software catalouge of Dietpi?

[MichaIng]

@wtfmaster
Thanks for your request.

There is another tool that does that thing, if I get it right: https://dnscrypt.info/

• Related request: https://github.com/Fourdee/DietPi/issues/1245

Maybe someone can explain what those tools do, what I get is:

• They will accept incoming DNS requests.
• They will proxy them to an external DNS provider, but verify it's identity by checking SSL certificates.
• So you need to configure your system (and/or Pi-hole, if in use) to send DNS requests to the tool (loopback IP + configured port).
• I guess you cannot simply use any DNS provider you want then, but it needs to support this. Since usually HTTPS certificates are only made/valid for domains, e.g. plain Google DNS IP will not work? Although cloudflared suggests plain CloudFlare DNS server IP 🤔.

In cloudflared you can configure the upstream DNS: https://docs.pi-hole.net/guides/dns-over-https/
DNSCrypt allows that as well, although the guide suggests dnscrypt.nl-ns0: https://itchy.nl/raspberry-pi-3-with-openvpn-pihole-dnscrypt

Further reading: https://community.cloudflare.com/t/dnscrypt-great-proxy-alternative-to-cloudflared/14650

---

So generally I am opened to implement both of them. It doesn't seem too much work, and from system side, only the DNS server needs to be changed, really no big deal.
Although we have DNSCrypt in combination with Pi-hole, I think it is worth to add independently. On Pi-hole install simply check for running DNS proxies (cloudflared/DNSCrypt) and set Pi-hole to use them. Actually, I believe if the system (resolv.conf) is already configured to use it, Pi-hole will automatically use the same upstream DNS on install?

[MindTooth]

I've used DNSCrypt-Proxy for several years. And the latest rewrite includes caching, meaning no need for DNSMasq any longer. Would love to see it include by default, and maybe a supplied interface to do changes.

[MichaIng]

Just to mention, there are several ideas/ways to mask your DNS requests:

• DNS-over-HTTPS (DoH), currently forced by browser developers
• DNS-over-TLS (DoT), which has less overhead but does not allow to use the same connection for multiple requests (DNS and others) natively (?)
• DNSCrypt: Another separate protocol for encrypted DNS, that was believed to be not continued anymore but gained new development meanwhile.
• Running your own local DNS server, e.g. via unbound.

A list of public free DNS providers and which supports which encryption protocol is available here: https://en.wikipedia.org/wiki/Public_recursive_name_server

It would be wonderful if we could implement all of them, however a client is always required since since Linux/Debian itself does not support this natively. DNSCrypt-proxy is known of course, cloudflared AFAIK uses DoH, for DoT I'm not sure currently.

[MichaIng]

Unbound supports upstream DoT and downstream DoT and DoH, so covers most reasonable cases. AFAIK there is not really an upstream DoH "resolver", meaning a node that can be connected to via any method to resolve hostnames and itself resolves them via DoH at public upstream DoH DNS provider like 9.9.9.9. DoH is mostly something that is done by the individual clients, e.g. the web browser itself, but it does not make much sense to use it for upstream resolving from unbound since all its benefits don't apply (mix DNS requests with existing HTTPS connections and traffic) and only the overhead (HTTP) stays.

So the only missing DNS feature, after unbound implementation, is DNSCrypt-Proxy, either as an alternative to unbound, or even in combination with unbound where DNSCrypt is used to encrypt upstream DNS requests and unbound mostly for DNS caching.

[Ernstian]

I recently switched to the dev branch and tried Unbound, but if I install it, I get an error while it tries to restart the service

[  OK  ] DietPi-Software | Setting in /etc/pihole/setupVars.conf adjusted: PIHOLE_DNS_1=127.0.0.1#5353
[  OK  ] DietPi-Software | Setting in /etc/pihole/setupVars.conf adjusted: PIHOLE_DNS_2=
[FAILED] DietPi-Software | systemctl restart unbound
[  OK  ] DietPi-Software | systemctl restart unbound

Retrying the command installs it just fine. This happened on 3/3 installations.

After installation, Unbound doesn't work. I'm running Pi-Hole, and while my local IP and port is written under custom DNS servers, if I disable all other DNS servers, nothing resolves. Unbound is running, the log has no errors, and Unbound is running in htop.

-- Logs begin at Thu 2019-02-14 10:11:58 GMT, end at Fri 2020-12-04 23:58:55 GMT. --
Dec 04 23:56:45 DietPi systemd[1]: Starting Unbound DNS server...
Dec 04 23:56:51 DietPi package-helper[431]: /var/lib/unbound/root.key has content
Dec 04 23:56:51 DietPi package-helper[431]: fail: the anchor is NOT ok and could not be fixed
Dec 04 23:57:06 DietPi unbound[470]: [1607126226] unbound[470:0] info: start of service (unbound 1.9.0).
Dec 04 23:57:06 DietPi systemd[1]: Started Unbound DNS server.

If I keep the IPv6-DNS active (as it is default after installing Unbound), I'll get the following result (commands taken from here, I just changed the port to 5353 ). It should not result in a SERVFAIL.

root@DietPi:~# dig pi-hole.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> pi-hole.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35995
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; Query time: 30 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sat Dec 05 01:10:39 CET 2020
;; MSG SIZE  rcvd: 40

root@DietPi:~# dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7850
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; Query time: 36 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sat Dec 05 01:11:50 CET 2020
;; MSG SIZE  rcvd: 57

root@DietPi:~# dig sigok.verteiltesysteme.net @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52011
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;sigok.verteiltesysteme.net.    IN      A

;; Query time: 29 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sat Dec 05 01:11:56 CET 2020
;; MSG SIZE  rcvd: 55

Minor nitpick here: the custom DNS is not removed from Pi-Hole if Unbound is uninstalled.

Other things I'm running: Pi-Hole, OwnCloud, fail2ban

[ravenclaw900]

Strange, since everything works for me (even automatically removing the Unbound DNS from Pi-hole on uninstall). Reading a Reddit post, it seems that some ISPs/Routers can intercept DNS requests, even when they're not supposed to, stopping Unbound from opening a secure connection. What happens if you remove Unbound from Pi-hole and run dig @127.0.0.1 pi-hole.net +norecurse?

[Ernstian]

Well, I'm using the Easybox 804 too. I guess that's the problem, then - at least it's not a problem with the implementation!

[MichaIng]

I'll also run another test, just to be sure.

[faxesystem]

I also ran into the problem when installing unbound and pihole on a fresh dietpi.

[ OK ] DietPi-Software | Setting in /etc/pihole/setupVars.conf adjusted: PIHOLE_DNS_1=127.0.0.1#5353
[ OK ] DietPi-Software | Setting in /etc/pihole/setupVars.conf adjusted: PIHOLE_DNS_2=
[FAILED] DietPi-Software | systemctl restart unbound
[ OK ] DietPi-Software | systemctl restart unbound

But for me retrying the command did not fix it and I had to cancel the installation.

[MichaIng]

Strange, I faced it as well now, however a retry fixed it here as well. Here the reason:

Dec 20 22:05:49 VM-Buster unbound[17816]: [1608498349] unbound[17816:0] error: can't bind socket: Address already in use for ::1 port 53
Dec 20 22:05:49 VM-Buster unbound[17816]: [1608498349] unbound[17816:0] fatal error: could not open ports

The override config is created before the restart is done: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-software#L8795-L8806

However, ss -tulp shows that actually dietpi-pihole.conf does not really override port and listening IP but adds it... More strangely after it worked once, unbound binds to 0.0.0.0:5353 and 127.0.0.1:5353, hence the port is overridden but the IP added 🤔.

I also tried to add it like:

server:
    port: 5353
    interface: 127.0.0.1

(the server: block definition) but that does not have any effect.

Bad that v6.34 has just been released. It seems like overriding settings does not work as expected, hence we need to change port and listening IP in our main config when installing Pi-hole.

[MichaIng]

@faxesystem
That means you can change port and interface settings in /etc/unbound/unbound.conf.d/dietpi.conf to 5353 and 127.0.0.1 as above and redo the install. The settings file will be preserved and unbound start should then succeed directly.

[faxesystem]

Will try this tonight. So this is something that will have to be fixed in a future DietPi release?

[MichaIng]

Yes, at least a beautiful long-term solution, as it requires likely some research and tests. But I'm sure we can hack an ugly but reliable solution meanwhile via MOTD script 😉.

[faxesystem]

Hmmmm does not work for me. I choose the open a sub shell when the error occurred and changed port and interface in dietpi.conf from 0.0.0.0 and 53 to 127.0.0.1 and 5353. After that I re-ran the command which still resulted in the same error.

systemctl status unbound.service
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2020-12-21 20:48:09 CET; 24s ago
     Docs: man:unbound(8)
  Process: 19566 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
  Process: 19569 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
  Process: 19573 ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS (code=exited, status=1/FAILURE)
 Main PID: 19573 (code=exited, status=1/FAILURE)

Dec 21 20:48:09 thesquirrelmaster systemd[1]: Stopped Unbound DNS server.
Dec 21 20:48:09 thesquirrelmaster systemd[1]: unbound.service: Start request repeated too quickly.
Dec 21 20:48:09 thesquirrelmaster systemd[1]: unbound.service: Failed with result 'exit-code'.
Dec 21 20:48:09 thesquirrelmaster systemd[1]: Failed to start Unbound DNS server.
Dec 21 20:48:09 thesquirrelmaster systemd[1]: unbound.service: Start request repeated too quickly.
Dec 21 20:48:09 thesquirrelmaster systemd[1]: unbound.service: Failed with result 'exit-code'.
Dec 21 20:48:09 thesquirrelmaster systemd[1]: Failed to start Unbound DNS server.
Dec 21 20:48:13 thesquirrelmaster systemd[1]: unbound.service: Start request repeated too quickly.
Dec 21 20:48:13 thesquirrelmaster systemd[1]: unbound.service: Failed with result 'exit-code'.
Dec 21 20:48:13 thesquirrelmaster systemd[1]: Failed to start Unbound DNS server.

[MichaIng]

Yes I recognised this as well, not sure if forgotten or intended @ravenclaw900? However, it is not required to connect via IPv6 in order to resolve hostnames to IPv6 addresses, AFAIK. And since every local network will have IPv4 addresses (at least additionally to IPv6), it should work fine. Otherwise, consequently we'd need to derive the local IPv6 network range as well for access-control.

[Joulinar]

I recall an old post from PiHole GitHub that it was not possible to have both IPv4 as well as IPv6 on custom entries. pi-hole/web#1499 (comment)

[Joulinar]

guys, I know a total n00b question. But which upstream DNS is used on unbound?

[ravenclaw900]

It uses the DNS root servers in https://www.internic.net/domain/named.root.

[Joulinar]

inside PiHole, I see queries answered by Cloudflare.

[ravenclaw900]

Strange, the queries should just be resolved by localhost#5353. It sounds like Cloudflare is selected instead of Unbound.

[Joulinar]

that's why I'm asking. Custom DNS is set to 127.0.0.1#5353 as expected but still queries are resolved by Cloudflare. Even after a reboot. 🤔

ok I got it working now. It changed the moment I hit save button again on PiHole > Settings > DNS. Some more testing would be needed to see if I can replicate the behaviour.

[ravenclaw900]

Mine had 1 request answered by Cloudflare, before the configuration changed it.

[MichaIng]

Btw, we apply Unbound as (only) DNS via /etc/pihole/setupVars.conf, but while this is important for Pi-hole repairs/reinstalls and updates, it does not affect the currently used DNS. For that we'd need to edit /etc/dnsmasq.d/01-pihole.conf and adjust the two server entries (https://github.com/pi-hole/pi-hole/blob/master/advanced/01-pihole.conf#L32-L33), respectively remove both and add an own server=127.0.0.1#5353.

[ravenclaw900]

We'd probably need to do the same when uninstalling Unbound and replacing it with Quad9, then. Possibly the reason for the 'minor nitpick' in #2409 (comment).

[Joulinar]

good find @MichaIng
That would explain why on an existing installation still old DNS sever are using instead of unbound

[MichaIng]

Issues are addressed with this PR: #4022
Additionally I made the default configuration a dedicated download: a23d799
To be more compatible, all local IPv4 ranges are allowed to access since the previous 192.168.* only estimation does not apply in all cases and it is generally hard to reliably obtain the actual local target subnet which does not always match the one from the www interface, e.g. with a dedicated local network or even a VPN which shall have access.

One question: identity: "Server"
Shall we give it a little more meaningful name, like "DietPi Unbound server" or has it a privacy reason to be unspecific? I have no idea where this would show up...

[ravenclaw900]

To be honest, I'm not even sure if it's needed. Right before it is hide-identity: yes, which refuses all the queries (id.server and hostname.bind) that would ask for the server identity anyway.

[MichaIng]

Okay, I think it's fine to keep both to assure max privacy. Probably we can sort and explain (via comments) the config file a bid to make it clearer why we set what.

[Joulinar]

Guys, there is a user on our forum looking into config file creating as well.
Next to this he is looking for some logging functionality and a graph that might be provided by unbound

https://dietpi.com/phpbb/viewtopic.php?f=9&t=8469