If there are multiple addresses available for a name server which BIND wants to contact, BIND will try the ones it believes are ``closest'' first. ``Closeness'' is defined in terms of similarity-of-address; that is, if one address is on the same subnet as some interface of the local host, then that address will be tried first. Failing that, an address which is on the same network will be tried first. Failing that, they will be tried in a more-or-less random order unless the sortlist directive was given in the named.boot file. sortlist has a syntax similar to forwarders, xfrnets, and bogusns -- you give it a list of dotted-quad networks and it uses these to ``prefer'' some remote name server addresses over others. If no explicit mask is provided with each element of a sortlist, one will be inferred based on the high order address bits.
If you are on a Class C net which has a Class B net between you and the rest of the Internet, you could try to improve the name server's luck in getting answers by listing the Class B network's number in a sortlist directive. This should have the effect of trying ``closer'' servers before the more ``distant'' ones. Note that this behaviour is new as of BIND 4.9.
The other and older effect of the sortlist directive is to cause BIND to sort the A records in any response it generates, so as to put those which appear on the sortlist earlier than those which do not. This is not as helpful as you might think, since many clients will reorder the A records either at random or using LIFO; also, consider the fact that the server won't be able to guess the client's network topology, and so will not be able to accurately order for ``closeness'' to all possible clients. Doing the ordering in the resolver is clearly superior.
In actual practice, this directive is used only rarely since it hardwires information which changes rapidly; a network which is ``close'' today may be ``distant'' next month. Since BIND builds up a cache of the remote name servers' response times, it will quickly converge on ``reasonable'' behaviour, which isn't the same as ``optimal'' but it's close enough. Future directions for BIND include choosing addresses based on local interface metrics (on hosts that have more than one) and perhaps on routing table information. We do not intend to solve the generalized ``multihomed host'' problem, but we should be able to do a little better than we're doing now. Likewise, we hope to see a higher level resolver library that sorts responses using topology information that only exists on the client's host.