← Back to branch summary

~ubuntu-branches/ubuntu/natty/bind9/natty-security

« back to all changes in this revision

Viewing changes to contrib/zkt/doc/rfc4641.txt

  • Committer: Bazaar Package Importer
  • Author(s): LaMont Jones
  • Date: 2010-07-15 17:11:12 UTC
  • mfrom: (1.6.8 upstream)
  • Revision ID: james.westby@ubuntu.com-20100715171112-t30mndas2k8o0pwn
Tags: 1:9.7.1.dfsg.P2-1~build1
ubuntu upload to speed things along

Show diffs side-by-side

added added

removed removed

Lines of Context:
contrib/zkt/doc/rfc4641.txt
1
 
 
2
 
 
3
 
 
4
 
 
5
 
 
6
 
 
7
 
Network Working Group                                         O. Kolkman
8
 
Request for Comments: 4641                                     R. Gieben
9
 
Obsoletes: 2541                                               NLnet Labs
10
 
Category: Informational                                   September 2006
11
 
 
12
 
 
13
 
                      DNSSEC Operational Practices
14
 
 
15
 
Status of This Memo
16
 
 
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.
20
 
 
21
 
Copyright Notice
22
 
 
23
 
   Copyright (C) The Internet Society (2006).
24
 
 
25
 
Abstract
26
 
 
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.
30
 
 
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.
34
 
 
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.
38
 
 
39
 
 
40
 
 
41
 
 
42
 
 
43
 
 
44
 
 
45
 
 
46
 
 
47
 
 
48
 
 
49
 
 
50
 
 
51
 
 
52
 
 
53
 
 
54
 
 
55
 
 
56
 
 
57
 
 
58
 
Kolkman & Gieben             Informational                      [Page 1]
59
 
 
60
 
RFC 4641              DNSSEC Operational Practices        September 2006
61
 
 
62
 
 
63
 
Table of Contents
64
 
 
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
110
 
 
111
 
 
112
 
 
113
 
 
114
 
Kolkman & Gieben             Informational                      [Page 2]
115
 
 
116
 
RFC 4641              DNSSEC Operational Practices        September 2006
117
 
 
118
 
 
119
 
1.  Introduction
120
 
 
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.
127
 
 
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'.
135
 
 
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.
140
 
 
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.
152
 
 
153
 
   The typographic conventions used in this document are explained in
154
 
   Appendix C.
155
 
 
156
 
   Since this is a document with operational suggestions and there are
157
 
   no protocol specifications, the RFC 2119 [7] language does not apply.
158
 
 
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.
164
 
 
165
 
 
166
 
 
167
 
 
168
 
 
169
 
 
170
 
Kolkman & Gieben             Informational                      [Page 3]
171
 
 
172
 
RFC 4641              DNSSEC Operational Practices        September 2006
173
 
 
174
 
 
175
 
1.1.  The Use of the Term 'key'
176
 
 
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.
186
 
 
187
 
1.2.  Time Definitions
188
 
 
189
 
   In this document, we will be using a number of time-related terms.
190
 
   The following definitions apply:
191
 
 
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.
196
 
 
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.
204
 
 
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.
211
 
 
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.
216
 
 
217
 
 
218
 
 
219
 
 
220
 
 
221
 
 
222
 
 
223
 
 
224
 
 
225
 
 
226
 
Kolkman & Gieben             Informational                      [Page 4]
227
 
 
228
 
RFC 4641              DNSSEC Operational Practices        September 2006
229
 
 
230
 
 
231
 
2.  Keeping the Chain of Trust Intact
232
 
 
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.
239
 
 
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.
244
 
 
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.
255
 
 
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.
262
 
 
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.
273
 
 
274
 
 
275
 
 
276
 
 
277
 
 
278
 
 
279
 
 
280
 
 
281
 
 
282
 
Kolkman & Gieben             Informational                      [Page 5]
283
 
 
284
 
RFC 4641              DNSSEC Operational Practices        September 2006
285
 
 
286
 
 
287
 
3.  Keys Generation and Storage
288
 
 
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.
292
 
 
293
 
3.1.  Zone and Key Signing Keys
294
 
 
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.
301
 
 
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.
312
 
 
313
 
