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

Danny Mayer <mayer@gis.net> Mon, 09 March 2009 04:24 UTC

Return-Path: <mayer@gis.net>
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 6B1C63A677E for <ietf@core3.amsl.com>; Sun, 8 Mar 2009 21:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level:
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
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 5BEU-Ezwwh8v for <ietf@core3.amsl.com>; Sun, 8 Mar 2009 21:24:25 -0700 (PDT)
Received: from gis.net (mx04.gis.net [208.218.130.12]) by core3.amsl.com (Postfix) with ESMTP id 478643A63D3 for <ietf@ietf.org>; Sun, 8 Mar 2009 21:24:24 -0700 (PDT)
Received: from [127.0.0.1] ([63.209.224.130]) by mx04.gis.net; Mon, 09 Mar 2009 00:24:39 -0400
Message-ID: <49B49A19.7090805@gis.net>
Date: Mon, 09 Mar 2009 00:24:57 -0400
From: Danny Mayer <mayer@gis.net>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
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> <823adswazg.fsf@mid.bfk.de> <93327.1236275992@nsa.vix.com>
In-Reply-To: <93327.1236275992@nsa.vix.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 09 Mar 2009 10:08:49 -0700
Cc: namedroppers@ops.ietf.org, ietf@ietf.org, Florian Weimer <fweimer@bfk.de>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mayer@gis.net
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: Mon, 09 Mar 2009 04:51:45 -0000

Paul Vixie wrote:
>>> 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.
> 
> i'm not sure we're in the same discussion.  pool.ntp.org is using short
> ttl and silent truncation and round robin.  there's no geo-ip stability
> that could be hurt by client-side reordering or rerandomizing.  and the
> nameserver examples you gave are all subject to rdns RTT sorting.  the
> "large RRset" approach works just fine, and is not related to Rule 9.
> 

pool.ntp.org divides itself up into subdomains (okay they are really
hostnames) for each country-code so that you get addresses in that
country code. NTP in the future will take advantage of the fact that it
gets back multiple addresses and will use more than just one of them to
find NTP servers. The order does not really matter and it's better that
there be no particular order so that we do not overload any one server.

Danny