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

bind 9.3结合mysql数据库

   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
      into the keyset and all the data in the zone is signed with DNSKEY
      10 and DNSKEY 11. The rollover period will need to exist until all
      data from version 0 of the zone has expired from remote caches.
      This will take at least the maximum Zone TTL of version 0 of the
      zone.
   after: DNSKEY 10 is removed from the zone. All the signatures from
      DNSKEY 10 are removed from the zone. The keyset, now only
      containing DNSKEY 11, is resigned with DNSKEY 1.

   At every instance the data from the previous version of the zone can
   be verified with the key from the current version and vice verse. The
   data from the current version can be verified with the data from the
   previous version of the zone. The duration of the rollover phase and
   the period between rollovers should be at least the "Maximum Zone
   TTL".

   Making sure that the rollover phase lasts until the signature
   expiration time of the data in version 0 of the zone is recommended.
   However, this date could be considerably longer than the Maximum Zone
   TTL, making the rollover a lengthy procedure.

   Note that in this example we assumed that the zone was not modified
   during the rollover. New data can be introduced in the zone as long
   as it is signed with both keys.

3.3.1.3  Pros and Cons of the Schemes

   Prepublish-keyset rollover: This rollover does not involve signing
      the zone data twice. Instead, just before the actual rollover, the
      new key is published in the keyset and thus available for
      cryptanalysis attacks. A small disavantage is that this process
      requires four steps. Also the prepublish scheme will not work for
      KSKs as explained in Section 3.3.
   Double signature rollover: The drawback of this signing scheme is
      that during the rollover the number of signatures in your zone
      doubles, this may be prohibitive if you have very big zones.  An
      advantage is that it only requires three steps.

3.3.2  Key-signing Key Rollovers

   For the rollover of a key-signing key the same considerations as for
   the rollover of a zone-signing key apply. However we can use a double
   signature scheme to guarantee that old data (only the apex keyset) in
   caches can be verified with a new keyset and vice versa.

   Since only the keyset is signed with a KSK, zone size considerations
   do not apply.



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


       normal          roll            after

       SOA0            SOA1            SOA2
       RRSIG10(SOA0)   RRSIG10(SOA1)   RRSIG10(SOA2)

       DNSKEY1         DNSKEY1         DNSKEY2
                       DNSKEY2
       DNSKEY10        DNSKEY10        DNSKEY10
       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
                       RRSIG2 (DNSKEY)
       RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)

   normal: Version 0 of the zone.  The parental DS points to DNSKEY1.
      Before the rollover starts the child will have to verify what the
      TTL is of the DS RR that points to DNSKEY1 - it is needed during
      the rollover and we refer to the value as TTL_DS.
   roll: During the rollover phase the zone administrator generates a
      second KSK, DNSKEY2. The key is provided to the parent and the
      child will have to wait until a new DS RR has been generated that
      points to DNSKEY2. After that DS RR has been published on _all_
      servers authoritative for the parents zone, the zone administrator
      has to wait at least TTL_DS to make sure that the old DS RR has
      expired from distant caches.
   after: DNSKEY1 has been removed.

   The scenario above puts the responsibility for maintaining a valid
   chain of trust with the child. It also is based on the premises that
   the parent only has one DS RR (per algorithm) per zone. St John [The
   draft has expired] proposed a mechanism where using an established
   trust relation, the interaction can be performed in-band. In this
   mechanism there are periods where there are two DS RRs at the parent.

   [Editors note: We probably need to mention more]

4.  Planning for Emergency Key Rollover

   This section deals with preparation for a possible key compromise.
   Our advice is to have a documented procedure ready for when a key
   compromise is suspected or confirmed.

   [Editors note: We are much in favor of a rollover tactic that keeps
   the authentication chain intact as long as possible. This means that
   one has to take all the regular rollover properties into account.]

   When the private material of one of your keys is compromised it can
   be used for as long as a valid authentication chain exists.  An
   authentication chain remains intact for:




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


   o  as long as a signature over the compromised key in the
      authentication chain is valid,
   o  as long as a parental DS RR (and signature) points to the
      compromised key,
   o  as long as the key is anchored in a resolver and is used as a
      starting point for validation. (This is the hardest to update.)
   While an authentication chain to your compromised key exists, your
   name-space is vulnerable to abuse by the malicious key holder (i.e.
   the owner of the compromised key). Zone operators have to make a
   trade off if the abuse of the compromised key is worse than having
   data in caches that cannot be validated. If the zone operator chooses
   to break the authentication chain to the compromised key, data in
   caches signed with this key cannot be validated. However, if the zone
   administrator chooses to take the path of a regular roll-over, the
   malicious key holder can spoof data so that it appears to be valid,
   note that this kind of attack will usually be localised in the
   Internet topology.


4.1  KSK Compromise

   When the KSK has been compromised the parent must be notified as soon
   as possible using secure means. The keyset of the zone should be
   resigned as soon as possible. Care must be taken to not break the
   authentication chain. The local zone can only be resigned with the
   new KSK after the parent's zone has been updated with the new KSK.
   Before this update takes place it would be best to drop the security
   status of a zone all together: the parent removes the DS of the child
   at the next zone update.  After that the child can be made secure
   again.

   An additional danger of a key compromise is that the compromised key
   can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
   rollover at the parent. When that happens the domain can be in
   dispute. An out of band and secure notify mechanism to contact a
   parent is needed in this case.

