Subject: Revised NSEC3 proof of nonexistence text

From: Ben Laurie <[email-masked]>
Date: Tue, 08 Mar 2005 17:28:58 +0000

In response to Ed's lecture, here's my second attempt:

In order to prove there are no wildcards for a domain, as well as no
RRs that match directly, an RR must be shown for the closest encloser,
and non-existence must be shown for all enclosers that could be
closer, and for the wildcard at the closest encloser.

This can be done as follows. If the QNAME in the query is
p1.p2...pn.c1.c2...cm (the reason for this notation will become
apparent) and the closest encloser is c1.c2...cm (note that p1.p2...pn
might, in practice, be a single label, but must be at least one label
long, since otherwise the QNAME would exist), then the server should
return an NSEC3 that demonstrates the nonexistence of pn.c1.c2...cm,
and NSEC3 that demonstrates the nonexistence of *.c1.c2...cm, and any
RR that demonstrates the existence of c1.c2...cm (if c1.c2...cm is an
empty non-terminal, then this will also have to be an NSEC3).

When a verifier checks this response, then the existence of
c1.c2...cm together with the non-existence of pn.c1.c2...cm proves to
it that the closest encloser is indeed c1.c2...cm (which, of course,
also proves that p1.p2...pn.c1.c2...cm does not exist). The
non-existence of *.c1.c2...cm shows that there is no wildcard at the
closest encloser, and so no source of synthesis for
p1.p2...pn.c1.c2...cm. These two facts are sufficient to satisfy the
resolver that the QNAME cannot be resolved.

In practice, since the NSEC3 owner and next names are hashed, if
the server responds with an NSEC3 for c1.c2...cm, the resolver will
have to try successively longer names, starting with cm, moving to
cm-1.cm, cm-2.cm-1.cm, and so on, until one of them hashes to a value
enclosed by one of the returned NSEC3s. Once it has done this, it
knows the closest encloser (i.e. c1.c2...cm), and can then easily
check the other two required proofs.

Note that it is not possible for one of the shorter names tried by
the resolver to be denied by one of the returned NSEC3s, since, by
definition, all these names exist and so cannot appear within the
range covered by an NSEC3. Note, however, that the first name that the
resolver tries MUST be the apex of the zone, since names above the
apex could be denied by one of the returned NSEC3s.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Alex Bligh <[email-masked]>
Date: Tue, 08 Mar 2005 19:08:25 +0000

> In response to Ed's lecture, here's my second attempt:

Must be something wrong here - I understood it first parse!

Alex