etc_dnsmasq_d Config not loading after updating to 6.1

jlsherman02 · June 1, 2025, 8:44pm

System Details

Operating System: Debian GNU/Linux 12 (bookworm)
Hardware Pi 3b+
Core version is v6.1 (Latest: v6.1)
Web version is v6.2.1 (Latest: v6.2.1)
FTL version is v6.2 (Latest: v6.2)

Expected Behavior:

The config files in /etc/dnsmasq.d should be loaded and Pi-Hole should get the result from the upstream server for the configured domain.

Actual Behavior:

While are no errors when it is loaded the system failed to get a valid response from the upstream server.

After upgrading the nslookup comes back with NXDOMAIN result for a server on my local network. There were no changes to the upstream windows DC that provides the response for the domain in question.
If I query the upstream server directly from Pi-Hole I get the correct response.
Also, if I configure Conditional forwarding on the Pi-Hole it will return a correct result for the domain. While that is a work around for the short term is it not acceptable as a solution.

Debug Token:

Two broken system
https://tricorder.pi-hole.net/xxNSXfOM/
https://tricorder.pi-hole.net/xCf72QVu/
Working with conditional forwarding.
https://tricorder.pi-hole.net/4A3G6ggN/

deHakkelaar · June 1, 2025, 10:25pm

Check out the misc.etc_dnsmasq_d and misc.dnsmasq_lines "Expert" settings under:

All settings --> miscellaneous

You can choose either whatever you prefer.

jlsherman02 · June 1, 2025, 10:54pm

The setting for misc.etc_dnsmasq_d is enabled and has always been enabled. This was working in version 6.0.6 without issue. Since upgrading to the current version, it stopped working. This appears to be a bug in the current version of an underlying component.

deHakkelaar · June 1, 2025, 10:56pm

Yeah be patient.
I believe they are hard at work to squash some bugs.

jlsherman02 · June 2, 2025, 6:21pm

Can you confirm that the behavior that I am reporting is a bug? If so, can you provide a bug number so that I can track the status?

rdwebdesign · June 2, 2025, 7:50pm

No.

At the moment we can't say if your issue is a bug, a config issue or something else.

The comment above just explained we are fixing another bug and you need to be patient until we have free time to see your issue.

BadBunny · June 2, 2025, 8:12pm

Since the update I have the same issue.
My rev-dns entries from /etc/dnsmasq.d/ are resolved correctly.
But for my local domain "homenet.lan" I just get is NXDOMAIN.

dhcp-option=6,10.1.1.30
server=/homenet.lan/10.1.1.18
server=/homenet.lan/10.1.1.19
### Reverse DNS ###
ptr-record=1.1.1.10.in-addr.arpa,fb6690.homenet.lan
ptr-record=2.1.1.10.in-addr.arpa,fb6591.homenet.lan
ptr-record=3.1.1.10.in-addr.arpa,fb6590.homenet.lan

This is only for hosts which have dns records on 10.1.1.18 and 10.1.1.19. If I try to resolve hosts which got their IP via DHCP they're resolved correctly.
DHCP Option is also set correct on all DHCP Clients. So custom settings for dnsmasq seem du be applied.

The behaviour before was exactly what I had needed. Resolve Hosts which got their IP via DHCP by pihole, if no IP exists, use the external DNS for the same domain.

Bucking_Horn · June 3, 2025, 7:17am

jlsherman02, I cannot reproduce your issue with my Pi-hole container.

Your debug log shows you have added some 40 lines of custom dnsmasq configuration files to your Pi-hole, spreading over six different files.

I have used the following set of options, tyring to cover the types of options that you've used:

server=/my.router/192.168.2.1/
server=/_msdcs.my.router/192.168.2.1
server=/2.168.192.in-addr.arpa/192.168.2.1
address=/0.ubnt.pool.ntp.org/192.168.2.1

I have no issues resolving related DNS requests, regardless whether I use misc.etc_dnsmasq_d or misc.dnsmasq_lines to include custom definitions.

Is this really fixing resolution for all your custom definitions?
To that end, could you be more specific about what lookups you are observing as not working?

Your Conditional Forwarding only concerns definitions from one of your six files, and only a fraction of that, as you forward only to one target server IP.

