1450893 - TRR: feature request, add domains exclusion list

Status: RESOLVED FIXED

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

Description

[Francois Guerraz]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180402220122

Steps to reproduce:

Just like there is a domain exclusion list for proxies (network.proxy.no_proxies_on), it would be nice to have an exclusion list for TRR.

The reason is the following: privacy concious people will set network.trr.mode=3 because otherwise TRR fails silently and falls back to native, so an attacker could block google/cloudflare servers to force users to fall back to less secure DNS without them noticing.
But in mode 3, there's no way to access either a company's internal services that are based on local domain names, or avahi/bonjour/whaterver .local addresses from services autodiscovery.

Comment 1

[Aidan Corey]

This is also a problem with network.trr.mode=2, where the company's public and internal DNS return different addresses for the same service (in my case the public site redirects to a gateway).

Comment 2

[Mario Thies]

In my opinion all of the connection-specific dns suffix's and all of the system dns suffixes have to be excluded automatically.

That should fix this issue in more than 99% of all cases.

Comment 3

[Francois Guerraz]

@Mario, so all an attacker would have to do to log/manipulate DNS traffic is to push a search domain via DHCP? That's a too easy attack vector...

Comment 4

[Mario Thies]

We are talking about company environment. Our DHCP/AD servers pushes some dns suffixes that have to be resolved by our local dns in any case. And no request must be sent out to the TRR due to security reasons. So which way would you prefer? Extra gpo's are not practicable.

Comment 5

[Mario Thies]

Here is a part of my trr log. I set network.trr.mode==1 at the moment. The browsing to local domains works (zammad.foobar.eu has a rfc 1918 ip), but the query are also sent to the trr. I'd call this a security disaster. 

2018-08-10 10:42:18,086:     INFO: [HTTPS] Received: ID 0 Question google.com. IN NS Peer ('127.0.0.1', 48196)
2018-08-10 10:42:18,087:     INFO: [DNS] Send: ID 55072 google.com. IN NS
2018-08-10 10:42:18,087:    DEBUG: Waiting for DNS response
2018-08-10 10:42:18,304:     INFO: [DNS] Received: ID 18901 www.google.com. IN A
2018-08-10 10:42:18,898:     INFO: [DNS] Received: ID 55072 google.com. IN NS
2018-08-10 10:42:18,898:     INFO: [HTTPS] Send: ID 0 Question google.com. IN NS Peer ('127.0.0.1', 48196)
2018-08-10 10:42:29,169:     INFO: [HTTPS] Received: ID 0 Question zammad.foobar.eu. IN A Peer ('127.0.0.1', 48198)
2018-08-10 10:42:29,170:     INFO: [DNS] Send: ID 41146 zammad.foobar.eu. IN A
2018-08-10 10:42:29,170:    DEBUG: Waiting for DNS response
2018-08-10 10:42:29,171:     INFO: [DNS] Received: ID 41146 zammad.foobar.eu. IN A
2018-08-10 10:42:29,172:     INFO: [HTTPS] Send: ID 0 Question zammad.foobar.eu. IN A Peer ('127.0.0.1', 48198)
2018-08-10 10:42:29,173:     INFO: [HTTPS] Received: ID 0 Question zammad.foobar.eu. IN AAAA Peer ('127.0.0.1', 48200)
2018-08-10 10:42:29,174:     INFO: [DNS] Send: ID 48841 zammad.foobar.eu. IN AAAA
2018-08-10 10:42:29,174:    DEBUG: Waiting for DNS response
2018-08-10 10:42:29,644:     INFO: [DNS] Received: ID 48841 zammad.foobar.eu. IN AAAA
2018-08-10 10:42:29,644:     INFO: [HTTPS] Send: ID 0 Question zammad.foobar.eu. IN AAAA Peer ('127.0.0.1', 48200)

Comment 6

[Francois Guerraz]

