[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