[dagenix]

Prediction: DNS-over-TLS won't win. I don't think it's going to be able to get around the non-standard port issue.

Instead, I think DNS-over-HTTP is gonna be the champ. The overhead of HTTP is a minor issue, but, I think using a standard port more than makes up for it. I think the real inflection point is going to be once QUIC is more widely deployed. Combined with TLS's 0-RTT connection setup, we'll be able to get back to answering a DNS query in a single round trip (like today), but with assurances that the data wasn't monitored or tampered with between the client and the recursive resolver.

[nykolasz]

I hope you are wrong. We don't need one more protocol tunneled through HTTP.

[djsumdog]

I kinda agree on this. It's like pumping everything into an electron app. Not everything needs to be pumped through 80/443.

[dagenix]

Do you want to not be blocked? That's a reason to go through 80/443.

[gsich]

Is this even an issue? Just look at games. They use various ports all the time. It still works. Don't optimize for crappy networks, it's not worth it.

[zaarn]

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.

[gsich]

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.

[dagenix]

Why? What's the specific harm? AIUI, as long as the request still fits into a single frame, its not anymore inneficient.

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

[spc476]

Why not tunnel everything over HTTPS then? Then even SSH will be secure!

[dagenix]

... which has nothing to do with what I'm talking about.

[spc476]

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.

[dagenix]

Yeah, thats annoying. That doesn't mean it's not also a practical decision.

[kromem]

Yeah, DNS over HTTP/2, (or the inevitable DNS over upcoming connection protocols) will definitely succeed.

I think the big paradigm shift is "let's decouple DNS interactions from a specific transport" - and once you open up to that concept, the option of having multiple transports for different use-cases as things move forward seems practical.