Unbound frequent restarts

General
97

Quick solution (instead of disabling IPv6 or removing Unbound): apt install resolvconf (and confirm removing openresolv instead)

You misinterprete what the "Packages providing" on Debian package pages means:

  • The resolvconf package is an own package with own source, see the "Source: resolvconf" link at the top of the page.
  • The dedicated openresolv package has a "Provides: resolvconf" entry in its control file, which means that packages which depend on resolvconf (have a "Depends: resolvconf" entry on their control file) are satisfied as well when openresolv is installed instead.
  • The packages listed at the Debian pages as "Packages providing" are hence additional/alternative packages that can be installed to satisfy the same dependency.

So there are dedicated sources, and they are identical on Debian, Raspbian, hence DietPi and Ubuntu. I'll have a look.

EDIT: Salsa is Debian's Gitlab instance, so those sources are probably correct, but not necessarily. Often I see packages released which do not match any of the branches there. Theoretically the "Vcs-*" entry on the control file should tell, but that isn't always correct either. But the package web page has original source and Debian patches+controls linked as tarballs.

EDIT2: I checked the resolvconf sources linked at the Buster suite package page, which match exactly the debian/1.79 branch on Salsa.
And grep -r 'unbound' has as only results the README where it is mentioned to support resolvconf, and a changelog entry about this README entry, so it's a behaviour dedicated to openresolv :slightly_smiling_face:.

So apt install resolvconf should hence solve the issue, while I cannot say something about other impacts. Basically both implementations do the same, but openresolv tries to do some more magic, not only with Unbound but with e.g. dnsmasq as well, as it has a dedicated file to handle it. From the filelist:

/lib/resolvconf/dnsmasq
/lib/resolvconf/libc
/lib/resolvconf/named
/lib/resolvconf/pdnsd
/lib/resolvconf/unbound

The openresolv Unbound script loops through the $DOMAINS variable, assigned here, which seems to consist of domain names and name servers, adds the name servers as forward-zone: entries to the Unbound config and then restarts it to apply the change. Not sure where those name servers are coming from (need to check the script that creates the variable), but to me it looks wrong on first view, that the system resolver does any change to Unbound, especially when it's about upstream DNS servers that Unbound shall use (that's what the forward-zone block is about, right?), as we want to have it using the DNS root servers based on the root hints, usually, nothing else.

EDIT3: Okay, it's not the Unbound config that is edited, but a dedicated file, defined by the unbound_conf setting in /etc/resolvconf.conf, which defaults to /etc/unbound-resolvconf.conf but is set in the Debian package by default as /var/cache/unbound/resolvconf_resolvers.conf: https://manpages.debian.org/buster/openresolv/resolvconf.conf.5.en.html#SUBSCRIBER_OPTIONS
The question is how Unbound uses this (it's in Unbound config syntax), probably that's what the unbound-resolvconf.service is for?

EDIT4: Nope, unbound-resolvconf.service only adds itself as system nameserver/upstream via resolvconf, if Unbound is bound to any loopback IP. This explains why the additional 127.0.0.1 entries were found in /etc/resolv.conf and why stopping this service does not resolve the restart issue. The question remains how /var/cache/unbound/resolvconf_resolvers.conf is used by Unbound, how it even know about that config (as this path is defined in openresolv's /etc/resolvconf.conf, not in any Unbound config).

EDIT5: Okay now it gets funny :grinning_face_with_smiling_eyes:: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913602
Until Debian Buster, /var/cache/unbound/resolvconf_resolvers.conf is used as default unbound_conf by openresolv, where it has zero effect. The bug report above lead to a fix, present with Debian Bullseye (never backported/applied to Buster), changing that path to /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf, which is the native path where Unbound reads configs from. I.e. with newer Ubuntu versions (Focal onwards) and Debian/Raspbian Bullseye (currently testing), this whole openresolv Unbound script becomes effective the first time, while currently these restarts are triggered for no reason. Whether it is wanted that the system resolver messes with the Unbound upstream DNS entries is a very different question and it is good to keep in mind that these settings additions are done. Probably someone else better knows the effect of this?

I'm still not 100% sure if the added addresses are simply the systems upstream DNS entries (which could cause a loop) or something else. @jmccamb @jpgpi250 @doncarajo (sorry I can only mention two users in one post) can you please paste the output of:

cat /var/cache/unbound/resolvconf_resolvers.conf

so we can get an idea (or assure assumptions) of what openresolv is trying to do.

But regardless of what openresolv is trying to do, DL6ER's speculation above looks absolutely correct. In addition, how I guess IPv6 is involved: With IPv6 enabled, the public prefix changes by times, which is then passed to the Pi-hole's (via RAs), hence the IP change that kicks the ball. With IPv6 disabled, the local IPv4 addresses wouldn't change (as long as static IPs or reserved IPs are assigned), hence no resolvconf calls on such regular basis. But instead of disabling IPv6, I'd purge openresolv or replace it with resolvconf (the package) to avoid those restarts which currently have no reason anyway.

2 Likes