3.1.1.  Motivations for the KSK and ZSK Separation
314
 
 
315
 
   Differentiating between the KSK and ZSK functions has several
316
 
   advantages:
317
 
 
318
 
   o  No parent/child interaction is required when ZSKs are updated.
319
 
 
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.
325
 
 
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.
329
 
 
330
 
   o  A KSK can have a longer key effectivity period.
331
 
 
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
335
 
 
336
 
 
337
 
 
338
 
Kolkman & Gieben             Informational                      [Page 6]
339
 
 
340
 
RFC 4641              DNSSEC Operational Practices        September 2006
341
 
 
342
 
 
343
 
   compromised, it can be simply dropped from the key set.  The new key
344
 
   set is then re-signed with the KSK.
345
 
 
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.
350
 
 
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.
355
 
 
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.
366
 
 
367
 
3.1.2.  KSKs for High-Level Zones
368
 
 
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.
376
 
 
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.
385
 
 
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.
390
 
 
391
 
 
392
 
 
393
 
 
394
 
Kolkman & Gieben             Informational                      [Page 7]
395
 
 
396
 
RFC 4641              DNSSEC Operational Practices        September 2006
397
 
 
398
 
 
399
 
3.2.  Key Generation
400
 
 
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.
409
 
 
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.
416
 
 
417
 
3.3.  Key Effectivity Period
418
 
 
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.
426
 
 
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.
431
 
 
432
 
   For key sizes that match these effectivity periods, see Section 3.5.
433
 
 
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.
442
 
 
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.
446
 
 
447
 
 
448
 
 
449
 
 
450
 
Kolkman & Gieben             Informational                      [Page 8]
451
 
 
452
 
RFC 4641              DNSSEC Operational Practices        September 2006
453
 
 
454
 
 
455
 
3.4.  Key Algorithm
456
 
 
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.
461
 
 
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.
464
 
 
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].
469
 
 
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.
474
 
 
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.
481
 
 
482
 
3.5.  Key Sizes
483
 
 
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.
493
 
 
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:
497
 
 
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
502
 
 
503
 
 
504
 
 
505
 
 
506
 
Kolkman & Gieben             Informational                      [Page 9]
507
 
 
508
 
RFC 4641              DNSSEC Operational Practices        September 2006
509
 
 
510
 
 
511
 
         security of the system and then take the logarithm base two of
512
 
         that number.  Call that logarithm value "n".
513
 
 
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.
517
 
 
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):
521
 
 
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
 
      +-------------+-----------+--------------+
537
 
 
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.
544
 
 
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.
550
 
 
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.
556
 
 
557
 
 
558
 
 
559
 
 
560
 
 
561
 
 
562
 
Kolkman & Gieben             Informational                     [Page 10]
563
 
 
564
 
RFC 4641              DNSSEC Operational Practices        September 2006
565
 
 
566
 
 
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.
572
 
 
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.
578
 
 
579
 
3.6.  Private Key Storage
580
 
 
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.
587
 
 
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.
599
 
 
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.
608
 
 
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.
613
 
 
614
 
 
615
 
 
616
 
 
617
 
 
618
 
Kolkman & Gieben             Informational                     [Page 11]
619
 
 
620
 
RFC 4641              DNSSEC Operational Practices        September 2006
621
 
 
622
 
 
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.
626
 
 
627
 
4.  Signature Generation, Key Rollover, and Related Policies
628
 
 
629
 
4.1.  Time in DNSSEC
630
 
 
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.
641
 
 
642
 
4.1.1.  Time Considerations
643
 
 
644
 
   Because of the expiration of signatures, one should consider the
645
 
   following:
646
 
 
647
 
   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
648
 
      of your signature validity period.
649
 
 
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.
659
 
 
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.
663
 
 
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.
667
 
 
668
 
 
669
 
 
670
 
 
671
 
 
672
 
 
673
 
 
674
 
Kolkman & Gieben             Informational                     [Page 12]
675
 
 
676
 
RFC 4641              DNSSEC Operational Practices        September 2006
677
 
 
678
 
 
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.
683
 
 
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:
689
 
 
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.
696
 
 
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.
701
 
 
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.
705
 
 
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.
709
 
 
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.
719
 
 
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
727
 
 
728
 
 
729
 
 
730
 