Also, note that the options affected by Conditional Forwarding are actually equivalent to your respective definitions, as that would just use a more convenient syntax.
E.g. for my above set of definitions, that would amount to changing
server=/2.168.192.in-addr.arpa/192.168.2.1
to
rev-server=192.168.2.0/24,192.168.2.1

To investigate how Pi-hole actually handles your DNS requests, please monitor your /var/log/pihole/pihole.log (e.g. via Tools | Tail log files | pihole.log), while running some resolution requests that you'd expect to be resolved or forwarded according to your custom configuration.
Please share the output of the following commands:

nslookup 0.ubnt.pool.ntp.org 192.168.2.114

nslookup 192.168.2.1 192.168.2.114

And please also share the corresponding lines from your pihole.log.

In a busy network, it may be useful to collate log lines by a query's serial number, which should be enabled prior to your lookups by running:

sudo pihole-FTL --config misc.extralogging true

jlsherman02 · June 4, 2025, 2:32am

You are correct I have a few dozen different lines and zones in my network as it hosts several different lab environments. Based on the testing that you have request the issue only happens for Forward looks zones and not reverse zones, and not the static address entries configured on the system.

Looking at the logs I think I see what is going on but can't explain why this is happening.
If you look at the qreuery that was submitted, it is correct. However, when Pi-Hole sends the request to the upstream server it adds the domain on the queue two time. So, I query abc99apc02.abc99.net and it sends abc99apc02.abc99.net.abc99.net As you can see from the above log.

2025-06-03 20:51:44.426 UDP 1317 192.168.2.32/58038 query 114.2.168.192.in-addr.arpa from 192.168.2.32
2025-06-03 20:51:44.427 UDP 1317 192.168.2.32/58038 cached 192.168.2.114 is abc99dns02.abc99.net
2025-06-03 20:51:44.440 UDP 1318 192.168.2.32/58039 query abc99apc02.abc99.net.abc99.net from 192.168.2.32
2025-06-03 20:51:44.443 UDP 1318 192.168.2.32/58039 config abc99apc02.abc99.net.abc99.net is NXDOMAIN
2025-06-03 20:51:44.447 UDP 1319 192.168.2.32/58040 query abc99apc02.abc99.net.abc99.net from 192.168.2.32
2025-06-03 20:51:44.450 UDP 1319 192.168.2.32/58040 config abc99apc02.abc99.net.abc99.net is NXDOMAIN
2025-06-03 20:51:44.456 UDP 1320 192.168.2.32/58041 query abc99apc02.abc99.net from 192.168.2.32m
2025-06-03 20:51:44.458 UDP 1320 192.168.2.32/58041 config abc99apc02.abc99.net is NXDOMAIN
2025-06-03 20:51:44.462 UDP 1321 192.168.2.32/58042 query abc99apc02.abc99.net from 192.168.2.32
2025-06-03 20:51:44.464 UDP 1321 192.168.2.32/58042 config abc99apc02.abc99.net is NXDOMAIN

Request

nslookup abc99cm01 192.168.2.114
Server:  abc99dns02.abc99.net
Address:  192.168.2.114

*** abc99dns02.abc99.net can't find abc99cm01: Non-existent domain

Logs

025-06-03 21:05:56.553 UDP 1842 192.168.2.32/61708 query 114.2.168.192.in-addr.arpa from 192.168.2.32
2025-06-03 21:05:56.554 UDP 1842 192.168.2.32/61708 cached 192.168.2.114 is abc99dns02.abc99.net
2025-06-03 21:05:56.568 UDP 1843 192.168.2.32/61709 query abc99cm01.abc99.net from 192.168.2.32
2025-06-03 21:05:56.570 UDP 1843 192.168.2.32/61709 config abc99cm01.abc99.net is NXDOMAIN
2025-06-03 21:05:56.576 UDP 1844 192.168.2.32/61710 query abc99cm01.abc99.net from 192.168.2.32
2025-06-03 21:05:56.578 UDP 1844 192.168.2.32/61710 config abc99cm01.abc99.net is NXDOMAIN

Request from the server that owns that zone

nslookup abc99cm01 192.168.2.15
Server:  abc99dc01.abc99.net
Address:  192.168.2.15

Name:    abc99cm01.abc99.NET
Address:  192.168.2.45

I have not tested removing the config files are placing the contents directly in misc.dnsmasq_lines.

