Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

Matt Larson <mlarson@verisign.com> Sun, 24 January 2010 01:00 UTC

Return-Path: <mlarson@verisign.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7171528C0F1 for <dnsop@core3.amsl.com>; Sat, 23 Jan 2010 17:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2
X-Spam-Level: **
X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[BAYES_80=2]
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 rj+FZF7vd38b for <dnsop@core3.amsl.com>; Sat, 23 Jan 2010 17:00:19 -0800 (PST)
Received: from mail.kahlerlarson.org (tornado.kahlerlarson.org [64.22.125.99]) by core3.amsl.com (Postfix) with ESMTP id 82B5A28C0E6 for <dnsop@ietf.org>; Sat, 23 Jan 2010 17:00:19 -0800 (PST)
Received: from sirocco.local (pool-71-178-183-75.washdc.fios.verizon.net [71.178.183.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kahlerlarson.org (Postfix) with ESMTP id 008FA37CF6 for <dnsop@ietf.org>; Sat, 23 Jan 2010 20:00:17 -0500 (EST)
Date: Sat, 23 Jan 2010 20:00:17 -0500
From: Matt Larson <mlarson@verisign.com>
To: dnsop WG <dnsop@ietf.org>
Message-ID: <20100124010017.GJ35464@sirocco.local>
References: <200904282021.n3SKL3sg051528@givry.fdupont.fr> <59A58419-FDBD-4810-B2FA-0D293FFA00A5@NLnetLabs.nl> <alpine.LFD.1.10.1001211245180.12114@newtla.xelerance.com> <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local> <alpine.LFD.1.10.1001221446090.24208@newtla.xelerance.com> <D6C3D7B5FE44C580F05A1673@nimrod.local> <alpine.LFD.1.10.1001221854270.24908@newtla.xelerance.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.1.10.1001221854270.24908@newtla.xelerance.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jan 2010 01:00:20 -0000

On Fri, 22 Jan 2010, Paul Wouters wrote:
> On Fri, 22 Jan 2010, Alex Bligh wrote:
>> I meant computational resource requirements resultant from crypto
>> operations, not algorithmic complexity.
>
> I had no problems doing this on a 1.2M domains TLD zone, using off the
> shelf hardware, integrating into the TLD's hourly update interval.
> (http://www.cira.ca/dnssec/)

Try 100M delegations, updated every 15 seconds, and sending the
resulting large non-Opt-out zone to places with poor connectivity such
as Nairobi, Kenya.

Arguments such as "I did it on once on commodity hardware with freely
available tools" or "you can implement that in an afternoon" do not
transfer well to large, critically important TLDs (or any large-scale,
critical service).

Matt