idnits 2.17.1 draft-ietf-dnsop-child-syncronization-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The parental agent MUST perform DNSSEC validation of the CSYNC RRType data and MUST perform DNSSEC validation of any data to be copied from the child to the parent. Parents MUST not process any data from any of these records if any of the validation results indicate any anything other than "Secure" [RFC4034]. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Process the CSYNC record immediately after noticing it if the "immediate" flag is set. If the "immediate" flag is not set, the parental agent MUST not act until the zone administrator approves the operation through an out-of-band mechanism (such as through pushing a button via a web interface). -- The document date (February 14, 2014) is 3722 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) == Unused Reference: 'RFC1034' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 490, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 February 14, 2014 5 Expires: August 18, 2014 7 Child To Parent Synchronization in DNS 8 draft-ietf-dnsop-child-syncronization-00 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 it may copy and process 14 certain records from the child zone. The existence and change of the 15 record may be monitored by a parental agent, after which the parent 16 may act on the data appropriately. 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 August 18, 2014. 35 Copyright Notice 37 Copyright (c) 2014 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 . . . . . . . . 4 57 2.1.2. The CSYNC Presentation Format . . . . . . . . . . . . 6 58 2.1.3. CSYNC RR Example . . . . . . . . . . . . . . . . . . . 6 59 2.2. CSYNC Data Processing . . . . . . . . . . . . . . . . . . 7 60 2.2.1. Processing Procedure . . . . . . . . . . . . . . . . . 7 61 2.2.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . 8 62 2.3. Operational Considerations . . . . . . . . . . . . . . . . 9 63 2.3.1. Error Reporting . . . . . . . . . . . . . . . . . . . 9 64 2.3.2. Child Nameserver Selection . . . . . . . . . . . . . . 9 65 2.3.3. Documented Parental Agent Type Support . . . . . . . . 10 66 2.3.4. Other Considerations . . . . . . . . . . . . . . . . . 10 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 This document specifies how a child zone in the DNS can publish a 78 record to indicate to a parental agent that it may copy and process 79 certain records from the child zone. The existence and change of the 80 record may be monitored by a parental agent, after which the parent 81 may act on the data appropriately. 83 Some resource records (RRs) in a parent zone are typically expected 84 to be in-sync with the source data in the child's zone. The most 85 common records, to date, that should match are the nameserver (NS) 86 records and any necessary associated address "glue" records (A and 87 AAAA). These records are referred to as "delegation records". 89 It has been traditionally challenging for children to update their 90 delegation records within the parent's set in a timely fashion. This 91 difficulty is frequently from simple operator laziness or because of 92 the complexities of maintaining a large number of DNS zones. Having 93 an automated mechanism for signaling updates will greatly ease the 94 child zone operator's maintenance burden and improve the robustness 95 of the DNS as a whole. 97 This draft introduces a new RR type (RRType) named "CSYNC" that 98 indicates which delegation records published by a child should be 99 processed by a parental agent and used to update the parent zone's 100 DNS data. 102 This specification does not address how to perform bootstrapping 103 operations to get the required initial DNSSEC-secured operating 104 environment in place. Additionally, this specification was not 105 designed to synchronize DNSSEC security records, such as DS pointers. 106 For such a solution, please see the complimentary solution 107 [I-D.kumari-ogud-dnsop-cds] for maintaining security delegation 108 information. 110 1.1. Terminology Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 This document is aimed at the case where there is an organizational 117 separation of the child and parent. In this case there are many 118 different operating situations. A common case is the Registrant/ 119 Registrar/Registry relationship, used by many Top Level Domains in 120 the DNS. In this case, the parent consists of Registrar and 121 Registry, with different rules about what each can do or not do. To 122 remain operating model neutral we will use the neutral word "Parental 123 Agent" as the entity that uses results of DNS queries discussed in 124 this document to update the delegation records into the parent zone. 125 The entity that performs the changes in the the DNS is called "DNS 126 Publisher". 128 2. Definition of the CSYNC RRType 130 The CSYNC RRType contains, in its RDATA component, these parts: an 131 SOA serial number, a set of flags and a simple bit-list indicating 132 the DNS RRTypes in the child that should be processed by the parental 133 agent in order to modify the DNS delegation records for the child 134 within the parent's zone. Children wanting a parental agent to 135 perform the synchronization steps outlined in this document MUST 136 publish a CSYNC record at the apex of the child zone. Parental agent 137 implementations MAY choose to query child zones for this record and 138 process DNS record data as indicated by the Type Bit Map field in the 139 RDATA of the CSYNC record. How the data is processed is described 140 later in Section Section 2.2. 142 Parental agents MUST process the entire set of child data indicated 143 by the Type Bit Map field (i.e., all record types indicated along 144 with all of the necessary records to support processing of that type) 145 or else parental agents MUST NOT make any changes to parental records 146 at all. Errors due to unsupported Type Bit Map bits or otherwise 147 nonpunishable data SHALL result in no change to the parent zone's 148 delegation information for the child. Parental agents MUST ignore a 149 child's CSYNC RDATA set if multiple CSYNC resource records are found; 150 only a single CSYNC record should ever be expected. 152 The parental agent MUST perform DNSSEC validation of the CSYNC RRType 153 data and MUST perform DNSSEC validation of any data to be copied from 154 the child to the parent. Parents MUST not process any data from any 155 of these records if any of the validation results indicate any 156 anything other than "Secure" [RFC4034]. 158 2.1. The CSYNC Resource Record Format 160 2.1.1. The CSYNC Resource Record Wire Format 162 The CSYNC RDATA consists of the following fields: 164 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | SOA Serial | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Flags | Type Bit Map / 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 / Type Bit Map (continued) / 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 2.1.1.1. The SOA Serial Field 176 The SOA Serial field contains a copy of the 32-bit SOA serial number 177 from the child zone. If the value is non-zero, parental agents 178 querying children's authoritative servers MUST NOT act on data from 179 zones advertising an SOA serial number less than this value. A 180 special value of 0 indicates that no such restriction is in place. 182 Note that a child zone's current SOA serial number may be greater 183 than the number indicated by the CSYNC record. A child SHOULD update 184 the SOA Serial field in the CSYNC record every time the data being 185 referenced by the CSYNC record is changed (e.g. an NS record or 186 associated address record is changed). A child MAY choose to update 187 the SOA Serial field to always match the current SOA serial field. 189 Parental agents MAY cache SOA serial numbers from data they use and 190 refuse to process data from zones older than the last instance they 191 pulled data from. 193 2.1.1.2. The Flags Field 195 The Flags field contains 16 bits of flags defining operations that 196 affect the processing of the CSYNC record. The flags defined in this 197 document are as follows: 199 0x00 0x01: "immediate" 201 The definitions for how the flags are to be used can be found later 202 in Section Section 2.2. 204 The remaining flags are reserved for use by future specifications. 205 Undefined flags MUST be set to 0 by CSYNC publishers. Parental 206 agents MUST NOT process a CSYNC record if it contains a 1 value for a 207 flag that is unknown to or unsupported by the parental agent. 209 2.1.1.2.1. The Type Bit Map Field 211 The Type Bit Map field indicates the record types to be processed by 212 the parental agent, according to the procedures in Section 213 Section 2.2. The Type Bit Map field is encoded in the same way as 214 the Type Bit Maps field of the NSEC record, described in [RFC4034], 215 Section 4.1.2. If a bit has been set that a parental agent 216 implementation does not understand, the parental agent MUST NOT act 217 upon the record. Specifically: a parental agent must not copy data 218 blindly; An IETF proposed (or higher) standard specification must 219 exist that defines how the data should be processed for a given bit. 221 2.1.2. The CSYNC Presentation Format 223 The CSYNC presentation format is as follows: 225 The SOA Serial field is represented as an integer. 227 The Flags field is represented as an integer. 229 The Type Bit Map field is represented as a sequence of RR type 230 mnemonics. When the mnemonic is not known, the TYPE 231 representation described in [RFC3597], Section 5, MUST be used. 232 Implementations that support parsing of presentation format 233 records SHOULD be able to read and understand these TYPE 234 representations as well. 236 2.1.3. CSYNC RR Example 238 The following CSYNC RR shows an example entry for "example.com" that 239 indicates the NS, A and AAAA bits are set and should be processed by 240 the parental agent for example.com. The parental agent should pull 241 data only from a zone using a minimum SOA serial number of 66 (0x42 242 in hexadecimal). 244 example.com. 3600 IN CSYNC 66 1 A NS AAAA 246 The RDATA component of the example CSYNC RR would be encoded on the 247 wire as follows: 249 0x00 0x00 0x00 0x42 (SOA Serial) 250 0x00 0x01 (Flags [the immediate bit is set]) 251 0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map) 253 2.2. CSYNC Data Processing 255 The CSYNC record and associated data must be processed as an "all or 256 nothing" operation set. If a parental agent fails to successfully 257 query for any of the required records, the whole operation MUST be 258 aborted. (Note that a query resulting in "no records exist" as 259 proven by NSEC or NSEC3 is to be considered successful). 261 Parental agents MAY: 263 Process the CSYNC record immediately after noticing it if the 264 "immediate" flag is set. If the "immediate" flag is not set, the 265 parental agent MUST not act until the zone administrator approves 266 the operation through an out-of-band mechanism (such as through 267 pushing a button via a web interface). 269 Require that the child zone administrator approve the operation 270 through an out-of-band mechanism (such as through pushing a button 271 via a web interface). I.e., a parental agent MAY choose not to 272 support the "immediate" flag. 274 Note: how the approval is done out-of-band is outside the scope of 275 this document and is implementation-specific to parental agents. 277 2.2.1. Processing Procedure 279 The following shows a sequence of steps that SHOULD be used when 280 collecting and processing CSYNC records from a child zone. Because 281 DNS queries are not allowed to contain more than one "question" at a 282 time, a sequence of requests is needed. When processing a CSYNC 283 transaction request, all DNS queries should be sent to a single 284 authoritative name server for the child zone. To ensure a single 285 host is being addressed, DNS over TCP SHOULD be used to avoid 286 conversing with multiple nodes at an anycast address. 288 1. Query for the child zone's SOA record 290 2. Query for the child zone's CSYNC record 292 3. Query for the child zone's data records, as required by the CSYNC 293 record's Type Bit Map field 295 4. Query for the child zone's SOA record again 297 If the SOA records from the first and last steps have different 298 serial numbers, then the CSYNC record obtained in the second set MUST 299 NOT be processed. 301 If the SOA serial numbers are equal but less than the CSYNC record's 302 SOA Serial Field, the record MUST NOT be processed. If state is 303 being kept by the parental agent and the SOA serial number is less 304 than the last time a CSYNC record was processed, this CSYNC record 305 SHOULD NOT be processed. Similarly, if state is being kept by the 306 parental agent and the SOA Serial Field of the CSYNC record is less 307 than the SOA Serial Field of the CSYNC record from last time, then 308 this CSYNC record SHOULD NOT be processed. 310 If DNSSEC fails to validate all of the data returned for these 311 queries as "secure", then this CSYNC record MUST NOT be processed. 313 See the "Operational Consideration" section (Section Section 2.3) for 314 additional guidance about processing. 316 2.2.2. CSYNC Record Types 318 This document defines how the following record types may be processed 319 if the CSYNC Type Bit Map field indicates they should be processed. 321 2.2.2.1. The NS type 323 The NS type flag indicates that the NS records from the child zone 324 should be copied into the parent's delegation information records for 325 the child. 327 NS records found within the child's zone should be copied verbatim 328 and the result published within the parent zone should be an exact 329 matching set of NS records. If the child has published a new NS 330 record within their set, this record should be added to the parent 331 zone. Similarly, if NS records in the parent's delegation records 332 for the child contain records that have been removed in the child's 333 NS set, then they should be removed in the parent's set as well. 335 Parental agents MAY refuse to perform NS updates if the replacement 336 records fail to meet NS record policies required by the parent zone 337 (e.g. "every child zone must have at least 2 NS records"). 339 2.2.2.2. The A and AAAA types 341 The A and AAAA type flags indicates that the A and AAAA, 342 respectively, address glue records for in-bailiwick NS records within 343 the child zone should be copied into the parent's delegation 344 information. 346 Queries should be sent by the parental agent to determine the A and 347 AAAA record addresses for each NS record within a NS set for the 348 child that are in-bailiwick. 350 Note: only the matching types should be queried. E.g., if the AAAA 351 bit has not been set, then the AAAA records (if any) in the parent's 352 delegation should remain as is. If a given address type is set and 353 the child's zone contains no data for that type (as proven by 354 appropriate NSEC or NSEC3 records), then the result in the parent's 355 delegation records for the child should be an empty set. 357 The procedure for querying for A and AAAA records MUST occur after 358 the procedure, if required, for querying for NS records as defined in 359 Section Section 2.2.2.1. This ensures that the right set NS records 360 is used as provided by the current NS set of the child. I.e, for 361 CSYNC records that have the NS bit set, the NS set used should be the 362 ones pulled from the child while processing the CSYNC record. For 363 CSYNC records without the NS bit set, the existing NS records within 364 the parent should be used to determine which A and/or AAAA records to 365 update. 367 2.3. Operational Considerations 369 There are a number of important things to consider when deploying a 370 CSYNC RRType. 372 2.3.1. Error Reporting 374 There is no inline mechanism for a parental agent to report errors to 375 operators of child zones. Thus, the only error reporting mechanisms 376 must be out of band, such as through a web console or over email. 377 Child operators utilizing the "immediate" flag that fail to see an 378 update within the parental agent's specified operational window 379 should access the parental agent's error logging interface to 380 determine why an update failed to be processed. 382 2.3.2. Child Nameserver Selection 384 Parental agents will need to poll child nameservers in search of 385 CSYNC records and related data records. 387 Parental agents MAY perform best-possible verification by querying 388 all NS records for available data to determine which has the most 389 recent SOA and CSYNC version (in an ideal world, they would all be 390 equal but this is not possible in practice due to synchronization 391 delays and transfer failures). 393 Parental agents MAY offer a configuration interface to allow child 394 operators to specify which nameserver should be considered the master 395 to send data queries too. This master may not be one of the 396 publically listed nameservers in the NS set (i.e., it may be a 397 "hidden master"). 399 2.3.3. Documented Parental Agent Type Support 401 Parental agents that support processing CSYNC records SHOULD publicly 402 document the following minimum processing characteristics: 404 The fact that they support CSYNC processing 406 The Type Bit Map bits they support 408 The frequency with which they poll clients (which MAY also be 409 configurable by the client) 411 If they support the "immediate" flag 413 If they poll a child's single nameserver, a configured list of 414 nameservers, or all of the advertised nameservers when querying 415 records 417 If they support SOA serial number caching to avoid issues with 418 regression and/or replay 420 Where errors for CSYNC processing are published 422 If they support sending queries to a "hidden master". 424 2.3.4. Other Considerations 426 XXX: Discuss complete replacement scenarios and if allowed. 428 3. Security Considerations 430 This specification requires the use of DNSSEC in order to determine 431 that the data being updated was unmodified by third-parties. 432 Parental agents implementing CSYNC processing MUST ensure all DNS 433 transactions are validated by DNSSEC as "secure". Clients deploying 434 CSYNC MUST ensure their zones are signed, current and properly linked 435 to the parent zone with a DS record that points to an appropriate 436 DNSKEY of the child's zone. 438 This specification does not address how to perform bootstrapping 439 operations to get the required initial DNSSEC-secured operating 440 environment in place. Additionally, this specification was not 441 designed to synchronize DNSSEC security records, such as DS pointers. 442 For such a solution, please see the complimentary solution 443 [I-D.kumari-ogud-dnsop-cds] for maintaining security delegation 444 information. 446 4. IANA Considerations 448 TBD 450 5. Acknowledgments 452 A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson, 453 who's work on the CDS record type helped inspire the work in this 454 document, as well as the definition for "Parental Agent" and "DNS 455 Publisher" definitions. A thank you also goes out to Ed Lewis, who 456 the author held many conversations with about the issues surrounding 457 parent/child relationships and synchronization. Much of the work in 458 this document is derived from the careful existing analysis of these 459 three esteemed colleagues. 461 A special thanks goes to Roy Arends, for taking the "bite out of that 462 hamburger" challenge while discussing this document. 464 6. References 466 6.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 472 (RR) Types", RFC 3597, September 2003. 474 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 475 Rose, "Resource Records for the DNS Security Extensions", 476 RFC 4034, March 2005. 478 6.2. Informative References 480 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 481 STD 13, RFC 1034, November 1987. 483 [RFC1035] Mockapetris, P., "Domain names - implementation and 484 specification", STD 13, RFC 1035, November 1987. 486 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 487 Rose, "DNS Security Introduction and Requirements", 488 RFC 4033, March 2005. 490 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 491 Rose, "Protocol Modifications for the DNS Security 492 Extensions", RFC 4035, March 2005. 494 [I-D.kumari-ogud-dnsop-cds] 495 Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 496 DNSSEC delegation trust maintenance", 497 draft-kumari-ogud-dnsop-cds-05 (work in progress), 498 October 2013. 500 Author's Address 502 Wes Hardaker 503 Parsons, Inc. 504 P.O. Box 382 505 Davis, CA 95617 506 US 508 Phone: +1 530 792 1913 509 Email: ietf@hardakers.net