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

Dave Crocker <dcrocker@bbiw.net> Mon, 07 July 2008 18:06 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 B1A143A691C; Mon, 7 Jul 2008 11:06:23 -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 5145A3A691C for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 11:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level:
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[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 gAFUmFzIOvay for <ietf@core3.amsl.com>; Mon, 7 Jul 2008 11:06:22 -0700 (PDT)
Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 7FB8A3A67E3 for <ietf@ietf.org>; Mon, 7 Jul 2008 11:06:21 -0700 (PDT)
Received: from [192.168.0.3] (adsl-68-122-70-168.dsl.pltn13.pacbell.net [68.122.70.168]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m67I67sr023930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 11:06:12 -0700
Message-ID: <48725B0F.7080502@bbiw.net>
Date: Mon, 07 Jul 2008 11:06:07 -0700
From: Dave Crocker <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: John Levine <johnl@iecc.com>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
References: <20080707171926.28210.qmail@simone.iecc.com>
In-Reply-To: <20080707171926.28210.qmail@simone.iecc.com>
X-Virus-Scanned: ClamAV 0.92/7655/Mon Jul 7 07:57:40 2008 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 07 Jul 2008 11:06:13 -0700 (PDT)
Cc: 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"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


John Levine wrote:
>> What will be the impact of having, perhaps,
>>
>>   1)  millions of entries in the root servers, and
> 
> Let's start by considering thousands of entries, since I see little
> reason to expect even that many from ICANN's current plans.

When making a paradigm change to a core, infrastructure mechanism, it is best to 
assume the worst-case conditions, rather than best.

For example, I can assure you from first-hand knowledge that US$ 100K cost for a 
domain name a company deems desirable is not all that rare.  I would certainly 
not assume the global limit to be a few thousand.

More generally, the difference between allowing unbounded TLDs, versus limiting 
them by a price, involves very different strategic decision-making.  The former 
is massive and fundamental.  The latter is rather minor and likely to be viewed 
as tweaking.

So any analysis had better be made on the assumption that limits are from more 
natural and persistent characteristics, rather than from a current charging or 
operations constraints decision.


>>   2)  constant traffic banging on those servers?
> * The proportion of invalid traffic, i.e., DNS pollution, hitting the
>   roots is still high, over 99% of the queries should not even be sent
>   to the root servers. 
...
> That suggests that if the legit traffic increased by an order of
> magnitude, it would still be down in the noise compared to the junk.

Not if, for example, the 99% also grew with the added legitimate traffice.

Again, the operations rule I've been taught is to base analyses based on the 
limit of worst-case scenarios that one can tolerate, not to make assumptions 
about reasonableness (other than there won't be any.)

d/

ps. I assume (and hope) that the real DNS root experts will weigh in on this, 
here, soon...

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf