Firefox and Chrome do yes, but none of these standards specify any kind of fall-back behaviour. There are no guarantees that any specific device or application needs to do that or how.

There is a cost to firewall rules like that as well. Who is going to maintain a list of all the IPs on the internet that are hosting DoH servers that could be used? What about the potentially more prolific proxies specified in this protocol enhancement? How does a network administrator keep all of those in sync with their edge networks? How does a home user?

Since DoH uses HTTPS there is no reason a service can't be multihomed on the same IP just like SNI allows multiple HTTPS servers on one IP. Would you be willing to block a legitimate website just so the applications on your network might fall-back to the name server you want them too?

You can snoop SNI and use that to block traffic, right? In another thread, someone suggested also stripping the keys for encrypted SNI from DNS queries which, when combined with a firewall that attempts to make a DoH query to every new SNI name it sees might potentially work.

For now. Encrypted SNI is in development and will eventually be used by devices and apps that want to do this sort of thing and hide what they're doing.

The solution to that is pretty simple. ESNI, I believe, requires encryption keys in DNS records: if you control DNS, you control ESNI. ECH might be harder to deal with, but you can always just block HTTPS connections you don’t want to support. Also, will some sort of certificate fingerprinting still work?

Well, adblock lists exist, DNS block lists exist, this is just something along similar lines that can be tested and aggregated and distributed. Not a perfect solution, but pi-hole as a router or similar could do it.

"If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc."

I wish it were that easy but it's very predictable that google will start resolving DoH on plain old "google.com".

So will everyone else ... it's not going to be malicious.userhostile.resolver.samsung.com, it's just going to be samsung.com ... so you can block it but you'll be blocking more than just the resolver ...

Grim thought, but surely they'd have to be serving from the same IPs?

Right, but do you want to block all access to google.com ?

I, and many users on my home network, use that site a lot :)

Blocking traffic for known DoH services would be trivial. How about blocking unknown, how would you block that?

Think out of the box: Just don't let the app connect to an IP it has not resolved a domain name for.

That's what we can do with the Portmaster (https://github.com/safing/portmaster). Check it out!

Thanks, I will check it out.

Trying to do content filtering on the kids chrome books for remote learning, I installed a pi-hole and was generally pleased with it. Then the kids (8 & 12) figured out to change the dns to cloudflare or google directly. I ended up having to add static routes on the router to block those paths.

(I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings...)

Any "how to" recommendations for setting up something similar? I have a pi-hole but after reading this thread I feel like im severely under-utilizing it.

I have blocked 1.1.1.1 and 8.8.8.8 and noticed some devices behave very badly, often crashing or restarting. Debugging the issue, once I removed the firewall rule they behaved normally. Almost all of the affected devices were google related, Android TV for example.

You can also DNAT all port 53 traffic to your resolver. Devices will think they are talking to 8.8.8.8 or whatever, but in reality they will ask your resolver and your filtering will apply.

Your filtering can still break these devices.

This only works as long as DNS is both unauthenticated and unencrypted.

Which, at port 53, it is.

Obviously, it would work with DoT (853) only with cert verification disabled.