Hacker News Reader

Comment by pjc50 | Hacker News Reader

This is the dark side of DNS-over-HTTPs: it prevents the network operator from changing what is received by browsers. Sometimes this is legitimate, as in Pi-hole.

Paul Vixie got very upset when he discovered that his chromecast bypasses local DNS settings to go directly to Google: https://news.ycombinator.com/item?id=19170671

I wouldn't be surprised if soon Chrome defaults to DNS-over-HTTPs direct to base, except for the corporate intranet version. They just need to work out how to deal with wifi captive portals.

View on HN

The problem is two mutually incompatible use cases:

1) trusted endpoint / untrusted network (laptop in a coffee shop)

2) untrusted endpoint / trusted network (chromecast/alexa/other corporate zombie on your home network)

Which category a given scenario falls under depends on who you ask - to Google, Chromecast is in the first category. I don't know if it's possible to design a system that somehow always favors the rights of the individual.

> I don't know if it's possible to design a system that somehow always favors the rights of the individual.

This is why people keep objecting to technological solutions to social problems. Adblocking is a stopgap technological solution (although very effective at the moment); properly protecting the rights of the individual requires a social and legal process.

I disagree. Technical solutions are largely preferable. Political solutions are feeble and can be changed on a whim.

If the NSA has the capability to sniff vast amounts of network traffic, encrypting that traffic is a much stronger defense than telling the NSA they aren't allowed to deploy the capability for the time being.

If Chrome insists on using its own DNS or removing the adblocking API for add-ons, one can just use another browser like Firefox that has the desired technical capabilities. Managing DNS lookups and HTTP requests are not "stopgap" solutions, they are basic functionality that any one entity can't eradicate.

Damn, this is a good point. Just because of network architecture, ultimately somebody-- either the client or the network-- has to have the Final Word on where DNS requests go, and either way opens people up to attacks depending on the scenario. If the client has the Final Word, you can't stop your Chromecast from talking to 8.8.8.8; if the network has the Final Word, you can't trust DNS on foreign networks or use your own resolver.

It's a big concern. I can block DNS on my network (except for pihole), but I can't block QUIC, and certainly not HTTPS or TLS. If I know about an IP ahead of time, I can block those, but who's to guarantee that Google or any other nefarious service would always use a well known IP for DoH?

How would devices use the obscure DoH IPs, there would have to be a method to update/lookup said IPs. That same method could be used to keep an up to date block list.

Alternatively, the traffic could be subject to heuristics to identify DoH connections.

could setup a small firewall (pfSense) that routes all DNS queries from connected devices to your own DNS server.

Not with DNS-over-HTTPs and certificate pinning you can't, because the certificate check would fail.

(That would be a very annoying thing to do in a device or browser, but it's certainly possible)

Exactly, the only choice is to root the device or return it as defective.

Reply on news.ycombinator.com