draft-ietf-dnsext-dnssec-2535typecode-change-02.txt   draft-ietf-dnsext-dnssec-2535typecode-change-03.txt 
INTERNET-DRAFT Samuel Weiler INTERNET-DRAFT Samuel Weiler
Expires: December 2003 June 12, 2003 Expires: December 2003 June 29, 2003
Updates: RFC 2535, [DS] Updates: RFC 2535, [DS]
Legacy Resolver Compatibility for Delegation Signer Legacy Resolver Compatibility for Delegation Signer
draft-ietf-dnsext-dnssec-2535typecode-change-02.txt draft-ietf-dnsext-dnssec-2535typecode-change-03.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 47 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 02 and 03:
KEY (as well as SIG) retained for SIG(0) use only.
Changes between 01 and 02: Changes between 01 and 02:
SIG(0) still uses SIG, not RRSIG. Added 2931 reference. SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
Domain names embedded in NSECs and RRSIGs are not compressible and Domain names embedded in NSECs and RRSIGs are not compressible and
are not downcased. Added unknown-rrs reference. are not downcased. Added unknown-rrs reference (as informative).
Simplified the last paragraph of section 3 (NSEC doesn't always Simplified the last paragraph of section 3 (NSEC doesn't always
signal a negative answer). signal a negative answer).
Changed the suggested type code assignments. Changed the suggested type code assignments.
Added 2119 reference. Added 2119 reference.
Added definitions of "unsecure delegation" and "unsecure referral", Added definitions of "unsecure delegation" and "unsecure referral",
since they're not clearly defined elsewhere. since they're not clearly defined elsewhere.
skipping to change at line 92 skipping to change at line 96
behaviors. This variety makes it difficult to predict how a behaviors. This variety makes it difficult to predict how a
protocol change will be handled by all deployed resolvers. The protocol change will be handled by all deployed resolvers. The
risk that a change will cause unacceptable or even catastrophic risk that a change will cause unacceptable or even catastrophic
failures makes it difficult to design and deploy a protocol change. failures makes it difficult to design and deploy a protocol change.
One strategy for managing that risk is to structure protocol One strategy for managing that risk is to structure protocol
changes so that existing resolvers can completely ignore input that changes so that existing resolvers can completely ignore input that
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 RFC 2535 [RFC2535]. Answers
DS-aware servers can trigger an unacceptable failure mode in some provided by DS-aware servers can trigger an unacceptable failure
resolvers that implement RFC 2535, which provides a great mode in some resolvers that implement RFC 2535, which provides a
disincentive to sign zones with DS. The proposed solution allows great disincentive to sign zones with DS. The proposed solution
for the incremental deployment of DS. allows 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 for which no DS record appears at the parent. An delegation for which no DS record appears at the parent. An
"unsecure referral" is an answer from the parent containing an NS "unsecure referral" is an answer from the parent containing an NS
RRset and a proof that no DS record exists for that name. RRset and a proof that 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 [DS] introduces new semantics for the NXT RR that Delegation Signer introduces new semantics for the NXT RR that are
are incompatible with the semantics in [RFC2535]. In [RFC2535], incompatible with the semantics in RFC 2535. In RFC 2535, NXT
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 proof. With 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, RCODE=0, and AA=0. Some widely deployed 2535-aware
2535-aware resolvers interpret any answer with an NXT as a proof of 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
delegations. 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.
skipping to change at line 167 skipping to change at line 171
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 with DS semantics is to have authoritative servers only records with DS semantics is to have authoritative servers only
send that data to DS-aware resolvers. It's been proposed that send that data to DS-aware resolvers. It's been proposed that
assigning a new EDNS0 flag bit to signal DS-awareness (tentatively assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
called "DA"), and having authoritative servers send DNSSEC data called "DA"), and having authoritative servers send DNSSEC data
only in response to queries with the DA bit set, would accomplish only in response to queries with the DA bit set, would accomplish
this. This bit would presumably supplant the DO bit described in this. This bit would 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 EDNS0 flags that they don't understand. If one passed through out EDNS0 flags that they don't understand. If one passed through
the DA bit unchanged, it would still see the new semantics, and it the DA bit unchanged, it would still see the new semantics, and it
would probably fail to see unsecure delegations. Since it's would probably fail to see unsecure delegations. Since it's
impractical to know how every DNS implementation handles unknown impractical to know how every DNS implementation handles unknown
EDNS0 flags, this is not a universal solution. It could, though, EDNS0 flags, this is not a universal solution. It could, though,
be considered in addition to changing the RR type codes. be considered in addition to changing the RR type codes.
2.4. Increment the EDNS version 2.4. Increment the EDNS version
Another proposed solution is to increment the EDNS version number Another proposed solution is to increment the EDNS version number
as defined in [RFC2671], on the assumption that all existing as defined in RFC 2671 [RFC2671], on the assumption that all
implementations will reject higher versions than they support, existing implementations will reject higher versions than they
and retain the DO bit as the signal for DNSSEC awareness. This support, and retain the DO bit as the signal for DNSSEC awareness.
approach has not been tested. This approach 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 [RFC2535] and [RFC2065] DNSSEC as defined by the standards track RFC 2535 and RFC 2065
and, due to underspecification in those documents, interpret any and, due to underspecification in those documents, interpret any
answer with an NXT as a non-existence proof. So long as that is answer with an NXT as a non-existence proof. So long as that is
the case, zone owners will have a strong incentive to not sign any the case, zone owners will have a strong incentive to not sign any
zones that contain unsecure delegations, lest those delegations be zones that contain unsecure delegations, lest those delegations be
invisible to such a large installed base. This will dramatically invisible to such a large installed base. This will dramatically
slow DNSSEC adoption. slow DNSSEC 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 [DS]. Historical data suggests
skipping to change at line 222 skipping to change at line 226
above, largely because the behavior of resolvers that receive above, largely because the behavior of resolvers that receive
unknown type codes is well understood. This approach has also unknown type codes is well understood. This approach has also
received the most testing. 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. These will replace SIG, and NSEC (Next SECure) will replace NXT. These
new types completely replace the old types, except that SIG(0) new types completely replace the old types, except that SIG(0)
[RFC2931] will continue to use SIG. [RFC2931] 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 [RFC2535] and [DS] except for specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
the following: the following:
1) Consistent with [UNKNOWN-RRs], domain names embedded in 1) Consistent with [UNKNOWN-RRs], domain names embedded in
RRSIG and NSEC RRs MUST NOT be compressed, RRSIG and NSEC 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 purposes of DNSSEC canonical form and ordering nor for for purposes of DNSSEC canonical form and ordering nor for
equality comparison, and equality 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. semantics.
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 RRs and SHOULD NOT assign any special semantic value to unknown RRs and SHOULD NOT assign any special semantic value to
them. It MUST NOT use them for DNSSEC validations or other DNS them. It MUST NOT use them for DNSSEC validations or other DNS
operational decision making. For example, a resolver MUST NOT use operational decision making. For example, a resolver MUST NOT use
DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. If SIG,
Authoritative servers SHOULD NOT serve SIG, KEY, or NXT records. KEY, or NXT RRs are included in a zone, they MUST NOT receive
If those records are included, they MUST NOT receive special special treatment. As an example, if a SIG is included in a signed
treatment. As an example, if a SIG is included in a signed zone, zone, there MUST be an RRSIG for it. Authoritative servers may
there MUST be an RRSIG for it. wish to give error messages when loading zones containing SIG or
NXT records (KEY records may be included for SIG(0)).
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 answers merely because they contain an NSEC. 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 RRSIG, NSEC, and Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
DNSKEY RRs, respectively. DNSKEY RRs, respectively.
Types 24 (SIG) is retained for SIG(0) [RFC2931] use only. Types 25 Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931]
and 30 (KEY and NXT) should be marked as Obsolete. use only. Type 30 (NXT) should be marked as Obsolete.
5. Security Considerations 5. Security Considerations
The change proposed here does not materially affect 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
skipping to change at line 332 skipping to change at line 337
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, 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 SPARTA, Inc.
15204 Omega Dr., Suite 300 7075 Samuel Morse Drive
Rockville, MD 20850 Columbia, MD 21046
USA USA
weiler@tislabs.com weiler@tislabs.com
 End of changes. 

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