Ah, yes, you’re absolutely right (as is Tony). I was getting a little bit obsessed with the zone apex. The munin01.runbox.com NSEC is required to demonstrate that mx.runbox.com doesn’t exist and that *.runbox.com is the In-scope wildcard.
Sorry for the noise. — Brian > On Sep 20, 2020, at 5:00 PM, Viktor Dukhovni <[email protected]> wrote: > > On Sun, Sep 20, 2020 at 11:41:31AM -0700, Brian Somers wrote: > >> In this case however, the presentation of *.runbox.com as an RR >> also implies that runbox.com has an NSEC. As that NSEC is not >> otherwise required, that’s enough. One record supplies the >> closest encloser and the proof that an applicable wildcard exists >> that doesn’t include the TLSA type. > > Yes, we know that "runbox.com" exists, but where's the proof that > the requested qname does not exist, required to make the wildcard > response applicable? > >>> Thanks! Looks much better now. Now it is Google's turn. I still see >>> an incomplete NSEC3 RRset from 8.8.8.8: >>> >>> $ hsdig -n8.8.8.8 -D -t tlsa _25._tcp.mx.runbox.com >>> _25._tcp.mx.runbox.com. IN TLSA ? ; NoError AD=1 >>> runbox.com. IN SOA dns61.copyleft.no. [email protected]. 3000008499 >>> 14400 3600 1296000 3600 >>> runbox.com. IN RRSIG SOA 13 2 86400 20200930104345 20200916091345 18202 >>> runbox.com. <sig> >>> *.runbox.com. IN NSEC _acme-challenge.runbox.com. A MX RRSIG NSEC >>> *.runbox.com. IN RRSIG NSEC 13 2 3600 20200930104345 20200916091345 18202 >>> runbox.com. <sig> > > Here there's only proof of the existence of the wildcard, the > non-existence of any of: > > 1. _25._tcp.mx.runbox.com. > 2. _tcp.mx.runbox.com. > 3. mx.runbox.com. > > is not established, without which the the wildcard response is bogus... > > -- > Viktor. > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
