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

Paul Vixie <vixie@isc.org> Wed, 04 March 2009 22:01 UTC

Return-Path: <vixie@vix.com>
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 901973A6D33 for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 14:01:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.378
X-Spam-Level:
X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 CDBMjDSfY91A for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 14:01:04 -0800 (PST)
Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id D6C323A6D29 for <ietf@ietf.org>; Wed, 4 Mar 2009 14:01:02 -0800 (PST)
Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 75CA6A1018; Wed, 4 Mar 2009 22:01:29 +0000 (UTC) (envelope-from vixie@nsa.vix.com)
From: Paul Vixie <vixie@isc.org>
To: Ondřej Surý <ondrej.sury@nic.cz>
Subject: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
In-Reply-To: Your message of "Wed, 04 Mar 2009 21:29:54 +0100." <e90946380903041229x2ce61e85p54ee9bed71acd431@mail.gmail.com>
References: <alpine.LSU.2.00.0903041400220.8701@hermes-2.csi.cam.ac.uk> <20563.1236179832@nsa.vix.com> <e90946380903040805v15ad9e7dv92491667cd1f7656@mail.gmail.com> <36372.1236198273@nsa.vix.com> <e90946380903041229x2ce61e85p54ee9bed71acd431@mail.gmail.com>
X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1
Date: Wed, 04 Mar 2009 22:01:29 +0000
Message-ID: <41007.1236204089@nsa.vix.com>
Sender: vixie@vix.com
X-Mailman-Approved-At: Thu, 05 Mar 2009 09:29:43 -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: Wed, 04 Mar 2009 22:01:05 -0000

>    /24 - could be, but is it worth?
>    /16 - not a chance; there are a lot of LIRs with /20 in RIPE region, so
>    /16 is way too
>    much (and you can have quicker connection to U.S. than to some parts of
>    Europe).

there are three modes here.

first, you can do some good.
second, you can do some harm.
third, you can have no effect.

RFC 3484 as it is can sometimes do some good.  and if it ends up using
address similarity as an indicator of probable proximity and it's wrong,
then it'll be the same as random.  only in the case where the server is
depending on rr ordering within rrsets, which dns has never guaranteed
and which many caches (both rdns and stubs) randomize or reorder anyway,
and where the server's imputation of topology knows about every private
interconnect that may affect client performance, would RFC 3484 do harm.