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

bind 源码 最新实现 linux/unix/windows平台

   RFC2541 [7] by Donald Eastlake.

   Mike StJohns designed the key exchange between parent and child
   mentioned in the last paragraph of Section 4.2.2

   Section 4.2.4 was supplied by G. Guette and O. Courtay.

   Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
   the spelling and style issues.

   Kolkman and Gieben take the blame for introducing all miscakes(SIC).

7.  References





Kolkman & Gieben        Expires September 2, 2005              [Page 23]

Internet-Draft        DNSSEC Operational Practices            March 2005


7.1  Normative References

   [1]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
        RFC 3757, May 2004.

   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "DNS Security Introduction and Requirements", RFC 4033,
        March 2005.

7.2  Informative References

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

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

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

   [6]   Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
         RFC 2308, March 1998.

   [7]   Eastlake, D., "DNS Security Operational Considerations",
         RFC 2541, March 1999.

   [8]   Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
         RFC 3658, December 2003.

   [9]   Hollenbeck, S., "Domain Name System (DNS) Security Extensions
         Mapping for the Extensible  Provisioning Protocol (EPP)",
         draft-hollenbeck-epp-secdns-07 (work in progress), March 2005.

   [10]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
         Sizes", The Journal of Cryptology 14 (255-293), 2001.

   [11]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
         Source Code in C", 1996.












Kolkman & Gieben        Expires September 2, 2005              [Page 24]

Internet-Draft        DNSSEC Operational Practices            March 2005


Authors' Addresses

   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.

   Anchored Key: A DNSKEY configured in resolvers around the globe.
      This key is hard to update, hence the term anchored.
   Bogus: Also see Section 5 of [2].  An RRset in DNSSEC is marked
      "Bogus" when a signature of a RRset does not validate against a
      DNSKEY.
   Key-Signing Key or KSK: A Key-Signing Key (KSK) is a key that is used
      exclusively for signing the apex key set.  The fact that a key is
      a KSK is only relevant to the signing tool.
   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.
   Key Rollover: A key rollover (also called key supercession in some
      environments) is the act of replacing one key pair by another at
      the end of a key effectivity period.





Kolkman & Gieben        Expires September 2, 2005              [Page 25]

Internet-Draft        DNSSEC Operational Practices            March 2005


   Secure Entry Point key or 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.
   Singing the Zone File: The term used for the event where an
      administrator joyfully signs its zone file while producing melodic
      sound patterns.
   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.
   Zone-Signing Key or 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.
   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 caches here
   follows the "HOWTO".
   Step 0: The preparation: Create two keys and publish both in your key
      set.  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.
      The protocol does not provide for attributes to mark a key as
      active or published.  This is something you have to do on your
      own, through the use of a notebook or key management tool.
   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.







Kolkman & Gieben        Expires September 2, 2005              [Page 26]

Internet-Draft        DNSSEC Operational Practices            March 2005


   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".
   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:





































Kolkman & Gieben        Expires September 2, 2005              [Page 27]

Internet-Draft        DNSSEC Operational Practices            March 2005


   example.net.     600     IN SOA  ns.example.net. bert.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     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.
                                     bZMjoZ3bHjnEz0nIsPMM... )

                     ...


   is reduced to the following representation:








Kolkman & Gieben        Expires September 2, 2005              [Page 28]

Internet-Draft        DNSSEC Operational Practices            March 2005


       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 c