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

来自「非常好的dns解析软件」· 文本 代码 · 共 1,507 行 · 第 1/5 页

   sizes of the RRSIG and DNSKEY records and will therefore increase the
   chance of DNS UDP packet overflow.  Also the time it takes to
   validate and create RRSIGs increases with larger keys, so don't
   needlessly double your key sizes.






Kolkman & Gieben        Expires September 7, 2006              [Page 11]

Internet-Draft        DNSSEC Operational Practices            March 2006


3.6.  Private Key Storage

   It is recommended that, where possible, zone private keys and the
   zone file master copy that is to be signed, be kept and used in off-
   line, non-network connected, physically secure machines only.
   Periodically an application can be run to add authentication to a
   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
   transferred.

   When relying on dynamic update to manage a signed zone [10], be aware
   that at least one private key of the zone will have to reside on the
   master server.  This key is only as secure as the amount of exposure
   the server receives to unknown clients and the security of the host.
   Although not mandatory one could administer the DNS in the following
   way.  The master that processes the dynamic updates is unavailable
   from generic hosts on the Internet, it is not listed in the NS RR
   set, although its name appears in the SOA RRs MNAME field.  The
   nameservers in the NS RR set are able to receive zone updates through
   NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism.  This
   approach is known as the "hidden master" setup.

   The ideal situation is to have a one way information flow to the
   network to avoid the possibility of tampering from the network.
   Keeping the zone master file on-line on the network and simply
   cycling it through an off-line signer does not do this.  The on-line
   version could still be tampered with if the host it resides on is
   compromised.  For maximum security, the master copy of the zone file
   should be off net and should not be updated based on an unsecured
   network mediated communication.

   In general keeping a zone-file off-line will not be practical and the
   machines on which zone files are maintained will be connected to a
   network.  Operators are advised to take security measures to shield
   unauthorized access to the master copy.

   For dynamically updated secured zones [10] both the master copy and
   the private key that is used to update signatures on updated RRs will
   need to be on-line.


4.  Signature generation, Key Rollover and Related Policies

4.1.  Time in DNSSEC

   Without DNSSEC all times in DNS are relative.  The SOA fields
   REFRESH, RETRY and EXPIRATION are timers used to determine the time
   elapsed after a slave server synchronized with a master server.  The
   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]



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


   are used to determine how long a forwarder should cache data after it
   has been fetched from an authoritative server.  By using a signature
   validity period, DNSSEC introduces the notion of an absolute time in
   the DNS.  Signatures in DNSSEC have an expiration date after which
   the signature is marked as invalid and the signed data is to be
   considered Bogus.

4.1.1.  Time Considerations

   Because of the expiration of signatures, one should consider the
   following:
   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
      of your signature validity period.
         If the TTL would be of similar order as the signature validity
         period, then all RRSets fetched during the validity period
         would be cached until the signature expiration time.  Section
         7.1 of [4] suggests that "the resolver may use the time
         remaining before expiration of the signature validity period of
         a signed RRSet as an upper bound for the TTL".  As a result
         query load on authoritative servers would peak at signature
         expiration time, as this is also the time at which records
         simultaneously expire from caches.
         To avoid query load peaks we suggest the TTL on all the RRs in
         your zone to be at least a few times smaller than your
         signature validity period.
   o  We suggest the Signature Publication Period to end at least one
      Maximum Zone TTL duration before the end of the Signature Validity
      Period.
         Re-signing a zone shortly before the end of the signature
         validity period may cause simultaneous expiration of data from
         caches.  This in turn may lead to peaks in the load on
         authoritative servers.
   o  We suggest the minimum zone TTL to be long enough to both fetch
      and verify all the RRs in the trust chain.  In workshop
      environments it has been demonstrated [19] that a low TTL (under 5
      to 10 minutes) caused disruptions because of the following two
      problems:
         1.  During validation, some data may expire before the
         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 RRSet 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.





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


   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 server will respond differently to queries for that
         zone.  Some servers issue SERVFAIL while others turn off the
         'AA' bit in the answers.  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 then 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 shorter 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.
         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 times 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 secondaries expire the zone; 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



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


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

   Pre-publish Key Rollover involves four stages as follows:

    initial         new DNSKEY       new RRSIGs      DNSKEY removal

    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)




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


   initial: Initial version 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.
   new DNSKEY: 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.
   new RRSIGs: At the "new RRSIGs" 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.
   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
      only containing DNSKEY 1 and DNSKEY 11 is re-signed 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 "new DNSKEY"
   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
   (II)":





















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


       initial             new RRSIGs          new DNSKEY

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

       DNSKEY1             DNSKEY1             DNSKEY1
       DNSKEY10            DNSKEY10            DNSKEY11