Re: [DNSOP] What is the purpose of NSEC3 "closest encloser" proofs?

Mark Andrews <marka@isc.org> Fri, 09 October 2020 03:46 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6923A1302 for <dnsop@ietfa.amsl.com>; Thu, 8 Oct 2020 20:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF92j0SeBx3M for <dnsop@ietfa.amsl.com>; Thu, 8 Oct 2020 20:46:46 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759253A1300 for <dnsop@ietf.org>; Thu, 8 Oct 2020 20:46:46 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2A6743AB0AA; Fri, 9 Oct 2020 03:46:45 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 052F0160071; Fri, 9 Oct 2020 03:46:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E85AA160073; Fri, 9 Oct 2020 03:46:44 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Noqswj-3EzvW; Fri, 9 Oct 2020 03:46:44 +0000 (UTC)
Received: from [172.30.42.67] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 8EBA6160071; Fri, 9 Oct 2020 03:46:43 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAHPuVdVm7cOGUZH45RhTT6H70cU+uUCsqpUeqV17CHFmpMf-oA@mail.gmail.com>
Date: Fri, 9 Oct 2020 14:46:36 +1100
Cc: Nick Johnson <nick@ethereum.org>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C2BC47E-4336-416F-9519-BF9EA7C0D31D@isc.org>
References: <CAFz7pMveOPbJDrLu2d8idr0xChMSCzcg_Uh_RZjPuQ9a02YpNg@mail.gmail.com> <CAHPuVdX8S0-0a_0Daxn79zh=XD-q702YTXaK4YDpxRS_eTKhKQ@mail.gmail.com> <CAFz7pMvXehUWvq1kQxm+K2Njj6L9KrP0UgCWDLg2666PEwpzEw@mail.gmail.com> <CAHPuVdVm7cOGUZH45RhTT6H70cU+uUCsqpUeqV17CHFmpMf-oA@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dp23HM1rTKspM8SjnnODfwInXZI>
Subject: Re: [DNSOP] What is the purpose of NSEC3 "closest encloser" proofs?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 09 Oct 2020 03:46:48 -0000

Or to put it another way

You can have a NSEC3 records that proves that a.b.c.example and *.b.c.example don’t exists but the wildcard you need to be checking is *.c.example when b.c.example does not exist or maybe even *.example if c.example does not exist.

Mark

> On 9 Oct 2020, at 14:13, Shumon Huque <shuque@gmail.com> wrote:
> 
> On Thu, Oct 8, 2020 at 10:38 PM Nick Johnson <nick@ethereum.org> wrote:
> 
> Let's use your example and say 'a.b.c.example' doesn't exist in the zone example.
> 
> Let's also say the longest ancestor of this name that actually does exist in the zone is 'c.example' (which could be an empty non-terminal or not -- either way, it will have an NSEC3 record matching the hash of the name).
> 
> The NXDOMAIN proof consists of:
> 
> ### Closest Encloser proof:
> * the NSEC3 RR that matches the closest encloser name 'c.example'
> * the NSEC3 RR that covers the next closer name 'b.c.example'
> 
> Right; what I don't follow is why the second of those two proofs isn't sufficient. Doesn't that alone prove that a.b.c.example doesn't exist?
> 
> It does. But the first NSEC3 is required for two reasons: the NSEC3 negative proof is defined in terms of finding the longest ancestor of the qname that does not exist, and also because we need to prove that the wildcard synthesis was not possible. Both those things require us to compute the closest encloser first.
> 
> Shumon.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org