Pi-Hole should be returning NXDOMAIN for queries for the Firefox DoH canary domain use-application-dns.net and instead is returning NOERROR with an A record of 0.0.0.0. This causes Firefox to use DoH and bypass Pi-Hole filtering.
Expected Behaviour:
In order for Firefox heuristics to correctly trigger and disable DoH on startup, the canary domain for DoH (use-application-dns.net) must return an NXDOMAIN or a NOERROR w/ an empty answer section.
Pi-Hole is returning a NOERROR and an answer of 0.0.0.0 for the canary domain, which means Firefox still uses DoH on my network. My understanding was this was supposedly fixed in Pi-Hole previously to use the canary domain by default, and I've verified it's still set correctly in the dnsmasq configuration file.
; <<>> DiG 9.10.6 <<>> use-application-dns.net @192.168.3.254
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18774
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;use-application-dns.net. IN A
;; ANSWER SECTION:
use-application-dns.net. 2 IN A 0.0.0.0
You have the proper config line in /etc/dnsmasq.d/01-pihole.conf:
server=/use-application-dns.net/
So there's something else that is interfering with the normal operation of Pi-hole. Have you added use-applicaion-dns.net to a blacklist or a manual block?
*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
192.168.3.254/24 matches the IP found in /etc/pihole/setupVars.conf
[✓] IPv6 address(es) bound to the eth0 interface:
2603:<redact>87 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
2603:<redact>cc does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
fe80::3410:bb2d:3c28:6e54 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
^ Please note that you may have more than one IP address listed.
As long as one of them is green, and it matches what is in /etc/pihole/setupVars.conf, there is no need for concern.
The link to the FAQ is for an issue that sometimes occurs when the IPv6 address changes, which is why we check for it.
[i] Default IPv4 gateway: 192.168.3.1
192.168.3.1
* Pinging 192.168.3.1
192.168.3.1...
[✗] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546)
[i] Default IPv6 gateway: fe80::44e8:e0ff:fef2:2feb
fe80::44e8:e0ff:fef2:2feb
* Pinging fe80::44e8:e0ff:fef2:2feb
fe80::44e8:e0ff:fef2:2feb...
[✗] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546)
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] www.rmpm.ly is 0.0.0.0 via localhost (127.0.0.1)
[✓] www.rmpm.ly is 0.0.0.0 via Pi-hole (192.168.3.254)
[✓] doubleclick.com is 172.217.1.142 via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] youngnpotent.tumblr.com is :: via localhost (::1)
[✗] Failed to resolve youngnpotent.tumblr.com via Pi-hole (2605:6000:6d86:8a00:9624:f764:5ead:c47a)
[✓] doubleclick.com is 2607:f8b0:4000:802::200e via a remote, public DNS server (2001:4860:4860::8888)
The solution appears to be to add an explicit whitelist entry for use-application-dns.net. This causes it to return NXDOMAIN as expected. I'm guessing one of the blocklists I added is blocking it, which is why it returned the incorrect result. It'd be useful to internally treat this domain specially in pi-hole, or to default to it being explicitly whitelisted out of the box, perhaps.
Yes, I haven't gotten around to setting up IPv6 ULA yet, so the address in setupVars.conf doesn't match the current address. I have another interesting hack in place that resolves this on the router side, but at any rate, I'll eventually fix that. It's not really problematic for me right now.
We need to be aware of those who want it to return a value for their use. This is probably a good lesson in being mindful of adding lists that you do not review personally. I can see from the log that you have a large number of lists and are using applications outside of Pi-hole's control to modify the domains and databases that Pi-hole depends on to function.
This is a fair point, but unfortunately isn't really feasible in any meaningful way. There's, quite frankly, too many malicious actors online for any one person, even an expert, to know with any level of rigor who all of them are and to what domains they are associated. Reviewing all of the blocklists personally would be a monumental task, and one that has to be repeated regularly as they update. Instead, necessarily, one must trust the work of volunteers, the community, and their track records to do a good job maintaining these lists as a group. Generally speaking, even with such a large number of lists, I've never had anything that should have been whitelisted blocked during my browsing and all of the lists I'm using work well.
I'll see if I can find out which blocklist includes the canary domain and submit a PR to remove it.