proxy dns when using socks5 not working in Firefox

[5uy4n9]

SwitchyOmega version / SwitchyOmega 版本

2.5.20

Browser version & OS version / 浏览器名称、版本及操作系统版本

Firefox 101.0.1 (64-bit)
macOS Monterey 12.4

Problem description / 问题描述

(Please provide as much detail as possible. We recommend the following format.)
(请尽可能多提供一些细节。我们推荐使用下面的格式。)

Steps to reproduce issue / 重现错误所需步骤

(What did you do? / 你做了什么？)

1. set network.proxy.socks_remote_dns = true in about:config
2. enable switchyOmega and add local socks5 proxy in profile and use it as proxy
3. use wireshark to capture dns traffic and open google.com in firefox

Expected behavior / 期望发生的情况

wirshark can't capture google.com dns traffic

Actual (or suggested) behavior / 实际发生的情况（或建议修改后的行为）

wirshark can capture google.com dns traffic

after disable switchyOmega, use firefox Manual proxy configuration, and set network.proxy.socks_remote_dns = true , wirshark can't capture google.com dns traffic

also tried to use curl to test in terminal
curl --socks5-hostname 127.0.0.1:8080 https://google.com
wirshark can't capture google.com dns traffic

and Chrome don't have this problem, looks like it's only happens in Firefox?

[ynyyn]

+1, same problem when using proxy enforced by SwitchyOmega. Firefox 102, macOS Monterey, ARM64.

I could clearly remember that this feature, DNS Proxy upon SwitchyOmega, was working well – just not long before (at least Firefox 97?), but somehow now it is broken.

It took me a long time to tweak over the config in order to fix it, but no matter how, it just behaves like it is not support.

After some research, I suspect it might be some recent change inside Firefox itself accidentally break it.

Here's why:

• The ability of WebExtensions to enforce DNS proxy was added to Firefox back in 2017, see https://bugzilla.mozilla.org/show_bug.cgi?id=1397991 for details.

  • Basically, it is achieved by WebExtensions returning a config-like object with .proxyDNS property set true. It was a new convention. Before that, a command-like plain text would be used.

• SwitchyOmega knew this matter clearly (because of known issue Firefox: SOCKS5 proxies do not use remote DNS #1172) and closely adapted in 06e7ad6#diff-31c899c3bc1fe56463eb5528955c2cf1c80c6bde6d7e023efcf9c080c93f1333R52, which is released in v2.5.3.

  SwitchyOmega/omega-target-chromium-extension/src/js/omega_webext_proxy_script.js

  Lines 46 to 58 in 06e7ad6

  	if (proxyInfo.type === 'socks5') {
  	// MOZ: SOCKS5 proxies are identified by "type": "socks".
  	// https://dxr.mozilla.org/mozilla-central/rev/ffe6cc09ccf38cca6f0e727837bbc6cb722d1e71/toolkit/components/extensions/ProxyScriptContext.jsm#51
  	proxyInfo.type = 'socks';
  	// Enable SOCKS5 remote DNS.
  	// TODO(catus): Maybe allow the users to configure this?
  	proxyInfo.proxyDNS = true;
  	}
  	if (auth) {
  	proxyInfo.username = auth.username;
  	proxyInfo.password = auth.password;
  	}
  	return [proxyInfo];

  • So, DNS Proxy should have been a very supported and stable feature upon SwitchyOmega, which is consistent with what I remember.

• To verify the extension side do its thing right, I opened up the extension debugger (about:debugging#/runtime/this-firefox), checked the running code of SwitchyOmega in my hand, examined with breakpoint, confirming that what SwitchyOmega returns is correct.

Thus, I believe it's a browser side issue, given that there is no further change statement on this thing.

I tried searching on bugzilla, but there seems to be no similar feedback recently. Fortunately, I found this issue here in SwitchyOmega.

I may file a bugzilla report afterwards to let there people see.

[kernel-panic-enjoyer]

Have you filed a bugzilla report @ynyyn ? Can you share any progress? The issue appears to persist.

[ynyyn]

Have you filed a bugzilla report @ynyyn ? Can you share any progress? The issue appears to persist.

I apologize for not following through with my word to file a bugzilla report. 😢 I put it off over and over again due to my busy schedule, and eventually gave up, just hoping that someone else would do the feedback... 😣

Fortunately, it seems that other people have reported this issue on bugzilla: 1799411 - DNS leaks with proxy extension.

That report is amazingly exhaustive and well-written. Salute.

[ynyyn]

Okay... The discussion at bugzilla says this problem seems related to the famous extension uBlockOrigin: uBlockOrigin/uBlock-issues#1743 (comment)

FYI:

uBO's DNS query not being proxied by another extension doing the proxying on-the-fly through proxy.onRequest(), which is expected as extensions can't interfere which each other's requests -- there is no way for uBO to know whether the proxying was done on-the-fly or is browser-wide.

---

It is probably true. I do have installed uBlockOrigin, so I did a quick verification. It turns out that the DNS leak disappears when uBlockOrigin is disabled at about:addons.

[kernel-panic-enjoyer]

Fortunately, it seems that other people have reported this issue on bugzilla: 1799411 - DNS leaks with proxy extension.

It is probably true. I do have installed uBlockOrigin, so I did a quick verification. It turns out that the DNS leak disappears when uBlockOrigin is disabled at about:addons.

Thank you for sharing the info you have. The tldr is that uBlock Origin is not aware of other addons such as SwitchyOmega and it cant instruct the browser to use a proxy for its request. Firefox itself is using SOCKS5 only for standard web traffic. Non-http(s) requests, such as DNS, are not proxied - which is by design! A flaw in Firefox, not the Addon.

A current workaround appears to be disabling the unloaking of canoncial names in uBlock:

Important note when using extension-based proxy service: Extension-based proxy services usually are performed on the fly through a browser API. In such a case, uBO's DNS queries to uncloak canonical names will NOT be caught and proxied by an extension-based proxy service. So you may want to disable this setting when using an extension-based proxy service.