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

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

         validation is complete.  The validator should be able to keep
         all data, until is completed.  This applies to all RRs needed
         to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
         final answers i.e. the RR set that is returned for the initial
         query.
         2.  Frequent verification causes load on recursive nameservers.
         Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
         caching.  The TTL on those should be relatively long.
   o  Slave servers will need to be able to fetch newly signed zones
      well before the RRSIGs in the zone served by the slave server pass
      their signature expiration time.
         When a slave server is out of sync with its master and data in
         a zone is signed by expired signatures it may be better for the
         slave server not to give out any answer.
         Normally a slave server that is not able to contact a master
         server for an extended period will expire a zone.  When that
         happens the zone will not respond on queries.  The time of
         expiration is set in the SOA record and is relative to the last
         successful refresh between the master and the slave server.
         There exists no coupling between the signature expiration of
         RRSIGs in the zone and the expire parameter in the SOA.
         If the server serves a DNSSEC zone than it may well happen that
         the signatures expire well before the SOA expiration timer
         counts down to zero.  It is not possible to completely prevent
         this from happening by tweaking the SOA parameters.
         However, the effects can be minimized where the SOA expiration
         time is equal or smaller than the signature validity period.
         The consequence of an authoritative server not being able to
         update a zone, whilst that zone includes expired signatures, is
         that non-secure resolvers will continue to be able to resolve
         data served by the particular slave servers while security
         aware resolvers will experience problems because of answers
         being marked as Bogus.



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


         We suggest the SOA expiration timer being approximately one
         third or one fourth of the signature validity period.  It will
         allow problems with transfers from the master server to be
         noticed before the actual signature time out.
         We also suggest that operators of nameservers that supply
         secondary services develop 'watch dogs' to spot upcoming
         signature expirations in zones they slave, and take appropriate
         action.
         When determining the value for the expiration parameter one has
         to take the following into account: What are the chances that
         all my secondary zones expire; How quickly can I reach an
         administrator of secondary servers to load a valid zone?  All
         these arguments are not DNSSEC specific but may influence the
         choice of your signature validity intervals.

4.2  Key Rollovers

   A DNSSEC key cannot be used forever (see Section 3.3).  So key
   rollovers -- or supercessions, as they are sometimes called -- are a
   fact of life when using DNSSEC.  Zone administrators who are in the
   process of rolling their keys have to take into account that data
   published in previous versions of their zone still lives in caches.
   When deploying DNSSEC, this becomes an important consideration;
   ignoring data that may be in caches may lead to loss of service for
   clients.

   The most pressing example of this is when zone material signed with
   an old key is being validated by a resolver which does not have the
   old zone key cached.  If the old key is no longer present in the
   current zone, this validation fails, marking the data Bogus.
   Alternatively, an attempt could be made to validate data which is
   signed with a new key against an old key that lives in a local cache,
   also resulting in data being marked Bogus.

4.2.1  Zone-signing Key Rollovers

   For zone-signing key rollovers there are two ways to make sure that
   during the rollover data still cached can be verified with the new
   key sets or newly generated signatures can be verified with the keys
   still in caches.  One schema, described in Section 4.2.1.2, uses
   double signatures; the other uses key pre-publication
   (Section 4.2.1.1).  The pros, cons and recommendations are described
   in Section 4.2.1.3.

