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

bind 9.3结合mysql数据库

DNSOP                                                         O. Kolkman
Internet-Draft                                                  RIPE NCC
Expires: August 30, 2004                                       R. Gieben
                                                              NLnet Labs
                                                              March 2004


                      DNSSEC Operational Practices
         draft-ietf-dnsop-dnssec-operational-practices-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 30, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document describes a set of practices for operating a DNSSEC
   aware environment.  The target audience is zone administrators
   deploying DNSSEC that need a guide to help them chose appropriate
   values for DNSSEC parameters.  It also discusses operational matters
   such as key rollovers, KSK and ZSK considerations and related
   matters.








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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   The Use of the Term 'key'  . . . . . . . . . . . . . . . .  3
     1.2   Keeping the Chain of Trust Intact  . . . . . . . . . . . .  3
   2.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Time Definitions . . . . . . . . . . . . . . . . . . . . .  4
     2.2   Time Considerations  . . . . . . . . . . . . . . . . . . .  5
   3.  Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Motivations for the KSK and ZSK Functions  . . . . . . . .  7
     3.2   Key Security Considerations  . . . . . . . . . . . . . . .  8
       3.2.1   Key Validity Period  . . . . . . . . . . . . . . . . .  8
       3.2.2   Key Algorithm  . . . . . . . . . . . . . . . . . . . .  8
       3.2.3   Key Sizes  . . . . . . . . . . . . . . . . . . . . . .  8
     3.3   Key Rollovers  . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.1   Zone-signing Key Rollovers . . . . . . . . . . . . . . 10
       3.3.2   Key-signing Key Rollovers  . . . . . . . . . . . . . . 13
   4.  Planning for Emergency Key Rollover  . . . . . . . . . . . . . 14
     4.1   KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
     4.2   ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
     4.3   Compromises of Keys Anchored in Resolvers  . . . . . . . . 16
   5.  Parental Policies  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1   Initial Key Exchanges and Parental Policies
           Considerations . . . . . . . . . . . . . . . . . . . . . . 16
     5.2   Storing Keys So Hashes Can Be Regenerated  . . . . . . . . 16
     5.3   Security Lameness Checks . . . . . . . . . . . . . . . . . 17
     5.4   DS Signature Validity Period . . . . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 18
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 18
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
   A.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 19
   B.  Zone-signing Key Rollover Howto  . . . . . . . . . . . . . . . 20
   C.  Typographic Conventions  . . . . . . . . . . . . . . . . . . . 20
   D.  Document Details and Changes . . . . . . . . . . . . . . . . . 22
     D.1   draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22
     D.2   draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22
       Intellectual Property and Copyright Statements . . . . . . . . 23











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


1.  Introduction

   During workshops and early operational deployment tests, operators
   and system administrators gained experience about operating DNSSEC
   aware DNS services.  This document translates these experiences into
   a set of practices for zone administrators. At the time of writing,
   there exists very little experience with DNSSEC in production
   environments, this document should therefore explicitly not be seen
   as represented 'Best Current Practices'.

   The procedures herein are focused on the maintenance of signed zones
   (i.e. signing and publishing zones on authoritative servers). It is
   intended that maintenance of zones such as resigning or key rollovers
   be transparent to any verifying clients on the Internet.

   The structure of this document is as follows: It begins with
   discussing some of the considerations with respect to timing
   parameters of DNS in relation to DNSSEC (Section 2). Aspects of key
   management such as key rollover schemes are described in Section 3.
   Emergency rollover considerations are addressed in Section 4.  The
   typographic conventions used in this document are explained in
   Appendix C.

   Since this is a document with operational suggestions and there are
   no protocol specifications, the RFC2119 [5] language does not apply.

1.1  The Use of the Term 'key'

   It is assumed that the reader is familiar with the concept of
   asymmetric keys on which DNSSEC is based (Public Key Cryptography
   [Ref to Schneider?]). Therefore, this document will use the term
   'key' rather loosely. Where it is written that 'a key is used to sign
   data' it is assumed that the reader understands that it is the
   private part of the key-pair that is used for signing. It is also
   assumed that the reader understands that the public part of the
   key-pair is published in the DNSKEY resource record and that it is
   used in key-exchanges.

