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.