4.2.1.1  Pre-publish key set Rollover

   This section shows how to perform a ZSK rollover without the need to
   sign all the data in a zone twice - the so-called "pre-publish



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


   rollover".This method has advantages in the case of a key compromise.
   If the old key is compromised, the new key has already been
   distributed in the DNS.  The zone administrator is then able to
   quickly switch to the new key and remove the compromised key from the
   zone.  Another major advantage is that the zone size does not double,
   as is the case with the double signature ZSK rollover.  A small
   "HOWTO" for this kind of rollover can be found in Appendix B.

    normal          pre-roll         roll            after

    SOA0            SOA1             SOA2            SOA3
    RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)

    DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
    DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
                    DNSKEY11         DNSKEY11
    RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
    RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)


   normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
      DNSKEY 10 is used to sign all the data of the zone, the zone-
      signing key.
   pre-roll: DNSKEY 11 is introduced into the key set.  Note that no
      signatures are generated with this key yet, but this does not
      secure against brute force attacks on the public key.  The minimum
      duration of this pre-roll phase is the time it takes for the data
      to propagate to the authoritative servers plus TTL value of the
      key set.  This equates to two times the Maximum Zone TTL.
   roll: At the rollover stage (SOA serial 2) DNSKEY 11 is used to sign
      the data in the zone exclusively  (i.e. all the signatures from
      DNSKEY 10 are removed from the zone).  DNSKEY 10 remains published
      in the key set.  This way data that was loaded into caches from
      version 1 of the zone can still be verified with key sets fetched
      from version 2 of the zone.
      The minimum time that the key set including DNSKEY 10 is to be
      published is the time that it takes for zone data from the
      previous version of the zone to expire from old caches i.e. the
      time it takes for this zone to propagate to all authoritative
      servers plus the Maximum Zone TTL value of any of the data in the
      previous version of the zone.
   after: DNSKEY 10 is removed from the zone.  The key set, now only
      containing DNSKEY 1 and DNSKEY 11 is resigned with the DNSKEY 1.

   The above scheme can be simplified by always publishing the "future"
   key immediately after the rollover.  The scheme would look as follows
   (we show two rollovers); the future key is introduced in "after" as
   DNSKEY 12 and again a newer one, numbered 13, in "2nd after":



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


       normal              roll                after

       SOA0                SOA2                SOA3
       RRSIG10(SOA0)       RRSIG11(SOA2)       RRSIG11(SOA3)

       DNSKEY1             DNSKEY1             DNSKEY1
       DNSKEY10            DNSKEY10            DNSKEY11
       DNSKEY11            DNSKEY11            DNSKEY12
       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)


       2nd roll            2nd after

       SOA4                SOA5
       RRSIG12(SOA4)       RRSIG12(SOA5)

       DNSKEY1             DNSKEY1
       DNSKEY11            DNSKEY12
       DNSKEY12            DNSKEY13
       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)


   Note that the key introduced after the rollover is not used for
   production yet; the private key can thus be stored in a physically
   secure manner and does not need to be 'fetched' every time a zone
   needs to be signed.

4.2.1.2  Double Signature Zone-signing Key Rollover

   This section shows how to perform a ZSK key rollover using the double
   zone data signature scheme, aptly named "double sig rollover".

   During the rollover stage the new version of the zone file will need
   to propagate to all authoritative servers and the data that exists in
   (distant) caches will need to expire, requiring at least the maximum
   Zone TTL.













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


       normal              roll               after

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

       DNSKEY1             DNSKEY1            DNSKEY1
       DNSKEY10            DNSKEY10           DNSKEY11
                           DNSKEY11
       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
                           RRSIG11(DNSKEY)

   normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
      DNSKEY 10 is used to sign all the data of the zone, the zone-
      signing key.
   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
      into the key set 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 key set, now only
      containing DNSKEY 11, is resigned with DNSKEY 1.

   At every instance, RRSIGs from the previous version of the zone can
   be verified with the DNSKEY RRset from the current version and the
   other way around.  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.
   This way all caches are cleared of the old signatures.  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.

4.2.1.3  Pros and Cons of the Schemes







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


   Pre-publish-key set rollover: This rollover does not involve signing
      the zone data twice.  Instead, before the actual rollover, the new
      key is published in the key set and thus available for
      cryptanalysis attacks.  A small disadvantage is that this process
      requires four steps.  Also the pre-publish scheme involves more
      parental work when used for KSK rollovers as explained in
      Section 4.2.
   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.

4.2.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 key
   set) in caches can be verified with a new key set and vice versa.

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


       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 parent's zone, the zone
      administrator has to wait at least TTL_DS to make sure that the
      old DS RR has expired from caches.





Kolkman & Gieben        Expires September 2, 2005              [Page 17]