draft-ietf-dnsop-child-syncronization-04.txt   draft-ietf-dnsop-child-syncronization-05.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Parsons, Inc. Internet-Draft Parsons, Inc.
Intended status: Standards Track November 26, 2014 Intended status: Standards Track December 4, 2014
Expires: May 30, 2015 Expires: June 7, 2015
Child To Parent Synchronization in DNS Child To Parent Synchronization in DNS
draft-ietf-dnsop-child-syncronization-04 draft-ietf-dnsop-child-syncronization-05
Abstract Abstract
This document specifies how a child zone in the DNS can publish a 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 record to indicate to a parental agent that the parental agent may
copy and process certain records from the child zone. The existence 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 of the record and any change in its value can be monitored by a
parental agent and acted on depending on local policy. parental agent and acted on depending on local policy.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used in This Document . . . . . . . . . . . . 3 1.1. Terminology Used in This Document . . . . . . . . . . . . 3
2. Definition of the CSYNC RRType . . . . . . . . . . . . . . . . 4 2. Definition of the CSYNC RRType . . . . . . . . . . . . . . . . 4
2.1. The CSYNC Resource Record Format . . . . . . . . . . . . . 4 2.1. The CSYNC Resource Record Format . . . . . . . . . . . . . 4
2.1.1. The CSYNC Resource Record Wire Format . . . . . . . . 5 2.1.1. The CSYNC Resource Record Wire Format . . . . . . . . 5
2.1.2. The CSYNC Presentation Format . . . . . . . . . . . . 6 2.1.2. The CSYNC Presentation Format . . . . . . . . . . . . 6
2.1.3. CSYNC RR Example . . . . . . . . . . . . . . . . . . . 6 2.1.3. CSYNC RR Example . . . . . . . . . . . . . . . . . . . 6
3. CSYNC Data Processing . . . . . . . . . . . . . . . . . . . . 7 3. CSYNC Data Processing . . . . . . . . . . . . . . . . . . . . 7
3.1. Processing Procedure . . . . . . . . . . . . . . . . . . . 7 3.1. Processing Procedure . . . . . . . . . . . . . . . . . . . 7
3.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . . . 8 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 3.2.2. The A and AAAA types . . . . . . . . . . . . . . . . . 9
4. Operational Considerations . . . . . . . . . . . . . . . . . . 10 4. Operational Considerations . . . . . . . . . . . . . . . . . . 10
4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10
4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 10 4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 10
4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 11 4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 11
4.4. Documented Parental Agent Type Support . . . . . . . . . . 11 4.4. Documented Parental Agent Type Support . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.5. Removal of the CSYNC records . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4.6. Parent/Child/Grandchild Glue Synchronization . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document specifies how a child zone in the DNS ([RFC1034], This document specifies how a child zone in the DNS ([RFC1034],
[RFC1035]) can publish a record to indicate to a parental agent that [RFC1035]) can publish a record to indicate to a parental agent (see
it can copy and process certain records from the child zone. The section Section 2 for a definition of "parental agent") that it can
existence of the record and any change in its value can be monitored copy and process certain records from the child zone. The existence
by a parental agent and acted on depending on local policy. 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 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 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 zone. The most common records that should match are the nameserver
(NS) records and any necessary associated address records (A and (NS) records and any necessary associated address records (A and
AAAA), also known as "glue records". These records are referred to AAAA), also known as "glue records". These records are referred to
as "delegation records". as "delegation records".
It has been challenging for operators of child DNS zones to update It has been challenging for operators of child DNS zones to update
their delegation records within the parent's set in a timely fashion. their delegation records within the parent's set in a timely fashion.
skipping to change at page 4, line 44 skipping to change at page 4, line 44
at all. Errors due to unsupported Type Bit Map bits, or otherwise at all. Errors due to unsupported Type Bit Map bits, or otherwise
nonpunishable data, SHALL result in no change to the parent zone's nonpunishable data, SHALL result in no change to the parent zone's
delegation information for the Child. Parental agents MUST ignore a delegation information for the Child. Parental agents MUST ignore a
Child's CSYNC RDATA set if multiple CSYNC resource records are found; Child's CSYNC RDATA set if multiple CSYNC resource records are found;
only a single CSYNC record should ever be present. only a single CSYNC record should ever be present.
The parental agent MUST perform DNSSEC validation ([RFC4033], The parental agent MUST perform DNSSEC validation ([RFC4033],
[RFC4034], [RFC4035]), of the CSYNC RRType data and MUST perform [RFC4034], [RFC4035]), of the CSYNC RRType data and MUST perform
DNSSEC validation of any data to be copied from the Child to the 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 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 "Secure" [RFC4034] or if any the required data can not be
successfully retrieved. successfully retrieved.
2.1. The CSYNC Resource Record Format 2.1. The CSYNC Resource Record Format
2.1.1. The CSYNC Resource Record Wire Format 2.1.1. The CSYNC Resource Record Wire Format
The CSYNC RDATA consists of the following fields: 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 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 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
skipping to change at page 8, line 9 skipping to change at page 8, line 9
authoritative name server for the child zone. To ensure a single authoritative name server for the child zone. To ensure a single
host is being addressed, DNS over TCP SHOULD be used to avoid host is being addressed, DNS over TCP SHOULD be used to avoid
conversing with multiple nodes at an anycast address. conversing with multiple nodes at an anycast address.
1. Query for the child zone's SOA record 1. Query for the child zone's SOA record
2. Query for the child zone's CSYNC record 2. Query for the child zone's CSYNC record
3. Query for the child zone's data records, as required by the CSYNC 3. Query for the child zone's data records, as required by the CSYNC
record's Type Bit Map field 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 4. Query for the collected SOA records again, starting with the
serial numbers (for example, because the zone was edited and deepest and ending with the SOA of the child's.
republished during the interval between steps 1 and 4), then the
CSYNC record obtained in the second set MUST NOT be processed. The If the SOA records from the first, middle and last steps for a given
operation MAY be restarted or retried in the future. 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 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 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 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 agent and the SOA serial number is less than the last time a CSYNC
record was processed, this CSYNC record SHOULD NOT be processed. record was processed, this CSYNC record SHOULD NOT be processed.
Similarly, if state is being kept by the parental agent and the SOA 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 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 the CSYNC record from last time, then this CSYNC record SHOULD NOT be
processed. processed.
skipping to change at page 8, line 47 skipping to change at page 9, line 12
This document defines how the following record types may be processed This document defines how the following record types may be processed
if the CSYNC Type Bit Map field indicates they are to be processed. if the CSYNC Type Bit Map field indicates they are to be processed.
3.2.1. The NS type 3.2.1. The NS type
The NS type flag indicates that the NS records from the child zone The NS type flag indicates that the NS records from the child zone
should be copied into the parent's delegation information records for should be copied into the parent's delegation information records for
the child. the child.
NS records found within the child's zone should be copied verbatim NS records found within the child's zone should be copied verbatim
and the result published within the parent zone should be an exact (with the exception of the TTL field, for which the parent MAY want
matching set of NS records. If the child has published a new NS to select a different value) and the result published within the
record within their set, this record should be added to the parent parent zone should be an exact matching set of NS records. If the
zone. Similarly, if NS records in the parent's delegation records child has published a new NS record within their set, this record
for the child contain records that have been removed in the child's should be added to the parent zone. Similarly, if NS records in the
NS set, then they should be removed in the parent's set as well. 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 Parental agents MAY refuse to perform NS updates if the replacement
records fail to meet NS record policies required by the parent zone 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 (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 agents MUST NOT perform NS updates if there are no NS records
returned in a query, as verified by DNSSEC denial of existence returned in a query, as verified by DNSSEC denial of existence
protection. This situation should never happen unless the child protection. This situation should never happen unless the child
nameservers are misconfigured. nameservers are misconfigured.
Note that it is permissible for a child's nameserver to return a Note that it is permissible for a child's nameserver to return a
CSYNC record that removes the queried nameserver itself from the CSYNC record that removes the queried nameserver itself from the
future NS or address set. future NS or address set.
3.2.2. The A and AAAA types 3.2.2. The A and AAAA types
The A and AAAA type flags indicates that the A and AAAA address glue 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 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 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 AAAA record addresses for each NS record within a NS set for the
child that are in-bailiwick. child that are in-bailiwick.
Note: only the matching types should be queried. E.g., if the AAAA 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 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 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 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 appropriate NSEC or NSEC3 records), then the result in the parent's
skipping to change at page 11, line 38 skipping to change at page 12, line 4
The Type Bit Map bits they support The Type Bit Map bits they support
The frequency with which they poll clients (which may also be The frequency with which they poll clients (which may also be
configurable by the client) configurable by the client)
If they support the "immediate" flag If they support the "immediate" flag
If they poll a child's single nameserver, a configured list of If they poll a child's single nameserver, a configured list of
nameservers, or all of the advertised nameservers when querying nameservers, or all of the advertised nameservers when querying
records records
If they support SOA serial number caching to avoid issues with If they support SOA serial number caching to avoid issues with
regression and/or replay regression and/or replay
Where errors for CSYNC processing are published Where errors for CSYNC processing are published
If they support sending queries to a "hidden master". 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 5. Security Considerations
This specification requires the use of DNSSEC in order to determine This specification requires the use of DNSSEC in order to determine
that the data being updated was unmodified by third-parties. that the data being updated was unmodified by third-parties.
Parental agents implementing CSYNC processing MUST ensure all DNS Parental agents implementing CSYNC processing MUST ensure all DNS
transactions are validated by DNSSEC as "secure". Clients deploying transactions are validated by DNSSEC as "secure". Clients deploying
CSYNC MUST ensure their zones are signed, current and properly linked CSYNC MUST ensure their zones are signed, current and properly linked
to the parent zone with a DS record that points to an appropriate to the parent zone with a DS record that points to an appropriate
DNSKEY of the child's zone. DNSKEY of the child's zone.
skipping to change at page 13, line 28 skipping to change at page 14, line 16
A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson, 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 who's work on the CDS record type helped inspire the work in this
document, as well as the definition for the "parental agent" document, as well as the definition for the "parental agent"
definition and significant contributions to the text. A thank you definition and significant contributions to the text. A thank you
also goes out to Ed Lewis, with whom the author held many also goes out to Ed Lewis, with whom the author held many
conversations with about the issues surrounding parent/child conversations with about the issues surrounding parent/child
relationships and synchronization. Much of the work in this document relationships and synchronization. Much of the work in this document
is derived from the careful existing analysis of these three esteemed is derived from the careful existing analysis of these three esteemed
colleagues. Thank you to the following people who have contributed 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 A special thanks goes to Roy Arends, for taking the "bite out of that
hamburger" challenge while discussing this document. hamburger" challenge while discussing this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
 End of changes. 15 change blocks. 
31 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/