Re: interop problems with getaddrinfo() address selection

[Keith Moore <[e-mail]>]

der Mouse wrote:
>> Services that use round robin DNS do not depend on preserved record
>> ordering: quite the opposite, they depend on disordering.
>>     
>
> Hmm?  It appears we're talking about differnet things.  To me, DNS
> round-robin refers to the sort of thing the NTP pool project does:
> rotating the answer(s) returned in response to a query through a larger
> (usually much larger) set of possible answers.  It sounds as though
> you're talking about simply returning all the answers and hoping that,
> somewhere along the line, someone will end up choosing one in a way
> that looks random with respect to the property you care about.
>   
mumble.  if what the site really wants it for the client to pick an
address at random, then having something besides the DNS server
randomize the order of the results doesn't matter so much.   (but if the
client sorts the addresses, the randomness is lost regardless of how
many random reorderings were imposed between DNS and the client).

on the other hand, if the site is trying to do dynamic load-balancing
with DNS by having DNS favor lightly-used servers, then reordering does
matter.
>> You can claim it's broken until you are blue in the face, but it
>> works in practice and it is widely documented (though not by the
>> IETF) without caveats.
>>     
>
> Whey I say it's broken to depend on it, what I mean is, it may "work",
> but if/when it fails, it's _your_ bug, and it's unreasonable to expect
> others to change to work around it.  Documentation implying otherwise
> may exist, but, if so, it's wrong.  1034 section 3.6: "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.".  5.2.1 item 1: "Since the DNS
> does not preserve the order of RRs," - the rest of this particular
> quote is actually relevant to the issue that started this thread:
> "...[name to address translation] may choose to sort the returned
> addresses..."
you and I (and I expect Tony also) agree on that.  but practically
speaking it makes little difference.  if a feature that used to "work"
in IPv4 (even if by coincidence or accident) fails to work in IPv6, IPv6
will get blamed.  and this may hinder adoption of IPv6.  most of the
people affected by this won't bother to read through the RFCs to see who
is really to blame.

Keith