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