Kolkman & Gieben             Informational                     [Page 13]
731
 
 
732
 
RFC 4641              DNSSEC Operational Practices        September 2006
733
 
 
734
 
 
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.
740
 
 
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.
748
 
 
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.
755
 
 
756
 
4.2.  Key Rollovers
757
 
 
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.
766
 
 
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".
774
 
 
775
 
4.2.1.  Zone Signing Key Rollovers
776
 
 
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
781
 
 
782
 
 
783
 
 
784
 
 
785
 
 
786
 
Kolkman & Gieben             Informational                     [Page 14]
787
 
 
788
 
RFC 4641              DNSSEC Operational Practices        September 2006
789
 
 
790
 
 
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.
794
 
 
795
 
4.2.1.1.  Pre-Publish Key Rollover
796
 
 
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.
806
 
 
807
 
   Pre-publish key rollover involves four stages as follows:
808
 
 
809
 
      ----------------------------------------------------------------
810
 
      initial         new DNSKEY       new RRSIGs      DNSKEY removal
811
 
      ----------------------------------------------------------------
812
 
      SOA0            SOA1             SOA2            SOA3
813
 
      RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
814
 
 
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
 
      ----------------------------------------------------------------
821
 
 
822
 
                         Pre-Publish Key Rollover
823
 
 
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.
827
 
 
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.
834
 
 
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
839
 
 
840
 
 
841
 
 
842
 
Kolkman & Gieben             Informational                     [Page 15]
843
 
 
844
 
RFC 4641              DNSSEC Operational Practices        September 2006
845
 
 
846
 
 
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.
855
 
 
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.
859
 
 
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)":
865
 
 
866
 
      ----------------------------------------------------------------
867
 
      initial             new RRSIGs          new DNSKEY
868
 
      ----------------------------------------------------------------
869
 
      SOA0                SOA1                SOA2
870
 
      RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
871
 
 
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
 
      ----------------------------------------------------------------
878
 
 
879
 
      ----------------------------------------------------------------
880
 
      new RRSIGs (II)     new DNSKEY (II)
881
 
      ----------------------------------------------------------------
882
 
      SOA3                SOA4
883
 
      RRSIG12(SOA3)       RRSIG12(SOA4)
884
 
 
885
 
      DNSKEY1             DNSKEY1
886
 
      DNSKEY11            DNSKEY12
887
 
      DNSKEY12            DNSKEY13
888
 
      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
889
 
      RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
890
 
      ----------------------------------------------------------------
891
 
 
892
 
              Pre-Publish Key Rollover, Showing Two Rollovers
893
 
 
894
 
 
895
 
 
896
 
 
897
 
 
898
 
Kolkman & Gieben             Informational                     [Page 16]
899
 
 
900
 
RFC 4641              DNSSEC Operational Practices        September 2006
901
 
 
902
 
 
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.
907
 
 
908
 
4.2.1.2.  Double Signature Zone Signing Key Rollover
909
 
 
910
 
   This section shows how to perform a ZSK key rollover using the double
911
 
   zone data signature scheme, aptly named "double signature rollover".
912
 
 
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.
917
 
 
918
 
   Double signature ZSK rollover involves three stages as follows:
919
 
 
920
 
      ----------------------------------------------------------------
921
 
      initial             new DNSKEY         DNSKEY removal
922
 
      ----------------------------------------------------------------
923
 
      SOA0                SOA1               SOA2
924
 
      RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
925
 
      RRSIG11(SOA1)
926
 
 
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
 
      ----------------------------------------------------------------
934
 
 
935
 
                Double Signature Zone Signing Key Rollover
936
 
 
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.
940
 
 
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.
947
 
 
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.
951
 
 
952
 
 
953
 
 
954
 
Kolkman & Gieben             Informational                     [Page 17]
955
 
 
956
 
RFC 4641              DNSSEC Operational Practices        September 2006
957
 
 
958
 
 
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.
965
 
 
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.
971
 
 
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.
975
 
 
976
 
4.2.1.3.  Pros and Cons of the Schemes
977
 
 
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.
985
 
 
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.
990
 
 
991
 
