- blacklists entire domains using wildcards (using an "unbound" DNS resolver and forcing all traffic to my DNS resolver, preventing my browser to use DoH -- I can still then use DoH if I want, from unbound)
- reject or drop a huge number of known bad actors, regularly updated: they go into gigantic "ip sets" firewall rules
- (I came up with this one): use a little firewall rule that prevents any IDN from resolving. That's a one line UDP rule and it stops cold dead any IDN homograph attack. Basically searching any UDP packet for the "xn--" string.
I do not care about what this breaks. The Web still works totally fine for me, including Google's G Suite (yeah, I know).
EDIT: just to be clear seen the comments for I realize I wasn't very precise... I'm not saying all IDN domains are bad! What I'm saying is that in my day to day Web surfing, 99.99% of the websites I'm using do not use IDN and so, in my case, blocking IDN, up until today, is totally fine as it not only doesn't prevent me from surfing the Web (I haven't seen a single site I need breaking) but it also protects me from IDN homograph attacks. Your mileage may vary and you live in a country where it's normal to go on website with internationalized domain names, then obviously you cannot simply drop all UDP packets attempting to resolve IDNs.
[0]: https://chromium.googlesource.com/chromium/src/+/main/docs/i...
There are a bunch of file variants to weed out specific bad actors.
It's well currated though I will disclaimer it has broken a few websites in the past for me. Maybe that's a good thing.
You can force traditional port 53 DNS protocol traffic to your own resolver with firewall rules, the same doesn't work for DoH. a DoH request to a domain your firewall blacklist doesn't have looks just like ordinary https/443 traffic and will pass unhindered.
It's why many browsers started defaulting to showing "xn--<whatever>" (punycode representation of IDN characters).
It sucks for domains that are emoji but whatevs. Scammers ruining things for everyone, as usual.
I don't like to have to set rules in browsers: I'll do it when mandatory but I prefer things that the browser won't change during it's next update and, also, I use several browsers.
Oh I know but so far you can still ask both Firefox and Chromium to not use DoH and hence force them to use port 53 and from what I've seen they really honor that. For the moment.
I don't doubt that in a not so distant future we may see companies hardcoding DoH into apps without any possibility of removing that setting!
What I do is no panacea but it gets rid of a lot of things.
> There are so many sneaky ways to resolve a hostname an app or device can choose to use now.
But I whitelist apps that can connect to the net. Browsers, apt (for Debian/Devuan package update), the one that update the NTP/time, SSH out and that's basically it.
I know it's a game of whack-a-mole, but I'm still playing it : )
Maybe this is so but I have yet to see it. AFAIK all the DoT/DoH are on known dedicated IP addresses. I know they don't have to be. They could be on generic Akamai/CF/BunnyCDN/etc... end points but I have yet to come across one utilized in the wild. Have you found any? What are their IP addresses? I would like to add them to my DNS timing/monitoring scripts.
I null route about 24 DoT/DoH IP addresses and my one smartphone seemed to figure out automagically that my router was serving up DoT on 853. I can tell if something is bypassing Unbound because there are things I know should not resolve correctly.
Little pro-tip for anyone who tries to run their own private DoH infrastructure too, Firefox doesn't like RFC1918 addresses for the DoH resolver. Set `network.trr.allow-rfc1918=true` if you run DoH on a private IP.
1. couldn’t you “just” (yea yea I know) install a cert on all your devices and force all 443 traffic though a proxy (like some corporate networks do)?
2. (Something I’ve been meaning to get around to trying for a while) default-block outgoing connections unless unless the external host was recently resolved for the corresponding internal host via your internal resolver? That seems like it would kill anything that tries to avoid your ad-blocking resolver. It seems like that might block hard-coded addresses too, but that could be a good thing..
That’s the design intent. Because not all network administration is benign.
DoH is a tool like any other. Good or bad entirely on why and how it’s used. And your own perspective on that use case.
True.
I had to install a system to MITM all my https traffic in order to block DoH requests.
DoH opens me up to security problems that I wouldn't otherwise have, and the extent I have to go to in order to stop it is crazy.
> DoH is a tool like any other. Good or bad entirely on why and how it’s used.
Except that it's a tool I have little control over, and no control over how and why it's used. That's the problem.
DoH is a plague.
I personally use Timescale magicDNS on all my devices, with pihole DNS running on a home server. The magicDNS can make my home server the 1st responder for DNS queries and it'll block a lot of ad domains.
That's insufficient. There's nothing stopping a web site (or ad on a website) from forming its own DoH request that bypasses the browser and the port. It can be done entirely within the HTTPS stream.
And hey, maybe one day advertisements will be served directly via IP addresses, not domains:)
And with 2), that would work, though you'd probably want to whitelist port 53 so that you can resolve names in the first place. Sounds like it should be effective, though.
You can't control it as a malicious censor who's trying to control what Web sites other people's computers can access just because they're on your Wi-Fi. You can absolutely control it on computers that are actually yours.
That's not true when the just the network itself is yours. It's only true when all of the computers on it are too.
> DoH opens me up to security problems that I wouldn't otherwise have, and the extent I have to go to in order to stop it is crazy.
What? No it doesn't.
> Except that it's a tool I have little control over, and no control over how and why it's used. That's the problem.
You're not supposed to be able to have control over what tools other people use on their own computers.
I do uBlock origin with pretty standard lists and have a list of allowed persistent cookies. Are the uBlock lists doing all that work in the background?
Yes you can. Do what corporate firewalls do. MITM all TLS connections with your own personal CA. Don't allow any traffic streams that you can't MITM to leave your network.
There's actually two protocols DNS over QUIC https://datatracker.ietf.org/doc/rfc9250/ which has a specific port 853. This can be blocked.
Then there is DNS over HTTP3 https://security.googleblog.com/2022/07/dns-over-http3-in-an...
It's actually not too difficult if your users use Firefox. You can use enterprise policies https://support.mozilla.org/en-US/products/firefox-enterpris...
/* 0710: disable DNS-over-HTTPS (DoH) rollout [FF60+]
* 0=off by default, 2=TRR (Trusted Recursive Resolver) first, 3=TRR only, 5=explicitly off
* see "doh-rollout.home-region": USA 2019, Canada 2021, Russia/Ukraine 2022 [3]
* [1] https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/
* [2] https://wiki.mozilla.org/Security/DOH-resolver-policy
* [3] https://support.mozilla.org/en-US/kb/firefox-dns-over-https
* [4] https://www.eff.org/deeplinks/2020/12/dns-doh-and-odoh-oh-my-year-review-2020 ***/
// user_pref("network.trr.mode", 5);
Chinese is the most popular, but only 760 for 2022 and the aggregate trend is down:
2016: 2378
2018: 2252
2020: 1675
2022: 1518
Internationalized Domain Name (IDN) Annual Report 2022
[1] https://www.icann.org/en/system/files/files/idn-annual-repor...
Of course, this is not the fault of DoH providers themselves - at worst, they have just made it easier to perform this.
The rest is just fear mongering, I'm sorry, not sure how to phrase that more elegantly or politely. I'm not an uber smart domain expert wrt certs, but we shouldn't have to be to know that valid device MITM with certs is a normal use case. And it shouldn't be used as a boogeyman man on layman users.
And it's a good thing that DoH is easy, because it helps protect vulnerable people from censorship and surveillance.
I couldn't see how to do this in Windows Firewall. Which OS/firewall/rule are you using?
I was unclear. This is exactly the case I'm talking about. The network, and all of the devices on the network, are mine.
> What? No it doesn't.
It does. It makes it easier for bad actors -- mostly advertising networks -- to bypass my DNS filtering. They can do it all with their own code, encrypted through HTTPS to hide it, and never touch my DNS systems, nor be affected by browser settings.
> You're not supposed to be able to have control over what tools other people use on their own computers.
Again, I'm talking about having control over my own machines, not anyone else's.
Basically the same process that some companies use for similar purposes.
This only works with devices that I can install my own CA key onto. I have not figured out how to do that with the vehicle diagnostic tool.
If that makes DoH bad, then privacy is bad too since it makes it easier for terrorists and pedophiles to evade the law.
DoH is literally just "DNS over HTTPS" (hence the TCP a lot of the time) and you can build this a ton of different ways, including as a basic RESTful API. Local javascript on the page could literally just call any old HTTPS web API to get hostnames resolved, and thanks to HTTPS is much harder to detect, inspect and interfere with than traditional DNS. Fundamentally, a DNS request is a really basic API to implement.
This is why DoH is so hard to conclusively block - its by design to look like "normal" web traffic so bad actors are prevented from manipulating your DNS responses, and the implementation can be done pretty much anyway you want - there are a million different ways to pass a message over HTTPS, and to a firewall they all look like the exact same normal HTTPS traffic if you don't explicitly block the IP or domain serving the DoH.
There is no such thing as right or wrong way to do DoH so long as the DNS messages are passing over HTTPS - the standards are largely to help make it easier to deploy and avoid common pitfalls of course (simpler to integrate to browsers and other software "for free" if the message response body format is standardised), but devices, apps and even javascript in the browser are free to solve this anyway they want, with whatever kind of message payload they can dream up.
DoH is just an HTTP request over SSL in most implementations, nothing more, with the record usually in the payload body in a JSON message or similar.
Yes, that's why I don't use any commercial IoT devices. I have no actual control over them. Before I shed the few I did have, I kept them segregated on their own subnet so that at least their presence didn't have to impact anything else.
The only privacy they are affording is specifically to entities that I don't want operating on my machines to begin with, who are mostly interested in violating my privacy.
So this privacy mechanism, in this use case, really is bad because it reduces my privacy.
If that's what you want, you need to give me time to put it together. I set this up a number of years ago and don't remember the details off the top of my head.
here's what I do remember: I use a squid proxy and replace all of the HTTPS certs on my other machines with my own. When HTTPS is negotiated, it's with my proxy, not the end destination.
Then the proxy does its proxy thing and sets up a normal HTTPS connection with the destination.
In my proxy, I have a script that is looking for the HTTP lookup exchanges detailed in RFC8484 (https://www.rfc-editor.org/rfc/rfc8484). When it finds them, it drops them on the floor. Everything else just gets passed through.
They will tell you it is to defeat censorship though and to improve network resilience, because they are deeply committed to having the image of being a champion of internet freedom.
And besides, every browser that supports DoH also lets you pick what server to use, and adblocking DoH servers exist.