draft-ietf-dnsop-dnssec-operational-practices-01.txt

bind 9.3结合mysql数据库

   Olaf M. Kolkman
   RIPE NCC
   Singel 256
   Amsterdam  1016 AB
   The Netherlands

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.ripe.net/


   Miek Gieben
   NLnet Labs
   Kruislaan 419
   Amsterdam  1098 VA
   The Netherlands

   EMail: [e-mail]
   URI:   http://www.nlnetlabs.nl

Appendix A.  Terminology

   In this document there is some jargon used that is defined in other
   documents. In most cases we have not copied the text from the
   documents defining the terms but given a more elaborate explanation
   of the meaning. Note that these explanations should not be seen as
   authoritative.

   Private and Public Keys: DNSSEC secures the DNS through the use of
      public key cryptography. Public key cryptography is based on the
      existence of two keys, a public key and a private key. The public
      keys are published in the DNS by use of the DNSKEY Resource Record
      (DNSKEY RR). Private keys should remain private i.e. should not be
      exposed to parties not-authorised to do the actual signing.
   Signer: The system that has access to the private key material and
      signs the Resource Record sets in a zone. A signer may be
      configured to sign only parts of the zone e.g. only those RRsets
      for which existing signatures are about to expire.
   KSK: A Key-Signing Key (KSK) is a key that is used exclusively for
      signing the apex keyset.  The fact that a key is a KSK is only
      relevant to the signing tool.
   ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all
      data in a zone.  The fact that a key is a ZSK is only relevant to
      the signing tool.





Kolkman & Gieben        Expires August 30, 2004                [Page 19]

Internet-Draft        DNSSEC Operational Practices            March 2004


   SEP Key: A KSK that has a parental DS record pointing to it. Note:
      this is not enforced in the protocol. A SEP Key with no parental
      DS is security lame.
   Anchored Key: A DNSKEY configured in resolvers around the globe. This
      Key is hard to update, hence the term anchored.
   Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked
      "Bogus" when a signature of a RRset does not validate against the
      DNSKEY. Even if the key itself was not marked Bogus. A cache may
      choose to cache Bogus data for various reasons.
   Singing the Zone File: The term used for the event where an
      administrator joyfully signs its zone file while producing melodic
      sound patterns.
   Zone Administrator: The 'role' that is responsible for signing a zone
      and publishing it on the primary authoritative server.

Appendix B.  Zone-signing Key Rollover Howto

   Using the pre-published signature scheme and the most conservative
   method to assure oneself that data does not live in distant caches
   here follows the "HOWTO". [WES: has some comments about this]
   Key notation:
   Step 0: The preparation: Create two keys and publish both in your
      keyset.  Mark one of the keys as "active" and the other as
      "published". Use the "active" key for signing your zone data.
      Store the private part of the "published" key, preferably
      off-line.
   Step 1: Determine expiration: At the beginning of the rollover make a
      note of the highest expiration time of signatures in your zone
      file created with the current key marked as "active".
      Wait until the expiration time marked in Step 1 has passed
   Step 2: Then start using the key that was marked as "published" to
      sign your data i.e. mark it as "active". Stop using the key that
      was marked as "active", mark it as "rolled".
   Step 3: It is safe to engage in a new rollover (Step 1) after at
      least one "signature validity period".

Appendix C.  Typographic Conventions

   The following typographic conventions are used in this document:
   Key notation: A key is denoted by KEYx, where x is a number, x could
      be thought of as the key id.
   RRset notations: RRs are only denoted by the type. All other
      information - owner, class, rdata and TTL - is left out. Thus:
      example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a
      list of RRs. A example of this would be: A1,A2, specifying the
      RRset containing two A records. This could again be abbreviated to
      just: A.




Kolkman & Gieben        Expires August 30, 2004                [Page 20]