"We are talking about company environment." and how do you differentiate between a "safe" environment and another one? How is Firefox supposed to know the difference between your "safe" corportate network (as if DHCP spoofing wasn't easy) and the coffee shop around the corner?

I understand the requirement not to send your "private" hostnames to TRR, but the only safe way of achieving this is by a user-controlled preference or admin-controlled GPO.

You *cannot* rely on DHCP for providing safe or accurate information.

If your company is worried about TRR today, you can disable TRR with a GPO. If you company doesn't do GPOs, and still allows users to use whichever browser, then your company is not really worried about security.

Comment 7

[Mario Thies]

Well, I've liked the FireFox for many years and I like the idea of doh or dot. But I see the requirements in our local network and in other companies I know. If an administrator has the choice between an IE that just works and a FireFox that needs GPO's, how will he decide?

And don't forget that there are also networks where guests log in to access local websites (demo pages, training pages). This must also be possible.

It may be an idea to define a switch like network.trr.trustLocalSuffixes with default true. Something you have to trust, and if a DHCP/AD in a company has been compromised, then the browser is the user's least of the problems.

Comment 8

[Johannes Pfrang [:johnp]]

> If an administrator has the choice between an IE that just works and a FireFox that needs GPO's, how will he decide?

Firefox ESR "just works" since it doesn't contain DoH and is the recommended version for deployment in enterprises. I cannot speak for Mozilla, but I would be very surprised if this ever were backported to ESR 60 (except for the Tor Browser), lest being enabled there.

> And no request must be sent out to the TRR due to security reasons.
FYI, if you're business' security relies on the obscurity of internal domain names you already have to centrally disable search suggestions in any other browser, since those already leak any/most address bar input (Firefox otoh filters out what looks like URLs, though it may also leak domain fragments (single words)).

Comment 9

[Machiel]

Regarding this issue I have the problem that we use internal dns overides for certain internet facing on-site hosted services. So webservice.example.com resolves to xx.xx.xx.xx internally and yy.yy.yy.yy externally. This is a functional requirement in the network for onsite hosted services. 

The devices on the network are not controlled by the administrators i.e. random user mobile devices.

Comment 10

[Mikael Falkvidd]

Sorry if this is not the correct issue to add to, but there are two use cases where I am unable to use TRR in Firefox:

1. mdns. I have IoT devices that use hostname.local. I can access them fine when TRR is disabled, but when using network.trr.mode=3 I get "Server not found. Hmm. We’re having trouble finding that site.".
2. When managing my home router. It has a DNS name that resolves to 192.168.1.1. When TRR is enabled, I get the same error message as in case 1.

For now, these problems have led me to use network.trr.mode=4

Comment 11

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

(In reply to Mikael Falkvidd from comment #10)
> Sorry if this is not the correct issue to add to, but there are two use
> cases where I am unable to use TRR in Firefox:
> 
> 1. mdns. I have IoT devices that use hostname.local. I can access them fine
> when TRR is disabled, but when using network.trr.mode=3 I get "Server not

For both cases, you should be using mode=2 - which is TRR but falls back to regular DNS when TRR fails. mode=3 is strict, and does not fail back to DNS at all.
https://gist.github.com/bagder/5e29101079e9ac78920ba2fc718aceec

Comment 12

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

Attachment: Bug 1450893 - Add pref for list of domains excluded from TRR r=dragana

Comment 13

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

Attachment: Bug 1450893 - Add way to clear DNS cache r=dragana

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/da9099238d4f
Add way to clear DNS cache r=dragana
https://hg.mozilla.org/integration/autoland/rev/d24302372a67
Add pref for list of domains excluded from TRR r=dragana

Comment 15

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

Comment on attachment 9052477 [details]
Bug 1450893 - Add way to clear DNS cache r=dragana

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: None
• User impact if declined: This patch is needed for bug 1529437 (TRR experiment v6)
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a very simple change that doesn't change behaviour in any way.
  It adds an API that allows native addons to clear the cache (including the TRR cache which is not currently possible) in order to make sure that when we perform a request it definitely uses the correct IP either from TRR or native DNS.
• String changes made/needed:
• Do you want to request approval of these patches as well?: on

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

Does this affect Fennec as well or only desktop Firefox?

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

And, is this going to land on m-c and beta as well?

Comment 19

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

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #17)

Does this affect Fennec as well or only desktop Firefox?

We're only running the experiment on desktop Firefox.

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #18)

And, is this going to land on m-c and beta as well?

It's already been pushed to autoland.
I'm not sure whether we need it in beta, but I suspect it's better to have it there in case we need to do another experiment after that.

Comment 20

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, does the same patch apply to beta?

Comment 21

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

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #20)

OK, does the same patch apply to beta?

Yes. I grafted it on both beta and release, and it applied without conflicts.

Comment 22

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/da9099238d4f
https://hg.mozilla.org/mozilla-central/rev/d24302372a67

Comment 23

[Pascal Chevrel:pascalc]

Comment on attachment 9052477 [details]
Bug 1450893 - Add way to clear DNS cache r=dragana

Low risk patch needed for bug 1529437 (TRR experiment v6), approved for our next 66 dot release. I am also adding my approval for beta so as that we have the patch on all trains if we need to continue the study in 67.

Comment 24

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/08398544a289
https://hg.mozilla.org/releases/mozilla-beta/rev/6db60f4d14ee

Comment 25

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

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #24)

Hi Sebastian,

Only this patch was approved for uplift

https://hg.mozilla.org/releases/mozilla-beta/rev/08398544a289

Not this one.

https://hg.mozilla.org/releases/mozilla-beta/rev/6db60f4d14ee

Comment 26

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-release/rev/1805599da5fd

Comment 27

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

(In reply to Valentin Gosu [:valentin] from comment #25)

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #24)

Hi Sebastian,

Only this patch was approved for uplift

https://hg.mozilla.org/releases/mozilla-beta/rev/08398544a289

Not this one.

https://hg.mozilla.org/releases/mozilla-beta/rev/6db60f4d14ee

Backed out: https://hg.mozilla.org/releases/mozilla-beta/rev/1dabaf68f8fe6e50d20202773f1a8bd95dadb4b4

TIL that the uplift request for other patches also includes the current patch, not just "as well".

(In reply to Valentin Gosu [:valentin] from comment #15)

• Do you want to request approval of these patches as well?: on

Comment 28

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Patch for this bug backed out: https://hg.mozilla.org/releases/mozilla-beta/rev/994e50d055c0b339a6541a460399189740324a4a