[dredmorbius]

If your (on-LAN or otherwise under-your-control) DNS server talks DNS-over-HTTPS, Mozilla can just talk directly to it. That's the point. The browser-specific option can be used where that's not viable or reliable (mobile devices, third-party networks).

And devices are handed DNS servers (with the option to opt out) via DHCP when they connect to the LAN.

[throw0101a]

Okay, and if malware uses DoH to figure out how to connect to its C&C server, how do I stop that DoH request (given it looks like any other HTTPS request)?

If Cloudflare starts serving DNS traffic from HTTPS on its CDN, the malware can use Cloudflare for DNS. Am I supposed to block all of Cloudflare's IPs because they can be used to circumvent DNS query monitoring?

[dredmorbius]

That's a separate threat model. DoH addresses surveillance, censorship, and injection by ISPs.

One DNSmasq already addresses in part through various asblock and malware-blocking DNS blacklists. I'm using one such that updates hourly or better. Requests to or for specific domains my be blocked (and are).

Keep in mind that by using DNSmasq at a centralised LAN server, you now have a single point of control to defend against such threats, rather than relying on multiple device- and application-specific points of control. Though software (such as browsers) offerring its own defences against such threats is in no way hindered.

You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware. At the OS level, firewalls such as Little Snitch monitor and block traffic at the application / process and user level, and may detect, alert on, and/or block such malware.

[throw0101a]

> * That's a separate threat model. DoH addresses surveillance, censorship, and injection by ISPs.*

As does DNS-over-TLS. Though since it has an official IANA port, this can be blocked.

> You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware.

And if malware leverages Cloudflare, am I supposed to block that? The ports associated with malware may be HTTPS.

[dredmorbius]

How does DoH make any of this worse than straight UDP/53 DNS?

You seem to be manufacturing a hypothetical threat that isn't actually impacted by DoH, to no clear end.

Malware already exploits specific IP spaces (DUL, datacentres, AWS), and ports (20, 22, 25, 53, 80, 443, ...), as well as vectors such as adtech networks, IFRAME, and XHR. Those are blocked as best as possible, leveraging numerous signature, to varying degrees of effectiveness.

Methods are not perfect. But if they on net reduce or manage risks more effectively, they're a net win.

Again, DoH, either in the browser or at the LAN level, addresses a specific set of known risks. And I'm not seeing the caveats you're suggesting as either more severe or non-mitigable.

[ubercow13]

Does this really matter? I am sure there are other ways malware could work around DNS blocking if it was motivated to

[throw0101a]

It depends on the malware. If it's self-contained and only goes around encrypting things and then prints a message to send money to a pre-defined particular Bit Coin address, then it won't matter.

If it needs to phone home or otherwise contact an outside address (excluding hard-coded IP addresses), then presumably it needs it needs to do a DNS look-up at some point.

Many botnets use pseudo-random DNS domains, and when the generation algorithm was figured out, people were able to get control of it:

* https://en.wikipedia.org/wiki/Botnet#Domains

* https://en.wikipedia.org/wiki/Fast_flux