[dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs

[Viktor Dukhovni]

On Sun, Feb 28, 2021 at 08:52:38PM +0100, Vladimír Čunát wrote:

> On 2/28/21 8:47 PM, Paul Hoffman wrote:
> >> [1]https://tools.ietf.org/html/rfc8482#section-7  [tools.ietf.org]
> > That RFC (a) doesn't update RFC 4025 and (b) is only about QTYPE of "ANY".
> 
> I meant just the informal future-work note focused on QTYPE=RRSIG (in 
> the linked section), to support my claim that there are advantages in 
> avoiding full replies to such queries.

Not only are "full" replies not needed, detached from the RRSet for
which an RRSIG is the signature, the content of the RRSIG is both
useless and meaningless.  Since it can never be validated it should not
be cached.

An interoperable synthetic reply when the qname exists would be:

    <qname> 0 IN RRSIG RRSIG 255 <numlabels> 0 <0x0> <0x0> 0 <closest-encloser> AA==

A signature payload of a single 0 byte avoids potential issues with
unexpected zero-length signatures.

  * It is less clear what to do when the qname is wildcard-synthesized.
    Should there be NSEC records to validate a wildcard-based response???

My take is "no", just always set the closest encloser to equal the
qname, and let the zero TTL take care of not having such replies
stick around in caches to imply anything about the node.

Iterative resolvers should not cache RRSIG replies, regardless of TTL.

I'm writing a new stub resolver for Haskell, and even prior to this
thread my plan was to not permit RRSIG queries, because they made no
sense.  I could instead just return the above synthetic response without
asking any upstream server, but an error telling the user they're doing
the wrong thing seems more appropriate.

-- 
    Viktor.