What would cause pihole-FTL to ignore PIHOLE_DNS_1 and resolve using resolv.conf instead?

Hi

I'm using a fairly standard setup with the exception I'm running a local unbound on port 5335.

After the last upgrade/pihole update I started having this issue where the PIHOLE_DNS_1 value is entirely ignored and pihole-FTL seems to be resolving using /etc/resolv.conf instead. Because it defaults to 127.0.0.1 (that seems to be some pi-hole changes) then pihole is basically asking itself for recursive lookups and all queries break with ex.:

Status: OK (cache) (not ready)
Reply: REFUSED (0.4ms)

To fix it I set the IP of another undound server (external) in /etc/resolv.conf then run pihole restartdns, and my pihole starts working again.

I can query the unbound server directly on 127.0.0.1#5335 and it responds, and the only stats I see on it are the manual queries.

Once resolv.conf is set up with another unbound server, I can set any ip/port in PIHOLE_DNS_1 (using the web interface) and pi-hole still keeps functioning happily as it's effectively ignoring it and querying the server in /etc/resolv.conf!

Other upstream DNS values are blank/unset.

Details about my system:

Pi-hole v5.6
FTL v5.11
Web v5.8
rPi 3B Rev 1.2 running Raspbian 10 (buster)
DHCP-provided static IPv4/IPv6 address
Forwarding of internal zones to the router's DNS server (updated from DHCP)

What I have changed since installing Pi-hole:

Set up unbound as per https://docs.pi-hole.net/guides/dns/unbound/ + forwarding zones
Upgraded OS and Pi-hole

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

Pi-hole does not write to resolv.conf ever since v5.0 (released in May 2020).
Did you consider other sources for that 127.0.0.1, e.g. a static network configuration?

Pi-hole would not read its host's resolv.conf at all.
The only way to change that would be to manually alter Pi-hole's dnsmasq configuration files.

Depending on your zone configuration, maybe unbound reads resolv.conf and uses it for your forwarding zones?

EDIT: Note that your pihole.log will show queries being forwarded to 127.0.0.1 since you are using unbound as upstream (and ports are absent from the log).

And we'd still need your debug token, please.

A post was split to a new topic: 2nd Pi-hole hits RATE_LIMIT

Hi,

Maybe some stale config files then, I've been running pi-hole since the 1.x series. The file is updated by resolvconf which do takes includes, so if I see anything pihole-related I'll remove them... But that is not really the issue, if pi-hole was querying the server it's supposed to (which runs on a non-standard port) there would be no issue.

Pi-hole dropped dnsmask a while back but I did see FTL is using dnsmask libs. Has is always been the case since the drop of dnsmask? Again, maybe related to stale config files from my former bastardized dnsmask setup back then...

Nope. I can query unbound and it responds fine. It acts as a resolver and forwarder for reverse lookups and local zones. It works. If I cannot find anything regarding the previous points, I'm gonna give it a trace and see if 1- it reads resolv.conf and 2- where it listens and connects to.

The point is, whatever IP I put in the web UI config, FTL resolves based on resolv.conf. I can put a bogus IP, the wrong port, it still works if resolv.conf points at a valid IP, and fails even with the router's resolver if resolv.conf points at 127.0.0.1.

I'm not uploading a debug log, but will hapilly investigate myself if needs be. I reached out to see if there were any any possiblity FTL does it on purpose and I think you raised some good points, thanks for that.

I did look at the debug log btw and it does mention the configured WebUI IP as a resolver, I didn't see anything wrong there at first glance.

Regards,

Thomas

