TRR: feature request, add domains exclusion list
Categories
(Core :: Networking: DNS, enhancement, P2)
Tracking
()
People
(Reporter: kubrick, Assigned: valentin)
References
Details
(Whiteboard: [necko-triaged][trr])
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
pascalc
:
approval-mozilla-release+
|
Details | Review |
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•6 years ago
|
Updated•6 years ago
|
Comment 1•5 years 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•5 years 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•5 years 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•5 years 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•5 years 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•5 years 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•5 years 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.
Comment 8•5 years ago
|
||
> 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)).
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•5 years 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
Assignee | ||
Comment 11•5 years ago
|
||
(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 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 12•5 years ago
|
||
Assignee | ||
Comment 13•5 years ago
|
||
Comment 14•5 years 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 | ||
Comment 15•5 years ago
|
||
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
Does this affect Fennec as well or only desktop Firefox?
And, is this going to land on m-c and beta as well?
Assignee | ||
Comment 19•5 years ago
•
|
||
(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.
OK, does the same patch apply to beta?
Assignee | ||
Comment 21•5 years ago
|
||
(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•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/da9099238d4f
https://hg.mozilla.org/mozilla-central/rev/d24302372a67
Comment 23•5 years ago
|
||
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.
Updated•5 years ago
|
![]() |
||
Comment 24•5 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 25•5 years ago
|
||
(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•5 years ago
|
||
bugherder uplift |
![]() |
||
Comment 27•5 years ago
|
||
(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•5 years ago
|
||
Patch for this bug backed out: https://hg.mozilla.org/releases/mozilla-beta/rev/994e50d055c0b339a6541a460399189740324a4a
Updated•5 years ago
|
Description
•