DNSEXT WG                                               Edward Lewis
INTERNET DRAFT                                          NAI Labs
Category:I-D                                            April 13,                                            July 12, 2000

         DNS Security Extension Clarification on Zone Status
             <draft-ietf-dnsext-zone-status-01.txt>
                <draft-ietf-dnsext-zone-status-02.txt>

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
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.

This draft expires on October 13, 2000. January 12, 2001.

Copyright Notice

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

Abstract

The definition of a secured zone is presented, updating RFC 2535.  The
new definition has consequences that alter
After discussion on the mailing list and other working group
consideration, removed from earlier editions of this draft are a new
interpretation of the NXT record, record and a proposal to obsolete NULL keys, and the designation
keys.  Deprecation of "experimentally
secure." secure" remains.

1 Introduction

Whether a DNS zone is "secured" or not is a question asked in at least
four contexts.  A zone administrator asks the question when
configuring a zone to use DNSSEC.  A dynamic update server asks the
question when an update request arrives, which may require DNSSEC
processing.  A delegating zone asks the question of a child zone when
the parent enters data indicating the status the child.  A resolver
asks the question upon receipt of data belonging to the zone.

Expires July 12, 2000                                     [Page  1]
^LDNS Security Extension Clarification on Zone Status     January 12, 2001

1.1 When a Zone's Status is Important

A zone administrator needs to be able to determine what steps are
needed to make the zone as secure as it can be.  Realizing that due to
the distributed nature of DNS and its administration, any single zone

Expires October 13, 2000                                     [Page  1]
is at the mercy of other zones when it comes to the appearance of
security.  This document will define what makes a zone qualify as
secure (absent interaction with other zones).

A name server performing dynamic updates needs to know whether a zone
being updated is to have signatures added to the updated data, NXT
records applied, and other required processing.  In this case, it is
conceivable that the name server is configured with the knowledge, but
being able to determine the status of a zone by examining the data is
a desirable alternative to configuration parameters.

A delegating zone is required to indicate whether a child zone is
secured.  The reason for this requirement lies in the way in which a
resolver makes its own determination about a zone (next paragraph). To
shorten a long story, a parent needs to know whether a child should be
considered secured.  This is a two part question, what does a parent
consider a secure child to be, and how does a parent know if the child
conforms?

A resolver needs to know if a zone is secured when the resolver is
processing data from the zone.  Ultimately, a resolver needs to know
whether or not to expect a usable signature covering the data.  How
this determination is done is out of the scope of this document,
except that, in some cases, the resolver will need to contact the
parent of the zone to see if the parent states that the child is
secured.

This document updates several sections

1.2 Islands of RFC 2535. Security

The definition goal of
a secured zone DNSSEC is an update to section 3.4 of the RFC.  The document
updates section 2.3.4, by specifying a replacement for the NULL have each zone
keys.  Section 3.4 is updated to eliminate secured, from the definition of
experimental keys root zone
and illustrate a way to still achieve the
functionality they were designed to provide.  Section 3.1.3 is updated
by the specifying top-level domains down the value of hierarchy to the protocol octet in a zone key.

2 Status of leaf zones.
Transitioning from an unsecured DNS, as we have now, to a Zone

In fully
secured - or "as much as will be secured" - tree will take some time.
During this section, rules governing a zone's time, DNSSEC status are presented.
There are three levels of security defined: full, private, and
unsecured.  A will be applied in various locations in the
tree, not necessarily "top down."

