draft-ietf-dnsext-dnssec-2535typecode-change-00.txt   draft-ietf-dnsext-dnssec-2535typecode-change-01.txt 
INTERNET-DRAFT Samuel Weiler INTERNET-DRAFT Samuel Weiler
Expires: November 2003 May 12, 2003 Expires: November 2003 May 22, 2003
Legacy Resolver Compatibility for Delegation Signer Legacy Resolver Compatibility for Delegation Signer
draft-ietf-dnsext-dnssec-2535typecode-change-00.txt draft-ietf-dnsext-dnssec-2535typecode-change-01.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 202 skipping to change at line 201
completely replace the old types. A resolver, if it receives the completely replace the old types. A resolver, if it receives the
old types, SHOULD treat them as unknown RRs, and SHOULD NOT assign old types, SHOULD treat them as unknown RRs, and SHOULD NOT assign
any special semantic value to them. It MUST NOT use them for any special semantic value to them. It MUST NOT use them for
DNSSEC validations or other DNS operational decision making. For DNSSEC validations or other DNS operational decision making. For
example, a resolver MUST NOT use DNSKEYs to validate SIGs or use example, a resolver MUST NOT use DNSKEYs to validate SIGs or use
KEYs to validate RRSIGs. Authoritative servers SHOULD NOT serve KEYs to validate RRSIGs. Authoritative servers SHOULD NOT serve
SIG, KEY, or NXT records. If those records are included, they MUST SIG, KEY, or NXT records. If those records are included, they MUST
NOT receive special treatment. As an example, if a SIG is included NOT receive special treatment. As an example, if a SIG is included
in a signed zone, there MUST be an RRSIG for it. in a signed zone, there MUST be an RRSIG for it.
As a clarification to previous documents, NSEC can appear in the As a clarification to previous documents, many positive responses,
authority section of an answer at any time, not just in negative including wildcard proofs and insecure referrals, will contain NSEC
answers. The mere presence of an NSEC record in the answer or RRs. As a result, resolvers MUST NOT treat answers with NSEC RRs
authority section of an answer with RCODE=NOERROR, MUST NOT be as negative answers merely because they contain an NSEC. A
interpreted as a negative answer. The NSEC must be validated. resolver SHOULD either ignore the NSEC, as a DNSSEC-unaware (or
2535-aware) resolver would, or validate the NSEC and check its
applicability and interpretation as described in [RFC2535] and
[DS].
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 DNSKEY, RRSIG, and
NSEC RRs, respectively. NSEC RRs, respectively.
Types 24, 25, and 30 (SIG, KEY, and NXT) should be marked as Types 24, 25, and 30 (SIG, KEY, and NXT) should be marked as
Obsolete. Obsolete.
 End of changes. 

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