Hacker News new | ask | show | jobs
by profmonocle 647 days ago
> As much hassle as things like DoH can be for securing and enforcing policy on a network, it’s about time it became ubiquitous enough that governments can’t leverage DNS for their own purposes anymore.

A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Currently, most clients using DoH/DoT use one of a small handful of providers. Cloudflare, Google, Quad9, etc. A motivated government could block those endpoints pretty easily.

Of course, a client using encrypted DNS could just refuse to work when encryption is blocked, rather than falling back to traditional DNS. But that could mean the client is unusable in the country implementing the block.

This sort of reminds me of when Kazakhstan announced they were going to MITM all TLS sessions within the country, and all citizens would need to manually install a root cert. Google, Apple, and Mozilla chose to completely block their root cert, so it would be unusable even if users chose to go along with it. https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a... Seems like the browser devs won that political standoff, but would they fight the same battle if DoH/DoT was blocked?

4 comments

This is the way. Few governments have the resources to play cat and mouse with OS or browser devs. Just look at the fuss over manifest v3, it shouldn’t be a big deal - just fork chromium and patch manifest v2 back in again - but it is because there’s no “just patching” chromium, it’s like a train.
A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Currently, most clients using DoH/DoT use one of a small handful of providers. Cloudflare, Google, Quad9, etc. A motivated government could block those endpoints pretty easily.

not if DNS is hosted on the same servers as eg google search itself. then they would have to block google search in order to block DNS.

…or use higher-level packet analysis to filter DoH.
That kind of DPI is computationally expensive to the point China doesn't even do it much.
Not anymore and mainland Chinese manufacturers sell them on in large numbers to autocratic governments.

Such devices have a pretty simple architecture: the highly performant data plane where DPI is implemented in the hardware (using either ASIC's or FPGA's – don't have enough information), and the control plane. The control plane comes with a SDK of sorts that DPI appliance users can use to tailor the appliance to their environment and that is used to «refine» the data plane behaviour, i.e. sending down / updating DPI pattern matching / processing rules.

OMG, they very much do. It is not on 100% of the traffic but at any given time a more then smaller % is subject to DPI.
With HTTP/3 there isn't much higher level packet analysis to do between anything useful in the headers being encrypted and the session being reused. All you see is there is a 443 UDP session to a Google server and encrypted packets keep getting sent back and forth... which looks exactly like any other HTTP/3 session to a Google server.

I think the weak points are wholly untechnical e.g. Google would often give in to protect the $$$ they make in a region.

Packet size (i forget if http/3 does padding) and packet rates are still available, dns looks a lot different than most http content.
In terms of packet size, DNS (DoH) doesn’t really look any different to an XHR request.
Request maybe, DoH responses are probably way shorter than anything else though.
Then they will block Google Search and blame it on Google ?
> A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs.

Unencrypted DNS also has to be bootstrapped by a well-known set of IPs. None of the current DNS propagation system would work if it wasn't for the hardcoded IPs for the root DNS servers at *.root-servers.net.

And, of course, end-user devices still need an IP to query for DNS, it's just that it's almost always supplied automatically via DHCP or similar.

If we make sure clients support proxies what are they going to do about all the proxies that may allow the DoH server list and may be the only way to do something else?