> The basic IT mantra has been 'If it aint broke, don't fix it.'
An unencrypted protocol that compromises privacy may not be "broke" for sysadmins, but it is for users.
Also, if your internal resources are using publicly trusted SSL certificates, the domain names are already being broadcast to the public thanks to Certificate Transparency. If you’re sophisticated enough to run a private CA for them, then you’re probably sophisticated enough to set up use-application-dns.net as well – though I still wouldn’t recommend ever treating domain name secrecy as a meaningful security boundary, considering how many ways they can be leaked. The remaining possibility is that your internal resources aren’t using SSL at all... in which case you have bigger problems than domain name leaks.
Firefox tries DoH via Cloudflare, for an internal domain that returns NXDOMAIN (Cloudflare can't answer for your internal resolver,) then they fall back to local resolvers, which is OS based (DHCP or statically set.)
The response time to complete the internal request goes up, because you're sending data to Cloudflare, they can't find it, then the 'normal' response time for internal resolvers.
Edit: Made more clear.
For 99% of users, that means they can't.
Luckily for them, they probably aren't allowed to use Firefox anyway, and are stuck using Edge or whatever, and the local MCSE will use this as another reason why Firefox may not be used by anyone.