# What would cause pihole-FTL to ignore PIHOLE\_DNS\_1 and resolve using resolv.conf instead?

**URL:** <https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971>\
**Category:** Community Help\
**Created:** [November 10, 2021, 12:03pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971 "2021-11-10T12:03:04Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![dermoth](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dermoth/32/2950_2.png) [@dermoth](https://discourse.pi-hole.net/u/dermoth)\
**Post date:** [November 10, 2021, 12:03pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/1 "2021-11-10T12:03:04Z")

</div>

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 [unbound - Pi-hole documentation](https://docs.pi-hole.net/guides/dns/unbound/) + forwarding zones  
Upgraded OS and Pi-hole

---

<div class="post-metadata">

**Author:** ![jfb](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/jfb/32/4332_2.png) [@jfb](https://discourse.pi-hole.net/u/jfb)\
**Post date:** [November 10, 2021, 1:07pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/2 "2021-11-10T13:07:45Z")

</div>

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:

```auto
pihole -d

```

or do it through the Web interface:

_ **Tools \> Generate Debug Log** _

---

<div class="post-metadata">

**Author:** ![Bucking\_Horn](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/bucking_horn/32/18719_2.png) [@Bucking\_Horn](https://discourse.pi-hole.net/u/Bucking_Horn)\
**Post date:** [November 10, 2021, 7:13pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/3 "2021-11-10T19:13:58Z")

</div>

> [@dermoth](#):
>
> using /etc/resolv.conf instead. Because it defaults to 127.0.0.1 (that seems to be some pi-hole changes)

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?

> [@dermoth](#):
>
> pihole-FTL seems to be resolving using /etc/resolv.conf instead

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.

> [@dermoth](#):
>
> Set up unbound as per [unbound - Pi-hole documentation](https://docs.pi-hole.net/guides/dns/unbound/) + forwarding zones

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

> [@dermoth](#):
>
> (...) unbound server directly on 127.0.0.1#5335 (...)

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.

---

<div class="post-metadata">

**Author:** ![Bucking\_Horn](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/bucking_horn/32/18719_2.png) [@Bucking\_Horn](https://discourse.pi-hole.net/u/Bucking_Horn)\
**Post date:** [November 11, 2021, 12:12pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/4 "2021-11-11T12:12:06Z")

</div>

A post was split to a new topic: [2nd Pi-hole hits RATE\_LIMIT](https://discourse.pi-hole.net/t/2nd-pi-hole-hits-rate-limit/50994)

---

<div class="post-metadata">

**Author:** ![dermoth](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dermoth/32/2950_2.png) [@dermoth](https://discourse.pi-hole.net/u/dermoth)\
**Post date:** [November 13, 2021, 2:23am UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/5 "2021-11-13T02:23:42Z")

</div>

Hi,

> [@Bucking\_Horn](#):
>
> > [@dermoth](#):
> >
> > using /etc/resolv.conf instead. Because it defaults to 127.0.0.1 (that seems to be some pi-hole changes)
> 
> 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?

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.

> [@Bucking\_Horn](#):
>
> > [@dermoth](#):
> >
> > pihole-FTL seems to be resolving using /etc/resolv.conf instead
> 
> 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.

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

> [@Bucking\_Horn](#):
>
> > [@dermoth](#):
> >
> > Set up unbound as per [unbound - Pi-hole documentation](https://docs.pi-hole.net/guides/dns/unbound/) + forwarding zones
> 
> Depending on your zone configuration, maybe _`unbound`_ reads `resolv.conf` and uses it for your forwarding zones?

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.

> [@Bucking\_Horn](#):
>
> > [@dermoth](#):
> >
> > (...) unbound server directly on 127.0.0.1#5335 (...)
> 
> 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.

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

---

<div class="post-metadata">

**Author:** ![Bucking\_Horn](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/bucking_horn/32/18719_2.png) [@Bucking\_Horn](https://discourse.pi-hole.net/u/Bucking_Horn)\
**Post date:** [November 13, 2021, 7:55am UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/6 "2021-11-13T07:55:42Z")

</div>

> [@dermoth](#):
>
> I'm not uploading a debug log, but will hapilly investigate myself if needs be.

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:

> [@dermoth](#):
>
> but I did see FTL is using dnsmask libs.

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

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`.

> [@dermoth](#):
>
> Maybe some stale config files then

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`_.

> [@WARNING: Raspbian October 2021 release bullseye + unbound](https://discourse.pi-hole.net/t/warning-raspbian-october-2021-release-bullseye-unbound/51027/1):
>
> /etc/unbound/unbound.conf.d/resolvconf\_resolvers.conf. You need to delete that file and restart unbound to resume normal behaviour.

May be that is what affects you as well?

---

<div class="post-metadata">

**Author:** ![dermoth](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dermoth/32/2950_2.png) [@dermoth](https://discourse.pi-hole.net/u/dermoth)\
**Post date:** [November 13, 2021, 12:51pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/7 "2021-11-13T12:51:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dermoth](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dermoth/32/2950_2.png) [@dermoth](https://discourse.pi-hole.net/u/dermoth)\
**Post date:** [November 17, 2021, 5:02am UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/9 "2021-11-17T05:02:49Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![harrypnyce](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/harrypnyce/32/6377_2.png) [@harrypnyce](https://discourse.pi-hole.net/u/harrypnyce)\
**Post date:** [November 20, 2021, 3:41am UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/17 "2021-11-20T03:41:42Z")

</div>

@dermoth sir, I believe this was our issue: [WARNING: Raspbian October 2021 release bullseye + unbound](https://discourse.pi-hole.net/t/warning-bullseye-unbound/51027)

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.

---

<div class="post-metadata">

**Author:** ![dermoth](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dermoth/32/2950_2.png) [@dermoth](https://discourse.pi-hole.net/u/dermoth)\
**Post date:** [November 21, 2021, 6:05pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/18 "2021-11-21T18:05:43Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![Bucking\_Horn](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/bucking_horn/32/18719_2.png) [@Bucking\_Horn](https://discourse.pi-hole.net/u/Bucking_Horn)\
**Post date:** [November 21, 2021, 6:39pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/19 "2021-11-21T18:39:40Z")

</div>

> [@dermoth](#):
>
> I suspect some bad interaction between the `dnsmasq` library (used by `pihole-FTL` )

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

> [@dermoth](#):
>
> It's `pihole-FTL` that was using the `resolv.conf` IP for resolving

I've already pointed out:

> [@Bucking\_Horn](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![harrypnyce](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/harrypnyce/32/6377_2.png) [@harrypnyce](https://discourse.pi-hole.net/u/harrypnyce)\
**Post date:** [November 21, 2021, 6:40pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/20 "2021-11-21T18:40:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dermoth](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dermoth/32/2950_2.png) [@dermoth](https://discourse.pi-hole.net/u/dermoth)\
**Post date:** [November 21, 2021, 7:04pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/24 "2021-11-21T19:04:15Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![Bucking\_Horn](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/bucking_horn/32/18719_2.png) [@Bucking\_Horn](https://discourse.pi-hole.net/u/Bucking_Horn)\
**Post date:** [November 21, 2021, 7:09pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/25 "2021-11-21T19:09:37Z")

</div>

> [@dermoth](#):
>
> 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/` .

> [@Bucking\_Horn](#):
>
> 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` .

* * *

> [@dermoth](#):
>
> Also for the debug log, I went over it myself

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.

---

<div class="post-metadata">

**Author:** ![system](https://discourse.pi-hole.net/uploads/default/original/3X/7/c/7c8792f649eeb921c5d2b4c41564ffa873d9a2b8.png) [@system](https://discourse.pi-hole.net/u/system)\
**Post date:** [December 12, 2021, 9:18pm UTC](https://discourse.pi-hole.net/t/what-would-cause-pihole-ftl-to-ignore-pihole-dns-1-and-resolve-using-resolv-conf-instead/50971/31 "2021-12-12T21:18:52Z")

</div>

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