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
