> On Mar 2, 2021, at 2:30 PM, Peter van Dijk <[email protected]>
> 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.
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
