"That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy."
This is a very good point and I am dealing with this myself on my home networks.
Like any household/family we have some number of dubious/untrusted devices that still need Internet access.
By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.
DoH breaks all of this.
I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them".
Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ...
This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...
> By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.
This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective.
> Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP that initiates a new connection, outbound, from your network - and then block all IPs that answer your DoH query.
It doesn't solve the CDN problem: CDNs will route traffic based on the hostname and blocking them will have a degree of collateral damage which most people can't work with. Setting up your own HTTPS proxy avoids this.
"This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective."
If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers.
That kind of control is what DoH breaks and I'd love to find an elegant (non-MITM proxy) solution for it ...
There isn’t an effective solution for a device which ignores local network policy other than returning it so the manufacturer pays the cost of designing a bad system.
With the side effect of your local vendor refusing to do further business with you, "the problem customer", with your "unreasonable demands" and technobable.
DNS over HTTPS has been a thing since before IETF standardized it, the technique was just in the form of a non-standardized API running on some benign domain.
Thinking about it, if you’re willing to give up TLS 1.3, you could probably just break all https connections with encrypted SNI and then filter based on the SNI information.
Just to nitpick: TLS 1.3 still uses plaintext SNI by default. You need to explicitly put public keys in DNS to enable the encrypted SNI extension.
And in the context of pihole and such, avoiding that means editing the DNS response to remove those public keys. Which takes us full circle back to "do I control DNS for this gadget, or not".
This is a very good point and I am dealing with this myself on my home networks.
Like any household/family we have some number of dubious/untrusted devices that still need Internet access.
By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.
DoH breaks all of this.
I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them".
Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ...
This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...