Games run a subset of network connections: Consumer Homelines.
They don't run in corporate networks, over public wifi or over mobile networks, all three frequently block non-standard ports (my city's free wifi blocks everything except 80 and 443, DNS is hijacked).
These three network types are also important, maybe more important than simple home landlines since they affect the people paying shitloads of cash or represent a very significant marketshare.
Besides public wlan this isn't an issue. In corporate networks it may be company policy to use their resolvers. External resolvers might not work for internal names, so their use is probably limited in the first place.
Mobile networks should allow all ports, if not call your regulator.
So 1 out of your 3 are actually important. Also, firewall rules can be changed.
I'll give you corporate networks though that's more guesswork than actual hard data on that. Plus point still stands that other protocols will be blocked unless using 443 or 80 ports.
Mobile networks in my experience block a variety of protocols and intercept DNS fairly regularly, even in presence of DNSSEC or DNSCrypt. Not sure what calling the regulator would give me, they're not responsible for what ports the network blocks. Not every operator is in the US, a majority of people do not live in the US and may want to use the internet without the operator playing around in DNS responses.
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.