If I place the forward lookups in to Conditional forwarding with the misc.dnsmasq_d Config still in place this is the result.

2025-06-03 21:18:54.545 UDP 77 192.168.2.32/49945 query 114.2.168.192.in-addr.arpa from 192.168.2.32
2025-06-03 21:18:54.546 UDP 77 192.168.2.32/49945 forwarded 114.2.168.192.in-addr.arpa to 192.168.2.15
2025-06-03 21:18:54.547 UDP 77 192.168.2.32/49945 reply 192.168.2.114 is abc99dns02.abc99.net
2025-06-03 21:18:54.552 UDP 78 192.168.2.32/49946 query abc99bbm01.abc99.net from 192.168.2.32
2025-06-03 21:18:54.553 UDP 78 192.168.2.32/49946 forwarded abc99bbm01.abc99.net to 192.168.2.15
2025-06-03 21:18:54.553 UDP 78 192.168.2.32/49946 forwarded abc99bbm01.abc99.net to 192.168.2.15
2025-06-03 21:18:54.553 UDP 78 192.168.2.32/49946 forwarded abc99bbm01.abc99.net to 192.168.2.16
2025-06-03 21:18:54.553 UDP 78 192.168.2.32/49946 forwarded abc99bbm01.abc99.net to 192.168.2.17
2025-06-03 21:18:54.553 UDP 78 192.168.2.32/49946 reply abc99bbm01.abc99.net is 192.168.2.11
2025-06-03 21:18:54.557 UDP 79 192.168.2.32/49947 query abc99bbm01.abc99.net from 192.168.2.32
2025-06-03 21:18:54.558 UDP 79 192.168.2.32/49947 forwarded abc99bbm01.abc99.net to 192.168.2.15
2025-06-03 21:18:54.558 UDP 79 192.168.2.32/49947 reply abc99bbm01.abc99.net is NODATA-IPv6

For a query that is to testws.lab01.com the log show the following. The query can't return as those system are offline at the moment.

2025-06-03 20:54:33.029 UDP 1454 192.168.2.32/50386 query 114.2.168.192.in-addr.arpa from 192.168.2.32
2025-06-03 20:54:33.030 UDP 1454 192.168.2.32/50386 cached 192.168.2.114 is abc99dns02.abc99.net
2025-06-03 20:54:33.072 UDP 1455 192.168.2.32/50387 query testws.lab01.com.abc99.net from 192.168.2.32
2025-06-03 20:54:33.076 UDP 1455 192.168.2.32/50387 config testws.lab01.com.abc99.net is NXDOMAIN
2025-06-03 20:54:33.080 UDP 1456 192.168.2.32/50388 query testws.lab01.com.abc99.net from 192.168.2.32
2025-06-03 20:54:33.082 UDP 1456 192.168.2.32/50388 config testws.lab01.com.abc99.net is NXDOMAIN
2025-06-03 20:54:33.182 UDP 1457 192.168.2.32/50389 query testws.lab01.com from 192.168.2.32
2025-06-03 20:54:33.184 UDP 1457 192.168.2.32/50389 forwarded testws.lab01.com to 172.21.1.10
2025-06-03 20:54:33.185 UDP 1457 192.168.2.32/50389 forwarded testws.lab01.com to 172.21.1.11
2025-06-03 20:54:35.146 UDP 1458 192.168.2.32/56682 query testws.lab01.com from 192.168.2.32
2025-06-03 20:54:35.147 UDP 1458 192.168.2.32/56682 forwarded testws.lab01.com to 172.21.1.10
2025-06-03 20:54:35.147 UDP 1458 192.168.2.32/56682 forwarded testws.lab01.com to 172.21.1.11

Can you explain why with the config were Pi-Hole has to forward the request to a different server it will add the domain two time?

^[1] I have Edited the results to change the domain to abc from the real domain with a find and replace.

Footnotes ↩︎

Bucking_Horn · June 4, 2025, 7:41am

That's expected, though those are not produced by Pi-hole.
Commonly, nslookup will create at least 4 DNS requests, one each for a given domain's A and AAAA records, with and without your local/search domain appended (it could be even more if your network would be configured with multiple search domains).
It's apparent from the logs which client has issued such a request, e.g.

(…) query testws.lab01.com.abc99.net from 192.168.2.32

I notice you've stripped the requested record types from your output, and you've obfuscated domains as well.
While it would be preferred to share logs as they are, it's ok to redact sensitive information - but at least make clear what you have redacted, so others won't try to work with non-sensical information.

In your case, I can browse through your actual configuration from your debug log (for another hour or so), but I can't correlate that with domains from your redacted log output above.

Alternatively, if you don't want to publicly disclose your logs here, you can create an excerpt and upload them to Pi-hole's servers, and share the resulting token here, e.g.

cat my-log-excerpts.log | sudo pihole tricorder

Just as with a debug log, only the Pi-hole team can access uploads, and they are autoremoved after 48 hours.
Speaking of which - your debug log is about to expire, so if you provide new logs, please also share a new debug token.

jlsherman02 · June 5, 2025, 12:56am

I only change the domain names on my previous post. I thought that I called that out at the bottom of my post sorry for any confusion this may have caused. I have collected logs are uploaded the full unedited pihole.log file to the tricorder site. All tested requests are coming from the IP 192.168.2.32 between 7:31PM and 7:34 PM. Please note that the requests that timed out are expected as the server that provides those requests is offline waiting on new hardware, they were included to show the forwarding of the request in the logs.

Transcript of the requests and the response.
https://tricorder.pi-hole.net/y1z1h4o6/
Full pihole.log file
https://tricorder.pi-hole.net/tjznvyrs/
New Debug log
https://tricorder.pi-hole.net/TWYW32PW/

Please let me know if there is any additional information needed to debug this issue.

Bucking_Horn · June 6, 2025, 10:46am

With the latest Pi-hole Docker Release 2025.06.0 · pi-hole/docker-pi-hole · GitHub, I can confirm your issue.

With the following lines added to misc.dnsmasq_lines:

rev-server=192.168.2.0/24,192.168.2.1
server=/fritz.box/192.168.2.1/
server=//192.168.2.1
server=/_msdcs.fritz.box/192.168.2.1

The resulting dnsmasq.conf looks like this (click for details)

$ sudo grep -v '^#\|^$' /etc/pihole/dnsmasq.conf 

hostsdir=/etc/pihole/hosts
no-resolv
port=53
server=192.168.2.53#5335
cache-size=10000
localise-queries
log-queries=proto
log-async
log-facility=/var/log/pihole/pihole.log
bogus-priv
dnssec
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
use-stale-cache=3600
interface=eth0
local=/home.arpa/
local=/pi.hole/
host-record=pi.hole,0.0.0.0
server=/test/
server=/localhost/
server=/invalid/
server=/bind/
server=/onion/
cache-rr=ANY
filter-rr=ANY
rev-server=192.168.2.0/24,192.168.2.1
server=/fritz.box/192.168.2.1/
server=//192.168.2.1
server=/_msdcs.fritz.box/192.168.2.1

Resolution of fritz.box, smartphone.fritz.box and _msdcs.fritz.box is expected to go to 192.168.2.1.

However, lookups for fritz.box, smartphone.fritz.box return with config is NXDOMAIN:

$ dig +noall +comment +answer fritz.box
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5831
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

2025-06-06 11:33:41.558 UDP 98 192.168.2.11/55980 query fritz.box from 192.168.2.11
2025-06-06 11:33:41.604 UDP 98 192.168.2.11/55980 config fritz.box is NXDOMAIN

$ dig +noall +comment +answer smartphone.fritz.box
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7684
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

2025-06-06 11:34:01.921 UDP 99 192.168.2.11/60131 query smartphone.fritz.box from 192.168.2.11
2025-06-06 11:34:01.924 UDP 99 192.168.2.11/60131 config smartphone.fritz.box is NXDOMAIN

Only _msdcs.fritz.box is actually forwarded:

$ dig +noall +comment +answer _msdcs.fritz.box
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4684
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

