DNS without DoH, DoT, or DoQ, is wide open to anyone snooping traffic in the raw, that’s not necessarily information you want to share with the world.
If somebody is on your local network capturing packets or they've cracked your wifi you've got bigger problems than your DNS leaking a list of domains. They'll also see the IP of every server you visit online anyway
The way DoH is implemented usually means that all of your DNS traffic is collected by some third party for-profit corporation like cloudflare anyway (who admittedly will already know most of the domains you visit anyway because of how often cloudflare's IP space is where DNS will point you).
There really aren't any good options for DNS and privacy, just a lot of compromises. Host your own. Or, if your ISP is trustworthy, you might be better off using what they provide. The DNS traffic between you and your ISP's servers should never leave their network.
People were setting their DNS resolver to custom values before DoH.
I agree that DoH would ideally be enabled at the OS level, or that the browser flow would default to still checking host file before sending out the query.
The browser should respect the OS. The OS should respect the network (dhcp/slacc). If you want to override this then that should be an active choice by the user.
I am quite happy with my OS using normal dns (via WireGuard when out) to my dns server which blocks bad domains before they even reach my firewall, I don’t need DoH, although I have no problem with that as a concept.
What I don’t like is my browser taking away my choice and breaking the model. It should defer to the OS (and I can’t see any time I wouldn’t want it to defer to the OS)
As for DoH, you can choose not to use it, or use your own DoH server. I see no problems with it.
There were other encrypted standards(dnscrypt for example) that didn't require you to do that, but the one that bypasses the OS was forced by adtech monopolist in charge.
> but the one that bypasses the OS was forced by adtech monopolist in charge.
Assuming by “adtech monopolist in charge” you mean Google, I don't think taking control from OS would benefit them given they effectively have control of more than two thirds of the mobile market share globally¹ so they are shooting themselves in the foot as much as anyone else – so I assume there are practical reasons², or purely technical ones, for DoH being their preferred choice (assuming that are pushing a preference).
And anyway, there is nothing that says applications have to implement DoH instead of letting the OS do that, Chrom{e|ium} and FF have gone that way in part because base OS support wasn't (isn't?) commonly available/enabled.
----
[1] A less than two thirds if you only count the US, as some published figures do, because Apple does rather better there compared to global averages.
[2] isn't dnscrypt's standard still officially a work-in-progress?
However it wasn’t, and it doesn’t defer to the OS or the network. I can’t set a dhcp option on my network to tell my dozens of clients what dns server to use, I have to manually adjust each browser. I additionally get different reaults depending what I use, my browser will contact a different server than any other application.
That’s broken behaviour which benefits AdTech companies like Google.
But at that point, you are effectively the ISP trying to control how users do DNS, in a way that might enable you to track/block/redirect. You might be trustworthy to your users so that is fine, but that isn't the case for every user's relationship with their service providers.
Is there an arrangement that would stop less trusted networks from tracking/redirecting/blocking DNS requests without (accidentally) helping AdTech by making DNS-based blocking harder?
First, you can disable encrypted DNS, second you can set up your own DNS server and setup browser to use it. And your own DNS server will respect DHCP config.
Personally I would like OS to completely ignore DHCP config (like proxy or DNS server address) because those features can be misused for malicious purposes.
In the case of mobile apps, it is.
You can MITM the traffic, and continue to deliver the traffic using a self signed certificate that you’ve trusted on your mobile device, and boom, you can capture the traffic at your proxy point and be happy.
A lot of mobile apps use certificate pinning to ensure that the backend certificate matches what the app expects. Now your self signed certificate, even though it’s trusted at the OS level, no longer matches the certificate that the app is expecting, and no data is exchanged after TLS handshake fails.