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

John C Klensin <john-ietf@jck.com> Mon, 07 July 2008 21:12 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 BB6703A68FA; Mon, 7 Jul 2008 14:12:56 -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 AC35D3A68FA for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 14:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.125
X-Spam-Level:
X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.159, 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 66j6lPuErEMM for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 14:12:54 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id AC0C43A6876 for <ietf@ietf.org>; Mon, 7 Jul 2008 14:12:53 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KFy12-000ALG-Q7; Mon, 07 Jul 2008 17:12:57 -0400
Date: Mon, 07 Jul 2008 17:12:56 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, Lyman Chapin <lyman@acm.org>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Message-ID: <18BA25DED8BFD9F794A10E84@p3.JCK.COM>
In-Reply-To: <48724347.6020500@dcrocker.net>
References: Your message of <200807022323.m62NNwVJ034275@drugs.dv.isc.org> <BLU137-W18376D2DBA85C8F712C06F93980@phx.gbl> <8953A1CE-E953-409F-A692-BD12DF4ADE61@acm.org> <48724347.6020500@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: 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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Monday, 07 July, 2008 09:24 -0700 Dave Crocker
<dhc2@dcrocker.net> wrote:

> 
> 
> Lyman Chapin wrote:
>>    If it were possible to put that aside, 
>> would you have any other objection to single label hostnames?
>> I know  that at least some of the interest in new gTLDs has
>> been expressed by  companies that like the idea of using a
>> globally-recognized trademark as  a TLD - for example,
>> "customerservice@ibm" (not to imply that IBM is one  of the
>> companies that has expressed this sort of interest).
> 
> What will be the impact of having, perhaps,
> 
>    1)  millions of entries in the root servers, and
> 
>    2)  constant traffic banging on those servers?
> 
> Historically, the view has been that bloating the root servers
> in that way would be very dangerous.
> 
> Counter-claims observe that .com seems to have survived with a
> similar storage and traffic pattern, so why should there be a
> problem moving the pattern up one level?

To answer your question with a question...

At least one rather popular DNS server implementation on a
popular platform now comes with initial configuration files that
strongly suggest local caching of the entire root zone file.
Although it may not be a universally good recommendation (and
the config file is careful to note that), it is entirely
reasonable and practical for many or most situations.  What do
you think would happen to that recommendation, and the benefits
it affords, if the size of the root zone increased by an order
of magnitude or so?  Think ICANN (or anyone else) has done
traffic projections on what would happen if the root zone were
cached at many locations on the network but had, not only the
same size but roughly the same volatility (e.g., updates due to
changes in servers or services) as COM does today and, if so,
what those analyses suggest?

    john


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