2025-06-06 11:34:24.768 UDP 101 192.168.2.11/59910 query _msdcs.fritz.box from 192.168.2.11
2025-06-06 11:34:24.771 UDP 101 192.168.2.11/59910 forwarded _msdcs.fritz.box to 192.168.2.1
2025-06-06 11:34:24.775 UDP 102 dnssec-query[DS] box to 192.168.2.53#5335
2025-06-06 11:34:24.776 UDP 102 reply box is DS for keytag 62294, algo 8, digest 2
2025-06-06 11:34:24.777 UDP 102 reply box is DS for keytag 63242, algo 8, digest 2
2025-06-06 11:34:24.778 UDP 103 dnssec-query[DS] fritz.box to 192.168.2.53#5335
2025-06-06 11:34:24.779 UDP 103 reply fritz.box is truncated
2025-06-06 11:34:24.783 TCP 103 dnssec-query[DS] fritz.box to 192.168.2.53#5335
2025-06-06 11:34:24.786 TCP 104 dnssec-query[DNSKEY] box to 192.168.2.53#5335
2025-06-06 11:34:24.789 TCP 104 reply box is DNSKEY keytag 872, algo 8
2025-06-06 11:34:24.789 TCP 104 reply box is DNSKEY keytag 62294, algo 8
2025-06-06 11:34:24.790 TCP 104 reply box is DNSKEY keytag 25033, algo 8
2025-06-06 11:34:24.790 TCP 104 reply box is DNSKEY keytag 23355, algo 8
2025-06-06 11:34:24.793 TCP 103 reply fritz.box is no DS
2025-06-06 11:34:24.794 UDP 101 192.168.2.11/59910 validation result is INSECURE
2025-06-06 11:34:24.795 UDP 101 192.168.2.11/59910 reply _msdcs.fritz.box is NXDOMAIN

Now, I remove all those lines from misc.dnsmasq_lines apart from server=/_msdcs.fritz.box/192.168.2.1, and enable Conditional Forwarding with:

true,192.168.2.0/24,192.168.2.1,fritz.box

The resulting dnsmasq.conf looks like this (click for details).

hostsdir=/etc/pihole/hosts
no-resolv
port=53
server=192.168.2.53#5335
cache-size=10000
localise-queries
log-queries=proto
log-async
log-facility=/var/log/pihole/pihole.log
bogus-priv
dnssec
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
use-stale-cache=3600
interface=eth0
rev-server=192.168.2.0/24,192.168.2.1
server=/fritz.box/192.168.2.1
server=//192.168.2.1
local=/home.arpa/
local=/pi.hole/
host-record=pi.hole,0.0.0.0
server=/test/
server=/localhost/
server=/invalid/
server=/bind/
server=/onion/
cache-rr=ANY
filter-rr=ANY
server=/_msdcs.fritz.box/192.168.2.1

As you can see, it contains the exact same lines, if in a different order.

With CF enabled, all lookups are forwarded as expected:

$ dig +noall +comment +answer fritz.box
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58021
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; ANSWER SECTION:
fritz.box.		9	IN	A	192.168.2.1

2025-06-06 11:57:48.478 UDP 97 192.168.2.11/47931 query fritz.box from 192.168.2.11
2025-06-06 11:57:48.531 UDP 97 192.168.2.11/47931 forwarded fritz.box to 192.168.2.1
2025-06-06 11:57:48.536 UDP 98 dnssec-query[DS] box to 192.168.2.53#5335
2025-06-06 11:57:48.538 UDP 98 reply box is DS for keytag 62294, algo 8, digest 2
2025-06-06 11:57:48.539 UDP 98 reply box is DS for keytag 63242, algo 8, digest 2
2025-06-06 11:57:48.540 UDP 99 dnssec-query[DS] fritz.box to 192.168.2.1
2025-06-06 11:57:48.544 Insecure reply received for DS fritz.box, assuming non-DNSSEC domain-specific server.
2025-06-06 11:57:48.544 UDP 99 reply fritz.box is no DS
2025-06-06 11:57:48.545 UDP 97 192.168.2.11/47931 validation result is INSECURE
2025-06-06 11:57:48.546 UDP 97 192.168.2.11/47931 reply fritz.box is 192.168.2.1

$ dig +noall +comment +answer smartphone.fritz.box
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57826
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; ANSWER SECTION:
smartphone.fritz.box.	9	IN	A	192.168.2.30

2025-06-06 11:57:54.211 UDP 100 192.168.2.11/35291 query smartphone.fritz.box from 192.168.2.11
2025-06-06 11:57:54.217 UDP 100 192.168.2.11/35291 forwarded smartphone.fritz.box to 192.168.2.1
2025-06-06 11:57:54.220 UDP 100 192.168.2.11/35291 validation result is INSECURE
2025-06-06 11:57:54.221 UDP 100 192.168.2.11/35291 reply smartphone.fritz.box is 192.168.2.30