For example, at a particular instant, the root zone and the "test."
TLD might be secured, but region1.test. might not be.  (For reference,
let's assume that region2.test. is fully secure when it complies with secured.)  However,
subarea1.region1.test. may have gone through the strictest
set process of DNSSEC processing rules.  A zone is privately secured when it becoming
secured, along with its delegations.  The dilemma here is configured in such a way that only resolvers that are appropriately
configured see the
subarea1 cannot get its zone keys properly signed as its parent zone,
region1, is not secured.  All other

The popular term for the secured zones are unsecured.

Note: there currently at or below subarea1 is no document completely defining DNSSEC
verification rules.  For the purposes an
"island of security."  The only way in which a DNSSEC resolver will
come to trust any data from this document, island is if the strictest
rules are assumed to state that resolver is
pre-configured with the verification chain of zone keys
parallels the delegation tree up to the root zone.  This is key(s) for subarea1.  All other resolvers
will not
intended to disallow alternate verification paths, just to establish a
baseline definition.

To avoid repetition in the rules below, the following terms are
defined. recognize this island as secured.

Expires October 13, July 12, 2000                                     [Page  2]

2.a.
^LDNS Security Extension Clarification on Zone signing KEY RR - A KEY RR whose flag field has the value 01
for name type (indicating a zone key) Status     January 12, 2001

Although both subarea1.region1.test. and either value 00 or value 01
for key type (indicating a key permitted region2.test. have both been
properly brought to authenticate data).  (See
RFC 2535, section 3.1.2).  The KEY RR also has a protocol octet value
of DNSSEC (3) or All (255).

The definition updates RFC 2535's definition secure state by the administering staff, only
the latter of a zone key.  The
requirement that the protocol field be either DNSSEC or All two is a new
requirement.

2.b On-tree Validation actually fully secured - The authorization model in which only the
parent zone sense that
all DNSSEC resolvers can and will verify its data.  The former,
subarea1, will be seen as secured by a subset of those resolvers, just
those appropriately configured.

In RFC 2535, there is recognized to supply a DNSSEC-meaningful signature provision for "certification authorities,"
entities that will sign public keys for zones such as subarea1.  There
is used by a resolver to build a chain another draft (currently in last call) that restricts this
activity.  Regardless of trust from the child's
keys to a recognized root of security.  The term "on-tree" refers other draft, resolvers would still need
proper configuration to
following up be able to use the DNS domain hierarchy certification authority to reach a trusted key,
presumably
verify the root key if no other key is available. data for the subarea1 island.

1.3 Impact on RFC 2535

This document updates several sections of RFC 2535.  The term
"validation" refers definition of
a secured zone is an update to section 3.4 of the digital signature by the parent RFC.  Section 3.4 is
updated to prove eliminate the integrity, authentication and authorization definition of experimental keys and
illustrate a way to still achieve the child' key functionality they were designed
to
sign provide.  Section 3.1.3 is updated by the child's zone data.

2.c Off-tree Validation - Any authorization model that permits domain
names other than specifying the parent's to provide a signature over value of
the protocol octet in a child's zone keys that will enable key.

2 Status of a resolver to trust the keys.

2.1 Fully Secured Zone

In this section, rules governing a zone's DNSSEC status are presented.
There are three levels of security defined: full, private, and
unsecured.  A zone is fully secure when it complies with the strictest
set of DNSSEC processing rules.  A zone is privately secured zone, in a nutshell, when it
is configured in such a zone way that uses only
mandatory to implement algorithms (RFC 2535, section 3.2) and relies
on a key certification chain resolvers that parallels are appropriately
configured see the delegation tree
(on-tree validation).  Fully secured zone as secured.  All other zones are defined by the
following unsecured.

Note: there currently is no document completely defining DNSSEC
verification rules.

2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at least
one zone signing KEY RR (2.a)  For the purposes of a mandatory to implement algorithm in this document, the set.

2.1.b. The zone's apex KEY RR set MUST be signed by a private key
belonging strictest
rules are assumed to state that the parent zone.  The private key's public companion MUST
be a zone signing KEY RR (2.a) verification chain of a mandatory to implement algorithm
and owned by the parent's apex.

If a zone cannot get a conforming signature from the parent zone, keys
parallels the
child zone cannot be considered fully secured.  The only exception delegation tree up to
this is the root zone, for which there is no parent zone.

2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC
2535, section 2.3.2.)  Note: there is some operational discomfort with
the current NXT record.  This requirement is open not
intended to modification when
two things happen.  First, an disallow alternate mechanism verification paths, just to the NXT is
defined and second, a means by which a zone can indicate that it is
using an alternate method.

2.1.d. Each RR set that qualifies for zone membership MUST be signed
by establish a key that is
baseline definition.

