draft-ietf-dnsext-dnssec-2535typecode-change-06.txt   rfc3755.txt 
INTERNET-DRAFT Samuel Weiler Network Working Group S. Weiler
Expires: June 2004 December 15, 2003 Request for Comments: 3755 SPARTA, Inc.
Updates: RFC 2535, [DS] Updates: 3658, 2535 May 2004
Category: Standards Track
Legacy Resolver Compatibility for Delegation Signer Legacy Resolver Compatibility for Delegation Signer (DS)
draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document specifies an Internet standards track protocol for the
of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
Comments should be sent to the author or to the DNSEXT WG mailing Copyright (C) The Internet Society (2004). All Rights Reserved.
list: namedroppers@ops.ietf.org
Abstract Abstract
As the DNS Security (DNSSEC) specifications have evolved, the As the DNS Security (DNSSEC) specifications have evolved, the syntax
syntax and semantics of the DNSSEC resource records (RRs) have and semantics of the DNSSEC resource records (RRs) have changed.
changed. Many deployed nameservers understand variants of these Many deployed nameservers understand variants of these semantics.
semantics. Dangerous interactions can occur when a resolver that Dangerous interactions can occur when a resolver that understands an
understands an earlier version of these semantics queries an earlier version of these semantics queries an authoritative server
authoritative server that understands the new delegation signer that understands the new delegation signer semantics, including at
semantics, including at least one failure scenario that will cause least one failure scenario that will cause an unsecured zone to be
an unsecured zone to be unresolvable. This document changes the unresolvable. This document changes the type codes and mnemonics of
type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
avoid those interactions.
Changes between 05 and 06:
Signifigantly reworked the IANA section -- went back to one
algorithm registry.
Removed Diffie-Hellman from the list of zone-signing algorithms
(leaving only DSA, RSA/SHA-1, and private algorithms).
Added a DNSKEY flags field registry.
Changes between 04 and 05:
IESG approved publication.
Cleaned up an internal reference in the acknowledgements section.
Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
Changed the names of both new registries. Added algorithm
mnemonics to the new zone signing algorithm registry. Minor
rewording in the IANA section for clarity.
Cleaned up formatting of references. Replaced unknown-rr draft
references with RFC3597. Bumped DS version number.
Changes between 03 and 04:
Clarified that RRSIG(0) may be defined by standards action.
Created a new algorithm registry and renamed the old algorithm
registry for SIG(0) only. Added references to the appropriate
crypto algorithm and format specifications.
Several minor rephrasings.
Changes between 02 and 03:
KEY (as well as SIG) retained for SIG(0) use only.
Changes between 01 and 02:
SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
Domain names embedded in NSECs and RRSIGs are not compressible and
are not downcased. Added unknown-rrs reference (as informative).
Simplified the last paragraph of section 3 (NSEC doesn't always
signal a negative answer).
Changed the suggested type code assignments.
Added 2119 reference.
Added definitions of "unsecure delegation" and "unsecure referral",
since they're not clearly defined elsewhere.
Moved 2065 to informative references, not normative.
1. Introduction 1. Introduction
The DNSSEC protocol has been through many iterations whose syntax The DNSSEC protocol has been through many iterations whose syntax and
and semantics are not completely compatible. This has occurred as semantics are not completely compatible. This has occurred as part
part of the ordinary process of proposing a protocol, implementing of the ordinary process of proposing a protocol, implementing it,
it, testing it in the increasingly complex and diverse environment testing it in the increasingly complex and diverse environment of the
of the Internet, and refining the definitions of the initial Internet, and refining the definitions of the initial Proposed
Proposed Standard. In the case of DNSSEC, the process has been Standard. In the case of DNSSEC, the process has been complicated by
complicated by DNS's criticality and wide deployment and the need DNS's criticality and wide deployment and the need to add security
to add security while minimizing daily operational complexity. while minimizing daily operational complexity.
A weak area for previous DNS specifications has been lack of detail A weak area for previous DNS specifications has been lack of detail
in specifying resolver behavior, leaving implementors largely on in specifying resolver behavior, leaving implementors largely on
their own to determine many details of resolver function. This, their own to determine many details of resolver function. This,
combined with the number of iterations the DNSSEC spec has been combined with the number of iterations the DNSSEC specifications have
through, has resulted in fielded code with a wide variety of been through, has resulted in fielded code with a wide variety of
behaviors. This variety makes it difficult to predict how a behaviors. This variety makes it difficult to predict how a protocol
protocol change will be handled by all deployed resolvers. The change will be handled by all deployed resolvers. The risk that a
risk that a change will cause unacceptable or even catastrophic change will cause unacceptable or even catastrophic failures makes it
failures makes it difficult to design and deploy a protocol change. difficult to design and deploy a protocol change. One strategy for
One strategy for managing that risk is to structure protocol managing that risk is to structure protocol changes so that existing
changes so that existing resolvers can completely ignore input that resolvers can completely ignore input that might confuse them or
might confuse them or trigger undesirable failure modes. trigger undesirable failure modes.
This document addresses a specific problem caused by Delegation This document addresses a specific problem caused by Delegation
Signer's [DS] introduction of new semantics for the NXT RR that are Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR
incompatible with the semantics in RFC 2535 [RFC2535]. Answers that are incompatible with the semantics in [RFC2535]. Answers
provided by DS-aware servers can trigger an unacceptable failure provided by DS-aware servers can trigger an unacceptable failure mode
mode in some resolvers that implement RFC 2535, which provides a in some resolvers that implement RFC 2535, which provides a great
great disincentive to sign zones with DS. The changes defined in disincentive to sign zones with DS. The changes defined in this
this document allow for the incremental deployment of DS. document allow for the incremental deployment of DS.
1.1 Terminology 1.1. Terminology
In this document, the term "unsecure delegation" means any In this document, the term "unsecure delegation" means any delegation
delegation for which no DS record appears at the parent. An for which no DS record appears at the parent. An "unsecure referral"
"unsecure referral" is an answer from the parent containing an NS is an answer from the parent containing an NS RRset and a proof that
RRset and a proof that no DS record exists for that name. no DS record exists for that name.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2 The Problem 1.2. The Problem
Delegation Signer introduces new semantics for the NXT RR that are Delegation Signer (DS) introduces new semantics for the NXT RR that
incompatible with the semantics in RFC 2535. In RFC 2535, NXT are incompatible with the semantics in RFC 2535. In RFC 2535, NXT
records were only required to be returned as part of a records were only required to be returned as part of a non-existence
non-existence proof. With DS, an unsecure referral returns, in proof. With DS, an unsecure referral returns, in addition to the NS,
addition to the NS, a proof of non-existence of a DS RR in the form a proof of non-existence of a DS RR in the form of an NXT and
of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a
to interpret a response with both an NS and an NXT in the authority response with RCODE=0, AA=0, and both an NS and an NXT in the
section, RCODE=0, and AA=0. Some widely deployed 2535-aware authority section. Some widely deployed 2535-aware resolvers
resolvers interpret any answer with an NXT as a proof of interpret any answer with an NXT as a proof of non-existence of the
non-existence of the requested record. This results in unsecure requested record. This results in unsecure delegations being
delegations being invisible to 2535-aware resolvers and violates invisible to 2535-aware resolvers and violates the basic
the basic architectural principle that DNSSEC must do no harm -- architectural principle that DNSSEC must do no harm -- the signing of
the signing of zones must not prevent the resolution of unsecured zones must not prevent the resolution of unsecured delegations.
delegations.
2. Possible Solutions 2. Possible Solutions
This section presents several solutions that were considered. This section presents several solutions that were considered.
Section 3 describes the one selected. Section 3 describes the one selected.
2.1. Change SIG, KEY, and NXT type codes 2.1. Change SIG, KEY, and NXT type codes
To avoid the problem described above, legacy (RFC2535-aware) To avoid the problem described above, legacy (RFC2535-aware)
resolvers need to be kept from seeing unsecure referrals that resolvers need to be kept from seeing unsecure referrals that include
include NXT records in the authority section. The simplest way to NXT records in the authority section. The simplest way to do that is
do that is to change the type codes for SIG, KEY, and NXT. to change the type codes for SIG, KEY, and NXT.
The obvious drawback to this is that new resolvers will not be able The obvious drawback to this is that new resolvers will not be able
to validate zones signed with the old RRs. This problem already to validate zones signed with the old RRs. This problem already
exists, however, because of the changes made by DS, and resolvers exists, however, because of the changes made by DS, and resolvers
that understand the old RRs (and have compatibility issues with DS) that understand the old RRs (and have compatibility issues with DS)
are far more prevalent than 2535-signed zones. are far more prevalent than 2535-signed zones.
2.2. Change a subset of type codes 2.2. Change a subset of type codes
The observed problem with unsecure referrals could be addressed by The observed problem with unsecure referrals could be addressed by
changing only the NXT type code or another subset of the type codes changing only the NXT type code or another subset of the type codes
that includes NXT. This has the virtue of apparent simplicity, but that includes NXT. This has the virtue of apparent simplicity, but
it risks introducing new problems or not going far enough. It's it risks introducing new problems or not going far enough. It's
quite possible that more incompatibilities exist between DS and quite possible that more incompatibilities exist between DS and
earlier semantics. Legacy resolvers may also be confused by seeing earlier semantics. Legacy resolvers may also be confused by seeing
records they recognize (SIG and KEY) while being unable to find records they recognize (SIG and KEY) while being unable to find NXTs.
NXTs. Although it may seem unnecessary to fix that which is not Although it may seem unnecessary to fix that which is not obviously
obviously broken, it's far cleaner to change all of the type codes broken, it's far cleaner to change all of the type codes at once.
at once. This will leave legacy resolvers and tools completely This will leave legacy resolvers and tools completely blinded to
blinded to DNSSEC -- they will see only unknown RRs. DNSSEC -- they will see only unknown RRs.
2.3. Replace the DO bit 2.3. Replace the DO bit
Another way to keep legacy resolvers from ever seeing DNSSEC Another way to keep legacy resolvers from ever seeing DNSSEC records
records with DS semantics is to have authoritative servers only with DS semantics is to have authoritative servers only send that
send that data to DS-aware resolvers. It's been proposed that data to DS-aware resolvers. It's been proposed that assigning a new
assigning a new EDNS0 flag bit to signal DS-awareness (tentatively EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and
called "DA"), and having authoritative servers send DNSSEC data having authoritative servers send DNSSEC data only in response to
only in response to queries with the DA bit set, would accomplish queries with the DA bit set, would accomplish this. This bit would
this. This bit would presumably supplant the DO bit described in presumably supplant the DO bit described in [RFC3225].
RFC 3225.
This solution is sufficient only if all 2535-aware resolvers zero This solution is sufficient only if all 2535-aware resolvers zero out
out EDNS0 flags that they don't understand. If one passed through EDNS0 flags that they don't understand. If one passed through the DA
the DA bit unchanged, it would still see the new semantics, and it bit unchanged, it would still see the new semantics, and it would
would probably fail to see unsecure delegations. Since it's probably fail to see unsecure delegations. Since it's impractical to
impractical to know how every DNS implementation handles unknown know how every DNS implementation handles unknown EDNS0 flags, this
EDNS0 flags, this is not a universal solution. It could, though, is not a universal solution. It could, though, be considered in
be considered in addition to changing the RR type codes. addition to changing the RR type codes.
2.4. Increment the EDNS version 2.4. Increment the EDNS version
Another possible solution is to increment the EDNS version number Another possible solution is to increment the EDNS version number as
as defined in RFC 2671 [RFC2671], on the assumption that all defined in [RFC2671], on the assumption that all existing
existing implementations will reject higher versions than they implementations will reject higher versions than they support, and
support, and retain the DO bit as the signal for DNSSEC awareness. retain the DO bit as the signal for DNSSEC awareness. This approach
This approach has not been tested. has not been tested.
2.5. Do nothing 2.5. Do nothing
There is a large deployed base of DNS resolvers that understand There is a large deployed base of DNS resolvers that understand
DNSSEC as defined by the standards track RFC 2535 and RFC 2065 DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and,
and, due to under specification in those documents, interpret any due to under specification in those documents, interpret any answer
answer with an NXT as a non-existence proof. So long as that is with an NXT as a non-existence proof. So long as that is the case,
the case, zone owners will have a strong incentive to not sign any zone owners will have a strong incentive to not sign any zones that
zones that contain unsecure delegations, lest those delegations be contain unsecure delegations, lest those delegations be invisible to
invisible to such a large installed base. This will dramatically such a large installed base. This will dramatically slow DNSSEC
slow DNSSEC adoption. adoption.
Unfortunately, without signed zones there's no clear incentive for Unfortunately, without signed zones there's no clear incentive for
operators of resolvers to upgrade their software to support the new operators of resolvers to upgrade their software to support the new
version of DNSSEC, as defined in [DS]. Historical data suggests version of DNSSEC, as defined in RFC 3658. Historical data suggests
that resolvers are rarely upgraded, and that old nameserver code that resolvers are rarely upgraded, and that old nameserver code
never dies. never dies.
Rather than wait years for resolvers to be upgraded through natural Rather than wait years for resolvers to be upgraded through natural
processes before signing zones with unsecure delegations, processes before signing zones with unsecure delegations, addressing
addressing this problem with a protocol change will immediately this problem with a protocol change will immediately remove the
remove the disincentive for signing zones and allow widespread disincentive for signing zones and allow widespread deployment of
deployment of DNSSEC. DNSSEC.
3. Protocol changes 3. Protocol changes
This document changes the type codes of SIG, KEY, and NXT. This This document changes the type codes of SIG, KEY, and NXT. This
approach is the cleanest and safest of those discussed above, approach is the cleanest and safest of those discussed above, largely
largely because the behavior of resolvers that receive unknown type because the behavior of resolvers that receive unknown type codes is
codes is well understood. This approach has also received the most well understood. This approach has also received the most testing.
testing.
To avoid operational confusion, it's also necessary to change the To avoid operational confusion, it's also necessary to change the
mnemonics for these RRs. DNSKEY will be the replacement for KEY, mnemonics for these RRs. DNSKEY will be the replacement for KEY,
with the mnemonic indicating that these keys are not for with the mnemonic indicating that these keys are not for application
application use, per [RFC3445]. RRSIG (Resource Record SIGnature) use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace
will replace SIG, and NSEC (Next SECure) will replace NXT. These SIG, and NSEC (Next SECure) will replace NXT. These new types
new types completely replace the old types, except that SIG(0) completely replace the old types, except that SIG(0) [RFC2931] and
[RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY. TKEY [RFC2930] will continue to use SIG and KEY.
The new types will have exactly the same syntax and semantics as The new types will have exactly the same syntax and semantics as
specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for
the following: the following:
1) Consistent with [RFC3597], domain names embedded in 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC
RRSIG and NSEC RRs MUST NOT be compressed, RRs MUST NOT be compressed,
2) Embedded domain names in RRSIG and NSEC RRs are not downcased 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for
for purposes of DNSSEC canonical form and ordering nor for purposes of DNSSEC canonical form and ordering nor for equality
equality comparison, and comparison, and
3) An RRSIG with a type-covered field of zero has undefined 3) An RRSIG with a type-covered field of zero has undefined
semantics. The meaning of such a resource record may only be semantics. The meaning of such a resource record may only be
defined by IETF Standards Action. defined by IETF Standards Action.
If a resolver receives the old types, it SHOULD treat them as If a resolver receives the old types, it SHOULD treat them as unknown
unknown RRs and SHOULD NOT assign any special meaning to them or RRs and SHOULD NOT assign any special meaning to them or give them
give them any special treatment. It MUST NOT use them for DNSSEC any special treatment. It MUST NOT use them for DNSSEC validations
validations or other DNS operational decision making. For example, or other DNS operational decision making. For example, a resolver
a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs.
validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive
they MUST NOT receive special treatment. As an example, if a SIG special treatment. As an example, if a SIG is included in a signed
is included in a signed zone, there MUST be an RRSIG for it. zone, there MUST be an RRSIG for it. Authoritative servers may wish
Authoritative servers may wish to give error messages when loading to give error messages when loading zones containing SIG or NXT
zones containing SIG or NXT records (KEY records may be included records (KEY records may be included for SIG(0) or TKEY).
for SIG(0) or TKEY).
As a clarification to previous documents, some positive responses, As a clarification to previous documents, some positive responses,
particularly wildcard proofs and unsecure referrals, will contain particularly wildcard proofs and unsecure referrals, will contain
NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative
negative answers merely because they contain an NSEC. answers merely because they contain an NSEC.
4. IANA Considerations 4. IANA Considerations
4.1 DNS Resource Record Types 4.1. DNS Resource Record Types
This document updates the IANA registry for DNS Resource Record This document updates the IANA registry for DNS Resource Record Types
Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,
DNSKEY RRs, respectively. respectively.
Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
TKEY [RFC2930] use only. TKEY [RFC2930] use only.
Type 30 (NXT) should be marked as Obsolete. Type 30 (NXT) should be marked as Obsolete.
4.2 DNS Security Algorithm Numbers 4.2. DNS Security Algorithm Numbers
To allow zone signing (DNSSEC) and transaction security mechanisms To allow zone signing (DNSSEC) and transaction security mechanisms
(SIG(0) and TKEY) to use different sets of algorithms, the existing (SIG(0) and TKEY) to use different sets of algorithms, the existing
"DNS Security Algorithm Numbers" registry is modified to include "DNS Security Algorithm Numbers" registry is modified to include the
the applicability of each algorithm. Specifically, two new columns applicability of each algorithm. Specifically, two new columns are
are added to the registry, showing whether each algorithm may be added to the registry, showing whether each algorithm may be used for
used for zone signing, transaction security mechanisms, or both. zone signing, transaction security mechanisms, or both. Only
Only algorithms usable for zone signing may be used in DNSKEY, algorithms usable for zone signing may be used in DNSKEY, RRSIG, and
RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in
may be used in SIG and KEY RRs. SIG and KEY RRs.
All currently defined algorithms remain usable for transaction All currently defined algorithms except for Indirect (algorithm 252)
security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private remain usable for transaction security mechanisms. Only RSA/SHA-1
algorithms (types 253 and 254) may be used for zone signing. Note [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and
that the registry does not contain the requirement level of each 254) may be used for zone signing. Note that the registry does not
algorithm, only whether or not an algorithm may be used for the contain the requirement level of each algorithm, only whether or not
given purposes. For example, RSA/MD5, while allowed for an algorithm may be used for the given purposes. For example,
transaction security mechanisms, is NOT RECOMMENDED, per RFC3110. RSA/MD5, while allowed for transaction security mechanisms, is NOT
RECOMMENDED, per [RFC3110].
Additionally, the presentation format algorithm mnemonics from Additionally, the presentation format algorithm mnemonics from
RFC2535 Section 7 are added to the registry. This document assigns [RFC2535] Section 7 are added to the registry. This document assigns
RSA/SHA-1 the mnemonic RSASHA1. RSA/SHA-1 the mnemonic RSASHA1.
As before, assignment of new algorithms in this registry requires As before, assignment of new algorithms in this registry requires
IETF Standards Action. Additionally, modification of algorithm IETF Standards Action. Additionally, modification of algorithm
mnemonics or applicability requires IETF Standards Action. mnemonics or applicability requires IETF Standards Action. Documents
Documents defining a new algorithm must address the applicability defining a new algorithm must address the applicability of the
of the algorithm and should assign a presentation mnemonic to the algorithm and should assign a presentation mnemonic to the algorithm.
algorithm.
4.3 DNSKEY Flags 4.3. DNSKEY Flags
Like the KEY resource record, DNSKEY contains a 16-bit flags field. Like the KEY resource record, DNSKEY contains a 16-bit flags field.
This document creates a new registry for the DNSKEY flags field. This document creates a new registry for the DNSKEY flags field.
Initially, this registry only contains an assignment for bit 7 (the Initially, this registry only contains an assignment for bit 7 (the
ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
Standards Action. Standards Action.
4.4 DNSKEY Protocol Octet 4.4. DNSKEY Protocol Octet
Like the KEY resource record, DNSKEY contains an eight bit protocol Like the KEY resource record, DNSKEY contains an eight bit protocol
field. The only defined value for this field is 3 (DNSSEC). No field. The only defined value for this field is 3 (DNSSEC). No
other values are allowed, hence no IANA registry is needed for this other values are allowed, hence no IANA registry is needed for this
field. field.
5. Security Considerations 5. Security Considerations
The changes introduced here do not materially affect security. The changes introduced here do not materially affect security. The
The implications of trying to use both new and legacy types implications of trying to use both new and legacy types together are
together are not well understood, and attempts to do so would not well understood, and attempts to do so would probably lead to
probably lead to unintended and dangerous results. unintended and dangerous results.
Changing type codes will leave code paths in legacy resolvers that Changing type codes will leave code paths in legacy resolvers that
are never exercised. Unexercised code paths are a frequent source are never exercised. Unexercised code paths are a frequent source of
of security holes, largely because those code paths do not get security holes, largely because those code paths do not get frequent
frequent scrutiny. scrutiny.
Doing nothing, as described in section 2.5, will slow DNSSEC Doing nothing, as described in section 2.5, will slow DNSSEC
deployment. While this does not decrease security, it also fails deployment. While this does not decrease security, it also fails to
to increase it. increase it.
6. Normative references
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", 6. References
RFC 2535, March 1999.
[DS] Gudmundsson, O., "Delegation Signer Resource Record", 6.1. Normative References
draft-ietf-dnsext-delegation-signer-15.txt, work in
progress, June 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
(SIG(0)s)", RFC 2931, September 2000. 2535, March 1999.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
RR)", RFC 2930, September 2000. (DNS)", RFC 2536, March 1999.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
System (DNS)", RFC 2436, March 1999. RFC 2930, September 2000.
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
Domain Name System (DNS)", RFC 2539, March 1999. (SIG(0)s)", RFC 2931, September 2000.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Domain Name System (DNS)", RFC 3110, May 2001. Name System (DNS)", RFC 3110, May 2001.
7. Informative References [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 6.2. Informative References
Extensions", RFC 2065, January 1997.
[RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999. 2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001. 3225, December 2001.
[RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42,
RFC 2929, September 2000.
[RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002. Resource Record (RR)", RFC 3445, December 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
Record (RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
8. Acknowledgments 7. Acknowledgments
The changes introduced here and the analysis of alternatives had The changes introduced here and the analysis of alternatives had many
many contributors. With apologies to anyone overlooked, those contributors. With apologies to anyone overlooked, those include:
include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
Lewis, Bill Manning, and Suzanne Woolf. Bill Manning, Paul Vixie, and Suzanne Woolf.
Thanks to Jakob Schlyter and Mark Andrews for identifying the Thanks to Jakob Schlyter and Mark Andrews for identifying the
incompatibility described in section 1.2. incompatibility described in section 1.2.
In addition to the above, the author would like to thank Scott In addition to the above, the author would like to thank Scott Rose,
Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive Olafur Gudmundsson, and Sandra Murphy for their substantive comments.
comments.
9. Author's Address 8. Author's Address
Samuel Weiler Samuel Weiler
SPARTA, Inc. SPARTA, Inc.
7075 Samuel Morse Drive 7075 Samuel Morse Drive
Columbia, MD 21046 Columbia, MD 21046
USA USA
weiler@tislabs.com
EMail: weiler@tislabs.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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