4.2  ZSK Compromise

   Primarily because there is no parental interaction required when a
   ZSK is compromised, the situation is less severe than with with a KSK
   compromise.  The zone must still be resigned with a new ZSK as soon
   as possible. As this is a local operation and requires no
   communication between the parent and child this can be achieved
   fairly quickly. However, one has to take into account that just as
   with a normal rollover the immediate disappearance from the old
   compromised key may lead to verification problems. The
   pre-publication scheme as discussed above minimises such problems.



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


4.3  Compromises of Keys Anchored in Resolvers

   A key can also be pre-configured in resolvers. If DNSSEC is rolled
   out as planned the root key should be pre-configured in every secure
   aware resolver on the planet. [Editors Note: add more about
   authentication of a newly received  resolver key]

   If trust-anchor keys are compromised, the resolvers using these keys
   should be notified of this fact. Zone administrators may consider
   setting up a mailing list to communicate the fact that a SEP key is
   about to be rolled over. This communication will of course need to be
   authenticated e.g. by using digital signatures.

5.  Parental Policies

5.1  Initial Key Exchanges and Parental Policies Considerations

   The initial key exchange is always subject to the policies set by the
   parent (or its registry). When designing a key exchange policy one
   should take into account that the authentication and authorisation
   mechanisms used during a key exchange should be as strong as the
   authentication and authorisation mechanisms used for the exchange of
   delegation information between parent and child.

   Using the DNS itself as the source for the actual DNSKEY material,
   with an off-band check on the validity of the DNSKEY, has the benefit
   that it reduces the chances of user error. A parental DNSKEY download
   tool can make use of the SEP bit [4] to select the proper key from a
   DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is
   sent. It can validate the self-signature over a key; thereby
   verifying the ownership of the private key material. Fetching the
   DNSKEY from the DNS ensures that the child will not become bogus once
   the parent publishes the DS RR indicating the child is secure.

   Note: the off-band verification is still needed when the key-material
   is fetched by a tool. The parent can not be sure whether the DNSKEY
   RRs have been spoofed.

5.2  Storing Keys So Hashes Can Be Regenerated

   When designing a registry system one should consider if the DNSKEYs
   and/or the corresponding DSs are stored. Storing DNSKEYs will help
   during troubleshooting while the overhead of calculating DS records
   from them is minimal.

   Having an out-of-band mechanism, such as a Whois database, to find
   out which keys are used to generate DS Resource Records for specific
   owners may also help with troubleshooting.



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


5.3  Security Lameness Checks

   Security Lameness is defined as what happens when a parent has a DS
   Resource Record pointing to a non-existing DNSKEY RR. During key
   exchange a parent should make sure that the child's key is actually
   configured in the DNS before publishing a DS RR in its zone. Failure
   to do so would render the child's zone being marked as bogus.

   Child zones should be very careful removing DNSKEY material,
   specifically SEP keys, for which a DS RR exists.

   Once a zone is "security lame" a fix (e.g. by removing a DS RR) will
   take time to propagate through the DNS.

5.4  DS Signature Validity Period

   Since the DS can be replayed as long as it has a valid signature a
   short signature validity period over the DS minimises the time a
   child is vulnerable in the case of a compromise of the child's
   KSK(s).  A signature validity period that is too short introduces the
   possibility that a zone is marked bogus in case of a configuration
   error in the signer; there may not be enough time to fix the problems
   before signatures expire.  Something as mundane as operator
   unavailability during weekends shows the need for DS signature
   lifetimes longer than 2 days. We recommend the minimum for a DS
   signature validity period to be a few days.

   The maximum signature lifetime of the DS record depends on how long
   child zones are willing to be vulnerable after a key compromise. We
   consider a signature validity period of around one week to be a good
   compromise between the operational constraints of the parent and
   minimising damage for the child.

6.  Security Considerations

   DNSSEC adds data integrity to the DNS. This document tries to assess
   considerations to operate a stable and secure DNSSEC service. Not
   taking into account the 'data propagation' properties in the DNS will
   cause validation failures and may make secured zones unavailable to
   security aware resolvers.

7.  Acknowledgments

   We, the folk mentioned as authors, only acted as editors. Most of the
   ideas in this draft were the result of collective efforts during
   workshops, discussions and try outs.

   At the risk of forgetting individuals who where the original



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


   contributors of the ideas we would like to acknowledge people who
   where actively involved in the compilation of this document. In
   random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,
   Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier
   Courtay, Sam Weiler.

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

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

8.  References

8.1  Normative References

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

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

   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
        Status", RFC 3090, March 2001.

   [4]  Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
        (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
        in progress), February 2003.

8.2  Informative References

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

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

   [7]  Gudmundsson, O., "Delegation Signer Resource Record",
        draft-ietf-dnsext-delegation-signer-13 (work in progress), March
        2003.

   [8]  Arends, R., "Protocol Modifications for the DNS Security
        Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in
        progress), March 2003.

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





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


Authors' Addresses