mIRC Homepage

$serverip returns 255.255.255.255

Posted By: HM2K

$serverip returns 255.255.255.255 - 19/11/09 09:07 PM

When using my perl Simple SOCKS Server as a firewall in mIRC it seems to return the $serverip as 255.255.255.255.

Why does mIRC return 255.255.255.255 instead of either the irc server I am connected to?

How does mIRC gather the $serverip value?

Thanks.
Posted By: argv0

Re: $serverip returns 255.255.255.255 - 20/11/09 10:38 AM

Probably from RAW 001-005:

Your host is irc.igs.ca[205.210.145.3/6667], running version ircd-ratbox-2.2.8

Posted By: s00p

Re: $serverip returns 255.255.255.255 - 20/11/09 01:53 PM

Originally Posted By: HM2K
When using my perl Simple SOCKS Server as a firewall in mIRC it seems to return the $serverip as 255.255.255.255.

Odd. Is that SOCKS4, SOCKS4a or SOCKS5?

Originally Posted By: HM2K
Why does mIRC return 255.255.255.255 instead of either the irc server I am connected to?

SOCKS5 (and less notably SOCKS4a) doesn't require DNS to be done at the client side. Same goes for HTTP proxies. My guess is: the domain hasn't been resolved at clientside and thus $serverip can't be determined.

Originally Posted By: HM2K
How does mIRC gather the $serverip value?

