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.


(boosts/sharing welcome)

> Networks that have implemented some sort of filtering via the default DNS resolver. This can be used to implement parental controls or to block access to malicious websites.


Modern Mozilla at its fucking finest. Somebody decides to make a brave step in favour of Internet freedom, and then somebody else comes along and neuters it to protect their fucking market share or something.

@restioson because the DNS provider can’t tie DNS lookups to IP address.

@qyliss I'm interested. I only have a vague idea of what DNS is and how it works, and I'd really like to learn more

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

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

@qyliss So, it seems like the only pro argument for DoH is currently directly circumvented by support.mozilla.org/en-US/kb/c
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

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

Sign in to participate in the conversation

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!