$ dig +noall +comment +answer _msdcs.fritz.box
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54687
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

2025-06-06 11:58:01.847 UDP 101 192.168.2.11/43245 query _msdcs.fritz.box from 192.168.2.11
2025-06-06 11:58:01.853 UDP 101 192.168.2.11/43245 forwarded _msdcs.fritz.box to 192.168.2.1
2025-06-06 11:58:01.858 UDP 101 192.168.2.11/43245 validation result is INSECURE
2025-06-06 11:58:01.859 UDP 101 192.168.2.11/43245 reply _msdcs.fritz.box is NXDOMAIN

It seems the 'true' parameter in Conditional Forwarding controls some extra behaviour, in addition to writing lines to dnsmasq.conf.
It's also strange that this doesn't affect server=/_msdcs.fritz.box/192.168.2.1.

jlsherman02, would you happen to recall which version you have been running prior to upgrading?

@Developers, can you take a look here, please?

jlsherman02 · June 6, 2025, 11:58am

Before the upgrade I was running 6.04 Pi-Hole, 6.02 of FTL (I think) 6.01 of web (I think). The FTL and web versions I am not 100% on what version they were on, however I know for sure the Pi-Hole version was 6.0.4.

pyrula · June 6, 2025, 12:44pm

same here, proxmox restore to 6.0.6 fixed that issue.

DragonQ · June 6, 2025, 1:05pm

Working (FTL 6.0):

Jun  6 13:03:42 dnsmasq[51]: query[A] odroid-eth.lan from 192.168.1.89
Jun  6 13:03:42 dnsmasq[51]: cached odroid-eth.lan is 192.168.1.83
Jun  6 13:03:42 dnsmasq[51]: query[AAAA] odroid-eth.lan from 192.168.1.89
Jun  6 13:03:42 dnsmasq[51]: cached-stale odroid-eth.lan is NODATA-IPv6
Jun  6 13:03:42 dnsmasq[51]: forwarded odroid-eth.lan to 192.168.1.254
Jun  6 13:03:42 dnsmasq[51]: reply odroid-eth.lan is NODATA-IPv6

Not working (FTL 6.1-6.2)

Jun  6 13:04:59 dnsmasq[51]: query odroid-eth.lan from 192.168.1.89
Jun  6 13:04:59 dnsmasq[51]: config odroid-eth.lan is NXDOMAIN

rdwebdesign · June 6, 2025, 6:01pm

Note about the boolean parameter:

This is just a flag to enable/disable a CF entry:
If true, the entry will be used.
If false, the entry will be ignored, but still saved in pihole.toml and it can be enabled later.

I think this was originally intended to be used as a toggle (a checkbox or a similar control) in the web interface, but we didn't add this kind of user interface to the CF field, yet (I still think it will be used in the future).

DL6ER · June 6, 2025, 6:10pm

We see quite a few reports about basically the same thing written in many places using different working right now.

No, no extra effects besides turning on and off as said by @rdwebdesign.

@Bucking_Horn you mentioned

since you already did extensive testing on this, could you please check if using the same order fixes it?

Bucking_Horn · June 7, 2025, 6:24am

I can't do that.
If I change the order in /etc/pihole/dnsmasq.conf and restart Pi-hole in order to read and apply those changes, my changes will be overwritten.

rdwebdesign · June 7, 2025, 7:13am

Maybe this can be tested removing the configuration changes from pihole.toml and using an extra file in /etc/dnsmasq.d to test the different variations.

Bucking_Horn · June 8, 2025, 8:09am

I don't see how that could be used to change the order as would be required.

The related lines added via CF, misc.dnsmasq_lines or misc.etc_dnsmasq_d are identical.

Pi-hole adds its own Conditional Forwarding lines smack in the middle of dnsmasq.conf, right before local=/home.arpa/, while any custom configuration goes to the very end.

It's also strange that the extra server=/_msdcs.fritz.box/192.168.2.1 always works.

And it's also worth noting that forwards to public DNS servers do not seem to be affected, as server=/met.no/9.9.9.9 is working for me.