In Raspberry Pi OS (Bullseye clean install), the offending package that installs the unwanted unbound configuration file (openresolv) can easily be removed with the package manager. When you restart unbound, the unwanted configuration files are no longer re-installed.
Why do you recommend installing resolvconf? Is this package needed?
In my testing with Raspbian Bullseye, the Pi runs fine without either openresolv or resolvconf installed.
I only recommend it as replacement for openresolv, not in general, hence the condition dpkg-query -s 'openresolv' in the suggested command. That way the resolvconf command stays available, hence the core functionality it provides to manage /etc/resolv.conf dynamically. Indeed, usually it is not required at all, especially when a static IP and nameserver is set and wanted.
Note: Those packages have conflicts defined on each other, hence installing one removes the other one automatically.
Tested everything we discussed. There is one annoing issue, the configuration file is already created during first boot.
content (IPv6 masked):
# Generated by resolvconf
forward-zone:
name: "localdomain"
forward-addr: 192.168.2.57
forward-addr: xxxx:yyyy:zzzz:6902:e7ba:9aaa:fe18:c808
forward-zone:
name: "."
forward-addr: 192.168.2.57
forward-addr: xxxx:yyyy:zzzz:6902:e7ba:9aaa:fe18:c808
Something will need to be added to the documentation to ensure this file is removed, prior to unbound installation. The solution Michalng provided prevents the file to be recreated, but since it is already there...
Ah that makes sense. So additionally the file needs to be manually removed once, after the package replacement or removal. Btw, configuration files are left by the package replacement that way, it may be cleaner to purge it (which can be also done individually afterwards). Does this probably remove that generated configuration as well?
apt purge openresolv
fresh SD card, immediatly run after startup:
dpkg-query -s 'openresolv' &> /dev/null && sudo apt-get purge -y openresolv && sudo apt-get -y install resolvconf
the file (/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf) still remains on the system
Okay, so then indeed it needs to be removed manually.
Lets continue here.
Yeah most users wont even notice this setting effecting how unbound resolves either as a dump dumb caching forwarder or as a recursive resolver.
But I prefer to comment/hash out the unwanted config instead of removing and installing packages because you never know if the system depends on openresolv in some other way.
Something like:
sudo sed -i 's\^unbound_conf=\#unbound_conf=\g' /etc/resolvconf.conf
sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
sudo service unbound restart
When looking at Debian packages:
$ apt rdepends openresolv
openresolv
Reverse Depends:
|Recommends: dhcpcd5
|Recommends: dhcpcd5
|Suggests: wireguard-tools
No hard dependency exists, so removing/purging the package won't trigger any other removal, as long as no 3rd party repository ships packages which strictly depend on it. For the resolvconf package reverse dependencies (including on packages with "provide" resolvconf, which openresolv does, as alternative) this looks different: On Bullseye there are two packages with a strict dependency on the "provided" resolvconf (so the command, but no specific implementation). The "Recommends" or "Suggests" basically mean that the resolvconf command is used when available, else either /etc/resolv.conf is altered directly or not at all.
But since commenting the setting solves all related issues we are currently aware of, DNS loops and frequent Unbound restarts, it is sufficient indeed and safest for a general recommendation in the docs.
@devs & @mods, shall I add a section?
Make sure the
openresolvpackage doesnt configureunboundto function as a simple caching DNS forwarder instead of a recursive DNS resolver.
This mostly applies to newer distro's like Debian/Raspbian Bullseye.
Errors like "file not found" can be ignored:
sudo sed -i 's\^unbound_conf=\#unbound_conf=\g' /etc/resolvconf.conf
sudo rm -f /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
The unbound daemon gets restarted later in the guide.
Not now. I'm working on an update to the unbound docs, and I'm considering the options for the new Bullseye problem. There are multiple solutions, and I don't think we should determine which the user should use. I'm looking at how to provide them options without confusion.
Fantastic thread, thanks to all who have contributed. Learned so much reading through this. Will be looking forward to the official Pi-hole documentation updates.
Just to let you know, since your updating the documentation...
In my comments, regarding the test (purge openresolv), suggested by @MichaIng, I forgot to mention that purging openresolv, see here, removes /etc/resolvconf.conf (the file that contains the "instructions" for openresolv to act upon). You might want to add this to the documentation change.
To be clear, it doesn't remove /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf, the file that makes unbound "misbehave", that will always require a manual intervention.
That makes sense, /etc/resolvconf.conf is a configuration file for openresolv only, not used by anything else. And purging removes all packages configuration files.
This is an amazing thread... it has completely resolved my issues... pun intended!
Thanks to you all.
This is an official request to please have this issue either documented in the docs better, or implement one of the above mentioned software "fixes".
I just spent about 3 days trying to solve this, and the documentation wasn't helpful. See thread here. Especially when coming from the point of view of a system that's been in "production" for over a year, that I only update/upgrade once in a while. (ie. It's already configured correctly, why would that change?) Just trying to keep up to date enough to keep from being hacked, or otherwise. But then a known bug ( Nov'21 to Jan'23, almost a year and a half later) borks the system when I do?!? And the only documentation is this thread? If the docs aren't going to be updated, and a software fix isn't deemed acceptable, then please at least pin this thread to the top until such time that the next LTS version has shown to not have this issue.
Pull requests are welcomed.
Pull requests are welcomed.
Does not the section proposed a year ago by @deHakkelaar already cover this? If that were a section, it would have helped me.
The alterations that have been made to the guide are a bit wrong or explained slightly wrong in my opinion.
Recent Debian-based OS releases auto-install a package called openresolv ...
1)) Above bit in the guide is wrong as openresolv was already installed before the Bullseye release:
pi@ph5a:~ $ lsb_release -d
Description: Raspbian GNU/Linux 10 (buster)
pi@ph5a:~ $ apt policy openresolv
openresolv:
Installed: 3.8.0-1
But it didnt affect your setup bc the path for the unbound configuration file was different and thus not affecting unbound:
pi@ph5a:~ $ cat /etc/resolvconf.conf
[..]
unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf
pi@ph5a:~ $ cat /var/cache/unbound/resolvconf_resolvers.conf
# Generated by resolvconf
forward-zone:
name: "home.dehakkelaar.nl"
forward-addr: 10.0.0.1
forward-zone:
name: "."
forward-addr: 10.0.0.1
forward-addr: 2a02:a459:XXXX
pi@ph5a:~ $ sudo unbound-control lookup .
The following name servers are used for lookup of .
;rrset 9639 13 1 8 0
. 9639 IN NS a.root-servers.net.
. 9639 IN NS b.root-servers.net.
. 9639 IN NS c.root-servers.net.
. 9639 IN NS d.root-servers.net.
. 9639 IN NS e.root-servers.net.
. 9639 IN NS f.root-servers.net.
. 9639 IN NS g.root-servers.net.
. 9639 IN NS h.root-servers.net.
. 9639 IN NS i.root-servers.net.
. 9639 IN NS j.root-servers.net.
. 9639 IN NS k.root-servers.net.
. 9639 IN NS l.root-servers.net.
. 9639 IN NS m.root-servers.net.
[..]
Compared to the path on Bullseye:
pi@ph5b:~ $ lsb_release -d
Description: Raspbian GNU/Linux 11 (bullseye)
pi@ph5b:~ $ cat /etc/resolvconf.conf
[..]
#unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
So the only thing that has changed from Buster to Bullseye is the path for the unbound configuration file thats being created by openresolv.
Openresolv's service/config instructs resolvconf to write unbound's own DNS service at nameserver 127.0.0.1 , but without the 5335 port, into the file /etc/resolv.conf.
openresolv has a systemd service called unbound-resolvconf.service.
2)) Its not above openresolv package thats changing the nameserver in the resolv.conf file on its own.
Its the unbound-resolvconf.service systemd unit that comes with the unbound package which instructs resolvconf to alter the resolv.conf file with that nameserver 127.0.0.1 line:
pi@ph5b:~ $ dpkg -S unbound-resolvconf.service
unbound: /lib/systemd/system/unbound-resolvconf.service
If you are sure you don't need the features of openresolv, then removal of the package is the simplest option.
3)) I disagree with above where removing openresolv is the first option.
How can someone be sure they dont need resolvconf?
Most likely if you install a VPN client on the Pi-hole host, it will reinstall the openresolv or resolvconf package to alter local DNS servers to those supplied by the VPN server.
I can imagine other software wanting to do something similar using resolvconf.
4)) For if someone is going to alter the guide, below command in the guide:
sudo systemctl status unbound-resolvconf.service
can be replaced with
systemctl is-active unbound-resolvconf.service
And below two:
sudo systemctl disable unbound-resolvconf.service
sudo systemctl stop unbound-resolvconf.service
can be compounded to:
sudo systemctl disable --now unbound-resolvconf.service