4.3 Processing Responses and SIG RRs

The following rules apply to the processing of SIG RRs included in a response:

1. a security aware resolver that receives a response from what it believes to be a security aware server via a secure communication with the AD bit (see Section 6.1) set, MAY choose to accept the RRs as received without verifying the zone SIG RRs.

2. in other cases, a security aware resolver SHOULD verify the SIG RRs for the RRs of interest. This may involve initiating additional queries for SIG or KEY RRs, especially in the case of getting a response from an insecure server. (As explained in 4.2 above, it will not be possible to secure CNAMEs being served up by non-secure resolvers.)

   NOTE: Implementers might expect the above SHOULD to be a MUST. However, local policy or the calling application may not require the security services.

3. If SIG RRs are received in response to a user query explicitly specifying the SIG type, no special processing is required.

   If the message does not pass reasonable checks or the SIG does not check against the signed RRs, the SIG RR is invalid and should be ignored. If all of the SIG RR(s) purporting to authenticate a set of RRs are invalid, then the set of RR(s) is not authenticated.

   If the SIG RR is the last RR in a response in the additional information section and has a type covered of zero, it is a transaction signature of the response and the query that produced the response. It MAY be optionally checked and the message rejected if the checks fail. But even if the checks succeed, such a transaction authentication SIG does NOT authenticate any RRs in the message. Only a proper SIG RR signed by the zone or a key tracing its authority to the zone or to static resolver configuration can authenticate RRs. If a resolver does not implement transaction and/or request SIGs, it MUST ignore them without error.

   If all reasonable checks indicate that the SIG RR is valid then RRs verified by it should be considered authenticated.