[tsimionescu]

While the gist of your post is spot on, I do feel it should be noted that DoH is preferred over DoT not to protect from middleboxes that don't work properly, but from middleboxes that are actively trying to outright censor encrypted DNS, but can't afford to snoop on/prevent all HTTPS traffic. It's an anti-censorship measure, not a compatibility measure.

[capitainenemo]

It's also about user privacy with ISPs as well as anti-censorship. https://www.cloudflare.com/learning/dns/dns-over-tls/

[tsimionescu]

DoT (DNS over TLS) would have been enough for privacy from your ISP, using a dedicated port. It's only when you want to protect from censorship that you need to hide the (encrypted) DNS traffic among other traffic that can't be easily blocked.

[nickburns]

Security through obscurity is not the same as actual concealment. That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted.

Many LAN operators conclude that the pragmatic impossiblility of blocking DoH is a net-negative for both network security and censorship avoidance.

[tsimionescu]

> That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted.

Of course there is. Blocking all traffic with destination port 443 is virtually impossible. Conversely, blocking port 853 is trivial, and it forces all clients to either not resolve DNS, or downgrade to un-encrypted DNS.

Of course, if DoH had not been encrypted, it wouldn't have mattered that it uses port 443. But being encrypted yet easily identifiable would have also defeated half the point.

[nickburns]

You've sidestepped my point and merely reiterated yours.

Both DoH and DoT achieve actual concealment (and therefore privacy and censorship avoidance) through encryption. That one is more obscure than the other doesn't change the fact that the whole point of both protocols is encrypted DNS queries, not obscured DNS queries.

And again, if I'm the network operator and a host can obscure/obfuscate its DNS queries, then I've lost some measure of control over my network and the hosts that connect to it. I can trivially redirect all TCP/853 traffic to my DoT-capable resolver of choice. I can't do the same for all TCP/443 traffic (i.e. redirect it to my DoH-capable resolver of choice).

I don't care that an eavesdropper can observe discrete TCP/853 traffic because it's encrypted. The whole point is maintained, and I've maintained control over my private network.

[tsimionescu]

I guess we're generally in agreement on the facts, just looking at this from different sides.

You're mostly commenting on the negative effect that DoH has over a private network administrator's legitimate need to control DNS resolution in their own private network.

I was discussing how DoH has positive effects on a network user trying to evade illegitimate control over their DNS resolution on the Internet, such as legally enforced DNS-based censorship of certain sites. Several countries have legally mandated ISPs log and prevent resolution of, say, thepiratebay.com; and some include a requirement to prevent attempts at circumvention of these bans, such as DoT traffic (they might also ban DoH traffic to well known resolvers, which is where own proxies come in).

Regardless, I think we can both agree that DoH was not created to work around ossification, the way QUIC was built on top of UDP instead of being a separate transport.

> I don't care that an eavesdropper can observe discrete TCP/853 traffic because it's encrypted.

Also, this is another level of miscommunication. I agree you don't need DoH to protect from eavesdropping, DoT works just as well. DoH protects from ISPs dropping easily-identifiable DoT packets to force a downgrade to regular plaintext DNS.

[bcrl]

Some ISPs do run DNS servers to improve performance for their customers, not to snoop on them. My company is one of them. Being able to answer DNS queries in <1ms is far superior to the 8-25ms of latency over the transport network to the nearest peering point, especially when most clients are hitting the same names over and over. It's not like any of the public DNS servers are more trustworthy.