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.
@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...
@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 :)
Generalistic Mastodon instance for open-minded people. Instance Mastodon généraliste pour personnes ouvertes d'esprit.