DoH as a protocol has no issues with HOSTS files. The issue is browsers implementing DoH instead of operating systems. If browsers stayed in their lane, and let operating systems implement DoH, compliant with corporate IT design and systems like the HOSTS file, everything would be fine.

Microsoft has already committed to implement DoH in Windows itself. Browsers just need to stop trying to be their own DNS clients.

Mozilla's operating system bombed horribly, so the only leverage they have is with the browser.

OSs didn't implement it though. And they never would unless browsers forced it on them. The right approach is for browsers to bring it in and then when the OS supports it, default to the OS version. But right now I don't know of any OS other than I think android that supports it.

Yes, that's the problem.

> Meaning if you connect to a public WiFi network, many will only allow captive DNS and block other protocols including DoT. DoH is difficult to distinguish from other HTTPS traffic and is more likely to successfully resolve (since they cannot block HTTPS and still be useful).

Are you referring to HTTPS-intercepting proxies? (i.e., if you want to use that network, you'd also have to install a custom root CA cert)

On a typical "coffee shop" wifi (where users are not expected to install custom certs), shouldn't DoT and DoH be virtually indistinguishable to the network as they are both shielded by TLS?

> Are you referring to HTTPS-intercepting proxies?

No, I am referring to what I said. Public WiFi networks only allow their own DNS resolver and block all others and most other non-HTTP/HTTPS network traffic. This breaks DoT and even unencrypted UDP DNS to your choice of resolver (outside of the WiFi's captured DNS/Middlebox DNS).

A lot of free public WiFi today break DoT and work with DoH. DoH is indistinguishable from other HTTPS traffic, DoT and DoH are highly distinguishable from one another. DoT is trivial to block (often without even targeting it specifically).

Out of couriosity, do you know how they do it? Just port blocking?

> Therefore you've created a secure, flexible, and reliable DNS replacement with only mild technical downsides on modern hardware

One (semi-ideological) concern I believe is valid is that this makes it increasingly complex to understand which HTTP features can or cannot be used somewhere - and when writing a naive implementation, there is the risk of accidentally enabling features that are supposed to be disabled.

E.g., when WebSocket was developed, there was some discussion how much HTTP should be allowed in the initial handshake - specifically whether or not redirects should be followed: Formally, following redirects would seem reasonable as, until the handshake is completed, you are speaking "ordinary" HTTP, which redirects are a part of. Practically, though, it didn't make a lot of sense as the requirement would have added a lot of complexity to clients - even though no there was not even demand for the feature in the first place. In the end, I believe it was decided that the handshake is actually a tightly limited subset of HTTP and any server response except 101 is invalid.

However, last time I checked, browsers in the wild do send cookies and user-agent strings in the handshake, even though you could argue those have nothing to do with WebSocket either.

So with DoH, we now have another "dialect" of HTTP with its own subset of features: On DoH requests, the User-Agent header must be omitted and cookies must never be stored. I can already imagine future privacy exploits if some DoH implementations just used a standard HTTP library and e.g. forgot to disable cookies.

I believe using an actual custom protocol would make it a lot easier to understand which features are and are not available.

> DoH is difficult to distinguish from other HTTPS traffic and is more likely to successfully resolve (since they cannot block HTTPS and still be useful).

Considering that most users would keep default setting and there are two browsers with two default DoH servers, you could just block few IP addresses and effectively block DoH for >95% users.

> many will only allow captive DNS

That's an anti-feature, something one shouldn't even call internet access. Engineering entire protocol stacks around it sounds like enshrining it as if it were good practice.

It's reinforcing an inadequate equilibrium.

So you are left with the choice of making something that works right now and will provide enhanced privacy for everyone or attempting to fight middleboxes and corporate configs and see a similar rate of adoption as ipv6.

Once absolutely everything is running through opaque https requests we might see middleboxes go away since they aren't able to do anything anymore.

> So you are left with the choice of making something that works right now and will provide enhanced privacy for everyone or attempting to fight middleboxes and corporate configs and see a similar rate of adoption as ipv6.

Actually solving the problem is always better than enshrining it by providing an ugly workaround. Even if it takes more time.

Imagine how quickly IPv6 would have been adopted if NAT didn't exist. DoH is kinda like that, a cludge that ultimately hinders progress.

What you are most likely to see is more corporate deployment of middleboxes that MITM https requests and an overall reduction in privacy for those on corporate networks.