Colleagues,
this is the first version of complement to RFC8482 that specifies how the DNS requestors
and DNS responders should behave in case of RRSIG query.
1. this already describes a practice of some DNS operators (Cloudflare, NS1)
2. it is important to realize that any validating resolver can't validate RRSIG(RR)
records without receiving RDATA for RR, so RRSIG queries for signed domains
can't be cached (not without significantly increasing a complexity)
3. RRSIG queries for signed domains have a same property as ANY queries,
but they are even worse. The ANY queries have a fringe debugging property,
the RRSIG responses are just "stuffing" that is being used for reflection attacks.
I agree with the goal of this draft, and that it would be good to refuse responses
for RRSIG queries.
I wonder though if rcode REFUSED and EDE 'Not Supported' is the ideal response.
In RFC9824, we introduced EDE 30 'Invalid Query Type', and we respond with
FORMERR for the NXNAME meta-type:
Implementations like BIND and Unbound already respond to unknown q & meta-type
type codes (and any meta-type that has no defined query behavior) with FORMERR.
And we tried to formalize that in this (now expired) draft:
Maybe that behavior should be generalized to include other types that should not
be allowed in queries too like RRSIG.
If the goal is to ban RRSIG queries, FORMERR and the Invalid Query Type EDE
carries a stronger semantic (there is a format error in the query, because it contains
an invalid or disallowed protocol element). By contrast, REFUSED and 'Not Supported'
implies the server may have refused to respond by policy or because it doesn't have
an answer, but that the query is not generally disallowed.
Shumon.