Providing it connects via SOCKS4 (not sure about mIRC's implementation for SOCKS4a, but somehow I doubt...) or directly, it needs to resolve the IP first. I agree, it's awkward that $serverip doesn't return correct values and perhaps the algorithm for connecting to proxies needs to be reviewed for next release.

Originally Posted By: argv0
Probably from RAW 001-005...

I doubt it. Raw 002 specifies the host, but there is no specific format to the message and many IRCds don't actually give an IP address within raw 001-005. I'm talking large networks, too, for example undernet, dalnet and freenode. In fact getting an IP from undernet would be most incorrect since they specify version of ircu in form uX.X.X.X where x are digits. $serverip is most likely determined if the domain name is resolved, before a connection is established.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 20/11/09 05:33 PM

@argv0 I'm not sure it does.

Feel free to try for yourself...

Just setup this on your server and connect to it...
https://ssspl.svn.sourceforge.net/svnroot/ssspl/sss.pl

I think @s00p might actually be on to something. I doubt it gathers it from the IRCd, but rather using DNS. But why it's failing to resolve it, I don't know, I can't work it out.
Posted By: s00p

Re: $serverip returns 255.255.255.255 - 20/11/09 10:28 PM

It doesn't fail to DNS the hostname at all. You're using SOCKS5, so it doesn't have to DNS the hostname. The problem is, it isn't DNSing the hostname. How is mIRC supposed to know $serverip if it doesn't DNS the hostname or the SOCKS5 proxy doesn't tell it... iirc the SOCKS5 proxy doesn't have to tell it accurately either.

The following is a rough procedure that describes the way mIRC appears to be connecting via SOCKS5 (and HTTPS?):
1. Connect to the proxy server.
2. Authenticate.
3. Connect the proxy server to the hostname provided.

The modification that's required to accurately fill in $serverip follows the same algorithm as the SOCKS4 connections:
1. DNS the hostname.
2. Pick an IP. Save it as $serverip.
3. Connect to the proxy server.
4. Authenticate.
5. Connect the proxy server to $serverip.
In reality, steps 1-2 and 3-4 could be performed independently, so they could be swapped or performed on different threads.
Posted By: argv0

Re: $serverip returns 255.255.255.255 - 21/11/09 11:15 PM

DNSing the hostname on your own would create a DNS information leak, which could potentially defeat the purpose of using a proxy if the intent is anonymity (a fair use case for a proxy). I'm no anonymity evangelist but I wouldn't recommend changing the existing behaviour-- there's a reason the DNS isn't done locally for these protocols.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 22/11/09 10:11 AM

@s00p

I don't think you really speak as an authority on this subject.

@argv0

Transparent proxies aren't designed for anonymity.

However, you seem to be implying that this is by design and in fact not a bug. Is this an accurate conclusion?
Posted By: Sat

Re: $serverip returns 255.255.255.255 - 22/11/09 12:20 PM

Originally Posted By: HM2K
Transparent proxies aren't designed for anonymity.

However, you seem to be implying that this is by design and in fact not a bug. Is this an accurate conclusion?

SOCKS4a and SOCKS5 are designed to be used in environments where, in addition to direct connections, DNS also does not work.

There is no point in making the user wait for the DNS request to time out, when the user already specified to be in such an environment by selecting SOCKS5.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 22/11/09 03:57 PM

It seems that you are saying that using SOCKS by nature means DNS won't work.

If this was the case, when connecting directly to the server ip, eg: 66.225.225.225, $serverip would return 66.225.225.225, because it wouldn't need to resolve the server hostname.

However, it does not, it returns 255.255.255.255.

I'm not convinced the issue has been properly identified.

I am still interested to know exactly where $serverip pulls the ip address from.
Posted By: argv0

Re: $serverip returns 255.255.255.255 - 23/11/09 03:33 AM

I believe this has been alluded to above, if not explicitly stated-- mIRC is not filling in $serverip in the case where it is not DNSing, and the default placeholder is apparently "255.255.255.255"... that seems to fit.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 23/11/09 05:16 PM

So I assume I can safely file this as a bug with mIRC, not my socks server.

Further more, you're saying it's not a bug in mIRC, it is in fact by design.

Do we expect that this may be developed further or is this a persistent feature (or deliberate bug)?

Otherwise, do you have any advice for users who use a socks server and wish to use $serverip?

Thanks.
Posted By: Khaled

Re: $serverip returns 255.255.255.255 - 23/11/09 06:16 PM

That's right: 255.255.255.255 is in fact the default value for a non-resolved address (INADDR_NONE). As someone mentioned in an earlier post, when using SOCKS5 mIRC does not need to resolve the address since 1) It is not connecting directly to that address, 2) The SOCKS5 server is performing the name resolution, and 3) The client may not be able to perform name resolutions.

That said, does anyone see any issues with making mIRC independently attempt a name resolution when connecting through a SOCKS5 server? On a secure/closed network that limits access through a SOCKS5 server, the worst that can happen is that the DNS fails. On the other hand, a separate DNS may show that address in your connection logs, whereas connecting through the SOCKS5 server and letting it perform the name resolution will not. Just a thought.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 23/11/09 06:35 PM

Thanks for your input Khaled, that makes more sense now.

Perhaps you can gather the server ip (if required) when $serverip is called rather than at connect time, that way the user has a choice.

That wouldn't be too difficult to impliment right?

Thanks.
Posted By: s00p

Re: $serverip returns 255.255.255.255 - 24/11/09 07:14 AM

Thankyou for confirming my belief.

You've named the section "firewall settings". Most IRCd administrators are thoroughly anti-anonymous proxy, as they allow ban evasions and fun stuff like flooding. Thus, I assume the idea behind naming it "firewall" is to imply that it should be used for application layer firewalls only. In this case, DNS may fail. IRC is also likely to fail.

If you have a look at the SOCKS4a/5 draft iirc it's slightly suggestive that the DNS features of the proxies are only to be used in the case where DNS resolution has failed locally. The most sensible way of handling this would be to add a checkbox to the "firewall settings" dialog that has the caption "resolve DNS locally", and allow input for SOCKS4a, SOCKS5 and HTTP since SOCKS4 alone has no mechanism for remote DNS resolution. The rest is self-explanitary.

Originally Posted By: HM2K
I don't think you really speak as an authority on this subject.

Originally Posted By: HM2K
Perhaps you can gather the server ip (if required) when $serverip is called rather than at connect time, that way the user has a choice.

That wouldn't be too difficult to impliment right?

That would be impossible to implement accurately in some cases. Take for example, irc.quakenet.org. DNS it using the command line:
Code:
Server:  Seven11.home
Address:  192.168.0.100

Non-authoritative answer:
Name:    irc.quakenet.org
Addresses:  213.131.156.51, 66.225.225.66, 83.140.172.212, 85.236.110.226
          128.39.2.28, 194.109.129.222, 195.54.159.109, 213.131.156.50

The proxy server will pick an IP by it's own means (which is implementation defined) and connect to it. The server may tell your client the correct IP, if it has a mechanism to do so, or it may simply tell your client 0.0.0.0 (as many SOCKS4a proxies do). Your suggestion is trash, and you have no authority either. Stop treating me like I'm some idiot.

SOCKS5 can be used for UDP communication. Another option may be to use SOCKS5 to send DNS packets over UDP.
Posted By: argv0

Re: $serverip returns 255.255.255.255 - 24/11/09 09:17 AM

I assume the DNS would occur in a separate thread? Otherwise I would see a useless delay in the worst case scenario-- the worst case scenario being common for someone using a proxy. I also think the DNS leak should also be a concern to people using a proxy.

An extra option for DNSing would probably be the best idea here, if the behaviour is changed.

In the meantime, what's wrong with /dns'ing the server manually? Why do you really need $serverip? It seems to be merely a convenience identifier.
Posted By: s00p

Re: $serverip returns 255.255.255.255 - 24/11/09 02:10 PM

It's not a useless delay, because someone still needs to do the DNS resolution. In order to obtain $serverip accurately, DNS resolution needs to be done before the tunnel is established so that the client can specify exactly which IP to connect to in the connection request. Windows uses the nameserver found in your adapter settings to query domains, then the query follows DNS RFC behaviour. Nameservers don't forward the IP of their clients.

Your argument regarding anonymity is silly, because proxies don't make you anonymous. I would be far more worried about who is running my public "anonymous" proxy, if I used one: your neighbour, the police, my IRC administrators (maybe they want to know who is flooding their network with proxies?), some hacker who wants to take advantage of vulnerable scripts that use $read insecurely...? Who do you think runs most "anonymous" proxies? Why do you think people run them, because they want people they don't know to be "anonymous"? No, they run them because they have something to gain, or because they want to secure their network using an application layer firewall (in which case they're not "anonymous").

The purpose of mIRC's proxy implementation appears to be for "application layer firewalls" (thus the word "firewall" used throughout), so there aren't many options. These, in order:
1. In most cases, a client can resolve locally.
2. In the case where a proxy implements UDP (SOCKS5), a simple DNS client can be layered on top. You'd need to find out which DNS server to query in the first place, which could result in more information disclosure than step 1. At least you'd have an IP to store for $serverip.
3. In the case where a proxy does not implement UDP, the client can send the hostname in the connection request and trust the proxy to choose an IP. The proxy may, or may not respond accurately with the IP it chose. This is the current behaviour for SOCKS5, where it should probably start at step 1 (as the SOCKS documentation suggests, IIRC). You could use the IP it responded with for $serverip (which may be the current behaviour), but that's guaranteed to be more inaccurate than the above methods.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 24/11/09 06:00 PM

I agree.

I've had a number of users ask me about why $serverip returns 255.255.255.255 instead of the server IP when using my socks server, so I guess some people would find it useful.
Posted By: Sat

Re: $serverip returns 255.255.255.255 - 24/11/09 10:07 PM

Originally Posted By: s00p
It's not a useless delay, because someone still needs to do the DNS resolution.

I think you missed the point. The proxy server will typically be able to do the DNS resolution -- the client may or may not. If the client is not, a client-side attempt at resolution incurs a delay. That is the worst case, and a realistic one at that.

Originally Posted By: s00p
Your argument regarding anonymity is silly, because proxies don't make you anonymous. I would be far more worried about who is running my public "anonymous" proxy [..]

Nobody argued that anonymity is only relevant when using a public proxy. Did you know that TOR comes with a SOCKS interface? I'm not saying that mIRC should cater to TOR users, but the argument is certainly valid. And no, if you really care about anonymity, you will not be willing to trust your ISP's nameserver either.

Originally Posted By: s00p
These, in order:
1. In most cases, a client can resolve locally.

Assumptions. I think the only legitimate proxy users will suffer from the delay caused by this assumption. And that just for $serverip? Feel free to disagree, but I think all this is just not worth it.
Posted By: argv0

Re: $serverip returns 255.255.255.255 - 24/11/09 11:47 PM

*One* purpose of proxies is indeed to deal with firewall restrictions.

*Another* perfectly valid purpose of proxies is anonymity. You may not agree with the use case (I generally don't), but it happens to be one. Just because you believe the vast majority of "anonymous proxies" are hackers doesn't justify removing behaviour for the valid use cases. A discussion about how many people use proxies responsibly is as irrelevant as a discussion about how many people use /fserve for legal content-- they're both features that should be properly implemented with the responsible users in mind. Anonymity happens to be a use case for some proxy users, and it's hardly your place to make any judgement on their behalf.

The rest was answered quite succinctly by Sat.

PS. it seems you don't quite understand what DNS Information Leak is and why it can be an issue, so here.
Posted By: s00p

Re: $serverip returns 255.255.255.255 - 26/11/09 12:34 AM

That diagram doesn't explain the DNS heirarchy sufficiently for you to understand why this isn't an anonymity issue. If that site suggests that anonymity is an issue, that site is wrong. See the second comment on that page. Also see the 7th comment on that page. The reason the leak is a "leak" is because it forces you to use a local nameserver, instead of the proxy's nameserver.

Here's a diagram that explains domain resolution for a typical Windows box:
Note, there's a local nameserver standing between you and the remote nameserver, and that local nameserver doesn't pass your IP on.

I do agree that it would be convenient for firefox (edit: and mIRC) to have a method of choosing (and forcing) between local and remote lookup, however, because proxies are sometimes used as application level firewalls. As I said earlier, the original SOCKS docs from socks.permeo.org (which has been down for years now so you'll have to trust me when I quote them) recommended that the DNS be done locally if possible, then remotely as an alternative.

Originally Posted By: original SOCKS4a docs
For version 4A, if the client cannot resolve the destination host's
domain name to find its IP address, it should set the first three bytes
of DSTIP to NULL and the last byte to a non-zero value. (This corresponds
to IP address 0.0.0.x, with x nonzero. As decreed by IANA -- The
Internet Assigned Numbers Authority -- such an address is inadmissible
as a destination IP address and thus should never occur if the client
can resolve the domain name.) Following the NULL byte terminating
USERID, the client must sends the destination domain name and termiantes
it with another NULL byte. This is used for both CONNECT and BIND requests.


See how it says, "if the client can not resolve ..."? Now, the relevant part of the SOCKS5 docs:

Originally Posted By: original SOCKS5 docs
This memo describes a protocol that is an evolution of the previous
version of the protocol, version 4 [1].


It then barely mentions domain resolution at all, aside from specifying where a domain name would belong. While perhaps you are correct in that it could incur an unwelcome delay (that wouldn't be much) for actual application level firewalls, a checkbox would remedy this. There's no security risk. In the very likely event that the client can resolve the name, I'd suggest there would be no comparable delay. As a result, $serverip would be far more likely to evaluate accurately.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 30/11/09 02:11 PM

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.
Posted By: s00p

Re: $serverip returns 255.255.255.255 - 02/12/09 01:16 PM

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.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 22/04/10 12:32 PM

@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
Posted By: Khaled

Re: $serverip returns 255.255.255.255 - 22/04/10 01:49 PM

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.
Posted By: HM2K

Re: $serverip returns 255.255.255.255 - 23/04/10 04:25 PM

@Khaled Thanks for the update smile
Posted By: Collective

Re: $serverip returns 255.255.255.255 - 29/04/10 11:08 PM

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.
Posted By: Khaled

Re: $serverip returns 255.255.255.255 - 30/04/10 09:05 AM

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.
© 2022 mIRC Discussion Forums