DietPi-Software | Unbound: Fixes and enhancements

[MichaIng]

Status: Ready

ToDo:

• Merge dietpi-pihole.conf and dietpi.conf on DietPi update
• Changelog

Testing:

• Merge dietpi-pihole.conf and dietpi.conf on DietPi update
• Reinstall with removed dietpi.conf
• Fresh standalone install
• Use of standalone install from other network client
• Install Pi-hole afterwards
• Fresh install together with Pi-hole
• Fresh install after Pi-hole

Commit list/description:

• DietPi-Software | Unbound: Pre-configure Unbound before installing it to avoid port binding conflicts right from the start
• DietPi-Software | Unbound: Install it before installing Pi-hole so that it can be used as upstream DNS directly
• DietPi-Software | Unbound: Use port 5335 by default when configuring it for Pi-hole since port 5353 is used for mDNS (Multicast DNS) by default
• DietPi-Software | Unbound: Whenever changing the Unbound port, assure that there is another upstream DNS server configured in /etc/resolv.conf
• DietPi-Software | Unbound: Do not overwrite an existing configuration file. Config overrides do not in cases where the setting is allowed multiple times, hence in case of interface (IP bindings) private and allowed IP ranges, users might need to configure our base config, which must be preserved.
• DietPi-Software | Pi-hole: When changing the upstream DNS, apply it directly via dnsmasq config and restart FTL to immediately use it.
• DietPi-Software | Spotify Connect Web: Enhance uninstall
• DietPi-Software | Unbound: Sort and comment default config file

[MichaIng]

@ravenclaw900
I updated the default log file, basically sorting it and adding comments: 44d2429

• I removed so-reuseport as this seems to be relevant only when using multiple threads, while we use only 1 by default.
• And I set edns-buffer-size to match the new upstream version defaults which matches DNS Flag Day 2020 (October) recommendations.
• Based on v6.34, I changed things to allow all IP ranges that are officially reserved for local networks, to practically prevent all www access by permit e.g. VPN or other secondary network access without intense hostname/IP command output parsing and guessing.

[Joulinar]

@MichaIng
can you have a look to following https://dietpi.com/phpbb/viewtopic.php?f=9&t=8534

I could replicate same behaviour on my test systems.

Jan 17 23:24:17 DietPi3 systemd[1]: Starting Unbound DNS server...
Jan 17 23:24:17 DietPi3 package-helper[350]: /var/lib/unbound/root.key has content
Jan 17 23:24:17 DietPi3 package-helper[350]: fail: the anchor is NOT ok and could not be fixed
Jan 17 23:24:18 DietPi3 systemd[1]: Started Unbound DNS server.
Jan 17 23:24:18 DietPi3 unbound[364]: [364:0] info: start of service (unbound 1.9.0).

looks like unbound is starting to early. Maybe we need to delay service start.
After=network.target dietpi-boot.service

---

one more thing in addition. On my test installation, I installed PiHole + Unbound together. However Unbound was not set as upstream DNS server and on PiHole UI, still the default was set, while customer DNS was empty. I used dev branche.

[Joulinar]

@MichaIng
Not sure if you already checked it but I guess we would need to delay unbound service start

[MichaIng]

Ah, that is true when doing IP binding, network adapters need to be configured. But with dietpi-boot.service this implies an issue: Network time sync is done as part of that service, which often requires DNS, so it would not work if the system itself uses Unbound for its DNS. I want to make the time sync an independent service anyway, respectively was thinking to hack an ExecStartPost into systemd-timesynd to gracefully quit itself, once initial time sync done. With this it could stay activated and would launch and sync asynchronously at boot. But until then, network-online.target is the best we can do.

[MichaIng]

Done: adee418

About the Unbound + Pi-hole install: If the Pi-hole installer runs, you can enter the Unbound IP there. Do you think in this case it should be automatically added after the Pi-hole installed finished as well? I'm just thinking that it might be an issue if users set upstream DNS within the installer and they end up with a different upstream than what they have just chosen. So currently only when Pi-hole was installed already, the upstream DNS is changed.

[Joulinar]

well let me turn around this question. Why do you install unbound if you like to run another upstream DNS on PiHole? Should we probably ask the user at the end of the installation process if he like to set unbound as upstream DNS inside PiHole?

[MichaIng]

I mean you're right, we skipped any interactive whiptails on the assumption that it is very unlikely that anyone would install Pi-hole + Unbound without having Pi-hole using Unbound. It just feels strange that one is asked during Pi-hole install to set the upstream DNS, one might invest some lookup and thoughts on this, and afterwards it is simply overwritten 😄. Maybe an info prompt before the Pi-hole installer runs through would be an idea, to inform that the upstream DNS part can be skipped (hit return to proceed with default) since dietpi-software takes care of this afterwards. Sadly currently there are no ways pre-answer this question for Pi-hole, AFAIK 🤔.

[Joulinar]

probably an idea to offer to PiHole guys, to allow pre-configuration using a config file 😉
But this is another story

[MichaIng]

It was tried, but refused: pi-hole/pi-hole#3589
Once they finished the migration to PH7-based integrated PHP handler + webserver, so that Pi-hole is a single binary only with a much simplified installer, we can bring up the topic again.