rfc2931.txt

bind 9.3结合mysql数据库


RFC 2931                       DNS SIG(0)                 September 2000


   That is

      data = RDATA | full query | response - SIG(0)

   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
   calculated less the signature itself.

   Verification of a response SIG(0) (which is signed by the server host
   key, not the zone key) by the requesting resolver shows that the
   query and response were not tampered with in transit, that the
   response corresponds to the intended query, and that the response
   comes from the queried server.

   In the case of a DNS message via TCP, a SIG(0) on the first data
   packet is calculated with "data" as above and for each subsequent
   packet, it is calculated as follows:

      data = RDATA | DNS payload - SIG(0) | previous packet

   where "|" is concatenations, RDATA is as above, and previous packet
   is the previous DNS payload including DNS header and the SIG(0) but
   not the TCP/IP header.  Support of SIG(0) for TCP is OPTIONAL.  As an
   alternative, TSIG may be used after, if necessary, setting up a key
   with TKEY [RFC 2930].

   Except where needed to authenticate an update, TKEY, or similar
   privileged request, servers are not required to check a request
   SIG(0).

   Note: requests and responses can either have a single TSIG or one
   SIG(0) but not both a TSIG and a SIG(0).

3.2 Processing Responses and SIG(0) RRs

   If a SIG RR is at the end of the additional information section of a
   response and has a type covered of zero, it is a transaction
   signature covering the response and the query that produced the
   response.  For TKEY responses, it MUST be checked and the message
   rejected if the checks fail unless otherwise specified for the TKEY
   mode in use.  For all other responses, it MAY be checked and the
   message rejected if the checks fail.

   If a response's SIG(0) check succeed, such a transaction
   authentication SIG does NOT directly authenticate the validity any
   data-RRs in the message.  However, it authenticates that they were
   sent by the queried server and have not been diddled.  (Only a proper
   SIG(0) RR signed by the zone or a key tracing its authority to the
   zone or to static resolver configuration can directly authenticate



Eastlake                    Standards Track                     [Page 6]

RFC 2931                       DNS SIG(0)                 September 2000


   data-RRs, depending on resolver policy.) If a resolver or server does
   not implement transaction and/or request SIGs, it MUST ignore them
   without error where they are optional and treat them as failing where
   they are required.

3.3 SIG(0) Lifetime and Expiration

   The inception and expiration times in SIG(0)s are for the purpose of
   resisting replay attacks.  They should be set to form a time bracket
   such that messages outside that bracket can be ignored.  In IP
   networks, this time bracket should not normally extend further than 5
   minutes into the past and 5 minutes into the future.

4. Security Considerations

   No additional considerations beyond those in [RFC 2535].

   The inclusion of the SIG(0) inception and expiration time under the
   signature improves resistance to replay attacks.

5. IANA Considerations

   No new parameters are created or parameter values assigned by this
   document.

References

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

   [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 2535] Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

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

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





Eastlake                    Standards Track                     [Page 7]

RFC 2931                       DNS SIG(0)                 September 2000


Author's Address

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

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







































Eastlake                    Standards Track                     [Page 8]

RFC 2931                       DNS SIG(0)                 September 2000


Appendix: SIG(0) Changes from RFC 2535

   Add explanatory text concerning the differences between TSIG and
   SIG(0).

   Change the data over which SIG(0) is calculated to include the SIG(0)
   RDATA other than the signature itself so as to secure the signature
   inception and expiration times and resist replay attacks.  Specify
   SIG(0) for TCP.

   Add discussion of appropriate inception and expiration times for
   SIG(0).

   Add wording to indicate that either a TSIG or one or more SIG(0)s may
   be present but not both.

   Reword some areas for clarity.


































Eastlake                    Standards Track                     [Page 9]

RFC 2931                       DNS SIG(0)                 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 10]