rfc2930.txt

bind 9.3结合mysql数据库

   The query TKEY RR inception and expiry give the time period the
   querier intends to consider the keying material valid.  The server
   can return a lesser time interval to advise that it will not maintain
   state for that long and can pre-expire keys in any case.

   This mode of query MUST be authenticated with a TSIG or SIG(0).
   Otherwise, an attacker can forge a resolver assigned TKEY query, and
   thereby the attacker could specify a shared secret key that would be
   accepted, used, and honored by the server.







Eastlake                    Standards Track                    [Page 11]

RFC 2930                    The DNS TKEY RR               September 2000


5. Spontaneous Server Inclusion

   A DNS server may include a TKEY RR spontaneously as additional
   information in responses.  This SHOULD only be done if the server
   knows the querier understands TKEY and has this option implemented.
   This technique can be used to delete a key and may be specified for
   modes defined in the future.  A disadvantage of this technique is
   that there is no way for the server to get any error or success
   indication back and, in the case of UDP, no way to even know if the
   DNS response reached the resolver.

5.1 Spontaneous Server Key Deletion

   A server can optionally tell a client that it has deleted a secret
   key by spontaneously including a TKEY RR in the additional
   information section of a response with the key's name and specifying
   the key deletion mode.  Such a response SHOULD be authenticated.  If
   authenticated, it "deletes" the key with the given name.  The
   inception and expiry times of the delete TKEY RR are ignored. Failure
   by a client to receive or properly process such additional
   information in a response would mean that the client might use a key
   that the server had discarded and would then get an error indication.

   For server assigned and Diffie-Hellman keys, the client MUST
   "discard" active state associated with the key.  For querier assigned
   keys, the querier MAY simply mark the key as no longer retained by
   the server and may re-send it in a future query specifying querier
   assigned keying material.

6. Methods of Encryption

   For the server assigned and resolver assigned key agreement modes,
   the keying material is sent within the key data field of a TKEY RR
   encrypted under the public key in an accompanying KEY RR [RFC 2535].
   This KEY RR MUST be for a public key algorithm where the public and
   private keys can be used for encryption and the corresponding
   decryption which recovers the originally encrypted data.  The KEY RR
   SHOULD correspond to a name for the decrypting resolver/server such
   that the decrypting process has access to the corresponding private
   key to decrypt the data.  The secret keying material being sent will
   generally be fairly short, usually less than 256 bits, because that
   is adequate for very strong protection with modern keyed hash or
   symmetric algorithms.

   If the KEY RR specifies the RSA algorithm, then the keying material
   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under



Eastlake                    Standards Track                    [Page 12]

RFC 2930                    The DNS TKEY RR               September 2000


   some other symmetric algorithm.)  In the unlikely event that the
   keying material will not fit within one RSA modulus of the chosen
   public key, additional RSA encryption blocks are included.  The
   length of each block is clear from the public RSA key specified and
   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
   encrypted data is actually keying material and what part is
   formatting or the required at least eight bytes of random [RFC 1750]
   padding.

7. IANA Considerations

   This section is to be interpreted as provided in [RFC 2434].

   Mode field values 0x0000 and 0xFFFF are reserved.

   Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
   can only be assigned by an IETF Standards Action.

   Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
   are allocated by IESG approval or IETF consensus.

   Mode field values 0x1000 through 0xEFFF are allocated based on
   Specification Required as defined in [RFC 2434].

   Mode values should not be changed when the status of their use
   changes.  For example, a mode value assigned based just on providing
   a specification should not be changed later just because that use's
   status is changed to standards track.

   The following assignments are documented herein:

      RR Type 249 for TKEY.

      TKEY Modes 1 through 5 as listed in section 2.5.

      Extended RCODE Error values of 19, 20, and 21 as listed in section
      2.6.

8. Security Considerations

   The entirety of this specification is concerned with the secure
   establishment of a shared secret between DNS clients and servers in
   support of TSIG [RFC 2845].

   Protection against denial of service via the use of TKEY is not
   provided.





Eastlake                    Standards Track                    [Page 13]

RFC 2930                    The DNS TKEY RR               September 2000


References

   [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
              Algorithms, and Source Code in C", 1996, John Wiley and
              Sons

   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specifications", STD 13, RFC 1035, November 1987.

   [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              September 1996.

   [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              August 1996.

   [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 2030, October 1996.

   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

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

   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
              April 1997.

   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
              Specifications Version 2.0", RFC 2437, October 1998.

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

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




Eastlake                    Standards Track                    [Page 14]

RFC 2930                    The DNS TKEY RR               September 2000


   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

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

Author's Address

   Donald E. Eastlake 3rd
   Motorola
   140 Forest Avenue
   Hudson, MA 01749 USA

   Phone: [phone] (h)
          [phone] (w)
   Fax:   [phone] (w)
   EMail: [e-mail]

































Eastlake                    Standards Track                    [Page 15]

RFC 2930                    The DNS TKEY RR               September 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Eastlake                    Standards Track                    [Page 16]