idnits 2.17.1 draft-hardaker-dnsop-csync-01.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 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 a web interface). == 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: Parental agents MUST check that at least one of the to-be-published DS records within the new set points to a "secure" DNSSEC-validated DNSKEY record. IE, updating of the DS record set within the parent zone MUST not be done if the parental agent determines it will no longer be possible to validate the zone data within the child. [XXX: yes, a discussion is needed about algorithm and other support differences]. -- The document date (July 14, 2013) is 3932 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 559, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 569, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 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 July 14, 2013 5 Expires: January 15, 2014 7 Child To Parent Synchronization in DNS 8 draft-hardaker-dnsop-csync-01 10 Abstract 12 This document specifies how a child zone in the DNS can publish a 13 record that can indicate that a parental agent 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 to either assist in 16 transferring or automatically transfer data from the child to the 17 parent. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 15, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology Used in This Document . . . . . . . . . . . . 3 55 2. Definition of the CSYNC RRType . . . . . . . . . . . . . . . . 4 56 2.1. The CSYNC Resource Record Format . . . . . . . . . . . . . 4 57 2.1.1. The CSYNC Resource Record Wire Format . . . . . . . . 4 58 2.1.2. The CSYNC Presentation Format . . . . . . . . . . . . 6 59 2.1.3. CSYNC RR Example . . . . . . . . . . . . . . . . . . . 6 60 2.2. CSYNC Data Processing . . . . . . . . . . . . . . . . . . 6 61 2.2.1. Processing Procedure . . . . . . . . . . . . . . . . . 7 62 2.2.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . 7 63 2.3. Operational Considerations . . . . . . . . . . . . . . . . 10 64 2.3.1. Error Reporting . . . . . . . . . . . . . . . . . . . 10 65 2.3.2. Child Nameserver Selection . . . . . . . . . . . . . . 11 66 2.3.3. Documented Parental Agent Type Support . . . . . . . . 11 67 2.3.4. Other Considerations . . . . . . . . . . . . . . . . . 12 68 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 [Up front note: this document is very rough in wording. It is 79 offered as a starting point to see if there is interest in pursuing 80 the concepts contained herein before significant work is done on 81 wording refinements] 83 This document specifies how a child zone in the DNS can publish a 84 record that can indicate that a parental agent may copy and process 85 certain records from the child zone. The existence and change of the 86 record may be monitored by a parental agent to either assist in 87 transferring or automatically transfer data from the child to the 88 parent. 90 Some resource records (RRs) in a parent zone are typically expected 91 to be in-sync with the data in the child's zone. The most common 92 records that should match are the nameserver (NS) records and any 93 necessary associated address (A and AAAA) "glue" records. 94 Additionally, the children frequently have DNSKEY records which 95 require corresponding DS record(s) in the parent. These records are 96 referred to as "delegation records". 98 It has been traditionally challenging for children to keep delegation 99 records within a parent's delegation record set up to date. This 100 difficult has usually derived from simple operator laziness or the 101 complexities of maintaining a large number of DNS zones. Having an 102 automated mechanism to update a parent's set of delegation records 103 will greatly ease the child zone operator's maintenance burden and 104 improve the robustness of the DNS as a whole. 106 This draft introduces a new RR type (RRType) named "CSYNC" that 107 indicates which delegation records within a child should be processed 108 into the parent's DNS zone data. 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. In this case the parent consists of 120 Registrar and Registry, with different rules on what each can do or 121 not do. To remain operating model neutral we will use the neutral 122 word "Parental Agent" as the entity that uses results of DNS queries 123 to inject delegation changes into the parent zone. The entity that 124 inserts the changes in the the DNS is called "DNS Publisher". 126 2. Definition of the CSYNC RRType 128 The CSYNC RRType contains, in its RDATA component, these parts: an 129 SOA serial number, a set of flags and a simple bit-list indicating 130 the DNS RRTypes in the child that should be processed by the parent 131 agent to modify the DNS delegation records for the child within the 132 parent's zone. Children wanting a parental agent to perform a 133 synchronization MUST publish a CSYNC record at the apex of the child 134 zone. Parent agent implementations MAY choose to query child zones 135 for this record and process the data indicated by the Type Bit Map 136 field in the RDATA of the CSYNC record. How the data is processed is 137 later described in Section Section 2.2. 139 Parental agents MUST process the entire set of child data requested 140 (i.e., all record types indicated along with all of the necessary 141 records to support processing of that type) or else parent agents 142 MUST NOT process any data records at all. Errors due to unsupported 143 Type Bit Map bits or otherwise nonpunishable data SHALL result in no 144 change to the parent zone's delegation information for the child. 145 Parental agents SHOULD ignore a child's CSYNC RDATA set if multiple 146 CSYNC resource records are found; only a single CSYNC record should 147 be expected. 149 The parental agent MUST perform DNSSEC validation of the CSYNC RRType 150 data and MUST perform DNSSEC validation of any data to be copied from 151 the child to the parent. Parents MUST not process any data if any of 152 the validation results indicate any anything other than "Secure" 153 [RFC4034]. 155 2.1. The CSYNC Resource Record Format 157 2.1.1. The CSYNC Resource Record Wire Format 159 The CSYNC RDATA consists of the following fields: 161 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | SOA Serial | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Flags | Type Bit Map / 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 / Type Bit Map (continued) / 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 2.1.1.1. The SOA Serial Field 173 The SOA Serial field contains a copy of the 32-bit SOA serial number 174 from the child zone. If the value is non-zero, parental agent 175 querying children's authoritative servers MUST NOT act on data from 176 zones advertising an SOA serial number less than this value. A 177 special value of 0 indicates that no such restriction is in place. 179 Note that a child zone's current SOA serial number maybe greater than 180 the number contained in the CSYNC record. A child SHOULD update the 181 SOA Serial field in the CSYNC record every time the data being 182 referenced by the CSYNC record is changed (e.g. an NS record or 183 associated address record is changed). A child MAY choose to update 184 the SOA Serial field to always match the current SOA serial field. 186 Parental agents MAY cache SOA serial numbers from data they use and 187 refuse to process data from zones older than the last instance they 188 pulled data from. 190 2.1.1.2. The Flags Field 192 The Flags field contains 16 bits of flags defining operations that 193 affect the processing of the CSYNC record. The flags defined in this 194 document are as follows: 196 0x00 0x01: "immediate" 198 The definitions for how the flags are to be used can be found later 199 in Section Section 2.2. 201 The remaining flags are reserved for use by future specifications. 202 Undefined flags MUST be set to 0 by CSYNC publishers. Parental 203 agents MUST NOT process a CSYNC record if it contains a 1 value for a 204 flag that is unknown to or unsupported by the parental agent. 206 2.1.1.2.1. The Type Bit Map Field 208 The Type Bit Map field indicates the record types to be processed by 209 the parental agent, according to the procedures in Section 210 Section 2.2. The Type Bit Map field is encoded in the same way as 211 the Type Bit Maps field of the NSEC record, described in [RFC4034], 212 Section 4.1.2. If a bit has been set that a parental agent 213 implementation does not understand, the parental agent MUST NOT act 214 upon the data. Specifically, a parental agent must not copy data 215 blindly; A specification must exist [insert long debate here over 216 level of specification required; IMHO: proposed IETF standard since a 217 bit can only be used once] that defines how the data should be 218 processed for a given bit. 220 2.1.2. The CSYNC Presentation Format 222 The CSYNC presentation format is as follows: 224 The SOA Serial field is represented as an integer. 226 The Flags field is represented as an integer. 228 The Type Bit Map field is represented as a sequence of RR type 229 mnemonics. When the mnemonic is not known, the TYPE 230 representation described in [RFC3597], Section 5, MUST be used. 232 2.1.3. CSYNC RR Example 234 The following CSYNC RR shows an example entry for "example.com" that 235 indicates the NS, A and AAAA bits are set and should be processed by 236 the parental agent for example.com. The parental agent should pull 237 data only from a zone using a minimum SOA serial number of 66 (0x42 238 in hexadecimal). 240 example.com. 3600 IN CSYNC 66 1 A NS AAAA 242 The RDATA component of the example CSYNC RR would be encoded on the 243 wire as follows: 245 0x00 0x00 0x00 0x42 (SOA Serial) 246 0x00 0x01 (Flags) 247 0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map) 249 2.2. CSYNC Data Processing 251 The CSYNC data must be processed as an "all or nothing" type 252 operation. If a parental agent fails to query for any of the 253 required records from the child, the whole operation MUST be aborted. 254 (Note that a query resulting in "no records exist" as proven by NSEC 255 or NSEC3 is to be considered successful). 257 Parental agents MAY: 259 Process the CSYNC record immediately after noticing it if the 260 "immediate" flag is set. If the "immediate" flag is not set, the 261 parental agent MUST not act until the zone administrator approves 262 the operation through an out-of-band mechanism (such as through a 263 web interface). 265 Require that the child zone administrator approve the operation 266 through an out-of-band mechanism (such as through a web 267 interface). I.e., a parental agent MAY choose not to support the 268 "immediate" flag. 270 Note: how the approval is done out-of-band is outside the scope of 271 this document and likely specific to a particular parental agent. 273 2.2.1. Processing Procedure 275 The following shows a sequence of steps that SHOULD be used when 276 collecting and processing CSYNC records from a child zone. Because 277 DNS queries are not allowed to contain more than one question at a 278 time, a sequence of requests will be needed. To ensure a single host 279 is being addressed, DNS over TCP SHOULD be used to avoid conversing 280 with multiple nodes at an anycast address. 282 1. Query for the child zone's SOA record 284 2. Query for the child zone's CSYNC record 286 3. Query for the child zone's data records, as required by the CSYNC 287 record's Type Bit Map field 289 4. Query for the child zone's SOA record again 291 If the SOA records from the first and last steps have different 292 serial numbers, then this CSYNC record set MUST NOT be processed. 294 If the SOA serial number(s) are less than the CSYNC record's SOA 295 Serial Field, the record MUST NOT be processed. If state is being 296 kept and the SOA serial number is less than the last time a CSYNC 297 record was processed, this CSYNC record SHOULD NOT be processed. 299 If DNSSEC fails to validate all of the data returned as "secure", 300 this CSYNC record MUST NOT be processed. 302 See the "Operational Consideration" section (Section Section 2.3) for 303 additional guidance about processing. 305 2.2.2. CSYNC Record Types 307 This document defines how the following record types may be processed 308 if the CSYNC Type Bit Map field indicates they should be processed. 310 2.2.2.1. The NS type 312 The NS type flag indicates that the NS records from the child zone 313 should be copied into the parent's delegation information records for 314 the child. 316 NS records found within the child's zone should be copied verbatim 317 and the result published within the parent zone should be a matching 318 set of NS records. Note: if NS records in the parent's delegation 319 records for the child contain records that have been removed in the 320 child's NS set, then they should be removed in the parent's set as 321 well. 323 Parental agents MAY refuse to perform NS updates if the replacement 324 records fail to meet NS record policies required by the parent zone 325 (e.g. "every child zone must have at least 2 NS records"). 327 2.2.2.2. The A and AAAA types 329 The A and AAAA type flags indicates that the A and AAAA, 330 respectively, address glue records for in-bailiwick NS records within 331 the child zone should be copied into the parent's delegation 332 information. 334 Queries should be sent by the parental agent to determine the A and 335 AAAA record addresses for each NS record within a NS set for the 336 child that are in-bailiwick. 338 Note: only the matching types should be queried. E.g., if the AAAA 339 bit has not been set, then the AAAA records (if any) in the parent's 340 delegation should remain as is. If a given address type is set and 341 the child's zone contains no data for that type (as proven by 342 appropriate NSEC or NSEC3 records), then the result in the parent's 343 delegation records for the child should be an empty set. 345 The procedure for querying for A and AAAA records MUST occur after 346 the procedure, if required, for querying for NS records as defined in 347 Section Section 2.2.2.1. This ensures that the right set NS records 348 is used as provided by the current NS set of the child. I.e, for 349 CSYNC records that have the NS bit set, the NS set used should be the 350 ones pulled from the child during processing. For CSYNC records 351 without the NS bit set, the existing NS records within the parent 352 should be used to determine which A and/or AAAA records to search 353 for. 355 2.2.2.3. The DNSKEY type 357 [Editors note: originally I was going to present this draft with no 358 support for DS records as the CDS draft existed and looked like a 359 mechansim that better covered all the DS specific usage cases. 360 However, I've added this section as a discussion point for another 361 mechansim based on conversations with IETF members. CSYNC may or may 362 not be sufficient and opinions are sought about whether CSYNC is a 363 viable mechansim for DS replacement or not.] 364 The DNSKEY type bit indicates that the DNSKEY records in the child 365 with the SEP bit set and the REVOKE bit cleared should be used to 366 create a new set of DS records for inclusion in the parent's 367 delegation records for the child zone. 369 A query should be sent to the child zone to obtain all the DNSKEY 370 records within the zone, and DS records should be generated for the 371 appropriate keys. 373 The DNSKEY type bit MUST NOT be set when the owner/maintainer of the 374 DNSKEY records for a zone that don't contain a set SEP bit is 375 different than the owner/maintainer of the DNSKEY records with the 376 SEP bit set. Organizationally, if the maintainers of the DNSKEY 377 records used to sign the entire contents of the zone are different 378 than the keys intended for the purpose of a secure-entry-point, it is 379 important than only the maintainers of the SEP bit set of DNSKEYs may 380 replace pointers to the SEP bit set of DNSKEYs. 382 Note: this DS change mechansim does not provide the client with the 383 ability to select (in-band) the DS algorithms used in the parent. 384 The DS type bit should be used instead if both the parent and child 385 wish the child to be able to select the DS algorithm(s) to be used. 386 Children that wish to do so should use the DS type bit instead, if 387 their parental agent supports it. 389 Note: this DS change mechansim does not let children publish DS 390 records that point to not-yet-published DNSKEYs. Children that wish 391 to do so should use the DS type bit instead, if their parental agent 392 supports it. 394 2.2.2.4. The DS type 396 [Editors note: originally I was going to present this draft with no 397 support for DS records as the CDS draft existed and looked like a 398 mechansim that better covered all the DS specific usage cases. 399 However, I've added this section as a discussion point for another 400 mechansim based on conversations with IETF members. CSYNC may or may 401 not be sufficient and opinions are sought about whether CSYNC is a 402 viable mechansim for DS replacement or not.] 404 The DS type bit indicates that the child has created and published DS 405 records within the child's zone (i.e., below the cut-point) and these 406 records should be copied into the parent's delegation records for the 407 child zone. 409 A query should be sent to the child zone to obtain all the DS records 410 within the zone, and the DS records should found should be copied 411 into the parent zone's delegation records for the child zone. 413 The DNSKEY type bit MUST NOT be set when the owner/maintainer of the 414 DNSKEY records for a zone that don't contain a set SEP bit is 415 different than the owner/maintainer of the DNSKEY records with the 416 SEP bit set. Organizationally, if the maintainers of the DNSKEY 417 records used to sign the entire contents of the zone are different 418 than the keys intended for the purpose of a secure-entry-point, it is 419 important than only the maintainers of the SEP bit set of DNSKEYs may 420 replace pointers to the SEP bit set of DNSKEYs. 422 Parental agents MUST check that at least one of the to-be-published 423 DS records within the new set points to a "secure" DNSSEC-validated 424 DNSKEY record. IE, updating of the DS record set within the parent 425 zone MUST not be done if the parental agent determines it will no 426 longer be possible to validate the zone data within the child. [XXX: 427 yes, a discussion is needed about algorithm and other support 428 differences]. 430 Note: this DS change mechansim does not let the parent select the 431 algorithms for the DS record to be used. The parent MAY choose not 432 to support the DS type bit if they wish to establish policy for DS 433 algorithm usage within their children's zones. In this case, the 434 parental agent should support the DNSKEY type bit instead. 436 Note: this DS change mechansim lets children publish DS records that 437 may point to unpublished DNSKEY records. 439 [Editors note: I'm not sure it's safe to reuse the DS record type 440 here. Having two different DS sets at a parent and child is 441 questionably safe from a validator's point of view. It's unclear the 442 effect that it might have on existing deployed code, and it would 443 seem safer to me to publish a new record type, such as the CDS type, 444 for querying child DS records rather than reusing the existing DS 445 type. Opinions desired.] 447 [One option would be to publish the DS records at a separate 448 location, such as _ds._dns.example.com] 450 2.3. Operational Considerations 452 There are a number of important things to consider when deploying a 453 CSYNC RRType. 455 2.3.1. Error Reporting 457 There is no inline mechanism for a parental agent to report errors to 458 child zones. Thus, the only error reporting mechanisms must be out 459 of band, such as through a web console or over email. Child 460 operators utilizing the "immediate" flag that fail to see an update 461 within the parental agent's specified operational window should 462 access the parental agent's log interface to determine why an update 463 failed to be processed. 465 2.3.2. Child Nameserver Selection 467 Parental agents will need to poll child nameservers in search of 468 CSYNC records and any other data required for processing a CSYNC 469 record. 471 Parental agents MAY perform best-possible verification by querying 472 all NS records for available data to determine which has the most 473 recent SOA and CSYNC version (in an ideal world, they would all be 474 equal but this is not possible in practice due to synchronization 475 delays and transfer failures). 477 Parental agents MAY offer a configuration interface to allow child 478 operators to specify which nameserver should be considered the master 479 to send data queries too. Child operators should be encouraged to 480 make use of this configuration interface. 482 2.3.3. Documented Parental Agent Type Support 484 Parental agents that support processing CSYNC records SHOULD publicly 485 document the following minimum processing characteristics: 487 The fact that they support CSYNC processing 489 The Type Bit Map bits they support 491 The frequency with which they poll clients (which MAY be 492 configurable by the client) 494 If they support the "immediate" flag 496 If they poll a child's single nameserver, a configured list of 497 nameservers, or all of the advertised nameservers when querying 498 records 500 If they support SOA serial number caching to avoid issues with 501 regression and/or replay 503 Where errors for CSYNC processing are published 505 2.3.4. Other Considerations 507 TBD 509 XXX: Discuss complete replacement scenarios and if allowed. 511 XXX: Polling frequency discussion 513 XXX: differences between DS and DNSKEY type bits 515 3. Security Considerations 517 TBD 519 XXX: mention over and over that DNSSEC validation is required for 520 every request 522 XXX: discussion on DNSSEC checking requirements for both before and 523 after changes take place. 525 XXX: mention that DS records for SEP-bit DNSKEYs being updating by 526 CSYNC records signed by non-SEP bits should be carefully considered 527 before being used. 529 4. IANA Considerations 531 TBD 533 5. Acknowledgments 535 A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson, 536 who's work on the CDS record type helped inspire the work in this 537 document, as well as the definition for "Parental Agent" and "DNS 538 Publisher" definitions. A thank you also goes out to Ed Lewis, who 539 the author held many conversations with about the issues surrounding 540 parent/child relationships and synchronization. Much of the work in 541 this document is derived from the careful existing analysis of these 542 three esteemed colleagues. 544 6. References 545 6.1. Normative References 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 551 (RR) Types", RFC 3597, September 2003. 553 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 554 Rose, "Resource Records for the DNS Security Extensions", 555 RFC 4034, March 2005. 557 6.2. Informative References 559 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 560 STD 13, RFC 1034, November 1987. 562 [RFC1035] Mockapetris, P., "Domain names - implementation and 563 specification", STD 13, RFC 1035, November 1987. 565 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 566 Rose, "DNS Security Introduction and Requirements", 567 RFC 4033, March 2005. 569 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 570 Rose, "Protocol Modifications for the DNS Security 571 Extensions", RFC 4035, March 2005. 573 Author's Address 575 Wes Hardaker 576 Parsons, Inc. 577 P.O. Box 382 578 Davis, CA 95617 579 US 581 Phone: +1 530 792 1913 582 Email: ietf@hardakers.net