HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox

johnpoz

Offering it on their NS that have open to the public is not at all the same thing as turning it on by default in the browser..

jimp

Nobody said it was. Just two recent things that happened regarding DoH.

johnpoz

True... Is there a link to where HE announced this... looking now.

jimp

I added a link and note about the DoH default rollout starting in the first post as well as instructions for adding the canary domain to the DNS resolver.

johnpoz

Yeah I see that, but maybe I need coffee not finding any news about HE and dot and doh..

kiokoman

https://forums.he.net/index.php?topic=3996.0

johnpoz

hehehe - that is isn't much fanfare over it ;)

Thanks for the link..

Gertjan

@kiokoman said in HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox:

https://forums.he.net/index.php?topic=3996.0

A typical he.net communication.
The smack down millions of infrastructure, and then they comm it using using 50 words or less - no images.

jpgpi250

I was reading this topic, also have been trying to keep DOH out of my network.
Pihole already implemented the NXDOMAIN reply for the canary domain, so firefox is no longer a problem. Google has announced it will start the rollout of chrome with DOH, this might become a problem (they claim the browser will be using DOH, if the system is configured with a DOH capable DNS server).

What I came up with (may OR maybe NOT) a good idea:
I search the web for all lists, mentioning DOH servers, found the following lists:

https://raw.githubusercontent.com/bambenek/block-doh/master/doh-hosts.txt
https://raw.githubusercontent.com/Sekhan/TheGreatWall/master/TheGreatWall.txt
https://raw.githubusercontent.com/oneoffdallas/dohservers/master/list.txt
https://raw.githubusercontent.com/vysecurity/DoH-Servers/master/README.md
https://raw.githubusercontent.com/tjay/DoH-List/master/hosts
https://raw.githubusercontent.com/flo-wer/doh-list/master/domains.txt
https://raw.githubusercontent.com/wiki/curl/curl/DNS-over-HTTPS.md
https://download.dnscrypt.info/dnscrypt-resolvers/json/public-resolvers.json
https://dtm.uk/dns-over-https-doh-servers/
https://heuristicsecurity.com/dohservers.txt

I wrote some scripts to parse, process and consolidate these lists, to create an IPv4 and and IPv6 list. These lists are updated daily, if there are changes

I than created (pfsense two URL Table (IPs) aliases, update frequency 1 (daily)
I added two firewall rules, using the aliases as destination, blocking only port 443 (see screenshot).

The goal is (I hope everything is correct) to prevent devices from using DOH.
So far, I haven't experienced anything negative from using these lists and rules. I haven't had any issues reported on github, not sure if there are users who are using the lists.

johnpoz

Did you on purpose set something to use doh? To test your list, or send traffic specific to those IPs on 443.. Your rules are showing hits..

I concur such a block list is handy for people wanting to make sure something on their network is not using doh without their consent.

I am currently using the thegreatwall list.. In your parsing of the multiple lists, have you found that no one list is complete?

jpgpi250

@johnpoz non of the list are complete, some are never updated, some are updated once a month, but at irregular moments. The list I compiled is the summary of all of these list, the scripts run daily, and verify the DNS name is resolvable. Entries that return no dig result are obviously not in the list. Look at the number of entries in the IPv4 list, compare the number to the number of entries in thegreatwall list, you'll notice a significant difference.
So far, I haven't had any problems using the rules, they have been active for over a month.

johnpoz

@jpgpi250 said in HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox:

haven't had any problems using the rules, they have been active for over a month.

Not what I asked ;) My question is related to you have hits.. So you have something trying to use doh.. Did you do that on purpose? To test you rules - or is there something on your network actually trying trying to use doh?

I would for sure investigate what source IP is triggering those hits, and see WTF its up with it and why is trying to use doh..

My doh rules have no hits..

I know they work because I tested them before.. but then I reset the rule counters on purpose.. Because If I see that tick up, I sure and the F would be chasing down the device that tried it..

Since I block the resolving of said doh domains anyway, these rules should never get any hits.. Because the client would not even be able to resolve the doh domains to use... But these rules are in place to catch some client that hard coded the name and IP of doh.. Take a guess - I am not a fan of doh or dot... But atleast dot is easy to block.. Doh is some sneaky ass shit.. That is just WRONG that some of these browsers and shit are auto opting someone into using their dns..

jpgpi250

@johnpoz
I started this proactively, I doesn't look like I currently have any clients, trying to use DoH. I tested my rules, using this DoH client (it isn't very good, but I only needed to verify the rules worked)
Blocking the domain names (DNS blocking) is only a partial defense to block DoH. Most clients need to resolve the domain, in order to send a DoH request. Using a DNS blocker (pihole, pfBlockerNG, Adguard Home, …) helps achieving this, however, there is a new technique, already in use by some providers that doesn't require the domain to be resolved, prior to the DoH request.
I assume devices and apps, that try to force DoH, this to ensure that blocking their DNS name doesn't prevent tracking and data collection, will soon pick up on this. I found an example here, the resulting string doesn't contain an IP or a domain name.

Apart from that, Some providers offer normal DNS (port 53) and DoH on the same IP address. Example:

resolver1.opendns.com
resolver2.opendns.com

Using the IP list(s), blocking only port 443, ensures the normal DNS requests (port 53) still work.

johnpoz

@jpgpi250 said in HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox:

Using the IP list(s), blocking only port 443, ensures the normal DNS requests (port 53) still work.

Dude your preaching to the choir.. I specifically went over why I also have the IP based rules ;)

If I were you, I would clear the counters on you rules.. So you can see by just a glace of your rules if anything has tried to use doh.

tman222

Just a heads up - Google Chrome's Secure DNS (DoH) is arriving soon. Thankfully it looks like it will be easy to disable:

https://blog.google/products/chrome/more-intuitive-privacy-and-security-controls-chrome/

johnpoz

Why and the F do they make this the default? If they want to support it great, just don't make it something I have OPT OUT of... Such features should always be opt in as the default stance..

Out of the box the browser should use the OS for dns.. It doing anything other that should be required to opt in!!

kiokoman

at least
if your current service provider supports it
from what i understant it will use doh only if the dns you have configured support it
?
You can also configure a different secure DNS provider in the Advanced security section
they didn't accept money from cloudflare or from any other dns services
if it's the case, it's not that bad and always better than firefox

kiokoman

interesting how this android phone is ignoring my dhcp settings (8.8.8.8 is not one of my dns) and try to use dot,

the phone have chrome installed, not firefox but maybe is some other apps running on it

Bob.Dig

@kiokoman Is Private DNS on or off?

HuskerDu

Some (most ?) Android devices do natively their Internet connectivity check towards 8.8.8.8.

Android 9+ have "Private DNS" settings enable/disable/auto for DoT.

Both things together may explain your logs.