Re: interop problems with getaddrinfo() address selection

Keith Moore <moore@cs.utk.edu> Tue, 11 December 2007 00:34 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1t4m-0003ER-FL; Mon, 10 Dec 2007 19:34:20 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1t4l-0003EF-KO for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 19:34:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1t4l-0003E5-Ag for discuss@apps.ietf.org; Mon, 10 Dec 2007 19:34:19 -0500
Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1t4j-0000tB-IB for discuss@apps.ietf.org; Mon, 10 Dec 2007 19:34:19 -0500
Received: from lust.indecency.org ([168.103.150.1]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIG38618 (AUTH admin@network-heretics.com); Mon, 10 Dec 2007 16:32:41 -0800 (PST)
Message-ID: <475DDAA7.3060308@cs.utk.edu>
Date: Mon, 10 Dec 2007 16:32:39 -0800
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: interop problems with getaddrinfo() address selection
References: <Pine.LNX.4.64.0712061901020.24448@hermes-1.csi.cam.ac.uk> <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <Pine.LNX.4.64.0712071735070.24448@hermes-1.csi.cam.ac.uk> <475B0ABC.5090806@cs.utk.edu> <Pine.LNX.4.64.0712092000150.29087@hermes-1.csi.cam.ac.uk> <475C5047.3010807@cs.utk.edu> <Pine.LNX.4.64.0712100739410.29087@hermes-1.csi.cam.ac.uk> <200712101815.NAA27674@Sparkle.Rodents.Montreal.QC.CA> <Pine.LNX.4.64.0712101935070.24448@hermes-1.csi.cam.ac.uk> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA>
In-Reply-To: <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA>
X-Enigmail-Version: 0.95.5
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

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