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