Privacy.

Query statistics is valuable data you can sell. Client DNS queries are in that regard similar to search queries and a default search engine setting, you can sell that to the highest bidder. So browser makers are incentivized to implement their own resolver with its own set of DNS servers instead of just the system ones. Either because they want to sell those statistics themselves. Or because they want to protect their users from the statistics collection of the underlying OS resolver or ISP resolver.

Android privacy tools are leaky (which is bad given it's privacy tooling, you don't want that to leak!) Their VPN tools on OS level are pretty notorious for not properly respecting kill switch settings[0].

That alone makes a native browser implementation a better solution than the OS version.

[0]: https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the... is just one example I found on Google (in this case, using the C function getaddrinfo bypasses the tunnel entirely, which Chrome in particular uses for DNS queries - only android API calls respect the tunnel), but you hear about stuff like this every couple years; in that post they also link to a prior incident where connectivity checks and NTP updates were conveniently not using the VPN even when killswitches are active. Neither of these incidents have been fixed as of the time of writing (and Google explicitly doesn't consider conncheck/NTP calls occuring outside of the VPN tunnel to be a bug.)

I thought Android only supported DNS over TLS, so at least this opens up options for people.

First not all Android versions do that, and not all vendors implement that. Not everyone is running the latest version and has a Google Pixel. Second passing from the OS is less secure since there are a multitude of actors, Google, the device vendor, eventual VPN app, etc. that could get access to that queries (in fact apps to block ADS such as ADAway if you don't have root use VPN functionality to intercept DNS queries). In the end if you want to be safe better not pass from the OS in the first place.

Android does same-provider auto-upgrade if it determines that the recursive supports DoH (last I checked, if it's on Google's list). However, this means that unless you configure your own resolver, you're vulnerable to whoever controls the network substituting their own resolver. Firefox uses a set of vetted and pre-specified resolvers ("trusted recursive resolvers"), so is less vulnerable to this form of attack. I say "less vulnerable" because by default it will fall back to the system DNS on failure, but you can configure hard-fail.

You may or may not think this is a better design (I was one of the people responsible for Firefox doing things this way, so I do), but hopefully this explains the difference.

See: https://educatedguesswork.org/posts/dns-security-dox/ for more on the difference.

Mullvad runs a privacy-oriented DoH service, which is free to use regardless of whether you use their VPN service.

https://mullvad.net/en/help/dns-over-https-and-dns-over-tls

I like quad9

For Germany/EU there is ffmuc: https://social.ffmuc.net/@freifunkMUC/114087819103432120

Hopefully we will see more regional DOH providers instead of centralized ones.

For those wanting a bit of privacy, you can run your own DOH server[0]. Be aware that the upstream requests can still be tracked, but additional safety steps can be taken such as hosting your own dns resolver (bind/powerdns), sending dns/doh queries over a vpn or tor connection, or spanning queries over multiple sources. Each has its own security and privacy implications, which is beyond the scope of this comment :)

[0] https://github.com/DNSCrypt/doh-server

Wikimedia runs an experimental DoH server, see: https://meta.wikimedia.org/wiki/Wikimedia_DNS

NextDNS is great

One approach to mitigate this is to spread the queries to multiple DoH providers: https://www3.cs.stonybrook.edu/~mikepo/papers/k-resolver.mad...

Actually, DoH doesn't change the situation here one way or the other, it's just a transport. It's true, that Firefox's approach to DoH ("trusted recursive resolver") does. centralize traffic some, but DoH need not be deployed this way. For example, Chrome does what's called same provider auto upgrade, which doesn't change the resolver, but just tries to use DoH if available.

Hey, just wanted to say thanks for your work on Waterfox!

> DoOH

How is the latency?

But if that request is going to a large provider (GCP, AWS, CloudFlare), without the hostname, the request is going to be close to meaningless for the snoop.

The promise is especially dangerous when a huge fraction of traffic doesn't use Encrypted Client Hello, [1] so the domain name is sent in the clear with the initial request to the server.

A while back I wrote a quick proof-of-concept that parses packet data from sniffglue [2] and ran it on my very low powered router to log all source IP address + hostname headers. It didn't even use a measurable amount of CPU, and I didn't bother to implement it efficiently, either.

I think it's safe to assume that anyone in a position to MITM you, including your ISP, could easily be logging this traffic if they want to.

[1] https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypt...

[2] https://github.com/kpcyrd/sniffglue

I don't have any issues with it. NoScript and uBlock Origin are working fine for me.

That's pretty harsh. It works fine for me. But even if it didn't, I'd still use it just for uBlock Origin.

Edge canary runs on android with full extension support?

Outside of IP-blocking known popular DoH hosts (e.g. https://github.com/jameshas/Public-DoH-Lists, and even then it's not the best since there's overlap with popular DNS hosts like Cloudflare), there's no good way to do it without break-and-inspect. That's because DoH is TLS traffic over 443, just with DNS inside instead of HTTP.