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

From: Nick Johnson <[email-masked]>
Date: Fri, 9 Oct 2020 12:46:10 +1300

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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 8 Oct 2020 20:59:00 -0400

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

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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 8 Oct 2020 21:32:07 -0400

> either way, it will have an NSEC3 record matching the hash of the name).

One small correction to my sentence above: strike the phrase about empty
non-terminals - the closest encloser can't be an ENT of course (otherwise
it wouldn't exist either!).

Shumon.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 9 Oct 2020 12:43:00 +1100

Shumon, you where correct the first time.  A closest encloser can be a ENT

a.b.c.d.example A ...
a.e.x A ...

with QNAME a.c.c.d.example the closest encloser is the ENT c.d.example.

> On 9 Oct 2020, at 12:32, Shumon Huque <[email-masked]> wrote:
> 
> On Thu, Oct 8, 2020 at 7:46 PM Nick Johnson <nick=[email-masked]> 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).
> 
> One small correction to my sentence above: strike the phrase about empty non-terminals - the closest encloser can't be an ENT of course (otherwise it wouldn't exist either!).
> 
> Shumon.
> 
> 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.
> 
> * the NSEC3 RR that covers the wildcard at the closest encloser, namely '*.c.example'.
> 
> Shumon Huque
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Shumon Huque <[email-masked]>
Date: Thu, 8 Oct 2020 21:50:03 -0400

Indeed Mark!

I should have thought about the general case, and not the specific example
in my mail. Thanks for correcting me! :)

Shumon.

On Thu, Oct 8, 2020 at 9:43 PM Mark Andrews <[email-masked]> wrote:

> > 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 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).
> >
> > 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.
> >

---

From: Mark Andrews <[email-masked]>
Date: Fri, 9 Oct 2020 12:50:56 +1100

!@#$!@#$ mail client.

a.b.c.d.example A …
a.e.c.d.example A … 

> On 9 Oct 2020, at 12:43, Mark Andrews <[email-masked]> wrote:
>

---

From: Nick Johnson <[email-masked]>
Date: Fri, 9 Oct 2020 15:38:13 +1300

> * 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?

---

From: Shumon Huque <[email-masked]>
Date: Thu, 8 Oct 2020 23:13:34 -0400

> 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.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 9 Oct 2020 14:46:36 +1100

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 <[email-masked]> wrote:
> 
> 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.
>

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 9 Oct 2020 08:24:25 +0200

Hello Nick,

The closest encloser proof is explained in RFC 7129, Section 5.5.

    https://tools.ietf.org/html/rfc7129#section-5.5

Best regards,

Matthijs

On 10/9/20 1:46 AM, Nick Johnson wrote:
> "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?
> 
> 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