zlacker

>>taubek+(OP)
Here are a few things I do to combat nasty websites:

- 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.

>>Tactic+ra
While these are all good practices, killing DoH conclusively on your home network is more difficult than you've made it seem, as ultimately all you can really do is use domain blacklists at your firewall. It's no longer as straight forward as just control port 53 traffic, not like you can realistically shut down 443... Blocking DoH is largely whack-a-mole and I think is only going to get worse as this and similar techniques spread. There are so many sneaky ways to resolve a hostname an app or device can choose to use now.

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.

>>giobox+yk
DoH uses UDP, not TCP. Unless you're using HTTP3/QUIC, you can block port 443/UDP.

And hey, maybe one day advertisements will be served directly via IP addresses, not domains:)

>>mmsc+cI
> DoH uses UDP, not TCP. Unless you're using HTTP3/QUIC, you can block port 443/UDP.

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...

>>dngray+ch1
While these are two common standards, you can easily implement DoH almost anyway you want if you are building a service or device. Its just replying to a request for a hostname record over HTTPS fundamentally - it can be as simple as an extra REST API you run. The number of "protocols" here is effectively limitless. I cant stress enough how simple it can be - check the specs you linked, the example HTTP request/response for the DNS over HTTP3 example is really basic - you could build your own in less than an hour if you really wanted and understand how traditional DNS works.

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.