Thanks, @jpgpi250 been fighting (by ignoring it and hoping it'll go away) this for a ~week since upgrading to RPiOS (bullseye) and couldn't quite rid myself of the forwarding zones that were blowing up my pihole2 device making it the top client across both Pi-hole instances.
Does this only happen on upgrades or do we need to amend the unbound install guide?
It's only an issue if openresolv is installed instead of classic/slim resolvconf, and it caused other issues already like restarting Unbound every time an RA with changed info is received. Basically it doesn't seem to work well at all with setups where a local resolver is meant to be used by the network instead of by the local host only.
So instead of working around all the issues that openresolv causes, what about replacing it with resolvconf when installed as part of the Pi-hole installer?
1 Like
I had the problem with a fresh install of raspbian lite october 30th
I haven't done anything to affect / change this, currently the system says:
- which openresolv -> nothing
- which resolvconf -> /usr/sbin/resolvconf
so unless something I have installed removes openresolv and than replaces it with resolvconf, I assume raspbian comes with resolvconf.
To clarify again the actions I took:
- fresh SD card with latest raspbian lite
- installed dnsmasq, compiled (need this for some other project - DL6ER knows - catch redirected DNS requests)
- installed unbound v 1.13.2 (compiled, so there is no unbound-resolvconf.service to remove)
- reboot to activate some other system changes (see optimizing unbound)
- installed pi-hole
- started debugging, until I found /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
- removed that unbound config file
- restarted unbound, normal behaviour restored
- checked /etc/resolvconf.conf and applied the fix (comment out the unbound entry)
- rebooted the system to ensure resolvconf didn't make anymore changes.
1 Like
It is meant to be a fully compatible replacement with additional features, hence ships the same command. Check it via:
dpkg -l | grep openresolv
That /etc/resolvconf.conf exists and has an effect is a prove of openresolv being installed, as resolvconf doesn't ship or use such a configuration file. openresolv does a lot of magic, basically it loops through all local resolvers it knows, including Unbound and (standalone) dnsmasq whenever via DHCP or RA any previously stored info changes (or even if it did not change, I can't find the related topic currently), and updates/creates a configuration for them with the provided DNS server address and then restarts their service. This can close a DNS loop:
Pi-hole => (as you configured) Unbound => (as configured by openresolv) Pi-hole
EDIT: Here the other issue: Unbound frequent restarts - #97 by MichaIng
Sorry for the messy post, I edited it a few times when understanding more and more how openresolv creates the problem with frequently restarted Unbound 
. And now I see that it was even you @jpgpi250 involved in this topic already. I hope you now understand why I recommended to purge openresolv all together 
.
1 Like
dpkg -l | grep openresolv
ii openresolv 3.12.0-1 all management framework for resolv.conf
there are 3 entries in resolvconf.conf (uncommented originally):
#dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
pdnsd_conf=/etc/pdnsd.conf
#unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
- 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....)
1 Like
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:
dpkg-query -s 'openresolv' &> /dev/null && apt -y install resolvconf
So replace it with standard resolvconf.
1 Like
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.
This will be reverted when you upgrade or reinstall the unbound package indeed. If you want to do a persistent change:
mkdir /etc/systemd/system/unbound.servce.d
echo -e '[Service]\nExecStartPre=/etc/unbound/resolvconf.sh' > /etc/systemd/system/unbound.servce.d/something.conf
systemctl daemon-reload
But what an effort if a simple package replacement solves all related issues effectively?
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.
1 Like
Tested everything we discussed. There is one annoing issue, the configuration file is already created during first boot.
- SD card formatter -> erase SD
- Win32DiskImager -> write raspbian image to SD
- add SSH file to boot to allow putty and winscp connection
- power on
- open winscp
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...
- removed the config file (/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf)
- applied the fix, provided by Michalng
- applied all updates (sudo apt-get update && sudo apt-get -y upgrade)
- installed dnsmasq (compiled)
- installed unbound (compiled)
- reboot -> file is NOT recreated.
1 Like
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
1 Like
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
1 Like
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.
1 Like
@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.