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.

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

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

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

That would explain DNS over TLS on port 443, no HTTP needed.