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

[Viktor Dukhovni]

> On Mar 2, 2021, at 2:30 PM, Peter van Dijk <peter.van.dijk at powerdns.com> wrote:
> 
> The earlier thread deemed both variants legitimate, in which case there
> is nothing to do. My reading of the current text is that the delegation
> response is the right one; and, as stated, my preference if we change
> anything is to, now worded better, make these queries pointless and
> allow servers to respond with absolutely nothing useful to them.

My suggestion is:

  * Stub resolvers SHOULD return errors for questions to RRSIG and NSEC3,
    rather than forward the question to any of the configured iterative
    resolvers.

  * Iterative resolvers SHOULD respond with REFUSED rather than ask for
    RRSIG or NSEC3 from any authoritative servers or upstream forwarders.

  * For RRSIG and NSEC3, authoritative servers MAY respond with REFUSED, or,
    for RRSIG, assuming the qname exists, MAY return either a synthetic answer
    of their choice or some non-empty subset of the actual RRSIG records.  For
    synthetic replies, a zero TTL answer with an arbitrary well-formed payload
    will do, there's no way to validate it and no point in caching it.

  * For NSEC, if the node is not delegated, answer naturally, otherwise return a
    delegation response.  There's no advantage to refusing NSEC queries, the requestor
    can instead ask for some random type and get the same answer, but this time
    also with an SOA record in tow.  May as well answer the NSEC query.

  * Finally, only since it was mentioned in the relevant text of 403[45],
    respond naturally to DNSKEY, that's a perfectly ordinary RRSet.

-- 
	Viktor.