The fact that we provide an unbound guide does not make unbound and system level problems within the scope of Pi-hole support.
2 Likes
After what I thought was a breakthrough by disabling unbound-resolvconf.service and a long period of about 4 - 5 hours of no resets, it turns out I was wrong. Both unbound instances running on both of my piholes are stopping and starting at the same exact same time.
I checked out the content of cat /etc/resolv.conf which appears to have added the IPV6 address of my second pihole to this file. Is that normal?
# Generated by resolvconf
search home.arpa
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver <static ipv6 that I set in setupVars>::30
nameserver <the ipv6 address of my second pihole instance>
I set a static IP for the main pihole, but not the second one. Do you think that the second one is getting it's prefix changed and this causing this whole chain of events?
I've been following this thread with interest. I am still convinced that pihole has something to do with it. Why?
- Disabling IPv6 support on PiHole stops the problem
- My other RPi which is running raspbian and unbound (but not pihole) does not exhibit this problem.
Just my 2 cents.
Plain Debian (jessie to sid) uses openresolv: Debian -- Details of package resolvconf in sid
Does Raspbian/DietPi really use something else? If so, do you know where the source code is?
Maybe this one?
https://salsa.debian.org/debian/resolvconf/-/blob/master/bin/resolvconf
Time to restart auditing to check what it was.
Well, yes. Some (whatever) component received an RA with the IP of your second Pi advertising it as nameserver. It may have been dhcpcd which ran resolveconf itself (so this has nothing to do with you stopping the service at all).
Yes. My speculation: Second Pi-hole got a new address and this is getting advertised on the network. dhcpcd on the first Pi-hole receives this, and decides it has to update resolv.conf to pick up the "new" DNS server. For this, it does not modify the file itself but calls resolvconf. Which also does the unbound kicking.
Question: Did you configure something for this to happen?
Sorry for maybe asking the same question twice: do you use Pi-hole's DHCP server on the second one?
Do they both have resolvconf installed? If so, do the config files differ?
1 Like
No, I don't use the DHCP server on the second one. The only real difference between the two is that one is running raspbian server and the other one is the desktop version.
I shut down the second pi and removed it from the DNS servers that get handed out to clients. I will report back if that changes anything.
edit Also I forgot to mention. I tried setting a static IP for the second pihole as a troubleshooting step to see if that would stop the prefix from changing and thus prevent this whole situation. I set the static IP in pfsense and also in setupVars.conf, but no where else and it didn't seem to respect that change when running ifconfig after a reboot
I am not sure how I got the static IP to stick on the first pihole. Maybe I just let the old IP expire?
They both have standard Raspbian installed and I have not played with those config files.
I probably wouldn't recommend to disable any services, even if we'd fully understood the whole chain of events.
That service may well do a lot more useful things than the one that's causing the annoying unbound reloads. In addition, that seems to be the unbound.in subscriber for openresolv resolvconf, not resolvconf itself.
In my Armbian installation, I could only find a /etc/resolvconf/update.d/unbound file that does contain neither HUP nor kill.
As said, there may be legitimate reasons for acting on an IPv6 RA.
Also note that IPv6 RA likely does not trigger resolvconf directly. Another component in your system's network stack may consume the RA and trigger resolvconf in return.
It would be good if we'd at least know what RA is causing your observations.
That's an Advanced DHCP setting in Pi-hole.
Your configuration differs in that regard from jmccamb's:
So that option has no ties to the observation under discussion here.
Do resolvconf, unbound and dhcpcd configurations show any differences for those installations?
Unbound is no longer installed on the original RPi (because of the frequent restarts) so I only have one configuration of that (on the RPi 0W - works as intended). I am very limited in my Linux knowledge so I don't really know where to find configuration files for resolvconf or dhcpcd, sorry.
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
resolvconfpackage is an own package with own source, see the "Source: resolvconf" link at the top of the page. - The dedicated
openresolvpackage has a "Provides: resolvconf" entry in its control file, which means that packages which depend onresolvconf(have a "Depends: resolvconf" entry on their control file) are satisfied as well whenopenresolvis 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 
.
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 
: 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
Hey! thank you for your response. It is going to take a minute to parse everything in here, but for now here is the content of the file you request:
forward-zone:
name: "home.arpa"
forward-addr: <static ipv6>
forward-zone:
name: "."
forward-addr: 1.1.1.1
forward-addr: 1.0.0.1
forward-addr: <static ipv6>
Installed resolvconf and in the log it shows:
(Reading database ... 41459 files and directories currently installed.)
Removing openresolv (3.8.0-1) ...
Selecting previously unselected package resolvconf.
(Reading database ... 41445 files and directories currently installed.)
^ based on this can I safely assume that openresolv is uninstalled?
I've listed it earlier in this topic, but here it is again:
cat /var/cache/unbound/resolvconf_resolvers.conf
# Generated by resolvconf
forward-zone:
name: "localdomain"
forward-addr: the IP v6 address of my pihole - masked for privacy
forward-zone:
name: "."
forward-addr: the IP v6 address of my pihole - masked for privacy
I assume the forward-zone: name: "." is the result of my unbound config has an entry for auth-zone: name: "." (read here).
Not sure I understand this. Both my IPv6 and IPv4 addresses haven't changed for a few weeks. I know this because I have a cron script running that checks this every 30 minutes.
The IP only changes when my ISP either kicks my modem (forced config change - we're not allowed access to the modem) or kicks their own IPv6 infra (sometimes, but not always announced on their status page).
anyway, since I'm adding another post, I might just as well let you now I've commented out the line
#unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf
in /etc/resolvconf.conf, done yesterday evening 22h43, no unbound stop messages since than. This is no confirmation this will definitely work, will need to monitor this for at least 3 or 4 days.
Why did I decided to do this? My system also has knot-resolver installed. I use kresd as a resolver for some lists I build overnight and publish on GitHub. I don't want the dnsmasq and unbound cache to hold these entries, hence using another local recursive resolver for this purpose only. Nothing to do with pihole, but I noticed /etc/resolvconf.conf doesn't contain an entry for knot-resolver (kresd), and looking at the logs, kresd never restarts. I would expect kresd to respond to IP changes in the same way unbound does.
edit
just checked, my own audit method (script as suggested by DL6ER) is still running. ther was an entry:
Mon 31 May 00:30:15 CEST 2021,6007,/bin/sh /usr/sbin/resolvconf -a eth0.ra
which previously matched the exact same time of an unbound stop message. Not this time though, no unbound stop. This makes me hope, but again, monitoring this for a few days will confirm...
/edit
What file did you comment that out in?
Many thanks. The forward-addr entries match the systems /etc/resolv.conf entries, right? The two IPv4 addresses are the public Cloudflare DNS at least. That seems to be indeed the intended addition that openresolv does on top of what regular resolvconf does. The package descriptions says
...and configures local resolvers such as dnsmasq and unbound.
So the idea is that upstream DNS servers used by the local systems libc resolver (the one that uses /etc/resolv.conf) are wanted as upstream DNS servers for locally running DNS servers as well, which is IMO usually a wrong assumption. When running a local DNS server on a network port, then it is usually not for the server system itself, but for other clients on the LAN, while the server system itself at best uses a regular public upstream DNS, so that it's services can stop without it breaking it's own network capabilities. More problematic is that all this is enabled by default: openresolv/resolvconf.in at b51e465c3d289da7bee9843ddc2eb5404e72b954 · NetworkConfiguration/openresolv · GitHub
If I get the code correct, it is possible to add unbound=off to /etc/resolvconf.conf to disable it, but that is not even documented.
@jpgpi250 that file is not based on any actual Unbound configs, but created by openresolv only based on the info it has/get, the local systems upstream DNS servers is seems. It is true in you case that /etc/resolv.conf as well contains this Pi-hole's IPv6 address?
Okay, if no IP (including the IPv6 prefix) did change, then the resolvconf script/command was called for a different reason. Probably dhcpcd or the respective network stack does this for other reasons as well. But in general: I do not see an issue when tools call resolvconf to update DNS info for whatever reason, as that is what it is for, but the problem is that it restarts Unbound by default on every such call.
When you comment unbound_conf in /etc/resolvconf.conf, the default is applied, hence then /etc/unbound-resolvconf.conf should be created instead and the restarts still triggered. Please try adding unbound=off (derived from the code in the script), if/when you see another Unbound restart.
EDIT: Ah, while the man page says that unbound_conf defaults to /etc/unbound-resolvconf.conf, I do not see where this default value is assigned. So probably it's only the value in the default upstream config file. So when you comment that setting, or set it empty (unbound_conf=), then the following should make the script exit before the restart is done: openresolv/unbound.in at b51e465c3d289da7bee9843ddc2eb5404e72b954 · NetworkConfiguration/openresolv · GitHub
1 Like
If you're asking me , the file is /etc/resolvconf.conf
Tip: hit the reply button from the message you want to reply to, not the general reply button. The user your are replying to will get a notification if you reply to a specific message.
1 Like
for me, both false
/etc/resolv.conf contains whatever you specified in /etc/dhcpcd.conf
My /etc/dhcpcd.conf contains:
static domain_name_servers=127.0.0.1 ::1
My /etc/resolv.conf contains
# Generated by resolvconf
domain localdomain
nameserver 127.0.0.1
nameserver ::1
I've checked this, whenever making changes to /etc/dhcpcd.conf, resolvconf pickes up the changes (reboot) and changes /etc/resolv.conf accordingly
edit
Do you mean my method will be working? Still some days of monitoring ahead...
Implies of course you need to add code (already in my script that checks IPv6 changes)
to update /var/cache/unbound/resolvconf_resolvers.conf and sudo pkill -SIGHUP unbound, this to inform unbound of the change, but only when the address has really changed.
/edit
2 Likes
I forgot to post the content of etc/resolv.conf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver <static ipv6>
search home.arpa
I should note this was after installing resolvconf
1 Like
Hmm, you're right, this DOMAINS variable is not made up from the regular /etc/resolv.conf entries directly: openresolv/resolvconf.in at b51e465c3d289da7bee9843ddc2eb5404e72b954 · NetworkConfiguration/openresolv · GitHub
-
nameserver,searchanddomainentries are first stored in other variables. - Then if none of the above is matches (probably the end of the file, the last empty line?) then the previously created variables are combined to create
DOMAINSin<domain/search>:<nameserver>, <domain2/search2>:<nameserver2>like format.
I'm a bit confused where the IPv6 address is then coming from. The output of resolvconf -l seems to be processed as well, probably it contains additional IPs, like IPv6 addresses for nameservers that are stored in IPv4 format or even as with loopback IP in dhcpcd.conf/resolv.conf only?
@jmccamb
So your case seems to verify my assumption fully. <static ipv6> in resolv.conf and /var/cache/unbound/resolvconf_resolvers.conf you posted above is the same as well?
1 Like
Yes that is correct
@MichaIng sorry I keep forgetting to tag people
Okay. While I did not yet fully understand all parts of how those entries are processed, I think the general idea of what openresolv tries to do, and that in your setup this is not wanted, is clear enough, as well the options to prevent openresolv from doing it, or using resolvconf that does not try it in the first place.
sorry I keep forgetting to tag people
No problem 
, the reply buttons directly below each message (instead of the blue one at the bottom of the whole thread) works as well to trigger a notification.
1 Like