"Proxy DNS when using SOCKS v5" enabled, but not immediately used
Categories
(Core :: Networking: DNS, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: thomas, Assigned: kershaw)
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Steps to reproduce:
A co-worker wanted to use a SOCKS5 proxy to access an internal host, so he used:
ssh -D 8080 user@sshserver.example.com
Then he configured the proxy settings in firefox 68.0.1 on Ubuntu:
Manual proxy configuration -> SOCKS Host: localhost, Port 8080
(but he didn't enable "Proxy DNS when using SOCKS v5")
At this point he tried to access the internal host, but of course firefox did not find a suitable DNS entry.
Now he enabled "Proxy DNS when using SOCKS v5" and tried to access the host again using Reload and Shift-Reload.
Actual results:
The standard firefox error page "Hmm. We’re having trouble finding that site. We can’t connect to the server at (internal hostname)" appeared, suggesting that the DNS lookup still fails.
I was able to reproduce this with firefox-esr 60.8.0esr-1~deb9u1 on Debian stretch.
Only after loading a page from a different web site the new setting was used.
(my co-worker restarted firefox and then it worked for him, so this part was only tested with the ESR version)
Expected results:
The setting "Proxy DNS when using SOCKS v5" should immediately become active after pressing OK in the proxy settings, so Reload (or at least Shift-Reload) works.
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Reporter | ||
Comment 2•5 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #1)
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
I'm not sure about this. Even if this is a generic networking/DNS issue in core, this feels more like a user interface issue, which does not propagate the changed setting hard enough.
"Core: Shared components used by Firefox and other Mozilla software, including handling of Web content; Gecko, HTML, CSS, layout, DOM, scripts, images, networking, etc. Issues with web page layout probably go here, while Firefox user interface issues belong in the Firefox product."
But a human firefox dev should decide this :)
Comment 3•5 years ago
|
||
necko is reacting on pref changes and as soon as pref changes it will respect it.
Comment 4•5 years ago
|
||
Hi Thomas,
Did you or your co-worker hit "OK" in the Connection Settings dialog before testing if you could load the page? The preference will only get written once you do that.
If so, can you repeat the experiment, but after hitting "OK", do the following:
- Go to about:config
- Type "network.proxy.socks_remote_dns" into the search filter
- Report back the value that's reported in the table
If the network.proxy.socks_remote_dns preference has been correctly set to "true", then at this point, the preference has been set correctly, and the issue is likely down in the networking stack.
Reporter | ||
Comment 5•5 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) (Catching up from PTO) from comment #4)
Did you or your co-worker hit "OK" in the Connection Settings dialog before testing if you could load the page? The preference will only get written once you do that.
Yes, I did.
If so, can you repeat the experiment, but after hitting "OK", do the following:
- Go to about:config
- Type "network.proxy.socks_remote_dns" into the search filter
- Report back the value that's reported in the table
It is "true".
Additionally, if keeping about:preferences and about:config open in two different windows, the value in about:config changes immediately when I change the setting in about:preferences and press OK.
If the network.proxy.socks_remote_dns preference has been correctly set to "true", then at this point, the preference has been set correctly, and the issue is likely down in the networking stack.
This is what I thought, too. It looks like Firefox needs a new reason to try the DNS lookup again (and this time through the SOCKS5 proxy), and accessing a different host gives Firefox such a reason, while just doing a reload or shift-reload doesn't.
Comment 6•5 years ago
|
||
Okay, thank you Thomas.
So, it sounds like Preferences is setting the network.proxy.socks_remote_dns
preference correctly. Over to the Necko team.
Assignee | ||
Comment 7•5 years ago
|
||
Hi Thomas,
May I ask you to provide the http log for this issue?
Please try to capture the log after enabling "Proxy DNS when using SOCKS v5".
Thanks!
Reporter | ||
Comment 8•5 years ago
|
||
- Using firefox-esr 60.8.0esr-1~deb9u1 on Debian stretch (amd64)
- With a fresh profile I configured the SOCKS5 proxy, but did not enable "Proxy DNS when using SOCKS v5" yet.
- Now I exited Firefox, started it again, and opened three tabs:
about:preferences
about:networking
http://tk2.hq.intevation.de/ (Hmm. We’re having trouble finding that site.) - Now enabled "Proxy DNS when using SOCKS v5" and clicked on OK.
- On about:networking -> Logging I clicked on "Start Logging"
- On the tk2 tab I clicked on Reload, Shift-Reload, clicked in the location field and pressed Enter
-> still "Hmm. We’re having trouble finding that site." - Now I clicked on "Stop Logging", exited Firefox, started it again (same Profile, Proxy DNS still enabled)
- Opening http://tk2.hq.intevation.de/ now works fine (please tell me if you need a log for that)
If I open a different internal site between 5. and 6. they work. In earlier tests opening different external sites in another tab made access to the internal site work, in today's tests it didn't for some reason.
Comment 9•5 years ago
|
||
In the log I can see 3 requests (not 4 as stated in the comment) to an internal site made, all assigned a proxy. In all 3 cases we do resolution natively. Looks like the change in using proxy to do DNS is not propagated. Looks more like a proxy backend bug than a DNS bug, but there is no component for it, let's leave it here.
Reporter | ||
Comment 10•5 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #9)
In the log I can see 3 requests (not 4 as stated in the comment)
I tried to describe what I did as precisely as possible, so I double-checked the comments:
As indicated in 4. I started the log after first trying to access the site with Proxy DNS disabled.
The three requests you see are from 5.: 1st: Reload, 2nd: Shift-Reload, 3rd: clicked in the location field and pressed Enter
-> comments and log match (good)
Comment 11•5 years ago
|
||
Looks like the change to Symbol F_<T_mozilla::net::nsProtocolProxyService>_mSOCKSProxyRemoteDNS - mozsearch doesn't propagate well to set Symbol E_<T_67f2d6147106a673>_TRANSPARENT_PROXY_RESOLVES_HOST,E_<T_6a7af66ac6c2a9f2>_TRANSPARENT_PROXY_RESOLVES_HOST,E_<T_b5debe5b0dbcfbd6>_TRANSPARENT_PROXY_RESOLVES_HOST,E_<T_d9c8ebe1>_TRANSPARENT_PROXY_RESOLVES_HOST - mozsearch on proxy info. Didn't look deeper into this, tho.
Updated•5 years ago
|
Assignee | ||
Comment 13•5 years ago
|
||
I think I've figured out the problem.
- "Proxy DNS when using SOCKS v5" is not enabled.
- Connect to http://tk2.hq.intevation.de/. The connection entry is created.
- Enable "Proxy DNS when using SOCKS v5".
- Connect to http://tk2.hq.intevation.de/ again, but we still use the old connection info and proxy info in connection entry created at step 2. TRANSPARENT_PROXY_RESOLVES_HOST is not set in the old proxy info, so we still try to resolve tk2.hq.intevation.de locally.
We should consider TRANSPARENT_PROXY_RESOLVES_HOST flag when building the hash key of connection info.
Assignee | ||
Comment 14•5 years ago
|
||
Assignee | ||
Comment 15•5 years ago
|
||
Hi Thomas,
Could you help to verify if the problem is fixed by this build [1]?
From the first comment, I guess you are using linux. Please let me know if you need a build for other platforms.
Thanks!
Comment 16•5 years ago
|
||
Pushed by kjang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2e42ca10c5a0 Add TRANSPARENT_PROXY_RESOLVES_HOST flag to connection info's hash key r=mayhemer
Comment 17•5 years ago
|
||
bugherder |
Reporter | ||
Comment 18•5 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #15)
Could you help to verify if the problem is fixed by this build [1]?
[1] https://queue.taskcluster.net/v1/task/B439Pk_3RL-L_nEw5YA2Ag/runs/0/artifacts/public/build/target.tar.bz2
Yes, it works fine with this build, thanks!
By the way, if I select SOCKS v4 (instead of the usual v5) it works in the same way, i.e. the "Proxy DNS when using SOCKS v5" setting is used, even though it is greyed out and can only changed by temporarily selecting v5. Should I create a bug report? (I was surprised that it works at all, either because Firefox is secretly using v5, or because our DNS server allows requests via TCP, too)
Description
•