Re: interop problems with getaddrinfo() address selection

der Mouse <mouse@Rodents.Montreal.QC.CA> Mon, 10 December 2007 23:11 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 1J1rmd-0005rm-St; Mon, 10 Dec 2007 18:11:31 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1rmc-0005rd-8Z for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 18:11:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1rmb-0005rV-VD for discuss@apps.ietf.org; Mon, 10 Dec 2007 18:11:29 -0500
Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1rma-0007CJ-Bs for discuss@apps.ietf.org; Mon, 10 Dec 2007 18:11:29 -0500
Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA01012; Mon, 10 Dec 2007 18:11:26 -0500 (EST)
Date: Mon, 10 Dec 2007 18:11:26 -0500
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
To: discuss@apps.ietf.org
Subject: Re: interop problems with getaddrinfo() address selection
In-Reply-To: <Pine.LNX.4.64.0712101935070.24448@hermes-1.csi.cam.ac.uk>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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

> 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.

For example, see this next quote, which makes sense only for the latter
meaning of "round-robin":

> (Bind does round-robin when acting as a cache as well as an
> authoritative server.)

Thanks for making my point for me :-) - this indicates that you can't
depend on a caching server preserving the order (or disorder, for that
matter) of records it receives from elsewhere.

Round-robin - this kind - is not broken per se.  Depending on it for
correctness (as opposed to efficiency) is - you cannot count on
arm's-length DNS servers doing anything you want, be it preserving or
disturbing, with the order of RRs handed to it.  If your setup depends
on spreading the load over multiple servers, then you really need to
return different addresses to different queries, not just the same
addresses in different orders.

> 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...".

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B