1 Internet Engineering Task Force (IETF) W. Hardaker
2 Request for Comments: 7477 Parsons, Inc.
3 Category: Standards Track March 2015
4 ISSN: 2070-1721
5
6
7 Child-to-Parent Synchronization in DNS
8
9 Abstract
10
11 This document specifies how a child zone in the DNS can publish a
12 record to indicate to a parental agent that the parental agent may
13 copy and process certain records from the child zone. The existence
14 of the record and any change in its value can be monitored by a
15 parental agent and acted on depending on local policy.
16
17 Status of This Memo
18
19 This is an Internet Standards Track document.
20
21 This document is a product of the Internet Engineering Task Force
22 (IETF). It represents the consensus of the IETF community. It has
23 received public review and has been approved for publication by the
24 Internet Engineering Steering Group (IESG). Further information on
25 Internet Standards is available in Section 2 of RFC 5741.
26
27 Information about the current status of this document, any errata,
28 and how to provide feedback on it may be obtained at
29 http://www.rfc-editor.org/info/rfc7477.
30
31 Copyright Notice
32
33 Copyright (c) 2015 IETF Trust and the persons identified as the
34 document authors. All rights reserved.
35
36 This document is subject to BCP 78 and the IETF Trust's Legal
37 Provisions Relating to IETF Documents
38 (http://trustee.ietf.org/license-info) in effect on the date of
39 publication of this document. Please review these documents
40 carefully, as they describe your rights and restrictions with respect
41 to this document. Code Components extracted from this document must
42 include Simplified BSD License text as described in Section 4.e of
43 the Trust Legal Provisions and are provided without warranty as
44 described in the Simplified BSD License.
45
46
47
48
49
50
51
52 Hardaker Standards Track [Page 1]
53 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
54
55
56 Table of Contents
57
58 1. Introduction ....................................................2
59 1.1. Terminology Used in This Document ..........................3
60 2. Definition of the CSYNC RRType ..................................3
61 2.1. The CSYNC Resource Record Format ...........................4
62 2.1.1. The CSYNC Resource Record Wire Format ...............4
63 2.1.2. The CSYNC Presentation Format .......................6
64 2.1.3. CSYNC RR Example ....................................6
65 3. CSYNC Data Processing ...........................................6
66 3.1. Processing Procedure .......................................7
67 3.2. CSYNC Record Types .........................................8
68 3.2.1. The NS type .........................................8
69 3.2.2. The A and AAAA Types ................................9
70 4. Operational Considerations ......................................9
71 4.1. Error Reporting ...........................................10
72 4.2. Child Nameserver Selection ................................10
73 4.3. Out-of-Bailiwick NS Records ...............................10
74 4.4. Documented Parental Agent Type Support ....................11
75 4.5. Removal of the CSYNC Records ..............................11
76 4.6. Parent/Child/Grandchild Glue Synchronization ..............12
77 5. Security Considerations ........................................12
78 6. IANA Considerations ............................................12
79 7. References .....................................................13
80 7.1. Normative References ......................................13
81 7.2. Informative References ....................................14
82 Acknowledgments ...................................................15
83 Author's Address ..................................................15
84
85 1. Introduction
86
87 This document specifies how a child zone in the DNS ([RFC1034]
88 [RFC1035]) can publish a record to indicate to a parental agent (see
89 Section 1.1 for a definition of "parental agent") that it can copy
90 and process certain records from the child zone. The existence of
91 the record and any change in its value can be monitored by a parental
92 agent and acted on depending on local policy.
93
94 Currently, some resource records (RRs) in a parent zone are typically
95 expected to be in sync with the source data in the child's zone. The
96 most common records that should match are the nameserver (NS) records
97 and any necessary associated address records (A and AAAA), also known
98 as "glue records". These records are referred to as "delegation
99 records".
100
101 It has been challenging for operators of child DNS zones to update
102 their delegation records within the parent's set in a timely fashion.
103 These difficulties may stem from operator laziness as well as from
104
105
106
107 Hardaker Standards Track [Page 2]
108 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
109
110
111 the complexities of maintaining a large number of DNS zones. Having
112 an automated mechanism for signaling updates will greatly ease the
113 child zone operator's maintenance burden and improve the robustness
114 of the DNS as a whole.
115
116 This document introduces a new Resource Record Type (RRType) named
117 "CSYNC" that indicates which delegation records published by a child
118 DNS operator should be processed by a parental agent and used to
119 update the parent zone's DNS data.
120
121 This specification was not designed to synchronize DNSSEC security
122 records, such as DS RRsets. For a solution to this problem, see the
123 complementary solution [RFC7344], which is designed to maintain
124 security delegation information. In addition, this specification
125 does not address how to perform bootstrapping operations, including
126 to get the required initial DNSSEC-secured operating environment in
127 place.
128
129 1.1. Terminology Used in This Document
130
131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
133 document are to be interpreted as described in [RFC2119].
134
135 Terminology describing relationships between the interacting roles
136 involved in this document are defined in the following list:
137
138 Child: The entity on record that has the delegation of the domain
139 from the parent
140
141 Parent: The domain in which the child is registered
142
143 Child DNS operator: The entity that maintains and publishes the zone
144 information for the child DNS
145
146 Parental agent: The entity that the child has relationship with, to
147 change its delegation information
148
149 2. Definition of the CSYNC RRType
150
151 The CSYNC RRType contains, in its RDATA component, these parts: an
152 SOA serial number, a set of flags, and a simple bit-list indicating
153 the DNS RRTypes in the child that should be processed by the parental
154 agent in order to modify the DNS delegation records within the
155 parent's zone for the child DNS operator. Child DNS operators
156 wanting a parental agent to perform the synchronization steps
157 outlined in this document MUST publish a CSYNC record at the apex of
158 the child zone. Parental agent implementations MAY choose to query
159
160
161
162 Hardaker Standards Track [Page 3]
163 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
164
165
166 child zones for this record and process DNS record data as indicated
167 by the Type Bit Map field in the RDATA of the CSYNC record. How the
168 data is processed is described in Section 3.
169
170 Parental agents MUST process the entire set of child data indicated
171 by the Type Bit Map field (i.e., all record types indicated along
172 with all of the necessary records to support processing of that type)
173 or else parental agents MUST NOT make any changes to parental records
174 at all. Errors due to unsupported Type Bit Map bits, or otherwise
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).
175 nonpunishable data, SHALL result in no change to the parent zone's
176 delegation information for the child. Parental agents MUST ignore a
177 child's CSYNC RDATA set if multiple CSYNC resource records are found;
178 only a single CSYNC record should ever be present.
179
180 The parental agent MUST perform DNSSEC validation ([RFC4033]
181 [RFC4034] [RFC4035]), of the CSYNC RRType data and MUST perform
182 DNSSEC validation of any data to be copied from the child to the
183 parent. Parents MUST NOT process any data from any of these records
184 if any of the validation results indicate anything other than
185 "Secure" [RFC4034] or if any the required data cannot be successfully
186 retrieved.
187
188 2.1. The CSYNC Resource Record Format
189
190 2.1.1. The CSYNC Resource Record Wire Format
191
192 The CSYNC RDATA consists of the following fields:
193
194 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
197 | SOA Serial |
198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
199 | Flags | Type Bit Map /
200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
201 / Type Bit Map (continued) /
202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
203
204 2.1.1.1. The SOA Serial Field
205
206 The SOA Serial field contains a copy of the 32-bit SOA serial number
207 from the child zone. If the soaminimum flag is set, parental agents
208 querying children's authoritative servers MUST NOT act on data from
209 zones advertising an SOA serial number less than this value. See
210 [RFC1982] for properly implementing "less than" logic. If the
211 soaminimum flag is not set, parental agents MUST ignore the value in
212 the SOA Serial field. Clients can set the field to any value if the
213 soaminimum flag is unset, such as the number zero.
214
215
216
217 Hardaker Standards Track [Page 4]
218 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
219
220
221 Note that a child zone's current SOA serial number may be greater
222 than the number indicated by the CSYNC record. A child SHOULD update
223 the SOA Serial field in the CSYNC record every time the data being
224 referenced by the CSYNC record is changed (e.g., an NS record or
225 associated address record is changed). A child MAY choose to update
226 the SOA Serial field to always match the current SOA Serial field.
227
228 Parental agents MAY cache SOA serial numbers from data they use and
229 refuse to process data from zones older than the last instance from
230 which they pulled data.
231
232 Although Section 3.2 of [RFC1982] describes how to properly implement
233 a less-than comparison operation with SOA serial numbers that may
234 wrap beyond the 32-bit value in both the SOA record and the CSYNC
235 record, it is important that a child using the soaminimum flag must
236 not increment its SOA serial number value more than 2^16 within the
237 period of time that a parent might wait between polling the child for
238 the CSYNC record.
239
240 2.1.1.2. The Flags Field
241
242 The Flags field contains 16 bits of boolean flags that define
243 operations that affect the processing of the CSYNC record. The flags
244 defined in this document are as follows:
245
246 0x00 0x01: "immediate"
247
248 0x00 0x02: "soaminimum"
249
250 The definitions for how the flags are to be used can be found in
251 Section 3.
252
253 The remaining flags are reserved for use by future specifications.
254 Undefined flags MUST be set to 0 by CSYNC publishers. Parental
255 agents MUST NOT process a CSYNC record if it contains a 1 value for a
256 flag that is unknown to or unsupported by the parental agent.
257
258 2.1.1.2.1. The Type Bit Map Field
259
260 The Type Bit Map field indicates the record types to be processed by
261 the parental agent, according to the procedures in Section 3. The
262 Type Bit Map field is encoded in the same way as the Type Bit Map
263 field of the NSEC record, described in [RFC4034], Section 4.1.2. If
264 a bit has been set that a parental agent implementation does not
265 understand, the parental agent MUST NOT act upon the record.
266 Specifically, a parental agent must not simply copy the data, and it
267 must understand the semantics associated with a bit in the Type Bit
268 Map field that has been set to 1.
269
270
271
272 Hardaker Standards Track [Page 5]
273 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
274
275
276 2.1.2. The CSYNC Presentation Format
277
278 The CSYNC presentation format is as follows:
279
280 The SOA Serial field is represented as an integer.
281
282 The Flags field is represented as an integer.
283
284 The Type Bit Map field is represented as a sequence of RRType
285 mnemonics. When the mnemonic is not known, the TYPE
286 representation described in [RFC3597], Section 5, MUST be used.
287 Implementations that support parsing of presentation format
288 records SHOULD be able to read and understand these TYPE
289 representations as well.
290
291 2.1.3. CSYNC RR Example
292
293 The following CSYNC RR shows an example entry for "example.com" that
294 indicates the NS, A, and AAAA bits are set and should be processed by
295 the parental agent for example.com. The parental agent should pull
296 data only from a zone using a minimum SOA serial number of 66 (0x42
297 in hexadecimal).
298
299 example.com. 3600 IN CSYNC 66 3 A NS AAAA
300
301 The RDATA component of the example CSYNC RR would be encoded on the
302 wire as follows:
303
304 0x00 0x00 0x00 0x42 (SOA Serial)
305 0x00 0x03 (Flags = immediate | soaminimum)
306 0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map)
307
308 3. CSYNC Data Processing
309
310 The CSYNC record and associated data must be processed as an "all or
311 nothing" operation set. If a parental agent fails to successfully
312 query for any of the required records, the whole operation MUST be
313 aborted. (Note that a query resulting in "no records exist" as
314 proven by NSEC or NSEC3 is to be considered successful).
315
316 Parental agents MAY:
317
318 Process the CSYNC record immediately if the "immediate" flag is
319 set. If the "immediate" flag is not set, the parental agent MUST
320 NOT act until the zone administrator approves the operation
321 through an out-of-band mechanism (such as through pushing a button
322 via a web interface).
323
324
325
326
327 Hardaker Standards Track [Page 6]
328 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
329
330
331 Choose not to process the CSYNC record immediately, even if the
332 "immediate" flag is set. That is, a parental agent might require
333 the child zone administrator approve the operation through an out-
334 of-band mechanism (such as through pushing a button via a web
335 interface).
336
337 Note: how the approval is done out of band is outside the scope of
338 this document and is implementation specific to parental agents.
339
340 3.1. Processing Procedure
341
342 The following shows a sequence of steps that SHOULD be used when
343 collecting and processing CSYNC records from a child zone. Because
344 DNS queries are not allowed to contain more than one "question" at a
345 time, a sequence of requests is needed. When processing a CSYNC
346 transaction request, all DNS queries should be sent to a single
347 authoritative name server for the child zone. To ensure a single
348 host is being addressed, DNS over TCP SHOULD be used to avoid
349 conversing with multiple nodes at an anycast address.
350
351 1. Query for the child zone's SOA record
352
353 2. Query for the child zone's CSYNC record
354
355 3. Query for the child zone's data records, as required by the CSYNC
356 record's Type Bit Map field
357
358 * Note: if any of the resulting records being queried are not
359 authoritative within the child zone but rather in a grandchild
360 or deeper, SOA record queries must be made for the
361 grandchildren. This will require the parental agent to
362 determine where the child/grandchild zone cuts occur. Because
363 of the additional operational complexity, parental agents MAY
364 choose not to support this protocol with children making use
365 of records that are authoritative in the grandchildren.
366
367 4. Query for the collected SOA records again, starting with the
368 deepest and ending with the SOA of the child's.
369
370 If the SOA records from the first, middle, and last steps for a given
371 zone have different serial numbers (for example, because the zone was
372 edited and republished during the interval between steps 1 and 4),
373 then the CSYNC record obtained in the second set SHOULD NOT be
374 processed (rapidly changing child zones may need special
375 consideration or processing). The operation MAY be restarted or
376 retried in the future.
377
378
379
380
381
382 Hardaker Standards Track [Page 7]
383 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
384
385
386 If the soaminimum flag is set and the SOA serial numbers are equal
387 but less than the CSYNC record's SOA Serial field [RFC1982], the
388 record MUST NOT be processed. If state is being kept by the parental
389 agent and the SOA serial number is less than the last time a CSYNC
390 record was processed, this CSYNC record SHOULD NOT be processed.
391 Similarly, if state is being kept by the parental agent and the SOA
392 Serial field of the CSYNC record is less than the SOA Serial field of
393 the CSYNC record from last time, then this CSYNC record SHOULD NOT be
394 processed.
395
396 If a failure of any kind occurs while trying to obtain any of the
397 required data, or if DNSSEC fails to validate all of the data
398 returned for these queries as "secure", then this CSYNC record MUST
399 NOT be processed.
400
401 See the "Operational Consideration" section (Section 4) for
402 additional guidance about processing.
403
404 3.2. CSYNC Record Types
405
406 This document defines how the following record types may be processed
407 if the CSYNC Type Bit Map field indicates they are to be processed.
408
409 3.2.1. The NS type
410
411 The NS type flag indicates that the NS records from the child zone
412 should be copied into the parent's delegation information records for
413 the child.
414
415 NS records found within the child's zone should be copied verbatim
416 (with the exception of the Time to Live (TTL) field, for which the
417 parent MAY want to select a different value) and the result published
418 within the parent zone should be a set of NS records that match
419 exactly. If the child has published a new NS record within their
420 set, this record should be added to the parent zone. Similarly, if
421 NS records in the parent's delegation records for the child contain
422 records that have been removed in the child's NS set, then they
423 should be removed in the parent's set as well.
424
425 Parental agents MAY refuse to perform NS updates if the replacement
426 records fail to meet NS record policies required by the parent zone
427 (e.g., "every child zone must have at least two NS records").
428 Parental agents MUST NOT perform NS updates if there are no NS
429 records returned in a query, as verified by DNSSEC denial-of-
430 existence protection. This situation should never happen unless the
431 child nameservers are misconfigured.
432
433
434
435
436
437 Hardaker Standards Track [Page 8]
438 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
439
440
441 Note that it is permissible for a child's nameserver to return a
442 CSYNC record that removes the queried nameserver itself from the
443 future NS or address set.
444
445 3.2.2. The A and AAAA Types
446
447 The A and AAAA type flags indicates that the A and AAAA address glue
448 records for in-bailiwick NS records within the child zone should be
449 copied verbatim (with the exception of the TTL field, for which the
450 parent MAY want to select a different value) into the parent's
451 delegation information.
452
453 Queries should be sent by the parental agent to determine the A and
454 AAAA record addresses for each NS record within a NS set for the
455 child that are in bailiwick.
456
457 Note: only the matching types should be queried. For example, if the
458 AAAA bit has not been set, then the AAAA records (if any) in the
459 parent's delegation should remain as is. If a given address type is
460 set and the child's zone contains no data for that type (as proven by
461 appropriate NSEC or NSEC3 records), then the result in the parent's
462 delegation records for the child should be an empty set. However, if
463 the end result of processing would leave no glue records present in
464 the parent zone for any of the of the in-bailiwick NS records, then
465 the parent MUST NOT update the glue address records. That is, if the
466 result of the processing would leave no in-bailiwick A or AAAA
467 records when there are in-bailiwick NS records, then processing of
468 the address records cannot happen as it would leave the parent/child
469 relationship without any address linkage.
470
471 The procedure for querying for A and AAAA records MUST occur after
472 the procedure, if required, for querying for NS records as defined in
473 Section 3.2.1. This ensures that the right set of NS records is used
474 as provided by the current NS set of the child. That is, for CSYNC
475 records that have the NS bit set, the NS set used should be the one
476 pulled from the child while processing the CSYNC record. For CSYNC
477 records without the NS bit set, the existing NS records within the
478 parent should be used to determine which A and/or AAAA records to
479 update.
480
481 4. Operational Considerations
482
483 There are a number of important operational aspects to consider when
484 deploying a CSYNC RRType.
485
486
487
488
489
490
491
492 Hardaker Standards Track [Page 9]
493 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
494
495
496 4.1. Error Reporting
497
498 There is no inline mechanism for a parental agent to report errors to
499 operators of child zones. Thus, the only error reporting mechanisms
500 must be out of band, such as through a web console or over email.
501 Parental agents should, at a minimum, at least log errors encountered
502 when processing CSYNC records. Child operators utilizing the
503 "immediate" flag that fail to see an update within the parental
504 agent's specified operational window should access the parental
505 agent's error logging interface to determine why an update failed to
506 be processed.
507
508 4.2. Child Nameserver Selection
509
510 Parental agents will need to poll child nameservers in search of
511 CSYNC records and related data records.
512
513 Parental agents MAY perform best-possible verification by querying
514 all NS records for available data to determine which has the most
515 recent SOA and CSYNC version (in an ideal world, they would all be
516 equal, but this is not possible in practice due to synchronization
517 delays and transfer failures).
518
519 Parental agents may offer a configuration interface to allow child
520 operators to specify which nameserver should be considered the master
521 to send data queries, too. Note that this master could be a
522 different nameserver than the publicly listed nameservers in the NS
523 set (i.e., it may be a "hidden master").
524
525 Parental agents with a large number of clients may choose to offer a
526 programmatic interface to let their children indicate that new CSYNC
527 records and data are available for polling rather than polling every
528 child on a frequent basis.
529
530 Children that wish to phase out a nameserver will need to publish the
531 CSYNC record to remove the nameserver and then wait for the parental
532 agent to process the published record before turning off the service.
533 This is required because the child cannot control which nameserver in
534 the existing NS set the parental agent may choose to query when
535 performing CSYNC processing.
536
537 4.3. Out-of-Bailiwick NS Records
538
539 When a zone contains NS records where the domain name pointed at does
540 not fall within the zone itself, there is no way for the parent to
541 safely update the associated glue records. Thus, the child DNS
542 operator MAY indicate that the NS records should be synchronized, and
543
544
545
546
547 Hardaker Standards Track [Page 10]
548 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
549
550
551 MAY set any glue record flags (A, AAAA) as well, but the parent will
552 only update those glue records that are below the child's delegation
553 point.
554
555 Children deploying NS records pointing to domain names within their
556 own children (the "grandchildren") SHOULD ensure the grandchildren's
557 associated glue records are properly set before publishing the CSYNC
558 record. That is, it is imperative that proper communication and
559 synchronization exist between the child and the grandchild.
560
561 4.4. Documented Parental Agent Type Support
562
563 Parental agents that support processing CSYNC records SHOULD publicly
564 document the following minimum processing characteristics:
565
566 The fact that they support CSYNC processing
567
568 The Type Bit Map bits they support
569
570 The frequency with which they poll clients (which may also be
571 configurable by the client)
572
573 If they support the "immediate" flag
574
575 If they poll a child's single nameserver, a configured list of
576 nameservers, or all of the advertised nameservers when querying
577 records
578
579 If they support SOA serial number caching to avoid issues with
580 regression and/or replay
581
582 Where errors for CSYNC processing are published
583
584 If they support sending queries to a "hidden master"
585
586 4.5. Removal of the CSYNC Records
587
588 Children MAY remove the CSYNC record upon noticing that the parent
589 zone has published the required records, thus eliminating the need
590 for the parent to continually query for the CSYNC record and all
591 corresponding records. By removing the CSYNC record from the child
592 zone, the parental agent will only need to perform the query for the
593 CSYNC record and can stop processing when it finds it missing. This
594 will reduce resource usage by both the child and the parental agent.
595
596
597
598
599
600
601
602 Hardaker Standards Track [Page 11]
603 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
604
605
606 4.6. Parent/Child/Grandchild Glue Synchronization
607
608 When a child needs to publish a CSYNC record that synchronizes NS and
609 A/AAAA glue records and the NS record is actually pointing to a child
610 of the child (a grandchild of the parent), then it is critical that
611 the glue records in the child point to the proper real addresses
612 records published by the grandchild. It is assumed that if a child
613 is using a grandchild's nameserver that they must be in careful
614 synchronization. Specifically, this specification requires this to
615 be the case.
616
617 5. Security Considerations
618
619 This specification requires the use of DNSSEC in order to determine
620 that the data being updated was unmodified by third parties.
621 Parental agents implementing CSYNC processing MUST ensure all DNS
622 transactions are validated by DNSSEC as "secure". Clients deploying
623 CSYNC MUST ensure their zones are signed, current and properly linked
624 to the parent zone with a DS record that points to an appropriate
625 DNSKEY of the child's zone.
626
627 This specification does not address how to perform bootstrapping
628 operations to get the required initial DNSSEC-secured operating
629 environment in place. Additionally, this specification was not
630 designed to synchronize DNSSEC security records, such as DS pointers,
631 or the CSYNC record itself. Thus, implementations of this protocol
632 MUST NOT use it to synchronize DS records, DNSKEY materials, CDS
633 records, CDNSKEY records, or CSYNC records. Similarly, future
634 documents extending this protocol MUST NOT offer the ability to
635 synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or
636 CSYNC records. For such a solution, please see the complimentary
637 solution [RFC7344] for maintaining security delegation information.
638
639 To ensure that an older CSYNC record making use of the soaminimum
640 flag cannot be replayed to revert values, the SOA serial number MUST
641 NOT be incremented by more than 2^16 during the lifetime of the
642 signature window of the associated RRSIGs signing the SOA and CSYNC
643 records. Note that this is independent of whether or not the
644 increment causes the 2^32 bit serial number field to wrap.
645
646 6. IANA Considerations
647
648 This document defines a new DNS Resource Record Type, named "CSYNC".
649 The IANA has assigned a code point from the "Resource Record (RR)
650 TYPEs" sub-registry of the "Domain Name System (DNS) Parameters"
651 registry (http://www.iana.org/assignments/dns-parameters) for this
652 record.
653
654
655
656
657 Hardaker Standards Track [Page 12]
658 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
659
660
661 TYPE Value Meaning Reference
662 ----- ------ -------------------------- -----------
663 CSYNC 62 Child-to-Parent Synchronization [RFC7477]
664
665 The IANA has created and maintains a sub-registry (the "Child
666 Synchronization (CSYNC) Flags" registry) of the "Domain Name System
667 (DNS) Parameters" registry. The initial values for this registry are
668 below.
669
670 A "Standards Action" [RFC5226] is required for the assignment of new
671 flag value.
672
673 This registry holds a set of single-bit "Flags" for use in the CSYNC
674 record within the 16-bit Flags field. Thus, a maximum of 16 flags
675 may be defined.
676
677 The initial assignments in this registry are:
678
679 Bit Flag Description Reference
680 ---- ------ ------------- -----------
681 Bit 0 immediate Immediately process this [RFC7477],
682 CSYNC record. Section 3
683
684 Bit 1 soaminimum Require a SOA serial [RFC7477],
685 number greater than the Section 2.1.1.1
686 one specified.
687
688 7. References
689
690 7.1. Normative References
691
692 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
693 August 1996, <http://www.rfc-editor.org/info/rfc1982>.
694
695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
696 Requirement Levels", BCP 14, RFC 2119, March 1997,
697 <http://www.rfc-editor.org/info/rfc2119>.
698
699 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
700 (RR) Types", RFC 3597, September 2003,
701 <http://www.rfc-editor.org/info/rfc3597>.
702
703 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
704 Rose, "Resource Records for the DNS Security Extensions",
705 RFC 4034, March 2005,
706 <http://www.rfc-editor.org/info/rfc4034>.
707
708
709
710
711
712 Hardaker Standards Track [Page 13]
713 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
714
715
716 7.2. Informative References
717
718 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
719 STD 13, RFC 1034, November 1987,
720 <http://www.rfc-editor.org/info/rfc1034>.
721
722 [RFC1035] Mockapetris, P., "Domain names - implementation and
723 specification", STD 13, RFC 1035, November 1987,
724 <http://www.rfc-editor.org/info/rfc1035>.
725
726 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
727 Rose, "DNS Security Introduction and Requirements", RFC
728 4033, March 2005,
729 <http://www.rfc-editor.org/info/rfc4033>.
730
731 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
732 Rose, "Protocol Modifications for the DNS Security
733 Extensions", RFC 4035, March 2005,
734 <http://www.rfc-editor.org/info/rfc4035>.
735
736 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
737 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
738 May 2008, <http://www.rfc-editor.org/info/rfc5226>.
739
740 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
741 DNSSEC Delegation Trust Maintenance", RFC 7344, September
742 2014, <http://www.rfc-editor.org/info/rfc7344>.
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767 Hardaker Standards Track [Page 14]
768 RFC 7477 Child-to-Parent Synchronization in DNS March 2015
769
770
771 Acknowledgments
772
773 A thank you goes out to Warren Kumari and Olafur Gudmundsson, whose
774 work on the CDS record type helped inspire the work in this document,
775 as well as the definition for the "parental agent" definition and
776 significant contributions to the text. A thank you also goes out to
777 Ed Lewis, with whom the author held many conversations about the
778 issues surrounding parent/child relationships and synchronization.
779 Much of the work in this document is derived from the careful
780 existing analysis of these three esteemed colleagues. Thank you to
781 the following people who have contributed text or detailed reviews to
782 the document (in no particular order): Matthijs Mekking, Petr Spacek,
783 JINMEI Tatuya, Pete Resnick, Joel Jaeggli, Brian Haberman, Warren
784 Kumari, Adrian Farrel, Alia Atlas, Barry Leiba, Richard Barnes,
785 Stephen Farrell, and Ted Lemon. Lastly, the DNSOP WG chairs Tim
786 Wicinski and Suzanne Woolf have been a tremendous help in getting
787 this document moving forward to publication.
788
789 A special thanks goes to Roy Arends, for taking the "bite out of that
790 hamburger" challenge while discussing this document.
791
792 A similar project, independently designed and developed, was
793 conducted by ep.net called "Child Activated DNS Refresh".
794
795 Author's Address
796
797 Wes Hardaker
798 Parsons, Inc.
799 P.O. Box 382
800 Davis, CA 95617
801 US
802
803 Phone: +1 530 792 1913
804 EMail: ietf@hardakers.net
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Hardaker Standards Track [Page 15]
823