To avoid repetition in the apex's rules below, the following terms are
defined.

2.a. Zone signing KEY RR set and is a zone signing - A KEY RR

Expires October 13, 2000                                     [Page  3]

(2.a) of whose flag field has the value 01
for name type (indicating a mandatory zone key) and either value 00 or value 01
for key type (indicating a key permitted to implement algorithm.  (Updates authenticate data).  (See
RFC 2535, section
2.3.1.)

Mentioned earlier, the root zone is 3.1.2).  The KEY RR also has a special case.  Defining what
constitutes protocol octet value
of DNSSEC (3) or ALL (255).

The definition updates RFC 2535's definition of a secure root zone is difficult, as key.  The
requirement that the discussion on
securing protocol field be either DNSSEC or ALL is a new
requirement.

2.b On-tree Validation - The authorization model in which only the root
parent zone has not come can is recognized to supply a consensus in an open forum.
However, the security DNSSEC-meaningful signature

Expires July 12, 2000                                     [Page  3]
^LDNS Security Extension Clarification on Zone Status     January 12, 2001

that is used by a resolver to build a chain of trust from the child's
keys to a recognized root zone will be determined by the
preconfiguration of security.  The term "on-tree" refers to
following up the DNS domain hierarchy to reach a trusted key,
presumably the root key in resolvers.  Who generates if no other key is available.  The term
"validation" refers to the digital signature by the parent to prove
the integrity, authentication and
distributes authorization of the trusted child' key is an open issue.

2.2 Privately Secured

Note to
sign the child's zone data.

2.c Off-tree Validation - Any authorization model that permits domain
names other than the term "privately" is open parent's to debate...

A privately secured zone is provide a signature over a child's
zone keys that complies with rules like those
for will enable a resolver to trust the keys.

2.1 Fully Secured

A fully secured zone, in a nutshell, is a zone with the following exceptions.  The signing
keys may be of an algorithm that is not uses only
mandatory to implement and/or
the verification of the zone keys in use may rely algorithms (RFC 2535, section 3.2) and relies
on a verification key certification chain that is not parallel to parallels the delegation tree (off-tree
(on-tree validation).

2.2.a.  Fully secured zones are defined by the
following rules.

2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at least
one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
the set.

2.2.b.

2.1.b. The zone's apex KEY RR set MUST be signed by a private key and
one of
belonging to the following two subclauses MUST hold true.

2.2.b.1 parent zone.  The private key's public companion MUST
be preconfigured in
all the resolvers of interest.

2.2.b.2 The private key's public component MUST be a zone signing KEY RR (2.a) authorized to provide validation of the zone's apex KEY RR
set, as recognized by resolvers of interest.

The previous sentence is trying to convey the notion of using a
trusted third party mandatory to provide validation of keys.  If the domain name
owning implement algorithm
and owned by the validating key is not parent's apex.

If a zone cannot get a conforming signature from the parent zone, the domain name must
represent someone the resolver trusts
child zone cannot be considered fully secured.  The only exception to provide validation.

2.2.c.
this is the root zone, for which there is no parent zone.

2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC
2535, section 2.3.2.)  Note: see there is some operational discomfort with
the discussion following 2.1.c.

2.2.d. current NXT record.  This requirement is open to modification when
two things happen.  First, an alternate mechanism to the NXT is
defined and second, a means by which a zone can indicate that it is
using an alternate method.

2.1.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY RR
(2.a)..
(2.a) of a mandatory to implement algorithm.  (Updates 2535, section
2.3.1.)

2.3 Unsecured

All other zones qualify as unsecured.  This includes zones that are
designed to be experimentally secure, as defined in

Mentioned earlier, the root zone is a later section on
that topic.

Expires October 13, 2000                                     [Page  4]

2.4 Wrap up

The designation of fully secured, privately secured, and unsecured are
merely labels to apply to zones, based on their contents.  Resolvers,
when determining whether a signature is expected or not, will only see special case.  Defining what
constitutes a secure root zone is difficult, as secured or unsecured.

