Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems
Paul Vixie <vixie@isc.org> Mon, 09 March 2009 15:54 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 313763A68C0 for <ietf@core3.amsl.com>; Mon, 9 Mar 2009 08:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level:
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599]
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 cxqpzLvw5s6S for <ietf@core3.amsl.com>; Mon, 9 Mar 2009 08:54:57 -0700 (PDT)
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 7CFF13A6C2B for <ietf@ietf.org>; Mon, 9 Mar 2009 08:54:57 -0700 (PDT)
Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 994ABA101D; Mon, 9 Mar 2009 15:55:29 +0000 (UTC) (envelope-from vixie@nsa.vix.com)
From: Paul Vixie <vixie@isc.org>
To: Florian Weimer <fweimer@bfk.de>
Subject: Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems
In-Reply-To: Your message of "Mon, 09 Mar 2009 08:43:42 +0100." <8263ijdtu9.fsf@mid.bfk.de>
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> <8263ijdtu9.fsf@mid.bfk.de>
X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1
Date: Mon, 09 Mar 2009 15:55:29 +0000
Message-ID: <46686.1236614129@nsa.vix.com>
Sender: vixie@vix.com
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: Mon, 09 Mar 2009 15:54:59 -0000
> The NTP issue is rather specific and affected ntpd when you had > > server pool.ntp.org > server pool.ntp.org > server pool.ntp.org > > in your configuration. > > And some those mirrors I mentioned are affected by *deterministic* > reordering. They don't care if traffic hits the closest instance, > they want to spread the load (security.debian.org, for instance, is > difficult to serve from a single node from time to time). thanks for explaining that. > > and the nameserver examples you gave are all subject to rdns RTT > > sorting. > > If you follow Rule 9, you haven't got that many RTTs to sort by: Rule > 10 ensures that there is a single IP address you should use as long as > the service on it is reachable. Unless you cheat, deviate from Rule > 9, contact additional servers, and gather additional RTTs--but you > have to cheat to get that data. i don't know any recursive nameservers that follow RFC 3483 for authority server selection? (your example here was of authority nameservers.) > > and they have to use drastically low TTL's to prevent mobility from > > breaking their assumptions. and they have no way to cope with opendns > > or any other global or semi-coherent caching layer. and even when they > > use TTL=0 and happen to be talking to an rdns who shares topology with > > the stub, they're making an educated guess without knowing what kinds > > of wormholes the stub may have access to, whether VPN, private > > interconnects that don't show up in global BGP, or whatever. > > Well, if it's not a good idea, why are most large web sites served > this way? nobody ever got fired for buying $whatever. so: great marketing trumps any kind of engineering whether good or bad. > I suspect there is currently no better way to distribute initial > client requests than to play DNS tricks. since the web protocols support both permanent and temporary redirects, i've always preferred approaches like IBM's over approaches like akamai's.
- 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