Executive summary: This is a getconninfo()/gethostbyaddr() issue rather than a res_send() one. See the SONAR and SRV drafts to understand the current (published) thinking. Detailed view:
Nope. Not only is DNS not a good directory system (see my comments on ".COM is full" on the ietf list last year), it's not a good routing system either. That it can be abused to either purpose is not significant, since 99% of the people and companies who will be on the Internet aren't here yet.
Paul, do you know of anyone who has done work on code to pick the best choice (ie, closest, fastest) from a list a multiple A records? Or on a name server that hands out "the best" A record.
From RFC 1034:
| 3.6. Resource Records | | A domain name identifies a node. Each node has a set of resource | information, which may be empty. The set of resource information | associated with a particular name is composed of separate resource | records (RRs). The order of RRs in a set is not significant, and need | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | not be preserved by name servers, resolvers, or other parts of the DNS. | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This means even if a DNS server had complete knowledge of the network topology (so that it could order things appropriately for each client), and there was no caching going on (so that the person asking the question was always an end host, never a forwarding or recursive server), there is absolutely no guarantee that the host receiving such an "ordered set" would use it in the order given.
From RFC 1035:
| 7.4. Using the cache | | In general, we expect a resolver to cache all data which it receives in | responses since it may be useful in answering future client requests. | However, there are several types of data which should not be cached: | | - When several RRs of the same type are available for a | particular owner name, the resolver should either cache them | all or none at all. When a response is truncated, and a | resolver doesn't know whether it has a complete set, it should | not cache a possibly partial set of RRs. This means the expected trick of sending only one A RR when several exist (since a set of 1 always has a stable order) won't work either, unless we set the TTL to zero on all responses containing A RRs for that name, which would defeat caching (which would be really, really horrible). Thus, I coauthored <draft-gulbrandsen-dns-rr-srvcs-03.txt>, now making its final approach toward specification (as a proposed standard RFC) and toward implementation (BIND 4.9.5, now in private alpha testing, supports it). SRV is not a complete solution but it's a step in the right direction. Matthew Dillon remarked here a while back that HTTP redirects are another way of approaching this problem. If we don't care about other protocols (and the traffic statistics say we don't need to, at least right now), that's fine. Keith Moore authored <draft-moore-sonar-01.txt> to help a host determine which of several addresses was "best"; SONAR and SRV together would be a powerful combination, and we can only pray that Microsoft and Netscape and Cisco each adopt both. Perhaps someone within the sound of my voice will decide to start a free implementation as a proof of concept. Shameless plug: This message has been brought to you by the Internet Software Consortium, without whose funding I would have to be doing honest work right this second. If you think the ISC is doing good work, plz consider sending in a donation to Carl Malamud, ISC's director. ISC's current grant runs out on December 31. ISC is a registered 501(c)3 and donations are tax deductible. The WWW page is <URL:http://www.isc.org/isc/> if you want to know what we've been up to.