User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170907220212 Steps to reproduce: Using one of the most famous proxy plugins, SwitchyOmega (pretty sure other proxy plugins are affected too), I'm frustrated to realize that it does not support remote DNS. Although Firefox's native proxy settings works smoothly, everyone deserves a better proxy plugin, isn't it? I know it's actually more a feature request than a bug, but believe me there is a vast area of land in the world where DNS is poisoned nationally. If Firefox 57 does not support those legacy proxy plugins nor provide an option to re-enable them, which is said to be true, that would be a disaster for those poor guys(weeping). Here are steps to reproduce: 1. Install Firefox Nightly and SwitchyOmega (of course) 2. Set network.proxy.socks_remote_dns=true && network.dns.disablePrefetch=true (No use, just another desperate attempt). 3. Set up proxy in SwitchyOmega, open Wireshark and start capturing 4. Go to www.google.com Actual results: Bang! DNS leakage detected. (And I don't think the Wireshark log is necessary) Expected results: What should have happened? 1. Install Firefox Nightly. 2. Add a remote DNS WebExtensions API. 3. Bug solved elegantly.

The following wensite can alao be used to detect DNS leakage when you connected with proxy: https://dnsleaktest.com/

Modify the summary to match the original meaning. I can see no leaks on https://dnsleaktest.com/ with SOCKS (not HTTPs) proxy enabled in SwitchyOmega, network.proxy.socks_remote_dns=false and 57.0a1 (2017-09-06) on Win10.

Well, that's weird. Because I got a positive result. I don't know how the https://dnsleaktest.com/ works, but I will assume that if you test DNS leakage using that website in an area where DNS is not poisoned certainly no leaks will be detected. I don't know whether it's my own problem or most people got this issue. But WebExtensions Proxy API certainly lacks of remote DNS options (See also https://stackoverflow.com/questions/45795097/webextension-proxy-api-resolve-dns-entries-on-socks5-proxy-not-on-the-local-sy/).

Okay, I've found an easy way to reproduce this. You just need another Linux box with SSH acccess. A virtual machine on AWS, etc., also serves the purpose. It doesn't even have to be Linux. 1. In your other Linux box, edit `/etc/hosts` and add a line: 93.184.216.34 internal.test www.internal.test (93.184.216.34 is the IP address of example.com. Use any IP you like which has an HTTP server running on Port 80. If that Linux box doubles as an HTTP server, feel free to use 127.0.0.1.) 2. On your own device, `ssh -D7070 username@ip-address-of-your-other-linux-box` to create an SOCKS5 server. If under Windows, use any SSH Tunnel application you like. 3. Use any WebExtension that allows you to return "SOCKS 127.0.0.1:7070". I would recommend SwitchyOmega, but you can also use others. Just make sure you select "SOCKS5", not "SOCKS4". You can also download the attachment from Bug 1398900 and modify proxy.js to return "SOCKS 127.0.0.1:7070". 4. Visit `http://internal.test/` in your browser. Expected: It should use the IP address on the other Linux box, and therefore it should show you a web page with "Not Found" on it (or whatever if you changed the IP address). Actual: It says "Server not found", which proves DNS requests are not resolved remotely. This issue is reproducible no matter what the value of `network.proxy.socks_remote_dns` is. However, if you use Firefox's browser proxy settings in Preferences with `Proxy DNS when using SOCKS v5` checked (which sets `network.proxy.socks_remote_dns`), then it works perfectly well. Therefore, we can reach the conclusion that WebExtension cannot use remote DNS, while the browser proxy settings can. This is a fully controlled environment and does not rely on an external tool, so someone please try it and move the status to CONFIRMED.

Now that Bug 1381290 has landed in Nightly, the proxy script can return an array of objects instead of a string. The objects have a "proxyDNS" property, which can control the usage of remote DNS (tested with attachment from Bug 1398900 and dnsleaktest.com).

Fixed with bug 1381290