The canarydomain is supported for some time do not exactly know when that was introduced.
At DDWRT we use the same setup to block unwanted DNS: Redirect port 53, 5353, 9953 (see below) Block port 853 Use IPSET with a DoH blocklist to block at the firewall. There are some loopholes you also might want to close, AdGuard listens on port 5353 , you can redirect but be careful if you use mDNS/Bonjour in that case do not redirect the multicast address (224.0.0.251) Quad nine also listens on port 9953 you can also redirect that to 53. Erik Van: Eric Fahlgren <[email protected]> Verzonden: maandag 19 december 2022 18:09 Aan: [email protected] CC: Michael Smith <[email protected]>; Jonathan Stafford <[email protected]>; [email protected] Onderwerp: Re: [Dnsmasq-discuss] Change upstream server by client? Thank you, I had not realized that 'use-applications-dns.net <http://use-applications-dns.net> ' was specialized like that, very interesting! My adblock lists already contained that host, which I now know triggers Firefox (and hopefully others?) to disable their DoH automatically. I do wonder when Mozilla implemented this though, there's no version or date on that page. In addition to my firewall-rule-based blocking of DoH hosts by IP, I also have all of the same DoH hosts listed by name in the dnsmasq config, so with luck the firewall rules are completely redundant. If you look at the nightly-updated part of the config you see these three lines (along with about 300k other hosts, see https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/master/doh-domains_overall.txt for just the DoH host names). ... local=/use-application-dns.net/ <http://use-application-dns.net/> ... local=/doh.dns.apple.com/ <http://doh.dns.apple.com/> local=/doh.opendns.com/ <http://doh.opendns.com/> ... I'm running bog standard dnsmasq 2.86, and the speed is blazing, no measurable degradation in performance with as many as a half million entries in the block lists. The "production" router is a PCengines APU2 (x86), system has 4GB RAM and less than 200MB is used - by everything, not just dnsmasq - when these lists are loaded. In fact, I'd venture to say that my current setup has better performance than passing, say, 1.1.1.1 around, since dnsmasq is caching results locally for all machines, rather than hitting the internet for every device. On Mon, Dec 19, 2022 at 5:13 AM <[email protected] <mailto:[email protected]> > wrote: For FireFox you can also set a Canary Domain : https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet That is what we also do to Redirect DNS request to the router (I am a DDWRT developer) Erik Van: Eric Fahlgren <[email protected] <mailto:[email protected]> > Verzonden: zondag 18 december 2022 19:44 Aan: Michael Smith <[email protected] <mailto:[email protected]> > CC: Jonathan Stafford <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Onderwerp: Re: [Dnsmasq-discuss] Change upstream server by client? Well, the real issue is DNS "leakage", because some (most?) browsers and lots of phone apps use their own resolvers, thus bypassing your advertised DNS resolver. My solution is on the router: I set up dnsmasq as my local resolver (with adblock and DNSSEC, stubby is my backend for DoT), don't even bother advertising it and then have three sets of firewall rules to make sure all hosts adhere to the One True DNS: 1) DNS redirect: All LAN device requests to WAN (or LAN) at port 53 are redirected to the router:53. 2) DoT block: All LAN devices attempting to access port 853 anywhere are blocked. 3) DoH block: All LAN devices that attempt to access port 443 on WAN are checked against a couple of sets of host IP addresses (one each for IPv4 and v6), and if the external host is a known-DoH resolver, the request is blocked. (I update nightly from https://github.com/dibdot/DoH-IP-blocklists) When setting this up, I would watch tcpdump for various requests and convinced myself that I was catching 99% of everything, but I have not even tried to figure out DNS-over-QUIC and how it might be getting past my rules. #1 means that if I go to any machine in the house and say 'nslookup blarg.com <http://blarg.com> 8.8.8.8' or 'dig @8.8.8.8 <http://8.8.8.8> blarg.com <http://blarg.com> ', then I see my router as the DNS resolver in the response, even though I explicitly asked for 8.8.8.8 to resolve it. Which in turn means that DNS configuration on a per-machine is not required, and anyone connecting to my network is subject to my rules. #3 causes some browsers to hang because they really, really want to use DoH. Usually there is a browser setting to disable DoH, so it resorts to plain DNS (at least there is in Firefox, which is what I make everyone here use; yeah, I'm dictator :) ). On Sun, Dec 18, 2022 at 9:57 AM Michael Smith <[email protected] <mailto:[email protected]> > wrote: I am not aware of a way, but hopefully someone else has ideas. I run two instances of pihole. One for the grown ups that points upstream to 1.1.1.1 and the other points to 1.1.1.3. Then I use similar stanzas below to point the clients to the right pihole Michael On Dec 18, 2022, at 9:10 AM, Jonathan Stafford <[email protected] <mailto:[email protected]> > wrote: Thanks, Michael. That will work to get them using that server, but it's totally bypassing dnsmasq which means my local entries from /etc/hosts don't resolve. I'd like both things to work to be difficult :) On Sun, Dec 18, 2022 at 10:36 AM Michael Smith <[email protected] <mailto:[email protected]> > wrote: On 12/18/22 06:59, Jonathan Stafford wrote: --server provides a way to change upstream resolvers based on the domain being queried. Is there a way to make the same sort of change based on the client doing the querying? For example, I'd like the IP address range I use for my kids' devices to use 1.1.1.3. You can achieve this using tags: # Define DNS servers dhcp-option=option:dns-server,1.1.1.1 dhcp-option=tag:kidsdevices,option:dns-server,1.1.1.3 dhcp-host=0c:51:01:95:d3:36,set:kidsdevices # Ipad dhcp-host=58:41:4E:CD:D2:0A,set:kidsdevices # Iphone Michael _______________________________________________ Dnsmasq-discuss mailing list [email protected] <mailto:[email protected]> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss _______________________________________________ Dnsmasq-discuss mailing list [email protected] <mailto:[email protected]> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________ Dnsmasq-discuss mailing list [email protected] https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
