[dns-operations] Google (formerly also CF) public DNS sometimes forwards incomplete subset of NSEC RRs
Tony Finch
dot at dotat.at
Sun Sep 20 23:29:09 UTC 2020
Brian Somers <bsomers at opendns.com> wrote:
> This is an interesting behaviour from google. It’s not wrong…
It is wrong :-) But Viktor's description is slightly mangled.
The NSEC records that need to be present in the answer are
munin01.runbox.com. IN NSEC ipmi.mysql01.runbox.com. A RRSIG NSEC
which proves _25._tcp.mx.runbox.com does not exist (i.e. Mark's note about
the no qname proof also doing duty as closest encloser proof), and
*.runbox.com. IN NSEC _acme-challenge.runbox.com. A MX RRSIG NSEC
which says there is a wildcard that matches the qname but it doesn't have
a TLSA RRset. The zone apex isn't involved at all apart from the SOA being
part of an RFC 2308 no data type 2 response. The wildcard's NSEC doesn't
cover the qname so it isn't enough by itself.
(I prefer to call it a top-of-zone wildcard and reserve the term "apex"
for the records at the zone name below the cut.)
Tony.
--
f.anthony.n.finch <dot at dotat.at> http://dotat.at/
the widest possible distribution of wealth
More information about the dns-operations
mailing list