[dns-operations] Google (formerly also CF) public DNS sometimes forwards incomplete subset of NSEC RRs

[Viktor Dukhovni]

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. hostmaster at copyleft.no. 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.