2. Two Basic Modes

A dynamic secure zone is any secure DNS zone containing one or more KEY RRs that can authorize dynamic updates, i.e., entity or user KEY RRs with the signatory field non-zero, and whose zone KEY RR signatory field indicates that updates are implemented. There are two basic modes of dynamic secure zone which relate to the update strategy, mode A and mode B. A summary comparison table is given below and then each mode is described.

                   SUMMARY OF DYNAMIC SECURE ZONE MODES


   CRITERIA:                |   MODE A           |   MODE B
   =========================+====================+===================
   Definition:              | Zone Key Off line  | Zone Key On line
   =========================+====================+===================
   Server Workload          |   Low              |   High
   -------------------------+--------------------+-------------------
   Static Data Security     |   Very High        |   Medium-High
   -------------------------+--------------------+-------------------
   Dynamic Data Security    |   Medium           |   Medium-High
   -------------------------+--------------------+-------------------
   Key Restrictions         |   Fine grain       |   Coarse grain
   -------------------------+--------------------+-------------------
   Dynamic Data Temporality |   Transient        |   Permanent
   -------------------------+--------------------+-------------------
   Dynamic Key Rollover     |   No               |   Yes
   -------------------------+--------------------+-------------------

For mode A, the zone owner key and static zone master file are always kept off-line for maximum security of the static zone contents.

As a consequence, any dynamicly added or changed RRs are signed in the secure zone by their authorizing dynamic update key and they are backed up, along with this SIG RR, in a separate online dynamic master file. In this type of zone, server computation is minimized since the server need only check signatures on the update data and request, which have already been signed by the updater, generally a much faster operation than signing data. However, the AXFR SIG and NXT RRs which covers the zone under the zone key will not cover dynamically added data. Thus, for type A dynamic secure zones, zone transfer security is not automatically provided for dynamically added RRs, where they could be omitted, and authentication is not provided for the server denial of the existence of a dynamically added type. Because the dynamicly added RRs retain their update KEY signed SIG, finer grained control of updates can be implemented via bits in the KEY RR signatory field. Because dynamic data is only stored in the online dynamic master file and only authenticated by dynamic keys which expire, updates are transient in nature. Key rollover for an entity that can authorize dynamic updates is more cumbersome since the authority of their key must be traceable to a zone key and so, in general, they must securely communicate a new key to the zone authority for manual transfer to the off line static master file. NOTE: for this mode the zone SOA must be signed by a dynamic update key and that private key must be kept on line so that the SOA can be changed for updates.

For mode B, the zone owner key and master file are kept on-line at the zone primary server. When authenticated updates succeed, SIGs under the zone key for the resulting data (including the possible NXT type bit map changes) are calculated and these SIG (and possible NXT) changes are entered into the zone and the unified on-line master file. (The zone transfer AXFR SIG may be recalculated for each update or on demand when a zone transfer is requested and it is out of date.)

As a consequence, this mode requires considerably more computational effort on the part of the server as the public/private keys are generally arranged so that signing (calculating a SIG) is more effort than verifying a signature. The security of static data in the zone is decreased because the ultimate state of the static data being served and the ultimate zone authority private key are all on-line on the net. This means that if the primary server is subverted, false data could be authenticated to secondaries and other servers/resolvers. On the other hand, this mode of operation means that data added dynamically is more secure than in mode A. Dynamic data will be covered by the AXFR SIG and thus always protected during zone transfers and will be included in NXT RRs so that it can be falsely denied by a server only to the same extent that static data can (i.e., if it is within a wild card scope). Because the zone key is used to sign all the zone data, the information as to who originated the current state of dynamic RR sets is lost, making unavailable the effects of some of the update control bits in the KEY RR signatory field. In addition, the incorporation of the updates into the primary master file and their authentication by the zone key makes then permanent in nature. Maintaining the zone key on-line also means that dynamic update keys which are signed by the zone key can be dynamically updated since the zone key is available to dynamically sign new values.

NOTE: The Mode A / Mode B distinction only effects the validation and performance of update requests. It has no effect on retrievals. One reasonable operational scheme may be to keep a mostly static main zone operating in Mode A and have one or more dynamic subzones operating in Mode B.