Summary: | Use the KDE-configured Socks Proxy to resolve DNS queries | ||
---|---|---|---|
Product: | [Unmaintained] kdelibs | Reporter: | Moran Zaltsman <junkie> |
Component: | knetwork | Assignee: | Thiago Macieira <thiago> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | wishlist | CC: | kopete-bugs-null |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Moran Zaltsman
2006-03-01 14:30:46 UTC
IMO, this is invalid for ICQ since we don't get a hostname back from the server for the second connection (ICQ login involves two seperate connections) and the network classes are perfectly happy with the IP address it gets from the server. There is no point to make several more roundtrips just to look up the hostname. I can't comment on MSN. I can say (after an examination of the Tor Socks-proxy log-files) that no matter how many queries Kopete did send to the ICQ server(s), the Tor Socks-Proxy only had been given an IP-address - and not a Hostname. * an IP-Address = only IP-Addresses * a Hostname = a single Hostname I don't know how the underlying network classes work in terms of name resolution before connection, but it would seem to me that the difference between Konqueror and Kopete is the use of ioslaves by Konqueror. Since ioslaves work differently from Kopete's connections this could explain the difference. Thiago: can you provide some more information please? Thanks. :) The only way to use SOCKS to do DNS queries, at the moment, is to use "socksify" or a similar LD_PRELOAD-trick. BTW, Kopete is behaving as expected: it's NOT using SOCKS to send DNS queries. That's how the whole of KDE behaves, except for kio_http. I did try "socksify" (Dante) and also "torify" (tsocks), and found that neither of them catches the "gethostbyname" syscall(s). Why doesn't KDE at general use the configured SOCKS Proxy to do the name resolution (DNS) ? Anyhow and IMHO, It probably would be better if the user could choose whatever if to use the SOCKS Proxy for doing DNS or not. There are two reasons for that: * the first is that the code to do that has never been written * the second is that, in order to comply with the list of exceptions that are listed as IP addresses, we have to resolve the IP address. And I'd rather not send a DNS request over SOCKS, but tell SOCKS to connect to the hostname. It's a bit of chicken-and-the-egg problem... I indeed wrote something like "... use the SOCKS Proxy to do the name resolution (DNS)" - but actually meant that the SOCKS Proxy should be supplied with a Hostname instead of an IP-Address. sorry for being a bit unclear. And as said before, IMHO, the User should better be let decide whatever if to supply the SOCKS Proxy with Hostnames or IP-Addresses - maybe by a simple Checkbox at the KDE Proxy Configuration menu ? No. This is too low-level for configuration. When I implement this, ALL proxy requests will use hostname or NONE. It all depends on how I implement this. People are free to disagree, of course, as long as they supply patches that change the behaviour. Sounds promising, as longs as Hostnames will be used instead of IP-Addresses :) they won't always be used. Comment #1 explains why. So there is nothing we can do, sorry. As Matt explained in Comment #1 this is not possible with oscar. Same goes for MSN, we resolve messenger.msn.com the first time, and after, the MSN server reply us with the IP we need to connect to for the NS session or the chat session. It should anyway works with Jabber, since it require only one connection with the server which is done by dns resolving. (it will fail to verify SSL certificate, but this may be contourned) I still can't see why won't every part of KDE, where apply, give the KDE Configured Socks-Proxy the Hostname or IP_address - AS IS - instead of doing the name-resolution on their own. I seem not to be able to deliver my message here - over and over again, why is that ? am I not clear enough ? should I add any further explanation of and/or info on my idea ? * the Hostname or IP_address = the Hostname or IP_address that the aforementioned part of KDE has and assign to the newly created component Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have implemented this wish. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann |