mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-09-01 23:25:38 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2003-07-09 21:58:32 +00:00
parent dbd34ac1d0
commit d8014b55f2
1 changed files with 38 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-02.txt → doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-03.txt
View File

@@ -1,10 +1,11 @@
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
@@ -44,12 +45,16 @@ Abstract
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).
@@ -89,11 +94,11 @@ Changes between 01 and 02:
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
@@ -108,15 +113,15 @@ Changes between 01 and 02:
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 --
@@ -164,7 +169,7 @@ Changes between 01 and 02:
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
@@ -177,16 +182,16 @@ Changes between 01 and 02:
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 under specification 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
@@ -219,10 +224,10 @@ Changes between 01 and 02:
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
@@ -239,11 +244,12 @@ Changes between 01 and 02:
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
@@ -256,8 +262,8 @@ Changes between 01 and 02:
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
@@ -312,7 +318,6 @@ Changes between 01 and 02:
Record Types. draft-ietf-dnsext-unknown-rrs-05.txt Record Types. draft-ietf-dnsext-unknown-rrs-05.txt
Publication as RFC pending. 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
@@ -330,9 +335,9 @@ Changes between 01 and 02:
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