Re: interop problems with getaddrinfo() address selection

Keith Moore <moore@cs.utk.edu> Tue, 11 December 2007 18:36 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 1J29yV-0007WH-GZ; Tue, 11 Dec 2007 13:36:59 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J29yV-0007WC-2o for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 13:36:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29yU-0007W3-PI for discuss@apps.ietf.org; Tue, 11 Dec 2007 13:36:58 -0500
Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J29yU-0006xb-GZ for discuss@apps.ietf.org; Tue, 11 Dec 2007 13:36:58 -0500
Received: from lust.indecency.org (12-46-55-205.seatac.seattwa.wayport.net [12.46.55.205]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIH35602 (AUTH admin@network-heretics.com); Tue, 11 Dec 2007 10:33:21 -0800 (PST)
Message-ID: <475ED7EF.7030009@cs.utk.edu>
Date: Tue, 11 Dec 2007 10:33:19 -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> <Pine.LNX.4.64.0712111037500.27891@hermes-1.csi.cam.ac.uk> <200712111430.JAA08747@Sparkle.Rodents.Montreal.QC.CA>
In-Reply-To: <200712111430.JAA08747@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: 7d33c50f3756db14428398e2bdedd581
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

>>> 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.
>   
which is fine if and only if it increments the zone serial # each time.

Keith