[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04                                                
DNSOP WG                                            Edward Lewis
INTERNET DRAFT                                      NAI Labs
Category: I-D                                       October 19, 1999

                    Handling of DNS zone signing keys

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

Comments should be sent to the authors or the DNSOP WG mailing list

This draft expires on April 19, 2000.

Copyright Notice

Copyright (C) The Internet Society (1999).  All rights reserved.


DNS Security Extensions require a greater interaction between zone
administrations sharing a zone cut.  The center of the interaction is
the handling of the zone keys of the child and the signature applied
by the parent.  DNSSEC does not include a protocol for this, but the
means of this interaction need definition to maintain the security of

1 Introduction

DNS Security Extensions require a greater interaction between zone
administrations sharing a zone cut.  The center of the interaction is
the handling of the zone keys of the child and the signature applied
by the parent.  DNSSEC does not include a protocol for this, but the
means of this interaction need definition to maintain the security of

This document discusses the issues defining the problems of handling
zone signing keys.  The document begins with an introduction to keys,

Expires April 19, 2000                                      [Page  1]
Internet Draft                                       October 19, 1999

delegations, and security. Following this, a few concepts are
described that will have an impact on the discussion to follow.  The
heart of the document discusses how a key is handled during its
lifetime and how keys are transferred between organizations.  Finally,
some of the surrounding issues are discussed in more detail.

This document is a straw man of the interaction between a parent and
child zone.  Comments, clarifications, additions and deletions are

1.1 Usage of the KEY RR

Before discussing how keys are to be handled, the different kinds of
keys in KEY RRs and the different roles keys play must be introduced.

Throughout this document, a key is either the pair of asymmetric keys
or one of the pair.  Symmetric keys are not able to be zone signing
keys. A "zone key" refers to the public key of a private-public pair.

The phrase "the zone keys signs data" is used throughout the document.
This should be read as "the private key corresponding to a public key
marked as a zone key signs data."  In subsequent editions of this
document, the wording will become more accurate.

1.1.1 Zone keys signing DNS contents

The key of primary interest is the zone key.  A zone key is stored at
the apex of the zone and has the zone key bit flag on.  Zone keys can
only be at the apex name of a zone.  In order to be valid, the zone
key must be signed by an appropriate authority, most commonly the

Policy governing the authentication of data in general, and keys in
particular is not well defined.  This document will stay neutral on
the issue also, so defining the validity of a key is not further

1.1.2 Non-zone keys signing DNS contents

A non-zone key may be allowed to sign some data in the zone.  The
range of names that such a key may sign is limited in scope compared
to a zone key.  The non-zone key must be signed by a zone key and have
signing flags and key strength bits set accordingly.  Such a key may
be most useful with dynamic update.

All signing keys must have their flag bits set to allow
authentication, and the protocol field set to either DNSSEC or ANY.
This applies to zone keys as well.

**** Addition to the 01 version ****

There is a proposal to restrict valid signatures of data to signatures
corresponding to DNSSEC (or ANY) protocol zone keys.  Only the zone's
apex can own a zone key.  Non-zone keys, whether the keys are owned by

Expires April 19, 2000                                      [Page  2]
Internet Draft                                       October 19, 1999

the apex or at another name will be used only for transaction
security.  The proposal is documented in [TSIG].

This change, if accepted, would mean that Non-zone keys would not be
acceptable when verifying DNS contents.

**** End addition ****

1.1.3 Keys not used in signing DNS data

DNS can hold keys that are not destined for signing DNS data.  A zone
key may be restricted from signing data, or simply be no longer in
use. Null keys are used to signify that data is not signed.  Host and
user keys may be used strictly for email, IPSEC, and other protocols.
Apex names, which hold the zone keys, may also hold other keys not
signified as zone keys. And finally, the CERT RR holds keys within
certificates which are not intended for DNS use.

With the exception of keys at the apex, keys not used for signing are
of no interest to this document.  Non-signing keys at the apex are
only a consideration in that they are validated by the parent just as
the signing zone keys are validated.

**** Addition for 01 ****

1.1.4 Keys used for transaction security

Transaction signature specifications, including TSIG, SIG(0), and
TKEY are still too unstable to dwell on their use in great detail.
Perhaps this new section should be 1.2, as it is not restricted to
the KEY RR.  This may cause a renumbering.

**** End addition ****

1.2 Off-line and on-line operations

The zone key advertised by a KEY RR is the public key of a
public-private key pair.  The public key is used to verify data.  The
private key is used to sign data.  Asymmetric key operations are
founded on the fact that, given the public key, the private key is not
derivable, and only the private key can generate the signature that
the public key validates.

The important idea here is that the private key must be protected.
Once the private key is exposed or stolen, the public-private key pair
has no usefulness.  The best way to keep the private key from being
exposed or stolen is to keep it away from the network that is using
the DNS.

This can be interpreted as a requirement to perform signing on a
computer that is not connected to the network, moving data manually
(removable media).  If this is done, the operator must also be a
person trusted not to otherwise make the private key known.  This is
known as "off-net" signing.

Expires April 19, 2000                                      [Page  3]
Internet Draft                                       October 19, 1999

            +-----------+                +----------+
            |  Signing  |      +---+     |  Name    |
            |  Machine  |   ===| o |==>  |  Server  |
            +-----------+      +--/      +----------+
                 ||                            ||
            ==================      ===================
                 ||         ||      ||         ||
            +-----------+  +----------+  +----------+
            |  Signing  |  | Firewall |  |  Name    |
            |  Machine  |  |          |  |  Server  |
            +-----------+  +----------+  +----------+

The signing machine need not be isolated from all networks, it may be
on an administrative network, as shown above.  This "back office" LAN
may have an air-gap to the main network (internet or intranet), or
there may be a firewall in place (as shown above).

If there is an air gap, then there is an issue of how to move data
across it.  The most obvious means is some sort of removable media.
If we assume the staff running this part of the network is
trustworthy, we don't need to consider deeper issues - such as
classified data.

Finally, this off-net signing is a recommendation, not a mandatory
configuration.  Off-net signing makes the private key harder to expose
and/or steal.  Performing on-line signing means that the signing
machine must be hardened against attack, or the private key is of
little value.

Unlike most servers, the compromise of a host with (any kind of) a
private key cannot be simply fixed by reinstalling from clean back up
tapes and patching the hole.  The loss of the key may require new keys
to be made, and the revocation of what rights and privileges were tied
to the old key.

**** Addition for 01 ****

Note that using secure dynamic update is in conflict with the off-net
arrangement.  If updated data is to be signed, then there will need
to be a private key in the server on the network.  This is key is in
harm's way.  Recommended practices to limit the risk and vulnerability
will be documented, perhaps in a later version of this draft.

**** End addition ****

1.3 Delegation Relationships

Throughout DNS, relationships among the administrations at a
delegation point vary in closeness.  Between a TLD and a second level
domain, a relationship is formal and distant.  Further down in the
domain structure, a lone DNS administrator may delegate a zone that is
also run by the same person.

The terms used to label the range of relationships are inter-

Expires April 19, 2000                                      [Page  4]
Internet Draft                                       October 19, 1999

organizational, intra-organizational, and intra-office or personal.
Naturally, the formality of the operations described in this document
will scale accordingly throughout the range of relationships.

    +----------+         +-----------+          +------------+
    |          |         |           |          |            |
    | Registry | <-----> | Registrar |  <-----> | Registrant |
    |          | <     > |           |        > |            |
    +----------+  \   /  +-----------+       /  +------------+
                   \ /                      /
                   ???  +--------------+   /
                     \  |              |  /
                      > | DNS Operator | <
                        |              |

There is one other aspect of relationships to introduce.  This is the
relationship of a DNS registry, the registrar, the registrant and the
operator of the DNS.  These four blocks may be distinct, or any pair,
trio, or all four, may be combined into one organization.

To preserve generality, this document will consider the inter-
organizational relationships and assume that the registry, registrar,
registrant, and operator are distinct.

1.4 Minimum Expectation of Security

Setting the expectation of security of DNSSEC is important.  A DNSSEC
signature means that the data received came from the indicated zone,
and not much else.  The data is neither necessarily correct, nor even
out of date.  The data may have arrived from a cache which is holding
data whose TTL was set too long by the authoritative owner.

To further refine "how secure" an answer is, a document on signature
policy is required.  One cannot assume that the signing zone employs
strong keys and secure practices to protect its signing operations.
Such a document can provide a basis for zone administrators to judge
whether their operations are secure "enough."

1.5 Security Considerations

The handling of keys in DNSSEC is not as sensitive as keys used in
encryption of sensitive data.  Uncompromised keys can be used to begin
the use of newer keys, as perfect forward secrecy is not an issue.

Perfect forward secrecy refers to the inability of an attacker to read
an ongoing stream of encrypted traffic which changes keys once the
attacker has defeated a particular key.

**** Addition for 01 ****

The security of a zone's key, particularly the private key, is an
issue for all of the delegations below the zone.  A compromised or
stolen key is a problem to the zone itself in that unauthorized

Expires April 19, 2000                                      [Page  5]
Internet Draft                                       October 19, 1999

entities will be able to add data to the zone (perhaps spoofing the
entire zone).  If this happens, delegations are vulnerable to having
their zone keys altered or their delegations removed.

A parent's security practices should be made known to all children,
"grand-children," and other delegations.  Zone administrators should
be aware of the parent practices and be aware of vulnerabilities.

**** End addition ****

2 Preliminary Digressions

A few issues need to be introduced and discussed.  Since these are not
directly related to the handling of keys, only a brief discussion is
present here.  Each of these issues appear in a later section, when
the elaboration is more appropriate.

2.1 Dynamic Update

Dynamic update is a recent addition to the DNS operating concept.  A
zone's contents may be altered on the fly, without reloading the zone.
The impact of this on key handling is that new entries will require
new signatures, which will be made using keys available to the
Internet. This issue is a dilemma for securing the private key.

**** Addition for 01 ****

The phrase "available to the Internet." should changed to "residing
on hosts on the Internet.  This raises the risk that these keys may
be compromised and exposed on the Internet."

**** End addition ****

2.2 NXT records

NXT records are used to indicate what data is not present in a zone.
In particular, each name in the zone's NXT record has the name of the
next domain in the zone.  Of interest is the situation found in a TLD,
each zone delegated from the TLD will have a record pointing to the
next "customer" of the TLD.  This is the current specification, but is
undergoing review. There are some feeling in the operator community
that this is not welcome.

2.3 .PARENT file

The .PARENT file is a mechanism in BIND version 4 and 8 used to
transfer data from the parent of a delegation to the child.  This is
not part of the DNSSEC specification, but has been imposed in BIND,
because of the way the software is currently written.  With time this
may disappear, but in the interim, these files will be used, and
unfortunately, may present some problems.

BIND version 9 will not use .PARENT files.

Expires April 19, 2000                                      [Page  6]
Internet Draft                                       October 19, 1999

**** Addition for 01 ****

2.4 Algorithm Issues

DNSSEC defines two algorithms for use at this time, with the
capability to add other algorithms in the future.  The two current
algorithms have different merits, which has been analyzed in other
documents.  One algorithm has shorter signatures versus the other
algorithm's quicker verification times.  The issue of interest here
is the interaction of zones using different algorithms.  This will be
reviewed in section 5.

**** End addition ****

3. Key Handling During Lifetime

A key's lifetime begins with its generation, and after a period of
time the key is disposed of.  The reason for time-limiting keys is
that, given enough time, any secret key can become exposed.  The
challenge is to use a key pair for less time than is needed to "break"
or "discover" its private component.

There are two primary factors which determine the span of time a key
is useable.  One is the quality of the generation process.  Truly
random number generation and hard to derive numbers make a key safer.
The other factor in the so-called strength of the key is its length,
generally, the longer or bigger the key, the longer it takes to break

3.1 Generation of keys

The first step in the life of a zone (or any) key is the generation of
the private and public key pair.  For DNSSEC, there are initially two
kinds of key pairs available, differing in algorithm.  One is the
mandatory to implement DSA and the other is the optional RSA

DSA is an unencumbered technology which can be included without cost
into server implementations.  The RSA algorithm is patented by RSA,
Inc., but there is a license to use it for DNS purposes.

RSA signature verification is much quicker than RSA or DSA signature
generation.  DSA signature verification is slower than generation.
(Signatures are more frequently verified than generated.)  A DSA
signature is much smaller than either an RSA signature or key.  A DSA
key is bigger than RSA.  (Time and size generalizations are made for
stated for similar strength key pairs.)

A name server, such as BIND, should provide its own means for
generating keys.  BIND includes an executable dnskeygen which creates
two files, a private key file and a public key file.  The public key
file is suitable for inclusion in the zone data file.  The private key
file should be kept protected as this is the secret needed to secure
the zone.

Expires April 19, 2000                                      [Page  7]
Internet Draft                                       October 19, 1999

3.2 Submitting key for signing

Before a key is put into use, the public key must be signed by an
appropriate authority, in this case, the parent zone.  A key is not
sent individually, rather, a set of keys that will be advertised
together are set for signing.

Starting with a new public key, add it to the collection of keys that
will be signed together.  The keys should be expressed in the KEY RR
format, similar to what the key generator has made.

Since key generators will vary in their output, a zone administrator
must ensure, whether manually or automatically, that each key record
has the appropriate RDATA values - flags, algorithm, protocol and
bits, along with appropriate envelope information - type, class, and
TTL. The TTLs must be the same throughout the set.

This KEY RR set is sent to the parent, and is kept locally.  The
parent must also be told what period of validity to apply to the SIG
record, i.e., the start and end times for the signature.

The parent must return the newly generated SIG(KEY) RR, one for each
set and each required algorithm the parent uses in signing its data.
If the parent uses NXT records (now they are mandatory) then NXT
record of the child belonging to the parent zone is also sent, signed.
 (This transfer may be dropped in the future.)

The child must verify the parent's signature over the keys as they
were sent to the parent.  Blindly relying on the keys (optionally)
returned by the parent, or the signature, makes the zone vulnerable to
an attack in which more zone keys are inserted between the local zone
the parent's signing machine.

**** Addition for 01 ****

An issue that has been raised in workshops is the relationship of the
parent zone's algorithm set and the child's set.  When the two are
different, e.g., the parent uses RSA and the child does not, the
parent will return a NULL RSA key in addition to the submitted keys.
This must be taken into account when verifying the data returned from
the parent.

**** End addition ****

3.3 Use of private key

Once a private key is to be used to sign data, this can be done
regardless of whether or not the public key's signing is finished by
the parent.  E.g., if the zone has produced its first key pair, the
public key is sent to the parent for signing.  While this is happening
the private key is put to use simultaneously.

If the use of the private key, i.e., signing the zone, finished before

Expires April 19, 2000                                      [Page  8]
Internet Draft                                       October 19, 1999

the public keys is signed by the parent, the newly signed zone must
wait.  The new signatures are not usable until the new key and its
signature is available and signed.

Once a private key is used, it may be reused for as long and as often
as desired.  The longer a span of time in which the key is used raises
the vulnerability of the key to exposure or breaking.  The key should
also be left off-net for greater safety.

Whenever a zone is signed, the presence of any child keys must be
noted. if a new signature is generated for a child's key set, the
child should be notified and given the new signature.

3.4 Preparation for publishing the zone

Once the zone is signed, and the signed key is available from the
parent, the two are combined.  The key is also inserted into the name
server configuration files or scripts, so that the zone can be
validated during the loading of the data.

3.5 Requesting a new signature of the zone keys

SIG RRs contain a validity period, which limits the span of time the
signature is trusted to verify the integrity of the the data.  This
introduces the concept of data expiring from even the primary
authoritative server.

When the SIG RR covering the zone keys is about to expire, and the
parent has not already begun to generate a new signature, the child
zone will have to request a new signature from the parent.  It is not
clear if the child must resend the keys, since the parent should have
them already.

3.6 Disposing of a key

Removing a key from the DNS is as simple as erasing it and the
signatures it generated.  There is no reason to archive old keys as
these are simply providing signatures, not encrypted data.  There is
no risk in old uses of a key coming back, such as someone unlocking an
encrypted message, since there is a fundamental assumption that DNS
holds no secret data.

4. Key Transfer between Zone Administrations

There are a number of data flows that are created by DNSSEC to handle
keys.  This section discusses each starting from the motivation for
the flow and includes the required data and operations involved.

4.1 New delegation

At the inception of a new zone, besides the traditional data exchange,
the child must give to the parent a set of zone keys to start the
security of the zone.  If the zone is initially unsigned, then the
parent assigns NULL keys to the zone.  The parent, prior to installing

Expires April 19, 2000                                      [Page  9]
Internet Draft                                       October 19, 1999

the new delegation records must supply a signature covering the keys,
installing this signature in its zone and sending the SIG RR to the
child.  See the discussion in the next section (4.2) for more details.

Since this is the first set of keys used by the child, the parent
needs to be sure that the child is truly who they claim to be.  There
must be some out of band means used to authenticate the new zone
administrator. Successive key sets can be installed using the first
set's signature, so this authentication is a one-time but crucial

The zone administrations should also make plans to handle "stolen"
child keys.  If a child zone's private key is exposed or stolen, the
zone must be able to install new keys and have the parent sign them.
The parent must authorize the child again to prevent hi-jacking of a

The parent and child must also agree on how to handle the refreshing
of signatures.  If a child's SIG(KEY) RR is about to become invalid,
and the parent hasn't sent a new one, the child must request a new
one. Handling "emergency" signings and/or having a fixed
request/response period are two operations that should be defined in
the agreement covering the delegation.

4.2 New zone key set

When a child creates a new zone key (or keys) intending to publish the
key in its zone, it adds the key to the existing keys it plans to
continue publishing.  E.g., a zone may create one new key pair each
month for use, and always retain the keys of the previous two months
in the zone.  Hence, there are always three keys in the DNS.  When
keys A, B, and C, are in the zone, and the next month begins, key D is
made.  A, B, and C are already signed, but now key D replaces key A.
So the set of keys B, C, and D are sent to the parent for signing.

A suggested scenario is that a zone administrator may generate 12 keys
in a year, and plan to use one a month.  At any one time, the key for
the previous month, the current key, and the next month's key are to
be advertised.  Instead of contacting the parent each month with a new
set of keys, the child may send the keys in groups at one time.  E.g.,
for keys named A-L, the first set would be A-C, the next B-D, then
C-E, and so on.  The validity period for each trio would be one month
after the previous trio.

For each key set sent to the parent, the child must supply fully
defined resource records.  This includes the fully qualified domain
name, class, type and time-to-live.  The child must also specify the
period of validity of the SIG RR.

In addition, while the parent uses NXT records and passes them to the
child (the current operation), the child must tell the parent what its
zone minimum TTL is, so that the parent can set the TTL on the
resulting TTL RR to the minimum of the parent's and child's TTLs.  The

Expires April 19, 2000                                      [Page 10]

Internet Draft                                       October 19, 1999

period of validity on the SIG(NXT) RR should match the SIG(KEY) RR

Upon receiving the SIG(RR) and other records from the parent, the
child must verify that the new SIG covers the KEY RR set as it was
sent - looking for accidently or maliciously inserted keys.  This
means that the child must be able to find the parent's signing public
key.  If this check is done on an off-net machine, then the parent's
key must be configured as a DNS lookup isn't possible.

4.3 Child requests a signing

A child zone may need a new signature to cover the keys without
generating a new key.  In this instance, the same data as mentioned in
the previous section must flow, perhaps with a notice that this is
just a signature refresh operation.

4.4 New parent key

When the parent zone signs with a new key and retires signatures
generated with an old key, the new SIG(KEY) and SIG(NXT) (if used)
must be send to each of the respective delegations.

The child must first verify the new SIG(KEY) and add it to the zone if
it passes.  If the signature does not verify, there may be a problem
with the set of keys held for the zone at the parent.

4.5 Zone key exposed

When a zone key is exposed, broken, or stolen, the zone needs to start
anew with a new key set.  The out of band mechanisms set up at the
generation of the zone should be used to get this new set of keys

4.6 Removal of delegation

A parent zone can always remove a child zone by simply erasing the
delegation records and adjusting the NXT records pointing to the name.
There is no special provision for informing the child of this.
However, the parent should be aware that unless the key used to sign
the child's keys is removed, the child's data will remain valid until
the signatures expire.

**** Addition for 01 ****

5.new Transaction Key Security

Generation, distribution, etc. based upon the TSIG, TKEY, and dynamic
update security drafts in process.  Does this belong in this draft?
The draft can be renamed is so.

**** End addition ****

Expires April 19, 2000                                      [Page 11]

Internet Draft                                       October 19, 1999

5. Further Digressions

Issues that were introduced in section 2 are brought back here for
further elaboration.

5.1 Dynamic Update

The care taken to keep a private key from view, namely the use of
off-net signing, can not be extended to dynamic update situations.
Data added to a secured zone through a dynamic update must be signed
just like all the other data in a zone.  Therefore, there must be a
private key available on line.

There are a few ways to maintain the high level of security of data
signed off-net when mixed with the use of dynamic update.  One way is
to use separate zones for data signed off-net and data changed via
updates. By "quarantining" the updates, no update can interfere with
the static data.

Another means is to use the strength bits in the key flags to prevent
off-net signed data from being modified by a dynamic update.  This
issue hasn't been resolved yet, however.

5.2 NXT records

NXT records represent another data flow - the NXT itself may be
updated without a change in the KEY or SIG(KEY).  This occurs when the
parent delegates a zone whose name is lexically immediately after the
child's name.   The parent must inform the child to replace the NXT
record it previously supplied with the new one.  The child must be
aware that there are two NXTs at the zone apex, corresponding to the
parent and child zones, respectively.

At this time, there is some confusion about the impact of this on the
SOA and the informing of the secondary name servers of this change.
More will follow later.

5.3 .PARENT file

The .PARENT file is a mechanism currently used to save data from being
removed when loading successive zones in a name server.  While this is
used, the .PARENT file provides a convenient format for communication
from the parent to the child.  The parent's response to the child may
be just the .PARENT file - assuming fully specified text
representations are used.  Specifically, the TTL must appear.

The .PARENT file lacks information that the child needs to pass to the
parent.  What is missing is: protection of the key set from the
insertion of other keys (which could be a signature of the set using
an older key), the desired validity period, and the child's minimum
ttl. This data must be worked into the format sent from child to
parent when requesting a new signature.  In addition, deadline data
may also be required, this depends on the agreement made at the time
the zone is delegated.

Expires April 19, 2000                                      [Page 12]

Internet Draft                                       October 19, 1999

Once again, BIND version 9 does not use the .PARENT file.
**** Addition for 01 ****

5.4 Algorithm Issues

One issue that has been noted in two work shops (NIC-SE and CAIRN,
see acknowledgements) is the treatment of a delegation where the
participants use different algorithms.  For example, a parent may
use only RSA, the child may use only DSS.

One impact has been the adding of NULL keys to turn off security in
the parent's algorithm once you hit the child.  This means that the
set signed by the parent is different from what the child sends for
certification, since we can't assume a child will account for the
parent's preferences.  (The parent may have recently changed.)

Another impact is that the parent could use an algorithm the child
does not comprehend.  The child's holding of SIG(KEY) for this
unknown algorithm is akin to signing a consent form written in a
foreign (to you) language.  The child should probably throw this
signature out, but then there is no signature over the child's key
set for a necessary algorithm by the parent - hence the child's KEY
should never fully verify.

**** End addition ****

6 IANA Considerations

This document does not place any requirements on the assigned numbers

7 Security Considerations

This entire document is a note on security considerations.  If the
zone key is mishandled, in a way that compromises its security, then
the security of its zone is compromised.

8 Author's Address

Edward Lewis
3060 Washington Rd (Rte 97)
Glenwood, MD 21738

9 Acknowledgements

The following individuals and groups have made significant input into
the content of this document: the attendees of the NIC-SE work shop on
DNSSEC, May 18 and 19, 1999, also Olafur Gudmundsson, and Brian

Expires April 19, 2000                                      [Page 13]

Internet Draft                                       October 19, 1999

**** Addition for 01 ****

A second workshop held by the CAIRN research network September 29 and
30th also provided input to this document.  Dan Massey has provided
input based upon this workshop and experience with DNSSEC in CAIRN.

**** End addition ****

10 References

This section will be more formally defined as the document progresses.

RFC 2535 defines DNSSEC
RFC 1035 is the start of the definition of DNS
RFC 2136 defines DNS Dynamic Updates
TSIG is defined in draft-ietf-dnsind-tsig-11.txt

11 Full Copyright Statement

Copyright (C) The Internet Society (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

Expires April 19, 2000                                      [Page 14]