draft-ietf-dnsext-zone-status-00.txt   draft-ietf-dnsext-zone-status-01.txt 
DNSEXT WG Edward Lewis DNSEXT WG Edward Lewis
INTERNET DRAFT NAI Labs INTERNET DRAFT NAI Labs
Category:I-D Feburary 1, 2000 Category:I-D April 13, 2000
DNS Security Extension Clarification on Zone Status DNS Security Extension Clarification on Zone Status
<draft-ietf-dnsext-zone-status-00.txt> <draft-ietf-dnsext-zone-status-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 10, line ? skipping to change at page 10, line ?
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Comments should be sent to the authors or the DNSIND WG mailing list Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net. namedroppers@internic.net.
This draft expires on August 1, 2000. This draft expires on October 13, 2000.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999, 2000). All rights reserved. Copyright (C) The Internet Society (1999, 2000). All rights reserved.
Abstract Abstract
The definition of a secured zone is presented, updating RFC 2535. The The definition of a secured zone is presented, updating RFC 2535. The
new definition has consequences which alter the interpretation of the new definition has consequences that alter the interpretation of the
NXT record, obsolete NULL keys, and the designation of "experimentally NXT record, obsolete NULL keys, and the designation of "experimentally
secure." secure."
1 Introduction 1 Introduction
Whether a DNS zone is "secured" or not is a question asked in at least Whether a DNS zone is "secured" or not is a question asked in at least
four contexts. A zone administrator asks the question when four contexts. A zone administrator asks the question when
configuring a zone to use DNSSEC. A dynamic update server asks the configuring a zone to use DNSSEC. A dynamic update server asks the
question when an update request arrives, which may require DNSSEC question when an update request arrives, which may require DNSSEC
processing. A delegating zone asks the question of a child zone when processing. A delegating zone asks the question of a child zone when
the parent enters data indicating the status the child. A resolver the parent enters data indicating the status the child. A resolver
asks the question upon receipt of data belonging to the zone. asks the question upon receipt of data belonging to the zone.
A zone administrator needs to be able to determine what steps are 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 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 August 1, 2000 [Page 1] Expires October 13, 2000 [Page 1]
the distributed nature of DNS and its administration, any single zone
is at the mercy of other zones when it comes to the appearance of 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 security. This document will define what makes a zone qualify as
secure (absent interaction with other zones). secure (absent interaction with other zones).
A name server performing dynamic updates needs to know whether a zone A name server performing dynamic updates needs to know whether a zone
being updated is to have signatures added to the updated data, NXT being updated is to have signatures added to the updated data, NXT
records applied, and other required processing. In this case, it is records applied, and other required processing. In this case, it is
conceivable that the name server is configured with the knowledge, but 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 being able to determine the status of a zone by examining the data is
a desirable alternative to configuration parameters. a desirable alternative to configuration parameters.
skipping to change at page 10, line ? skipping to change at page 10, line ?
processing data from the zone. Ultimately, a resolver needs to know processing data from the zone. Ultimately, a resolver needs to know
whether or not to expect a usable signature covering the data. How whether or not to expect a usable signature covering the data. How
this determination is done is out of the scope of this document, this determination is done is out of the scope of this document,
except that, in some cases, the resolver will need to contact the 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 parent of the zone to see if the parent states that the child is
secured. secured.
This document updates several sections of RFC 2535. The definition of This document updates several sections of RFC 2535. The definition of
a secured zone is an update to section 3.4 of the RFC. The document a secured zone is an update to section 3.4 of the RFC. The document
updates section 2.3.4, by specifying a replacement for the NULL zone updates section 2.3.4, by specifying a replacement for the NULL zone
keys. The document also updates section 3.4 to eliminate the keys. Section 3.4 is updated to eliminate the definition of
definition of experimental keys and illustrate a way to still achieve experimental keys and illustrate a way to still achieve the
the functionality they were designed to provide. functionality they were designed to provide. Section 3.1.3 is updated
by the specifying the value of the protocol octet in a zone key.
2 Status of a Zone 2 Status of a Zone
In this section, rules governing a zone's DNSSEC status are presented. In this section, rules governing a zone's DNSSEC status are presented.
There are three levels of security defined; full, private, and There are three levels of security defined: full, private, and
unsecured. A zone is fully secure when it complies with the strictest unsecured. A zone is fully secure when it complies with the strictest
set of DNSSEC processing rules. A zone is privately secured when it set of DNSSEC processing rules. A zone is privately secured when it
is configured in such a way that only resolvers that are appropriately is configured in such a way that only resolvers that are appropriately
configured see the zone as secured. All other zones are unsecured. configured see the zone as secured. All other zones are unsecured.
Note: there currently is no other document completely defining DNSSEC Note: there currently is no document completely defining DNSSEC
processing rules. For the purposes of this document, the strictest verification rules. For the purposes of this document, the strictest
rules are assumed to state that the verification chain of zone keys rules are assumed to state that the verification chain of zone keys
parallels the delegation tree up to the root zone. This is not parallels the delegation tree up to the root zone. This is not
intended to disallow alternate verification paths, just to establish a intended to disallow alternate verification paths, just to establish a
baseline definition. baseline definition.
To avoid repetition in the rules below, the following term is defined. To avoid repetition in the rules below, the following terms are
defined.
2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
Expires August 1, 2000 [Page 2] Expires October 13, 2000 [Page 2]
2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
for name type (indicating a zone key) and either value 00 or value 01 for name type (indicating a zone key) and either value 00 or value 01
for key type (indicating a key permitted to authenticate data). (See for key type (indicating a key permitted to authenticate data). (See
RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value
of DNSSEC (3) or All (255). of DNSSEC (3) or All (255).
The definition updates RFC 2535's definition of a zone key. The
requirement that the protocol field be either DNSSEC or All is a new
requirement.
2.b On-tree Validation - The authorization model in which only the
parent zone can is recognized to supply a DNSSEC-meaningful signature
that is used by a resolver to build a chain of trust from the child's
keys to a recognized root of security. The term "on-tree" refers to
following up the DNS domain hierarchy to reach a trusted key,
presumably the root key if no other key is available. The term
"validation" refers to the digital signature by the parent to prove
the integrity, authentication and authorization of the child' key to
sign the child's zone data.
2.c Off-tree Validation - Any authorization model that permits domain
names other than the parent's to provide a signature over a child's
zone keys that will enable a resolver to trust the keys.
2.1 Fully Secured 2.1 Fully Secured
A fully secured zone, in a nutshell, is a zone that uses only A fully secured zone, in a nutshell, is a zone that uses only
mandatory to implement algorithms (RFC 2535, section 3.2) and relies mandatory to implement algorithms (RFC 2535, section 3.2) and relies
on a key certification chain that parallels the delegation tree. Fully on a key certification chain that parallels the delegation tree
secured zones are defined by the following rules. (on-tree validation). 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 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 one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
the set. the set.
2.1.b. The zone's apex KEY RR set MUST be signed by a private key 2.1.b. The zone's apex KEY RR set MUST be signed by a private key
belonging to the parent zone. The private key's public companion MUST belonging to the parent zone. The private key's public companion MUST
be a zone signing KEY RR (2.a) of a mandatory to implement algorithm be a zone signing KEY RR (2.a) of a mandatory to implement algorithm
and owned by the parent's apex. and owned by the parent's apex.
If a zone cannot get a conforming signature from the parent zone, the If a zone cannot get a conforming signature from the parent zone, the
child zone cannot be considered fully secured. child zone cannot be considered fully secured. The only exception 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 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 2535, section 2.3.2.) Note: there is some operational discomfort with
the current NXT record. This requirement is open to modification when the current NXT record. This requirement is open to modification when
two things happen. First, an alternate mechanism to the NXT is 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 defined and second, a means by which a zone can indicate that it is
using an alternate method. using an alternate method.
2.1.d. Each RR set that qualifies for zone membership MUST be signed 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 by a key that is in the apex's KEY RR set and is a zone signing KEY RR
Expires October 13, 2000 [Page 3]
(2.a) of a mandatory to implement algorithm. (Updates 2535, section (2.a) of a mandatory to implement algorithm. (Updates 2535, section
2.3.1.) 2.3.1.)
Mentioned earlier, the root zone is a special case. Defining what
constitutes a secure root zone is difficult, as the discussion on
securing the root zone has not come to a consensus in an open forum.
However, the security of the root zone will be determined by the
preconfiguration of a trusted key in resolvers. Who generates and
distributes the trusted key is an open issue.
2.2 Privately Secured 2.2 Privately Secured
Note that the term "privately" is open to debate...
A privately secured zone is a zone that complies with rules like those A privately secured zone is a zone that complies with rules like those
for fully secured, with the following exceptions. The signing keys for a fully secured zone with the following exceptions. The signing
may be of an algorithm that is not mandatory to implement and/or the keys may be of an algorithm that is not mandatory to implement and/or
verification of the zone keys in use may rely on a verification chain the verification of the zone keys in use may rely on a verification
that is not parallel to the delegation tree. chain that is not parallel to the delegation tree (off-tree
validation).
2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least
one zone signing KEY RR (2.a) in the set. 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 and 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
one of the following two sentences MUST hold true. The private key's one of the following two subclauses MUST hold true.
public companion MUST be preconfigured in all the resolvers of
interest. 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.
Expires August 1, 2000 [Page 3] 2.2.b.1 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 The previous sentence is trying to convey the notion of using a
trusted third party to provide validation of keys. If the domain name trusted third party to provide validation of keys. If the domain name
owning the validating key is not the parent zone, the domain name must owning the validating key is not the parent zone, the domain name must
represent someone the resolver trusts to provide validation. represent someone the resolver trusts to provide validation.
2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC 2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC
2535, section 2.3.2.) Note: see the discussion following 2.1.c. 2535, section 2.3.2.) Note: see the discussion following 2.1.c.
2.2.d. Each RR set that qualifies for zone membership MUST be signed 2.2.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 by a key that is in the apex's KEY RR set and is a zone signing KEY RR
(2.a). (Updates 2535, section 2.3.1.) (2.a).. (Updates 2535, section 2.3.1.)
2.3 Unsecured 2.3 Unsecured
All other zones qualify as unsecured. This includes zones that are All other zones qualify as unsecured. This includes zones that are
designed to be experimentally secure, as defined in a later section on designed to be experimentally secure, as defined in a later section on
that topic. that topic.
Expires October 13, 2000 [Page 4]
2.4 Wrap up 2.4 Wrap up
The designation of fully secured, privately secured, and unsecured are The designation of fully secured, privately secured, and unsecured are
merely labels to apply to zones, based on their contents. Resolvers, merely labels to apply to zones, based on their contents. Resolvers,
when determining whether a signature is expected or not, will only see when determining whether a signature is expected or not, will only see
a zone as secured or unsecured. a zone as secured or unsecured.
Resolvers that follow the most restrictive DNSSEC verification rules Resolvers that follow the most restrictive DNSSEC verification rules
will only see fully secured zones as secured, and all others as will only see fully secured zones as secured, and all others as
unsecured, including zones which are privately secured. Resolvers unsecured, including zones which are privately secured. Resolvers
which are not as restrictive, such as those that implement algorithms that are not as restrictive, such as those that implement algorithms
in addition to the mandatory to implement algorithms, will see some in addition to the mandatory to implement algorithms, will see some
privately secured zones as secured. privately secured zones as secured.
The intent of the labels "fully" and "privately" is to identify the The intent of the labels "fully" and "privately" is to identify the
specific attributes of a zone. The words are chosen to assist in the specific attributes of a zone. The words are chosen to assist in the
writing of a document recommending the actions a zone administrator writing of a document recommending the actions a zone administrator
take in making use of the DNS security extensions. The words are take in making use of the DNS security extensions. The words are
explicitly not intended to convey a state of compliance with DNS explicitly not intended to convey a state of compliance with DNS
security standards. security standards.
3 Parental Notification 3 Parental Notification
For a resolver to come to a definitive answer concerning a zone's For a resolver to come to a definitive answer concerning a zone's
security status, there is a requirement that the parent of a zone security status there is a requirement that the parent of a zone
signify whether the child zone is signed or not. The justification of signify whether the child zone is signed or not. The justification of
this requirement requires a discussion of the resolver's activity, this requirement requires a discussion of the resolver's activity,
which is described in RFC 2535. which is described in RFC 2535.
In RFC 2535, a parent is required to hold a NULL key for an unsigned In RFC 2535, a parent is required to hold a NULL key for an unsigned
child (a bone of contention here is how this works in light of child (a bone of contention here is how this works in light of
multiple algorithms). The parent has the option to hold the keys of multiple algorithms). The parent has the option to hold the keys of
the child if the child is signed. The parent may also hold nothing the child if the child is signed. The parent may also hold nothing
cryptographic if the child is signed. This, of course, assumes the cryptographic if the child is signed. This, of course, assumes the
parent is a signed zone. parent is a signed zone.
Expires August 1, 2000 [Page 4] RFC 2535 does permit the following case, a child zone that uses DNSSEC
capable software yet chooses to remain unsecured could hold a signed
NULL key delivered from the parent. This is considered to be a rare
condition, a zone administrator 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 to the parent.
There is a strong case for discouraging a parent from holding keys of There is a strong case for discouraging a parent from holding keys of
a signed child. These include concrete concerns about performance and a signed child, or an unsigned child for that matter. These include
more abstract concerns about the liability of the parent. concrete concerns about performance and more abstract concerns about
the liability of the parent.
DNS [RFC 1034 and 1035] requires a parent to hold NS records for a DNS [RFC 1034 and 1035] requires a parent to hold NS records for a
child zone, this signifies the delegation. RFC 2535 requires a child zone, this signifies the delegation. RFC 2535 requires a
secured parent to also have signed NXT records for the child, and secured parent to also have signed NXT records for the child, and
possibly a signed KEY RR set (required for NULL key situations). possibly a signed KEY RR set (required for some NULL key situations).
By redefining the security status of a zone to be per zone and not per By redefining the security status of a zone to be per zone and not per
Expires October 13, 2000 [Page 5]
algorithm, there is an opportunity to completely remove the need for a algorithm, there is an opportunity to completely remove the need for a
KEY RR set in the parent. Because the question of whether the zone is KEY RR set in the parent. Because the question of whether the zone is
secure or not is a yes-or-no question, the notification needs just one secure or not is a yes-or-no question, the notification needs just one
bit to be expressed. bit to be expressed.
Keep in mind that the following sections speak to the contents of a Keep in mind that the following sections speak to the contents of a
zone, not a name server. In the case of a name server speaking 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 authoritatively for both the parent and child, or if a server caches
the information for the other half of the delegation, then a server the information for the other half of the delegation, then a server
will have more types of data at a delegation point than a parent is 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 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 SOA for the child, the SOA is not in the parent zone, but is in the
server's cache.) server's cache.)
3.1 Child Is Secured Bit 3.1 Child Has Keys Bit
This section is written assuming the current definition of NXT holds. This section is written assuming the current definition of NXT holds.
There is some controversy surrounding the NXT record which may result There is some controversy surrounding the NXT record, which may result
in a complete replacement of it for proof of non-existence. The in a complete replacement of it for proof of non-existence. The
current NXT definition provides an extension bit in the types present current NXT definition provides an extension bit in the types present
bit map, whose use is remains incompletely defined. The following bit map, whose use is remains incompletely defined. The following
text largely ignores these uncertainties, and should be rewritten to text largely ignores these uncertainties, and should be rewritten to
accommodate these uncertainties in revisions. accommodate these uncertainties in revisions.
In the parent's half of the delegation point, there will be an NXT In the parent's half of the delegation point, there will be an NXT
record. According to the rules for a delegation point, only the NS, record, called an "upper" NXT. According to the rules for a
NXT, and SIG bits will be turned on in the types present field, delegation point, only the NS, NXT, and SIG bits will be turned on in
assuming we drop the KEY set altogether. 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 The KEY bit in the parent's NXT types present bit map is hereby
redefined to have the following meaning. redefined to have the following meaning. (Note that this applies to
just delegation points.)
If the bit corresponding to the KEY RR set in a parent NXT is set, the If the bit corresponding to the KEY RR set in an upper NXT is set, the
parent has signed a KEY RR set for the child that includes a zone parent has generated and issued a currently valid SIG (KEY) RR
signing KEY RR (2.a). Furthermore, the validity period on the SIG validating the child's apex KEY RR set. Note that this does not
(KEY) RR covers the current time and the public component of the key require the child to include either a zone signing KEY RR (2.a) or a
used to generate the SIG (KEY) RR is validly available from the NULL zone KEY RR. This does assume that only on-tree validation (2.b)
parent. is in use.
E.g., Assume the zone "test." signs a key for "zone1.test.," with the The temporal validity of the bit's setting may be enforced in the SIG
signature valid from May 1st to June 1st and a public key from "test." (NXT) RR validity period, timely editing of the master file, dynamic
available from April 1st until July 1st. The NXT record for updates, or whatever another mechanism.
"zone1.test." will have the KEY RR bit set from May 1st to June 1st.
Expires August 1, 2000 [Page 5] 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) and know to treat
the child as unsecured.
This constraint may be enforced in the SIG (NXT) RR validity period, If a NULL zone KEY RR is seen, the resolver ignores it. If a NULL key
timely editing of the master file, or whatever other mechanism "test." is the only zone key, then the resolver will deduce the child is
chooses to implement. unsecured as in the previous paragraph. If there is both a NULL and
Conversely, if the bit is 0, then the child is not secured. Note that Expires October 13, 2000 [Page 6]
for a fully secured zone (section 2.1), the bit is on (1). For all
unsecured zones (section 2.3) the bit is off (0). For privately one or more zone signing KEY RR (2.a), then the zone is considered
secured zones (section 2.2), the setting of the bit is determined by signed in the algorithm(s) identified in the signing capable key(s).
whether the parent signs the child's keys or not. Hence, for
privately secured zones, the parent may have no responsibility. A If the bit is 0 then the child has not submitted a KEY RR set for
child wishing to have the parent set the bit must contact the parent. 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 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 3.2 Rules Governing the Bit
In this section, the words of the previous are turned into definitive 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 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 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 types present (e.g., if bit 0 of the field is defined) or a successor
to the NXT is defined. to the NXT is defined.
3.2.a. At a delegation point, a parent zone MUST have a mechanism in 3.2.a. At a delegation point, a secured parent zone MUST have a
place to indicate which RR sets are present. The mechanism MUST mechanism in place to indicate which RR sets are present. The
indicate that the NS, SIG, and the type(s) corresponding to the mechanism MUST indicate that the NS, SIG, and the type(s)
mechanism itself are present (of course, with these types actually corresponding to the mechanism itself are present (of course, with
being present). With the exception of the KEY RR type, all other these types actually being present). With the exception of the KEY RR
types MUST be indicated as not present, and, in accordance with type, all other types MUST be indicated as not present, and, in
delegation rules, actually be absent from the zone. If, in the accordance with delegation rules, actually be absent from the zone.
future, other data is permitted to be present at a delegation point, If, in the future, other data is permitted to be present at a
this requirement MUST be amended. delegation point, this requirement MUST be amended.
Assuming the NXT record, the above requirement reads as follows. At a Assuming the NXT record, the above requirement reads as follows. At a
delegation point, a parent zone must have a secured NXT record. This 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. 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 With the exception of KEY, all other types must be indicated as not
present. The lower casing of the word "must" is intentional, present. The lower casing of the word "must" is intentional,
conveying that this is an explanation of the rule above. 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 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, 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 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 a signature for the KEY RR set, the KEY set MUST be indicated to be
absent. absent.
If the parent has issued signatures with discontinuous validity spans, If the parent has issued signatures with discontinuous validity spans,
then the presence of the KEY set will flip from present to not present then the presence of the KEY set will flip from present to not present
and back as time progresses. and back as time progresses.
If the parent is aware that the child's keys are becoming valid or
will be becoming invalid at a certain point in time, it is recommended
that this be reflected in the NXT's signature validity period.
3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully 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 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 parent SHOULD make clear to child zones what steps are to be taken to
Expires August 1, 2000 [Page 6] Expires October 13, 2000 [Page 7]
get the parent to indicate that the child is signed. This document get the parent to indicate that the child is signed. This document
will go no further in specifying operational considerations. will go no further in specifying operational considerations.
(Let's say the parent signs the child's key set with an algorithm the (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 child can't process. The child could elect not to advertise this
signature as it cannot verify that the signature covers the real key signature, as it cannot verify that the signature covers the real key
set. If this happens, is the parent justified in claiming that the set. If this happens, is the parent justified in claiming that the
child is secured?) child is secured?)
3.2.d. The parent MUST allow the child, through some trusted, probably 3.2.d. The parent MUST have the capability to allow the child, through
non-DNS mechanism, to request that the indication of the KEY set in some trusted, probably non-DNS mechanism, to request that the
the NXT be turned off. This allows a child to revert to an unsigned indication of the KEY set to be turned off. This allows a child to
state. revert to an unsigned state.
3.2.e. The parent SHOULD NOT allow the child to request that the KEY 3.2.e. The parent SHOULD NOT allow the child to request that the KEY
set be indicated in the absence of a key signing request. set be indicated as present in the absence of a key signing request.
3.3 Operational Considerations 3.3 Operational Considerations
Retrieving the NXT for a delegated name from the parent zone (the Retrieving the NXT for a delegated name from the parent zone (the
upper NXT) is not a trivial operation. The complication arises due to 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 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 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 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 secured, then there will be at most one NXT, which is easily
retrieved.) retrieved.)
skipping to change at page 10, line ? skipping to change at page 10, line ?
There are two complications to describe. One involves the multiple There are two complications to describe. One involves the multiple
NXT sets matching the same owner. The other is the pragmatic issue of NXT sets matching the same owner. The other is the pragmatic issue of
knowing where to get the answer. knowing where to get the answer.
With multiple NXT sets at the same owner, caches may become a problem. 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 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 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 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. 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 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 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 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 to the root servers and descend) in order to obtain the upper NXT
record. record.
A potential solution to this is to define an NXT meta-query which will 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 force a recursive server to find all available NXT RR sets for a given
name. Details of this have not been examined. name. Details of this have not been examined.
3.4 Interaction with Dynamic Update 3.4 Interaction with Dynamic Update
Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update- Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update-
xy.txt] defines a means by which a zone can change without undergoing 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 a full reload. This combination of dynamic update and the proposed
use of the NXT record to signify a child's status raises some use of the NXT record to signify a child's status raises some
concerns. concerns.
Expires August 1, 2000 [Page 7]
First a few elements need to be labeled. There is an off-line signer, 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 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 server. There is an on-line signer, part of a name server, that the
dynamic update mechanism uses to sign the updated data. Finally, dynamic update mechanism uses to sign the updated data. Finally,
there is an on-line key validator, perhaps a misnomer, which accepts there is an on-line key validator, perhaps a misnomer, which accepts
requests for parent signatures over each child zone's keys. requests for parent signatures over each child zone's keys.
The proposal depicted in this draft relies upon the on-line key 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 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. 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 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 August. child is secured for the month of July, but not the month of August.
The first issues pertain to the way in which a validation is encoded The first issues pertain to the way in which an off-line signer comes
in an NXT record by the off-line signer. There is a need for the 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 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 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 this information makes the transition is an issue. The second issue
is through what mechanism is this information ingested into the NXT is through what mechanism is this information ingested into the NXT
generating process. Recall that all other information can be derived generating process. Recall that all other information can be derived
by the zone data, the status of the child isn't stored anywhere else by the zone data, the status of the child isn't stored anywhere else
in the parent zone. in the parent zone.
The next issue is the means in which a validation action is reported The next issue is the means in which a validation action is reported
to the active zone. On the surface, dynamically updating the NXT to the active zone. On the surface, dynamically updating the NXT
skipping to change at page 10, line ? skipping to change at page 10, line ?
The issue raised in the last paragraph leads to a questioning of the The issue raised in the last paragraph leads to a questioning of the
sanity of using signature validity periods to signify the temporal sanity of using signature validity periods to signify the temporal
status of data in a server. What does a server return if the NXT status of data in a server. What does a server return if the NXT
needed is not currently covered by a valid signature? needed is not currently covered by a valid signature?
4 NULL keys 4 NULL keys
Through the use of the types present to indicate the existence of a Through the use of the types present to indicate the existence of a
signature validating the KEY set of a child, the need for NULL keys signature validating the KEY set 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 effectively disappears. NULL keys are left as a defined entity, but
are rendered meaningless in DNSSEC. are rendered meaningless in DNSSEC.
Expires August 1, 2000 [Page 8]
5 Experimental Status 5 Experimental Status
Without NULL keys, an experimentally secured zone cannot be defined as Without NULL keys, an experimentally secured zone cannot be defined as
it is in RFC 2535. The purpose of an experimentally secured zone was it is in RFC 2535. The purpose of an experimentally secured zone was
to facilitate the migration from an unsecured zone to a secured zone. to facilitate the migration from an unsecured zone to a secured zone.
The objective of facilitating the migration can be achieved without a The objective of facilitating the migration can be achieved without a
special designation of an experimentally secure status. Experimentally special designation of an experimentally secure status. Experimentally
secured is a special case of privately secured. A zone administrator secured is a special case of privately secured. A zone administrator
can achieve this by publishing a zone with signatures and configuring can achieve this by publishing a zone with signatures and configuring
skipping to change at page 10, line ? skipping to change at page 11, line 8
[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities,"
RFC 1034, November 1987. RFC 1034, November 1987.
[RFC1035] P. Mockapetris, "Domain Names - Implementation and [RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1034, November 1987. Specification," RFC 1034, November 1987.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997 Requirement Levels," RFC 2119, March 1997
Expires August 1, 2000 [Page 9]
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
Updates in the Domain Name System," RFC 2136, April 1997. Updates in the Domain Name System," RFC 2136, April 1997.
[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC [RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
2535, March 1999. 2535, March 1999.
[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple [draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
Secure Domain Name System (DNS) Dynamic Update", version 00, February Secure Domain Name System (DNS) Dynamic Update," version 00, February
2000. 2000.
10 Author Information 10 Author Information
Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443 Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
259 2352 <lewis@tislabs.com> 259 2352 <lewis@tislabs.com>
11 Full Copyright Statement 11 Full Copyright Statement
Copyright (C) The Internet Society (1999, 2000). All Rights Reserved. Copyright (C) The Internet Society (1999, 2000). All Rights Reserved.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/