draft-ietf-dnsext-dnssec-2535typecode-change-01.txt   draft-ietf-dnsext-dnssec-2535typecode-change-02.txt 
INTERNET-DRAFT Samuel Weiler INTERNET-DRAFT Samuel Weiler
Expires: November 2003 May 22, 2003 Expires: December 2003 June 12, 2003
Updates: RFC 2535, [DS]
Legacy Resolver Compatibility for Delegation Signer Legacy Resolver Compatibility for Delegation Signer
draft-ietf-dnsext-dnssec-2535typecode-change-01.txt draft-ietf-dnsext-dnssec-2535typecode-change-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 45 skipping to change at line 47
syntax and semantics of the DNSSEC resource records (RRs) have syntax and semantics of the DNSSEC resource records (RRs) have
changed. Many deployed nameservers understand variants of these changed. Many deployed nameservers understand variants of these
semantics. Dangerous interactions can occur when a resolver that semantics. Dangerous interactions can occur when a resolver that
understands an earlier version of these semantics queries an understands an earlier version of these semantics queries an
authoritative server that understands the new delegation signer authoritative server that understands the new delegation signer
semantics, including at least one failure scenario that will cause semantics, including at least one failure scenario that will cause
an unsecured zone to be unresolvable. This document proposes that an unsecured zone to be unresolvable. This document proposes that
these interactions be avoided by changing the type codes and these interactions be avoided by changing the type codes and
mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). mnemonics of the DNSSEC RRs (SIG, KEY, and NXT).
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.
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 semantics are not completely compatible. This has occurred as and semantics are not completely compatible. This has occurred as
part of the ordinary process of proposing a protocol, implementing part of the ordinary process of proposing a protocol, implementing
it, testing it in the increasingly complex and diverse environment it, testing it in the increasingly complex and diverse environment
of the Internet, and refining the definitions of the initial of the Internet, and refining the definitions of the initial
Proposed Standard. In the case of DNSSEC, the process has been Proposed Standard. In the case of DNSSEC, the process has been
complicated by DNS's criticality and wide deployment and the need complicated by DNS's criticality and wide deployment and the need
to add security while minimizing daily operational complexity. to add security while minimizing daily operational complexity.
skipping to change at line 77 skipping to change at line 98
might confuse them or trigger undesirable failure modes. might confuse them or 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] introduction of new semantics for the NXT RR that are
incompatible with the semantics in [RFC2535]. Answers provided by incompatible with the semantics in [RFC2535]. Answers provided by
DS-aware servers can trigger an unacceptable failure mode in some DS-aware servers can trigger an unacceptable failure mode in some
resolvers that implement RFC 2535, which provides a great resolvers that implement RFC 2535, which provides a great
disincentive to sign zones with DS. The proposed solution allows disincentive to sign zones with DS. The proposed solution allows
for the incremental deployment of DS. for the incremental deployment of DS.
1.1 The Problem 1.1 Terminology
Delegation signer [DS] introduces new semantics for the NXT RR that In this document, the term "unsecure delegation" means any
delegation for which no DS record appears at the parent. An
"unsecure referral" is an answer from the parent containing an NS
RRset and a proof that no DS record exists for that name.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2 The Problem
Delegation Signer [DS] introduces new semantics for the NXT RR that
are incompatible with the semantics in [RFC2535]. In [RFC2535], are incompatible with the semantics in [RFC2535]. In [RFC2535],
NXT records were only required to be returned as part of a NXT records were only required to be returned as part of a
non-existence proof. In [DS], an unsecure referral returns, in non-existence proof. With DS, an unsecure referral returns, in
addition to the NS, a proof of non-existence of a DS RR in the form addition to the NS, a proof of non-existence of a DS RR in the form
of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
to interpret a response with both an NS and an NXT in the authority to interpret a response with both an NS and an NXT in the authority
section and with NOERROR or NODATA set. Some widely deployed section and with NOERROR or NODATA set. Some widely deployed
2535-aware resolvers interpret any answer with an NXT as a proof of 2535-aware resolvers interpret any answer with an NXT as a proof of
non-existence of the requested record. This results in unsecure non-existence of the requested record. This results in unsecure
delegations being invisible to 2535-aware resolvers and violates delegations being invisible to 2535-aware resolvers and violates
the basic architectural principle that DNSSEC must do no harm -- the basic architectural principle that DNSSEC must do no harm --
the signing of zones must not prevent the resolution of unsecured the signing of zones must not prevent the resolution of unsecured
names. delegations.
2. Possible Solutions 2. Possible Solutions
This section presents several possible solutions. Section 3 This section presents several possible solutions. Section 3
recommends one and describes it in more detail. recommends one and describes it in more detail.
2.1. Change SIG, KEY, and NXT 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 NXT records in the authority section. The simplest way to include NXT records in the authority section. The simplest way to
do that is to change the type codes for SIG, KEY, and NXT. do that is 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)
skipping to change at line 179 skipping to change at line 211
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 this problem with a protocol change will immediately addressing this problem with a protocol change will immediately
remove the disincentive for signing zones and allow widespread remove the disincentive for signing zones and allow widespread
deployment of DNSSEC. deployment of DNSSEC.
3. Protocol changes 3. Protocol changes
This document proposes changing the type codes of SIG, KEY, and This document proposes changing the type codes of SIG, KEY, and
NXT. This solution is the cleanest and safest, largely because the NXT. This approach is the cleanest and safest of those discussed
behavior of resolvers that receive unknown type codes is well above, largely because the behavior of resolvers that receive
understood. This approach has also received the most testing. unknown type codes is well understood. This approach has also
received the most 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 use, per [RFC3445]. RRSIG (Resource Record SIGnature) application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
will replace SIG, and NSEC (Next SECure) will replace NXT. will replace SIG, and NSEC (Next SECure) will replace NXT. These
new types completely replace the old types, except that SIG(0)
[RFC2931] will continue to use SIG.
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 [RFC2535] and [DS], and they specified for SIG, KEY, and NXT in [RFC2535] and [DS] except for
completely replace the old types. A resolver, if it receives the the following:
old types, SHOULD treat them as unknown RRs, and SHOULD NOT assign
any special semantic value to them. It MUST NOT use them for
DNSSEC validations or other DNS operational decision making. For
example, a resolver MUST NOT use DNSKEYs to validate SIGs or use
KEYs to validate RRSIGs. Authoritative servers SHOULD NOT serve
SIG, KEY, or NXT records. If those records are included, they MUST
NOT receive special treatment. As an example, if a SIG is included
in a signed zone, there MUST be an RRSIG for it.
As a clarification to previous documents, many positive responses, 1) Consistent with [UNKNOWN-RRs], domain names embedded in
including wildcard proofs and insecure referrals, will contain NSEC RRSIG and NSEC RRs MUST NOT be compressed,
RRs. As a result, resolvers MUST NOT treat answers with NSEC RRs
as negative answers merely because they contain an NSEC. A 2) Embedded domain names in RRSIG and NSEC RRs are not downcased
resolver SHOULD either ignore the NSEC, as a DNSSEC-unaware (or for purposes of DNSSEC canonical form and ordering nor for
2535-aware) resolver would, or validate the NSEC and check its equality comparison, and
applicability and interpretation as described in [RFC2535] and
[DS]. 3) An RRSIG with a type covered field of zero has undefined
semantics.
If a resolver receives the old types, it SHOULD treat them as
unknown RRs and SHOULD NOT assign any special semantic value to
them. It MUST NOT use them for DNSSEC validations or other DNS
operational decision making. For example, a resolver MUST NOT use
DNSKEYs to validate SIGs or use KEYs to validate RRSIGs.
Authoritative servers SHOULD NOT serve SIG, KEY, or NXT records.
If those records are included, they MUST NOT receive special
treatment. As an example, if a SIG is included in a signed zone,
there MUST be an RRSIG for it.
As a clarification to previous documents, some positive responses,
particularly wildcard proofs and unsecure referrals, will contain
NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
negative answers merely because they contain an NSEC.
4. IANA Considerations 4. IANA Considerations
This document updates the IANA registry for DNS Resource Record This document updates the IANA registry for DNS Resource Record
Types by assigning types 46, 47, and 48 to the DNSKEY, RRSIG, and Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
NSEC RRs, respectively. DNSKEY RRs, respectively.
Types 24, 25, and 30 (SIG, KEY, and NXT) should be marked as Types 24 (SIG) is retained for SIG(0) [RFC2931] use only. Types 25
Obsolete. and 30 (KEY and NXT) should be marked as Obsolete.
5. Security Considerations 5. Security Considerations
The change proposed here does not materially effect security. The The change proposed here does not materially affect security. The
implications of trying to use both new and legacy types together implications of trying to use both new and legacy types together
are not well understood, and attempts to do so would probably lead are not well understood, and attempts to do so would probably lead
to unintended and dangerous results. to 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 security holes, largely because those code paths do not get of security holes, largely because those code paths do not get
frequent scrutiny. frequent scrutiny.
Doing nothing, as described in 3.1, will slow DNSSEC deployment. Doing nothing, as described in 3.1, will slow DNSSEC deployment.
While this does not decrease security, it also fails to increase While this does not decrease security, it also fails to increase
it. it.
6. Normative references 6. Normative references
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[DS] Gudmundsson, O., "Delegation Signer Resource Record", [DS] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-14.txt, work in draft-ietf-dnsext-delegation-signer-14.txt, work in
progress, May 2003. progress, May 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
7. Informative References 7. Informative References
[RFC2065] Eastlake, 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. [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning.
Domain Name System (DNS) IANA Considerations. BCP 42, Domain Name System (DNS) IANA Considerations. BCP 42,
RFC 2929, September 2000. 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.
[UNKNOWN-RRs] Gustafsson, A. Handling of Unknown DNS Resource
Record Types. draft-ietf-dnsext-unknown-rrs-05.txt
Publication as RFC pending.
8. Acknowledgments 8. Acknowledgments
The proposed solution and the analysis of alternatives had many The proposed solution and the analysis of alternatives had many
contributors. With apologies to anyone overlooked, those include: contributors. With apologies to anyone overlooked, those include:
Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
Bill Manning, and Suzanne Woolf. Bill Manning, 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.1. 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, Olafur Gudmundsson, and Sandra Murphy for their substantive Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
comments. comments.
9. Author's Address 9. Author's Address
Samuel Weiler Samuel Weiler
Network Associates Laboratories Network Associates Laboratories
15204 Omega Dr., Suite 300 15204 Omega Dr., Suite 300
 End of changes. 

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