[deeter72]

This is why I absolutely despise DoH. SysAdmins have no direct control over it. In my organization we have blocked direct IP access from userspace VLAN's to all known public DNS servers thus forcing all clients to rely on the company DNS servers, which is not the most ideal way to do things.

[yjftsjthsd-h]

Don't you just set a canary domain - https://support.mozilla.org/en-US/kb/canary-domain-use-appli... - and then it's disabled for your network?

[deeter72]

Again not the most ideal way to do things and Mozilla is doing a different approach to Chrome and Edge. and also a concern is that malware can use DoH to retrieve data without logging suspicious DNS queries on Firewall DNS logs which are monitored to highlight of new domains that have not been pre-approved.

DNS should be something that is handled by the OS. I favor DoT which is secure and practical over DoH.

[jlgaddis]

Actually, in that case, adding the canary domain to your existing Microsoft DNS servers probably IS the most ideal way to disable Firefox's DoH support.

Alternatively, you can roll out a Group Policy or use Mozilla's "Enterprise" policies to do it.

Hopefully you're also blocking 53/TCP and 53/UDP outbound (except from your internal DNS servers).

[jefftk]

> malware can use DoH to retrieve data without logging suspicious DNS queries on Firewall DNS logs

Malware can already query IPs of its choice to learn about other IPs it should contact. DoH doesn't let it do anything new.

[jlgaddis]

In a corporate network, it's pretty common to block all outgoing DNS traffic (53/TCP and 53/UDP), except from the company's DNS servers.

In that case, DoH does let malware do something new -- block the company's existing DNS policies, quert logging, and security monitoring!

[jefftk]

DoH is a protocol for using HTTPS to learn what IPs to talk to.

Malware does not need DoH to do this. They can simply run an ordinary HTTPS server with a self-signed cert on an arbitrary IP, with a simple JSON-based or whatever protocol, and have support for that in their client.

[jlgaddis]

> Malware does not need DoH to do this.

Yes, you're right, of course.

There are any number of things that malware can do. Most of it doesn't, however, and can either be stopped completely or, at the least, detected quite easily using some basic techniques.

[topranks]

Not really.

Malware could always use some proprietary wrapping in TLS to hide name resolution.

Domain fronting through Azure is still a thing for instance.

[speedgoose]

Why do you want them to rely on the company DNS servers?

[jlgaddis]

1. Internal names won't resolve if a client is using, for example, 1.1 as their DNS server (breaking, among other things, logging on to an Active Directory domain!)

2. Many companies have established DNS logging and monitoring in place for security.

[deeter72]

Active Directory, Internal Domains, monitoring, blocking, etc.

[topranks]

Policy.

Not sending my private browsing data/DNS history to a third party (Cloudflare, Google etc.)