--- 1/draft-ietf-dnsop-child-syncronization-04.txt 2014-12-05 23:14:48.983309293 -0800 +++ 2/draft-ietf-dnsop-child-syncronization-05.txt 2014-12-05 23:14:49.015310074 -0800 @@ -1,18 +1,18 @@ DNSOP W. Hardaker Internet-Draft Parsons, Inc. -Intended status: Standards Track November 26, 2014 -Expires: May 30, 2015 +Intended status: Standards Track December 4, 2014 +Expires: June 7, 2015 Child To Parent Synchronization in DNS - draft-ietf-dnsop-child-syncronization-04 + draft-ietf-dnsop-child-syncronization-05 Abstract This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy. Status of this Memo @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 30, 2015. + This Internet-Draft will expire on June 7, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -52,42 +52,45 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology Used in This Document . . . . . . . . . . . . 3 2. Definition of the CSYNC RRType . . . . . . . . . . . . . . . . 4 2.1. The CSYNC Resource Record Format . . . . . . . . . . . . . 4 2.1.1. The CSYNC Resource Record Wire Format . . . . . . . . 5 2.1.2. The CSYNC Presentation Format . . . . . . . . . . . . 6 2.1.3. CSYNC RR Example . . . . . . . . . . . . . . . . . . . 6 3. CSYNC Data Processing . . . . . . . . . . . . . . . . . . . . 7 3.1. Processing Procedure . . . . . . . . . . . . . . . . . . . 7 3.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . . . 8 - 3.2.1. The NS type . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.1. The NS type . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. The A and AAAA types . . . . . . . . . . . . . . . . . 9 4. Operational Considerations . . . . . . . . . . . . . . . . . . 10 4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 10 4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 11 4.4. Documented Parental Agent Type Support . . . . . . . . . . 11 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 4.5. Removal of the CSYNC records . . . . . . . . . . . . . . . 12 + 4.6. Parent/Child/Grandchild Glue Synchronization . . . . . . . 12 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This document specifies how a child zone in the DNS ([RFC1034], - [RFC1035]) can publish a record to indicate to a parental agent that - it can copy and process certain records from the child zone. The - existence of the record and any change in its value can be monitored - by a parental agent and acted on depending on local policy. + [RFC1035]) can publish a record to indicate to a parental agent (see + section Section 2 for a definition of "parental agent") that it can + copy and process certain records from the child zone. The existence + of the record and any change in its value can be monitored by a + parental agent and acted on depending on local policy. Currently today, some resource records (RRs) in a parent zone are typically expected to be in sync with the source data in the child's zone. The most common records that should match are the nameserver (NS) records and any necessary associated address records (A and AAAA), also known as "glue records". These records are referred to as "delegation records". It has been challenging for operators of child DNS zones to update their delegation records within the parent's set in a timely fashion. @@ -153,21 +156,21 @@ at all. Errors due to unsupported Type Bit Map bits, or otherwise nonpunishable data, SHALL result in no change to the parent zone's delegation information for the Child. Parental agents MUST ignore a Child's CSYNC RDATA set if multiple CSYNC resource records are found; only a single CSYNC record should ever be present. The parental agent MUST perform DNSSEC validation ([RFC4033], [RFC4034], [RFC4035]), 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 + if any of the validation results indicate anything other than "Secure" [RFC4034] or if any the required data can not be successfully retrieved. 2.1. The CSYNC Resource Record Format 2.1.1. The CSYNC Resource Record Wire Format The CSYNC RDATA consists of the following fields: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 @@ -306,27 +309,39 @@ authoritative name server for the child zone. To ensure a single host is being addressed, DNS over TCP SHOULD be used to avoid conversing with multiple nodes at an anycast address. 1. Query for the child zone's SOA record 2. Query for the child zone's CSYNC record 3. Query for the child zone's data records, as required by the CSYNC record's Type Bit Map field - 4. Query for the child zone's SOA record again + * Note: if any of the resulting records being queried are not + authoritative within the child zone but rather in a grandchild + or deeper, SOA record queries must be made for the + grandchildren. This will require the parental agent to + determine where the child/grandchild zone cuts occur. Because + of the additional operational complexity, parental agents MAY + choose not to support this protocol with children making use + of records that are authoritative in the grandchildren. - If the SOA records from the first and last steps have different - serial numbers (for example, because the zone was edited and - republished during the interval between steps 1 and 4), then the - CSYNC record obtained in the second set MUST NOT be processed. The - operation MAY be restarted or retried in the future. + 4. Query for the collected SOA records again, starting with the + deepest and ending with the SOA of the child's. + + If the SOA records from the first, middle and last steps for a given + zone have different serial numbers (for example, because the zone was + edited and republished during the interval between steps 1 and 4), + then the CSYNC record obtained in the second set SHOULD NOT be + processed (rapidly changing child zones may need special + consideration or processing). The operation MAY be restarted or + retried in the future. If the soaminimum flag is set and the SOA serial numbers are equal but less than the CSYNC record's SOA Serial Field [RFC1982], the record MUST NOT be processed. If state is being kept by the parental agent and the SOA serial number is less than the last time a CSYNC record was processed, this CSYNC record SHOULD NOT be processed. Similarly, if state is being kept by the parental agent and the SOA Serial Field of the CSYNC record is less than the SOA Serial Field of the CSYNC record from last time, then this CSYNC record SHOULD NOT be processed. @@ -344,44 +359,48 @@ This document defines how the following record types may be processed if the CSYNC Type Bit Map field indicates they are to be processed. 3.2.1. The NS type The NS type flag indicates that the NS records from the child zone should be copied into the parent's delegation information records for the child. NS records found within the child's zone should be copied verbatim - and the result published within the parent zone should be an exact - matching set of NS records. If the child has published a new NS - record within their set, this record should be added to the parent - zone. Similarly, if NS records in the parent's delegation records - for the child contain records that have been removed in the child's - NS set, then they should be removed in the parent's set as well. + (with the exception of the TTL field, for which the parent MAY want + to select a different value) and the result published within the + parent zone should be an exact matching set of NS records. If the + child has published a new NS record within their set, this record + should be added to the parent zone. Similarly, if NS records in the + parent's delegation records for the child contain records that have + been removed in the child's NS set, then they should be removed in + the parent's set as well. Parental agents MAY refuse to perform NS updates if the replacement records fail to meet NS record policies required by the parent zone (e.g. "every child zone must have at least 2 NS records"). Parental agents MUST NOT perform NS updates if there are no NS records returned in a query, as verified by DNSSEC denial of existence protection. This situation should never happen unless the child nameservers are misconfigured. Note that it is permissible for a child's nameserver to return a CSYNC record that removes the queried nameserver itself from the future NS or address set. 3.2.2. The A and AAAA types The A and AAAA type flags indicates that the A and AAAA address glue records for in-bailiwick NS records within the child zone should be - copied into the parent's delegation information. + copied verbatim (with the exception of the TTL field, for which the + parent MAY want to select a different value) into the parent's + delegation information. Queries should be sent by the parental agent to determine the A and AAAA record addresses for each NS record within a NS set for the child that are in-bailiwick. Note: only the matching types should be queried. E.g., if the AAAA bit has not been set, then the AAAA records (if any) in the parent's delegation should remain as is. If a given address type is set and the child's zone contains no data for that type (as proven by appropriate NSEC or NSEC3 records), then the result in the parent's @@ -476,28 +495,48 @@ The Type Bit Map bits they support The frequency with which they poll clients (which may also be configurable by the client) If they support the "immediate" flag If they poll a child's single nameserver, a configured list of nameservers, or all of the advertised nameservers when querying records - If they support SOA serial number caching to avoid issues with regression and/or replay Where errors for CSYNC processing are published If they support sending queries to a "hidden master". +4.5. Removal of the CSYNC records + + Children MAY remove the CSYNC record upon noticing that the parent + zone has published the required records, thus eliminating the need + for the parent to continually query for the CSYNC record and all + corresponding records. By removing the CSYNC record from the child + zone, the parental agent will only need to perform the query for the + CSYNC record and can stop processing when it finds it missing. This + will reduce resource usage by both the child and the parental agent. + +4.6. Parent/Child/Grandchild Glue Synchronization + + When a child needs to publish a CSYNC record that synchronizes NS and + A/AAAA glue records and the NS record is actually pointing to a child + of the child (a grandchild of the parent), then it is critical that + the glue records in the child point to the proper real addresses + records published by the grandchild. It is assumed that if a child + is using a grandchild's nameserver that they must be in careful + synchronization. Specifically, this specification requires this to + be the case. + 5. Security Considerations This specification requires the use of DNSSEC in order to determine that the data being updated was unmodified by third-parties. Parental agents implementing CSYNC processing MUST ensure all DNS transactions are validated by DNSSEC as "secure". Clients deploying CSYNC MUST ensure their zones are signed, current and properly linked to the parent zone with a DS record that points to an appropriate DNSKEY of the child's zone. @@ -560,21 +599,27 @@ A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson, who's work on the CDS record type helped inspire the work in this document, as well as the definition for the "parental agent" definition and significant contributions to the text. A thank you also goes out to Ed Lewis, with whom the author held many conversations with about the issues surrounding parent/child relationships and synchronization. Much of the work in this document is derived from the careful existing analysis of these three esteemed colleagues. Thank you to the following people who have contributed - text to the document: Matthijs Mekking and Petr Spacek. + text or detailed reviews to the document (in no particular order): + Matthijs Mekking, Petr Spacek, 神明達哉, Pete + Resnick, Joel Jaeggli, Brian Haberman, Warren Kumari, Adrian Farrel, + Alia Atlas, Barry Leiba, Richard Barnes, Stephen Farrell, and Ted + Lemon. Lastly, the DNSOP working group chairs Tim Wicinski and + Suzanne Woolf have been a tremendous help in getting this draft + moving forward to publication. A special thanks goes to Roy Arends, for taking the "bite out of that hamburger" challenge while discussing this document. 8. References 8.1. Normative References [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.