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.
Last edited by s00p; 24/11/09 03:17 PM.