IETF Logo Mail Archive

Re: interop problems with getaddrinfo() address selection

der Mouse <mouse@Rodents.Montreal.QC.CA> Tue, 11 December 2007 19:42 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 1J2B0D-0002AF-Vz; Tue, 11 Dec 2007 14:42:49 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J2B0D-0002AA-FH for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 14:42:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2B0D-0002A2-5d for discuss@apps.ietf.org; Tue, 11 Dec 2007 14:42:49 -0500
Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2B0B-0008TD-PG for discuss@apps.ietf.org; Tue, 11 Dec 2007 14:42:49 -0500
Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA12236; Tue, 11 Dec 2007 14:42:45 -0500 (EST)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200712111942.OAA12236@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 14:40:34 -0500
To: discuss@apps.ietf.org
Subject: Re: interop problems with getaddrinfo() address selection
In-Reply-To: <475ED7F9.3060703@network-heretics.com>
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> <475ED7F9.3060703@network-heretics.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
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

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

Agreed.

But since almost all queries do not see the zone serial, this is not
relevant to whether doing such things in normal operation is
reasonable.

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

v2.14.0 | Report a Bug | By Email