Re: Update of RFC 2606 based on the recent ICANN changes ?

Joe Abley <jabley@ca.afilias.info> Tue, 08 July 2008 02:55 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70BB3A6A23; Mon, 7 Jul 2008 19:55:02 -0700 (PDT)
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 79C5B3A6A23 for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 19:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level:
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
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 t105MG1L-x3K for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 19:55:00 -0700 (PDT)
Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id D29F63A6920 for <ietf@ietf.org>; Mon, 7 Jul 2008 19:54:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=V5Rw8zTaGy7r7kbnDSI1NOQ0cQDu/Ajv2FrD4bnU/P6CYRfxaa2RmnLFQOyPT9/7fHK+Wfvz6kQleqdF1d+3l3lLg/4ds4JwA/p+XW2dPtrMxcZZhTvJeCEGrGAwo5jC;
Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>) id 1KG3Pf-000C4m-Ev; Tue, 08 Jul 2008 02:58:43 +0000
Message-Id: <49D74735-AB16-4ABE-B626-EF7BC099EAD9@ca.afilias.info>
From: Joe Abley <jabley@ca.afilias.info>
To: James Seng <james@seng.sg>
In-Reply-To: <558a39a60807071836s38244439g4054b1175a976454@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Date: Mon, 07 Jul 2008 22:55:01 -0400
References: <200807022323.m62NNwVJ034275@drugs.dv.isc.org> <BLU137-W18376D2DBA85C8F712C06F93980@phx.gbl> <8953A1CE-E953-409F-A692-BD12DF4ADE61@acm.org> <48724347.6020500@dcrocker.net> <18BA25DED8BFD9F794A10E84@p3.JCK.COM> <4872BF88.5040706@bbiw.net> <558a39a60807071836s38244439g4054b1175a976454@mail.gmail.com>
X-Mailer: Apple Mail (2.926)
Cc: John C Klensin <john-ietf@jck.com>, Dave Crocker <dcrocker@bbiw.net>, IETF Discussion <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-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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 7 Jul 2008, at 21:36, James Seng wrote:

>> And all of the questions I asked 10 years ago said that TLDs on  
>> that latter
>> scale would be problematic to the root.
>
> Was that pre-Anycast or post-Anycast?

There are plenty of examples of people hosting large, infrastructure- 
type zones using servers and software that are conventional, commodity  
choices. NSD and BIND9 are both quite capable of hosting zones with  
single-digit millions of delegations without needing special care and  
feeding, for example.

Whether the DNS service for a zone is anycast or not has some, but  
really not that much relevance when you're considering the risk of an  
engorged root zone. I don't read anything in the layer-9 musings I've  
seen so far to suggest that the bar to entry for new TLDs will be so  
low that we'll see widespread TLD tasting and churn, for example,  
sufficient to make far-flung anycast instances struggle to keep up.

I'm not suggesting that growth should be allowed to happen without  
considering the technical consequences. However, I believe in practice  
with the headroom in systems and network that root server operators  
generally install anyway, there's considerable room for growth and the  
general argument that growth in the root zone will undermine stability  
sounds more like hysteria than science.


Joe
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf