putting this issue to rest

Paul A Vixie paul at vix.com
Mon Aug 19 16:34:33 UTC 1996

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.

More information about the NANOG mailing list