in order to ensure unbound works for pi-hole users, the unbound line needs to be commented out. Due to the changed path in bullseye, the configuration file now has (an undesired) effect on unbound, in buster, the path was simply wrong, so the file had no effect, however, unbound was restarted (see here).
dnsmasq stores its configuration files in /etc/dnsmasq.d/, so once again, resolvconf changes a file that has no effect (commented it out to ensure resolvconf doesn't affect dnsmasq in any way)
to ensure raspbian doesn't do unwanted changes to my config, I have added a line to /lib/systemd/system/unbound.service:
ExecStartPre=/etc/unbound/resolvconf.sh
content of that script (partial):
file=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
if [ -f ${file} ]; then
echo "WARNING: resolvconf changed unbound config!" | \
socat - UDP4:"${remoteSyslogServer}":"${remoteSyslogServerPort}",connect-timeout=2
{ echo from: root
.....
} | sudo sendmail -d -t pi
fi
which is supposed to warn me if this happens again (does apt-get update resolvconf and change / restore the configuration file - lets hope not....)
Thanks, I read through the other topic again, and you sum it up pretty well. But really, before you basically disable all openresolv magic manually and do other changes, I clearly recommend to everyone who uses Pi-hole and Unbound on Debian or Raspbian to:
Maybe this is something the developpers can do automatically in the pi-hole installation script, regardless of unbound being installed or not. @DL6ER ????
edit
I suggest the documentation for unbound changes the section Disable resolvconf for unbound from optional to mandatory, this to ensure proper unbound operation for users that use the raspbian unbound package (see the comment of Dean_Harry_Smith, here
/edit
All I want resolvconf to do is pickup changes made in /etc/dhcpcd.conf (static domain_name_servers=127.0.0.1 ::1) and make changes accordingly in /etc/resolv.conf
That is what it does now (my modified configuration), after a reboot.
I very much like your proposed solution, this wasn't available (I didn't know this), when I added the test / warning to my system:
I will try this out as soon as I build a new system, making my test / warning obsolete.
If the developers / moderators consider your solution as the best one, they should mark it as "solution', however, I'm not sure this will solve the problem for users that use the raspbian unbound package (thus not compiled). The raspbian package aparently installs another service (unbound-resolvconf.service), which creates the same / similar problem.
All Debian/Raspbian unbound packages are the same and contain this service, it existed on Stretch and Buster as well, but it is not what causes your issues. All it does is adding itself as nameserver entry to /etc/resolv.conf, hence it creates a nameserver 127.0.0.1 entry, which you do anyway via dhcpcd currently. Here the related code:
unbound-checkconf $CHROOT_DIR/$UNBOUND_CONF -o interface | (
default=yes
while read interface; do
default=no
if [ "x$interface" = x0.0.0.0 -o "x$interface" = x127.0.0.1 ]; then
echo "nameserver 127.0.0.1"
elif [ "x$interface" = x::0 -o "x$interface" = x::1 ]; then
echo "nameserver ::1"
fi
done
if [ $default = yes ]; then
# unbound defaults to listening on localhost
echo "nameserver 127.0.0.1"
fi
) | /sbin/resolvconf -a lo.unbound
openresolv alone causes the issues.
This is your issue, so you are the one who should mark the solution that works best for you . The Pi-hole team/moderators will be careful to recommend/mark anything as a generally valid solution, as things may depend on the individual case, though in this case (Debian/Raspbian with Pi-hole + Unbound) I am pretty certain that replacing the package is a great and simple solution.
I checked back with the Pi-hole installer, and indeed neither is resolvconf installed as dependency anymore, nor configured in any way, so starting to do anything about this isn't the right thing. But it makes sense to add it has hint to the Pi-hole's Unbound documentation page. There is already a hint about the service you disabled: unbound - Pi-hole documentation
Generally this makes sense as the Pi-hole server usually does not need to use Pi-hole itself (if there is no desktop and web browser used on the same system), so it can stop/maintain Pi-hole without breaking its own DNS. But leaving it enabled does not break anything.
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.
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...
removed the config file (/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf)
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?
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
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.
Make sure the openresolv package doesnt configure unbound to 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
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.
. The Pi-hole team/moderators will be careful to recommend/mark anything as a generally valid solution, as things may depend on the individual case, though in this case (Debian/Raspbian with Pi-hole + Unbound) I am pretty certain that replacing the package is a great and simple solution.