etc/services - sync with NetBSD-8
[minix.git] / external / bsd / bind / dist / contrib / zkt-1.1.3 / doc / rfc4641.txt
blob0a013bcba5a8e70a7a43bc36cc5e02c57e467cd9
7 Network Working Group                                         O. Kolkman
8 Request for Comments: 4641                                     R. Gieben
9 Obsoletes: 2541                                               NLnet Labs
10 Category: Informational                                   September 2006
13                       DNSSEC Operational Practices
15 Status of This Memo
17    This memo provides information for the Internet community.  It does
18    not specify an Internet standard of any kind.  Distribution of this
19    memo is unlimited.
21 Copyright Notice
23    Copyright (C) The Internet Society (2006).
25 Abstract
27    This document describes a set of practices for operating the DNS with
28    security extensions (DNSSEC).  The target audience is zone
29    administrators deploying DNSSEC.
31    The document discusses operational aspects of using keys and
32    signatures in the DNS.  It discusses issues of key generation, key
33    storage, signature generation, key rollover, and related policies.
35    This document obsoletes RFC 2541, as it covers more operational
36    ground and gives more up-to-date requirements with respect to key
37    sizes and the new DNSSEC specification.
58 Kolkman & Gieben             Informational                      [Page 1]
60 RFC 4641              DNSSEC Operational Practices        September 2006
63 Table of Contents
65    1. Introduction ....................................................3
66       1.1. The Use of the Term 'key' ..................................4
67       1.2. Time Definitions ...........................................4
68    2. Keeping the Chain of Trust Intact ...............................5
69    3. Keys Generation and Storage .....................................6
70       3.1. Zone and Key Signing Keys ..................................6
71            3.1.1. Motivations for the KSK and ZSK Separation ..........6
72            3.1.2. KSKs for High-Level Zones ...........................7
73       3.2. Key Generation .............................................8
74       3.3. Key Effectivity Period .....................................8
75       3.4. Key Algorithm ..............................................9
76       3.5. Key Sizes ..................................................9
77       3.6. Private Key Storage .......................................11
78    4. Signature Generation, Key Rollover, and Related Policies .......12
79       4.1. Time in DNSSEC ............................................12
80            4.1.1. Time Considerations ................................12
81       4.2. Key Rollovers .............................................14
82            4.2.1. Zone Signing Key Rollovers .........................14
83                   4.2.1.1. Pre-Publish Key Rollover ..................15
84                   4.2.1.2. Double Signature Zone Signing Key
85                            Rollover ..................................17
86                   4.2.1.3. Pros and Cons of the Schemes ..............18
87            4.2.2. Key Signing Key Rollovers ..........................18
88            4.2.3. Difference Between ZSK and KSK Rollovers ...........20
89            4.2.4. Automated Key Rollovers ............................21
90       4.3. Planning for Emergency Key Rollover .......................21
91            4.3.1. KSK Compromise .....................................22
92                   4.3.1.1. Keeping the Chain of Trust Intact .........22
93                   4.3.1.2. Breaking the Chain of Trust ...............23
94            4.3.2. ZSK Compromise .....................................23
95            4.3.3. Compromises of Keys Anchored in Resolvers ..........24
96       4.4. Parental Policies .........................................24
97            4.4.1. Initial Key Exchanges and Parental Policies
98                   Considerations .....................................24
99            4.4.2. Storing Keys or Hashes? ............................25
100            4.4.3. Security Lameness ..................................25
101            4.4.4. DS Signature Validity Period .......................26
102    5. Security Considerations ........................................26
103    6. Acknowledgments ................................................26
104    7. References .....................................................27
105       7.1. Normative References ......................................27
106       7.2. Informative References ....................................28
107    Appendix A. Terminology ...........................................30
108    Appendix B. Zone Signing Key Rollover How-To ......................31
109    Appendix C. Typographic Conventions ...............................32
114 Kolkman & Gieben             Informational                      [Page 2]
116 RFC 4641              DNSSEC Operational Practices        September 2006
119 1.  Introduction
121    This document describes how to run a DNS Security (DNSSEC)-enabled
122    environment.  It is intended for operators who have knowledge of the
123    DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC.
124    See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the
125    newly introduced Resource Records (RRs), and RFC 4035 [6] for the
126    protocol changes.
128    During workshops and early operational deployment tests, operators
129    and system administrators have gained experience about operating the
130    DNS with security extensions (DNSSEC).  This document translates
131    these experiences into a set of practices for zone administrators.
132    At the time of writing, there exists very little experience with
133    DNSSEC in production environments; this document should therefore
134    explicitly not be seen as representing 'Best Current Practices'.
136    The procedures herein are focused on the maintenance of signed zones
137    (i.e., signing and publishing zones on authoritative servers).  It is
138    intended that maintenance of zones such as re-signing or key
139    rollovers be transparent to any verifying clients on the Internet.
141    The structure of this document is as follows.  In Section 2, we
142    discuss the importance of keeping the "chain of trust" intact.
143    Aspects of key generation and storage of private keys are discussed
144    in Section 3; the focus in this section is mainly on the private part
145    of the key(s).  Section 4 describes considerations concerning the
146    public part of the keys.  Since these public keys appear in the DNS
147    one has to take into account all kinds of timing issues, which are
148    discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
149    rollover, or supercession, of keys.  Finally, Section 4.4 discusses
150    considerations on how parents deal with their children's public keys
151    in order to maintain chains of trust.
153    The typographic conventions used in this document are explained in
154    Appendix C.
156    Since this is a document with operational suggestions and there are
157    no protocol specifications, the RFC 2119 [7] language does not apply.
159    This document obsoletes RFC 2541 [12] to reflect the evolution of the
160    underlying DNSSEC protocol since then.  Changes in the choice of
161    cryptographic algorithms, DNS record types and type names, and the
162    parent-child key and signature exchange demanded a major rewrite and
163    additional information and explanation.
170 Kolkman & Gieben             Informational                      [Page 3]
172 RFC 4641              DNSSEC Operational Practices        September 2006
175 1.1.  The Use of the Term 'key'
177    It is assumed that the reader is familiar with the concept of
178    asymmetric keys on which DNSSEC is based (public key cryptography
179    [17]).  Therefore, this document will use the term 'key' rather
180    loosely.  Where it is written that 'a key is used to sign data' it is
181    assumed that the reader understands that it is the private part of
182    the key pair that is used for signing.  It is also assumed that the
183    reader understands that the public part of the key pair is published
184    in the DNSKEY Resource Record and that it is the public part that is
185    used in key exchanges.
187 1.2.  Time Definitions
189    In this document, we will be using a number of time-related terms.
190    The following definitions apply:
192    o  "Signature validity period" The period that a signature is valid.
193       It starts at the time specified in the signature inception field
194       of the RRSIG RR and ends at the time specified in the expiration
195       field of the RRSIG RR.
197    o  "Signature publication period" Time after which a signature (made
198       with a specific key) is replaced with a new signature (made with
199       the same key).  This replacement takes place by publishing the
200       relevant RRSIG in the master zone file.  After one stops
201       publishing an RRSIG in a zone, it may take a while before the
202       RRSIG has expired from caches and has actually been removed from
203       the DNS.
205    o  "Key effectivity period" The period during which a key pair is
206       expected to be effective.  This period is defined as the time
207       between the first inception time stamp and the last expiration
208       date of any signature made with this key, regardless of any
209       discontinuity in the use of the key.  The key effectivity period
210       can span multiple signature validity periods.
212    o  "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum
213       value of the TTLs from the complete set of RRs in a zone.  Note
214       that the minimum TTL is not the same as the MINIMUM field in the
215       SOA RR.  See [11] for more information.
226 Kolkman & Gieben             Informational                      [Page 4]
228 RFC 4641              DNSSEC Operational Practices        September 2006
231 2.  Keeping the Chain of Trust Intact
233    Maintaining a valid chain of trust is important because broken chains
234    of trust will result in data being marked as Bogus (as defined in [4]
235    Section 5), which may cause entire (sub)domains to become invisible
236    to verifying clients.  The administrators of secured zones have to
237    realize that their zone is, to verifying clients, part of a chain of
238    trust.
240    As mentioned in the introduction, the procedures herein are intended
241    to ensure that maintenance of zones, such as re-signing or key
242    rollovers, will be transparent to the verifying clients on the
243    Internet.
245    Administrators of secured zones will have to keep in mind that data
246    published on an authoritative primary server will not be immediately
247    seen by verifying clients; it may take some time for the data to be
248    transferred to other secondary authoritative nameservers and clients
249    may be fetching data from caching non-authoritative servers.  In this
250    light, note that the time for a zone transfer from master to slave is
251    negligible when using NOTIFY [9] and incremental transfer (IXFR) [8].
252    It increases when full zone transfers (AXFR) are used in combination
253    with NOTIFY.  It increases even more if you rely on full zone
254    transfers based on only the SOA timing parameters for refresh.
256    For the verifying clients, it is important that data from secured
257    zones can be used to build chains of trust regardless of whether the
258    data came directly from an authoritative server, a caching
259    nameserver, or some middle box.  Only by carefully using the
260    available timing parameters can a zone administrator ensure that the
261    data necessary for verification can be obtained.
263    The responsibility for maintaining the chain of trust is shared by
264    administrators of secured zones in the chain of trust.  This is most
265    obvious in the case of a 'key compromise' when a trade-off between
266    maintaining a valid chain of trust and replacing the compromised keys
267    as soon as possible must be made.  Then zone administrators will have
268    to make a trade-off, between keeping the chain of trust intact --
269    thereby allowing for attacks with the compromised key -- or
270    deliberately breaking the chain of trust and making secured
271    subdomains invisible to security-aware resolvers.  Also see Section
272    4.3.
282 Kolkman & Gieben             Informational                      [Page 5]
284 RFC 4641              DNSSEC Operational Practices        September 2006
287 3.  Keys Generation and Storage
289    This section describes a number of considerations with respect to the
290    security of keys.  It deals with the generation, effectivity period,
291    size, and storage of private keys.
293 3.1.  Zone and Key Signing Keys
295    The DNSSEC validation protocol does not distinguish between different
296    types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
297    practice, operators use Key Signing and Zone Signing Keys and use the
298    so-called Secure Entry Point (SEP) [3] flag to distinguish between
299    them during operations.  The dynamics and considerations are
300    discussed below.
302    To make zone re-signing and key rollover procedures easier to
303    implement, it is possible to use one or more keys as Key Signing Keys
304    (KSKs).  These keys will only sign the apex DNSKEY RRSet in a zone.
305    Other keys can be used to sign all the RRSets in a zone and are
306    referred to as Zone Signing Keys (ZSKs).  In this document, we assume
307    that KSKs are the subset of keys that are used for key exchanges with
308    the parent and potentially for configuration as trusted anchors --
309    the SEP keys.  In this document, we assume a one-to-one mapping
310    between KSK and SEP keys and we assume the SEP flag to be set on all
311    KSKs.
313 3.1.1.  Motivations for the KSK and ZSK Separation
315    Differentiating between the KSK and ZSK functions has several
316    advantages:
318    o  No parent/child interaction is required when ZSKs are updated.
320    o  The KSK can be made stronger (i.e., using more bits in the key
321       material).  This has little operational impact since it is only
322       used to sign a small fraction of the zone data.  Also, the KSK is
323       only used to verify the zone's key set, not for other RRSets in
324       the zone.
326    o  As the KSK is only used to sign a key set, which is most probably
327       updated less frequently than other data in the zone, it can be
328       stored separately from and in a safer location than the ZSK.
330    o  A KSK can have a longer key effectivity period.
332    For almost any method of key management and zone signing, the KSK is
333    used less frequently than the ZSK.  Once a key set is signed with the
334    KSK, all the keys in the key set can be used as ZSKs.  If a ZSK is
338 Kolkman & Gieben             Informational                      [Page 6]
340 RFC 4641              DNSSEC Operational Practices        September 2006
343    compromised, it can be simply dropped from the key set.  The new key
344    set is then re-signed with the KSK.
346    Given the assumption that for KSKs the SEP flag is set, the KSK can
347    be distinguished from a ZSK by examining the flag field in the DNSKEY
348    RR.  If the flag field is an odd number it is a KSK.  If it is an
349    even number it is a ZSK.
351    The Zone Signing Key can be used to sign all the data in a zone on a
352    regular basis.  When a Zone Signing Key is to be rolled, no
353    interaction with the parent is needed.  This allows for signature
354    validity periods on the order of days.
356    The Key Signing Key is only to be used to sign the DNSKEY RRs in a
357    zone.  If a Key Signing Key is to be rolled over, there will be
358    interactions with parties other than the zone administrator.  These
359    can include the registry of the parent zone or administrators of
360    verifying resolvers that have the particular key configured as secure
361    entry points.  Hence, the key effectivity period of these keys can
362    and should be made much longer.  Although, given a long enough key,
363    the key effectivity period can be on the order of years, we suggest
364    planning for a key effectivity on the order of a few months so that a
365    key rollover remains an operational routine.
367 3.1.2.  KSKs for High-Level Zones
369    Higher-level zones are generally more sensitive than lower-level
370    zones.  Anyone controlling or breaking the security of a zone thereby
371    obtains authority over all of its subdomains (except in the case of
372    resolvers that have locally configured the public key of a subdomain,
373    in which case this, and only this, subdomain wouldn't be affected by
374    the compromise of the parent zone).  Therefore, extra care should be
375    taken with high-level zones, and strong keys should be used.
377    The root zone is the most critical of all zones.  Someone controlling
378    or compromising the security of the root zone would control the
379    entire DNS namespace of all resolvers using that root zone (except in
380    the case of resolvers that have locally configured the public key of
381    a subdomain).  Therefore, the utmost care must be taken in the
382    securing of the root zone.  The strongest and most carefully handled
383    keys should be used.  The root zone private key should always be kept
384    off-line.
386    Many resolvers will start at a root server for their access to and
387    authentication of DNS data.  Securely updating the trust anchors in
388    an enormous population of resolvers around the world will be
389    extremely difficult.
394 Kolkman & Gieben             Informational                      [Page 7]
396 RFC 4641              DNSSEC Operational Practices        September 2006
399 3.2.  Key Generation
401    Careful generation of all keys is a sometimes overlooked but
402    absolutely essential element in any cryptographically secure system.
403    The strongest algorithms used with the longest keys are still of no
404    use if an adversary can guess enough to lower the size of the likely
405    key space so that it can be exhaustively searched.  Technical
406    suggestions for the generation of random keys will be found in RFC
407    4086 [14].  One should carefully assess if the random number
408    generator used during key generation adheres to these suggestions.
410    Keys with a long effectivity period are particularly sensitive as
411    they will represent a more valuable target and be subject to attack
412    for a longer time than short-period keys.  It is strongly recommended
413    that long-term key generation occur off-line in a manner isolated
414    from the network via an air gap or, at a minimum, high-level secure
415    hardware.
417 3.3.  Key Effectivity Period
419    For various reasons, keys in DNSSEC need to be changed once in a
420    while.  The longer a key is in use, the greater the probability that
421    it will have been compromised through carelessness, accident,
422    espionage, or cryptanalysis.  Furthermore, when key rollovers are too
423    rare an event, they will not become part of the operational habit and
424    there is risk that nobody on-site will remember the procedure for
425    rollover when the need is there.
427    From a purely operational perspective, a reasonable key effectivity
428    period for Key Signing Keys is 13 months, with the intent to replace
429    them after 12 months.  An intended key effectivity period of a month
430    is reasonable for Zone Signing Keys.
432    For key sizes that match these effectivity periods, see Section 3.5.
434    As argued in Section 3.1.2, securely updating trust anchors will be
435    extremely difficult.  On the other hand, the "operational habit"
436    argument does also apply to trust anchor reconfiguration.  If a short
437    key effectivity period is used and the trust anchor configuration has
438    to be revisited on a regular basis, the odds that the configuration
439    tends to be forgotten is smaller.  The trade-off is against a system
440    that is so dynamic that administrators of the validating clients will
441    not be able to follow the modifications.
443    Key effectivity periods can be made very short, as in a few minutes.
444    But when replacing keys one has to take the considerations from
445    Section 4.1 and Section 4.2 into account.
450 Kolkman & Gieben             Informational                      [Page 8]
452 RFC 4641              DNSSEC Operational Practices        September 2006
455 3.4.  Key Algorithm
457    There are currently three different types of algorithms that can be
458    used in DNSSEC: RSA, DSA, and elliptic curve cryptography.  The
459    latter is fairly new and has yet to be standardized for usage in
460    DNSSEC.
462    RSA has been developed in an open and transparent manner.  As the
463    patent on RSA expired in 2000, its use is now also free.
465    DSA has been developed by the National Institute of Standards and
466    Technology (NIST).  The creation of signatures takes roughly the same
467    time as with RSA, but is 10 to 40 times as slow for verification
468    [17].
470    We suggest the use of RSA/SHA-1 as the preferred algorithm for the
471    key.  The current known attacks on RSA can be defeated by making your
472    key longer.  As the MD5 hashing algorithm is showing cracks, we
473    recommend the usage of SHA-1.
475    At the time of publication, it is known that the SHA-1 hash has
476    cryptanalysis issues.  There is work in progress on addressing these
477    issues.  We recommend the use of public key algorithms based on
478    hashes stronger than SHA-1 (e.g., SHA-256), as soon as these
479    algorithms are available in protocol specifications (see [19] and
480    [20]) and implementations.
482 3.5.  Key Sizes
484    When choosing key sizes, zone administrators will need to take into
485    account how long a key will be used, how much data will be signed
486    during the key publication period (see Section 8.10 of [17]), and,
487    optionally, how large the key size of the parent is.  As the chain of
488    trust really is "a chain", there is not much sense in making one of
489    the keys in the chain several times larger then the others.  As
490    always, it's the weakest link that defines the strength of the entire
491    chain.  Also see Section 3.1.1 for a discussion of how keys serving
492    different roles (ZSK vs. KSK) may need different key sizes.
494    Generating a key of the correct size is a difficult problem; RFC 3766
495    [13] tries to deal with that problem.  The first part of the
496    selection procedure in Section 1 of the RFC states:
498       1. Determine the attack resistance necessary to satisfy the
499          security requirements of the application.  Do this by
500          estimating the minimum number of computer operations that the
501          attacker will be forced to do in order to compromise the
506 Kolkman & Gieben             Informational                      [Page 9]
508 RFC 4641              DNSSEC Operational Practices        September 2006
511          security of the system and then take the logarithm base two of
512          that number.  Call that logarithm value "n".
514          A 1996 report recommended 90 bits as a good all-around choice
515          for system security.  The 90 bit number should be increased by
516          about 2/3 bit/year, or about 96 bits in 2005.
518    [13] goes on to explain how this number "n" can be used to calculate
519    the key sizes in public key cryptography.  This culminated in the
520    table given below (slightly modified for our purpose):
522       +-------------+-----------+--------------+
523       | System      |           |              |
524       | requirement | Symmetric | RSA or DSA   |
525       | for attack  | key size  | modulus size |
526       | resistance  | (bits)    | (bits)       |
527       | (bits)      |           |              |
528       +-------------+-----------+--------------+
529       |     70      |     70    |      947     |
530       |     80      |     80    |     1228     |
531       |     90      |     90    |     1553     |
532       |    100      |    100    |     1926     |
533       |    150      |    150    |     4575     |
534       |    200      |    200    |     8719     |
535       |    250      |    250    |    14596     |
536       +-------------+-----------+--------------+
538    The key sizes given are rather large.  This is because these keys are
539    resilient against a trillionaire attacker.  Assuming this rich
540    attacker will not attack your key and that the key is rolled over
541    once a year, we come to the following recommendations about KSK
542    sizes: 1024 bits for low-value domains, 1300 bits for medium-value
543    domains, and 2048 bits for high-value domains.
545    Whether a domain is of low, medium, or high value depends solely on
546    the views of the zone owner.  One could, for instance, view leaf
547    nodes in the DNS as of low value, and top-level domains (TLDs) or the
548    root zone of high value.  The suggested key sizes should be safe for
549    the next 5 years.
551    As ZSKs can be rolled over more easily (and thus more often), the key
552    sizes can be made smaller.  But as said in the introduction of this
553    paragraph, making the ZSKs' key sizes too small (in relation to the
554    KSKs' sizes) doesn't make much sense.  Try to limit the difference in
555    size to about 100 bits.
562 Kolkman & Gieben             Informational                     [Page 10]
564 RFC 4641              DNSSEC Operational Practices        September 2006
567    Note that nobody can see into the future and that these key sizes are
568    only provided here as a guide.  Further information can be found in
569    [16] and Section 7.5 of [17].  It should be noted though that [16] is
570    already considered overly optimistic about what key sizes are
571    considered safe.
573    One final note concerning key sizes.  Larger keys will increase the
574    sizes of the RRSIG and DNSKEY records and will therefore increase the
575    chance of DNS UDP packet overflow.  Also, the time it takes to
576    validate and create RRSIGs increases with larger keys, so don't
577    needlessly double your key sizes.
579 3.6.  Private Key Storage
581    It is recommended that, where possible, zone private keys and the
582    zone file master copy that is to be signed be kept and used in off-
583    line, non-network-connected, physically secure machines only.
584    Periodically, an application can be run to add authentication to a
585    zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
586    transferred.
588    When relying on dynamic update to manage a signed zone [10], be aware
589    that at least one private key of the zone will have to reside on the
590    master server.  This key is only as secure as the amount of exposure
591    the server receives to unknown clients and the security of the host.
592    Although not mandatory, one could administer the DNS in the following
593    way.  The master that processes the dynamic updates is unavailable
594    from generic hosts on the Internet, it is not listed in the NS RR
595    set, although its name appears in the SOA RRs MNAME field.  The
596    nameservers in the NS RRSet are able to receive zone updates through
597    NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism.  This
598    approach is known as the "hidden master" setup.
600    The ideal situation is to have a one-way information flow to the
601    network to avoid the possibility of tampering from the network.
602    Keeping the zone master file on-line on the network and simply
603    cycling it through an off-line signer does not do this.  The on-line
604    version could still be tampered with if the host it resides on is
605    compromised.  For maximum security, the master copy of the zone file
606    should be off-net and should not be updated based on an unsecured
607    network mediated communication.
609    In general, keeping a zone file off-line will not be practical and
610    the machines on which zone files are maintained will be connected to
611    a network.  Operators are advised to take security measures to shield
612    unauthorized access to the master copy.
618 Kolkman & Gieben             Informational                     [Page 11]
620 RFC 4641              DNSSEC Operational Practices        September 2006
623    For dynamically updated secured zones [10], both the master copy and
624    the private key that is used to update signatures on updated RRs will
625    need to be on-line.
627 4.  Signature Generation, Key Rollover, and Related Policies
629 4.1.  Time in DNSSEC
631    Without DNSSEC, all times in the DNS are relative.  The SOA fields
632    REFRESH, RETRY, and EXPIRATION are timers used to determine the time
633    elapsed after a slave server synchronized with a master server.  The
634    Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
635    are used to determine how long a forwarder should cache data after it
636    has been fetched from an authoritative server.  By using a signature
637    validity period, DNSSEC introduces the notion of an absolute time in
638    the DNS.  Signatures in DNSSEC have an expiration date after which
639    the signature is marked as invalid and the signed data is to be
640    considered Bogus.
642 4.1.1.  Time Considerations
644    Because of the expiration of signatures, one should consider the
645    following:
647    o  We suggest the Maximum Zone TTL of your zone data to be a fraction
648       of your signature validity period.
650          If the TTL would be of similar order as the signature validity
651          period, then all RRSets fetched during the validity period
652          would be cached until the signature expiration time.  Section
653          7.1 of [4] suggests that "the resolver may use the time
654          remaining before expiration of the signature validity period of
655          a signed RRSet as an upper bound for the TTL".  As a result,
656          query load on authoritative servers would peak at signature
657          expiration time, as this is also the time at which records
658          simultaneously expire from caches.
660          To avoid query load peaks, we suggest the TTL on all the RRs in
661          your zone to be at least a few times smaller than your
662          signature validity period.
664    o  We suggest the signature publication period to end at least one
665       Maximum Zone TTL duration before the end of the signature validity
666       period.
674 Kolkman & Gieben             Informational                     [Page 12]
676 RFC 4641              DNSSEC Operational Practices        September 2006
679          Re-signing a zone shortly before the end of the signature
680          validity period may cause simultaneous expiration of data from
681          caches.  This in turn may lead to peaks in the load on
682          authoritative servers.
684    o  We suggest the Minimum Zone TTL to be long enough to both fetch
685       and verify all the RRs in the trust chain.  In workshop
686       environments, it has been demonstrated [18] that a low TTL (under
687       5 to 10 minutes) caused disruptions because of the following two
688       problems:
690          1.  During validation, some data may expire before the
691              validation is complete.  The validator should be able to
692              keep all data until it is completed.  This applies to all
693              RRs needed to complete the chain of trust: DSes, DNSKEYs,
694              RRSIGs, and the final answers, i.e., the RRSet that is
695              returned for the initial query.
697          2.  Frequent verification causes load on recursive nameservers.
698              Data at delegation points, DSes, DNSKEYs, and RRSIGs
699              benefit from caching.  The TTL on those should be
700              relatively long.
702    o  Slave servers will need to be able to fetch newly signed zones
703       well before the RRSIGs in the zone served by the slave server pass
704       their signature expiration time.
706          When a slave server is out of sync with its master and data in
707          a zone is signed by expired signatures, it may be better for
708          the slave server not to give out any answer.
710          Normally, a slave server that is not able to contact a master
711          server for an extended period will expire a zone.  When that
712          happens, the server will respond differently to queries for
713          that zone.  Some servers issue SERVFAIL, whereas others turn
714          off the 'AA' bit in the answers.  The time of expiration is set
715          in the SOA record and is relative to the last successful
716          refresh between the master and the slave servers.  There exists
717          no coupling between the signature expiration of RRSIGs in the
718          zone and the expire parameter in the SOA.
720          If the server serves a DNSSEC zone, then it may well happen
721          that the signatures expire well before the SOA expiration timer
722          counts down to zero.  It is not possible to completely prevent
723          this from happening by tweaking the SOA parameters.  However,
724          the effects can be minimized where the SOA expiration time is
725          equal to or shorter than the signature validity period.  The
726          consequence of an authoritative server not being able to update
730 Kolkman & Gieben             Informational                     [Page 13]
732 RFC 4641              DNSSEC Operational Practices        September 2006
735          a zone, whilst that zone includes expired signatures, is that
736          non-secure resolvers will continue to be able to resolve data
737          served by the particular slave servers while security-aware
738          resolvers will experience problems because of answers being
739          marked as Bogus.
741          We suggest the SOA expiration timer being approximately one
742          third or one fourth of the signature validity period.  It will
743          allow problems with transfers from the master server to be
744          noticed before the actual signature times out.  We also suggest
745          that operators of nameservers that supply secondary services
746          develop 'watch dogs' to spot upcoming signature expirations in
747          zones they slave, and take appropriate action.
749          When determining the value for the expiration parameter one has
750          to take the following into account: What are the chances that
751          all my secondaries expire the zone? How quickly can I reach an
752          administrator of secondary servers to load a valid zone?  These
753          questions are not DNSSEC specific but may influence the choice
754          of your signature validity intervals.
756 4.2.  Key Rollovers
758    A DNSSEC key cannot be used forever (see Section 3.3).  So key
759    rollovers -- or supercessions, as they are sometimes called -- are a
760    fact of life when using DNSSEC.  Zone administrators who are in the
761    process of rolling their keys have to take into account that data
762    published in previous versions of their zone still lives in caches.
763    When deploying DNSSEC, this becomes an important consideration;
764    ignoring data that may be in caches may lead to loss of service for
765    clients.
767    The most pressing example of this occurs when zone material signed
768    with an old key is being validated by a resolver that does not have
769    the old zone key cached.  If the old key is no longer present in the
770    current zone, this validation fails, marking the data "Bogus".
771    Alternatively, an attempt could be made to validate data that is
772    signed with a new key against an old key that lives in a local cache,
773    also resulting in data being marked "Bogus".
775 4.2.1.  Zone Signing Key Rollovers
777    For "Zone Signing Key rollovers", there are two ways to make sure
778    that during the rollover data still cached can be verified with the
779    new key sets or newly generated signatures can be verified with the
780    keys still in caches.  One schema, described in Section 4.2.1.2, uses
786 Kolkman & Gieben             Informational                     [Page 14]
788 RFC 4641              DNSSEC Operational Practices        September 2006
791    double signatures; the other uses key pre-publication (Section
792    4.2.1.1).  The pros, cons, and recommendations are described in
793    Section 4.2.1.3.
795 4.2.1.1.  Pre-Publish Key Rollover
797    This section shows how to perform a ZSK rollover without the need to
798    sign all the data in a zone twice -- the "pre-publish key rollover".
799    This method has advantages in the case of a key compromise.  If the
800    old key is compromised, the new key has already been distributed in
801    the DNS.  The zone administrator is then able to quickly switch to
802    the new key and remove the compromised key from the zone.  Another
803    major advantage is that the zone size does not double, as is the case
804    with the double signature ZSK rollover.  A small "how-to" for this
805    kind of rollover can be found in Appendix B.
807    Pre-publish key rollover involves four stages as follows:
809       ----------------------------------------------------------------
810       initial         new DNSKEY       new RRSIGs      DNSKEY removal
811       ----------------------------------------------------------------
812       SOA0            SOA1             SOA2            SOA3
813       RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
815       DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
816       DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
817       DNSKEY11         DNSKEY11
818       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
819       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
820       ----------------------------------------------------------------
822                          Pre-Publish Key Rollover
824    initial: Initial version of the zone: DNSKEY 1 is the Key Signing
825       Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
826       Signing Key.
828    new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
829       signatures are generated with this key yet, but this does not
830       secure against brute force attacks on the public key.  The minimum
831       duration of this pre-roll phase is the time it takes for the data
832       to propagate to the authoritative servers plus TTL value of the
833       key set.
835    new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is
836       used to sign the data in the zone exclusively (i.e., all the
837       signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
838       remains published in the key set.  This way data that was loaded
842 Kolkman & Gieben             Informational                     [Page 15]
844 RFC 4641              DNSSEC Operational Practices        September 2006
847       into caches from version 1 of the zone can still be verified with
848       key sets fetched from version 2 of the zone.  The minimum time
849       that the key set including DNSKEY 10 is to be published is the
850       time that it takes for zone data from the previous version of the
851       zone to expire from old caches, i.e., the time it takes for this
852       zone to propagate to all authoritative servers plus the Maximum
853       Zone TTL value of any of the data in the previous version of the
854       zone.
856    DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
857       only containing DNSKEY 1 and DNSKEY 11, is re-signed with the
858       DNSKEY 1.
860    The above scheme can be simplified by always publishing the "future"
861    key immediately after the rollover.  The scheme would look as follows
862    (we show two rollovers); the future key is introduced in "new DNSKEY"
863    as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
864    (II)":
866       ----------------------------------------------------------------
867       initial             new RRSIGs          new DNSKEY
868       ----------------------------------------------------------------
869       SOA0                SOA1                SOA2
870       RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
872       DNSKEY1             DNSKEY1             DNSKEY1
873       DNSKEY10            DNSKEY10            DNSKEY11
874       DNSKEY11            DNSKEY11            DNSKEY12
875       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
876       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
877       ----------------------------------------------------------------
879       ----------------------------------------------------------------
880       new RRSIGs (II)     new DNSKEY (II)
881       ----------------------------------------------------------------
882       SOA3                SOA4
883       RRSIG12(SOA3)       RRSIG12(SOA4)
885       DNSKEY1             DNSKEY1
886       DNSKEY11            DNSKEY12
887       DNSKEY12            DNSKEY13
888       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
889       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
890       ----------------------------------------------------------------
892               Pre-Publish Key Rollover, Showing Two Rollovers
898 Kolkman & Gieben             Informational                     [Page 16]
900 RFC 4641              DNSSEC Operational Practices        September 2006
903    Note that the key introduced in the "new DNSKEY" phase is not used
904    for production yet; the private key can thus be stored in a
905    physically secure manner and does not need to be 'fetched' every time
906    a zone needs to be signed.
908 4.2.1.2.  Double Signature Zone Signing Key Rollover
910    This section shows how to perform a ZSK key rollover using the double
911    zone data signature scheme, aptly named "double signature rollover".
913    During the "new DNSKEY" stage the new version of the zone file will
914    need to propagate to all authoritative servers and the data that
915    exists in (distant) caches will need to expire, requiring at least
916    the Maximum Zone TTL.
918    Double signature ZSK rollover involves three stages as follows:
920       ----------------------------------------------------------------
921       initial             new DNSKEY         DNSKEY removal
922       ----------------------------------------------------------------
923       SOA0                SOA1               SOA2
924       RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
925       RRSIG11(SOA1)
927       DNSKEY1             DNSKEY1            DNSKEY1
928       DNSKEY10            DNSKEY10           DNSKEY11
929       DNSKEY11
930       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
931       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
932       RRSIG11(DNSKEY)
933       ----------------------------------------------------------------
935                 Double Signature Zone Signing Key Rollover
937    initial: Initial Version of the zone: DNSKEY 1 is the Key Signing
938       Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
939       Signing Key.
941    new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
942       introduced into the key set and all the data in the zone is signed
943       with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
944       continue until all data from version 0 of the zone has expired
945       from remote caches.  This will take at least the Maximum Zone TTL
946       of version 0 of the zone.
948    DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
949       signatures from DNSKEY 10 are removed from the zone.  The key set,
950       now only containing DNSKEY 11, is re-signed with DNSKEY 1.
954 Kolkman & Gieben             Informational                     [Page 17]
956 RFC 4641              DNSSEC Operational Practices        September 2006
959    At every instance, RRSIGs from the previous version of the zone can
960    be verified with the DNSKEY RRSet from the current version and the
961    other way around.  The data from the current version can be verified
962    with the data from the previous version of the zone.  The duration of
963    the "new DNSKEY" phase and the period between rollovers should be at
964    least the Maximum Zone TTL.
966    Making sure that the "new DNSKEY" phase lasts until the signature
967    expiration time of the data in initial version of the zone is
968    recommended.  This way all caches are cleared of the old signatures.
969    However, this duration could be considerably longer than the Maximum
970    Zone TTL, making the rollover a lengthy procedure.
972    Note that in this example we assumed that the zone was not modified
973    during the rollover.  New data can be introduced in the zone as long
974    as it is signed with both keys.
976 4.2.1.3.  Pros and Cons of the Schemes
978    Pre-publish key rollover: This rollover does not involve signing the
979       zone data twice.  Instead, before the actual rollover, the new key
980       is published in the key set and thus is available for
981       cryptanalysis attacks.  A small disadvantage is that this process
982       requires four steps.  Also the pre-publish scheme involves more
983       parental work when used for KSK rollovers as explained in Section
984       4.2.3.
986    Double signature ZSK rollover: The drawback of this signing scheme is
987       that during the rollover the number of signatures in your zone
988       doubles; this may be prohibitive if you have very big zones.  An
989       advantage is that it only requires three steps.
991 4.2.2.  Key Signing Key Rollovers
993    For the rollover of a Key Signing Key, the same considerations as for
994    the rollover of a Zone Signing Key apply.  However, we can use a
995    double signature scheme to guarantee that old data (only the apex key
996    set) in caches can be verified with a new key set and vice versa.
997    Since only the key set is signed with a KSK, zone size considerations
998    do not apply.
1010 Kolkman & Gieben             Informational                     [Page 18]
1012 RFC 4641              DNSSEC Operational Practices        September 2006
1015    --------------------------------------------------------------------
1016        initial        new DNSKEY        DS change       DNSKEY removal
1017    --------------------------------------------------------------------
1018      Parent:
1019        SOA0           -------->         SOA1            -------->
1020        RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
1021        DS1            -------->         DS2             -------->
1022        RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
1025      Child:
1026        SOA0            SOA1             -------->       SOA2
1027        RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
1028                                         -------->
1029        DNSKEY1         DNSKEY1          -------->       DNSKEY2
1030                        DNSKEY2          -------->
1031        DNSKEY10        DNSKEY10         -------->       DNSKEY10
1032        RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
1033                        RRSIG2 (DNSKEY)  -------->
1034        RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
1035    --------------------------------------------------------------------
1037    Stages of Deployment for a Double Signature Key Signing Key Rollover
1039    initial: Initial version of the zone.  The parental DS points to
1040       DNSKEY1.  Before the rollover starts, the child will have to
1041       verify what the TTL is of the DS RR that points to DNSKEY1 -- it
1042       is needed during the rollover and we refer to the value as TTL_DS.
1044    new DNSKEY: During the "new DNSKEY" phase, the zone administrator
1045       generates a second KSK, DNSKEY2.  The key is provided to the
1046       parent, and the child will have to wait until a new DS RR has been
1047       generated that points to DNSKEY2.  After that DS RR has been
1048       published on all servers authoritative for the parent's zone, the
1049       zone administrator has to wait at least TTL_DS to make sure that
1050       the old DS RR has expired from caches.
1052    DS change: The parent replaces DS1 with DS2.
1054    DNSKEY removal: DNSKEY1 has been removed.
1056    The scenario above puts the responsibility for maintaining a valid
1057    chain of trust with the child.  It also is based on the premise that
1058    the parent only has one DS RR (per algorithm) per zone.  An
1059    alternative mechanism has been considered.  Using an established
1060    trust relation, the interaction can be performed in-band, and the
1061    removal of the keys by the child can possibly be signaled by the
1062    parent.  In this mechanism, there are periods where there are two DS
1066 Kolkman & Gieben             Informational                     [Page 19]
1068 RFC 4641              DNSSEC Operational Practices        September 2006
1071    RRs at the parent.  Since at the moment of writing the protocol for
1072    this interaction has not been developed, further discussion is out of
1073    scope for this document.
1075 4.2.3.  Difference Between ZSK and KSK Rollovers
1077    Note that KSK rollovers and ZSK rollovers are different in the sense
1078    that a KSK rollover requires interaction with the parent (and
1079    possibly replacing of trust anchors) and the ensuing delay while
1080    waiting for it.
1082    A zone key rollover can be handled in two different ways: pre-publish
1083    (Section 4.2.1.1) and double signature (Section 4.2.1.2).
1085    As the KSK is used to validate the key set and because the KSK is not
1086    changed during a ZSK rollover, a cache is able to validate the new
1087    key set of the zone.  The pre-publish method would also work for a
1088    KSK rollover.  The records that are to be pre-published are the
1089    parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
1090    We first describe the rollover scheme and then indicate these
1091    drawbacks.
1093    --------------------------------------------------------------------
1094      initial         new DS           new DNSKEY      DS/DNSKEY removal
1095    --------------------------------------------------------------------
1096    Parent:
1097      SOA0            SOA1             -------->       SOA2
1098      RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
1099      DS1             DS1              -------->       DS2
1100                      DS2              -------->
1101      RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
1104    Child:
1105      SOA0            -------->        SOA1            SOA1
1106      RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
1107                      -------->
1108      DNSKEY1         -------->        DNSKEY2         DNSKEY2
1109                      -------->
1110      DNSKEY10        -------->        DNSKEY10        DNSKEY10
1111      RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
1112      RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
1113    --------------------------------------------------------------------
1115       Stages of Deployment for a Pre-Publish Key Signing Key Rollover
1122 Kolkman & Gieben             Informational                     [Page 20]
1124 RFC 4641              DNSSEC Operational Practices        September 2006
1127    When the child zone wants to roll, it notifies the parent during the
1128    "new DS" phase and submits the new key (or the corresponding DS) to
1129    the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
1130    and DNSKEY2, respectively.  During the rollover ("new DNSKEY" phase),
1131    which can take place as soon as the new DS set propagated through the
1132    DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
1133    ("DS/DNSKEY removal" phase), it can notify the parent that the old DS
1134    record can be deleted.
1136    The drawbacks of this scheme are that during the "new DS" phase the
1137    parent cannot verify the match between the DS2 RR and DNSKEY2 using
1138    the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
1139    "security lame" key (see Section 4.4.3).  Finally, the child-parent
1140    interaction consists of two steps.  The "double signature" method
1141    only needs one interaction.
1143 4.2.4.  Automated Key Rollovers
1145    As keys must be renewed periodically, there is some motivation to
1146    automate the rollover process.  Consider the following:
1148    o  ZSK rollovers are easy to automate as only the child zone is
1149       involved.
1151    o  A KSK rollover needs interaction between parent and child.  Data
1152       exchange is needed to provide the new keys to the parent;
1153       consequently, this data must be authenticated and integrity must
1154       be guaranteed in order to avoid attacks on the rollover.
1156 4.3.  Planning for Emergency Key Rollover
1158    This section deals with preparation for a possible key compromise.
1159    Our advice is to have a documented procedure ready for when a key
1160    compromise is suspected or confirmed.
1162    When the private material of one of your keys is compromised it can
1163    be used for as long as a valid trust chain exists.  A trust chain
1164    remains intact for
1166    o  as long as a signature over the compromised key in the trust chain
1167       is valid,
1169    o  as long as a parental DS RR (and signature) points to the
1170       compromised key,
1172    o  as long as the key is anchored in a resolver and is used as a
1173       starting point for validation (this is generally the hardest to
1174       update).
1178 Kolkman & Gieben             Informational                     [Page 21]
1180 RFC 4641              DNSSEC Operational Practices        September 2006
1183    While a trust chain to your compromised key exists, your namespace is
1184    vulnerable to abuse by anyone who has obtained illegitimate
1185    possession of the key.  Zone operators have to make a trade-off if
1186    the abuse of the compromised key is worse than having data in caches
1187    that cannot be validated.  If the zone operator chooses to break the
1188    trust chain to the compromised key, data in caches signed with this
1189    key cannot be validated.  However, if the zone administrator chooses
1190    to take the path of a regular rollover, the malicious key holder can
1191    spoof data so that it appears to be valid.
1193 4.3.1.  KSK Compromise
1195    A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
1196    as long as the compromised KSK is configured as trust anchor or a
1197    parental DS points to it.
1199    A compromised KSK can be used to sign the key set of an attacker's
1200    zone.  That zone could be used to poison the DNS.
1202    Therefore, when the KSK has been compromised, the trust anchor or the
1203    parental DS should be replaced as soon as possible.  It is local
1204    policy whether to break the trust chain during the emergency
1205    rollover.  The trust chain would be broken when the compromised KSK
1206    is removed from the child's zone while the parent still has a DS
1207    pointing to the compromised KSK (the assumption is that there is only
1208    one DS at the parent.  If there are multiple DSes this does not apply
1209    -- however the chain of trust of this particular key is broken).
1211    Note that an attacker's zone still uses the compromised KSK and the
1212    presence of a parental DS would cause the data in this zone to appear
1213    as valid.  Removing the compromised key would cause the attacker's
1214    zone to appear as valid and the child's zone as Bogus.  Therefore, we
1215    advise not to remove the KSK before the parent has a DS to a new KSK
1216    in place.
1218 4.3.1.1.  Keeping the Chain of Trust Intact
1220    If we follow this advice, the timing of the replacement of the KSK is
1221    somewhat critical.  The goal is to remove the compromised KSK as soon
1222    as the new DS RR is available at the parent.  And also make sure that
1223    the signature made with a new KSK over the key set with the
1224    compromised KSK in it expires just after the new DS appears at the
1225    parent, thus removing the old cruft in one swoop.
1227    The procedure is as follows:
1229    1.  Introduce a new KSK into the key set, keep the compromised KSK in
1230        the key set.
1234 Kolkman & Gieben             Informational                     [Page 22]
1236 RFC 4641              DNSSEC Operational Practices        September 2006
1239    2.  Sign the key set, with a short validity period.  The validity
1240        period should expire shortly after the DS is expected to appear
1241        in the parent and the old DSes have expired from caches.
1243    3.  Upload the DS for this new key to the parent.
1245    4.  Follow the procedure of the regular KSK rollover: Wait for the DS
1246        to appear in the authoritative servers and then wait as long as
1247        the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
1248        and modify/extend the expiration time.
1250    5.  Remove the compromised DNSKEY RR from the zone and re-sign the
1251        key set using your "normal" validity interval.
1253    An additional danger of a key compromise is that the compromised key
1254    could be used to facilitate a legitimate DNSKEY/DS rollover and/or
1255    nameserver changes at the parent.  When that happens, the domain may
1256    be in dispute.  An authenticated out-of-band and secure notify
1257    mechanism to contact a parent is needed in this case.
1259    Note that this is only a problem when the DNSKEY and or DS records
1260    are used for authentication at the parent.
1262 4.3.1.2.  Breaking the Chain of Trust
1264    There are two methods to break the chain of trust.  The first method
1265    causes the child zone to appear 'Bogus' to validating resolvers.  The
1266    other causes the child zone to appear 'insecure'.  These are
1267    described below.
1269    In the method that causes the child zone to appear 'Bogus' to
1270    validating resolvers, the child zone replaces the current KSK with a
1271    new one and re-signs the key set.  Next it sends the DS of the new
1272    key to the parent.  Only after the parent has placed the new DS in
1273    the zone is the child's chain of trust repaired.
1275    An alternative method of breaking the chain of trust is by removing
1276    the DS RRs from the parent zone altogether.  As a result, the child
1277    zone would become insecure.
1279 4.3.2.  ZSK Compromise
1281    Primarily because there is no parental interaction required when a
1282    ZSK is compromised, the situation is less severe than with a KSK
1283    compromise.  The zone must still be re-signed with a new ZSK as soon
1284    as possible.  As this is a local operation and requires no
1285    communication between the parent and child, this can be achieved
1286    fairly quickly.  However, one has to take into account that just as
1290 Kolkman & Gieben             Informational                     [Page 23]
1292 RFC 4641              DNSSEC Operational Practices        September 2006
1295    with a normal rollover the immediate disappearance of the old
1296    compromised key may lead to verification problems.  Also note that as
1297    long as the RRSIG over the compromised ZSK is not expired the zone
1298    may be still at risk.
1300 4.3.3.  Compromises of Keys Anchored in Resolvers
1302    A key can also be pre-configured in resolvers.  For instance, if
1303    DNSSEC is successfully deployed the root key may be pre-configured in
1304    most security aware resolvers.
1306    If trust-anchor keys are compromised, the resolvers using these keys
1307    should be notified of this fact.  Zone administrators may consider
1308    setting up a mailing list to communicate the fact that a SEP key is
1309    about to be rolled over.  This communication will of course need to
1310    be authenticated, e.g., by using digital signatures.
1312    End-users faced with the task of updating an anchored key should
1313    always validate the new key.  New keys should be authenticated out-
1314    of-band, for example, through the use of an announcement website that
1315    is secured using secure sockets (TLS) [21].
1317 4.4.  Parental Policies
1319 4.4.1.  Initial Key Exchanges and Parental Policies Considerations
1321    The initial key exchange is always subject to the policies set by the
1322    parent.  When designing a key exchange policy one should take into
1323    account that the authentication and authorization mechanisms used
1324    during a key exchange should be as strong as the authentication and
1325    authorization mechanisms used for the exchange of delegation
1326    information between parent and child.  That is, there is no implicit
1327    need in DNSSEC to make the authentication process stronger than it
1328    was in DNS.
1330    Using the DNS itself as the source for the actual DNSKEY material,
1331    with an out-of-band check on the validity of the DNSKEY, has the
1332    benefit that it reduces the chances of user error.  A DNSKEY query
1333    tool can make use of the SEP bit [3] to select the proper key from a
1334    DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is
1335    sent.  It can validate the self-signature over a key; thereby
1336    verifying the ownership of the private key material.  Fetching the
1337    DNSKEY from the DNS ensures that the chain of trust remains intact
1338    once the parent publishes the DS RR indicating the child is secure.
1340    Note: the out-of-band verification is still needed when the key
1341    material is fetched via the DNS.  The parent can never be sure
1342    whether or not the DNSKEY RRs have been spoofed.
1346 Kolkman & Gieben             Informational                     [Page 24]
1348 RFC 4641              DNSSEC Operational Practices        September 2006
1351 4.4.2.  Storing Keys or Hashes?
1353    When designing a registry system one should consider which of the
1354    DNSKEYs and/or the corresponding DSes to store.  Since a child zone
1355    might wish to have a DS published using a message digest algorithm
1356    not yet understood by the registry, the registry can't count on being
1357    able to generate the DS record from a raw DNSKEY.  Thus, we recommend
1358    that registry systems at least support storing DS records.
1360    It may also be useful to store DNSKEYs, since having them may help
1361    during troubleshooting and, as long as the child's chosen message
1362    digest is supported, the overhead of generating DS records from them
1363    is minimal.  Having an out-of-band mechanism, such as a registry
1364    directory (e.g., Whois), to find out which keys are used to generate
1365    DS Resource Records for specific owners and/or zones may also help
1366    with troubleshooting.
1368    The storage considerations also relate to the design of the customer
1369    interface and the method by which data is transferred between
1370    registrant and registry; Will the child zone administrator be able to
1371    upload DS RRs with unknown hash algorithms or does the interface only
1372    allow DNSKEYs?  In the registry-registrar model, one can use the
1373    DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15],
1374    which allows transfer of DS RRs and optionally DNSKEY RRs.
1376 4.4.3.  Security Lameness
1378    Security lameness is defined as what happens when a parent has a DS
1379    RR pointing to a non-existing DNSKEY RR.  When this happens, the
1380    child's zone may be marked "Bogus" by verifying DNS clients.
1382    As part of a comprehensive delegation check, the parent could, at key
1383    exchange time, verify that the child's key is actually configured in
1384    the DNS.  However, if a parent does not understand the hashing
1385    algorithm used by child, the parental checks are limited to only
1386    comparing the key id.
1388    Child zones should be very careful in removing DNSKEY material,
1389    specifically SEP keys, for which a DS RR exists.
1391    Once a zone is "security lame", a fix (e.g., removing a DS RR) will
1392    take time to propagate through the DNS.
1402 Kolkman & Gieben             Informational                     [Page 25]
1404 RFC 4641              DNSSEC Operational Practices        September 2006
1407 4.4.4.  DS Signature Validity Period
1409    Since the DS can be replayed as long as it has a valid signature, a
1410    short signature validity period over the DS minimizes the time a
1411    child is vulnerable in the case of a compromise of the child's
1412    KSK(s).  A signature validity period that is too short introduces the
1413    possibility that a zone is marked "Bogus" in case of a configuration
1414    error in the signer.  There may not be enough time to fix the
1415    problems before signatures expire.  Something as mundane as operator
1416    unavailability during weekends shows the need for DS signature
1417    validity periods longer than 2 days.  We recommend an absolute
1418    minimum for a DS signature validity period of a few days.
1420    The maximum signature validity period of the DS record depends on how
1421    long child zones are willing to be vulnerable after a key compromise.
1422    On the other hand, shortening the DS signature validity interval
1423    increases the operational risk for the parent.  Therefore, the parent
1424    may have policy to use a signature validity interval that is
1425    considerably longer than the child would hope for.
1427    A compromise between the operational constraints of the parent and
1428    minimizing damage for the child may result in a DS signature validity
1429    period somewhere between a week and months.
1431    In addition to the signature validity period, which sets a lower
1432    bound on the number of times the zone owner will need to sign the
1433    zone data and which sets an upper bound to the time a child is
1434    vulnerable after key compromise, there is the TTL value on the DS
1435    RRs.  Shortening the TTL means that the authoritative servers will
1436    see more queries.  But on the other hand, a short TTL lowers the
1437    persistence of DS RRSets in caches thereby increasing the speed with
1438    which updated DS RRSets propagate through the DNS.
1440 5.  Security Considerations
1442    DNSSEC adds data integrity to the DNS.  This document tries to assess
1443    the operational considerations to maintain a stable and secure DNSSEC
1444    service.  Not taking into account the 'data propagation' properties
1445    in the DNS will cause validation failures and may make secured zones
1446    unavailable to security-aware resolvers.
1448 6.  Acknowledgments
1450    Most of the ideas in this document were the result of collective
1451    efforts during workshops, discussions, and tryouts.
1453    At the risk of forgetting individuals who were the original
1454    contributors of the ideas, we would like to acknowledge people who
1458 Kolkman & Gieben             Informational                     [Page 26]
1460 RFC 4641              DNSSEC Operational Practices        September 2006
1463    were actively involved in the compilation of this document.  In
1464    random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
1465    Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
1466    Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
1467    Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch.
1469    Some material in this document has been copied from RFC 2541 [12].
1471    Mike StJohns designed the key exchange between parent and child
1472    mentioned in the last paragraph of Section 4.2.2
1474    Section 4.2.4 was supplied by G. Guette and O. Courtay.
1476    Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of
1477    the spelling and style issues.
1479    Kolkman and Gieben take the blame for introducing all miscakes (sic).
1481    While working on this document, Kolkman was employed by the RIPE NCC
1482    and Gieben was employed by NLnet Labs.
1484 7.  References
1486 7.1.  Normative References
1488    [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
1489          13, RFC 1034, November 1987.
1491    [2]   Mockapetris, P., "Domain names - implementation and
1492          specification", STD 13, RFC 1035, November 1987.
1494    [3]   Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
1495          KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
1496          Flag", RFC 3757, May 2004.
1498    [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
1499          "DNS Security Introduction and Requirements", RFC 4033, March
1500          2005.
1502    [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
1503          "Resource Records for the DNS Security Extensions", RFC 4034,
1504          March 2005.
1506    [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
1507          "Protocol Modifications for the DNS Security Extensions", RFC
1508          4035, March 2005.
1514 Kolkman & Gieben             Informational                     [Page 27]
1516 RFC 4641              DNSSEC Operational Practices        September 2006
1519 7.2.  Informative References
1521    [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
1522          Levels", BCP 14, RFC 2119, March 1997.
1524    [8]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
1525          1996.
1527    [9]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
1528          (DNS NOTIFY)", RFC 1996, August 1996.
1530    [10]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
1531          Update", RFC 3007, November 2000.
1533    [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
1534          RFC 2308, March 1998.
1536    [12]  Eastlake, D., "DNS Security Operational Considerations", RFC
1537          2541, March 1999.
1539    [13]  Orman, H. and P. Hoffman, "Determining Strengths For Public
1540          Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
1541          April 2004.
1543    [14]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
1544          Requirements for Security", BCP 106, RFC 4086, June 2005.
1546    [15]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
1547          Mapping for the Extensible Provisioning Protocol (EPP)", RFC
1548          4310, December 2005.
1550    [16]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1551          Sizes", The Journal of Cryptology 14 (255-293), 2001.
1553    [17]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
1554          Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
1555          (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
1556          1996.
1558    [18]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
1560    [19]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
1561          Records in DNSSEC", Work in Progress, January 2006.
1563    [20]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
1564          Resource Records (RRs)", RFC 4509, May 2006.
1570 Kolkman & Gieben             Informational                     [Page 28]
1572 RFC 4641              DNSSEC Operational Practices        September 2006
1575    [21]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
1576          T. Wright, "Transport Layer Security (TLS) Extensions", RFC
1577          4366, April 2006.
1626 Kolkman & Gieben             Informational                     [Page 29]
1628 RFC 4641              DNSSEC Operational Practices        September 2006
1631 Appendix A.  Terminology
1633    In this document, there is some jargon used that is defined in other
1634    documents.  In most cases, we have not copied the text from the
1635    documents defining the terms but have given a more elaborate
1636    explanation of the meaning.  Note that these explanations should not
1637    be seen as authoritative.
1639    Anchored key: A DNSKEY configured in resolvers around the globe.
1640       This key is hard to update, hence the term anchored.
1642    Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
1643       "Bogus" when a signature of an RRSet does not validate against a
1644       DNSKEY.
1646    Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
1647       exclusively for signing the apex key set.  The fact that a key is
1648       a KSK is only relevant to the signing tool.
1650    Key size: The term 'key size' can be substituted by 'modulus size'
1651       throughout the document.  It is mathematically more correct to use
1652       modulus size, but as this is a document directed at operators we
1653       feel more at ease with the term key size.
1655    Private and public keys: DNSSEC secures the DNS through the use of
1656       public key cryptography.  Public key cryptography is based on the
1657       existence of two (mathematically related) keys, a public key and a
1658       private key.  The public keys are published in the DNS by use of
1659       the DNSKEY Resource Record (DNSKEY RR).  Private keys should
1660       remain private.
1662    Key rollover: A key rollover (also called key supercession in some
1663       environments) is the act of replacing one key pair with another at
1664       the end of a key effectivity period.
1666    Secure Entry Point (SEP) key: A KSK that has a parental DS record
1667       pointing to it or is configured as a trust anchor.  Although not
1668       required by the protocol, we recommend that the SEP flag [3] is
1669       set on these keys.
1671    Self-signature: This only applies to signatures over DNSKEYs; a
1672       signature made with DNSKEY x, over DNSKEY x is called a self-
1673       signature.  Note: without further information, self-signatures
1674       convey no trust.  They are useful to check the authenticity of the
1675       DNSKEY, i.e., they can be used as a hash.
1682 Kolkman & Gieben             Informational                     [Page 30]
1684 RFC 4641              DNSSEC Operational Practices        September 2006
1687    Singing the zone file: The term used for the event where an
1688       administrator joyfully signs its zone file while producing melodic
1689       sound patterns.
1691    Signer: The system that has access to the private key material and
1692       signs the Resource Record sets in a zone.  A signer may be
1693       configured to sign only parts of the zone, e.g., only those RRSets
1694       for which existing signatures are about to expire.
1696    Zone Signing Key (ZSK): A key that is used for signing all data in a
1697       zone.  The fact that a key is a ZSK is only relevant to the
1698       signing tool.
1700    Zone administrator: The 'role' that is responsible for signing a zone
1701       and publishing it on the primary authoritative server.
1703 Appendix B.  Zone Signing Key Rollover How-To
1705    Using the pre-published signature scheme and the most conservative
1706    method to assure oneself that data does not live in caches, here
1707    follows the "how-to".
1709    Step 0: The preparation: Create two keys and publish both in your key
1710       set.  Mark one of the keys "active" and the other "published".
1711       Use the "active" key for signing your zone data.  Store the
1712       private part of the "published" key, preferably off-line.  The
1713       protocol does not provide for attributes to mark a key as active
1714       or published.  This is something you have to do on your own,
1715       through the use of a notebook or key management tool.
1717    Step 1: Determine expiration: At the beginning of the rollover make a
1718       note of the highest expiration time of signatures in your zone
1719       file created with the current key marked as active.  Wait until
1720       the expiration time marked in Step 1 has passed.
1722    Step 2: Then start using the key that was marked "published" to sign
1723       your data (i.e., mark it "active").  Stop using the key that was
1724       marked "active"; mark it "rolled".
1726    Step 3: It is safe to engage in a new rollover (Step 1) after at
1727       least one signature validity period.
1738 Kolkman & Gieben             Informational                     [Page 31]
1740 RFC 4641              DNSSEC Operational Practices        September 2006
1743 Appendix C.  Typographic Conventions
1745    The following typographic conventions are used in this document:
1747    Key notation: A key is denoted by DNSKEYx, where x is a number or an
1748    identifier, x could be thought of as the key id.
1750    RRSet notations: RRs are only denoted by the type.  All other
1751    information -- owner, class, rdata, and TTL--is left out.  Thus:
1752    "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
1753    list of RRs.  A example of this would be "A1, A2", specifying the
1754    RRSet containing two "A" records.  This could again be abbreviated to
1755    just "A".
1757    Signature notation: Signatures are denoted as RRSIGx(RRSet), which
1758    means that RRSet is signed with DNSKEYx.
1760    Zone representation: Using the above notation we have simplified the
1761    representation of a signed zone by leaving out all unnecessary
1762    details such as the names and by representing all data by "SOAx"
1764    SOA representation: SOAs are represented as SOAx, where x is the
1765    serial number.
1767    Using this notation the following signed zone:
1769    example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
1770                             2006022100   ; serial
1771                             86400        ; refresh (  24 hours)
1772                             7200         ; retry   (   2 hours)
1773                             3600000      ; expire  (1000 hours)
1774                             28800 )      ; minimum (   8 hours)
1775                      86400  RRSIG   SOA 5 2 86400 20130522213204 (
1776                                   20130422213204 14 example.net.
1777                                   cmL62SI6iAX46xGNQAdQ... )
1778                      86400  NS      a.iana-servers.net.
1779                      86400  NS      b.iana-servers.net.
1780                      86400  RRSIG   NS 5 2 86400 20130507213204 (
1781                                   20130407213204 14 example.net.
1782                                   SO5epiJei19AjXoUpFnQ ... )
1783                      86400  DNSKEY  256 3 5 (
1784                                   EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
1785                      86400  DNSKEY  257 3 5 (
1786                                   gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
1787                      86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
1788                                   20130422213204 14 example.net.
1789                                   J4zCe8QX4tXVGjV4e1r9... )
1794 Kolkman & Gieben             Informational                     [Page 32]
1796 RFC 4641              DNSSEC Operational Practices        September 2006
1799                      86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
1800                                   20130422213204 15 example.net.
1801                                   keVDCOpsSeDReyV6O... )
1802                      86400  RRSIG   NSEC 5 2 86400 20130507213204 (
1803                                   20130407213204 14 example.net.
1804                                   obj3HEp1GjnmhRjX... )
1805    a.example.net.    86400  IN TXT  "A label"
1806                      86400  RRSIG   TXT 5 3 86400 20130507213204 (
1807                                   20130407213204 14 example.net.
1808                                   IkDMlRdYLmXH7QJnuF3v... )
1809                      86400  NSEC    b.example.com. TXT RRSIG NSEC
1810                      86400  RRSIG   NSEC 5 3 86400 20130507213204 (
1811                                   20130407213204 14 example.net.
1812                                   bZMjoZ3bHjnEz0nIsPMM... )
1813                      ...
1815    is reduced to the following representation:
1817        SOA2006022100
1818        RRSIG14(SOA2006022100)
1819        DNSKEY14
1820        DNSKEY15
1822        RRSIG14(KEY)
1823        RRSIG15(KEY)
1825    The rest of the zone data has the same signature as the SOA record,
1826    i.e., an RRSIG created with DNSKEY 14.
1850 Kolkman & Gieben             Informational                     [Page 33]
1852 RFC 4641              DNSSEC Operational Practices        September 2006
1855 Authors' Addresses
1857    Olaf M. Kolkman
1858    NLnet Labs
1859    Kruislaan 419
1860    Amsterdam  1098 VA
1861    The Netherlands
1863    EMail: olaf@nlnetlabs.nl
1864    URI:   http://www.nlnetlabs.nl
1867    R. (Miek) Gieben
1869    EMail: miek@miek.nl
1906 Kolkman & Gieben             Informational                     [Page 34]
1908 RFC 4641              DNSSEC Operational Practices        September 2006
1911 Full Copyright Statement
1913    Copyright (C) The Internet Society (2006).
1915    This document is subject to the rights, licenses and restrictions
1916    contained in BCP 78, and except as set forth therein, the authors
1917    retain all their rights.
1919    This document and the information contained herein are provided on an
1920    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1921    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1922    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1923    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1924    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1925    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1927 Intellectual Property
1929    The IETF takes no position regarding the validity or scope of any
1930    Intellectual Property Rights or other rights that might be claimed to
1931    pertain to the implementation or use of the technology described in
1932    this document or the extent to which any license under such rights
1933    might or might not be available; nor does it represent that it has
1934    made any independent effort to identify any such rights.  Information
1935    on the procedures with respect to rights in RFC documents can be
1936    found in BCP 78 and BCP 79.
1938    Copies of IPR disclosures made to the IETF Secretariat and any
1939    assurances of licenses to be made available, or the result of an
1940    attempt made to obtain a general license or permission for the use of
1941    such proprietary rights by implementers or users of this
1942    specification can be obtained from the IETF on-line IPR repository at
1943    http://www.ietf.org/ipr.
1945    The IETF invites any interested party to bring to its attention any
1946    copyrights, patents or patent applications, or other proprietary
1947    rights that may cover technology that may be required to implement
1948    this standard.  Please address the information to the IETF at
1949    ietf-ipr@ietf.org.
1951 Acknowledgement
1953    Funding for the RFC Editor function is provided by the IETF
1954    Administrative Support Activity (IASA).
1962 Kolkman & Gieben             Informational                     [Page 35]