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

Florian Weimer <fweimer@bfk.de> Thu, 05 March 2009 09:54 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 02CF93A690A for <ietf@core3.amsl.com>; Thu, 5 Mar 2009 01:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.249
X-Spam-Level:
X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=1.000, 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 BVVxXf9aQk4c for <ietf@core3.amsl.com>; Thu, 5 Mar 2009 01:54:50 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id E98353A68FE for <ietf@ietf.org>; Thu, 5 Mar 2009 01:54:48 -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 1LfAHj-0008QM-N2; Thu, 05 Mar 2009 10:54:35 +0100
Received: from fweimer by bfk.de with local id 1LfAHr-0005k9-CS; Thu, 05 Mar 2009 10:54:43 +0100
To: Paul Vixie <vixie@isc.org>
Subject: Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems
References: <alpine.LSU.2.00.0903041400220.8701@hermes-2.csi.cam.ac.uk> <20090304145901.GC6574@shinkuro.com> <alpine.LSU.2.00.0903041505260.7093@hermes-2.csi.cam.ac.uk> <25201.1236185908@nsa.vix.com> <alpine.LSU.2.00.0903041704350.8701@hermes-2.csi.cam.ac.uk> <37326.1236199403@nsa.vix.com>
From: Florian Weimer <fweimer@bfk.de>
Date: Thu, 05 Mar 2009 10:54:43 +0100
In-Reply-To: <37326.1236199403@nsa.vix.com> (Paul Vixie's message of "Wed, 04 Mar 2009 20:43:23 +0000")
Message-ID: <823adswazg.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:40 -0800
Cc: namedroppers@ops.ietf.org, ietf@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: Thu, 05 Mar 2009 09:54:51 -0000

* Paul Vixie:

>> Large numbers of sites have been depending on this behaviour for over 15
>> years, so it was wrong of RFC 3484 to break it.
>
> some number of vendors have depended on revenue from selling this feature
> but i'd say that only a small number of sites ever saw any benefit from it.

pool.ntp.org, security.debian.org, rsync.gentoo.org,
[a-o].ns.spamhaus.org, [a-n].surbl.org.  In general the "large RRset"
approach is used by those who do not buy special DNS appliance to
serve their zones, I think.

Many CDNs also serve multiple addresses selected from a larger pool,
probably based on network topology and server load/availability.
Those folks can mitigate Rule 9 impact by carefully tuning the address
set in each response.  But those who rely on IETF protocols to
distribute and publish their DNS data are out of luck.

(Another approach to deal with the Rule 9 fallout is to put all your
servers into a dedicated prefix, but I don't think this is a good idea
in general.)

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