1ods-kasp(5) OpenDNSSEC KASP ods-kasp(5)
2
6 ods-kasp - OpenDNSSEC kasp specification
7
9 /etc/opendnssec/kasp.xml
10
12 The kasp file describes the parameters of the DNSSEC Key and Signing
13 Policy (KASP), the policy used to sign zones. Each policy comprises a
14 series of parameters that define the way the zone is signed.
15 KASP Parameters
17 A policy has a set of common parameters to identify the policy.
18 Policy Name
20 The name is used to link a policy to a zone that needs to be
21 signed. Each policy must have a unique name. The policy named
22 "default" is special, as it is associated with all zones that do
23 not have a policy explicitly associated with them.
24 Policy Description
26 A policy can have a description associated with it.
27 Signatures Parameters
29 This section lists the parameters for the signatures created
30 using the policy.
31 Signature Resign Interval
33 This is the interval between runs of the signer. For example, a
34 zone that has a Re-sign Interval of PT2H (2 hours) is handled by
35 the signer every 2 hours.
36 Signature Refresh Interval
38 The Refresh Interval is describing when a signature should be
39 refreshed. As signatures are typically valid for much longer
40 than the interval between runs of the signer, there is no need
41 to regenerate the signatures each time the signer is running.
42 This means that the Re-sign Interval must be smaller than the
43 Refresh Interval. In order to make refreshing signatures possi‐
44 ble, the Re-sign Interval should be at least half of the Refresh
45 Interval. In the case a signer runs and detects that there is no
46 change to the data being signed, signatures may be refreshed. A
47 signature will be refreshed when the time until the signature
48 expiration is closer than the Refresh Interval.
49 Signature Validity
51 The Signature Validity describes how long the signatures are
52 valid for. This parameter groups two elements of information.
53 The Default Signature Validity is the validity interval for all
54 RRSIG records except those related to NSEC or NSEC3 records. For
55 these records, the validity period is given by the value of the
56 Denial Signature Validity.
57 Signature Jitter
59 The Signature Jitter (j) is the value added to or subtracted
60 from the expiration time of signatures to ensure that not all
61 signatures expire at the same time. The actual value of the
62 jitter is a random value, uniformly ranging between Minus Signa‐
63 ture Jitter and Signature Jitter [-j...j]. This value is added
64 to Signature Validity to determine the signature expiration
65 time.
66 Signature Inception Offset
68 This is a duration subtracted from the time at which a record is
69 signed to give the inception time of the RRSIG record. This is
70 required to allow for clock skew between the signing system and
71 the system on which the signature is checked. Without it, the
72 possibility exists that the checking system could retrieve a
73 signature whose start time is later than the current time. The
74 relationship between these elements is shown below in Figure 1.
75 Inception Signing Expi‐
77 ration
78 time time
79 time
80 | | | |
81 |
82 |---------------------|---------------------------|.......|.......|
83 | | | |
84 |
85 [ +/-
86 Jitter ]
87 | Inception offset | |
89 |<------------------->| Validity Interval |
90 | |<--------------------------------->|
91 Inception Signing reuse reuse new Expi‐
94 ration
95 time time signature
96 time
97 | | | | | |
98 |---------------------|-----------------------------------|
99 | | | | | |
100 <-----> <-----> <----->
101 Re-sign Interval
102 |Refresh Interval|
104 |<-------------->|
105 | |
106 Figure 1: Signature Timing Parameters
109 Authenticated Denial of Existence Parameters
112 Authenticated denial of existence - proving that domain names do
113 not exist in the zone - is discussed in this section. Below,
114 the list of the parameters is given for creating NSEC or NSEC3
115 records using the policy.
116 NSEC or NSEC3
118 If the NSEC scheme is used to implement authenticated denial of
119 existence, there are no record elements we can tune. If NSEC3
120 [RFC5155] is used, there are some more options.
121 NSEC3 Opt-Out
123 Whether to enable or disable "opt-out". This is an optimisation
124 that means that NSEC3 records are only created for authoritative
125 data or for secure delegations; insecure delegations have no
126 NSEC3 records. For zones where a majority of the entries are
127 delegations that are not signed - typically TLDs during the
128 take-up phase of DNSSEC - this reduces the number of DNSSEC
129 records in the zone.
130 NSEC3 Re-salt Interval
132 The is the interval between generating new salt values for the
133 hashing algorithm.
134 NSEC3 Hash Parameters
136 The NSEC3 Hash Parameters tells parameters related to NSEC3.
137 NSEC3 Hash Algorithm
139 The NSEC3 Hash Algorithm tells what hashing algorithm should be
140 used to create the NSEC3 records.
141 NSEC3 Hash Iterations
143 The NSEC3 Hash Iterations shows how many iterations of the hash
144 function should be performed over the original owner name.
145 NSEC3 Hash Salt Length
147 The NSEC3 Hash Salt Length provides the length of the salt value
148 to be generated.
149 Key Parameters
151 This section covers parameters related to keys. There are a
152 number of parameters relating to both zone-signing keys (ZSK)
153 and key-signing keys (KSK).
154 DNSKEY TTL
156 This is the time-to-live value for the DNSKEY resource records.
157 Key Retire Safety
159 The Key Retire Safety is the retire safety margin for the keys.
160 This interval is a safety margin added to calculated timing val‐
161 ues to ensure that keys are retired without there being a chance
162 of signatures created with the keys being considered invalid.
163 Key Publish Safety
165 The Key Publish is the publish safety margins for the keys. This
166 interval is the safety margin added to calculated timing values
167 to ensure that keys are published and without there being a
168 chance of signatures created with the keys being considered
169 invalid.
170 Key Sharing
172 If multiple zones are associated with a policy, a key may be
173 shared between zones. For example, if you have 100 zones then
174 you will only use one set of keys instead of 100 sets. This
175 will safe space in your HSM.
176 Key Purging Interval
178 Key Purging is the event where keys marked as dead (as defined
179 by draft-ietf-dnsop-dnssec- key-timing [key-timing]) will be
180 automatically purged from the key database. The Key Purging
181 Interval is the interval of when Key Purging is done.
182 KSK Parameters
184 There are parameters specific for the KSK.
185 KSK Algorithm
187 The KSK Algorithm determines the algorithm used for KSKs.
188 KSK Lifetime
190 The KSK Lifetime determines how long the KSK is used for before
191 it is must be rolled.
192 KSK Repository
194 The KSK Repository determines the location of the KSKs.
195 Manual KSK Rollover
197 It may be desirable to force that a key rollover will only be
198 initiated on the command by the operator. Note that if KSK
199 rollover is done automatically, there is currently still a step
200 for the KSK that needs manual intervention, where the corre‐
201 sponding DS record for the key needs to be published to the par‐
202 ent before the rollover is completed.
203 ZSK Parameters
205 The same parameters for the KSK are available for the ZSK. The
206 split between the series of parameters is that with a ZSK/KSK
207 Split Signing Scheme, the values for the parameters may be dif‐
208 ferent.
209 ZSK Algorithm
211 The ZSK Algorithm determines the algorithm used for ZSKs.
212 ZSK Lifetime
214 The ZSK Lifetime determines how long the ZSK is used for before
215 it is must be rolled.
216 ZSK Repository
218 The ZSK Repository determines the location of the ZSKs.
219 Manual ZSK Rollover
221 The ZSK rollover will be fully automatic if Manual ZSK Rollover
222 is disabled.
223 Zone Parameters
225 General information concerning the zones is described here.
226 Propagation Delay
228 The Propagation Delay is the amount of time needed for informa‐
229 tion changes at the master server for the zone to work its way
230 through to all the secondary nameservers.
231 SOA Parameters
233 These parameters are necessary for maintaining the SOA record in
234 the signed zone. These values will override values set for the
235 SOA record in the input zone.
236 SOA TTL
238 This is the time-to-live of the SOA record.
239 SOA MINIUM
241 This is value for the MINIMUM RDATA element in the SOA record.
242 SOA Serial
244 This represents the format of the serial number in the signed
245 zone. This is one of the following:
246 counter: Use an increasing counter (but use the serial from
247 the unsigned zone
248 if possible).
249 datecounter: Use increasing counter in YYYYMMDDxx format (xx
251 is the number of
252 increments within each day, starting at 00).
253 unixtime: The serial number is set to the "Unix time" (sec‐
255 onds since 00:00 on
256 1 January 1970 (UTC)) at which the signer is run.
257 keep: Keep the serial from the unsigned zone (do not re-sign
259 unless it has been
260 incremented). This way, no signed zone is created
261 unless the zone operator
262 explicitly initiated a zone update.
263 Parent Zone Parameters
265 If a DNSSEC zone is in a chain of trust, digest information
266 about the KSKs used in the zone will be stored in DS records in
267 the parent zone. To properly roll keys, timing information about
268 the parent zone must be configured.
269 Propagation Delay
271 The Propagation Delay parameter related to the parent zone is
272 the interval between the time a new KSK is published in the zone
273 and the time that the DS record appears in the parent zone. In
274 reality, this is a variable value. The value for the Propagation
275 Delay in the policy should be a estimate.
276 DS TTL This represents the DS time-to-live. The DS TTL should be set to
278 the TTL of the DS record in the parent zone.
279 SOA Parameters
281 The SOA Parameters related to the parent zone gives information
282 about the parent's SOA record. These are necessary to calculate
283 the timings in particular rollover scenarios.
284 SOA TTL
286 This should be set to the time-to-live of the parent zone SOA
287 record.
288 SOA MINIUM
290 This should be set to the value of the MINIMUM RDATA element in
291 the parent zone SOA record.
292
295 ods-control(8), ods-enforcerd(8), ods-enforcer(8), ods-signerd(8),
296 pds-signer(8), ods-ksmutil(1), ods-kaspcheck(1), ods-timing(5),
297 ods-hsmutil(1), ods-hsmspeed(1), opendnssec(7), ISO 8601,
298 http://www.opendnssec.org/
299
301 OpenDNSSEC was written by NLnet Labs as part of the OpenDNSSEC project.
302 http://www.opendnssec.org/
303OpenDNSSEC April 2016 ods-kasp(5)