Resolvers that follow the most restrictive DNSSEC verification rules
will only see fully secured zones as secured, and all others as
unsecured, including zones which are privately secured.  Resolvers
that are discussion on
securing the root zone has not as restrictive, such as those that implement algorithms
in addition come to a consensus in an open forum.
However, the mandatory to implement algorithms, will see some
privately secured zones as secured.

The intent security of the labels "fully" and "privately" is to identify root zone will be determined by the
specific attributes
pre-configuration of a zone.  The words are chosen to assist trusted key in resolvers.  Who generates and
distributes the
writing of a document recommending the actions a zone administrator
take in making use of trusted key is an open issue.

Expires July 12, 2000                                     [Page  4]
^LDNS Security Extension Clarification on Zone Status     January 12, 2001

2.2 Privately Secured

Note that the DNS security extensions. term "privately" is open to debate.  The words are
explicitly not intended term stems from
the likely hood that the only resolvers to convey a state of compliance with DNS
security standards.

3 Parental Notification

For be configured for a resolver to come
particular zone will be resolvers "private" to a definitive answer concerning a zone's
security status there an organization.
Perhaps the more clumsy "colloquially secure" is more accurate.

A privately secured zone is a requirement zone that the parent of complies with rules like those
for a fully secured zone
signify whether with the child zone is signed or not. following exceptions.  The justification signing
keys may be of
this requirement requires a discussion an algorithm that is not mandatory to implement and/or
the verification of the resolver's activity,
which is described zone keys in RFC 2535.

In RFC 2535, use may rely on a parent verification
chain that is required not parallel to hold the delegation tree (off-tree
validation).

2.2.a. The zone's apex MUST have a NULL KEY RR set.  There MUST be at least
one zone signing KEY RR (2.a) in the set.

2.2.b. The zone's apex KEY RR set MUST be signed by a private key for an unsigned
child (a bone and
one of contention here is how this works the following two subclauses MUST hold true.

2.2.b.1 The private key's public companion MUST be pre-configured in light
all the resolvers of
multiple algorithms). interest.

2.2.b.2 The parent has private key's public component MUST be a zone signing KEY
RR (2.a) authorized to provide validation of the option zone's apex KEY RR
set, as recognized by resolvers of interest.

The previous sentence is trying to hold convey the keys notion of using a
trusted third party to provide validation of keys.  If the child if domain name
owning the child validating key is signed.  The not the parent may also hold nothing
cryptographic if zone, the child is signed.  This, of course, assumes domain name must
represent someone the resolver trusts to provide validation.

2.2.c. NXT records MUST be deployed throughout the
parent is a signed zone. (Updates RFC 2535 does permit
2535, section 2.3.2.) Note: see the discussion following case, a child zone 2.1.c.

2.2.d. Each RR set that uses DNSSEC
capable software yet chooses to remain unsecured could hold a qualifies for zone membership MUST be signed
NULL
by a key delivered from that is in the parent.  This apex's KEY RR set and is considered to be a rare
condition, a zone administrator signing KEY RR
(2.a).  (Updates 2535, section 2.3.1.)

2.3 Unsecured

All other zones qualify as unsecured.  This includes zones that goes to the trouble to get the
keys from the parent and have it signed will likely just sign the
whole zone, or leave the NULL key are
designed to the parent.

There is a strong case for discouraging a parent from holding keys of be experimentally secure, as defined in a signed child, or an unsigned child for later section on
that matter.  These include
concrete concerns about performance and more abstract concerns about
the liability topic.

2.4 Wrap up

The designation of the parent.

DNS [RFC 1034 fully secured, privately secured, and 1035] requires a parent unsecured are
merely labels to hold NS records for a
child zone, this signifies the delegation.  RFC 2535 requires a
secured parent apply to also have signed NXT records for the child, and
possibly a signed KEY RR set (required for some NULL key situations).

By redefining the security status of zones, based on their contents.  Resolvers,
when determining whether a zone to be per zone and not per

Expires October 13, 2000                                     [Page  5]

algorithm, there signature is an opportunity to completely remove the need for expected or not, will only see
a
KEY RR set in the parent.  Because the question of whether the zone is
secure as secured or not is a yes-or-no question, the notification needs just one
bit to be expressed.