4.2.2.  Key Signing Key Rollovers
992
 
 
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.
999
 
 
1000
 
 
1001
 
 
1002
 
 
1003
 
 
1004
 
 
1005
 
 
1006
 
 
1007
 
 
1008
 
 
1009
 
 
1010
 
Kolkman & Gieben             Informational                     [Page 18]
1011
 
 
1012
 
RFC 4641              DNSSEC Operational Practices        September 2006
1013
 
 
1014
 
 
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)    -------->
1023
 
 
1024
 
 
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
 
   --------------------------------------------------------------------
1036
 
 
1037
 
   Stages of Deployment for a Double Signature Key Signing Key Rollover
1038
 
 
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.
1043
 
 
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.
1051
 
 
1052
 
   DS change: The parent replaces DS1 with DS2.
1053
 
 
1054
 
   DNSKEY removal: DNSKEY1 has been removed.
1055
 
 
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
1063
 
 
1064
 
 
1065
 
 
1066
 
Kolkman & Gieben             Informational                     [Page 19]
1067
 
 
1068
 
RFC 4641              DNSSEC Operational Practices        September 2006
1069
 
 
1070
 
 
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.
1074
 
 
1075
 
4.2.3.  Difference Between ZSK and KSK Rollovers
1076
 
 
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.
1081
 
 
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).
1084
 
 
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.
1092
 
 
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)
1102
 
 
1103
 
 
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
 
   --------------------------------------------------------------------
1114
 
 
1115
 
      Stages of Deployment for a Pre-Publish Key Signing Key Rollover
1116
 
 
1117
 
 
1118
 
 
1119
 
 
1120
 
 
1121
 
 
1122
 
Kolkman & Gieben             Informational                     [Page 20]
1123
 
 
1124
 
RFC 4641              DNSSEC Operational Practices        September 2006
1125
 
 
1126
 
 
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.
1135
 
 
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.
1142
 
 
1143
 
4.2.4.  Automated Key Rollovers
1144
 
 
1145
 
   As keys must be renewed periodically, there is some motivation to
1146
 
   automate the rollover process.  Consider the following:
1147
 
 
1148
 
   o  ZSK rollovers are easy to automate as only the child zone is
1149
 
      involved.
1150
 
 
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.
1155
 
 
1156
 
4.3.  Planning for Emergency Key Rollover
1157
 
 
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.
1161
 
 
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
1165
 
 
1166
 
   o  as long as a signature over the compromised key in the trust chain
1167
 
      is valid,
1168
 
 
1169
 
   o  as long as a parental DS RR (and signature) points to the
1170
 
      compromised key,
1171
 
 
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).
1175
 
 
1176
 
 
1177
 
 
1178
 
Kolkman & Gieben             Informational                     [Page 21]
1179
 
 
1180
 
RFC 4641              DNSSEC Operational Practices        September 2006
1181
 
 
1182
 
 
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.
1192
 
 
1193
 
4.3.1.  KSK Compromise
1194
 
 
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.
1198
 
 
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.
1201
 
 
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).
1210
 
 
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.
1217
 
 
1218
 
4.3.1.1.  Keeping the Chain of Trust Intact
1219
 
 
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.
1226
 
 
1227
 
   The procedure is as follows:
1228
 
 
1229
 
   1.  Introduce a new KSK into the key set, keep the compromised KSK in
1230
 
       the key set.
1231
 
 
1232
 
 
1233
 
 
1234
 
Kolkman & Gieben             Informational                     [Page 22]
1235
 
 
1236
 
RFC 4641              DNSSEC Operational Practices        September 2006
1237
 
 
1238
 
 
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.
1242
 
 
1243
 
   3.  Upload the DS for this new key to the parent.
1244
 
 
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.
1249
 
 
1250
 
   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
1251
 
       key set using your "normal" validity interval.
1252
 
 
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.
1258
 
 
1259
 
   Note that this is only a problem when the DNSKEY and or DS records
1260
 
   are used for authentication at the parent.
1261
 
 
1262
 
4.3.1.2.  Breaking the Chain of Trust
1263
 
 
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.
1268
 
 
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.
1274
 
 
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.
1278
 
 
1279
 
