1 Internet Engineering Task Force (IETF) W. Kumari
2 Request for Comments: 7344 Google
3 Category: Informational O. Gudmundsson
4 ISSN: 2070-1721 OGUD Consulting
5 G. Barwood
6 September 2014
7
8
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), except that updating of parent zones is not yet implemented.
9 Automating DNSSEC Delegation Trust Maintenance
10
11 Abstract
12
13 This document describes a method to allow DNS Operators to more
14 easily update DNSSEC Key Signing Keys using the DNS as a
15 communication channel. The technique described is aimed at
16 delegations in which it is currently hard to move information from
17 the Child to Parent.
18
19 Status of This Memo
20
21 This document is not an Internet Standards Track specification; it is
22 published for informational purposes.
23
24 This document is a product of the Internet Engineering Task Force
25 (IETF). It represents the consensus of the IETF community. It has
26 received public review and has been approved for publication by the
27 Internet Engineering Steering Group (IESG). Not all documents
28 approved by the IESG are a candidate for any level of Internet
29 Standard; see Section 2 of RFC 5741.
30
31 Information about the current status of this document, any errata,
32 and how to provide feedback on it may be obtained at
33 http://www.rfc-editor.org/info/rfc7344.
34
35 Copyright Notice
36
37 Copyright (c) 2014 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
39
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
49
50
51
52 Kumari, et al. Informational [Page 1]
53 RFC 7344 Delegation Trust Maintenance September 2014
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
60 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
62 2.1. DNS Delegations . . . . . . . . . . . . . . . . . . . . . 5
63 2.2. Relationship between Parent and Child DNS Operators . . . 5
64 2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6
65 2.2.2. DNSSEC Key Change Process . . . . . . . . . . . . . . 7
66 3. CDS (Child DS) and CDNSKEY (Child DNSKEY) Record Definitions 7
67 3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8
68 3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
69 4. Automating DS Maintenance with CDS/CDNSKEY Records . . . . . 8
70 4.1. CDS and CDNSKEY Processing Rules . . . . . . . . . . . . 9
71 5. CDS/CDNSKEY Publication . . . . . . . . . . . . . . . . . . . 9
72 6. Parent-Side CDS/CDNSKEY Consumption . . . . . . . . . . . . . 9
73 6.1. Detecting a Changed CDS/CDNSKEY . . . . . . . . . . . . . 10
74 6.1.1. CDS/CDNSKEY Polling . . . . . . . . . . . . . . . . . 10
75 6.1.2. Polling Triggers . . . . . . . . . . . . . . . . . . 11
76 6.2. Using the New CDS/CDNSKEY Records . . . . . . . . . . . . 11
77 6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 12
78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
79 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
83 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
84 11.2. Informative References . . . . . . . . . . . . . . . . . 15
85 Appendix A. RRR Background . . . . . . . . . . . . . . . . . . . 17
86 Appendix B. CDS Key Rollover Example . . . . . . . . . . . . . . 17
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Kumari, et al. Informational [Page 2]
108 RFC 7344 Delegation Trust Maintenance September 2014
109
110
111 1. Introduction
112
113 The first time a DNS Operator signs a zone, they need to communicate
114 the keying material to their Parent through some out-of-band method
115 to complete the chain of trust. Depending on the desires of the
116 Parent, the Child might send their DNSKEY record, a DS record, or
117 both.
118
119 Each time the Child changes the key that is represented in the
120 Parent, the updated and/or deleted key information has to be
121 communicated to the Parent and published in the Parent's zone. How
122 this information is sent to the Parent depends on the relationship
123 the Child has with the Parent. In many cases this is a manual
124 process -- and not an easy one. For each key change, there may be up
125 to two interactions with the Parent. Any manual process is
126 susceptible to mistakes and/or errors. In addition, due to the
127 annoyance factor of the process, Operators may avoid changing keys or
128 skip needed steps to publish the new DS at the Parent.
129
130 DNSSEC provides data integrity to information published in DNS; thus,
131 DNS publication can be used to automate maintenance of delegation
132 information. This document describes a method to automate
133 publication of subsequent DS records after the initial one has been
134 published.
135
136 Readers are expected to be familiar with DNSSEC, including [RFC4033],
137 [RFC4034], [RFC4035], [RFC5011], and [RFC6781].
138
139 This document outlines a technique in which the Parent periodically
140 (or upon request) polls its signed Children and automatically
141 publishes new DS records. To a large extent, the procedures this
142 document follows are as described in [RFC6781], Section 4.1.2.
143
144 This technique is designed to be friendly both to fully automated
145 tools and humans. Fully automated tools can perform all the actions
146 needed without human intervention and thus can monitor when it is
147 safe to move to the next step.
148
149 The solution described in this document only allows transferring
150 information about DNSSEC keys (DS and DNSKEY) from the Child to the
151 Parental Agent. It lists exactly what the Parent should publish and
152 allows for publication of standby keys. A different protocol,
153 [CPSYNC-DNS], can be used to maintain other important delegation
154 information, such as NS and glue records. These two protocols have
155 been kept as separate solutions because the problems are
156 fundamentally different and a combined solution is overly complex.
157
158
159
160
161
162 Kumari, et al. Informational [Page 3]
163 RFC 7344 Delegation Trust Maintenance September 2014
164
165
166 This document describes a method for automating maintenance of the
167 delegation trust information and proposes a polled/periodic trigger
168 for simplicity. Some users may prefer a different trigger, for
169 example, a button on a web page, a REST interface, or a DNS NOTIFY.
170 These alternate additional triggers are not discussed in this
171 document.
172
173 This proposal does not include all operations needed for the
174 maintenance of DNSSEC key material, specifically the initial
175 introduction or complete removal of all keys. Because of this,
176 alternate communications mechanisms must always exist, potentially
177 introducing more complexity.
178
179 1.1. Terminology
180
181 The terminology we use is defined in this section. The highlighted
182 roles are as follows:
183
184 o Child: The entity on record that has the delegation of the domain
185 from the Parent.
186
187 o Parent: The domain in which the Child is registered.
188
189 o Child DNS Operator: The entity that maintains and publishes the
190 zone information for the Child DNS.
191
192 o Parental Agent: The entity that the Child has a relationship with
193 to change its delegation information.
194
195 o Provisioning System: A system that the Operator of the master DNS
196 server operates to maintain the information published in the DNS.
197 This includes the systems that sign the DNS data.
198
199 o CDS/CDNSKEY: This notation refers to CDS and/or CDNSKEY, i.e., one
200 or both.
201
202 1.2. Requirements Notation
203
204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
206 "OPTIONAL" in this document are to be interpreted as described in
207 [RFC2119].
208
209
210
211
212
213
214
215
216
217 Kumari, et al. Informational [Page 4]
218 RFC 7344 Delegation Trust Maintenance September 2014
219
220
221 2. Background
222
223 2.1. DNS Delegations
224
225 DNS operation consists of delegations of authority. For each
226 delegation, there are (most of the time) two parties: the Parent and
227 the Child.
228
229 The Parent publishes information about the delegations to the Child;
230 for the name servers, it publishes an NS [RFC1035] Resource Record
231 Set (RRset) that lists a hint for name servers that are authoritative
232 for the Child. The Child also publishes an NS RRset, and this set is
233 the authoritative list of name servers to the Child zone.
234
235 The second RRset the Parent sometimes publishes is the DS [RFC4034]
236 set. The DS RRset provides information about the DNSKEY(s) that the
237 Child has told the Parent it will use to sign its DNSKEY RRset. In
238 DNSSEC, a trust relationship between zones is provided by the
239 following chain:
240
241 Parent DNSKEY --> DS --> Child DNSKEY.
242
243 A prior proposal [AUTO-CPSYNC] suggested that the Child send an
244 "update" to the Parent via a mechanism similar to DNS UPDATE. The
245 main issue became: how does the Child find the actual Parental Agent/
246 server to send the update to? While that could have been solved via
247 technical means, it failed to reach consensus. There is also a
248 similar proposal in [PARENT-ZONES].
249
250 As the DS record can only be present at the Parent [RFC4034], some
251 other method is needed to automate which DNSKEYs are picked to be
252 represented in the Parent zone's DS records. One possibility is to
253 use flags in the DNSKEY record. If the Secure Entry Point (SEP) bit
254 is set, this indicates that the DNSKEY is intended for use as a
255 secure entry point. This DNSKEY signs the DNSKEY RRset, and the
256 Parental Agent can calculate DS records based on that. But this
257 fails to meet some operating needs, including the Child having no
258 influence on what DS digest algorithms are used and DS records that
259 can only be published for keys that are in the DNSKEY RRset; thus,
260 this technique would not be compatible with Double-DS rollover
261 [RFC6781].
262
263 2.2. Relationship between Parent and Child DNS Operators
264
265 In practical application, there are many different relationships
266 between the Parent and Child DNS Operators. The type of relationship
267 affects how the Child DNS Operator communicates with the Parent.
268
269
270
271
272 Kumari, et al. Informational [Page 5]
273 RFC 7344 Delegation Trust Maintenance September 2014
274
275
276 This section will highlight some of the different situations but is
277 by no means a complete list.
278
279 Different communication paths:
280
281 o Direct/API: The Child can change the delegation information via
282 automated/scripted means. The Extensible Provisioning Protocol
283 (EPP) [RFC5730], used by many Top-Level Domains (TLDs), is an
284 example of this. Other examples are web-based programmatic
285 interfaces that Registrars make available to their Resellers.
286
287 o User Interface: The Child uses a web site set up by the Parental
288 Agent for updating delegation information.
289
290 o Indirect: The communication has to be transmitted via an out-of-
291 band mechanism between two parties, such as by email or telephone.
292 This is common when the Child DNS Operator is neither the Child
293 itself nor the Registrar for the domain, but a third party.
294
295 o Multi-step Combinations: The information flows through an
296 intermediary. It is possible, but unlikely, that all the steps
297 are automated via APIs and there are no humans involved.
298
299 A domain name holder (Child) may operate its own DNS servers or
300 outsource the operation. While we use the word "Parent" as singular,
301 a Parent can consist of a single entity or a composite of many
302 discrete parts that have rules and roles. We refer to the entity
303 that the Child corresponds with as the Parent.
304
305 An organization (such as an enterprise) may delegate parts of its
306 name-space to be operated by a group that is not the same as that
307 which operates the organization's DNS servers. In some of these
308 cases, the flow of information is handled either in an ad hoc manner
309 or via some corporate mechanism; this can range from email to a fully
310 automated operation.
311
312 2.2.1. Solution Space
313
314 This document is aimed at the cases in which there is a separation
315 between the Child and Parent.
316
317 A further complication is when the Child DNS Operator is not the
318 Child. There are two common cases of this:
319
320 a) The Parental Agent (e.g., Registrar) handles the DNS operation.
321
322 b) A third party takes care of the DNS operation.
323
324
325
326
327 Kumari, et al. Informational [Page 6]
328 RFC 7344 Delegation Trust Maintenance September 2014
329
330
331 If the Parental Agent is the DNS Operator, life is much easier; the
332 Parental Agent can inject any delegation changes directly into the
333 Parent's provisioning system. The techniques described below are not
334 needed in the case when the Parental Agent is the DNS Operator.
335
336 In the case of a third-party DNS Operator, the Child either needs to
337 relay changes in DNS delegation or give the Child DNS Operator access
338 to its delegation/registration account.
339
340 Some Parents want the Child to express their DNSKEYs in the form of
341 DS records, while others want to receive the DNSKEY records and
342 calculate the DS records themselves. There is no consensus on which
343 method is better; both have good reasons to exist. This solution is
344 DS vs. DNSKEY agnostic and allows operation with either.
345
346 2.2.2. DNSSEC Key Change Process
347
348 After a Child DNS Operator first signs the zone, there is a need to
349 interact with the Parent, for example, via a delegation account
350 interface to upload or paste in the zone's DS information. This
351 action of logging in through the delegation account user interface
352 authenticates that the user is authorized to change delegation
353 information for the Child published in the Parent zone. In the case
354 where the Child DNS Operator does not have access to the registration
355 account, the Child needs to perform the action.
356
357 At a later date, the Child DNS Operator may want to publish a new DS
358 record in the Parent, either because they are changing keys or
359 because they want to publish a standby key. This involves performing
360 the same process as before. Furthermore, when this is a manual
361 process with cut and paste, operational mistakes will happen -- or
362 worse, the update action will not be performed at all.
363
364 The Child DNS Operator may also introduce new keys and can do so when
365 old keys exist and can be used. The Child may also remove old keys,
366 but this document does not support removing all keys. This is to
367 avoid making signed zones unsigned. The Child may not enroll the
368 initial key or introduce a new key when there are no old keys that
369 can be used (without some additional out-of-band validation of the
370 keys) because there is no way to validate the information.
371
372 3. CDS (Child DS) and CDNSKEY (Child DNSKEY) Record Definitions
373
374 This document specifies two new DNS resource records, CDS and
375 CDNSKEY. These records are used to convey, from one zone to its
376 Parent, the desired contents of the zone's DS resource record set
377 residing in the Parent zone.
378
379
380
381
382 Kumari, et al. Informational [Page 7]
383 RFC 7344 Delegation Trust Maintenance September 2014
384
385
386 The CDS and CDNSKEY resource records are published in the Child zone
387 and give the Child control of what is published for it in the
388 parental zone. The Child can publish these manually, or they can be
389 automatically maintained by DNS provisioning tools. The CDS/CDNSKEY
390 RRset expresses what the Child would like the DS RRset to look like
391 after the change; it is a "replace" operation, and it is up to the
392 software that consumes the records to translate that into the
393 appropriate add/delete operations in the provisioning systems (and in
394 the case of CDNSKEY, to generate the DS from the DNSKEY). If neither
395 CDS nor CDNSKEY RRset is present in the Child, this means that no
396 change is needed.
397
398 3.1. CDS Resource Record Format
399
400 The wire and presentation format of the Child DS (CDS) resource
401 record is identical to the DS record [RFC4034]. IANA has allocated
402 RR code 59 for the CDS resource record via Expert Review
403 [DNS-TRANSPORT]. The CDS RR uses the same registries as DS for its
404 fields.
405
406 No special processing is performed by authoritative servers or by
407 resolvers, when serving or resolving. For all practical purposes,
408 CDS is a regular RR type.
409
410 3.2. CDNSKEY Resource Record Format
411
412 The wire and presentation format of the CDNSKEY ("Child DNSKEY")
413 resource record is identical to the DNSKEY record. IANA has
414 allocated RR code 60 for the CDNSKEY resource record via Expert
415 Review. The CDNSKEY RR uses the same registries as DNSKEY for its
416 fields.
417
418 No special processing is performed by authoritative servers or by
419 resolvers, when serving or resolving. For all practical purposes,
420 CDNSKEY is a regular RR type.
421
422 4. Automating DS Maintenance with CDS/CDNSKEY Records
423
424 CDS/CDNSKEY resource records are intended to be "consumed" by
425 delegation trust maintainers. The use of CDS/CDNSKEY is OPTIONAL.
426
427 If the Child publishes either the CDS or the CDNSKEY resource record,
428 it SHOULD publish both. If the Child knows which the Parent
429 consumes, it MAY choose to only publish that record type (for
430 example, some Children wish the Parent to publish a DS, but they wish
431 to keep the DNSKEY "hidden" until needed). If the Child publishes
432 both, the two RRsets MUST match in content.
433
434
435
436
437 Kumari, et al. Informational [Page 8]
438 RFC 7344 Delegation Trust Maintenance September 2014
439
440
441 4.1. CDS and CDNSKEY Processing Rules
442
443 If there is neither CDS nor CDNSKEY RRset in the Child, this signals
444 that no change should be made to the current DS set. This means
445 that, once the Child and Parent are in sync, the Child DNS Operator
446 MAY remove all CDS and CDNSKEY resource records from the zone. The
447 Child DNS Operator may choose to do this to decrease the size of the
448 zone or to decrease the workload for the Parent (if the Parent
449 receives no CDS/CDNSKEY records, it can go back to sleep). If it
450 does receive a CDS or CDNSKEY RRset, it needs to check them against
451 what is currently published (see Section 5).
452
453 The following acceptance rules are placed on the CDS and CDNSKEY
454 resource records as follows:
455
456 o Location: MUST be at the Child zone apex.
457
458 o Signer: MUST be signed with a key that is represented in both the
459 current DNSKEY and DS RRsets, unless the Parent uses the CDS or
460 CDNSKEY RRset for initial enrollment; in that case, the Parent
461 validates the CDS/CDNSKEY through some other means (see
462 Section 6.1 and the Security Considerations).
463
464 o Continuity: MUST NOT break the current delegation if applied to DS
465 RRset.
466
467 If any these conditions fail, the CDS or CDNSKEY resource record MUST
468 be ignored, and this error SHOULD be logged.
469
470 5. CDS/CDNSKEY Publication
471
472 The Child DNS Operator publishes CDS/CDNSKEY RRset(s). In order to
473 be valid, the CDS/CDNSKEY RRset(s) MUST be compliant with the rules
474 in Section 4.1. When the Parent DS is in sync with the CDS/CDNSKEY
475 RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);
476 the Child can determine if this is the case by querying for DS
477 records in the Parent.
478
479 6. Parent-Side CDS/CDNSKEY Consumption
480
481 The CDS/CDNSKEY RRset(s) SHOULD be used by the Parental Agent to
482 update the DS RRset in the Parent zone. The Parental Agent for this
483 uses a tool that understands the CDS/CDNSKEY signing rules in
484 Section 4.1, so it might not be able to use a standard validator.
485
486
487
488
489
490
491
492 Kumari, et al. Informational [Page 9]
493 RFC 7344 Delegation Trust Maintenance September 2014
494
495
496 The Parent MUST choose to use either CDNSKEY or CDS resource records
497 as its default updating mechanism. The Parent MAY only accept either
498 CDNSKEY or CDS, but it MAY also accept both so it can use the other
499 in the absence of the default updating mechanism; it MUST NOT expect
500 there to be both.
501
502 6.1. Detecting a Changed CDS/CDNSKEY
503
504 How the Parental Agent gets the CDS/CDNSKEY RRset may differ. Below
505 are two examples of how this can take place.
506
507 Polling: The Parental Agent operates a tool that periodically checks
508 each of the Children that has a DS record to see if there is a
509 CDS or CDNSKEY RRset.
510
511 Pushing: The delegation user interface has a button {Fetch DS} that,
512 when pushed, performs the CDS/CDNSKEY processing. If the
513 Parent zone does not contain DS for this delegation, then the
514 "push" SHOULD be ignored. If the Parental Agent displays the
515 contents of the CDS/CDNSKEY to the user and gets confirmation
516 that this represents their key, the Parental Agent MAY use this
517 for initial enrollment (when the Parent zone does not contain
518 the DS for this delegation).
519
520 In either case, the Parental Agent MAY apply additional rules that
521 defer the acceptance of a CDS/CDNSKEY change. These rules may
522 include a condition that the CDS/CDNSKEY remains in place and valid
523 for some time period before it is accepted. It may be appropriate in
524 the "Pushing" case to assume that the Child is ready and thus accept
525 changes without delay.
526
527 6.1.1. CDS/CDNSKEY Polling
528
529 This is the only defined use of CDS/CDNSKEY resource records in this
530 document. There are limits to the scalability of polling techniques;
531 thus, some other mechanism is likely to be specified later that
532 addresses CDS/CDNSKEY resource record usage in the situation where
533 polling runs into scaling issues. Having said that, polling will
534 work in many important cases such as enterprises, universities, and
535 smaller TLDs. In many regulatory environments, the Registry is
536 prohibited from talking to the Registrant. In most of these cases,
537 the Registrant has a business relationship with the Registrar, so the
538 Registrar can offer this as a service.
539
540 If the CDS/CDNSKEY RRset(s) do not exist, the Parental Agent MUST
541 take no action. Specifically, it MUST NOT delete or alter the
542 existing DS RRset.
543
544
545
546
547 Kumari, et al. Informational [Page 10]
548 RFC 7344 Delegation Trust Maintenance September 2014
549
550
551 6.1.2. Polling Triggers
552
553 It is assumed that other mechanisms will be implemented to trigger
554 the Parent to look for an updated CDS/CDNSKEY RRset. As the CDS/
555 CDNSKEY resource records are validated with DNSSEC, these mechanisms
556 can be unauthenticated. As an example, a Child could telephone its
557 Parent and request that it process the new CDS or CDNSKEY resource
558 records, or an unauthenticated POST could be made to a web server
559 (with rate-limiting).
560
561 Other documents can specify the trigger conditions.
562
563 6.2. Using the New CDS/CDNSKEY Records
564
565 Regardless of how the Parental Agent detected changes to a CDS/
566 CDNSKEY RRset, the Parental Agent SHOULD use a DNSSEC validator to
567 obtain a validated CDS/CDNSKEY RRset from the Child zone. A NOT
568 RECOMMENDED exception to this is if the Parent performs some
569 additional validation on the data to confirm that it is the "correct"
570 key.
571
572 The Parental Agent MUST ensure that previous versions of the CDS/
573 CDNSKEY RRset do not overwrite more recent versions. This MAY be
574 accomplished by checking that the signature inception in the Resource
575 Record Signature (RRSIG) for CDS/CDNSKEY RRset is later and/or that
576 the serial number on the Child's Start of Authority (SOA) is greater.
577 This may require the Parental Agent to maintain some state
578 information.
579
580 The Parental Agent MAY take extra security measures. For example, to
581 mitigate the possibility that a Child's Key Signing Key (KSK) has
582 been compromised, the Parental Agent may inform (by email or other
583 methods) the Child DNS Operator of the change. However, the precise
584 out-of-band measures that a Parent zone takes are outside the scope
585 of this document.
586
587 Once the Parental Agent has obtained a valid CDS/CDNSKEY RRset it
588 MUST check the publication rules from Section 4.1. In particular,
589 the Parental Agent MUST check the Continuity rule and do its best not
590 to invalidate the Child zone. Once checked, if the information in
591 the CDS/CDNSKEY and DS differ, it may apply the changes to the Parent
592 zone. If the Parent consumes CDNSKEY, the Parent should calculate
593 the DS before doing this comparison.
594
595
596
597
598
599
600
601
602 Kumari, et al. Informational [Page 11]
603 RFC 7344 Delegation Trust Maintenance September 2014
604
605
606 6.2.1. Parent Calculates DS
607
608 There are cases where the Parent wants to calculate the DS record due
609 to policy reasons. In this case, the Child publishes CDNSKEY
610 records, and the Parent calculates the DS records on behalf of the
611 Children.
612
613 When a Parent operates in "calculate DS" mode, it can operate in one
614 of two sub-modes:
615
616 full: The Parent only publishes DS records it calculates from DNSKEY
617 records.
618
619 augment: The Parent will make sure there are DS records for the
620 digest algorithm(s) it requires(s).
621
622 In the case where the Parent fetches the CDNSKEY RRset and calculates
623 the DS, the resulting DS can differ from the CDS published by the
624 Child. It is expected that the differences are only due to the
625 different set of digest algorithms used.
626
627 7. IANA Considerations
628
629 IANA has assigned RR Type code 59 for the CDS resource record. This
630 was done for a draft version whose content was later incorporated
631 into this document [DNS-TRANSPORT]. This document is the reference
632 for CDS RRtype.
633
634 IANA has assigned an RR Type for the CDNSKEY as described below:
635
636 Type: CDNSKEY
637
638 Value: 60
639
640 Meaning: DNSKEY(s) the Child wants reflected in DS
641
642 Reference: This document
643
644 8. Privacy Considerations
645
646 All of the information handled or transmitted by this protocol is
647 public information published in the DNS.
648
649
650
651
652
653
654
655
656
657 Kumari, et al. Informational [Page 12]
658 RFC 7344 Delegation Trust Maintenance September 2014
659
660
661 9. Security Considerations
662
663 This work is for the normal case; when things go wrong there is only
664 so much that automation can fix.
665
666 If the Child breaks DNSSEC validation by removing all the DNSKEYs
667 that are represented in the DS set, its only repair actions are to
668 contact the Parent or restore the DNSKEYs in the DS set.
669
670 In the event of a compromise of the server or system generating
671 signatures for a zone, an attacker might be able to generate and
672 publish new CDS/CDNSKEY resource records. The modified CDS/CDNSKEY
673 records will be picked up by this technique and may allow the
674 attacker to extend the effective time of his attack. If there is a
675 delay in accepting changes to DS, as in [RFC5011], then the attacker
676 needs to hope his activity is not detected before the DS in the
677 Parent is changed. If this type of change takes place, the Child
678 needs to contact the Parent (possibly via a Registrar web interface)
679 and remove any compromised DS keys.
680
681 A compromise of the account with the Parent (e.g., Registrar) will
682 not be mitigated by this technique, as the "new Registrant" can
683 delete or modify the DS records at will.
684
685 While it may be tempting, the techniques specified in this document
686 SHOULD NOT be used for initial enrollment of keys since there is no
687 way to ensure that the initial key is the correct one. If it is
688 used, strict rules for inclusion of keys -- such as hold-down times,
689 challenge data inclusion, or similar -- MUST be used along with some
690 kind of challenge mechanism. A Child cannot use this mechanism to go
691 from signed to unsigned (publishing an empty CDS/CDNSKEY RRset means
692 no change should be made in the Parent).
693
694 The CDS RR type should allow for enhanced security by simplifying the
695 process. Since key change is automated, updating a DS RRset by other
696 means may be regarded as unusual and subject to extra security
697 checks.
698
699 As this introduces a new mechanism to update information in the
700 Parent, it MUST be clear who is fetching the records and creating the
701 appropriate records in the Parent zone. Specifically, some
702 operations may use mechanisms other than what is described here. For
703 example, a Registrar may assume that it is maintaining the DNSSEC key
704 information in the Registry and may have this cached. If the
705 Registry is fetching the CDS/CDNSKEY RRset, then the Registry and
706 Registrar may have different views of the DNSSEC key material; the
707
708
709
710
711
712 Kumari, et al. Informational [Page 13]
713 RFC 7344 Delegation Trust Maintenance September 2014
714
715
716 result of such a situation is unclear. Therefore, this mechanism
717 SHOULD NOT be used to bypass intermediaries that might cache
718 information and, because of that, get the wrong state.
719
720 If there is a failure in applying changes in the Child zone to all
721 DNS servers listed in either Parent or Child NS set, it is possible
722 that the Parental Agent may get confused either because it gets
723 different answers on different checks or CDS RR validation fails. In
724 the worst case, the Parental Agent performs an action reversing a
725 prior action after the Child signing system decides to take the next
726 step in the key change process, resulting in a broken delegation.
727
728 DNS is a loosely coherent distributed database with local caching;
729 therefore, it is important to allow old information to expire from
730 caches before deleting DS or DNSKEY records. Similarly, it is
731 important to allow new records to propagate through the DNS before
732 use (see [RFC6781]).
733
734 It is common practice for users to outsource their DNS hosting to a
735 third-party DNS provider. In order for that provider to be able to
736 maintain the DNSSEC information, some users give the provider their
737 Registrar login credentials (which obviously has negative security
738 implications). Deploying the solution described in this document
739 allows third-party DNS providers to maintain the DNSSEC information
740 without Registrants giving their Registrar credentials, thereby
741 improving security.
742
743 By automating the maintenance of the DNSSEC key information (and
744 removing humans from the process), we expect to decrease the number
745 of DNSSEC related outages, which should increase DNSSEC deployment.
746
747 10. Acknowledgements
748
749 We would like to thank a large number of folk, including Mark
750 Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian
751 Dickson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir
752 Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu,
753 Matt Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul
754 Wouters, John Dickinson, Timothe Litt, and Edward Lewis.
755
756 Special thanks to Wes Hardaker for contributing significant text and
757 creating the complementary (CSYNC) solution, and to Patrik Faltstrom,
758 Paul Hoffman, Matthijs Mekking, Mukund Sivaraman, and Jeremy C. Reed
759 for text and in-depth review. Brian Carpenter provided a good
760 Gen-ART review.
761
762 There were a number of other folk with whom we discussed this
763 document; apologies for not remembering everyone.
764
765
766
767 Kumari, et al. Informational [Page 14]
768 RFC 7344 Delegation Trust Maintenance September 2014
769
770
771 11. References
772
773 11.1. Normative References
774
775 [RFC1035] Mockapetris, P., "Domain names - implementation and
776 specification", STD 13, RFC 1035, November 1987.
777
778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
779 Requirement Levels", BCP 14, RFC 2119, March 1997.
780
781 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
782 Rose, "DNS Security Introduction and Requirements", RFC
783 4033, March 2005.
784
785 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
786 Rose, "Resource Records for the DNS Security Extensions",
787 RFC 4034, March 2005.
788
789 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
790 Rose, "Protocol Modifications for the DNS Security
791 Extensions", RFC 4035, March 2005.
792
793 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
794 Trust Anchors", STD 74, RFC 5011, September 2007.
795
796 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
797 Operational Practices, Version 2", RFC 6781, December
798 2012.
799
800 11.2. Informative References
801
802 [AUTO-CPSYNC]
803 Mekking, W., "Automated (DNSSEC) Child Parent
804 Synchronization using DNS UPDATE", Work in Progress,
805 December 2010.
806
807 [CPSYNC-DNS]
808 Hardaker, W., "Child To Parent Synchronization in DNS",
809 Work in Progress, July 2014.
810
811 [DNS-TRANSPORT]
812 Barwood, G., "DNS Transport", Work in Progress, June 2011.
813
814 [PARENT-ZONES]
815 Andrews, M., "Updating Parent Zones", Work in Progress,
816 November 2013.
817
818
819
820
821
822 Kumari, et al. Informational [Page 15]
823 RFC 7344 Delegation Trust Maintenance September 2014
824
825
826 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
827 STD 69, RFC 5730, August 2009.
828
829 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
830 Security Extensions Mapping for the Extensible
831 Provisioning Protocol (EPP)", RFC 5910, May 2010.
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877 Kumari, et al. Informational [Page 16]
878 RFC 7344 Delegation Trust Maintenance September 2014
879
880
881 Appendix A. RRR Background
882
883 RRR is our shorthand for the Registry/Registrar/Registrant model of
884 Parent-Child relationships.
885
886 In the RRR world, the different parties are frequently from different
887 organizations. In the single enterprise world, there are also
888 organizational, geographical, and cultural separations that affect
889 how information flows from a Child to the Parent.
890
891 Due to the complexity of the different roles and interconnections,
892 automation of delegation information has not yet occurred. There
893 have been proposals to automate this, in order to improve the
894 reliability of the DNS. These proposals have not gained enough
895 traction to become standards.
896
897 For example, in many of the TLD cases, there is the RRR model
898 (Registry/Registrar/Registrant). The Registry operates DNS for the
899 TLD, and the Registrars accept registrations and place information
900 into the Registry's database. The Registrant only communicates with
901 the Registrar; frequently, the Registry is not allowed to communicate
902 with the Registrant. In that case, as far as the Registrant is
903 concerned, the Registrar is the same entity as the Parent.
904
905 In many RRR cases, the Registrar and Registry communicate via EPP
906 [RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number of
907 Country Code TLDs (ccTLDs), there are other mechanisms in use as well
908 as EPP, but in general, there seems to be a movement towards EPP
909 usage when DNSSEC is enabled in the TLD.
910
911 Appendix B. CDS Key Rollover Example
912
913 This section shows an example on how CDS is used when performing a
914 KSK rollover. This example will demonstrate the Double-DS rollover
915 method from Section 4.1.2 of [RFC6781]. Other rollovers using
916 CDNSKEY and double KSK are left as an exercise to the reader. The
917 table below does not reflect the Zone Signing Keys (ZSKs) as they do
918 not matter during KSK rollovers. The wait steps highlight what RRset
919 needs to expire from caches before progressing to the next step.
920
921
922
923
924
925
926
927
928
929
930
931
932 Kumari, et al. Informational [Page 17]
933 RFC 7344 Delegation Trust Maintenance September 2014
934
935
936 +------+---------------+---------+---------+--------------+---------+
937 | Step | State | Parent | Child | DNSKEY and | Child |
938 | | | DS | KSK | CDS signer | CDS |
939 +------+---------------+---------+---------+--------------+---------+
940 | | Beginning | A | A | A | |
941 | 1 | Add CDS | A | A | A | AB |
942 | Wait | for DS change | A | A | A | AB |
943 | 2 | Updated DS | AB | A | A | AB |
944 | Wait | > DS TTL | AB | A | A | AB |
945 | 3 | Actual | AB | B | B | AB |
946 | | Rollover | | | | |
947 | Wait | > DNSKEY TTL | AB | B | B | AB |
948 | 4 | Child Cleanup | AB | B | B | B |
949 | 5 | Parent cleans | B | B | B | B |
950 | 6 | Optional CDS | B | B | B | |
951 | | delete | | | | |
952 +------+---------------+---------+---------+--------------+---------+
953
954 Table 1: States
955
956 Authors' Addresses
957
958 Warren Kumari
959 Google
960 1600 Amphitheatre Parkway
961 Mountain View, CA 94043
962 US
963
964 EMail: warren@kumari.net
965
966
967 Olafur Gudmundsson
968 OGUD Consulting
969 3821 Village Park Dr.
970 Chevy Chase, MD 20815
971 US
972
973 EMail: ogud@ogud.com
974
975
976 George Barwood
977 33 Sandpiper Close
978 Gloucester GL2 4LZ
979 United Kingdom
980
981 EMail: george.barwood@blueyonder.co.uk
982
983
984
985
986
987 Kumari, et al. Informational [Page 18]
988
RFC8078 puts this RFC onto Standards Track.
In addition, it extends the protocol here. The introduction says:
In addition, [RFC7344] lacks two different options for full automated operation to be possible. It does not define a method for the initial trust establishment, leaving it open to each parent to come up with an acceptance policy. Additionally, [RFC7344] does not provide a "delete" signal for the child to inform the parent that the DNSSEC security for its domain must be removed.
Note that RFC8078 has significant technical errata.