From nobody Thu Oct 8 17:59:15 2020 Return-Path: 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 07C823A10A4 for ; Thu, 8 Oct 2020 17:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Qbe--CuEPB-X for ; Thu, 8 Oct 2020 17:59:13 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E413A0BB9 for ; Thu, 8 Oct 2020 17:59:13 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id dg9so5327639edb.12 for ; Thu, 08 Oct 2020 17:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EUa4wFE+TPKf9YlOqgEfpJCTbcQfK+zI1kM4Ej7wJ9M=; b=T5GEL6lKxCwcihcnL5VozwEVOMrcLDRE49q2cJk7U8VNfg+0Busc52yMwAyeaTgy5x G2YJEU2f4zl+JvLDGC3i54ae2L0/0E+3TUe3DKNQ+Kk2Hu+726jWgQTPqIo+T8X3Vhol +pkXZhPU6G2kIFqrQuagy9iJtpq7NSkw8RpLmUu+/HMRMFeCFCBrQnx1aupUxbDyHuv4 +zOS7pquCbFuNiG9fFWxdykUljUrJ5+WmZBza6A0FQdxLyvwSySE46Pu4344mK8NaN/0 AVc5NhzbGgqKhnPaU4ZIFJEnKIfMjCrSYi9MiVVR8EoFQAQLRCOOzlbbeJZjJbAWoOoE HdAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EUa4wFE+TPKf9YlOqgEfpJCTbcQfK+zI1kM4Ej7wJ9M=; b=Pq1iunByvQRlF85XAlzqpq0UvrLbodoMEwL6oGK6+1h6Pd6pvduy9JbuKi9aL1R92x ycfHiAzp+LQSqxvIcOOc05QxB9bu5L+ILiLyRjth2KZ9ZAjf2QoEOAfwBgYSmJ9SHhz7 LEKP8yO2ESi1ypRhAmT2PwfcrIT8z80k9qJHlLSsXZAseqXYJ5f/c+DMYOoZ2H623tya 9JEaFIRaX/y4P/H2EKGIu3T3T0Am60x1bHoVKXQeizgokCmwrfiZQsAGsZcRxsfWwnb8 uFZL7121YrzxPk4CZG3fgDzlIoI3+F6x8zgHwefoB4GqdmmtsnJxJeaqybJusON965YA 8o+A== X-Gm-Message-State: AOAM533r+dMRe2Y1QCnEOxF7ynPoZ8k4fse3RG2XMX7A9JMl9KwPdNz+ l+tTkAlVubrvejk+molIJORbLECVZTnzQzt6W3IDMENX5oY= X-Google-Smtp-Source: ABdhPJzN4gE7cMksFy/XpFLOTeVYnkw/yso8jPrzMaSm9o89coMuGeJFbctYOwIsp+Pod6gYOMXbneFuXzuug1ruS3I= X-Received: by 2002:aa7:c256:: with SMTP id y22mr12087632edo.324.1602205151846; Thu, 08 Oct 2020 17:59:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shumon Huque Date: Thu, 8 Oct 2020 20:59:00 -0400 Message-ID: To: Nick Johnson Cc: dnsop WG Content-Type: multipart/alternative; boundary="000000000000eee74705b1327493" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 00:59:15 -0000 --000000000000eee74705b1327493 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 8, 2020 at 7:46 PM Nick Johnson wrote: > I'm reading RFC 5155, and I'm a bit puzzled by the requirement for > "closest encloser" proofs to prove nonexistence of a domain. Given that the > RFC requires generating NSEC3 records on empty non-terminals, isn't it > sufficient to examine a single NSEC3 record to prove nonexistence? > > For example, if I want to prove the nonexistence of a.b.c.example, isn't > it sufficient to validate an NSEC3 record that covers that name and is one > level higher (eg, somehash.b.c.example)? Why do I need to prove the > closest-encloser with a second NSEC3 record? > > -Nick Johnson > The closest encloser proof actually *is* what proves that the name doesn't exist. But the other reason is that for NXDOMAIN proofs, you also need to prove that the name could not have been synthesized by a wildcard. The hypothetical wildcard that might have synthesized a response for the name is constructed by prepending the asterisk label to the closest encloser. 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' This proves that b.c.example does not exist. This automatically means that all names under it, including a.b.c.example, do not exist. ### Wildcard non existence proof: * the NSEC3 RR that covers the wildcard at the closest encloser, namely '*.c.example'. Shumon Huque --000000000000eee74705b1327493 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 8, 2020 at 7:46 PM Nick Johns= on <nick=3D40ethereum.o= rg@dmarc.ietf.org> wrote:
I'm r= eading RFC 5155, and I'm a bit puzzled by the requirement for "clo= sest encloser" proofs to prove nonexistence of a domain. Given that th= e RFC requires generating NSEC3 records on empty non-terminals, isn't i= t sufficient to examine a single NSEC3 record to prove nonexistence?
<= div>
For example, if I want to prove the nonexistence of a.b.= c.example, isn't it sufficient to validate an NSEC3 record that covers = that name and is one level higher (eg, somehash.b.c.example)? Why do I need= to prove the closest-encloser with a second NSEC3 record?

-Nick Johnson

The clos= est encloser proof actually *is* what proves that the name doesn't exis= t. But the other reason is that for NXDOMAIN proofs, you also need to prove= that the name could not have been synthesized by a wildcard. The hypotheti= cal wildcard that might have synthesized a response for the name is constru= cted by prepending the asterisk label to the closest encloser.
Let's use your example and say 'a.b.c.example' doe= sn'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 -- eit= her 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 clo= sest encloser name 'c.example'
* the NSEC3 RR that covers= the next closer name 'b.c.example'

This p= roves that b.c.example does not exist. This automatically means that all na= mes under it, including a.b.c.example, do not exist.

### Wildcard non existence proof:
* the NSEC3 RR that covers t= he wildcard at the closest encloser, namely '*.c.example'.

Shumon Huque

--000000000000eee74705b1327493--