That's your choice, but without it, I can't help you much further than I've already done.
(It's only a handful of trusted PI-hole members that can access a debug log, and it auto-deletes after 48 hours.)

EDIT:

(It's dnsmasq, not dnsmask - unless you are reffering to another software I am not aware of :wink: )

Pi-hole is using dnsmasq configuration files because pihole-FTL is dnsmasq, with Pi-hole's optimisations. The dnsmasq configuration files obey the exact syntax of dnsmasq.
Configuration of pihole-FTL specifics is done via /etc/pihole/pihole-FTL.conf.

Very unlikely.
Though that may have been the case initially, once you've edited resolv.conf, it wouldn't be Pi-hole that reapplies 127.0.0.1 to it.

But your issue has some similarities to a very recent topic where upgrading to Bullseye has produced a DNS loop for unbound.

May be that is what affects you as well?

Thanks, I'll look into this as well as soon as I can. I don't have that file but I do have a /etc/resolvconf/update.d/unbound script, but it would fail/return 1 due to a missing /lib/resolvconf/list-records script (which isn't even present anywhere, beside the apparent lack of a $PREFIX - unbound is installed in /usr).

Also unbound works, so I'm not sure it's the same issue (I haven't read the post yet though).

Thanks for the help, will let you know if I find anything.

Well, thanks for the help but in the end we'll probably never know - while doing some cleanups I auto-removed some packages required for the web UI, so I ran a pihole -r and after that it started querying from the correct server (I could see it right away in the query log).

resolv.conf still points at 127.0.0.1 after reboot; I'm not sure of the mechanism but I'm guessing it's done by unbound as it's normally the recursive nameserver. It's not an issue if pi-hole itself works as expected

@dermoth sir, I believe this was our issue: WARNING: bullseye + unbound

It ONLY happened for me on RaspiOS (arm) after upgrade to buster, but did not happen on pure Debian (x86). Or maybe it was something else entirely, but after a week this fixed my forward zone issues. Now completely removed, no extra FTL traffic from Pihole2.

@harrypnyce I'm not sure I get it... that might explain the localhost IP in resolv.conf? But that was not the issue, my pi-hole works happily using itself as a resolver for local lookups.

I could query unbound directly and it worked fine, resolved everything itself except for local domains forwarded to the router's dnsmasq on a nonstandard port (this allow forward/reverse lookup of local hosts and IP's).

It's pihole-FTL that was using the resolv.conf IP for resolving, despite the fact the configuration and the debug log clearly stated the upstream DNS was the unbound IP/Port. As a proof, once working by fixing resolv.conf and restarting pihole-FTL, I could enter any bogus IP/Port for the upstream DNS server and the pi-hole would keep working unexpectedly! The query log stated the answers still came from the IP in resolv.conf.

Of course that wasn't practical as unbound responds to a non-standard port and I haven't even checked if it's possible to specify one in resolv.conf, and even then there's no guarantee it will be picked up by whatever broken mechanism was doing it...

I didn't keep the debug log nor any config backups, so it would be very hard to investigate further. I suspect some bad interaction between the dnsmasq library (used by pihole-FTL) and some stale config from the pi-hole v1.x days.

The bottom line is: pihole -r (repair) fixed it and that would be the first thing to try if someone gets similar behavior, specifically pihole-FTL resolving based on resolv.conf IP's rather than configures upstream DNS servers. It has nothing to do with using a local resolver.

Pi-hole isn't using any dnsmasq library, but provides its own binary instead.

I've already pointed out:

We never were able to verify since you chose to not provide a debug log.

Of course, any manually or third-party alterations to Pi-hole's dnsmasq configuration files would have been reverted after running pihole -r.
But let me repeat that Pi-hole does not configure itself to read resolv.conf at all.

So if your configuration would have been altered, the source of that change would not have been Pi-hole.

It's a lengthy thread, but apparently something about bullseye updates have broken functionality and the Pi-hole dev team are currently looking for the best way to recommend changes for unbound users. I anticipate forthcoming changes to the documentation reflecting this.

If you've removed both openresolv and resolvconf and your issues no longer persist, quite happy you figured it out in significantly less time than I did. Those forward lookup zones caused my pihole2 client device to be spamming both DNS servers with requests, but was different than the DNS loops I'd encountered in the past. Again, only encountered issues for me on Raspbian (RPiOS), but not pure Debian despite using unbound 1.13.1 in both places.

dpkg-query -s 'openresolv'

My apologies if I misunderstood your underlying issue.

@Bucking_Horn I'm not talking about dynamic link, there's actually a copy of the dnsmasq code in FTL's project, and clearly dnsmask configs are being used as pi-hole writes /etc/dnsmasq.conf and adds more config files in /etc/dnsmasq.d/.

Also for the debug log, I went over it myself and there was not a single reference to resolv.conf or the 127.0.0.1 IP FTL was trying to use, it said the upstream DNS server is the one I had in the config, yet it clearly wasn't being used.

NB: I did mention I started from pi-hole 1.x which was using dnsmask, and I even said my setup back then was bastardized. I had to redo the config elsewhere when it moved away but didn't clean up anything.

@harrypnyce My unbound server is manually configured, so I would not have random forward zones popping into it. The only forward zones in my unbound config are the ones for my router.

I do have openresolv installed, but this is Debian Buster not Bullseye. I mentioned resolvconf before but I the resolvconf configs are actually managed by openresolv, it's probably just a fork of the project.


I'm not denying that or your observation as such.
I just say we couldn't verify possible causes, partially because we were lacking a debug log.

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.