620 lines
24 KiB
Plaintext
620 lines
24 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group D. Eastlake 3rd
|
||
Request for Comments: 2137 CyberCash, Inc.
|
||
Updates: 1035 April 1997
|
||
Category: Standards Track
|
||
|
||
|
||
Secure Domain Name System Dynamic Update
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Abstract
|
||
|
||
Domain Name System (DNS) protocol extensions have been defined to
|
||
authenticate the data in DNS and provide key distribution services
|
||
[RFC2065]. DNS Dynamic Update operations have also been defined
|
||
[RFC2136], but without a detailed description of security for the
|
||
update operation. This memo describes how to use DNSSEC digital
|
||
signatures covering requests and data to secure updates and restrict
|
||
updates to those authorized to perform them as indicated by the
|
||
updater's possession of cryptographic keys.
|
||
|
||
Acknowledgements
|
||
|
||
The contributions of the following persons (who are listed in
|
||
alphabetic order) to this memo are gratefully acknowledged:
|
||
|
||
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............................................2
|
||
1.1 Overview of DNS Dynamic Update.........................2
|
||
1.2 Overview of DNS Security...............................2
|
||
2. Two Basic Modes.........................................3
|
||
3. Keys....................................................5
|
||
3.1 Update Keys............................................6
|
||
3.1.1 Update Key Name Scope................................6
|
||
3.1.2 Update Key Class Scope...............................6
|
||
3.1.3 Update Key Signatory Field...........................6
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 1]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
3.2 Zone Keys and Update Modes.............................8
|
||
3.3 Wildcard Key Punch Through.............................9
|
||
4. Update Signatures.......................................9
|
||
4.1 Update Request Signatures..............................9
|
||
4.2 Update Data Signatures................................10
|
||
5. Security Considerations................................10
|
||
References................................................10
|
||
Author's Address..........................................11
|
||
|
||
1. Introduction
|
||
|
||
Dynamic update operations have been defined for the Domain Name
|
||
System (DNS) in RFC 2136, but without a detailed description of
|
||
security for those updates. Means of securing the DNS and using it
|
||
for key distribution have been defined in RFC 2065.
|
||
|
||
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
|
||
|
||
DNS dynamic update defines a new DNS opcode, new DNS request and
|
||
response structure if that opcode is used, and new error codes. An
|
||
update can specify complex combinations of deletion and insertion
|
||
(with or without pre-existence testing) of resource records (RRs)
|
||
with one or more owner names; however, all testing and changes for
|
||
any particular DNS update request are restricted to a single zone.
|
||
Updates occur at the primary server for a zone.
|
||
|
||
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 authenticates data in the DNS by also storing digital
|
||
signatures in the DNS as SIG resource records (RRs). A SIG RR
|
||
provides a digital signature on the set of all RRs with the same
|
||
owner name and class as the SIG and whose type is the type covered by
|
||
the SIG. The SIG RR cryptographically binds the covered RR set to
|
||
the signer, time signed, signature expiration date, etc. There are
|
||
one or more keys associated with every secure zone and all data in
|
||
the secure zone is signed either by a zone key or by a dynamic update
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 2]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
key tracing its authority to a zone key.
|
||
|
||
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
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 3]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 4]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
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
|
||
|
||
Dynamic update requests depend on update keys as described in section
|
||
3.1 below. In addition, the zone secure dynamic update mode and
|
||
availability of some options is indicated in the zone key. Finally,
|
||
a special rule is used in searching for KEYs to validate updates as
|
||
described in section 3.3.
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 5]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
3.1 Update Keys
|
||
|
||
All update requests to a secure zone must include signatures by one
|
||
or more key(s) that together can authorize that update. In order for
|
||
the Domain Name System (DNS) server receiving the request to confirm
|
||
this, the key or keys must be available to and authenticated by that
|
||
server as a specially flagged KEY Resource Record.
|
||
|
||
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
|
||
|
||
The owner name of any update authorizing KEY RR must (1) be the same
|
||
as the owner name of any RRs being added or deleted or (2) a wildcard
|
||
name including within its extended scope (see section 3.3) the name
|
||
of any RRs being added or deleted and those RRs must be in the same
|
||
zone.
|
||
|
||
3.1.2 Update Key Class Scope
|
||
|
||
The class of any update authorizing KEY RR must be the same as the
|
||
class of any RR's being added or deleted.
|
||
|
||
3.1.3 Update Key Signatory Field
|
||
|
||
The four bit "signatory field" (see RFC 2065) of any update
|
||
authorizing KEY RR must be non-zero. The bits have the meanings
|
||
described below for non-zone keys (see section 3.2 for zone type
|
||
keys).
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 6]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 7]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
3.2 Zone Keys and Update Modes
|
||
|
||
Zone type keys are automatically authorized to sign anything in their
|
||
zone, of course, regardless of the value of their signatory field.
|
||
For zone keys, the signatory field bits have different means than
|
||
they they do for update keys, as shown below. The signatory field
|
||
MUST be zero if dynamic update is not supported for a zone and MUST
|
||
be non-zero if it is.
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 8]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
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
|
||
|
||
Just as a zone key is valid throughout the entire zone, update keys
|
||
with wildcard names are valid throughout their extended scope, within
|
||
the zone. That is, they remain valid for any name that would match
|
||
them, even existing specific names within their apparent scope.
|
||
|
||
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
|
||
|
||
An update can effect multiple owner names in a zone. It may be that
|
||
these different names are covered by different dynamic update keys.
|
||
For every owner name effected, the updater must know a private key
|
||
valid for that name (and the zone's class) and must prove this by
|
||
appending request SIG RRs under each such key.
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 9]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
4.2 Update Data Signatures
|
||
|
||
Mode A dynamic secure zones require that the update requester provide
|
||
SIG RRs that will authenticate the after update state of all RR sets
|
||
that are changed by the update and are non-empty after the update.
|
||
These SIG RRs appear in the request as RRs to be added and the
|
||
request must delete any previous data SIG RRs that are invalidated by
|
||
the request.
|
||
|
||
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
|
||
|
||
Any zone permitting dynamic updates is inherently less secure than a
|
||
static secure zone maintained off line as recommended in RFC 2065. If
|
||
nothing else, secure dynamic update requires on line change to and
|
||
re-signing of the zone SOA resource record (RR) to increase the SOA
|
||
serial number. This means that compromise of the primary server host
|
||
could lead to arbitrary serial number changes.
|
||
|
||
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
|
||
|
||
[RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
|
||
Extensions", RFC 2065, CyberCash, Iris, January 1997.
|
||
|
||
[RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
|
||
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
|
||
April 1997.
|
||
|
||
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
||
Specifications", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 10]
|
||
|
||
RFC 2137 SDNSDU April 1997
|
||
|
||
|
||
Author's Address
|
||
|
||
Donald E. Eastlake, 3rd
|
||
CyberCash, Inc.
|
||
318 Acton Street
|
||
Carlisle, MA 01741 USA
|
||
|
||
Phone: +1 508-287-4877
|
||
+1 508-371-7148 (fax)
|
||
+1 703-620-4200 (main office, Reston, Virginia, USA)
|
||
EMail: dee@cybercash.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 11]
|
||
|