4.3.2.  ZSK Compromise
1280
 
 
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
1287
 
 
1288
 
 
1289
 
 
1290
 
Kolkman & Gieben             Informational                     [Page 23]
1291
 
 
1292
 
RFC 4641              DNSSEC Operational Practices        September 2006
1293
 
 
1294
 
 
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.
1299
 
 
1300
 
4.3.3.  Compromises of Keys Anchored in Resolvers
1301
 
 
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.
1305
 
 
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.
1311
 
 
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].
1316
 
 
1317
 
4.4.  Parental Policies
1318
 
 
1319
 
4.4.1.  Initial Key Exchanges and Parental Policies Considerations
1320
 
 
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.
1329
 
 
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.
1339
 
 
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.
1343
 
 
1344
 
 
1345
 
 
1346
 
Kolkman & Gieben             Informational                     [Page 24]
1347
 
 
1348
 
RFC 4641              DNSSEC Operational Practices        September 2006
1349
 
 
1350
 
 
1351
 
4.4.2.  Storing Keys or Hashes?
1352
 
 
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.
1359
 
 
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.
1367
 
 
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.
1375
 
 
1376
 
4.4.3.  Security Lameness
1377
 
 
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.
1381
 
 
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.
1387
 
 
1388
 
   Child zones should be very careful in removing DNSKEY material,
1389
 
   specifically SEP keys, for which a DS RR exists.
1390
 
 
1391
 
   Once a zone is "security lame", a fix (e.g., removing a DS RR) will
1392
 
   take time to propagate through the DNS.
1393
 
 
1394
 
 
1395
 
 
1396
 
 
1397
 
 
1398
 
 
1399
 
 
1400
 
 
1401
 
 
1402
 
Kolkman & Gieben             Informational                     [Page 25]
1403
 
 
1404
 
RFC 4641              DNSSEC Operational Practices        September 2006
1405
 
 
1406
 
 
1407
 
4.4.4.  DS Signature Validity Period
1408
 
 
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.
1419
 
 
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.
1426
 
 
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.
1430
 
 
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.
1439
 
 
1440
 
5.  Security Considerations
1441
 
 
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.
1447
 
 
1448
 
6.  Acknowledgments
1449
 
 
1450
 
   Most of the ideas in this document were the result of collective
1451
 
   efforts during workshops, discussions, and tryouts.
1452
 
 
1453
 
   At the risk of forgetting individuals who were the original
1454
 
   contributors of the ideas, we would like to acknowledge people who
1455
 
 
1456
 
 
1457
 
 
1458
 
Kolkman & Gieben             Informational                     [Page 26]
1459
 
 
1460
 
RFC 4641              DNSSEC Operational Practices        September 2006
1461
 
 
1462
 
 
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.
1468
 
 
1469
 
   Some material in this document has been copied from RFC 2541 [12].
1470
 
 
1471
 
   Mike StJohns designed the key exchange between parent and child
1472
 
   mentioned in the last paragraph of Section 4.2.2
1473
 
 
1474
 
   Section 4.2.4 was supplied by G. Guette and O. Courtay.
1475
 
 
1476
 
   Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of
1477
 
   the spelling and style issues.
1478
 
 
1479
 
   Kolkman and Gieben take the blame for introducing all miscakes (sic).
1480
 
 
1481
 
   While working on this document, Kolkman was employed by the RIPE NCC
1482
 
   and Gieben was employed by NLnet Labs.
1483
 
 
1484
 
7.  References
1485
 
 
1486
 
7.1.  Normative References
1487
 
 
1488
 
   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
1489
 
         13, RFC 1034, November 1987.
1490
 
 
1491
 
   [2]   Mockapetris, P., "Domain names - implementation and
1492
 
         specification", STD 13, RFC 1035, November 1987.
1493
 
 
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.
1497
 
 
1498
 
   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
1499
 
         "DNS Security Introduction and Requirements", RFC 4033, March
1500
 
         2005.
1501
 
 
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.
1505
 
 
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.
1509
 
 
1510
 
 
1511
 
 
1512
 
 
1513
 
 
1514
 
Kolkman & Gieben             Informational                     [Page 27]
1515
 
 
1516
 
RFC 4641              DNSSEC Operational Practices        September 2006
1517
 
 
1518
 
 
1519
 
