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

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

DNSOP                                                         O. Kolkman
Internet-Draft                                                 R. Gieben
Obsoletes: 2541 (if approved)                                 NLnet Labs
Expires: September 7, 2006                                 March 6, 2006


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 September 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a set of practices for operating the DNS with
   security extensions (DNSSEC).  The target audience is zone
   administrators deploying DNSSEC.

   The document discusses operational aspects of using keys and
   signatures in the DNS.  It discusses issues as key generation, key
   storage, signature generation, key rollover and related policies.




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


   This document obsoletes RFC 2541, as it covers more operational
   ground and gives more up to date requirements with respect to key
   sizes and the new DNSSEC specification.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  The Use of the Term 'key'  . . . . . . . . . . . . . . . .  4
     1.2.  Time Definitions . . . . . . . . . . . . . . . . . . . . .  5
   2.  Keeping the Chain of Trust Intact  . . . . . . . . . . . . . .  5
   3.  Keys Generation and Storage  . . . . . . . . . . . . . . . . .  6
     3.1.  Zone and Key Signing Keys  . . . . . . . . . . . . . . . .  6
       3.1.1.  Motivations for the KSK and ZSK Separation . . . . . .  7
       3.1.2.  KSKs for High Level Zones  . . . . . . . . . . . . . .  8
     3.2.  Key Generation . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Key Effectivity Period . . . . . . . . . . . . . . . . . .  9
     3.4.  Key Algorithm  . . . . . . . . . . . . . . . . . . . . . .  9
     3.5.  Key Sizes  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.6.  Private Key Storage  . . . . . . . . . . . . . . . . . . . 12
   4.  Signature generation, Key Rollover and Related Policies  . . . 12
     4.1.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.1.  Time Considerations  . . . . . . . . . . . . . . . . . 13
     4.2.  Key Rollovers  . . . . . . . . . . . . . . . . . . . . . . 14
       4.2.1.  Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
       4.2.2.  Key Signing Key Rollovers  . . . . . . . . . . . . . . 19
       4.2.3.  Difference Between ZSK and KSK Rollovers . . . . . . . 20
       4.2.4.  Automated Key Rollovers  . . . . . . . . . . . . . . . 21
     4.3.  Planning for Emergency Key Rollover  . . . . . . . . . . . 22
       4.3.1.  KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
       4.3.2.  ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
       4.3.3.  Compromises of Keys Anchored in Resolvers  . . . . . . 24
     4.4.  Parental Policies  . . . . . . . . . . . . . . . . . . . . 24
       4.4.1.  Initial Key Exchanges and Parental Policies
               Considerations . . . . . . . . . . . . . . . . . . . . 24
       4.4.2.  Storing Keys or Hashes?  . . . . . . . . . . . . . . . 25
       4.4.3.  Security Lameness  . . . . . . . . . . . . . . . . . . 25
       4.4.4.  DS Signature Validity Period . . . . . . . . . . . . . 26
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Terminology . . . . . . . . . . . . . . . . . . . . . 29
   Appendix B.  Zone Signing Key Rollover Howto . . . . . . . . . . . 30
   Appendix C.  Typographic Conventions . . . . . . . . . . . . . . . 31
   Appendix D.  Document Details and Changes  . . . . . . . . . . . . 33



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


     D.1.  draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
     D.2.  draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
     D.3.  draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
     D.4.  draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
     D.5.  draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
     D.6.  draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
     D.7.  draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
     D.8.  draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
     D.9.  draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 36








































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


1.  Introduction

   This document describes how to run a DNSSEC (DNS SECure) enabled
   environment.  It is intended for operators who have knowledge of the
   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC.  See
   RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
   newly introduced Resource Records and finally RFC 4035 [6] for the
   protocol changes.

   During workshops and early operational deployment tests, operators
   and system administrators have gained experience about operating the
   DNS with security extensions (DNSSEC).  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 representing '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 re-signing or key
   rollovers be transparent to any verifying clients on the Internet.

   The structure of this document is as follows.  In Section 2 we
   discuss the importance of keeping the "chain of trust" intact.
   Aspects of key generation and storage of private keys are discussed
   in Section 3; the focus in this section is mainly on the private part
   of the key(s).  Section 4 describes considerations concerning the
   public part of the keys.  Since these public keys appear in the DNS
   one has to take into account all kinds of timing issues, which are
   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
   rollover, or supercession, of keys.  Finally Section 4.4 discusses
   considerations on how parents deal with their children's public keys
   in order to maintain chains of trust.

   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 RFC 2119 [9] language does not apply.

   This document obsoletes RFC 2541 [12].

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
   [18]).  Therefore, this document will use the term 'key' rather
   loosely.  Where it is written that 'a key is used to sign data' it is



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


   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 the public part that is
   used in key exchanges.

1.2.  Time Definitions

   In this document we will be using a number of time related terms.
   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.
   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.
         After one stops publishing an RRSIG in a zone it may take a
         while before the RRSIG has expired from caches and has actually
         been removed from the DNS.
   o  "Key effectivity period"
         The period during which a key pair is expected to be effective.
         This period is defined as the time between the first inception
         time stamp and the last expiration date of any signature made
         with this key, regardless of any discontinuity in the use of
         the key.
         The key effectivity period can span multiple signature validity
         periods.
   o  "Maximum/Minimum Zone Time to Live (TTL)"
         The maximum or minimum value of the TTLs from the complete set
         of RRs in a zone.  Note that the minimum TTL is not the same as
         the MINIMUM field in the SOA RR.  See [11] for more
         information.


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 (as defined in [4]
   section 5), which may cause entire (sub)domains to become invisible
   to verifying clients.  The administrators of secured zones have to
   realize that their zone is, to verifying clients, part of a chain of
   trust.

   As mentioned in the introduction, the procedures herein are intended



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


   to ensure that maintenance of zones, such as re-signing or key
   rollovers, will 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
   transferred to other secondary authoritative nameservers and clients
   may be fetching data from caching non-authoritative servers.  In this
   light it is good to note that the time for a zone transfer from
   master to slave is negligible when using NOTIFY [8] and IXFR [7],
   increasing by reliance on AXFR, and more if you rely on the SOA
   timing parameters for zone refresh.

   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