github-actions[bot]
commented
6 days ago This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.
Open kaechele opened 1 month ago
github-actions[bot]
commented
6 days ago This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.
PromoFaux
commented
4 days ago Do you see the same behaviour if you set the blocking mode to NXDOMAIN rather than NULL?
kaechele
commented
3 days ago When I change the blocking mode to NXDOMAIN the behaviour changes to working as intended:
host host1 on my clienthost1.domain1.lanhost1.domain1.lanhost1.domain2.lan (the second configured search domain)host1.domain2.lan from the forwarded server via PiHolePromoFaux
commented
3 days ago Thanks for the update.
@DL6ER any thoughts here?
DL6ER
commented
3 days ago @kaechele This is not necessarily a setup I can easily reproduce here but let me start with asking if is this still an issue with the most recent development-v6 ? I recall us having fixed something concerning the detection of the external blocked status a few weeks ago, this may have coincided with your issue ticket which I unfortunately missed myself. I will move this to the right repository.
If it still exists with your previous configuration (which may be the case), please run
sudo pihole-FTL --config debug.queries trueand try again the host host1 on your client. The related content in /var/log/pihole/FTL.log should give us a better picture of what is going on here (and hopefully why FTL seems to have detected an upstream blocking attempt with NXRA).
kaechele
commented
2 days ago I'm pretty sure the culprit is this: https://github.com/pi-hole/FTL/blob/61a211f1c187206f5ff901afae657968114fde15/src/dnsmasq_interface.c#L2617-L2626
I reverted dns.blocking.mode back to NULL (the default) and set debug.queries to true to capture the following log:
My read of what's happening here:
10.0.0.10, the upstream server set in the conditional forwarding for domain1.lan, is a PowerDNS Authoritative DNS server.domain1.lan, so that it is able to respond to queries for both domain1.lan A queries as well as for 0.0.10.in-addr.arpa PTR queries.RA bit.NXDOMAIN with unset RA bit as the name being blocked upstream, is satisfied with that and considers the domain blocked for itself as well.AA bit because it is authoritative for domain1.lan. It knows for sure this name doesn't exist.In this case the upstream server behaves correctly, because it doesn't have an entry for this host but it also cannot do recursion. It also doesn't need to, because it is authoritative for domain1.lan.
This is what the query looks like towards 10.0.0.10 using dig:
; <<>> DiG 9.18.28 <<>> host1.domain1.lan @10.0.0.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50978
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;host1.domain1.lan. IN A
;; AUTHORITY SECTION:
domain1.lan. 3600 IN SOA dns.domain1.lan. hostmaster.domain1.lan. 2024101608 10800 3600 604800 3600
;; Query time: 22 msec
;; SERVER: 10.0.0.10#53(10.0.0.10) (UDP)
;; WHEN: Wed Oct 16 22:53:51 EDT 2024
;; MSG SIZE rcvd: 111I believe the root cause here is that PiHole needs to only consider a domain blocked upstream if both the RA and the AA bit are not set. If the AA bit is set PiHole should treat any NXDOMAIN response as authoritatively non-existent rather than blocked.
For comparison, here is a response from 9.9.9.9 for a known Malware domain that this server blocks:
; <<>> DiG 9.18.28 <<>> 1312services.ru @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29040
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;1312services.ru. IN A
;; Query time: 29 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Wed Oct 16 23:00:36 EDT 2024
;; MSG SIZE rcvd: 44No RA bit but also no AA bit. It's probably fine to continue considering this type of response as "blocked externally".
DL6ER
commented
2 days ago Thank you, this is about what I was assuming. Also thank you very much for the proposed fix already :-)
I will review/verify this after returning from work today (it's still earlyish morning on this side of the planet)
Versions
Platform
Expected behavior
When two search domains are configured on a client and more than one conditional forwarder is configured in Pi-Hole, Pi-Hole should respond
NXDOMAINfor those domains instead of blocking them asBlocked (external, NXRA)and responding0.0.0.0/::. Not responding withNXDOMAINwill result in the client not attempting to resolve the non-FQDN hostname using the second configured search domain.Actual behavior / bug
Pihole responds
A 0.0.0.0/AAAA ::to the non-FQDN query forhost1:Therefor the client never tries to resolve
host1.domain2.lan, which would trigger conditional forwarding to the other internal DNS server that has a valid entry forhost1.domain2.lanthat satisfies this request.Steps to reproduce
Scenario:
The client has the following DNS settings:
Configuration for Pi-Hole under Settings -> DNS -> Conditional Forwarding
Steps to reproduce the behavior:
host1host1.domain1.landue to the search domain setting ofdomain1.lan domain2.lanhost1.domain1.lan10.0.0.10) that receives this request due to conditional forwarding does not have a valid RRSet for this domainNXDOMAINfrom10.0.0.10and decides to block the request as it doesn't allow this request to be forwarded to the internetA 0.0.0.0/AAAA ::response from Pi-Hole and is satisfied. Had it received anNXDOMAINresponse it would have tried queryinghost1.domain2.lan, which would have yielded the desired response.Debug Token