rfc3445.txt

bind 9.3结合mysql数据库


RFC 3445         Limiting the KEY Resource Record (RR)     December 2002


4. Changes from RFC 2535 KEY RR

   The KEY RDATA format is not changed.

   All flags except for the zone key flag are eliminated:

      The A/C bits (bits 0 and 1) are eliminated.  They MUST be set to 0
      and MUST be ignored by the receiver.

      The extended flags bit (bit 3) is eliminated.  It MUST be set to 0
      and MUST be ignored by the receiver.

      The host/user bit (bit 6) is eliminated.  It MUST be set to 0 and
      MUST be ignored by the receiver.

      The zone bit (bit 7) remains unchanged.

      The signatory field (bits 12-15) are eliminated by [5].  They MUST
      be set to 0 and MUST be ignored by the receiver.

      Bits 2,4,5,8,9,10,11 remain unchanged.  They are reserved, MUST be
      set to zero and MUST be ignored by the receiver.

   Assignment of any future KEY RR Flag values requires a standards
   action.

   All Protocol Octet values except DNSSEC (3) are eliminated:

      Value 1 (Email) is renamed to RESERVED.

      Value 2 (IPSEC) is renamed to RESERVED.

      Value 3 (DNSSEC) is unchanged.

      Value 4 (TLS) is renamed to RESERVED.

      Value 5-254 remains unchanged (reserved).

      Value 255 (ANY) is renamed to RESERVED.

   The authoritative data for a zone MUST NOT include any KEY records
   with a protocol octet other than 3.  The registry maintained by IANA
   for protocol values is closed for new assignments.

   Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
   RRs with a value other than 3.  If out of date DNS zones contain
   deprecated KEY RRs with a protocol octet value other than 3, then
   simply dropping the deprecated KEY RRs from the KEY RR set would



Massey & Rose               Standards Track                     [Page 6]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002


   invalidate any associated SIG record(s) and could create caching
   consistency problems.  Note that KEY RRs with a protocol octet value
   other than 3 MUST NOT be used to authenticate DNS data.

   The algorithm and public key fields are not changed.

5. Backward Compatibility

   DNSSEC zone KEY RRs are not changed and remain backwards compatible.
   A properly formatted RFC 2535 zone KEY would have all flag bits,
   other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
   Octet set to 3.  This remains true under the restricted KEY.

   DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
   but the distinction between host and user keys (flag bit 6) is lost.

   No backwards compatibility is provided for application keys.  Any
   Email, IPSEC, or TLS keys are now deprecated.  Storing application
   keys in the KEY RR created problems such as keys at the apex and
   large RR sets and some change in the definition and/or usage of the
   KEY RR would have been required even if the approach described here
   were not adopted.

   Overall, existing nameservers and resolvers will continue to
   correctly process KEY RRs with a sub-type of DNSSEC keys.

6. Storing Application Keys in the DNS

   The scope of this document is strictly limited to the KEY record.
   This document prohibits storing application keys in the KEY record,
   but it does not endorse or restrict the storing application keys in
   other record types.  Other documents can describe how DNS handles
   application keys.

7. IANA Considerations

   RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
   values.  Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
   values 5-254 were made available for assignment by IANA.  This
   document makes two sets of changes to this registry.

   First, this document re-assigns DNS KEY RR Protocol Octet values 1,
   2, 4, and 255 to "reserved".  DNS Key RR Protocol Octet Value 3
   remains unchanged as "DNSSEC".







Massey & Rose               Standards Track                     [Page 7]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002


   Second, new values are no longer available for assignment by IANA and
   this document closes the IANA registry for DNS KEY RR Protocol Octet
   Values.  Assignment of any future KEY RR Protocol Octet values
   requires a standards action.

8. Security Considerations

   This document eliminates potential security problems that could arise
   due to the coupling of DNS zone keys and application keys.  Prior to
   the change described in this document, a correctly authenticated KEY
   set could include both application keys and DNSSEC keys.  This
   document restricts the KEY RR to DNS security usage only.  This is an
   attempt to simplify the security model and make it less user-error
   prone.  If one of the application keys is compromised, it could be
   used as a false zone key to create false DNS signatures (SIG
   records).  Resolvers that do not carefully check the KEY sub-type
   could believe these false signatures and incorrectly authenticate DNS
   data.  With this change, application keys cannot appear in an
   authenticated KEY set and this vulnerability is eliminated.

   The format and correct usage of DNSSEC keys is not changed by this
   document and no new security considerations are introduced.

9. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

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

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

   [4]  Eastlake, D., "DNS Request and Transaction Signatures
        (SIG(0)s)", RFC 2931, September 2000.

   [5]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
        Update", RFC 3007, November 2000.












Massey & Rose               Standards Track                     [Page 8]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002


10. Authors' Addresses

   Dan Massey
   USC Information Sciences Institute
   3811 N. Fairfax Drive
   Arlington, VA  22203
   USA

   EMail: [e-mail]


   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-3460
   USA

   EMail: [e-mail]

































Massey & Rose               Standards Track                     [Page 9]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Massey & Rose               Standards Track                    [Page 10]