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.
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.
> 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.
It had everything to do with it, as more and more is being forced through HTTPS, because I don't know, it's more secure or it's the only port not being filtered. There were a few times I has to run sshd on port 443 (on a server I control---a preventive measure) because a network I was forced to use (a "public" wi-fi) only allowed ports 53, 80 and 443 outbound.
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.