0.6.x: dnsseed action differs with proxy value, DNS leak, SOCKS5 #2088

0.6.x aea0658578a64503967856c235d7ca1a361e1c3b

When proxy=127.0.0.1:7053 dns seed is performed. When proxy=192.168.0.1:9050 dns seed is not performed.

1. According to '-h', dnsseed should always be used if dnsseed is 1 or unspecified. And not used if 0.

This difference in dnsseed / ThreadDNSAddressSeed based on the proxy value is bad. It should always follow dnsseed setting/default.

2. And when the former setting is used, the dns seed does not go through the proxy as directed. This leak is bad. If proxy is specified, all traffic needs to go through the proxy.

2a) Also, suggest using primarily socks5, secondary socks4a, tertiary socks4. Also socks4 and socks4a cannot do IPv6!

https://en.wikipedia.org/wiki/SOCKS https://tools.ietf.org/html/rfc1928

Edit: If still the case, do not assume use of proxy port 9050 is Tor, and that use of any other proxy port is not Tor. I should test with v0.7.x. bitcoin_stable repo is missing some recent release tags.

Current help-text for -dnsseed is Find peers using DNS lookup (default: 1 unless -connect). You should indeed test with current master or at least 0.7.1 or 0.7.2 RC to verify that problem is current.

This code is used to check if ThreadDNSAddressSeed should be started:

<pre> if (!GetBoolArg("-dnsseed", true)) printf("DNS seeding disabled\n"); else if (!NewThread(ThreadDNSAddressSeed, NULL)) printf("Error: NewThread(ThreadDNSAddressSeed) failed\n"); </pre>

I'm rather sure current code is knowing, that SOCKS versions != 5 can't do IPv6. SOCKS4a is not implemented and most likely won't get implemented. I know there was even some discussion a few months ago to remove SOCKS4, as most proxies are SOCKS5 anyway. Oh and SOCKS5 is default, if not specified otherwise.

0.6.x is quite old now is there a particular reason you're reporting against it? (As diapolo points out, the behavior you're writing about is fixed in 0.7). Since this area of network handling was completely rewritten reports against old versions here are less useful than typical.

There were some recent commits in 0.6.x leading to thought it was still active. 0.7.x seems ok re ticket, will migrate.

These are places where 9050 still shows up. Don't know whether these are defaults if unspecified?, hardcoded? or what? Hope they are overrideable to the user's actual port.

./src/init.cpp: addrProxy = CService(mapArgs["-proxy"], 9050); ./src/init.cpp: addrOnion = CService(mapArgs["-tor"], 9050); ./src/qt/optionsmodel.cpp: CService addrProxy(settings.value("addrProxy", "127.0.0.1:9050").toString().toStdString()); ./src/qt/optionsmodel.cpp: return QVariant(9050); ./src/qt/optionsmodel.cpp: proxy.first = CService("127.0.0.1", 9050); ./src/qt/optionsmodel.cpp: proxy.first = CService("127.0.0.1", 9050);

-proxy and -tor allow to specify the used port, so 9050 is not "hardcoded" AFAIK.