4.1.3 Zone Transfer (AXFR) SIG

The above SIG mechanisms assure the authentication of all zone signed RRs of a particular name, class and type. However, to efficiently assure the completeness and security of zone transfers, a SIG RR owned by the zone name must be created with a type covered of AXFR that covers all zone signed RRs in the zone and their zone SIGs but not the SIG AXFR itself. The RRs are ordered and concatenated for hashing as described in Section 4.1.1. (See also ordering discussion in Section 5.1.)

The AXFR SIG must be calculated last of all zone key signed SIGs in the zone. In effect, when signing the zone, you order, as described above, all RRs to be signed by the zone, and all associated glue RRs and delegation point NS RRs. You can then make one pass inserting all the zone SIGs. As you proceed you hash RRs to be signed into both an RRset hash and the zone hash. When the name or type changes you calculate and insert the RRset zone SIG, clear the RRset hash, and hash that SIG into the zone hash (note that glue RRs and delegation point NSs are not zone signed but zone apex NSs are). When you have finished processing all the starting RRs as described above, you can then use the cumulative zone hash RR to calculate and insert an AXFR SIG covering the zone. Of course any computational technique producing the same results as above is permitted.

The AXFR SIG really belongs to the zone as a whole, not to the zone name. Although it should be correct for the zone name, the labels field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only retrieved as part of a zone transfer. After validation of the AXFR SIG, the zone MAY be considered valid without verification of the internal zone signed SIGs in the zone; however, any RRs authenticated by SIGs signed by entity keys or the like MUST still be validated. The AXFR SIG SHOULD be transmitted first in a zone transfer so the receiver can tell immediately that they may be able to avoid verifying other zone signed SIGs.

RRs which are authenticated by a dynamic update key and not by the zone key (see Section 3.2) are not included in the AXFR SIG. They may originate in the network and might not, in general, be migrated to the recommended off line zone signing procedure (see Section 7.2). Thus, such RRs are not directly signed by the zone, are not included in the AXFR SIG, and are protected against omission from zone transfers only to the extent that the server and communication can be trusted.