IETF Logo Mail Archive

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

Florian Weimer <fweimer@bfk.de> Wed, 04 March 2009 18:01 UTC

Return-Path: <fweimer@bfk.de>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D9528C0E0 for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 10:01:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.178
X-Spam-Level:
X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nj3CCne9j0kv for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 10:01:08 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 822AC28C148 for <ietf@ietf.org>; Wed, 4 Mar 2009 10:01:07 -0800 (PST)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1LevP0-0004bs-2R; Wed, 04 Mar 2009 19:01:06 +0100
Received: from fweimer by bfk.de with local id 1LevPF-0000JG-0W; Wed, 04 Mar 2009 19:01:21 +0100
To: Christian Huitema <huitema@windows.microsoft.com>
Subject: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
References: <alpine.LSU.2.00.0903041400220.8701@hermes-2.csi.cam.ac.uk> <20563.1236179832@nsa.vix.com> <alpine.LSU.2.00.0903041531250.8701@hermes-2.csi.cam.ac.uk> <8EFB68EAE061884A8517F2A755E8B60A1CB2DFD5C2@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
From: Florian Weimer <fweimer@bfk.de>
Date: Wed, 04 Mar 2009 19:01:20 +0100
In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1CB2DFD5C2@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> (Christian Huitema's message of "Wed, 4 Mar 2009 09:21:46 -0800")
Message-ID: <828wnl1827.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 05 Mar 2009 09:27:04 -0800
Cc: Paul Vixie <vixie@isc.org>, "ietf@ietf.org" <ietf@ietf.org>, "namedroppers@ops.ietf.org" <namedroppers@ops.ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2009 18:01:09 -0000

* Christian Huitema:

> The order of5C records in a DNS response is, at best, a
> hint. Relying on it as if it were a mandate to clients is a gamble.

When you run RRset-based load balancing, you don't rely on servers
preserving order, or reordering responses.  It is completely
sufficient that there is a certain amount of variation among resolver
and application address selection.  It has been repeatedly and
independently observed that Rule 9 does not provide sufficient
variance, in contrast to previous behavior.

Rule 9 is also unfortunate because it means that after renumbering,
server loads change in ways the operator cannot influence (except by
requesting addresses with certain bit patterns, but I don't think
anybody wants vanity IP addresses).

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

v2.23.0 | Report a Bug | By Email