I was following this guide unbound - Pi-hole documentation to verify that Unbound is working correctly. I installed it a while ago. I got to the spot about debian installing openresolv by default, and the nessessary steps required to prevent it from overwriting resolv.conf.
Actual Behaviour:
However on my raspberry pi 3 - Debian 12 bookworm system, openresolv is not installed, and resolvconf.conf does not exist. I do have /etc/resolvconf/update.d/unbound and ../dnsmasq though.
These are the contents of /etc/resolvconf/update.d/unbound:
Summary
#!/bin/sh -e
#
# This hook is the part of resolvconf+unbound integration which makes
# unbound to use the upstream nameservers provided by the local network
# instead of doing full recursive resolving starting with the root
# name servers.
#
# Since unbound performs DNSSEC validation by default, such integration
# can be problematic if the upstream nameservers do not perform DNSSEC
# validation correctly. This also can be an issue if a "forward-zone"
# declaration for the root zone has been configured by the administrator
# in unbound.conf.
#
# This hook was disabled by default for several releases because of the
# above reasons, by giving out the executable bits of this file, but it
# is now enabled for new installs.
#
# You can enable or disable this hook by controlling the executable bits
# of this script:
# chmod +x /etc/resolvconf/update.d/unbound
# to enable it, or
# chmod -x /etc/resolvconf/update.d/unbound
# to disable.
#
# An alternative way to disable this hook (provided the script is executable)
# it is to specify
# USE_RESOLVCONF_FORWARDS=false
# in /etc/default/unbound.
#
# There is also dnssec-trigger package which can help detecting upstream
# nameservers with broken DNSSEC validation. When using dnssec-trigger,
# this unbound resolvconf hook can probably be disabled too.
#
PATH=/usr/sbin:/usr/bin:/sbin:/bin
command -v unbound-control >/dev/null || exit 0
[ -x /lib/resolvconf/list-records ] || exit 0
if [ -f /etc/default/unbound ]; then
USE_RESOLVCONF_FORWARDS=
. /etc/default/unbound
case "$USE_RESOLVCONF_FORWARDS" in
( no | false | 0 ) exit 0 ;;
esac
fi
resolvconfs=$(/lib/resolvconf/list-records)
fwds=$(sed -rne 's/^[[:space:]]*nameserver[[:space:]]+//p' $resolvconfs /dev/null |
egrep -v '^(127\.|::1)')
unbound-control -q forward ${fwds:-off}
Questions
Do I need to create resolvconf.conf and add a line with '#unbound_conf=/ '?
Is openresolv actually auto-installed on Debian 12 bookworm?
It sounds from this that I do not need to worry about openresolv automatically installing on my system. My question remains -- is openresolv usually auto-installed in bookworm, and I removed it in the past? Or was it not auto-installed on my system, and the Docs might be updated to say something like "you might have openresolv, but if you don't, skip this section"?
Am not sure.
My minbase lite Bookworm Debian doesnt install either and resolv.conf is populated directly by NetworkManager instead of via resolvconf or its more contemporary replacement openresolv.
It depends on how NM is configured if resolvconf will be involved/invoked:
$ man NetworkManager.conf
[..]
dns
Set the DNS processing mode.
If the key is unspecified, default is used, unless
/etc/resolv.conf is a symlink to
/run/systemd/resolve/stub-resolv.conf,
/run/systemd/resolve/resolv.conf,
/lib/systemd/resolv.conf or /usr/lib/systemd/resolv.conf.
In that case, systemd-resolved is chosen automatically.
default: NetworkManager will update /etc/resolv.conf to
reflect the nameservers provided by currently active
connections. The rc-manager setting (below) controls how
this is done.
dnsmasq: NetworkManager will run dnsmasq as a local
caching nameserver, using "Conditional Forwarding" if you
are connected to a VPN, and then update resolv.conf to
point to the local nameserver. It is possible to pass
custom options to the dnsmasq instance by adding them to
files in the "/etc/NetworkManager/dnsmasq.d/" directory.
Note that when multiple upstream servers are available,
dnsmasq will initially contact them in parallel and then
use the fastest to respond, probing again other servers
after some time. This behavior can be modified passing
the 'all-servers' or 'strict-order' options to dnsmasq
(see the manual page for more details).
systemd-resolved: NetworkManager will push the DNS
configuration to systemd-resolved
none: NetworkManager will not modify resolv.conf. This
implies rc-manager unmanaged
Note that the plugins dnsmasq and systemd-resolved are
caching local nameservers. Hence, when NetworkManager
writes /run/NetworkManager/resolv.conf and
/etc/resolv.conf (according to rc-manager setting below),
the name server there will be localhost only.
NetworkManager also writes a file
/run/NetworkManager/no-stub-resolv.conf that contains the
original name servers pushed to the DNS plugin.
When using dnsmasq and systemd-resolved per-connection
added dns servers will always be queried using the device
the connection has been activated on.
$ man NetworkManager.conf
[..]
rc-manager
[..]
resolvconf: NetworkManager will run resolvconf to update
the DNS configuration.
So you dont need either of those two packages anymore.
But some "network manglers" that can be applied/installed for Debian can still depend on resolvconf.
They would do something like below (different older system):