[nykolasz]

First, I think it gives too much power to the browsers. Firefox was already taking some dangerous choices with DNS over HTTPS on some of their recent changes. Chrome as well, doing changes that will benefit Google, in detriment of the rest of the web.

Second, I think it is an overall bad design choice to tunnel a lightweight protocol on top of HTTP on top of TLS. Instead of just tunneling it under TLS.

[jrockway]

I don't really see how encoding a DNS request as HTTP gives extra power to browsers. What power do they gain by writing "GET www.example.com" after a TLS handshake with port 443 versus writing "1234 0 0 0 0 1 0 0 1 0 0 0 ..." after a handshake with port 53?

Browsers can already do whatever they want to the URL you type in. What DNS packets look like does not add or remove any power.

Meanwhile, https isn't exactly heavy, and it's very well supported by everything. Every programming language has an https library. Writing an DNS-over-HTTPS program will be 3 lines of code.

[dagenix]

> First, I think it gives too much power to the browsers. Firefox was already taking some dangerous choices with DNS over HTTPS on some of their recent changes. Chrome as well, doing changes that will benefit Google, in detriment of the rest of the web.

I really don't understand how DNS-over-HTTPs benefits Google to the detriment of the web anymore than over TLS would. I'm not really sure how either hurts the web.

> Second, I think it is an overall bad design choice to tunnel a lightweight protocol on top of HTTP on top of TLS. Instead of just tunneling it under TLS.

Port 443 is generally unblocked. Port 853 is often blocked. How does tunneling via HTTP on port 443 hurt anyone? Yeah, it's ridiculous, and, a result of ridiculous middle boxes imposing silly policy. But, if you can't change that (and you can't), then, what is the harm? A few wasted bytes? So what? As long as it still fits in a single frame, it still a single round trip on the network.