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 <shu...@gmail.com> wrote: > > On Thu, Oct 8, 2020 at 10:38 PM Nick Johnson <n...@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: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