Internet-Draft        DNSSEC Operational Practices            March 2004


   Signature notation: Signatures are denoted as RRSIGx(RRset), which
      means that RRset is signed with DNSKEYx.
   Zone representation: Using the above notation we have simplified the
      representation of a signed zone by leaving out all unnecessary
      details such as the names and by  representing all data by "SOAx"
   SOA representation: SOA's are represented as SOAx, where x is the
      serial number.
   Using this notation the following zone :


   example.net.      600     IN SOA  ns.example.net. ernie.example.net. (
                                     10         ; serial
                                     450        ; refresh (7 minutes 30 seconds)
                                     600        ; retry (10 minutes)
                                     345600     ; expire (4 days)
                                     300        ; minimum (5 minutes)
                                     )
                     600     RRSIG   SOA 5 2 600 20130522213204 (
                                     20130422213204 14 example.net.
                                     cmL62SI6iAX46xGNQAdQ... )
                     600     NS      a.iana-servers.net.
                     600     NS      b.iana-servers.net.
                     600     RRSIG   NS 5 2 600 20130507213204 (
                                     20130407213204 14 example.net.
                                     SO5epiJei19AjXoUpFnQ ... )
                     3600    DNSKEY  256 3 5 (
                                     EtRB9MP5/AvOuVO0I8XDxy0...
                                     ) ; key id = 14
                     3600    DNSKEY  256 3 5 (
                                     gsPW/Yy19GzYIY+Gnr8HABU...
                                     ) ; key id = 15
                     3600    RRSIG   DNSKEY 5 2 3600 20130522213204 (
                                     20130422213204 14 example.net.
                                     J4zCe8QX4tXVGjV4e1r9... )
                     3600    RRSIG   DNSKEY 5 2 3600 20130522213204 (
                                     20130422213204 15 example.net.
                                     keVDCOpsSeDReyV6O... )
                     600     NSEC    a.example.net. NS SOA TXT RRSIG DNSKEY NSEC
                     600     RRSIG   NSEC 5 2 600 20130507213204 (
                                     20130407213204 14 example.net.
                                     obj3HEp1GjnmhRjX... )
   a.example.net.    600     IN TXT  "A label"
                     600     RRSIG   TXT 5 3 600 20130507213204 (
                                     20130407213204 14 example.net.
                                     IkDMlRdYLmXH7QJnuF3v... )
                     600     NSEC    b.example.com. TXT RRSIG NSEC
                     600     RRSIG   NSEC 5 3 600 20130507213204 (
                                     20130407213204 14 example.net.



Kolkman & Gieben        Expires August 30, 2004                [Page 21]

Internet-Draft        DNSSEC Operational Practices            March 2004


                                     bZMjoZ3bHjnEz0nIsPMM... )

                     ...


    is reduced to the following represenation:

       SOA10
       RRSIG14(SOA10)

       DNSKEY14
       DNSKEY15

       RRSIG14(KEY)
       RRSIG15(KEY)

    The rest of the zone data has the same signature as the SOA record,
   i.e a RRSIG created with DNSKEY 14.

Appendix D.  Document Details and Changes

   This section is to be removed by the RFC editor if and when the
   document is published.

   $Header: /var/cvs/dnssec-key/
   draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12
   08:29:11 dnssec Exp $

D.1  draft-ietf-dnsop-dnssec-operational-practices-00

   Submission as working group document. This document is a modified and
   updated version of draft-kolkman-dnssec-operational-practices-00.

D.2  draft-ietf-dnsop-dnssec-operational-practices-01

   changed the definition of "Bogus" to reflect the one in the protocol
   draft.

   Bad to Bogus

   Style and spelling corrections

   KSK - SEP mapping made explicit.

   Updates from Sam Weiler added






Kolkman & Gieben        Expires August 30, 2004                [Page 22]

Internet-Draft        DNSSEC Operational Practices            March 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

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

   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



Kolkman & Gieben        Expires August 30, 2004                [Page 23]

Internet-Draft        DNSSEC Operational Practices            March 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Kolkman & Gieben        Expires August 30, 2004                [Page 24]