7.2.  Informative References
1520
 
 
1521
 
   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
1522
 
         Levels", BCP 14, RFC 2119, March 1997.
1523
 
 
1524
 
   [8]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
1525
 
         1996.
1526
 
 
1527
 
   [9]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
1528
 
         (DNS NOTIFY)", RFC 1996, August 1996.
1529
 
 
1530
 
   [10]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
1531
 
         Update", RFC 3007, November 2000.
1532
 
 
1533
 
   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
1534
 
         RFC 2308, March 1998.
1535
 
 
1536
 
   [12]  Eastlake, D., "DNS Security Operational Considerations", RFC
1537
 
         2541, March 1999.
1538
 
 
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.
1542
 
 
1543
 
   [14]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
1544
 
         Requirements for Security", BCP 106, RFC 4086, June 2005.
1545
 
 
1546
 
   [15]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
1547
 
         Mapping for the Extensible Provisioning Protocol (EPP)", RFC
1548
 
         4310, December 2005.
1549
 
 
1550
 
   [16]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1551
 
         Sizes", The Journal of Cryptology 14 (255-293), 2001.
1552
 
 
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.
1557
 
 
1558
 
   [18]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
1559
 
 
1560
 
   [19]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
1561
 
         Records in DNSSEC", Work in Progress, January 2006.
1562
 
 
1563
 
   [20]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
1564
 
         Resource Records (RRs)", RFC 4509, May 2006.
1565
 
 
1566
 
 
1567
 
 
1568
 
 
1569
 
 
1570
 
Kolkman & Gieben             Informational                     [Page 28]
1571
 
 
1572
 
RFC 4641              DNSSEC Operational Practices        September 2006
1573
 
 
1574
 
 
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.
1578
 
 
1579
 
 
1580
 
 
1581
 
 
1582
 
 
1583
 
 
1584
 
 
1585
 
 
1586
 
 
1587
 
 
1588
 
 
1589
 
 
1590
 
 
1591
 
 
1592
 
 
1593
 
 
1594
 
 
1595
 
 
1596
 
 
1597
 
 
1598
 
 
1599
 
 
1600
 
 
1601
 
 
1602
 
 
1603
 
 
1604
 
 
1605
 
 
1606
 
 
1607
 
 
1608
 
 
1609
 
 
1610
 
 
1611
 
 
1612
 
 
1613
 
 
1614
 
 
1615
 
 
1616
 
 
1617
 
 
1618
 
 
1619
 
 
1620
 
 
1621
 
 
1622
 
 
1623
 
 
1624
 
 
1625
 
 
1626
 
Kolkman & Gieben             Informational                     [Page 29]
1627
 
 
1628
 
RFC 4641              DNSSEC Operational Practices        September 2006
1629
 
 
1630
 
 
1631
 
Appendix A.  Terminology
1632
 
 
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.
1638
 
 
1639
 
   Anchored key: A DNSKEY configured in resolvers around the globe.
1640
 
      This key is hard to update, hence the term anchored.
1641
 
 
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.
1645
 
 
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.
1649
 
 
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.
1654
 
 
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.
1661
 
 
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.
1665
 
 
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.
1670
 
 
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.
1676
 
 
1677
 
 
1678
 
 
1679
 
 
1680
 
 
1681
 
 
1682
 
Kolkman & Gieben             Informational                     [Page 30]
1683
 
 
1684
 
RFC 4641              DNSSEC Operational Practices        September 2006
1685
 
 
1686
 
 
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.
1690
 
 
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.
1695
 
 
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.
1699
 
 
1700
 
   Zone administrator: The 'role' that is responsible for signing a zone
1701
 
      and publishing it on the primary authoritative server.
1702
 
 
1703
 
Appendix B.  Zone Signing Key Rollover How-To
1704
 
 
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".
1708
 
 
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.
1716
 
 
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.
1721
 
 
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".
1725
 
 
1726
 
   Step 3: It is safe to engage in a new rollover (Step 1) after at
1727
 
      least one signature validity period.
1728
 
 
1729
 
 
1730
 
 
1731
 
 
1732
 
 
1733
 
 
1734
 
 
1735
 
 
1736
 
 
1737
 
 
1738
 
