HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox
-
simple. privacy is a businness after all. it will not be strange if that work was sponsorized by cloudflare and the like. they are only selling all your data to them and telling you that this way you are more protected
i hate when company make fun of customers. if they left it as an option instead of imposing it as a default it would have been something else -
Now it seems google/chrome wants to join in on the data mining fun.. WTF!!!
https://www.zdnet.com/article/google-to-run-dns-over-https-doh-experiment-in-chrome/dot is easy to block since uses its own port... But guess its time to start compiling list of all known doh servers and blocking them.. Gawd Damn it!!!
-
@johnpoz said in HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox:
But guess its time to start compiling list of all known doh servers and blocking them.. Gawd Damn it!!!
They are also contradicting their own argumentation. Mozilla for example arguments over governmental or rogue ISPs grabbing your data. At the same time they 1) send all your data to a single provider instead of using resolvers to dsitribute the DNS calls to a wide range of servers and 2) use use-application-dns.net as their canary to determine wether or not to disable automagic DoH. So we roll out some application specific black magic BS that breaks your local setup but hand out the free pass for their own attackers to disable it. WTF? How is that thought-out? First thing a rogue ISP or anyone else would be to hand out NXDOMAIN to use-application-dns.net calls to disable that. And if anyone does that... yeah.
Pushing OS developers to include DoT and DoH in their base OS and as next step push all DNS servers to wide-range adaption of both protocols would be the right way. Then you could just tell your local resolver to use either DoH/DoT for resolving (and do or don't fallback to normal udp/53 DNS). Their tactic? No just send it all to Google/Cloudflare etc. Right...
-
the Internet Services Providers Association (ISPAUK), a trade association for internet service providers in the UK, decided to nominate Mozilla for its award of 2019 Internet Villain, next to Donald Trump and the EU's Article 13 Copyright Directive.
https://www.zdnet.com/article/mozilla-no-plans-to-enable-dns-over-https-by-default-in-the-uk/
https://www.ispreview.co.uk/index.php/2019/07/ispa-pulls-uk-internet-villain-category-over-mozilla-doh-fallout.html
ISPAUK have a point here
An application switching to DoH should ensure that this switch does not undermine choices that have been previously made by the user. For example, if parents have decided to filter an internet connection in their home via network or local level DNS controls, these choices should not simply be ignored by the application.
If DoH doesn’t work or is slow, a customer’s internet access will be affected. The customer will contact their ISP, not the DoH provider, but the ISP won’t be able to fix things for them. As a minimum, any application switching to DoH should ensure that the selected resolver should provide a 24/7 user call centre reachable via low-cost/local rate telephony and an online support capability. Support for fault-diagnosis and resolution between ISP, resolver and users should also be provided.
-
@kiokoman said in HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox:
An application switching to DoH should ensure that this switch does not undermine choices that have been previously made by the user
All of which just SCREAMS this can not be opt-out, but MUST be OPT-IN to switch...Where the users has to specifically do something to actually use it, vs just using the OS already set dns..
edit:
I think the thought process has gone something like this.
Q: How can we mine more data from our users without logging and sending the info where they go.. "telemetry" they don't seem to like that.A: Lets have them use us for dns, so that we know everywhere they they go.
Q: How can we get them to do that?
A: We will tell them its for their own security, from the bad isp they are paying every month for internet.Q: Well they are not switching over fast enough, and we don't want to actually spend any money on PR to have them think this is best option for their "security/privacy"
A: Lets just switch them over, and state that is for their own good if they complain, because they are just too stupid anyway.
-
https://apple.news/AREysIdXnROWCIANTguz06A
Not sure if the link will work, they are trying a personal vpn now..
-
They can offer whatever they want - just don't freaking make something like that default... If the user has to turn it on, and make an effort to use it..
-
So I found this listing of known doh servers
https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-serversI have a pm out of @BBcan177 asking if he plans on easy way of blocking these in pfblocker, if not will be working my own listing of them to use in firewall rules and host overrides to block queries for them.
Will prob have dns queries for their fqdn point to a specific IP that I block and log, and any hits to that rule get attention and any devices doing it will if not easy to disable be off the network..
-
I'd also use
local-zone: "use-application-dns.net" static
in the DNS Resolver "custom options" box so to answer with an NXDOMAIN to the canary domain Mozilla uses. Won't help if they switch their approach or simply use a service manually entered but at least the "automagic switch" should be off then.
-
Yeah been in place for some time already ;)
Notice I posted how to do it like 8 days ago ;) Look back over the thread..
-
@johnpoz said in HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox:
I have a pm out of @BBcan177 asking if he plans on easy way of blocking these in pfblocker, if not will be working my own listing of them to use in firewall rules and host overrides to block queries for them.
Some more details here for now until I add this officially to pfBlockerNG:
https://www.reddit.com/r/pfBlockerNG/comments/d3p1gf/doh_server_blocklist/
-
Thanks - but you the have the
use-application-dns.netIn there - that would not return an NX, so it wouldn't work per my understanding of how the firefox canary is suppose to work.. It has to get back a NX to not enable it from my understanding.
I threw this together real quick this morning from list linked to earlier.
local-data: "dns.adguard.com. 120 IN A 172.19.19.19" local-data: "dns-family.adguard.com. 120 IN A 172.19.19.19" local-data: "dns.google. 120 IN A 172.19.19.19" local-data: "cloudflare-dns.com. 120 IN A 172.19.19.19" local-data: "dns.quad9.net. 120 IN A 172.19.19.19" local-data: "dns9.quad9.net. 120 IN A 172.19.19.19" local-data: "dns10.quad9.net. 120 IN A 172.19.19.19" local-data: "doh.opendns.com. 120 IN A 172.19.19.19" local-data: "doh.cleanbrowsing.org. 120 IN A 172.19.19.19" local-data: "dns.nextdns.io. 120 IN A 172.19.19.19" local-data: "dns.dnsoverhttps.net. 120 IN A 172.19.19.19" local-data: "doh.crypto.sx. 120 IN A 172.19.19.19" local-data: "doh.powerdns.org. 120 IN A 172.19.19.19" local-data: "doh-ch.blahdns.com. 120 IN A 172.19.19.19" local-data: "doh-jp.blahdns.com. 120 IN A 172.19.19.19" local-data: "doh-de.blahdns.com. 120 IN A 172.19.19.19" local-data: "dns.dns-over-https.com. 120 IN A 172.19.19.19" local-data: "doh.securedns.eu. 120 IN A 172.19.19.19" local-data: "dns.rubyfish.cn. 120 IN A 172.19.19.19" local-data: "doh-2.seby.io. 120 IN A 172.19.19.19" local-data: "doh.seby.ie. 120 IN A 172.19.19.19" local-data: "commons.host. 120 IN A 172.19.19.19" local-data: "doh.dnswarden.com. 120 IN A 172.19.19.19" local-data: "dns-nyc.aaflalo.me. 120 IN A 172.19.19.19" local-data: "dns.aaflalo.me. 120 IN A 172.19.19.19" local-data: "doh.appliedprivary.net. 120 IN A 172.19.19.19" local-data: "doh.captnemo.in. 120 IN A 172.19.19.19" local-data: "doh.tiar.app. 120 IN A 172.19.19.19" local-data: "doh.dns.sb. 120 IN A 172.19.19.19" local-data: "rdns.faelix.net. 120 IN A 172.19.19.19" local-data: "doh.li. 120 IN A 172.19.19.19" local-data: "doh.armadillodns.net. 120 IN A 172.19.19.19" local-data: "doh.netweaver.uk. 120 IN A 172.19.19.19" local-data: "jp.tiar.app. 120 IN A 172.19.19.19" local-data: "doh.42l.fr. 120 IN A 172.19.19.19"
Here is sample query for one of those.
;; QUESTION SECTION: ;doh.dns.sb. IN A ;; ANSWER SECTION: doh.dns.sb. 120 IN A 172.19.19.19
Simple add that to your custom box in unbound, then put a block log rule in place that logs anything that tries to go to my out of thin air IP that I do not use locally 172.19.19.19
This way I can see if anything is trying to resolve this by just looking if any hits in the firewall rules, and then look into the logs to which IP tried and investigate what its trying to do exactly.
Keep in mind, this could cause you some grief if any of those fqdn are serving up stuff other than doh that you might want to get to.. Some are on other ports other then 443, so I just made the block rule any..
-
bind9
$TTL 60 @ IN SOA localhost. root.localhost. ( 2019091601 3H ; refresh 1H ; retry 1W ; expiry 1H) ; minimum IN NS localhost. ; Make TRR unavailable dns.adguard.com 120 IN CNAME . dns-family.adguard.com 120 IN CNAME . dns.google 120 IN CNAME . cloudflare-dns.com 120 IN CNAME . dns.quad9.net 120 IN CNAME . dns9.quad9.net 120 IN CNAME . dns10.quad9.net 120 IN CNAME . doh.opendns.com 120 IN CNAME . doh.cleanbrowsing.org 120 IN CNAME . dns.nextdns.io 120 IN CNAME . dns.dnsoverhttps.net 120 IN CNAME . doh.crypto.sx 120 IN CNAME . doh.powerdns.org 120 IN CNAME . doh-ch.blahdns.com 120 IN CNAME . doh-jp.blahdns.com 120 IN CNAME . doh-de.blahdns.com 120 IN CNAME . dns.dns-over-https.com 120 IN CNAME . doh.securedns.eu 120 IN CNAME . dns.rubyfish.cn 120 IN CNAME . doh-2.seby.io 120 IN CNAME . doh.seby.ie 120 IN CNAME . commons.host 120 IN CNAME . doh.dnswarden.com 120 IN CNAME . dns-nyc.aaflalo.me 120 IN CNAME . dns.aaflalo.me 120 IN CNAME . doh.appliedprivary.net 120 IN CNAME . doh.captnemo.in 120 IN CNAME . doh.tiar.app 120 IN CNAME . doh.dns.sb 120 IN CNAME . rdns.faelix.net 120 IN CNAME . doh.li 120 IN CNAME . doh.armadillodns.net 120 IN CNAME . doh.netweaver.uk 120 IN CNAME . jp.tiar.app 120 IN CNAME . doh.42l.fr 120 IN CNAME .
i can change the dot to some "out of thin air ip" if i want to log, reporting NX for the moment
laboratorio@server:/$ dig @127.0.0.1 doh.crypto.sx ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> @127.0.0.1 doh.crypto.sx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10547 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: dda6e2c23949f6cda855e6485d7fa7fddeb8459af20d8f8b (good) ;; QUESTION SECTION: ;doh.crypto.sx. IN A ;; ADDITIONAL SECTION: overrides. 60 IN SOA localhost. root.localhost. 2019091601 10800 3600 604800 3600 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Sep 16 17:19:25 CEST 2019 ;; MSG SIZE rcvd: 129
-
Only reason pointed it to an IP, is I normally don't log dns queries - there are so freaking many of them it can be information overload to weed through... I only enable dns query logs when wanting to troubleshoot a specific issue.
Figured if I point it to a specific IP, I can log any attempted access to that odd IP so can see at a glance in the firewall interface if any hits to it. And then investigate..
Multiple ways to skin the cat is best, so no matter what what users are using specific in there setups they have a easy way to skin this one..
These little devices could bypass these method with a direct query to the IP.. So prob need to put together an alias that lists the actual public IPs and blocks.. This is going to turn into such a shit show..
Uncontrolled circumvention of a local networks controls is not by any stretch of the imagination good for anyone!
-
Was just shown this by colleague: https://bsd.network/interact/102767562311572315
Had to laugh ;) -
This resolver now points to https://mozilla.cloudflare-dns.com/dns-query instead of https://cloudflare-dns.com/dns-query
-
@JeGr said in HEADS UP: Be aware of Trusted Recursive Resolver (TRR) in Firefox:
canary
But the canary stayed the same, so that should already disable it.
-
I have been reading this thread and have added the list found in the link that BBcan177 provided above to DNSBL. However, where is the about:config mentioned by Jim so I can set network.trr.mode to 5? This is what I saw in Firefox preference:
-
in the about:config section
-
@johnpoz Thanks John for responding...it seems that Macs don't have that options...I am using Firefox 69.0.2...
-
I don't have a mac to test with.. But your at about:preferences not about:config?
No you wouldn't find it there - see I went there in my windows firefox
-
@johnpoz Found it John...one has to type about:config in the URL bar and accept the risk...thank you!
-
I've just tried the unbound custom option... it seems Firefox keeps asking for its DoH stuff, Suricata seeing some associated traffic.
1 TCP A Network Trojan was Detected 10.X.X.X 51133 104.16.249.249 443 1:2027695 ET POLICY Observed Cloudflare DNS over HTTPS Domain (cloudflare-dns .com in TLS SNI)
-
Did you set TRR in firefox to 5? Without some details of what you actually did there is little anyone can do to help you find out what you did wrong.
You need to make sure unbound return NX..
I watch this like a hawk and have rules in place to log any sort of doh to any of the know ns doing doh, and block tos - and have not seen any hits on the rules at all.
-
The purpose was to test the usage that Firefox makes of its canary domain and if it obey their published rules.
First of all, the status is NOERROR not NXDOMAIN
; <<>> DiG 9.10.6 <<>> use-application-dns.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27411 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;use-application-dns.net. IN A ;; ANSWER SECTION: use-application-dns.net. 60 IN A 10.10.10.1 ;; Query time: 45 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Tue Nov 26 21:31:02 CET 2019 ;; MSG SIZE rcvd: 68
TRR was 2 as it was the intend of that quick test.
-
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.
-
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))
-
@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..
-
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 ?
-
@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
-
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.
-
@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..
-
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)
-
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.
-
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 ... -
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/
-
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..
-
Nobody said it was. Just two recent things that happened regarding DoH.
-
True... Is there a link to where HE announced this... looking now.
-
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.