DNS security would like to view each zone as a unit of data completely under the control of the zone owner and signed by the zone's key. But the operational DNS views the leaf nodes in a zone, which are also the apex nodes of a subzone (i.e., delegation points), as "really" belonging to the subzone. These nodes occur in two master files and may have RRs signed by both the upper and lower zone's keys. A retrieval could get a mixture of these RRs and SIGs, especially since one server could be serving both the zone above and below a delegation point.
In general, there must be a zone KEY RR for the subzone in the superzone and the copy signed in the superzone is controlling. For all but one other RR type that should appearing in both the superzone and subzone, the data from the subzone is more authoritative. To avoid conflicts, only the KEY RR in the superzone should be signed and the NS and any A (glue) RRs should only be signed in the subzone. The SOA and any other RRs that have the zone name as owner should appear only in the subzone and thus are signed there. The NXT RR type is an exceptional case that will always appear differently and authoritatively in both the superzone and subzone, if both are secure, as described in Section 5.