Each application shipping with its own DoH resolver - spearheaded by browser vendors in the name of security - will put a lid on that.

They are rightly saying that DoH will secure requests from tampering --- but when it's the owner who's doing the tampering, it becomes yet another anti-user security feature.

Personally, I'm less concerned about privacy of DNS queries than the loss of control and need to have another centralised third-party in the process.

It was a bad security feature anyway, easy to bypass

On Firefox it is configurable or even disablable trivially. Much ado about nothing.

That doesn't mean the other apps which use DOH will also be trivially configurable to disable it.

This is exactly correct. The purpose of DoH is two-fold; for Google, to allow themselves to be the endpoint DNS resolver so they can both bypass local ad blocking and collect statistical behavioral data (I am aware that their policy does not permit them to do this; it will certainly not be the first time Google violates their stated policies in the mission of serving advertisements), and for e.g. Cloudflare, to centralize and control additional pieces of previously-distributed Internet infrastructure (and thus permit centralized monitoring not if but when they are compelled or subverted by the intelligence community).

Mozilla I don't understand. The most likely explanation appears to be that they are still in a catch-up-to-Chrome mindset, which is a disservice to themselves and their community.

DNS queries should be encrypted. Centralization-by-default is not the answer and people should look more closely at the incentives in play by those pushing the DoH standard. I appreciate the efforts of e.g. OpenBSD to prevent this side-channel leakage of user data to private corporations: https://undeadly.org/cgi?action=article;sid=20190911113856

> Mozilla I don't understand.

Mozilla also send tons of users data to Google, and, probably, gets money/better contracts/other benefits.

Proof: https://twitter.com/jonathansampson/status/11658588961766604...

A good DoH feature is that it distrusts the local network's services in favor of ones on the local device. Especially with Comcast, Verizon and others doing bad stuff with traffic, not trusting the network providers looks like a good thing.

Ideally one could change to any range of DoH resolvers - right now there's 3 or so.

DoT and running your own recursive resolver is better still.

Or if you work at an ISP, set up an alternative DNS that users can opt out of, for blocking telemetry for everyone except those that really wants it. Invert the playfield so to speak.

I'm glad I'm not the only one concerned about this.

As far as I'm concerned, Google are only interested in DoH so far as prohibiting DNS level adblocking within their walled gardens.

Everyone thinks they're working toward tamper proof connections for the benefit of users, but it's really for the ad companies IMO.

And manufacturers. I tried to install system-wide cert on my Android to intercept and see exactly what system apps on my old Nokia phone were sending to Chinese servers but couldn't because Google thoughtfully "protects" its users. Tivoization at its worst.

jup, I am concerned as well.

cloudflare DOH fortunately uses it own domain for dns, so you can block it at firewall level.

Google could be evil and make resolver "google.com", so you would have to block whole google.

I was talking to a few people, of creating a list of all public doh servers, so we could all use it on our firewalls to block them.

That doesn't help if ad companies and other attackers set up their own DoH resolvers.

That's why I've installed a MITM proxy for all HTTPS connections over my LAN.

Last time I put a large list of blocked domains in my /etc/hosts file, it was causing non-trivial amount of delay (hundreds of ms) to every dns lookup. I guess hosts file is not designed to be scalable. I ended up running a local dns server (which able to use those blocked domains list without noticeable performance hit). These day I just use pi-hole running on a spare raspberry pi.