Since Mozilla and Google announced, that they intend to activate DNS over HTTPS in the default settings in the future and the IETF approved officially the draft (https://datatracker.ietf.org/wg/doh/about/), I tried to understand the impact on our corporate network. It is now possible for every application to bypass the internal DNS Server (assigned via DHCP) and directly connect to a public DNS service. There is no easy way for an administrator to prevent application and users doing this, since all traffic is routed through HTTPS.
In most corporations that I know, there is a split DNS setup in place, allowing internal (intranet) and external (internet) name and IP resolution for the same domain name (e.g. mail.mycorp.example) with different resolve values. It also allows to add additional, intranet only, services like wiki.intra.mycorp.example, that would not be resolvable/accessible from the internet. Same goes for infrastructure names like server01.eq.mycorp.example.
The problem I see is, that if the application itself is preferring DNS over HTTPS and is not correctly falling back to the system assigned DNS servers, internal only domains would not be accessible.
I made an experiment with Firefox 61.0.1 (64-Bit) on Windows 10. I have set:
network.trr.bootstrapAddress= 1.1.1.1network.trr.uri=https://mozilla.cloudflare-dns.com/dns-querynetwork.trr.mode= 2
network.trr.mode = 2 should prefer DNS over HTTPS, but fallback to system DNS if no value received, mode = 1, which I also tried, should make a race and use the first valid result that Firefox gets back.
Unfortunately, after activating DNS over HTTPS in Firefox, all internal only websites did no longer work. All requests end in a timeout and fail therefor.
What do I miss? Is there a better way to handle internal only DNS entries in future setups?
The exact configuration you described works in my corporate network. It first tries DoH for internal sites, then falls back to local DNS and internal sites resolve and load correctly.