1.2  Keeping the Chain of Trust Intact

   Maintaining a valid chain of trust is important because broken chains
   of trust will result in data being marked as bogus, which may cause
   entire (sub)domains to become invisible to verifying clients. The
   administrators of secured zones have to realise that their zone is,
   to their clients, part of a chain of trust.

   As mentioned in the introduction, the procedures herein are intended
   to ensure maintenance of zones, such as resigning or key rollovers,



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


   be transparent to the verifying clients on the Internet.
   Administrators of secured zones will have to keep in mind that data
   published on an authoritative primary server will not be immediately
   seen by verifying clients; it may take some time for the data to be
   transfered to other secondary authoritative nameservers, during which
   period clients may be fetching data from caching non-authoritative
   servers.  For the verifying clients it is important that  data from
   secured zones can be used to build chains of trust regardless of
   whether the  data came directly from an authoritative server, a
   caching nameserver or some middle box. Only by carefully using the
   available timing parameters can a zone administrator  assure that the
   data necessary for verification can be obtained.

   The responsibility for maintaining the chain of trust is shared by
   administrators of secured zones in the chain of trust. This is most
   obvious in the case of a 'key compromise' when a trade off between
   maintaining a valid chain of trust and the fact that the key has been
   stolen, must be made.

   The zone administrator will have to make a tradeoff between keeping
   the chain of trust intact  -thereby allowing for attacks with the
   compromised key- or to deliberately break the chain of trust thereby
   making secured subdomains invisible to security aware resolvers. Also
   see Section 4.

2.  Time in DNSSEC

   Without DNSSEC all times in DNS are relative. The SOA's refresh,
   retry and expiration timers are counters that are used to determine
   the time elapsed after a slave server syncronised (or tried to
   syncronise) with a master server. The Time to Live (TTL) value and
   the SOA minimum TTL parameter [6] are used to determine how long a
   forwarder should cache data after it has been fetched from an
   authoritative server. 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.

2.1  Time Definitions

   In this document we will be using a number of time related terms.
   Within the context of this document the following definitions apply:
   o  "Signature validity period"
         The period that a signature is valid. It starts at the time
         specified in the signature inception field of the RRSIG RR and
         ends at the time specified in the expiration field of the RRSIG
         RR.




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


   o  "Signature publication period"
         Time after which a signature (made with a specific key) is
         replaced with a new signature (made with the same key). This
         replacement takes place by publishing the relevant RRSIG in the
         master zone file.  If a signature is published at time T0 and a
         new signature is published at time T1, the signature
         publication period is T1 - T0.
         If all signatures are refreshed at zone (re)signing then the
         signature publication period is equal signature validity
         period.
   o  "Maximum/Minimum Zone TTL"
         The maximum or minimum value of all the TTLs in a zone.

2.2  Time Considerations

   Because of the expiration of signatures, one should consider the
   following.
   o  The Maximum Zone TTL of your zone data should 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.  As a
         result query load on authoritative servers would peak at
         signature expiration time.
         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  The signature publication period should be at least one maximum
      TTL smaller than the signature validity period.
         Resigning 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  The Minimum zone TTL should be long enough to both fetch and
      verify all the RRs in the authentication chain.
            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 RR 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 August 30, 2004                 [Page 5]

Internet-Draft        DNSSEC Operational Practices            March 2004


         We have seen events where data needed for verification of an
         authentication chain had expired from caches.
         We suggest the TTL on DNSKEY and DSs to be between ten minutes
         and one hour.  We recommend zone administrators to chose TTLs
         longer than half a minute.
         [Editor's Note: this observation could be implementation
         specific. We are not sure if we should leave this item]
   o  Slave servers will need to be able to fetch newly signed zones
      well before the data expires from your zone.
         'Better no answers than bad answers.'
         If a properly implemented slave server is not able to contact a
         master server for an extended period the data will at some
         point expire and the slave server will not hand out any data.
         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 signaturs, is
         that non-secure resolvers will continue to be able to resolve
         data served by the particular slave servers. Security aware
         resolvers will experience problems.
         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 suggest that operators of nameservers with slave zones
         develop 'watch dogs' to spot upcoming signature expirations in
         slave zones, 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 and load a valid zone? All these arguments are
         not DNSSEC specific.

3.  Keys

   In the DNSSEC protocol there is only one type of key, the zone key.
   With this key, the data in a zone is signed.

   To make zone re-signing and key rollovers procedures easier to
   implement, it is possible to use one or more keys as Key Signing Keys
   (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other
   keys can be used to sign all the RRsets in a zone and are referred to
   as Zone Signing Keys (ZSK). In this document we assume that KSKs are
   the subset of keys that are used for key exchanges with the parents



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