draft-ietf-dnsext-dnssec-2535typecode-change-06.txt

bind 源码 最新实现 linux/unix/windows平台

   This approach has not been tested.

2.5. Do nothing

   There is a large deployed base of DNS resolvers that understand
   DNSSEC as defined by the standards track RFC 2535 and RFC 2065
   and, due to under specification in those documents, interpret any
   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
   zones that contain unsecure delegations, lest those delegations be
   invisible to such a large installed base.  This will dramatically
   slow DNSSEC adoption.

   Unfortunately, without signed zones there's no clear incentive for
   operators of resolvers to upgrade their software to support the new
   version of DNSSEC, as defined in [DS].  Historical data suggests
   that resolvers are rarely upgraded, and that old nameserver code
   never dies.

   Rather than wait years for resolvers to be upgraded through natural
   processes before signing zones with unsecure delegations,
   addressing this problem with a protocol change will immediately
   remove the disincentive for signing zones and allow widespread
   deployment of DNSSEC.

3. Protocol changes

   This document changes the type codes of SIG, KEY, and NXT.  This
   approach is the cleanest and safest of those discussed above,
   largely because the behavior of resolvers that receive 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
   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
   with the mnemonic indicating that these keys are not for
   application use, per [RFC3445].  RRSIG (Resource Record SIGnature)
   will replace SIG, and NSEC (Next SECure) will replace NXT.  These
   new types completely replace the old types, except that SIG(0)
   [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.

   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
   the following:

      1) Consistent with [RFC3597], domain names embedded in
      RRSIG and NSEC RRs MUST NOT be compressed,

      2) Embedded domain names in RRSIG and NSEC RRs are not downcased
      for purposes of DNSSEC canonical form and ordering nor for
      equality comparison, and

      3) An RRSIG with a type-covered field of zero has undefined
      semantics.  The meaning of such a resource record may only be
      defined by IETF Standards Action.

   If a resolver receives the old types, it SHOULD treat them as
   unknown RRs and SHOULD NOT assign any special meaning to them or
   give them any special treatment.  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.  If SIG, KEY, or NXT RRs are included in a zone,
   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.
   Authoritative servers may wish to give error messages when loading
   zones containing SIG or NXT records (KEY records may be included
   for SIG(0) or TKEY).

   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.1 DNS Resource Record Types

   This document updates the IANA registry for DNS Resource Record
   Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
   DNSKEY RRs, respectively.

   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
   TKEY [RFC2930] use only.

   Type 30 (NXT) should be marked as Obsolete.

4.2 DNS Security Algorithm Numbers

   To allow zone signing (DNSSEC) and transaction security mechanisms
   (SIG(0) and TKEY) to use different sets of algorithms, the existing
   "DNS Security Algorithm Numbers" registry is modified to include
   the applicability of each algorithm.  Specifically, two new columns
   are added to the registry, showing whether each algorithm may be
   used for zone signing, transaction security mechanisms, or both.
   Only algorithms usable for zone signing may be used in DNSKEY,
   RRSIG, and DS RRs.  Only algorithms usable for SIG(0) and/or TSIG
   may be used in SIG and KEY RRs.

   All currently defined algorithms remain usable for transaction
   security mechanisms.  Only RSA/SHA-1, DSA/SHA-1, and private
   algorithms (types 253 and 254) may be used for zone signing.  Note
   that the registry does not contain the requirement level of each
   algorithm, only whether or not an algorithm may be used for the
   given purposes.  For example, RSA/MD5, while allowed for
   transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.

   Additionally, the presentation format algorithm mnemonics from
   RFC2535 Section 7 are added to the registry.  This document assigns
   RSA/SHA-1 the mnemonic RSASHA1.

   As before, assignment of new algorithms in this registry requires
   IETF Standards Action.  Additionally, modification of algorithm
   mnemonics or applicability requires IETF Standards Action.
   Documents defining a new algorithm must address the applicability
   of the algorithm and should assign a presentation mnemonic to the
   algorithm.

4.3 DNSKEY Flags

   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
   This document creates a new registry for the DNSKEY flags field.

   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
   Standards Action.

4.4 DNSKEY Protocol Octet

   Like the KEY resource record, DNSKEY contains an eight bit protocol
   field.  The only defined value for this field is 3 (DNSSEC).  No
   other values are allowed, hence no IANA registry is needed for this
   field.

5. Security Considerations

   The changes introduced here do not materially affect security.
   The implications of trying to use both new and legacy types
   together are not well understood, and attempts to do so would
   probably lead to unintended and dangerous results.

   Changing type codes will leave code paths in legacy resolvers that
   are never exercised.  Unexercised code paths are a frequent source
   of security holes, largely because those code paths do not get
   frequent scrutiny.

   Doing nothing, as described in section 2.5, will slow DNSSEC
   deployment.  While this does not decrease security, it also fails
   to increase it.

6. Normative references

   [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
             RFC 2535, March 1999.

   [DS]      Gudmundsson, O., "Delegation Signer Resource Record",
             draft-ietf-dnsext-delegation-signer-15.txt, work in
             progress, June 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.

   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
             RR)", RFC 2930, September 2000.

   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
             System (DNS)", RFC 2436, March 1999.

   [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
             Domain Name System (DNS)", RFC 2539, March 1999.

   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
             Domain Name System (DNS)", RFC 3110, May 2001.

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
	     2671, August 1999.

   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
             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
	     Resource Record (RR)", RFC 3445, December 2002.

   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
             Record (RR) Types", RFC 3597, September 2003.

8. Acknowledgments

   The changes introduced here and the analysis of alternatives had
   many contributors.  With apologies to anyone overlooked, those
   include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
   Lewis, Bill Manning, and Suzanne Woolf.

   Thanks to Jakob Schlyter and Mark Andrews for identifying the
   incompatibility described in section 1.2.

   In addition to the above, the author would like to thank Scott
   Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
   comments.

9. Author's Address

   Samuel Weiler
   SPARTA, Inc.
   7075 Samuel Morse Drive
   Columbia, MD 21046
   USA
   [e-mail]