1512255 - [meta] Handle split horizon DNS with TRR

Status: RESOLVED FIXED

(Core :: Networking: DNS, enhancement, P2)

Description

[Valentin Gosu [:valentin] (he/him)]

Split horizon DNS is common in enterprise environments, and it's unclear how to handle this with TRR. The user may encounter bad-cert errors, or may not notice at all over unsecure connections.

One option may be to disable TRR by default if there are _any_ enterprise policies set, requiring the TRR to be enabled through an explicit policy or user decision.

We also need to figure out how to mitigate the use case when devices aren't managed by the enterprise. We could retry on any error without TRR, or maybe something else.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

(In reply to Valentin Gosu [:valentin] from comment #0)
> One option may be to disable TRR by default if there are _any_ enterprise
> policies set, requiring the TRR to be enabled through an explicit policy or
> user decision.

Hi Mike, I see that you created the enterprise policy in bug 1484843.
Is it possible to have different pref defaults (or find out at runtime) if any enterprise policy is set? Thanks!

Comment 2

[Mike Kaply [:mkaply]]

Right now we're explicitly setting the prefs for DNSoverhttps:

https://searchfox.org/mozilla-central/source/browser/components/enterprisepolicies/Policies.jsm#267

We could switch to a model where we do something like this:

manager.disallowFeature("DNSOverHTTPS", true);

which would then allow you to query if the feature itself was enabled or disabled.

Disabling DNSOverHTTPS if any policy is applied does not seem correct (IT would disable it for new Mozilla employees since we use policy).

Policy could be simply setting bookmarks.

Is there no way to detect Split Horizon?

Comment 3

[Valentin Gosu [:valentin] (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #2)
> Disabling DNSOverHTTPS if any policy is applied does not seem correct (IT
> would disable it for new Mozilla employees since we use policy).

What I meant is: if there is no DNSOverHTTPS policy defined, but any other enterpise is defined, then we should default TRR to disabled. Otherwise it's whatever all.js or the user chooses it to be.

> Is there no way to detect Split Horizon?

Not as it currently stands. I've been brainstorming the issue, and the enterprise could either use captive portals to instruct the user to disable/whitelist(bug 1450893) it.

Another way would be, assuming the enterprise controls the domains involved in split-horizon, to add a TXT record for those domains that would amount to an opt-out of DoH for that domain. But that would require an extra resolve to get the TXT record.

Comment 4

[Mike Kaply [:mkaply]]

This sounds like a pretty big problem with DNSOverHTTPS in general? Leaking enterprise domains?

I will make sure it stays off on ESR, but I'm concerned about folks using Firefox in their enterprise without customizations.

But to answer your original question:

if (Services.policies.status == Services.policies.ACTIVE) {

Comment 5

[Valentin Gosu [:valentin] (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #4)
> This sounds like a pretty big problem with DNSOverHTTPS in general? Leaking
> enterprise domains?

For internal domains, that don't have a public DNS record, that might be an issue, which the policy should at least mitigate. But at least there would be no connection failures, since on failure we can retry with regular DNS.
For split-horizon DNS, the domains also exist in the real world, so there isn't a "leaking" problem, but it's very difficult to detect, which is why it would be good to avoid it.

> I will make sure it stays off on ESR, but I'm concerned about folks using
> Firefox in their enterprise without customizations.

Tough question. I think keeping it off ESR could be the best solution. If companies install release Firefox without customization, that's tough. And if devices are self managed, then that would be equivalent to a user manually setting their resolver to 8.8.8.8 (or similar), which again the company cannot mitigate.

> But to answer your original question:
> 
> if (Services.policies.status == Services.policies.ACTIVE) {

Thanks!

Comment 6

[Pas]

Hello!

Was there any plan to try to get the already configured/known DNS server (usually configured/provisioned via DHCP) and "ping" it via DoH? Or any effort underway (at IETF for example) to get OS providers and DHCP server maintainers to support DoH server selection?

Comment 7

[Valentin Gosu [:valentin] (he/him)]

(In reply to Pas from comment #6)

Hello!

Was there any plan to try to get the already configured/known DNS server (usually configured/provisioned via DHCP) and "ping" it via DoH? Or any effort underway (at IETF for example) to get OS providers and DHCP server maintainers to support DoH server selection?

There is work under way to do this:
https://datatracker.ietf.org/doc/draft-ietf-doh-resolver-associated-doh/

The problem with just trying to use DoH with the configured DNS server is that the server is usually an IP address - maybe 10.0.0.1 ? And DoH works over HTTPS so you need a certificate for that IP/hostname. So we need a slightly more complicated solution.

Comment 8

[Mike Kaply [:mkaply]]

Here's some code that would check for policies and DNSOverHTTPS

if (Services.policies.status == Services.policies.ACTIVE) {
  let policies = Services.policies.getActivePolicies()
  if (!("DNSOverHTTPS" in policies) {
    // Don't enable DNSOverHTTPS
  } else {
    // If they have configured DNSOverHTTPS, make sure policy wins
  }

}

Comment 9

[saschmit]

Not all split horizon DNS is by enterprises (though I admit they're typically the ones with expertise). Any reason not to use the DHCP search list instead (bug #1582472)?

Comment 10

[Valentin Gosu [:valentin] (he/him)]

(In reply to saschmit from comment #9)

Not all split horizon DNS is by enterprises (though I admit they're typically the ones with expertise). Any reason not to use the DHCP search list instead (bug #1582472)?

That's next on our list of priorities. Should be implemented in the next month.

Comment 11

[Julien Cristau [:jcristau]]

Should this be included in the 72 release notes? If yes please nominate by setting the relnote-firefox flag to "?" and fill in the form. Thanks.