Closed Bug 1571356 Opened 5 years ago Closed 5 years ago

"Proxy DNS when using SOCKS v5" enabled, but not immediately used

Categories

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

68 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla70
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.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Networking: DNS
Product: Firefox → Core

(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 :)

necko is reacting on pref changes and as soon as pref changes it will respect it.

Component: Networking: DNS → Preferences
Product: Core → Firefox

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:

  1. Go to about:config
  2. Type "network.proxy.socks_remote_dns" into the search filter
  3. 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.

Flags: needinfo?(thomas)

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

  1. Go to about:config
  2. Type "network.proxy.socks_remote_dns" into the search filter
  3. 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.

Flags: needinfo?(thomas)

Okay, thank you Thomas.

So, it sounds like Preferences is setting the network.proxy.socks_remote_dns preference correctly. Over to the Necko team.

Component: Preferences → Networking: DNS
Product: Firefox → Core

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!

Flags: needinfo?(thomas)
  1. Using firefox-esr 60.8.0esr-1~deb9u1 on Debian stretch (amd64)
  2. With a fresh profile I configured the SOCKS5 proxy, but did not enable "Proxy DNS when using SOCKS v5" yet.
  3. 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.)
  4. Now enabled "Proxy DNS when using SOCKS v5" and clicked on OK.
  5. On about:networking -> Logging I clicked on "Start Logging"
  6. 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."
  7. Now I clicked on "Stop Logging", exited Firefox, started it again (same Profile, Proxy DNS still enabled)
  8. 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.

Flags: needinfo?(thomas)

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.

Priority: -- → P2
Whiteboard: [necko-triaged]

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

I'd like to work on this.

Assignee: nobody → kershaw
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

I think I've figured out the problem.

  1. "Proxy DNS when using SOCKS v5" is not enabled.
  2. Connect to http://tk2.hq.intevation.de/. The connection entry is created.
  3. Enable "Proxy DNS when using SOCKS v5".
  4. 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.

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!

[1] https://queue.taskcluster.net/v1/task/B439Pk_3RL-L_nEw5YA2Ag/runs/0/artifacts/public/build/target.tar.bz2

Flags: needinfo?(thomas)
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
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

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

Status: RESOLVED → VERIFIED
Flags: needinfo?(thomas)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: