Re: interop problems with getaddrinfo() address selection

der Mouse <mouse@Rodents.Montreal.QC.CA> Tue, 11 December 2007 14:30 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 1J2689-0007k7-1A; Tue, 11 Dec 2007 09:30:41 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2687-0007eM-1j for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 09:30:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2686-0007eB-O2 for discuss@apps.ietf.org; Tue, 11 Dec 2007 09:30:38 -0500
Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2685-0001Q8-7E for discuss@apps.ietf.org; Tue, 11 Dec 2007 09:30:38 -0500
Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA08747; Tue, 11 Dec 2007 09:30:36 -0500 (EST)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200712111430.JAA08747@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.
Date: Tue, 11 Dec 2007 09:26:31 -0500 (EST)
To: discuss@apps.ietf.org
Subject: Re: interop problems with getaddrinfo() address selection
In-Reply-To: <Pine.LNX.4.64.0712111037500.27891@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> <200712102311.SAA01012@Sparkle.Rodents.Montreal.QC.CA> <Pine.LNX.4.64.0712111037500.27891@hermes-1.csi.cam.ac.uk>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
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

>> 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.
> That's incompatible with RFC 2181 section 5

I read through 2181 section 5 and the only thing I see that seems
plausible to me as what you're talking about is 5.1: "A query for a
specific (or non-specific) label, class, and type, will always return
all records in the associated RRSet".

All you need to do here is hold your mind a little differently - think
of it as changing the RRset instead of returning only some of the
records from an unchanging RRset.

> and DNSSEC.

(a) I don't see how it could be, assuming the mental attitude mentioned
above (a small changing RRset instead of part of a large static RRset).

(b) So, don't sign such records. :-)

/~\ 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