rfc3007.txt

bind 9.3结合mysql数据库

   NXT records MUST NOT be created, modified, or deleted by dynamic
   update, as their update may cause instability in the protocol.  This
   is an update to RFC 2136.

   Issues concerning updates of KEY records are discussed in the
   Security Considerations section.

3.2 - Additional policies

   Users are free to implement any policies.  Policies may be as
   specific or general as desired, and as complex as desired.  They may
   depend on the principal or any other characteristics of the signed
   message.

4 - Interaction with DNSSEC

   Although this protocol does not change the way updates to secure
   zones are processed, there are a number of issues that should be
   clarified.








Wellington                  Standards Track                     [Page 5]

RFC 3007                 Secure Dynamic Update             November 2000


4.1 - Adding SIGs

   An authorized update request MAY include SIG records with each RRset.
   Since SIG records (except SIG(0) records) MUST NOT be used for
   authentication of the update message, they are not required.

   If a principal is authorized to update SIG records and there are SIG
   records in the update, the SIG records are added without
   verification.  The server MAY examine SIG records and drop SIGs with
   a temporal validity period in the past.

4.2 - Deleting SIGs

   If a principal is authorized to update SIG records and the update
   specifies the deletion of SIG records, the server MAY choose to
   override the authority and refuse the update.  For example, the
   server may allow all SIG records not generated by a zone key to be
   deleted.

4.3 - Non-explicit updates to SIGs

   If the updated zone is secured, the RRset affected by an update
   operation MUST, at the completion of the update, be signed in
   accordance with the zone's signing policy.  This will usually require
   one or more SIG records to be generated by one or more zone keys
   whose private components MUST be online [RFC3008].

   When the contents of an RRset are updated, the server MAY delete all
   associated SIG records, since they will no longer be valid.

4.4 - Effects on the zone

   If any changes are made, the server MUST, if necessary, generate a
   new SOA record and new NXT records, and sign these with the
   appropriate zone keys.  Changes to NXT records by secure dynamic
   update are explicitly forbidden.  SOA updates are allowed, since the
   maintenance of SOA parameters is outside of the scope of the DNS
   protocol.

5 - Security Considerations

   This document requires that a zone key and possibly other
   cryptographic secret material be held in an on-line, network-
   connected host, most likely a name server.  This material is at the
   mercy of host security to remain a secret.  Exposing this secret puts
   DNS data at risk of masquerade attacks.  The data at risk is that in
   both zones served by the machine and delegated from this machine.




Wellington                  Standards Track                     [Page 6]

RFC 3007                 Secure Dynamic Update             November 2000


   Allowing updates of KEY records may lead to undesirable results,
   since a principal may be allowed to insert a public key without
   holding the private key, and possibly masquerade as the key owner.

6 - Acknowledgements

   The author would like to thank the following people for review and
   informative comments (in alphabetical order):

   Harald Alvestrand
   Donald Eastlake
   Olafur Gudmundsson
   Andreas Gustafsson
   Bob Halley
   Stuart Kwan
   Ed Lewis

7 - 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 1035, November 1987.

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

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

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

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

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

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

   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
              Signing Authority", RFC 3008, November 2000.




Wellington                  Standards Track                     [Page 7]

RFC 3007                 Secure Dynamic Update             November 2000


8 - Author's Address

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

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










































Wellington                  Standards Track                     [Page 8]

RFC 3007                 Secure Dynamic Update             November 2000


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



















Wellington                  Standards Track                     [Page 9]