Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

Edward Lewis <Ed.Lewis@neustar.biz> Fri, 22 January 2010 20:46 UTC

Return-Path: <Ed.Lewis@neustar.biz>
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 4AE0F3A67AA for <dnsop@core3.amsl.com>; Fri, 22 Jan 2010 12:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.846
X-Spam-Level:
X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 JXdRM7VkS3cO for <dnsop@core3.amsl.com>; Fri, 22 Jan 2010 12:46:08 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E31EA3A67A5 for <dnsop@ietf.org>; Fri, 22 Jan 2010 12:46:07 -0800 (PST)
Received: from [10.31.200.180] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0MKjvHv021388; Fri, 22 Jan 2010 15:45:58 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240800c77fbd63ac6b@[10.31.200.180]>
In-Reply-To: <D6C3D7B5FE44C580F05A1673@nimrod.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>
Date: Fri, 22 Jan 2010 15:45:54 -0500
To: Alex Bligh <alex@alex.org.uk>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: multipart/alternative; boundary="============_-947929338==_ma============"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Cc: dnsop WG <dnsop@ietf.org>, Alex Bligh <alex@alex.org.uk>
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: Fri, 22 Jan 2010 20:46:09 -0000

At 20:31 +0000 1/22/10, Alex Bligh wrote:


>contents) in example.org. So, whilst opt-out should be avoided
>across intervals containing secure delegations, I see no reason
>to avoid it across intervals that don't contain secure delegations.

Opt-out is restricted to "intervals" that contain only unsecured delegations.

RFC 5155:
6.  Opt-Out
... (first paragraph's last sentence):
    name of the delegation.  Setting the Opt-Out flag modifies this by
    allowing insecure delegations to exist within the signed zone without
    a corresponding NSEC3 RR at the hashed owner name of the delegation.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.