Kolkman & Gieben             Informational                     [Page 31]
1739
 
 
1740
 
RFC 4641              DNSSEC Operational Practices        September 2006
1741
 
 
1742
 
 
1743
 
Appendix C.  Typographic Conventions
1744
 
 
1745
 
   The following typographic conventions are used in this document:
1746
 
 
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.
1749
 
 
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".
1756
 
 
1757
 
   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
1758
 
   means that RRSet is signed with DNSKEYx.
1759
 
 
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"
1763
 
 
1764
 
   SOA representation: SOAs are represented as SOAx, where x is the
1765
 
   serial number.
1766
 
 
1767
 
   Using this notation the following signed zone:
1768
 
 
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... )
1790
 
 
1791
 
 
1792
 
 
1793
 
 
1794
 
Kolkman & Gieben             Informational                     [Page 32]
1795
 
 
1796
 
RFC 4641              DNSSEC Operational Practices        September 2006
1797
 
 
1798
 
 
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
 
                     ...
1814
 
 
1815
 
   is reduced to the following representation:
1816
 
 
1817
 
       SOA2006022100
1818
 
       RRSIG14(SOA2006022100)
1819
 
       DNSKEY14
1820
 
       DNSKEY15
1821
 
 
1822
 
       RRSIG14(KEY)
1823
 
       RRSIG15(KEY)
1824
 
 
1825
 
   The rest of the zone data has the same signature as the SOA record,
1826
 
   i.e., an RRSIG created with DNSKEY 14.
1827
 
 
1828
 
 
1829
 
 
1830
 
 
1831
 
 
1832
 
 
1833
 
 
1834
 
 
1835
 
 
1836
 
 
1837
 
 
1838
 
 
1839
 
 
1840
 
 
1841
 
 
1842
 
 
1843
 
 
1844
 
 
1845
 
 
1846
 
 
1847
 
 
1848
 
 
1849
 
 
1850
 
Kolkman & Gieben             Informational                     [Page 33]
1851
 
 
1852
 
RFC 4641              DNSSEC Operational Practices        September 2006
1853
 
 
1854
 
 
1855
 
Authors' Addresses
1856
 
 
1857
 
   Olaf M. Kolkman
1858
 
   NLnet Labs
1859
 
   Kruislaan 419
1860
 
   Amsterdam  1098 VA
1861
 
   The Netherlands
1862
 
 
1863
 
   EMail: olaf@nlnetlabs.nl
1864
 
   URI:   http://www.nlnetlabs.nl
1865
 
 
1866
 
 
1867
 
   R. (Miek) Gieben
1868
 
 
1869
 
   EMail: miek@miek.nl
1870
 
 
1871
 
 
1872
 
 
1873
 
 
1874
 
 
1875
 
 
1876
 
 
1877
 
 
1878
 
 
1879
 
 
1880
 
 
1881
 
 
1882
 
 
1883
 
 
1884
 
 
1885
 
 
1886
 
 
1887
 
 
1888
 
 
1889
 
 
1890
 
 
1891
 
 
1892
 
 
1893
 
 
1894
 
 
1895
 
 
1896
 
 
1897
 
 
1898
 
 
1899
 
 
1900
 
 
1901
 
 
1902
 
 
1903
 
 
1904
 
 
1905
 
 
1906
 
Kolkman & Gieben             Informational                     [Page 34]
1907
 
 
1908
 
RFC 4641              DNSSEC Operational Practices        September 2006
1909
 
 
1910
 
 
1911
 
Full Copyright Statement
1912
 
 
1913
 
   Copyright (C) The Internet Society (2006).
1914
 
 
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.
1918
 
 
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.
1926
 
 
1927
 
Intellectual Property
1928
 
 
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.
1937
 
 
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.
1944
 
 
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.
1950
 
 
1951
 
Acknowledgement
1952
 
 
1953
 
   Funding for the RFC Editor function is provided by the IETF
1954
 
   Administrative Support Activity (IASA).
1955
 
 
1956
 
 
1957
 
 
1958
 
 
1959
 
 
1960
 
 
1961
 
 
1962
 
Kolkman & Gieben             Informational                     [Page 35]
1963