I wrote a summary of the DNS over TLS vs DNS over HTTPS debate (without going too much into the drama).
It also contains an introduction to my proposed solution, and why it’s better than either.
Mozilla what the fuck are you doing https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
@qyliss Awesome! You are a great writer.
@masterofthetiger wow, thank you very much!
@qyliss I'm glad you're thinking and working and writing about these issues!
One concern I have with all the proposals I've seen for don't-trust-local-dns is that they make many kinds of network optimization more difficult. For example streaming popular videos (netflix or whatever) should happen between the endpoint and a city-local cdn server, not longhauling the stream from Boston to Berlin just because that's where the DNS resolution happened. The last time I built a service with streaming in it, we found that local cdn nodes improved the user experience enormously.
There are ways around this impact, but they're all quite a bit of work, and I'd like to see DoX (dns over whatever) proposal discussions that acknowledge the challenges that will occur due to the proposed solution...
@eqe my naive idea would be to do this at layers above DNS. If, say, you have a web page displaying video, your web server could use the connecting IP to determine a nearby server to load the video from.
But interesting point that I hadn’t considered. Thank you.
@qyliss glad to be helpful!
One solution is for the cdn to operate with tcp over anycast IP, rather than unicast, so that the network-nearest server cluster can respond to a globally used IP. Back in the day you'd have an IP cluster for the Boston cdn and a different IP range for the Berlin cdn and use dns to send user requests to the right geo, but I guess the modern way is to have a consistent name-to-IP mapping and do the geo routing at the BGP layer instead. Doing this is a deep pile of black magic to most engineers, though. So I don't know if it's now standard in the cdn market or if only the more advanced ones do anycast.
The approach you mention is doable for media streams too, send a 204 or whatever redirecting the request to a network-closest server name. That has more round-trips at the start which is fine if your streams are more than a few dozen seconds. Might be a problem for Vine :)
@qyliss So, it seems like the only pro argument for DoH is currently directly circumvented by https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
I'd also think that it would be possible without problems to run DoTLS on port 443?
@momar Yes I don’t know wtf Moz is doing with that.
if you did DoT on 443, unless you could find some way to _also_ serve HTTPS on that port, it would be easy to check whether it was a DoT server.
@qyliss oh for fuck's sake, what are you even defending against anymore if you just hand your entire threat model an off button
@embr your ad revenue, presumably
@qyliss Do you say 'no' with network level censorship in mind? Because when I read that I thought about DNS resolvers that people might set up themselves for ad/tracker blocking
@mcol trivial to make your self-setup server DoH, and then you can block ads from anywhere.
@qyliss fair point
@qyliss I can't believe it took me until this toot to realize that DoH is going to completely fuck up my work situation (I use Firefox, but IT and nearly every employee uses Chrome, and we have many internal hostnames that don't resolve on the public internet)
@eqe by default it will fall back for non-public hosts, but if you don’t want those sent to CF you can also just disable DoH.
@qyliss DTT sounds like a genius idea. I love this.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!