> A normal middlebox can't even tell the difference between DoH and DoT because they both just look like TLS.
You forgot the "let's intercept in a public place (e.g. public Wi-Fi hotspots)" one where blocking port 853 is super trivial while blocking port 443... is impossible. Sure, Google DNS will be blocked easily but there a lot of DoH providers!
There's a ton of minor ones, it's easy to spin up your own, and the hope is that eventually, with ECH, it won't be possible to block them without blocking basically the entire Internet like North Korea does.
Malicious DNS in terms of returning bad results is generally irrelevant because if you can't trust the network then returning the wrong IP address and routing the right IP address to the wrong server are the same. Also, you're using HTTPS/TLS/SSH/etc. on the actual connection anyway, right?
So the point of this is to prevent Comcast from seeing your DNS queries. And then it works fine to trust the network to say "no, really, use this one and not the default DoH one" as long as that setting is one that Comcast would get in trouble for misusing. Notice that they don't return bad results for use-application-dns.net as it is.
At that point you might as well use DoH. But you're also reasoning axiomatically about something we have a lot of documentary evidence for: the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
What benefit is the additional complexity and overhead of HTTP buying you there?
> the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
This is one of the main issues here: When then DNS operator is you, i.e. your local network at home or your corporate network within your own company, you should be able to control DNS on your own network, which you can't if a bunch of adversarial devices are bypassing your DNS servers.
When the DNS operator is your ISP, letting them block encrypted DNS is bad.
So what we need is some way to distinguish between these situations so that the local network administrator's preferences are heeded but Comcast can go pound sand. But browsers are too late in the stack for that because they have no way to tell if the system DNS server is the one the user wants or the one they got by default from their ISP and never knew to change.
I don't think we need any way to distinguish these situations any more than we needed to preserve the non-ephemeral key exchanges in the jump from TLS 1.2 to TLS 1.3, which were opposed for the same reason. You can control which computers you allow on your network, and allow only computers which give you endpoint monitoring. The 2025 TCP/IP protocol stack should not be going out of its way to give network operators more visibility into what applications are doing.
> You can control which computers you allow on your network, and allow only computers which give you endpoint monitoring.
This would be a great argument if it was actually feasible, but then you have Chromecasts hard-coding Google's DoH servers to prevent ad blocking etc., and devices doing automatic firmware updates to change things like that after you've already bought them.
Pass the law that says the customer has to be given root and the ability to install custom firmware on any device they buy before saying that is reasonable.
You're not going to get either of those things. The market has converged on DoH and applications will continue to run it, and you're not going to get a law giving you root on all the devices that go on your network. If you're concerned about Chromecast's DNS, don't hook up a Chromecast. I don't, and I'm doing fine.
Saying "the market" when you're mainly just talking about Firefox and Chrome implies that it couldn't be changed just by convincing a small set of specific people.
And we'll yet see about that law. Right to repair is pretty popular.
You forgot the "let's intercept in a public place (e.g. public Wi-Fi hotspots)" one where blocking port 853 is super trivial while blocking port 443... is impossible. Sure, Google DNS will be blocked easily but there a lot of DoH providers!