Cannot enable /etc/dnsmasq.d

Expected Behaviour:

Records in the /etc/dnsmasq.d folder are loaded into the resolver after enabling the misc.etc_dnsmasq_d setting in the “All Settings → Misc” tab.

File list of /etc/dnsmasq.d
ls -l /etc/dnsmasq.d/
total 4
-rw-r--r-- 1 root root 226 Sep 26 13:43 99-ansible-local-hosts.conf

OS Info:
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm

PiHole Versions:
Core version is v6.1.4 (Latest: v6.1.4)
Web version is v6.2.1 (Latest: v6.2.1)
FTL version is v6.2.3 (Latest: v6.2.3)

Actual Behaviour:

After attempting to enable the misc.etc_dnsmasq_d and save, a red error box opens on the right top corner

Invalid configuration
dnsmasq: bad option at line 2 of /etc/dnsmasq.d/01-local-network.conf: "# (c) 2025 Pi-hole, LLC (https://pi-hole.net)"

There is no 01-local-network.conf file in my /etc/dnsmasq.d directory to have a “bad option” in.

Debug Token:

https://tricorder.pi-hole.net/UIAJyoPb/

You didn't enable misc.etc_dnsmasq_d:

   [misc]
     etc_dnsmasq_d = false

Please read this topic: Etc/dnsmasq.d files

Your debug log shows your router's DHCP servers to distribute two DNS servers:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
   Scanning all your interfaces for DHCP servers and IPv6 routers
   
   * Received 307 bytes from 10.100.0.1 @ ens18
     Offered IP address: 10.100.0.12
     DHCP options:
      Message type: DHCPOFFER (2)
      router: 10.100.0.1
      dns-server: 10.100.0.12
      dns-server: 10.100.0.9
      --- end of options ---

The debug log is from 10.100.0.12.

Assuming both are Pi-holes, I'd suspect that it would have been the other Pi-hole that complained about the invalid configuration?


Unrelated to your observation, there is also a second DHCP server on your Pi-hole's link, and that one only distributes itself as DNS server:

   * Received 300 bytes from 10.100.0.50 @ ens18
     Offered IP address: 10.100.0.231
     DHCP options:
      Message type: DHCPOFFER (2)
      router: 10.100.0.50
      dns-server: 10.100.0.50
      --- end of options ---

Devices that would acquire their lease through that DHCP server would not use 10.100.0.12 nor 10.100.0.9 for DNS.
What's that 10.100.0.50?

In addition, your main router is advertising its own IPv6 for DNS:

*** [ DIAGNOSING ]: Networking
(…)
[i] Default IPv6 gateway(s):
     fe80::<redacted>0%ens18
   * Received 120 bytes from fe80::<redacted>0 @ ens18
     Hop limit: 64
     (…)
     Recursive DNS server 1/1: 2600:<redacted>0
     DNS server lifetime:1800 sec
     DNS search list: ky-edwards.family 
      DNS search list lifetime: 1800 sec

This would allow your IPv6 clients to by-pass Pi-hole via your router, unless you had configured that router to use Pi-hole as its only upstream (but note that may have closed a partial DNS loop, and that you won't be able to attribute DNS requests to original individual IPv6 clients in such a configuration).

It would be preferred to find a way to configure your router to stop advertising its own IPv6 as DNS server, or to advertise your Pi-hole host machine's IPv6.

That was the reason I opened this ticket. I cannot enable it, at least not via the Web UI.

I will look at the DHCP settings, but I don't think that is related to the issue, though I could be wrong. The intent is that my router (10.100.0.1) is my only DHCP server. I also have set up, and it is likely overkill, PiHole on three "servers" on my network. A VM on each of my ProxMox servers (used to be one LXC and one VM on the same proxmox) and one Raspberry Pi. One VM is the primary DNS (10.100.0.12) and was the primary before the LXC was decommissioned. The former LXC and the Raspberry Pi have Keepalived running a VIP between them. They are 10.100.0.10 and 10.100.0.11 (10 used to be primary before the LXC developed issues). The VIP assigned in 10.100.0.9 and is set to be secondary DNS. All three are running unbound on their own system and have the loopback port set to be the upstream dns on port 5353. I share the config amongst the servers using nebula sync.

The log I uploaded was from 10.100.0.12. It won't let me set the dnsmasq setting in the web UI.

For some reason, when I went to look at my local records config the other day, all my values were gone and were now listed in the "hosts" section of my pihole.toml. I wanted to add a new one (my octoprint VM) but when I try to add it, it wasn't in the resolve lists. I wanted to centralize things, so I made an ansible script that would append to a 99-ansible-hosts.conf in the dnsmasq.d folder. It is not reading in the dnsmasq.d because of the setting I cannot change in the webui. I assume I can edit the pihole.toml, but I don't know why the error is reporting back a file that doesn't exist in my dnsmasq.d directory at all.

10.100.0.50 is my primary docker host on my network. It is hosting a caddy reverse proxy so a lot of DNS records point to it for final resolution.

I recently got my IPv6 up and running. I will see if I can make it so that DNS resolution will look to PiHole on it.

Yes, that second DHCP server is unrelated to your issue.
Nevertheless, your router's advertised IPv6 DNS server should be addressed, to prevent Pi-hole being by-passed.

My initial quoting of the DHCP server discovery output is to explain and support my suspicion that your observation is related to that assumed second Pi-hole in your network, in particular because you didn't mention you had another Pi-hole in your network.

Now that you've disclosed you are actually running three Pi-holes, and that you further do...

I'm almost convinced that your other Pi-hole's configuration plays a role in this, and I'm going to suspect that NebulaSync contributes to your observation.
Could you check all of your Pi-holes for that rogue 01-local-network.conf?


Also, unrelated to your observation:

Your debug log has expired, so I can't tell if your unbound really would be using 5353 instead of 5335.
As 5353 is reserved for mDNS protocol usage and shouldn't be used for plain DNS, you should switch to another port, e.g. 5335.

It was all a big mistake on my part. I was migrating some of my servers around and thought my changes to make dns and dns3 on my network swap places. So when I was logged into what my primary via SSH where I was working on the dnsmasq settings, the UI was pointed to my dns3 server. The UI said it was the primary, but that was a cross configure issue where I didn't update the resolution. I got everything figured out and it is all running cleanly now.