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:
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:
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.
