Re: [DNSOP] Why does RFC 4035 allows a security-aware authoritative name server to not send RRSIG RRs that a security-aware resolver can use to authenticate the RRsets in the response?

[Paul Wouters <[e-mail]>]

On Thu, 13 Jan 2022, Joey Deng wrote:

> In RFC 4035 3.1.1. Including RRSIG RRs in a Response, it says:
>
>>    When responding to a query that has the DO bit set, a security-aware
>>    authoritative name server SHOULD attempt to send RRSIG RRs that a
>>    security-aware resolver can use to authenticate the RRsets in the
>>    response.  A name server SHOULD make every attempt to keep the RRset
>>    and its associated RRSIG(s) together in a response.  Inclusion of
>>    RRSIG RRs in a response is subject to the following rules:
>
> All the statements above use SHOULD, which means RECOMMENDED, which means that there exists valid reasons in particular circumstances to NOT SEND RRSIG RRs with the RRSet in the response.
> However, the paragraph below it uses MUST:
>
>>       o  When placing a signed RRset in the Answer section, the name server
>>       MUST also place its RRSIG RRs in the Answer section.  The RRSIG
>>       RRs have a higher priority for inclusion than any other RRsets
>>       that may have to be included.  If space does not permit inclusion
>>       of these RRSIG RRs, the name server MUST set the TC bit.
>
> It would be very helpful if someone could help me understand this SHOULD/MUST behavior difference

Likely people were overly caution at the time of writing?

> 1. What are the particular circumstances in which a name server is allowed to do that?
>
> 2. One case I can think of is truncation, is truncation the only situation allowed to not include RRSIG?

Truncation should happen on the RRset + RRSIG. Eg either you include the
RRset+RRSIG, or you omit it entirely. You shouldn't just omit the
signature.

Paul