I have not yet seen an argument against DNS-over-HTTPS that does not amount to “but how will we spy on the people we provide a service to?”

So I think that means it’s working :)

Network operators have no right to know or monitor what people are doing with the utility service they provide.

If you can’t trust them, either make it so you don’t need to trust them, or find trustworthy people and trustworthy (by means of being free) software. Spying on them is never okay.

(although I recommend DNS over TCP over Tor as the best way to preserve privacy when using DNS, if you’re actually going to implement it yourself)

I think I’m sufficiently mad about the state of DNS discourse that a DNS privacy blog post is incoming. Stay tuned.

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.

alyssa.is/proposing-dns-over-t

(boosts/sharing welcome)

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

Follow

@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 :)

@eqe @qyliss incidentally I believe this is at least partly how Cloudflare's load balancing works.

Running comparatively long-lived protocols like HTTP over anycast is fraught with issues though, and I'm not sure it's public knowledge how CF makes it work so well.

@eqe @qyliss also anycast routes bloat the global routing table so there's a fair argument that this is not something everyone should be doing.

Sign in to participate in the conversation
Mastodon

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!