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

Shumon Huque <> Fri, 09 October 2020 00:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07C823A10A4 for <>; Thu, 8 Oct 2020 17:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qbe--CuEPB-X for <>; Thu, 8 Oct 2020 17:59:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64E413A0BB9 for <>; Thu, 8 Oct 2020 17:59:13 -0700 (PDT)
Received: by 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;; 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;; 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, 08 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-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

On Thu, Oct 8, 2020 at 7:46 PM Nick Johnson <nick=> 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

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

Shumon Huque