[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?

[Joey Deng <[e-mail]>]

Hello,

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

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?

3. If the name server is allowed to only include the RRSet, how could the security-aware resolver fetch the missing RRSIG separately (A specific RFC would be very helpful!)? 
(I tried to use dig to send query for RRSIG explicitly, but it seems that the name server will only return partial result or no result for the RRSIG query, so I guess the result of RRSIG query is similar to the result of type ANY query?).

Thanks.

--
Joey Deng