rfc2845.txt

bind 9.3结合mysql数据库

   4.6.3. MAC error handling

   If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
   this is a MAC error, and client MAY retry the request with a new
   request ID but it would be better to try a different shared key if
   one is available.  Client SHOULD keep track of how many MAC errors
   are associated with each key.  Clients SHOULD log this event.

   4.7. Special considerations for forwarding servers

   A server acting as a forwarding server of a DNS message SHOULD check
   for the existence of a TSIG record.  If the name on the TSIG is not
   of a secret that the server shares with the originator the server
   MUST forward the message unchanged including the TSIG.  If the name
   of the TSIG is of a key this server shares with the originator, it
   MUST process the TSIG.  If the TSIG passes all checks, the forwarding
   server MUST, if possible, include a TSIG of his own, to the
   destination or the next forwarder.  If no transaction security is
   available to the destination and the response has the AD flag (see
   [RFC2535]), the forwarder MUST unset the AD flag before adding the
   TSIG to the answer.

5 - Shared Secrets

   5.1. Secret keys are very sensitive information and all available
   steps should be taken to protect them on every host on which they are
   stored.  Generally such hosts need to be physically protected.  If
   they are multi-user machines, great care should be taken that
   unprivileged users have no access to keying material.  Resolvers
   often run unprivileged, which means all users of a host would be able
   to see whatever configuration data is used by the resolver.

   5.2. A name server usually runs privileged, which means its
   configuration data need not be visible to all users of the host.  For
   this reason, a host that implements transaction-based authentication
   should probably be configured with a "stub resolver" and a local
   caching and forwarding name server.  This presents a special problem
   for [RFC2136] which otherwise depends on clients to communicate only
   with a zone's authoritative name servers.

   5.3. Use of strong random shared secrets is essential to the security
   of TSIG.  See [RFC1750] for a discussion of this issue.  The secret
   should be at least as long as the keyed message digest, i.e. 16 bytes
   for HMAC-MD5 or 20 bytes for HMAC-SHA1.







Vixie, et al.               Standards Track                    [Page 11]

RFC 2845                        DNS TSIG                        May 2000


6 - Security Considerations

   6.1. The approach specified here is computationally much less
   expensive than the signatures specified in [RFC2535].  As long as the
   shared secret key is not compromised, strong authentication is
   provided for the last hop from a local name server to the user
   resolver.

   6.2. Secret keys should be changed periodically.  If the client host
   has been compromised, the server should suspend the use of all
   secrets known to that client.  If possible, secrets should be stored
   in encrypted form.  Secrets should never be transmitted in the clear
   over any network.  This document does not address the issue on how to
   distribute secrets. Secrets should never be shared by more than two
   entities.

   6.3. This mechanism does not authenticate source data, only its
   transmission between two parties who share some secret.  The original
   source data can come from a compromised zone master or can be
   corrupted during transit from an authentic zone master to some
   "caching forwarder."  However, if the server is faithfully performing
   the full [RFC2535] security checks, then only security checked data
   will be available to the client.

   6.4. A fudge value that is too large may leave the server open to
   replay attacks.  A fudge value that is too small may cause failures
   if machines are not time synchronized or there are unexpected network
   delays.  The recommended value in most situation is 300 seconds.

7 - IANA Considerations

   IANA is expected to create and maintain a registry of algorithm names
   to be used as "Algorithm Names" as defined in Section 2.3.  The
   initial value should be "HMAC-MD5.SIG-ALG.REG.INT".  Algorithm names
   are text strings encoded using the syntax of a domain name.  There is
   no structure required other than names for different algorithms must
   be unique when compared as DNS names, i.e., comparison is case
   insensitive.  Note that the initial value mentioned above is not a
   domain name, and therefore need not be a registered name within the
   DNS.  New algorithms are assigned using the IETF Consensus policy
   defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
   looks like a FQDN for historical reasons; future algorithm names are
   expected to be simple (i.e., single-component) names.








Vixie, et al.               Standards Track                    [Page 12]

RFC 2845                        DNS TSIG                        May 2000


   IANA is expected to create and maintain a registry of "TSIG Error
   values" to be used for "Error" values as defined in section 2.3.
   Initial values should be those defined in section 1.7.  New TSIG
   error codes for the TSIG error field are assigned using the IETF
   Consensus policy defined in RFC 2434.

8 - References

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

   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1034, November 1987.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

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

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

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

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

   [RFC2137]  Eastlake 3rd, D., "Secure Domain Name System Dynamic
              Update", RFC 2137, April 1997.

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

   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
              RFC 2673, August 1999.













Vixie, et al.               Standards Track                    [Page 13]

RFC 2845                        DNS TSIG                        May 2000


9 - Authors' Addresses

   Paul Vixie
   Internet Software Consortium
   950 Charter Street
   Redwood City, CA 94063

   Phone: [phone]
   EMail: [e-mail]


   Olafur Gudmundsson
   NAI Labs
   3060 Washington Road, Route 97
   Glenwood, MD 21738

   Phone: [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]


   Brian Wellington
   Nominum, Inc.
   950 Charter Street
   Redwood City, CA 94063

   Phone: [phone]
   EMail: [e-mail]















Vixie, et al.               Standards Track                    [Page 14]

RFC 2845                        DNS TSIG                        May 2000


10  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.



















Vixie, et al.               Standards Track                    [Page 15]