mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
Joined: Aug 2003
Posts: 80
H
HM2K Offline OP
Babel fish
OP Offline
Babel fish
H
Joined: Aug 2003
Posts: 80
What socks are actually used for is debatable. At present there's little reliable information to cite exact usage.

However, the original complaint I'm getting from users is that when using a SOCKS5 server, they are getting 255.255.255.255 instead of the ip address of the irc server.

When $serverip is called, I see no reason why it should not lookup the IP address of the server, as the user requested.

DNS leaks are part of the nature of resolving the server hostname to an ip address. Users should understand this when calling such a command.


-HM2K- hm2k.org
Joined: Jul 2008
Posts: 236
S
Fjord artisan
Offline
Fjord artisan
S
Joined: Jul 2008
Posts: 236
I see multiple small 'issues' with what you're suggesting.

When considering a round-robin name, where the domain is resolved to multiple IP addresses and they are rotated as the nameserver's implementation defines, and where the proxy chooses an IP as the proxy's implementation defines, how do you decide the correct IP? It's not possible. I have already said this so I'll provide an example: go to start -> run -> cmd.exe and type nslookup irc.dal.net.

Furthermore, DNS records change. What if you connect to irc.dal.net, and then 3 hours later someone hijacks the nameserver and points it to 193.109.122.77 (which just so happens to be the only address that irc.efnet.nl resolves to)? You then have a bunch of proxy scripts that have been fooled into believing the server IP is different.

While you believe this is a simple solution, it is a lot more difficult than you can likely imagine. What if the nameserver in question goes down or faces latency of ~2-3 seconds? You end up with a script that just hangs. Given the single-threaded nature of the mIRC interpreter, and the fact that mIRC does not have co-routines, as Python does, this would probably be difficult to implement asynchronously. Think about it, if this could be done asynchronously, don't you think Khaled would have written the DNS implementation a little bit differently (more on this at the end, in case Khaled does decide to do things this way).

I believe your misunderstanding may be a logical misunderstanding. $serverip does not 'lookup the IP address of the server' at the time it is called, regardless of proxy settings. It returns a value that is resolved before a connection to the IRC server is established. The issue is that SOCKS5 doesn't require a local DNS resolution before the connection is established. The simplest way to achieve an ideal result would be to resolve before connection to the IRC server is established. If you're less concerned about delays than you are anonymity (and by the sounds of things, this is the case), and your computer just happens to be the local DNS server (which is unlikely) this initial resolution can be done 'anonymously' via a SOCKS5 (but not SOCKS4/a or HTTP) proxy using the UDP features. If you're less concerned about the accuracy of the return value (and by the sounds of things, this is the case), there is an IP field within a SOCKS5 success response that the proxy might fill in that could be used. Both of these options are likely to yield more accurate results, with less GUI freezes. Of course, if you're not the local DNS server then you shouldn't be all that concerned about anonymity when resolving domains, because as I stated previously the nameserver will not pass your IP on.

My contribution is in the form of an extension to HM2K's suggestion, should you follow through with that instead Khaled. I find the DNS implementation cumbersome, but I've learnt to live with it because I know how the internet, computers and interpreters work. Should you decide to implement his asynchronous, script-halting name resolution, I believe it would be beneficial to extend upon this. You could add an identifier, $serverhn which is guaranteed to store the hostname (as opposed to whatever the IRC server wants the client to store in $server -- which is dependant upon IRCd configuration), and extend upon the $dns alias in such a way that it can be used without requiring an on DNS event. For example, where this is all independent of an on DNS event: $dns(www.google.com,0) would return the total number of IP addresses and $dns(www.google.com,n) would return the nth IP address. The same could be done for nickname resolutions: %ip = $dns($nick). This would eliminate the necessity for an on DNS event, the .nick, .addr and .ip properties of the $dns(N) identifier and would simplify scripting with the DNS event greatly.

Here's an example of a resolution script that performs a DNS remotely when triggered, using the current DNS implementation:
Code:
on 1:TEXT:.dns *:#: {
  dns -h $2
  hadd -m dns_wait $1 $hget(dns_wait,$1) $nick
}

on 1:DNS: {
  var %t, %addr = $dns(0).addr

  tokenize 32 $hget(dns_wait,%addr)
  if ($0 == 0) { return }

  if ($dns(0) > 0) {
    var %n = $v1
    %t = Resolved %addr to $v1 IP addresses:
    while (%n > 0) {
      %t = %t $dns(%n).ip
      dec %n
    }
  }
  else { %t = Unable to resolve $dns(0).addr }

  msg $1 %t
  if ($0 == 1) { hdel dns_wait %addr }
  else { hadd dns_wait %addr $2- }
}


Here's an example of a resolution script that performs a DNS remotely when triggered, using my proposed suggestion:
Code:
on 1:TEXT:.dns *:#: {
  var %t

  if ($dns($1,0) > 0) {
    var %n = $v1
    %t = Resolved $1 to %n IP addresses:
    while (%n > 0) {
      %t = %t $dns($1,%n).ip
      dec %n
    }
  }
  else { %t = Unable to resolve $1 }

  msg $nick %t
}


Ahh, wouldn't life be sweet? I already know this won't happen, though.

Last edited by s00p; 02/12/09 01:18 PM.
Joined: Aug 2003
Posts: 80
H
HM2K Offline OP
Babel fish
OP Offline
Babel fish
H
Joined: Aug 2003
Posts: 80
@s00p, after re-reading I see your issue with robin-round, however it's a none issue. Allow me to explain...

To reproduce the issue:

/server irc.quakenet.org
;connects to quakenet
//echo -a $server
;gives servercentral.il.us.quakenet.org
/dns servercentral.il.us.quakenet.org
;Dns resolved servercentral.il.us.quakenet.org to 66.225.225.66
//echo -a $serverip
;gives 255.255.255.255

What is expected:

//echo -a $serverip
;gives 66.225.225.66


-HM2K- hm2k.org
Joined: Dec 2002
Posts: 5,417
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,417
The next version of mIRC will perform a separate DNS on the server address when connecting through a SOCKS5 proxy, which should resolve this issue.

Joined: Aug 2003
Posts: 80
H
HM2K Offline OP
Babel fish
OP Offline
Babel fish
H
Joined: Aug 2003
Posts: 80
@Khaled Thanks for the update smile


-HM2K- hm2k.org
Joined: Dec 2002
Posts: 3,138
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 3,138
Originally Posted By: Khaled
The next version of mIRC will perform a separate DNS on the server address when connecting through a SOCKS5 proxy, which should resolve this issue.

For the privacy reasons outlined in previous posts I think this should be made optional, as it is in Firefox.

Joined: Dec 2002
Posts: 5,417
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,417
I have just re-read this thread and looked into DNS leakage, and as I suspected in my earlier post, DNS leaks are an important issue. So this will have to be an option that is disabled by default. I cannot add an option to the proxy dialog just now since it will not fit cleanly, so I have delayed adding this feature.

However, I have made a change so that /dns $server will fill $serverip. Socks5 users will be able to add /dns $server to a numeric 001 event to fill $serverip, which is what an mIRC option would do in any case.

Note: The priority currently is to ensure that the Unicode version of mIRC (which took over a year of work and required tens of thousands of code changes) is stable and working as closely to mIRC v6.35 as possible. Once that has been achieved, the next set of major changes are planned, which include interface changes.

Page 2 of 2 1 2

Link Copied to Clipboard