Keep in mind unsecured.

Resolvers that follow the following sections speak to the contents of a
zone, not a name server.  In the case of a name server speaking
authoritatively for both the parent and child, or if a server caches
the information for the other half of the delegation, then a server most restrictive DNSSEC verification rules
will have more types of data at a delegation point than a parent is
supposed to hold.  (E.g., if a parent zone's name server caches the
SOA for the child, the SOA is not in the parent zone, but is in the
server's cache.)

3.1 Child Has Keys Bit

This section is written assuming the current definition of NXT holds.
There is some controversy surrounding the NXT record, which may result
in a complete replacement of it for proof of non-existence.  The
current NXT definition provides an extension bit in the types present
bit map, whose use is remains incompletely defined.  The following
text largely ignores these uncertainties, and should be rewritten to
accommodate these uncertainties in revisions.

In the parent's half of the delegation point, there will be an NXT
record, called an "upper" NXT.  According to the rules for a
delegation point, only the NS, NXT, and SIG bits will be turned on in
the types present field, assuming we drop the KEY set altogether.

The KEY bit in the parent's NXT types present bit map is hereby
redefined to have the following meaning.  (Note that this applies to
just delegation points.)

If the bit corresponding to the KEY RR set in an upper NXT is set, the
parent has generated and issued a currently valid SIG (KEY) RR
validating the child's apex KEY RR set.  Note that this does not
require the child to include either a zone signing KEY RR (2.a) or a
NULL zone KEY RR.  This does assume that only on-tree validation (2.b)
is in use.

The temporal validity of the bit's setting may be enforced in the SIG
(NXT) RR validity period, timely editing of the master file, dynamic
updates, or whatever another mechanism.

If a child submits a key set to the parent for validation that does
not include a zone signing KEY RR (2.a), then the child will remain
unsecured although the upper NXT KEY RR bit will be set to 1 by the
parent.  A resolver seeing this will know to look for a child key set,
and see that there is no zone signing KEY RR (2.a) fully secured zones as secured, and know to treat
the child all others as unsecured.

If a NULL zone KEY RR is seen, the resolver ignores it.  If a NULL key
is the only zone key, then the resolver will deduce the child is
unsecured as in the previous paragraph.  If there is both a NULL and

Expires October 13, July 12, 2000                                     [Page  6]

one or more zone signing KEY RR (2.a), then the zone is considered
signed in the algorithm(s) identified in the signing capable key(s).

If the bit is 0 then the child has not submitted a KEY RR set for
validation, hence is to be considered unsigned.

Note that for a fully secured zone (section 2.1), the bit is on (1).
For all unsecured zones (section 2.3) the bit is either off (0) or  5]
^LDNS Security Extension Clarification on
(1) with a NULL KEY and no zone signing KEY RR at the apex.  For
privately secured zones (section 2.2), the setting of the bit is
determined by whether the parent signs the child's keys or not.
Hence, for privately secured zones, the parent may have no
responsibility.  A child wishing to have the parent set the bit must
contact the parent.

3.2 Rules Governing the Bit

In this section, the words of the previous are turned into definitive
MUST and SHOULDs.  Note that this section does not refer to the bit in
the NXT.  This is in anticipation of a change in the way NXT indicates
types present (e.g., if bit 0 of the field is defined) or a successor
to the NXT is defined.

3.2.a. At a delegation point, a secured parent zone MUST have a
mechanism in place to indicate which RR sets are present.  The
mechanism MUST indicate that the NS, SIG, and the type(s)
corresponding to the mechanism itself are present (of course, with
these types actually being present).  With the exception of the KEY RR
type, all other types MUST be indicated as not present, and, in
accordance with delegation rules, actually be absent from the zone.
If, in the future, other data is permitted to be present at a
delegation point, this requirement MUST be amended.

Assuming the NXT record, the above requirement reads as follows.  At a
delegation point, a parent zone must have a secured NXT record.  This
NXT record must indicate that the NS, SIG, and NXT types are present.
With the exception of KEY, all other types must be indicated as not
present.  The lower casing of the word "must" is intentional,
conveying that this is an explanation of the rule above.

3.2.b. The KEY set MUST be indicated as present during the time when
the parent has issued a signature for the child's KEY set. Conversely,
during periods of time in which the parent knows it has not generated
a signature for the KEY RR set, the KEY set MUST be indicated to be
absent.

If the parent has issued signatures with discontinuous validity spans,
then the presence of the KEY set will flip from present to not present
and back as time progresses.

3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully
consider the algorithm of the key used to generate the signature.  The
parent SHOULD make clear to child zones what steps are to be taken to

Expires October 13, 2000                                     [Page  7]

get the parent to indicate that the child is signed.  This document
will go no further in specifying operational considerations.

(Let's say the parent signs the child's key set with an algorithm the
child can't process.  The child could elect not to advertise this
signature, as it cannot verify that the signature covers the real key
set.  If this happens, is the parent justified in claiming that the
child is secured?)

3.2.d. The parent MUST have the capability to allow the child, through
some trusted, probably non-DNS mechanism, to request that the
indication of the KEY set to be turned off.  This allows a child to
revert to an unsigned state.

3.2.e. The parent SHOULD NOT allow the child to request that the KEY
set be indicated as present in the absence of a key signing request.

3.3 Operational Considerations

Retrieving the NXT for a delegated name from the parent zone (the
upper NXT) is not a trivial operation.  The complication arises due to
having an NXT in the delegatee (the lower NXT) that matches the owner
name of the upper NXT.  (The case in which both the parent and child
zones are secured is the only case mentioned here.  If both are not
secured, then there will be at most one NXT, which is easily
retrieved.)

There are two complications to describe.  One involves the multiple
NXT sets matching the same owner.  The other is the pragmatic issue of
knowing where to get the answer.

With multiple NXT sets at the same owner, caches may become a problem.
If a (for example) recursive server has cached the lower NXT, any
query for the upper NXT may be confused for a lower NXT query.  This
is akin to the issue of the ANY query, where a server with some cached
data will answer with just that and not seek the rest of the data.

Note that distinguishing between an upper and lower NXT is a trivial
operation, especially so if the SIG RR is available.

A resolver may know the child's server's addresses and the parent zone
may not be sharing servers with the child.  In this case the resolver
will need to be able to locate the parent zones (possibly having to go
to the root servers and descend) in order to obtain the upper NXT
record.

A potential solution to this is to define an NXT meta-query that will
force a recursive server to find all available NXT RR sets for a given
name.  Details of this have not been examined.

3.4 Interaction with Dynamic Update

Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update-
xy.txt] defines a means by which a zone can change without undergoing

Expires October 13, 2000                                     [Page  8]

a full reload.  This combination of dynamic update and the proposed
use of the NXT record to signify a child's status raises some
concerns.

First a few elements need to be labeled.  There is an off-line signer,
which is the process that signs zone data files away from the name
server.  There is an on-line signer, part of a name server, that the
dynamic update mechanism uses to sign the updated data.  Finally,
there is an on-line key validator, perhaps a misnomer, which accepts
requests for parent signatures over each child zone's keys.

The proposal depicted in this draft relies upon the on-line key
validator informing the on-line and off-line signers of the status of
a child, recall that the status of a child has a temporal element.
E.g., a signature may be generated for just the month of July, so the
child is secured for the month of July, but not the month of August.

The first issues pertain to the way in which an off-line signer comes
to encode a validation in an NXT record.  There is a need for the
status information to flow from the on-line validator to the off-line
signer and then be used as input to the signing process.  The way that
this information makes the transition is an issue.  The second issue
is through what mechanism is this information ingested into the NXT
generating process.  Recall that all other information can be derived
by the zone data, the status of the child isn't stored anywhere else
in the parent zone.

The next issue is the means in which a validation action is reported
to the active zone.  On the surface, dynamically updating the NXT
would seem to make sense, but updating the NXT in this manner can lead
to a race condition in the server, this is unstable.  The issue here
is deriving a mechanism by Zone Status     January 12, 2001

