ci: Unbound: add build script #7632
Conversation
32f7414 to
df9851c
Compare
ba82fbc to
e784d55
Compare
Why did you do that? Do you use it with Pi-hole or AdGuard Home?
While this should not cause issues, it is not needed, since the Unbound-embedded root hints are recent enough. The last time root servers actually changed was over 2 years ago, before that 6 years ago. Even the Debian package does not set
Why do you define a forward zone? This effectively disables Unbounds recursive and validating DNS resolving, also rendering Did you change settings in If the issue persists, please raise |
|
Nearly all of Unbound users will use serve-expired with some level of caching, since it's used as a recursive DNS server - that's the unique selling point of unbound. |
Yes, it's for AdGuard Home.
It is for use in conjunction with
I tested this on a clean VM before migrating my current configuration, and with the default settings and adding the I'm guessing it's thanks to |
Sure, we also enabled it OOTB, as well as But this has nothing to do with external caching, or whether a persistent cache makes sense or not. We are talking about minutes here, and these features are more meant to be fallbacks in case of failing upstream queries, and Unbound recently hardened defaults to try harder with upstream queries, instead of using expired cache entries overly long. The selling point of Unbound, if you have Pi-hole or AGH with their own DNS caches, is IMO not so much the cache, but the privacy aspect, either skipping 3rd party DNS providers, or alternatively encrypting queries to lock out LAN and ISP from the content. If you use Unbound only, then the cache of course is valuable. But an external potentially persistent caching backend, IMO not so much, based on what we discussed so far.
Okay, so first of all good to know that you did not install Unbound with So you installed
But whether adding
Btw, to everyone here: We were always talking about Unbound having DoH support in newer versions. However, I could actually only find downstream DoH, also downstream DoQ and even downstream DNScrypt (protocol, not to confuse with |
|
serve-expired-reply-ttl is the ttl to which a cached response is served back to the client - it's not the lifetime of the entry in the cache. |
|
True, but it first tries to resolve upstream:
But you are right, I misinterpreted it earlier. So with
In older Unbound versions, I guess for our default configuration, we could set |
|
My current Unbound config uses the following and it's been flawless for me in terms of performance and security for the last 3+ years: cache-min-ttl: 3600 |
|
As a default, I would probably not have a minimum cache TTL of 1 hour, and not reset the cache entry TTL in case of every failed upstream query ( But regarding the original topic of persistent Redis cache: with |
I've not noticed invalid IP's or otherwise - when I previously had my expired TTL's set to 0 (i.e the previous unbound default of "infinite") I did see it occasionally (and/or certificate errors for websites). This all went away when using the config above and have found it to be a good balance between performance and security/privacy. |
|
I guess Regarding |
I'm not directly installing via
I keep getting
So would this guide be conceptually incorrect or not necessary for today's times?
But what if Unbound doesn't offer DoH, wouldn't this implementation with
The goal would be privacy with performance, as you mention, making packets harder to detect, both by IPS and upstream DNS, hence the preference for DoH. |
|
Okay got it.
So Unbound fails to connect to (or get a proper response from) the So previously you used cat << '_EOF_' | sudo tee /etc/unbound/unbound.conf.d/dnscrypt-proxy.conf
server:
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 127.0.0.1@5353
forward-addr: ::1@5353
_EOF_
sudo systemctl restart unboundWhile the option to connect via IPv6 doesn't hurt, it should work via IPv4 as well, of course, and does so with I'll try this locally as well later tonight.
Not directly "incorrect", but adds one component that IMO does not serve any purpose.
Yes, but why using Unbound at all then? If you want to use DoH or oDoH, use Unbound adds another cache. The guide hence disables the cache in |
|
I found the problem: These settings aren't in Adding this new set of lines that indicates, returns Would it be a problem to include
Since AGH has the DNS cache option, would enabling it there bypass the system's use of the cache similar to what Unbound would do? Thank you very much for the answers. |
|
Great, I missed that indeed, respectively did not think of it being relevant in this case, falsely interpreted it as "do not try to resolve 'localhost' upstream". Makes sense, so this setting is enabled by default, most likely to prevent DNS loops, and hence needs to be disabled to allow Unbound using another local resolver as upstream: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-do-not-query-localhost Looks like something we should add to our docs, though the question remains about the purpose of Unbound in such case. |
|
So just checking this build is ok to install or are further changes/fixes/etc. required? What happens with my existing installation of Unbound that was made via DietPi Software? |
|
Unbound as an application will be overwritten and updated to a newer version. The configuration should remain intact. It is better to make a backup beforehand. |
|
Installed. Everything seems to be good! |
|
Yes, config file setup has been aligned with Debian's package, so all modified config files remain untouched (new ones will be stored next to them with So it is a drop-in replacement as much as possible. |
|
Worked a treat! Unbound-control still works - presumably this was because it was there previously? |
|
To see package content: dpkg -L unbound |
|
Is unbound-anchor not needed for DNSSEC validation and then the updating of the root trust file thereafter? Along with the corresponding line in the config to point to the root.key file? https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound-anchor.html |
No it is not. This tool allows to basically copy the DNSSEC keys from somewhere else to the path where Unbound is reading them, assuring correct permissions, and probably doing some validation. However, Debian provides the keys via dns-root-data package where no validation is needed, and copying them from one place to another is not exactly a task we need a dedicated tool for. Debian thought the same, and hence split that tool into its own package, instead of keeping it as part of the The setting with the path is in |
|
Got it. Thanks. By default, Unbound stores the root.hints and root.key files into /usr/share/dns/ but all the config files that DietPi provides point to /var/lib/unbound/ Presumably the files are copied from usr/share/dns to /var/lib/unbound whenever Unbound (or the files?) are updated to ensure that recent and current files are used? |
Both settings have no default at all:
Not sure where you got
This config file is part of the Debian package, so we chose to keep it that way, staying compatible with the Debian package also regarding config files. We would have stored that setting with the same value in the |
|
So there's a script that copies them to /var/lib...etc. from /usr/share/dns? |
Yes, as said, Debian does this as part of the service start. Check the |
|
Presumably the file copy is here - carried out in the build.bash script for Unbound (correct me if I'm also wrong that this only copies the file if it doesn't already exist - it doesn't overwrite it with a newer version if applicable): ** if [ ! -f '/var/lib/$NAME/root.key' ] So given that it copies the files from /usr/share/dns/ which is created by dns-root-data, how, for example, do you ensure the root.key file/s are kept up-to-date - since the latest installed version of dns-root-data is from 2024 (and therefore the files that reside therein are from that time as well??) - without unbound-anchor installed (which runs automated checks to update the root.key files)? Or does Unbound keep the files updated regardless? Also regarding root.hints - even the unbound devs (and documentation) recommend using a root.hints file and not relying on the built-in hints. |
These keys are only needed a single time as anchor. From that point on, Unbound updates them by itself, which is why the file needs to be writable. You can compare its contents on original and Unbound paths, where you see that it validates them regularly, and updates them in case. So updating it with a "new version" is not needed, it could even make the keys older. And since Unbound writes the files regularly, the mtime is moreless always newer anyway. The only reason why copying on service start could make sense, is if you do not run unbound for some years, so that the keys are too old to serve as anchor for new ones. For now, I think this scenario is not so relevant. But I guess a
Where do they recommend it? It makes sense for Debian, since they their Unbound version is frozen within a Debian release. We however update it on every Unbound release, which makes it unnecessary. Note that DNS root server IPs change only every several years. The last change was an addition some years ago. So even if that was missed, there wouldn't have been any outdated entry in the embedded data. Read the first post, where I discussed all decisions 😉. EDIT: Funnily, Debian does not set |
In the docs - by recommend I mean good/best practice:
|
Test builds: https://github.com/MichaIng/DietPi/actions/runs/16510133216
Our package has a few differences compared to the Debian package:
pythonkeyword inmodule-config:setting, and defining apython-script:to be called along the processing chain. If anyone is actually making use of this, we can compile it in, but calling Python scripts along DNS query processing sounds like a very inefficient and slowing-down procedure, so I would be very interested of the use case then. Not compiling it in gets rid of Python dependency of our package.chrootcould also be enabled OOTB, like done upstream, and it should be additionally possible to run the service itself asunbounduser, instead of relying on Unbound dropping privileges, adding port 53 permissions via privileges instead.resolvconfhandling done by the Debian package, which IMO causes more issues than it solves.unbound-resolvconf.service, which we do not ship as of above.dns-root-datapackage in place, which we skip, letting Unbound prime it from builtin data instead, if missing on first start. Unbound keeps these updated automatically, so it is relevant only on very first start. The only situation it could break is if the system stays offline for a very long time, so that both contained keys become invalid, making it impossible for Unbound to use them as basis for key updates. However, this really happens only every several years, and probably Unbound is then able (after upgrading the package) to replace the outdated keys with builtin ones, like if the file was missing. In any case simply removing the anchor file and upgrading the Unbound package (for up-to-date builtin keys) would solve it.chrootif configured, which is not enabled by default with the Debian package. If it is wanted, we would set it up via systemd unitBindPathsinstead./etc/init.d/unboundare appended to theunbound.list(static files) of the new package, and hence preserved until probably/hopefully only next package upgrade. I do not know the reason behind it. However, this means that additional processing is done when enabling/disabling the service after the upgrade, including two additionalsystemd system-reloadsteps etc, and the old service depends on the helper script, which is not available anymore. Hence our package manually removes that init.d service viapostinstscript.It ships without Debian'sEDIT: Added as of user request./etc/unbound/unbound.conf.d/remote-control.conf, hence remote control needs to be enabled manually if needed, i.e. ifunbound-controlis used. Though, since it does not use a TCP port, but a UNIX socket, it is probably worth it to keep that one?/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conffor DNSSEC is included, of course.I am happy to add sandboxing via systemd unit and/or
chrootby default, the way the upstream systemd unit does, and hence thankful for everyone who can help testing those directives.To test
Not necessarily needed, but at best update to DietPi v9.15. Then:
There are some other changes, unrelated to the own builds:
dns-root-datapackage, which ships and keeps them updated. However, root servers change only every several years, last update was one server ~3 years ago, And Unbound itself keeps them updated in their embedded list as well. For simplicity, since we aim to distribute our own package with ~instant updates on upstream release, and to align with upstream and Debian package defaults as well, we drop the external root hints usage entirely and rely on Unbound builtin data, getting also rid of one potential attack vector./etc/unbound/unbound.conf.d/dietpi.conf, potentially newly added settings (some just in case they were manually removed previously) are assured to be added within theserver:block.unbound-resolvconf.serviceis now not disabled after package installation, but (in case disabled and) masked before the package installation, so it really never starts when installed via DietPi. Our own package won't ship it at all, it is a Debian-only maintainer implementation, not upstream, hence the mask is relevant for the Debian package, and in case someone decides to downgrade from our package to the original Debian package for some reason. In any case, we aim to be compatible with both for now.