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
- RFC 3484 section 6 rule 9 causing more operationa… Tony Finch
- Re: RFC 3484 section 6 rule 9 causing more operat… Andrew Sullivan
- Re: RFC 3484 section 6 rule 9 causing more operat… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- RE: [dnsext] RFC 3484 section 6 rule 9 causing mo… Christian Huitema
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Florian Weimer
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Nicholas Weaver
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Ondřej Surý
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Mark Andrews
- Re: RFC 3484 section 6 rule 9 causing more operat… Jari Arkko
- Re: RFC 3484 section 6 rule 9 causing more operat… Tim Chown
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… bmanning
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Chris Thompson
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Florian Weimer
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Florian Weimer
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Florian Weimer
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Ondřej Surý
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Ondřej Surý
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Paul Vixie
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Paul Vixie
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Danny Mayer
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Ask Bjørn Hansen
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Florian Weimer
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Danny Mayer
- Re: RFC 3484 section 6 rule 9 causing more operat… Arifumi Matsumoto