unsecured, including zones which a name server knows to signify that
the child status has changed.  Note are privately secured.  Resolvers
that this applies to newly
validated keys are not as well restrictive, such as the granting of a child's request those that implement algorithms
in addition to cancel
a validation.

The final issue is the operation of the off-line signer.  When an NXT
is being regenerated, the old NXT is needed mandatory to implement algorithms, will see what the previous
setting of the child's status had been.  The old NXT signature is also
needed to know that, had the child been known to be secured, for what
interval was is it thought to be some
privately secured so that the new NXT signature
is appropriately set.  Of course, if the reason for updating the NXT
is a change zones as described in the previous paragraph, the old NXT is of
lesser value. secured.

The issue raised in intent of the last paragraph leads labels "fully" and "privately" is to a questioning of identify the
sanity
specific attributes of using signature validity periods a zone.  The words are chosen to signify assist in the temporal
status
writing of data in a server.  What does a server return if document recommending the NXT
needed is not currently covered by actions a valid signature?

4 NULL keys

Through the zone administrator
take in making use of the types present DNS security extensions.  The words are
explicitly not intended to indicate the existence of convey a
signature validating the KEY set state of a child, the need for NULL keys

Expires October 13, 2000                                     [Page  9]

effectively disappears.  NULL keys are left as a defined entity, but
are rendered meaningless in DNSSEC. compliance with DNS
security standards.

3 Deleted

4 Deleted

5 Experimental Status

Without NULL keys, an experimentally secured zone cannot be defined as
it is in RFC 2535.

The purpose of an experimentally secured zone was is to facilitate the
migration from an unsecured zone to a secured zone.  This distinction
is dropped.

The objective of facilitating the migration can be achieved without a
special designation of an experimentally secure status.
Experimentally secured is a special case of privately secured.  A zone
administrator can achieve this by publishing a zone with signatures
and configuring a set of test resolvers with the corresponding public
keys.  Even if the public key is published in a KEY RR, as long as
there is no parent signature, the resolvers will need some preconfiguration
pre-configuration to know to process the signatures.  This allows a
zone to be secured with in the sphere of the experiment, yet still be
registered as unsecured in the general Internet.

6 IANA/ICANN Considerations

This document does not request any action from an assigned number
authority nor recommends any actions.

7 Security Considerations

Without a means to enforce compliance with specified protocols or
recommended actions, declaring a DNS zone to be "completely" secured
is impossible.  Even if, assuming an omnipotent view of DNS, one can
declare a zone to be properly configured for security, and all of the
zones up to the root too, a misbehaving resolver could be duped into
believing bad data.  If a zone and resolver comply, a non-compliant or
subverted parent could interrupt operations.  The best that can be
hoped for is that all parties are prepared to be judged secure and
that security incidents can be traced to the cause in short order.

8 Acknowledgements

The need to refine the definition of a secured zone has become
apparent through the efforts of the participants at two DNSSEC

Expires July 12, 2000                                     [Page  6]
^LDNS Security Extension Clarification on Zone Status     January 12, 2001

workshops, sponsored by the NIC-SE (.se registrar) and registrar), CAIRN (a
DARPA-funded research network). network), and other workshops.  Further
discussions leading to the document include Olafur Gudmundsson, Russ
Mundy, Robert Watson, and Brian Wellington.  Roy Arends, Ted Lindgreen
and others have contributed significant input via the namedroppers
mailing list.

9 References

[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities,"
RFC 1034, November 1987.

[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1034, November 1987.

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997

[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
Updates in the Domain Name System," RFC 2136, April 1997.

[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
2535, March 1999.

[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
Secure Domain Name System (DNS) Dynamic Update," version 00, February
2000.

10 Author Information

Edward Lewis
NAI Labs
3060 Washington Road
Glenwood, MD 21738
+1 443 259 2352
<lewis@tislabs.com>

11 Full Copyright Statement

Copyright (C) The Internet Society (1999, 2000).  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 English.

Expires July 12, 2000                                     [Page  7]
^LDNS Security Extension Clarification on Zone Status     January 12, 2001

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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Expires July 12, 2000                                     [Page  8]