2

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.1
  • network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
  • network.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?

Daniel Stenberg
  • 54,736
  • 17
  • 146
  • 222
kwinsch
  • 59
  • 1
  • 6
  • 2
    Your question is not very much relate to programming which is the topic here. You may get better answers on [sf]. – Patrick Mevzek Jul 25 '18 at 18:24
  • I think that when you see "prefer DNS over HTTPS but fallback to system DNS" it means the fallback happens if the DOH server does not reply at all. IF the server replies "NXDOMAIN" this is a valid reply and the consumer has no reason to fall back to another server and do another query. This is confirmed in documentation: *2 - First. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.* Name resolution failure is different from NXDOMAIN reply. – Patrick Mevzek Jul 25 '18 at 18:25
  • Use of (external) DOH is typically because you do not trust your local DNS resolver or you do not trust the path from you to the resolver. In case of private networks managed by an organization why would an employee configure its tools to use an external DOH server instead of the local one(s) managed by the organization he is working for? This at least may leak sensitive data out of the network. While I would technically be difficult to completely forbid it, your network policy could clearly state against it. – Patrick Mevzek Jul 25 '18 at 18:30

1 Answers1

0

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.

Brandon
  • 1