1 Internet Engineering Task Force (IETF) O. Gudmundsson
2 Request for Comments: 8078 CloudFlare
3 Updates: 7344 P. Wouters
4 Category: Standards Track Red Hat
5 ISSN: 2070-1721 March 2017
6
7
8 Managing DS Records from the Parent via CDS/CDNSKEY
9
10 Abstract
11
12 RFC 7344 specifies how DNS trust can be maintained across key
13 rollovers in-band between parent and child. This document elevates
14 RFC 7344 from Informational to Standards Track. It also adds a
15 method for initial trust setup and removal of a secure entry point.
16
17 Changing a domain's DNSSEC status can be a complicated matter
18 involving multiple unrelated parties. Some of these parties, such as
19 the DNS operator, might not even be known by all the organizations
20 involved. The inability to disable DNSSEC via in-band signaling is
21 seen as a problem or liability that prevents some DNSSEC adoption at
22 a large scale. This document adds a method for in-band signaling of
23 these DNSSEC status changes.
24
25 This document describes reasonable policies to ease deployment of the
26 initial acceptance of new secure entry points (DS records).
27
28 It is preferable that operators collaborate on the transfer or move
29 of a domain. The best method is to perform a Key Signing Key (KSK)
30 plus Zone Signing Key (ZSK) rollover. If that is not possible, the
31 method using an unsigned intermediate state described in this
32 document can be used to move the domain between two parties. This
33 leaves the domain temporarily unsigned and vulnerable to DNS
34 spoofing, but that is preferred over the alternative of validation
35 failures due to a mismatched DS and DNSKEY record.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Gudmundsson & Wouters Standards Track [Page 1]
53 RFC 8078 Managing DS Records March 2017
54
55
56 Status of This Memo
57
58 This is an Internet Standards Track document.
59
60 This document is a product of the Internet Engineering Task Force
61 (IETF). It represents the consensus of the IETF community. It has
62 received public review and has been approved for publication by the
63 Internet Engineering Steering Group (IESG). Further information on
64 Internet Standards is available in Section 2 of RFC 7841.
65
66 Information about the current status of this document, any errata,
67 and how to provide feedback on it may be obtained at
68 http://www.rfc-editor.org/info/rfc8078.
69
70 Copyright Notice
71
72 Copyright (c) 2017 IETF Trust and the persons identified as the
73 document authors. All rights reserved.
74
75 This document is subject to BCP 78 and the IETF Trust's Legal
76 Provisions Relating to IETF Documents
77 (http://trustee.ietf.org/license-info) in effect on the date of
78 publication of this document. Please review these documents
79 carefully, as they describe your rights and restrictions with respect
80 to this document. Code Components extracted from this document must
81 include Simplified BSD License text as described in Section 4.e of
82 the Trust Legal Provisions and are provided without warranty as
83 described in the Simplified BSD License.
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Gudmundsson & Wouters Standards Track [Page 2]
108 RFC 8078 Managing DS Records March 2017
109
110
111 Table of Contents
112
113 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
114 1.1. Introducing a DS Record . . . . . . . . . . . . . . . . . 3
115 1.2. Removing a DS Record . . . . . . . . . . . . . . . . . . 4
116 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
117 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
118 2. The Three Uses of CDS . . . . . . . . . . . . . . . . . . . . 5
119 2.1. The Meaning of the CDS RRset . . . . . . . . . . . . . . 5
120 3. Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . . 6
121 3.1. Accept Policy via Authenticated Channel . . . . . . . . . 6
122 3.2. Accept with Extra Checks . . . . . . . . . . . . . . . . 6
123 3.3. Accept after Delay . . . . . . . . . . . . . . . . . . . 7
124 3.4. Accept with Challenge . . . . . . . . . . . . . . . . . . 7
125 3.5. Accept from Inception . . . . . . . . . . . . . . . . . . 7
126 4. DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . . 7
127 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
128 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
129 6.1. Promoting RFC 7344 to Standards Track . . . . . . . . . . 9
130 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
131 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
132 7.2. Informative References . . . . . . . . . . . . . . . . . 10
133 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
135
136 1. Introduction
137
138 CDS (Child DS) and CDNSKEY (Child DNSKEY) [RFC7344] records are used
139 to signal changes in secure entry points. This is one method to
140 maintain delegations that can be used when the DNS operator has no
141 other way to inform the parent that changes are needed. This
142 document elevates [RFC7344] from Informational to Standards Track.
143
144 In addition, [RFC7344] lacks two different options for full automated
145 operation to be possible. It does not define a method for the
146 initial trust establishment, leaving it open to each parent to come
147 up with an acceptance policy. Additionally, [RFC7344] does not
148 provide a "delete" signal for the child to inform the parent that the
149 DNSSEC security for its domain must be removed.
150
151 1.1. Introducing a DS Record
152
153 Automated insertion of DS records has been limited for many zones by
154 the requirement that all changes pass through a "Registry" of the
155 child zone's parent. This has significantly hindered deployment of
156 DNSSEC at a large scale for DNS hosters, as the child zone owner is
157 often not aware or able to update DNS records such as the DS record.
158
159
160
161
162 Gudmundsson & Wouters Standards Track [Page 3]
163 RFC 8078 Managing DS Records March 2017
164
165
166 This document describes a few possible methods for the parent to
167 accept a request by the child to add a DS record to its zone. These
168 methods have different security properties that address different
169 deployment scenarios, all resulting in an automated method of trust
170 introduction.
171
172 1.2. Removing a DS Record
173
174 This document introduces the delete option for both CDS and CDNSKEY,
175 allowing a child to signal to the parent to turn off DNSSEC. When a
176 domain is moved from one DNS operator to another, sometimes it is
177 necessary to turn off DNSSEC to facilitate the change of DNS
178 operator. Common scenarios include:
179
180 1. Alternative to doing a proper DNSSEC algorithm rollover due to
181 operational limitations such as software limitations.
182
183 2. Moving from a DNSSEC operator to a non-DNSSEC-capable operator.
184
185 3. Moving to an operator that cannot or does not want to do a proper
186 DNSSEC rollover.
187
188 4. When moving between two DNS operators that use disjoint sets of
189 algorithms to sign the zone, an algorithm rollover cannot be
190 performed.
191
192 5. The domain holder no longer wants DNSSEC enabled.
193
194 The lack of a "remove my DNSSEC" option is cited as a reason why some
195 operators cannot deploy DNSSEC, as this is seen as an operational
196 risk.
197
198 Turning off DNSSEC reduces the security of the domain and thus should
199 only be done carefully, and that decision should be fully under the
200 child domain's control.
201
202 1.3. Notation
203
204 Signaling can happen via CDS or CDNSKEY records. The only
205 differences between the two records are how information is
206 represented and who calculates the DS digest. For clarity, this
207 document uses the term "CDS" to mean "either CDS or CDNSKEY".
208
209 When this document uses the word "parent", it implies an entity that
210 is authorized to insert DS records into the parent zone on behalf of
211 the child domain. Which entity this exactly is does not matter. It
212
213
214
215
216
217 Gudmundsson & Wouters Standards Track [Page 4]
218 RFC 8078 Managing DS Records March 2017
219
220
221 could be the Registrar or Reseller that the child domain was
222 purchased from. It could be the Registry that the domain is
223 registered in when allowed. Or it could be some other entity.
224
225 1.4. Terminology
226
227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
229 document are to be interpreted as described in [RFC2119].
230
231 2. The Three Uses of CDS
232
233 In general, there are three operations that a domain wants to
234 instruct its parent to perform:
235
236 1. Enable DNSSEC validation, i.e., place an initial DS Resource
237 Record Set (RRset) in the parent.
238
239 2. Roll over the KSK. This means updating the DS records in the
240 parent to reflect the new set of KSKs at the child. This could
241 be an ADD operation, a DELETE operation on one or more records
242 while keeping at least one DS RR, or a full REPLACE operation.
243
244 3. Turn off DNSSEC validation, i.e., delete all the DS records.
245
246 KSK rollover is covered in [RFC7344]. It is considered the safest
247 use case of a CDS/CDNSKEY record as it makes no change to the trust
248 relationship between parent and child. Introduction and removal of
249 DS records are defined in this document. As these CDS/CDNSKEY use
250 cases create or end the trust relationship between the parent and
251 child, these use cases should be carefully implemented and monitored.
252
253 2.1. The Meaning of the CDS RRset
254
255 The semantic meaning of publishing a CDS RRset is interpreted to
256 mean:
257
258 Publishing a CDS or CDNSKEY record signals to the parent that the
259 child desires that the corresponding DS records be synchronized.
260 Every parent or parental agent should have an acceptance policy of
261 these records for the three different use cases involved: Initial
262 DS publication, Key rollover, and Returning to Insecure.
263
264 In short, the CDS RRset is an instruction to the parent to modify the
265 DS RRset if the CDS and DS Resets differ.
266
267
268
269
270
271
272 Gudmundsson & Wouters Standards Track [Page 5]
273 RFC 8078 Managing DS Records March 2017
274
275
276 The acceptance policy for CDS in the rollover case is "seeing"
277 according to [RFC7344]. The acceptance policy in the Delete case is
278 seeing a (validly signed) CDS RRset with the delete operation
279 specified in this document.
280
281 3. Enabling DNSSEC via CDS/CDNSKEY
282
283 There are number of different models for managing initial trust, but
284 in the general case, the child wants to enable global validation. As
285 long as the child is insecure, DNS answers can be forged. The goal
286 is to promote the child from insecure to secure as soon as reasonably
287 possible by the parent. This means that the period from the child's
288 publication of CDS/CDNSKEY RRset to the parent publishing the
289 synchronized DS RRset should be as short as possible.
290
291 One important use case is how a third-party DNS operator can upload
292 its DNSSEC information to the parent, so the parent can publish a DS
293 record for the child. In this case, there is a possibility of
294 setting up some kind of authentication mechanism and submission
295 mechanism that is outside the scope of this document.
296
297 Below are some policies that parents can use. These policies assume
298 that the notifications can be verified or authenticated.
299
300 3.1. Accept Policy via Authenticated Channel
301
302 In this case, the parent is notified via authenticated channel UI/API
303 that a CDS/CDNSKEY RRset exists. In the case of a CDS RRset, the
304 parent retrieves the CDS RRset and inserts the corresponding DS RRset
305 as requested. In the case of CDNSKEY, the parent retrieves the
306 CDNSKEY RRset and calculates the DS record(s). Parents may limit the
307 DS record type based on local policy. Parents SHOULD NOT refuse CDS/
308 CDNSKEY updates that do not (yet) have a matching DNSKEY in the child
309 zone. This will allow the child to pre-publish a spare (and
310 potentially offline) DNSKEY.
311
312 3.2. Accept with Extra Checks
313
314 In this case, the parent checks that the source of the notification
315 is allowed to request the DS insertion. The checks could include
316 whether this is a trusted entity, whether the nameservers correspond
317 to the requester, whether there have been any changes in registration
318 in the last few days, etc. The parent can also send a notification
319 requesting a confirmation, for example, by sending email to the
320 registrant requesting a confirmation. The end result is that the CDS
321 RRset is accepted at the end of the checks or when the out-of-band
322 confirmation is received. Any extra checks should have proper rate
323 limiting in place to prevent abuse.
324
325
326
327 Gudmundsson & Wouters Standards Track [Page 6]
328 RFC 8078 Managing DS Records March 2017
329
330
331 3.3. Accept after Delay
332
333 In this case, if the parent deems the request valid, it starts
334 monitoring the CDS RRset at the child nameservers over a period of
335 time to make sure nothing changes. After some time or after a number
336 of checks, preferably from different vantage points in the network,
337 the parent accepts the CDS RRset as a valid signal to update its DS
338 RRset for this child.
339
340 3.4. Accept with Challenge
341
342 In this case, the parent instructs the requester to insert some
343 record into the child domain to prove it has the ability to do so
344 (i.e., it is the operator of the zone). This method imposes a new
345 task on the parent to monitor the child zone to see if the challenge
346 has been added to the zone. The parent should verify that the
347 challenge is published by all the child's nameservers and should test
348 for this challenge from various diverse network locations to increase
349 the security of this method as much as possible.
350
351 3.5. Accept from Inception
352
353 If a parent is adding a new child domain that is not currently
354 delegated at all, it could use the child CDS/CDNSKEY RRset to
355 immediately publish a DS RRset along with the new NS RRset. This
356 would ensure that the new child domain is never active in an insecure
357 state.
358
359 4. DNSSEC Delete Algorithm
360
361 This document defines the previously reserved DNS Security Algorithm
362 Number of value 0 in the context of CDS and CDNSKEY records to mean
363 that the entire DS RRset at the parent must be removed. The value 0
364 remains reserved for the DS and DNSKEY records.
365
366 No DNSSEC validator can treat algorithm 0 as a valid signature
367 algorithm. If a validator sees a DNSKEY or DS record with this
368 algorithm value, it must treat it as unknown. Accordingly, the zone
369 is treated as unsigned unless there are other algorithms present. In
370 general, the value 0 should never be used in the context of DNSKEY
371 and DS records.
372
373 The CERT record [RFC4398] defines the value 0 similarly to mean the
374 algorithm in the CERT record is not defined in DNSSEC.
375
376
377
378
379
380
381
382 Gudmundsson & Wouters Standards Track [Page 7]
383 RFC 8078 Managing DS Records March 2017
384
385
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions). Updating of parent zones is not yet implemented.
386 The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
387 contain the exact fields as shown below.
388
389 CDS 0 0 0 0
390
391 CDNSKEY 0 3 0 0
392
393 The keying material payload is represented by a single 0. This
394 record is signed in the same way as regular CDS/CDNSKEY RRsets are
395 signed.
396
397 Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the
398 DNSKEY algorithm is what signals the DELETE operation, but for
399 clarity, the "0 0 0 0" notation is mandated -- this is not a
400 definition of DS digest algorithm 0. The same argument applies to
401 "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by
402 [RFC4034], Section 2.1.2.
403
404 Once the parent has verified the CDS/CDNSKEY RRset and it has passed
405 other acceptance tests, the parent MUST remove the DS RRset. After
406 waiting a sufficient amount of time -- depending on the parental TTLs
407 -- the child can start the process of turning off DNSSEC.
408
409 5. Security Considerations
410
411 Turning off DNSSEC reduces the security of the domain and thus should
412 only be done as a last resort in preventing DNSSEC validation errors
413 due to mismatched DS and DNSKEY records.
414
415 Users should keep in mind that re-establishing trust in delegation
416 can be hard and takes time. Before deciding to complete the rollover
417 via an unsigned state, all other options should be considered first.
418
419 A parent SHOULD ensure that when it is allowing a child to become
420 securely delegated, it has a reasonable assurance that the CDS/
421 CDNSKEY RRset used to bootstrap the security is visible from a
422 geographically and topologically diverse view. It SHOULD also ensure
423 that the zone validates correctly if the parent publishes the DS
424 record. A parent zone might also consider sending an email to its
425 contact addresses to give the child zone a warning that security will
426 be enabled after a certain amount of wait time -- thus allowing a
427 child administrator to cancel the request.
428
429 This document describes a few possible acceptance criteria for the
430 initial trust establishment. Due to a large variety of legal
431 frameworks surrounding parent domains (Top-Level Domain (TLDs) in
432 particular), this document cannot give a definitive list of valid
433 acceptance criteria. Parental zones should look at the listed
434
435
436
437 Gudmundsson & Wouters Standards Track [Page 8]
438 RFC 8078 Managing DS Records March 2017
439
440
441 methods and pick the most secure method possible within their legal
442 and technical scenario, possibly further securing the acceptance
443 criteria, as long as the deployed method still enables a fully
444 automated method for non-direct parties such as third-party DNS
445 hosters.
446
447 6. IANA Considerations
448
449 IANA has assigned entry number 0 in the "DNS Security Algorithm
450 Numbers" registry as follows:
451
452 +--------+--------------+----------+----------+---------+-----------+
453 | Number | Description | Mnemonic | Zone | Trans. | Reference |
454 | | | | Signing | Sec. | |
455 +--------+--------------+----------+----------+---------+-----------+
456 | 0 | Delete DS | DELETE | N | N | [RFC4034] |
457 | | | | | | [RFC4398] |
458 | | | | | | [RFC8078] |
459 +--------+--------------+----------+----------+---------+-----------+
460
461 6.1. Promoting RFC 7344 to Standards Track
462
463 Experience has shown that CDS and CDNSKEY are useful in the
464 deployment of DNSSEC. [RFC7344] was published as Informational; this
465 document elevates RFC 7344 to Standards Track.
466
467 7. References
468
469 7.1. Normative References
470
471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
472 Requirement Levels", BCP 14, RFC 2119,
473 DOI 10.17487/RFC2119, March 1997,
474 <http://www.rfc-editor.org/info/rfc2119>.
475
476 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
477 Rose, "Resource Records for the DNS Security Extensions",
478 RFC 4034, DOI 10.17487/RFC4034, March 2005,
479 <http://www.rfc-editor.org/info/rfc4034>.
480
481 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
482 DNSSEC Delegation Trust Maintenance", RFC 7344,
483 DOI 10.17487/RFC7344, September 2014,
484 <http://www.rfc-editor.org/info/rfc7344>.
485
486
487
488
489
490
491
492 Gudmundsson & Wouters Standards Track [Page 9]
493 RFC 8078 Managing DS Records March 2017
494
495
496 7.2. Informative References
497
498 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
499 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006,
500 <http://www.rfc-editor.org/info/rfc4398>.
501
502 Acknowledgments
503
504 We thank a number of people that have provided feedback and useful
505 comments including Bob Harold, John Levine, Dan York, Shane Kerr,
506 Jacques Latour, and especially Matthijs Mekking.
507
508 Authors' Addresses
509
510 Olafur Gudmundsson
511 CloudFlare
512
513 Email: olafur+ietf@cloudflare.com
514
515
516 Paul Wouters
517 Red Hat
518
519 Email: pwouters@redhat.com
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Gudmundsson & Wouters Standards Track [Page 10]
548
The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
contain the exact fields as shown below.
CDS 0 0 0 0
CDNSKEY 0 3 0 0
The keying material payload is represented by a single 0. This
record is signed in the same way as regular CDS/CDNSKEY RRsets are
signed.
Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the
DNSKEY algorithm is what signals the DELETE operation, but for
clarity, the "0 0 0 0" notation is mandated -- this is not a
definition of DS digest algorithm 0. The same argument applies to
"CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by
[RFC4034], Section 2.1.2.
The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
contain the exact fields as shown below.
CDS 0 0 0 00
CDNSKEY 0 3 0 0AA==
The keying material payload is represented by a single octet with
the value 00. This record is signed in the same way as regular
CDS/CDNSKEY RRsets are signed.
Strictly speaking, the CDS record could be "CDS X 0 X X" as only the
DNSKEY algorithm is what signals the DELETE operation, but for
clarity, the "0 0 0 00" notation is mandated -- this is not a
definition of DS digest algorithm 0. The same argument applies to
"CDNSKEY 0 3 0 0AA=="; the value 3 in the second field is mandated by
[RFC4034], Section 2.1.2.