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

johnpoz

Well that is not how canary is meant to work - so yeah it would fail... It needs to return NX..

https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet

You returned no error and A record... So yeah its going to be able to use doh.

HuskerDu

I've changed

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

to

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

And it now works

; <<>> DiG 9.10.6 <<>> use-application-dns.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58414
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;use-application-dns.net.	IN	A

;; Query time: 37 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Wed Dec 04 20:16:56 CET 2019
;; MSG SIZE  rcvd: 52

Well kind of, Suricata keeps logging the same alert (ET POLICY Observed Cloudflare DNS over HTTPS Domain (cloudflare-dns .com in TLS SNI))

johnpoz

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

cloudflare-dns .com in TLS SNI)

Who says that is firefox? That could be some malware/trojan you have on your network.

I see zero hits to 1.1.1.1 or 1.0.0.1, so firefox wouldn't doing it.. Unless your client not using pfsense for dns, and not seeing the nx for the canary..

HuskerDu

This only happens when I launch Firefox from the machine which generates an alert in Suricata. No worms/trojans and co, it only happens when :

Firefox is set to use DNS over HTTPS
Firefox is launched

My firewall rules only allow DNS to pFsense (including NATing 8.8.8.8:53 towards the firewall for Android devices.... whatever you are telling them, they keep checking "Internet connectivity" on that).

Interestingly, it is not hitting 1.1.1.1 but 104.16.249.249. Maybe the anycast IP is used for marketing purposes but not always used in real life traffic ?

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.