WARNING: Raspbian October 2021 release bullseye + unbound

remember this one?

been busy the entire day to find out bullseye (fresh install) reconfigures unbound

the solution is the same, comment out the unbound entry in /etc/resolvconf.conf, however, if resolvconf managed to run with the entry active, it creates a file /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf. You need to delete that file and restart unbound to resume normal behaviour.

The file created on my system contained only IPv6 info (IP address masked):

# Generated by resolvconf

forward-zone:
	name: "localdomain"
	forward-addr: xxxx:yyyy:zzzz:6902:e7ba:9aaa:fe18:c808

forward-zone:
	name: "."
	forward-addr: xxxx:yyyy:zzzz:6902:e7ba:9aaa:fe18:c808

This is the IPv6 address of my pi

The result is that all queries received by unbound are forwarded to pihole-FTL, most of the queries (all IPv6 queries) in the query log appeared to be comming from pi.hole (normally, that count is close to zero).

It also increases the number of status 14 (Already forwarded, not forwarding again) dramatically.

my scripts deleted the file (/var/cache/unbound/resolvconf_resolvers.conf), used in buster (had zero impact), but the file has been relocated in bullseye, with the very unpleasant result (unbound forwarding to pihole-FTL).

moderators / developers: you might want to add this test to pihole -d, check for the existance of the file, users might (will?) be impacted...

DL6ER: is there a way to get this warning (and others) in the tools / pihole diagnosis (message table) using bash?

2 Likes

Is this not adequately addressed in our unbound guide?

https://docs.pi-hole.net/guides/dns/unbound/#disable-resolvconf-for-unbound-optional

My scripts (buster) do ensure this cannot happen, however, resolvconf managed to create the file prior to the actions to eliminate the impact. The file may have been created before you take that action (disable the entry or disable resolvconf altogether).

the manual reffers unbound-resolvconf.service, the compiled version of unbound doesn't have this service, the damage is done by resolvconf (/usr/sbin/resolvconf).

If the file exists, the damage is there to stay (until it is deleted). This is what happened with bullseye.

1 Like

Whilst it is addressed, for someone who is not completely clued up with unbound and pihole I read the "Optional" bit as being something for more advanced users would use but as a noob don't mess with optional code.

Not sure what you want exactly. The message table can easily be queried through bash by using the sqlite3 CLI and /etc/pihole/pihole-FTL.db.

Or do you suggest a new feature that is push a warning to the message table when status 14 queries get too numerous (say, > 10% of all queries). This barrier would barely have been exceeded in your screenshots above.

This is the structure of a message:

What I want to know is what to put in the differenf fields, so the message will appear in the web interface the way you intended. e.g. something like:

assume (example) these entries in the log:

[2021-11-14 09:00:01.865 875/T881] SQLite3 message: database is locked in "SELECT name FROM network_addresses WHERE name IS NOT NULL AND ip = ?;" (5)
[2021-11-14 09:00:01.865 875/T881] getNameFromIP("xxxx:yyyy:zzzz:6903:e9c9:580a:faff:143a") - SQL error prepare: database is locked
sudo sqlite3 "/etc/pihole/pihole-FTL.db" ".timeout = 50000" \
"insert or ignore into 'message' \
( timestamp, type, message, blob1, blob2, blob3, blob4, blob5 ) \
values ( \"${timestamp}\", ....);

what are the intended values of:

  • type (?)
  • message (?)
  • blob1 (?)
  • blob2 (?)
  • blob3 (?)
  • blob4 (?)
  • blob5 (?)

additionally, there is no UNIQUE field, which makes it hard not to flood the message table.

Depends on the type

Probably even more obvious if you look at how the web interface interprets the values:


Yes, because the various fields may have different interpretations and the same message can be meaningful multiple time (e.g. the same error in multiple regex).

FTL ensure itself that no duplicates exist for types where this is meaningful (like rate limiting or hostname error messages)

I also struggled with latest RPIOS and unbound. Following helped me to get it work.

  • disable and stop unbound-resolvconf.service
  • commenting resolv_conf=/etc/resolv.conf and unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf in /etc/resolvconf.conf
  • deleting /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
  • reboot

Afterwards /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf wasn't created automatically anymore and everything worked as expected.

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 :sweat_smile:. 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 :grinning_face_with_smiling_eyes:.

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 :wink:. 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.