Blocking DNS over HTTPS. Seems the only way is to fire a shotgun at it

Lanna

The custom resolve option only works with Firefox AFAIK, and such measures would require compliance from all programs and apps, which Malware vendors would just ignore anyway. Chrome doesn't use a canary domain. Chrome devs themselves state that they use a 'unique' method.

About pfBlocker I'll look into that.

Raffi_

Yes, good point.

I think I see the option you mentioned in chrome now. It's not clear to me what "with your current service provider" means but I'm guessing my current DNS service provider which is pfSense?

I found this though, not sure if it applies in your scenario.
https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html

Raffi_

I do have the default option enable as I showed above in Chrome, so I did some quick testing. Running a packet capture, I'm seeing normal DNS requests as I would expect within my network and the requests are going straight to pfSense over 53.

I am doing DNS redirection as mentioned in the first link I provided, I am also using the Firefox DoH blocking option in pfblockerNG-Devel. I don't know if either of those are actually making it work for me but I can confirm it's not an issue in my setup.

Lanna

What OS are you using? I've been unable to reproduce this on my Linux box. I can only make it happen on a Windows 10 machine with Chrome 85 in our Bangkok office, which I am controlling via VNC.

Raffi_

@Lanna said in Blocking DNS over HTTPS. Seems the only way is to fire a shotgun at it:

What OS are you using? I've been unable to reproduce this on my Linux box. I can only make it happen on a Windows machine in our Bangkok office, which I am controlling via VNC.

I'm using Windows 10 pro.

Lanna

Looking at the settings, this appears to only have support on Windows. With Linux variants of Chrome and Chromium, the options are greyed out for the time being.
Also, it's clear that we will have to keep an eye on which DNS providers are supported by Chrome. See here. . .
https://www.chromium.org/developers/dns-over-https

I am now blocking all of those with Aliases

johnpoz

@Lanna said in Blocking DNS over HTTPS. Seems the only way is to fire a shotgun at it:

You have to block Cloudflare's entire IP space. I do it with an Alias.

That would be throwing out the baby with the bath water sort of solution.. Clouldflare serves up a huge chunk of the internet, if you blocked all ports to all of cloudflare IP space many a site would not work.. Not just dns lookups.

That clarly can not be the case for sure - because for doh to work, a specific fqdn is used.. They can not just shotgun all of their space, nor could they have their fqdn resolve to all of their IPs.

Lanna

Do you know how I might find that FQDN (assuming you are correct about that)?. If they are doing anycast on that FQDN and thus using anything in their IP space to serve up the DNS, I see no other solution that just just block it in it's entirety, and accept that any Cloudflare protected site is gone.

To be clear, if I allow any specific Cloudflare subnet, DNS over HTTPS starts working again.

johnpoz

@Lanna said in Blocking DNS over HTTPS. Seems the only way is to fire a shotgun at it:

If they are doin anycast on that FQDN and thus using anything in their IP space

anycast is not going to be ALL of their IP space... DOH operates on a fqdn, while sure it could go to anycast IP(s) there is not possible way it could go to all of their space..

Yeah your solution works - sure, but you washed the baby, and then threw it out as well with the dirty water ;)

Your going to sure have some unhappy users if you block all of cloudflare.. Easier solution from an enterprise standpoint is force use of proxy..

Lanna

I know it's a crude solution, but it's all I have until something else is suggested.

johnpoz

I hear you, and agree with you what the companies are doing is utter shitstorm... Looking out for the users my ass.. They just want the dns queries sent to them.. And they want them from each of their products directly so they can better track every single user vs a bunch of users hiding behind a caching server..

These companies are not trying to better anything - they are finding more ways to monetize user data..

This whole dot, doh is just one large shit show... That is is for damn sure.

If your going to roll it out, it sure and the hell should be mandatory opt-in, and it should check for a canary that the local enterprise can put in place to make sure its turned off on any browser on the corp network, where dhcp handed the OS a corp dns server.

Atleast with dot, port 853 its easy enough to block. Hiding it inside 443 is just more sneaky bs..

Here is list of doh IPs I am using
https://raw.githubusercontent.com/Sekhan/TheGreatWall/master/TheGreatWall_ipv4

This it the IPs they list for cloudflare doh

# Cloudflare
1.1.1.1
1.0.0.1
104.16.248.249
104.16.249.249
104.18.2.55
104.18.3.55
104.18.27.128
104.18.26.128

Also when they control your dns - pretty difficult to block ads based on dns..

Anyone that thinks this is doing anything but giving these companies more control and more info is blinded by the BS.. Trust us we will make you safer my F'ing ASS! ;)

You can look here for a list of doh fqdn
https://github.com/curl/curl/wiki/DNS-over-HTTPS

And they have a script to help you parse it.

Lanna

@johnpoz Thanks for that list, I'll study that. In fact I'll evaluate the efficacy of that list in place of the blanket block I currently test.

johnpoz

I also have put in some host overrides to resolve most of these fqdn to local IP that I block, and log - so I can see what IP might be trying to hit it

local-zone: "use-application-dns.net"  always_nxdomain
local-zone: "local."  always_nxdomain
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"

It is much longer than that - but really need to work out a more elegant way than just entries in unbound.. Just haven't gotten around to it yet.. And nothing has hit any of my rules.. I always make sure sure its turned off any browser I use..

see my edit above for a github list that lists many of the fqdn used..

Lanna

I tested the list at https://raw.githubusercontent.com/Sekhan/TheGreatWall/master/TheGreatWall_ipv4
Unfortunately, Chrome immediately started sending queries to 162.158.161.161 in Singapore and bypassing my countermeasures.

Lanna

I realise Cloudflare cannot be using their entire IP space to serve up DNS, but they're clearly using a lot of IPs embedded in many, many subnets, either as a part of their design, or deliberately to obfuscate the target server for network admins.

Uglybrian

Hi-
How do you feel about using this list in PF Blocker https://heuristicsecurity.com/dohservers.txt.

I know not everyone uses PF blocker, but how does a list of the DNS ip work for blocking when the query is sent out FQDN?

Lanna

I'm now playing with a host override in my DNS resolver, pointing cloudflare-dns.com at local IPs to monitor, as you suggest above. However, I am seeing completely different IPs being queried from Chrome, also with DNS leak test websites. If I do a DNS lookup from the gateway itself, on those Cloudflare FQDNs, the IPs returned are in the blocklist. IPs queried from Chrome are not in the blocklist. Chrome must be using a different, unknown FQDN

johnpoz

What exactly are you settings in chrome? So you have it on purpose set to try and use doh, and your trying to block it?

You have it set like this

If so, I can do that and look to see what its doing.. Logging all traffic coming from the machine.. with a sniff.

And see if dns works.

Lanna

@johnpoz Yes, Chrome DoH set to use system DNS, host machine set to use 1.0.0.1 and 1.1.1.1

This particular machine in Bangkok keeps using IP 162.158.161.161 when using DNS leak test website

johnpoz

Show me the setting you have set, like I have above - you have the other setting set..

And how your seeing that IP is from a leaktest.. I think your not understanding how those tests work.. Then.. Just because you see an IP there doesn't mean your client talked to that IP..