TRR: feature request, add domains exclusion list

RESOLVED FIXED in Firefox 66

Status

()

enhancement
P2
major
RESOLVED FIXED
a year ago
a month ago

People

(Reporter: kubrick, Assigned: valentin)

Tracking

(Blocks 1 bug, Regressed 1 bug)

61 Branch
mozilla68
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox66blocking fixed, firefox67 fixed, firefox68 fixed)

Details

(Whiteboard: [necko-triaged][trr])

Attachments

(2 attachments)

Reporter

Description

a year ago
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.
Reporter

Updated

a year ago
Severity: normal → enhancement
Component: Untriaged → Networking: DNS
Product: Firefox → Core
Priority: -- → P3
Whiteboard: [necko-triaged][trr]

Comment 1

a year ago
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

10 months ago
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.
Reporter

Comment 3

10 months ago
@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

10 months ago
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

10 months ago
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)
Reporter

Comment 6

10 months ago
"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

10 months ago
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.
> 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

6 months ago
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.
Assignee

Updated

6 months ago
Blocks: DoH

Comment 10

6 months ago
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
(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
Assignee

Updated

5 months ago
Blocks: 1507082
Assignee

Updated

2 months ago
Assignee: nobody → valentin.gosu
Priority: P3 → P2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 14

2 months ago
Pushed by valentin.gosu@gmail.com:
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
Assignee

Updated

2 months ago
Blocks: 1537916

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
Attachment #9052477 - Flags: approval-mozilla-release?
Duplicate of this bug: 1537916

Does this affect Fennec as well or only desktop Firefox?

Flags: needinfo?(valentin.gosu)

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

(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.

Flags: needinfo?(valentin.gosu)

OK, does the same patch apply to beta?

(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

2 months ago
bugherder
Status: ASSIGNED → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

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.

Attachment #9052477 - Flags: approval-mozilla-release?
Attachment #9052477 - Flags: approval-mozilla-release+
Attachment #9052477 - Flags: approval-mozilla-beta+
Severity: enhancement → major

(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

Flags: needinfo?(aryx.bugmail)

(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
Flags: needinfo?(aryx.bugmail)
Assignee

Updated

2 months ago
Duplicate of this bug: 1539094
Flags: qe-verify-
Regressions: 1543331
You need to log in before you can comment on or make changes to this bug.