idnits 2.17.1 draft-ietf-dnsop-child-syncronization-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 6, 2015) is 3395 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP W. Hardaker 3 Internet-Draft Parsons, Inc. 4 Intended status: Standards Track January 6, 2015 5 Expires: July 10, 2015 7 Child To Parent Synchronization in DNS 8 draft-ietf-dnsop-child-syncronization-07 10 Abstract 12 This document specifies how a child zone in the DNS can publish a 13 record to indicate to a parental agent that the parental agent may 14 copy and process certain records from the child zone. The existence 15 of the record and any change in its value can be monitored by a 16 parental agent and acted on depending on local policy. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 10, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 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. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology Used in This Document . . . . . . . . . . . . 3 54 2. Definition of the CSYNC RRType . . . . . . . . . . . . . . . . 4 55 2.1. The CSYNC Resource Record Format . . . . . . . . . . . . . 4 56 2.1.1. The CSYNC Resource Record Wire Format . . . . . . . . 5 57 2.1.2. The CSYNC Presentation Format . . . . . . . . . . . . 6 58 2.1.3. CSYNC RR Example . . . . . . . . . . . . . . . . . . . 6 59 3. CSYNC Data Processing . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Processing Procedure . . . . . . . . . . . . . . . . . . . 7 61 3.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . . . 8 62 3.2.1. The NS type . . . . . . . . . . . . . . . . . . . . . 9 63 3.2.2. The A and AAAA types . . . . . . . . . . . . . . . . . 9 64 4. Operational Considerations . . . . . . . . . . . . . . . . . . 10 65 4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 66 4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 10 67 4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 11 68 4.4. Documented Parental Agent Type Support . . . . . . . . . . 11 69 4.5. Removal of the CSYNC records . . . . . . . . . . . . . . . 12 70 4.6. Parent/Child/Grandchild Glue Synchronization . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 This document specifies how a child zone in the DNS ([RFC1034], 82 [RFC1035]) can publish a record to indicate to a parental agent (see 83 section Section 2 for a definition of "parental agent") that it can 84 copy and process certain records from the child zone. The existence 85 of the record and any change in its value can be monitored by a 86 parental agent and acted on depending on local policy. 88 Currently today, some resource records (RRs) in a parent zone are 89 typically expected to be in sync with the source data in the child's 90 zone. The most common records that should match are the nameserver 91 (NS) records and any necessary associated address records (A and 92 AAAA), also known as "glue records". These records are referred to 93 as "delegation records". 95 It has been challenging for operators of child DNS zones to update 96 their delegation records within the parent's set in a timely fashion. 97 These difficulties may stem from operator laziness, as well as from 98 the complexities of maintaining a large number of DNS zones. Having 99 an automated mechanism for signaling updates will greatly ease the 100 child zone operator's maintenance burden and improve the robustness 101 of the DNS as a whole. 103 This draft introduces a new Resource Record Type (RRType) named 104 "CSYNC" that indicates which delegation records published by a child 105 DNS operator should be processed by a parental agent and used to 106 update the parent zone's DNS data. 108 This specification was not designed to synchronize DNSSEC security 109 records, such as DS RRsets. For a solution to this problem, see the 110 complementary solution [RFC7344], which is designed to maintain 111 security delegation information. In addition, this specification 112 does not address how to perform bootstrapping operations, including 113 to get the required initial DNSSEC-secured operating environment in 114 place. 116 1.1. Terminology Used in This Document 118 The terminology used in this document is defined in this section. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 Terminology describing relationships between the interacting roles 125 involved in this document are defined in the following list: 127 Child: The entity on record that has the delegation of the domain 128 from the parent 130 Parent: The domain in which the child is registered 132 Child DNS operator: The entity that maintains and publishes the zone 133 information for the child DNS 135 Parental agent: The entity that the child has relationship with, to 136 change its delegation information 138 2. Definition of the CSYNC RRType 140 The CSYNC RRType contains, in its RDATA component, these parts: an 141 SOA serial number, a set of flags and a simple bit-list indicating 142 the DNS RRTypes in the child that should be processed by the parental 143 agent in order to modify the DNS delegation records within the 144 parent's zone for the child DNS operator. Child DNS operators 145 wanting a parental agent to perform the synchronization steps 146 outlined in this document MUST publish a CSYNC record at the apex of 147 the child zone. Parental agent implementations MAY choose to query 148 child zones for this record and process DNS record data as indicated 149 by the Type Bit Map field in the RDATA of the CSYNC record. How the 150 data is processed is described in Section 3. 152 Parental agents MUST process the entire set of child data indicated 153 by the Type Bit Map field (i.e., all record types indicated along 154 with all of the necessary records to support processing of that type) 155 or else parental agents MUST NOT make any changes to parental records 156 at all. Errors due to unsupported Type Bit Map bits, or otherwise 157 nonpunishable data, SHALL result in no change to the parent zone's 158 delegation information for the Child. Parental agents MUST ignore a 159 Child's CSYNC RDATA set if multiple CSYNC resource records are found; 160 only a single CSYNC record should ever be present. 162 The parental agent MUST perform DNSSEC validation ([RFC4033], 163 [RFC4034], [RFC4035]), of the CSYNC RRType data and MUST perform 164 DNSSEC validation of any data to be copied from the Child to the 165 Parent. Parents MUST NOT process any data from any of these records 166 if any of the validation results indicate anything other than 167 "Secure" [RFC4034] or if any the required data can not be 168 successfully retrieved. 170 2.1. The CSYNC Resource Record Format 171 2.1.1. The CSYNC Resource Record Wire Format 173 The CSYNC RDATA consists of the following fields: 175 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | SOA Serial | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Flags | Type Bit Map / 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 / Type Bit Map (continued) / 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 2.1.1.1. The SOA Serial Field 187 The SOA Serial field contains a copy of the 32-bit SOA serial number 188 from the child zone. If the soaminimum flag is set, parental agents 189 querying children's authoritative servers MUST NOT act on data from 190 zones advertising an SOA serial number less than this value. See 191 [RFC1982] for properly implementing "less than" logic. If the 192 soaminimum flag is not set, parental agents MUST ignore the value in 193 the SOA Serial Field. Clients can set the field to any value if the 194 soaminimum flag is unset, such as the number zero. 196 Note that a child zone's current SOA serial number may be greater 197 than the number indicated by the CSYNC record. A child SHOULD update 198 the SOA Serial field in the CSYNC record every time the data being 199 referenced by the CSYNC record is changed (e.g. an NS record or 200 associated address record is changed). A child MAY choose to update 201 the SOA Serial field to always match the current SOA serial field. 203 Parental agents MAY cache SOA serial numbers from data they use and 204 refuse to process data from zones older than the last instance they 205 pulled data from. 207 Although Section 3.2 of [RFC1982] describes how to properly implement 208 a less-than comparison operation with SOA serial numbers that may 209 wrap beyond the 32-bit value in both the SOA record and the CSYNC 210 record, it is important than a child using the soaminimum flag must 211 not increment it's SOA serial number value more than 2^16 within the 212 period of time that a parent might wait between polling the child for 213 the CSYNC record. 215 2.1.1.2. The Flags Field 217 The Flags field contains 16 bits of boolean flags that define 218 operations which affect the processing of the CSYNC record. The 219 flags defined in this document are as follows: 221 0x00 0x01: "immediate" 223 0x00 0x02: "soaminimum" 225 The definitions for how the flags are to be used can be found later 226 in Section Section 3. 228 The remaining flags are reserved for use by future specifications. 229 Undefined flags MUST be set to 0 by CSYNC publishers. Parental 230 agents MUST NOT process a CSYNC record if it contains a 1 value for a 231 flag that is unknown to or unsupported by the parental agent. 233 2.1.1.2.1. The Type Bit Map Field 235 The Type Bit Map field indicates the record types to be processed by 236 the parental agent, according to the procedures in Section Section 3. 237 The Type Bit Map field is encoded in the same way as the Type Bit 238 Maps field of the NSEC record, described in [RFC4034], Section 4.1.2. 239 If a bit has been set that a parental agent implementation does not 240 understand, the parental agent MUST NOT act upon the record. 241 Specifically: a parental agent must not just copy the data and must 242 understand the semantics associated with an bit in the Type Bit Map 243 field that has been set to 1. 245 2.1.2. The CSYNC Presentation Format 247 The CSYNC presentation format is as follows: 249 The SOA Serial field is represented as an integer. 251 The Flags field is represented as an integer. 253 The Type Bit Map field is represented as a sequence of RR type 254 mnemonics. When the mnemonic is not known, the TYPE 255 representation described in [RFC3597], Section 5, MUST be used. 256 Implementations that support parsing of presentation format 257 records SHOULD be able to read and understand these TYPE 258 representations as well. 260 2.1.3. CSYNC RR Example 262 The following CSYNC RR shows an example entry for "example.com" that 263 indicates the NS, A and AAAA bits are set and should be processed by 264 the parental agent for example.com. The parental agent should pull 265 data only from a zone using a minimum SOA serial number of 66 (0x42 266 in hexadecimal). 268 example.com. 3600 IN CSYNC 66 3 A NS AAAA 270 The RDATA component of the example CSYNC RR would be encoded on the 271 wire as follows: 273 0x00 0x00 0x00 0x42 (SOA Serial) 274 0x00 0x03 (Flags = immediate | soaminimum) 275 0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map) 277 3. CSYNC Data Processing 279 The CSYNC record and associated data must be processed as an "all or 280 nothing" operation set. If a parental agent fails to successfully 281 query for any of the required records, the whole operation MUST be 282 aborted. (Note that a query resulting in "no records exist" as 283 proven by NSEC or NSEC3 is to be considered successful). 285 Parental agents MAY: 287 Process the CSYNC record immediately if the "immediate" flag is 288 set. If the "immediate" flag is not set, the parental agent MUST 289 NOT act until the zone administrator approves the operation 290 through an out-of-band mechanism (such as through pushing a button 291 via a web interface). 293 Choose not to process the CSYNC record immediately, even if the 294 "immediate" flag is set. That is, a parental agent might require 295 the child zone administrator approve the operation through an out- 296 of-band mechanism (such as through pushing a button via a web 297 interface). 299 Note: how the approval is done out-of-band is outside the scope of 300 this document and is implementation-specific to parental agents. 302 3.1. Processing Procedure 304 The following shows a sequence of steps that SHOULD be used when 305 collecting and processing CSYNC records from a child zone. Because 306 DNS queries are not allowed to contain more than one "question" at a 307 time, a sequence of requests is needed. When processing a CSYNC 308 transaction request, all DNS queries should be sent to a single 309 authoritative name server for the child zone. To ensure a single 310 host is being addressed, DNS over TCP SHOULD be used to avoid 311 conversing with multiple nodes at an anycast address. 313 1. Query for the child zone's SOA record 314 2. Query for the child zone's CSYNC record 316 3. Query for the child zone's data records, as required by the CSYNC 317 record's Type Bit Map field 319 * Note: if any of the resulting records being queried are not 320 authoritative within the child zone but rather in a grandchild 321 or deeper, SOA record queries must be made for the 322 grandchildren. This will require the parental agent to 323 determine where the child/grandchild zone cuts occur. Because 324 of the additional operational complexity, parental agents MAY 325 choose not to support this protocol with children making use 326 of records that are authoritative in the grandchildren. 328 4. Query for the collected SOA records again, starting with the 329 deepest and ending with the SOA of the child's. 331 If the SOA records from the first, middle and last steps for a given 332 zone have different serial numbers (for example, because the zone was 333 edited and republished during the interval between steps 1 and 4), 334 then the CSYNC record obtained in the second set SHOULD NOT be 335 processed (rapidly changing child zones may need special 336 consideration or processing). The operation MAY be restarted or 337 retried in the future. 339 If the soaminimum flag is set and the SOA serial numbers are equal 340 but less than the CSYNC record's SOA Serial Field [RFC1982], the 341 record MUST NOT be processed. If state is being kept by the parental 342 agent and the SOA serial number is less than the last time a CSYNC 343 record was processed, this CSYNC record SHOULD NOT be processed. 344 Similarly, if state is being kept by the parental agent and the SOA 345 Serial Field of the CSYNC record is less than the SOA Serial Field of 346 the CSYNC record from last time, then this CSYNC record SHOULD NOT be 347 processed. 349 If a failure occurs of any kind while trying to obtain any of the 350 required data, or if DNSSEC fails to validate all of the data 351 returned for these queries as "secure", then this CSYNC record MUST 352 NOT be processed. 354 See the "Operational Consideration" section (Section Section 4) for 355 additional guidance about processing. 357 3.2. CSYNC Record Types 359 This document defines how the following record types may be processed 360 if the CSYNC Type Bit Map field indicates they are to be processed. 362 3.2.1. The NS type 364 The NS type flag indicates that the NS records from the child zone 365 should be copied into the parent's delegation information records for 366 the child. 368 NS records found within the child's zone should be copied verbatim 369 (with the exception of the TTL field, for which the parent MAY want 370 to select a different value) and the result published within the 371 parent zone should be an exact matching set of NS records. If the 372 child has published a new NS record within their set, this record 373 should be added to the parent zone. Similarly, if NS records in the 374 parent's delegation records for the child contain records that have 375 been removed in the child's NS set, then they should be removed in 376 the parent's set as well. 378 Parental agents MAY refuse to perform NS updates if the replacement 379 records fail to meet NS record policies required by the parent zone 380 (e.g. "every child zone must have at least 2 NS records"). Parental 381 agents MUST NOT perform NS updates if there are no NS records 382 returned in a query, as verified by DNSSEC denial of existence 383 protection. This situation should never happen unless the child 384 nameservers are misconfigured. 386 Note that it is permissible for a child's nameserver to return a 387 CSYNC record that removes the queried nameserver itself from the 388 future NS or address set. 390 3.2.2. The A and AAAA types 392 The A and AAAA type flags indicates that the A and AAAA address glue 393 records for in-bailiwick NS records within the child zone should be 394 copied verbatim (with the exception of the TTL field, for which the 395 parent MAY want to select a different value) into the parent's 396 delegation information. 398 Queries should be sent by the parental agent to determine the A and 399 AAAA record addresses for each NS record within a NS set for the 400 child that are in-bailiwick. 402 Note: only the matching types should be queried. E.g., if the AAAA 403 bit has not been set, then the AAAA records (if any) in the parent's 404 delegation should remain as is. If a given address type is set and 405 the child's zone contains no data for that type (as proven by 406 appropriate NSEC or NSEC3 records), then the result in the parent's 407 delegation records for the child should be an empty set. However, if 408 the end result of processing would leave no glue records present in 409 the parent zone for any of the of the in-bailiwick NS records, then 410 the parent MUST NOT update the glue address records. I.E., if the 411 result of the processing would leave no in-bailiwick A or AAAA 412 records when there are in-bailiwick NS records, then processing of 413 the address records can not happen as it would leave the parent/child 414 relationship without any address linkage. 416 The procedure for querying for A and AAAA records MUST occur after 417 the procedure, if required, for querying for NS records as defined in 418 Section Section 3.2.1. This ensures that the right set of NS records 419 is used as provided by the current NS set of the child. I.e., for 420 CSYNC records that have the NS bit set, the NS set used should be the 421 one pulled from the child while processing the CSYNC record. For 422 CSYNC records without the NS bit set, the existing NS records within 423 the parent should be used to determine which A and/or AAAA records to 424 update. 426 4. Operational Considerations 428 There are a number of important operational aspects to consider when 429 deploying a CSYNC RRType. 431 4.1. Error Reporting 433 There is no inline mechanism for a parental agent to report errors to 434 operators of child zones. Thus, the only error reporting mechanisms 435 must be out of band, such as through a web console or over email. 436 Parental agents should, at a minimum, at least log errors encountered 437 when processing CSYNC records. Child operators utilizing the 438 "immediate" flag that fail to see an update within the parental 439 agent's specified operational window should access the parental 440 agent's error logging interface to determine why an update failed to 441 be processed. 443 4.2. Child Nameserver Selection 445 Parental agents will need to poll child nameservers in search of 446 CSYNC records and related data records. 448 Parental agents MAY perform best-possible verification by querying 449 all NS records for available data to determine which has the most 450 recent SOA and CSYNC version (in an ideal world, they would all be 451 equal, but this is not possible in practice due to synchronization 452 delays and transfer failures). 454 Parental agents may offer a configuration interface to allow child 455 operators to specify which nameserver should be considered the master 456 to send data queries too. Note that this master could be a different 457 nameserver than the publically listed nameservers in the NS set 458 (i.e., it may be a "hidden master"). 460 Parental agents with a large number of clients may choose to offer a 461 programmatic interface to let their children indicate that new CSYNC 462 records and data are available for polling rather than polling every 463 child on a frequent basis. 465 Children that wish to phase out a nameserver will need to publish the 466 CSYNC record to the nameserver being removed and wait for the 467 parental agent to process the published record before turning off the 468 service. This is required because the child can not control which 469 nameserver in the existing NS set the parental agent may choose to 470 query when performing CSYNC processing. 472 4.3. Out-of-balliwick NS Records 474 When a zone contains NS records where the domain-name pointed at does 475 not fall within the zone itself, there is no way for the parent to 476 safely update the associated glue records. Thus, the child DNS 477 operator MAY indicate that the NS records should be synchronized, and 478 MAY set any glue record flags (A, AAAA) as well, but the parent will 479 only update those glue records which are below the child's delegation 480 point. 482 Children deploying NS records pointing to domain-names within their 483 own children (the "grandchildren") SHOULD ensure the grandchildren's 484 associated glue records are properly set before publishing the CSYNC 485 record. I.e., it is imperative that proper communication and 486 synchronization exist between the child and the grandchild. 488 4.4. Documented Parental Agent Type Support 490 Parental agents that support processing CSYNC records SHOULD publicly 491 document the following minimum processing characteristics: 493 The fact that they support CSYNC processing 495 The Type Bit Map bits they support 497 The frequency with which they poll clients (which may also be 498 configurable by the client) 500 If they support the "immediate" flag 502 If they poll a child's single nameserver, a configured list of 503 nameservers, or all of the advertised nameservers when querying 504 records 505 If they support SOA serial number caching to avoid issues with 506 regression and/or replay 508 Where errors for CSYNC processing are published 510 If they support sending queries to a "hidden master". 512 4.5. Removal of the CSYNC records 514 Children MAY remove the CSYNC record upon noticing that the parent 515 zone has published the required records, thus eliminating the need 516 for the parent to continually query for the CSYNC record and all 517 corresponding records. By removing the CSYNC record from the child 518 zone, the parental agent will only need to perform the query for the 519 CSYNC record and can stop processing when it finds it missing. This 520 will reduce resource usage by both the child and the parental agent. 522 4.6. Parent/Child/Grandchild Glue Synchronization 524 When a child needs to publish a CSYNC record that synchronizes NS and 525 A/AAAA glue records and the NS record is actually pointing to a child 526 of the child (a grandchild of the parent), then it is critical that 527 the glue records in the child point to the proper real addresses 528 records published by the grandchild. It is assumed that if a child 529 is using a grandchild's nameserver that they must be in careful 530 synchronization. Specifically, this specification requires this to 531 be the case. 533 5. Security Considerations 535 This specification requires the use of DNSSEC in order to determine 536 that the data being updated was unmodified by third-parties. 537 Parental agents implementing CSYNC processing MUST ensure all DNS 538 transactions are validated by DNSSEC as "secure". Clients deploying 539 CSYNC MUST ensure their zones are signed, current and properly linked 540 to the parent zone with a DS record that points to an appropriate 541 DNSKEY of the child's zone. 543 This specification does not address how to perform bootstrapping 544 operations to get the required initial DNSSEC-secured operating 545 environment in place. Additionally, this specification was not 546 designed to synchronize DNSSEC security records, such as DS pointers, 547 or the CSYNC record itself. Thus, implementations of this protocol 548 MUST NOT use it to synchronize DS records, DNSKEY materials, CDS 549 records, CDNSKEY records, or CSYNC records. Similarly, future 550 documents extending this protocol MUST NOT offer the ability to 551 synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or 552 CSYNC records. For such a solution, please see the complimentary 553 solution [RFC7344] for maintaining security delegation information. 555 To ensure that an older CSYNC record making use of the soaminimum 556 flag can not be replayed to revert values, the SOA serial number MUST 557 NOT be incremented by more than 2^16 during the lifetime of the 558 signature window of the associated RRSIGs signing the SOA and CSYNC 559 records. Note that this is independent of whether or not the 560 increment causes the 2^32 bit serial number field to wrap. 562 6. IANA Considerations 564 This document defines a new DNS Resource Record Type, named "CSYNC". 565 The IANA is requested to assign a code point from the "Resource 566 Record (RR) TYPEs" sub-registry of the "Domain Name System (DNS) 567 Parameters" registry (http://www.iana.org/assignments/dns-parameters) 568 for this record. 570 TYPE Value Meaning Reference 571 ----- ------ -------------------------- ----------- 572 CSYNC TBD Child To Parent Synchronization [This document] 574 The IANA is also requested to create and maintain a sub-registry (the 575 "Child Synchronization (CSYNC) Flags" registry) of the "Domain Name 576 System (DNS) Parameters" registry. The initial values for this 577 registry are below. 579 A "Standards Action" [RFC5226] is required for the assignment of new 580 flag value. 582 This registry will hold a set of single-bit "Flags" for use in the 583 CSYNC record within the 16 bit Flags field. Thus, a maximum of 16 584 flags may be defined. 586 The initial assignments in this registry are: 588 Bit Flag Description Reference 589 ---- ------ ------------- ----------- 590 Bit 0 immediate Immediately process this [This document, 591 CSYNC record. Section 3] 593 Bit 1 soaminimum Require a SOA serial [This document, 594 number greater than the Section 2.1.1.1] 595 one specified. 597 For new assignments to be made to this registry, a new standards 598 track RFC must be published via a Standards Action. 600 7. Acknowledgments 602 A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson, 603 who's work on the CDS record type helped inspire the work in this 604 document, as well as the definition for the "parental agent" 605 definition and significant contributions to the text. A thank you 606 also goes out to Ed Lewis, with whom the author held many 607 conversations with about the issues surrounding parent/child 608 relationships and synchronization. Much of the work in this document 609 is derived from the careful existing analysis of these three esteemed 610 colleagues. Thank you to the following people who have contributed 611 text or detailed reviews to the document (in no particular order): 612 Matthijs Mekking, Petr Spacek, 神明達哉, Pete 613 Resnick, Joel Jaeggli, Brian Haberman, Warren Kumari, Adrian Farrel, 614 Alia Atlas, Barry Leiba, Richard Barnes, Stephen Farrell, and Ted 615 Lemon. Lastly, the DNSOP working group chairs Tim Wicinski and 616 Suzanne Woolf have been a tremendous help in getting this draft 617 moving forward to publication. 619 A special thanks goes to Roy Arends, for taking the "bite out of that 620 hamburger" challenge while discussing this document. 622 8. References 624 8.1. Normative References 626 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 627 August 1996. 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 633 (RR) Types", RFC 3597, September 2003. 635 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 636 Rose, "Resource Records for the DNS Security Extensions", 637 RFC 4034, March 2005. 639 8.2. Informative References 641 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 642 STD 13, RFC 1034, November 1987. 644 [RFC1035] Mockapetris, P., "Domain names - implementation and 645 specification", STD 13, RFC 1035, November 1987. 647 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 648 Rose, "DNS Security Introduction and Requirements", 649 RFC 4033, March 2005. 651 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 652 Rose, "Protocol Modifications for the DNS Security 653 Extensions", RFC 4035, March 2005. 655 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 656 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 657 May 2008. 659 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 660 DNSSEC Delegation Trust Maintenance", RFC 7344, 661 September 2014. 663 Author's Address 665 Wes Hardaker 666 Parsons, Inc. 667 P.O. Box 382 668 Davis, CA 95617 669 US 671 Phone: +1 530 792 1913 672 Email: ietf@hardakers.net