Secure Domain Name System Dynamic Update

Status of this Memo

Abstract

Acknowledgements

      Olafur Gudmundsson (ogud@tis.com>
      Charlie Kaufman <Charlie_Kaufman@iris.com>
      Stuart Kwan <skwan@microsoft.com>
      Edward Lewis <lewis@tis.com>
 

Table of Contents

1. Introduction

This memo proposes techniques based on the defined DNS security mechanisms to authenticate DNS updates.

Familiarity with the DNS system [RFC 1034, 1035] is assumed. Familiarity with the DNS security and dynamic update proposals will be helpful.
 

1.1 Overview of DNS Dynamic Update

The primary server for a secure dynamic zone must increment the zone SOA serial number when an update occurs or the next time the SOA is retrieved if one or more updates have occurred since the previous SOA retrieval and the updates themselves did not update the SOA.
 

1.2 Overview of DNS Security

DNS security also defines transaction SIGs and request SIGs. Transaction SIGs appear at the end of a response.  Transaction SIGs authenticate the response and bind it to the corresponding request with the key of the host where the responding DNS server is.  Request SIGs appear at the end of a request and authenticate the request with the key of the submitting entity.

Request SIGs are the primary means of authenticating update requests.

DNS security also permits the storage of public keys in the DNS via KEY RRs.  These KEY RRs are also, of course, authenticated by SIG RRs.  KEY RRs for zones are stored in their superzone and subzone servers, if any, so that the secure DNS tree of zones can be traversed by a security aware resolver.
 

2. Two Basic Modes

                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.
 

3. Keys

3.1 Update Keys

The scope of authority of such keys is indicated by their KEY RR owner name, class, and signatory field flags as described below. In addition, such KEY RRs must be entity or user keys and not have the authentication use prohibited bit on.  All parts of the actual update must be within the scope of at least one of the keys used for a request SIG on the update request as described in section 4.
 

3.1.1 Update Key Name Scope

3.1.2 Update Key Class Scope

3.1.3 Update Key Signatory Field

                 UPDATE KEY RR SIGNATORY FIELD BITS

      0           1           2           3
+-----------+-----------+-----------+-----------+
|   zone    |  strong   |  unique   |  general  |
+-----------+-----------+-----------+-----------+

Bit 0, zone control - If nonzero, this key is authorized to attach,
     detach, and move zones by creating and deleting NS, glue A, and
     zone KEY RR(s).  If zero, the key can not authorize any update
     that would effect such RRs.  This bit is meaningful for both
     type A and type B dynamic secure zones.

     NOTE:  do not confuse the "zone" signatory field bit with the
     "zone" key type bit.

Bit 1, strong update - If nonzero, this key is authorized to add and
     delete RRs even if there are other RRs with the same owner name
     and class that are authenticated by a SIG signed with a
     different dynamic update KEY. If zero, the key can only
     authorize updates where any existing RRs of the same owner and
     class are authenticated by a SIG using the same key.  This bit
     is meaningful only for type A dynamic zones and is ignored in
     type B dynamic zones.

     Keeping this bit zero on multiple KEY RRs with the same or
     nested wild card owner names permits multiple entities to exist
     that can create and delete names but can not effect RRs with
     different owner names from any they created.  In effect, this
     creates two levels of dynamic update key, strong and weak, where
     weak keys are limited in interfering with each other but a
     strong key can interfere with any weak keys or other strong
     keys.

Bit 2, unique name update - If nonzero, this key is authorized to add
     and update RRs for only a single owner name.  If there already
     exist RRs with one or more names signed by this key, they may be
     updated but no new name created until the number of existing
     names is reduced to zero.  This bit is meaningful only for mode
     A dynamic zones and is ignored in mode B dynamic zones. This bit
     is meaningful only if the owner name is a wildcard.  (Any
     dynamic update KEY with a non-wildcard name is, in effect, a
     unique name update key.)

     This bit can be used to restrict a KEY from flooding a zone with
     new names.  In conjunction with a local administratively imposed
     limit on the number of dynamic RRs with a particular name, it
     can completely restrict a KEY from flooding a zone with RRs.

Bit 3, general update - The general update signatory field bit has no
     special meaning.  If the other three bits are all zero, it must
     be one so that the field is non-zero to designate that the key
     is an update key.  The meaning of all values of the signatory
     field with the general bit and one or more other signatory field
     bits on is reserved.

All the signatory bit update authorizations described above only apply if the update is within the name and class scope as per sections 3.1.1 and 3.1.2.
 

3.2 Zone Keys and Update Modes

                  ZONE KEY RR SIGNATORY FIELD BITS

               0           1           2           3
         +-----------+-----------+-----------+-----------+
         |   mode    |  strong   |  unique   |  general  |
         +-----------+-----------+-----------+-----------+

Bit 0, mode - This bit indicates the update mode for this zone.  Zero
     indicates mode A while a one indicates mode B.

Bit 1, strong update - If nonzero, this indicates that the "strong"
     key feature described in section 3.1.3 above is implemented and
     enabled for this secure zone.  If zero, the feature is not
     available.  Has no effect if the zone is a mode B secure update
     zone.

Bit 2, unique name update - If nonzero, this indicates that the
     "unique name" feature described in section 3.1.3 above is
     implemented and enabled for this secure zone.  If zero, this
     feature is not available.  Has no effect if the zone is a mode B
     secure update zone.

Bit 3, general - This bit has no special meeting.  If dynamic update
     for a zone is supported and the other bits in the zone key
     signatory field are zero, it must be a one.  The meaning of zone
     keys where the signatory field has the general bit and one or
     more other bits on is reserved.

If there are multiple dynamic update KEY RRs for a zone and zone policy is in transition, they might have different non-zero signatory fields.  In that case, strong and unique name restrictions must be enforced as long as there is a non-expired zone key being advertised that indicates mode A with the strong or unique name bit on
respectively.  Mode B updates MUST be supported as long as there is a non-expired zone key that indicates mode B.  Mode A updates may be treated as mode B updates at server option if non-expired zone keys indicate that both are supported.

A server that will be executing update operations on a zone, that is, the primary master server, MUST not advertize a zone key that will attract requests for a mode or features that it can not support.
 

3.3 Wildcard Key Punch Through

If this were not so, then whenever a name within a wildcard scope was created by dynamic update, it would be necessary to first create a copy of the KEY RR with this name, because otherwise the existence of the more specific name would hide the authorizing KEY RR and would make later updates impossible.  An updater could create such a KEY RR but could not zone sign it with their authorizing signer.  They would have to sign it with the same key using the wildcard name as signer.
Thus in creating, for example, one hundred type A RRs authorized by a *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100 KEYs, and 200 SIGs would have to be created as opposed to merely 100 As and 100 SIGs with key punch through.
 

4. Update Signatures

Two kinds of signatures can appear in updates.  Request signatures, which are always required, cover the entire request and authenticate the DNS header, including opcode, counts, etc., as well as the data. Data signatures, on the other hand, appear only among the RRs to be added and are only required for mode A operation.  These two types of signatures are described further below.
 

4.1 Update Request Signatures

As specified in RFC 2065, a request signature is a SIG RR occurring at the end of a request with a type covered field of zero.  For an update, request signatures occur in the Additional information section.  Each request SIG signs the entire request, including DNS header, but excluding any other request SIG(s) and with the ARCOUNT in the DNS header set to what it wold be without the request SIGs.
 

4.2 Update Data Signatures

In Mode B dynamic secure zones, all zone data is authenticated by zone key SIG RRs.  In this case, data signatures need not be included with the update.  A resolver can determine which mode an updatable secure zone is using by examining the signatory field bits of the zone KEY RR (see section 3.2).
 

5. Security Considerations

Isolation of dynamic RRs to separate zones from those holding most static RRs can limit the damage that could occur from breach of a dynamic zone's security.
 

References

Author's Address

Phone:   +1 508-287-4877
         +1 508-371-7148 (fax)
         +1 703-620-4200 (main office, Reston, Virginia, USA)
EMail:   dee@cybercash.com