2007-05-02 »
Why doesn't netselect do reverse name lookups?
Someone asked via email about a slightly odd behaviour of netselect: when you give it a hostname that has only one IP, it'll return the hostname as the result (if that host wins the contest). If you give it a hostname with more than one IP, it'll return just the winning IP, not the hostname. Why not do a reverse lookup on the IP and get its "real", unique hostname?
The main reason I didn't reverse-resolve the names is that I didn't want to get into an endless loop of foo.com -> 1.2.3.4, 5.6.7.8 -> foo.com. If the starting name has more than one IP, there's no guarantee that the reverse name lookup will have only one IP associated with it (regardless of commonly accepted practices with DNS, which say you should never do that), so I'd have to forward look it up again to be absolutely sure I wasn't lying. This could end up tripling the time netselect spends in DNS resolution when you run it.
In the end, netselect works by choosing the fastest IP address from the list. DNS names exist so that people can move their servers around on the network without you noticing, but chances are if they do that, your netselect results will change anyway, so using the DNS name hasn't helped you. Besides, is seeing a name like HSI-KBW-085-216-115-221.hsi.kabelbw.de actually better than 85.216.115.221? It tells you the host is in Germany, but as we learn from running netselect, choosing servers based on physical geography is extremely ineffective.
...so that's my excuse. The real reason is that I was too lazy to implement the parallel DNS lookup code twice (or three times), and the existing implementation is pretty function-specific. Doing it would probably increase the code size of netselect by 50% or so.
Why would you follow me on twitter? Use RSS.