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

johnpoz

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

104.16.249.249

https://community.cloudflare.com/t/dns-over-https-using-https-104-16-249-249-dns-query

motific

I skimmed the comments and didn’t see any mention of this...

I’m now seeing IOS devices trying to connect out to google DoH servers.

For now I’ve just blocked Google’s DoH infrastructure but it looks like we’re on the cusp of a technological arms-race.

johnpoz

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

looks like we’re on the cusp of a technological arms-race.

Yup!! Its going to be interesting to be sure.. I think this is is an understatement to be sure. But I really do not think its the place of applications to try and circumvent local dns no matter if their intentions are good or not..

Unless the user of said application be it a browser or any other application specifically sets this application to use some dns be it direct or doh or dot, the application should use the OS set dns..

I am not a fan of the browser using anything other than what my OS is set to use for dns, without my explicit validation to do so.. It for sure its an arms race to have users dns point to a specific location.. I have no problem with the browser offering the ability to do doh or dot.. But its not something the application should just assume - it should have to be called out to do such things by the person running the application.. If they want to default the application to do such a thing it should be a clear op in sort of thing.. There is no scenario where opt out makes any sense - and opt out is a bad thing for sure..

This goes for any sort of device or application - you should use the dns handed you via dhcp, or set by the user in the os or device. Circumvention of this in anyway is violation of user choice! If the user wanted to use xyz for dns - then they should set that be it on the device/application specifically or what they hand out via dhcp..

Using the excuse that the user is too stupid to set this, and we are going what is best for the user is just nonsense!! And just looking to grab information from the users too stupid to know what is going on. Even IF!!! this was being done with the best of intentions - which it is not.. Its the wrong way to go about it.. Education of the user is the correct way!! Let the user chose and set what they want to use..

coreybrett

When I put

local-zone: "use-application-dns.net" static

in my Custom options box, I get

The following input errors were detected:

The generated config file cannot be parsed by unbound. Please correct the following errors:
/var/unbound/test/unbound.conf:102: error: syntax error
read /var/unbound/test/unbound.conf failed: 1 errors in configuration file

Line 102 in that file is the local-zone line from above.

I'm running 2.4.4-RELEASE-p3 (amd64)

johnpoz

You need the

server:

Statement in the box before you can add any other custom commands

here

You can also add the always_nxdomain for good measure.

kiokoman

hurricane electric joined the doh and dot party
The public recursors at 74.82.42.42 / 2001:470:20::2 / ordns.he.net now also support DNS over TLS (DoT) and DNS over HTTPS (DoH) for those who wish to use those interfaces. or for those who want to block it ...

jimp

Just in time for Firefox to crank up the DoH setting

https://arstechnica.com/information-technology/2020/02/firefox-turns-encrypted-dns-on-by-default-to-thwart-snooping-isps/

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.