draft-ietf-dnsop-child-syncronization-02.txt   draft-ietf-dnsop-child-syncronization-03.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Parsons, Inc. Internet-Draft Parsons, Inc.
Intended status: Standards Track July 3, 2014 Intended status: Standards Track September 3, 2014
Expires: January 4, 2015 Expires: March 7, 2015
Child To Parent Synchronization in DNS Child To Parent Synchronization in DNS
draft-ietf-dnsop-child-syncronization-02 draft-ietf-dnsop-child-syncronization-03
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 it may copy and process record to indicate to a parental agent that the parental agent may
certain records from the child zone. The existence of and value copy and process certain records from the child zone. The existence
change of the record may be monitored by a parental agent and acted of the record and any change in its value can be monitored by a
on as appropriate. parental agent and acted on depending on local policy.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 4, 2015. This Internet-Draft will expire on March 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 3, line 9 skipping to change at page 3, line 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
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 that
it may copy and process certain records from the child zone. The can copy and process certain records from the child zone. The
existence of and value change of the record may be monitored by a existence of the record and any change in its value can be monitored
parental agent and acted on as appropriate. 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 traditionally challenging for child DNS operators to It has been challenging for operators of child DNS zones to update
update their delegation records within the parent's set in a timely their delegation records within the parent's set in a timely fashion.
fashion. This difficulty is frequently from simple operator laziness These difficulties may stem from operator laziness, as well as from
or because of the complexities of maintaining a large number of DNS the complexities of maintaining a large number of DNS zones. Having
zones. Having an automated mechanism for signaling updates will an automated mechanism for signaling updates will greatly ease the
greatly ease the child zone operator's maintenance burden and improve child zone operator's maintenance burden and improve the robustness
the robustness of the DNS as a whole. of the DNS as a whole.
This draft introduces a new Resource Record Type (RRType) named This draft introduces a new Resource Record Type (RRType) named
"CSYNC" that indicates which delegation records published by a child "CSYNC" that indicates which delegation records published by a child
DNS operator should be processed by a parental agent and used to DNS operator should be processed by a parental agent and used to
update the parent zone's DNS data. update the parent zone's DNS data.
This specification was not designed to synchronize DNSSEC security This specification was not designed to synchronize DNSSEC security
records, such as DS RRsets. For a solution to this problem, see the records, such as DS RRsets. For a solution to this problem, see the
complimentary solution complementary solution
[I-D.ietf-dnsop-delegation-trust-maintainance], which is designed to [I-D.ietf-dnsop-delegation-trust-maintainance], which is designed to
maintain security delegation information. In addition, this maintain security delegation information. In addition, this
specification does not address how to perform bootstrapping specification does not address how to perform bootstrapping
operations, including to get the required initial DNSSEC-secured operations, including to get the required initial DNSSEC-secured
operating environment in place. operating environment in place.
1.1. Terminology Used in This Document 1.1. Terminology Used in This Document
The terminology used in this document is defined in this section. The terminology used in this document is defined in this section.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
The CSYNC RRType contains, in its RDATA component, these parts: an The CSYNC RRType contains, in its RDATA component, these parts: an
SOA serial number, a set of flags and a simple bit-list indicating SOA serial number, a set of flags and a simple bit-list indicating
the DNS RRTypes in the child that should be processed by the parental the DNS RRTypes in the child that should be processed by the parental
agent in order to modify the DNS delegation records within the agent in order to modify the DNS delegation records within the
parent's zone for the child DNS operator. Child DNS operators parent's zone for the child DNS operator. Child DNS operators
wanting a parental agent to perform the synchronization steps wanting a parental agent to perform the synchronization steps
outlined in this document MUST publish a CSYNC record at the apex of outlined in this document MUST publish a CSYNC record at the apex of
the child zone. Parental agent implementations MAY choose to query the child zone. Parental agent implementations MAY choose to query
child zones for this record and process DNS record data as indicated child zones for this record and process DNS record data as indicated
by the Type Bit Map field in the RDATA of the CSYNC record. How the by the Type Bit Map field in the RDATA of the CSYNC record. How the
data is processed is described in Section Section 3. data is processed is described in Section 3.
Parental agents MUST process the entire set of child data indicated Parental agents MUST process the entire set of child data indicated
by the Type Bit Map field (i.e., all record types indicated along by the Type Bit Map field (i.e., all record types indicated along
with all of the necessary records to support processing of that type) with all of the necessary records to support processing of that type)
or else parental agents MUST NOT make any changes to parental records or else parental agents MUST NOT make any changes to parental records
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.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
flag that is unknown to or unsupported by the parental agent. flag that is unknown to or unsupported by the parental agent.
2.1.1.2.1. The Type Bit Map Field 2.1.1.2.1. The Type Bit Map Field
The Type Bit Map field indicates the record types to be processed by The Type Bit Map field indicates the record types to be processed by
the parental agent, according to the procedures in Section Section 3. the parental agent, according to the procedures in Section Section 3.
The Type Bit Map field is encoded in the same way as the Type Bit The Type Bit Map field is encoded in the same way as the Type Bit
Maps field of the NSEC record, described in [RFC4034], Section 4.1.2. Maps field of the NSEC record, described in [RFC4034], Section 4.1.2.
If a bit has been set that a parental agent implementation does not If a bit has been set that a parental agent implementation does not
understand, the parental agent MUST NOT act upon the record. understand, the parental agent MUST NOT act upon the record.
Specifically: a parental agent must not copy data blindly; An IETF Specifically: a parental agent must not copy data blindly and must
proposed (or higher) standard specification must exist that defines understand the semantics associated with an bit in the Type Bit Map
how the data should be processed for a given bit. field that has been set to 1.
2.1.2. The CSYNC Presentation Format 2.1.2. The CSYNC Presentation Format
The CSYNC presentation format is as follows: The CSYNC presentation format is as follows:
The SOA Serial field is represented as an integer. The SOA Serial field is represented as an integer.
The Flags field is represented as an integer. The Flags field is represented as an integer.
The Type Bit Map field is represented as a sequence of RR type The Type Bit Map field is represented as a sequence of RR type
skipping to change at page 7, line 21 skipping to change at page 7, line 21
proven by NSEC or NSEC3 is to be considered successful). proven by NSEC or NSEC3 is to be considered successful).
Parental agents MAY: Parental agents MAY:
Process the CSYNC record immediately if the "immediate" flag is Process the CSYNC record immediately if the "immediate" flag is
set. If the "immediate" flag is not set, the parental agent MUST set. If the "immediate" flag is not set, the parental agent MUST
NOT act until the zone administrator approves the operation NOT act until the zone administrator approves the operation
through an out-of-band mechanism (such as through pushing a button through an out-of-band mechanism (such as through pushing a button
via a web interface). via a web interface).
Require that the child zone administrator approve the operation Choose not to process the CSYNC record immediately, even if the
through an out-of-band mechanism (such as through pushing a button "immediate" flag is set. That is, a parental agent might require
via a web interface). I.e., a parental agent MAY choose not to the child zone administrator approve the operation through an out-
support the "immediate" flag. of-band mechanism (such as through pushing a button via a web
interface).
Note: how the approval is done out-of-band is outside the scope of Note: how the approval is done out-of-band is outside the scope of
this document and is implementation-specific to parental agents. this document and is implementation-specific to parental agents.
3.1. Processing Procedure 3.1. Processing Procedure
The following shows a sequence of steps that SHOULD be used when The following shows a sequence of steps that SHOULD be used when
collecting and processing CSYNC records from a child zone. Because collecting and processing CSYNC records from a child zone. Because
DNS queries are not allowed to contain more than one "question" at a DNS queries are not allowed to contain more than one "question" at a
time, a sequence of requests is needed. When processing a CSYNC time, a sequence of requests is needed. When processing a CSYNC
skipping to change at page 7, line 50 skipping to change at page 7, line 51
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 4. Query for the child zone's SOA record again
If the SOA records from the first and last steps have different If the SOA records from the first and last steps have different
serial numbers, then the CSYNC record obtained in the second set MUST serial numbers (for example, because the zone was edited and
NOT be processed. The operation MAY be restarted or retried in the republished during the interval between steps 1 and 4), then the
future. CSYNC record obtained in the second set MUST NOT be processed. The
operation MAY be restarted or retried in the future.
If the SOA serial numbers are equal but less than the CSYNC record's If the SOA serial numbers are equal but less than the CSYNC record's
SOA Serial Field [RFC1982], the record MUST NOT be processed. If SOA Serial Field [RFC1982], the record MUST NOT be processed. If
state is being kept by the parental agent and the SOA serial number 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 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 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 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, less than the SOA Serial Field of the CSYNC record from last time,
then this CSYNC record SHOULD NOT be processed. then this CSYNC record SHOULD NOT be processed.
skipping to change at page 8, line 47 skipping to change at page 8, line 49
zone. Similarly, if NS records in the parent's delegation records zone. Similarly, if NS records in the parent's delegation records
for the child contain records that have been removed in the child's 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. 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"). (e.g. "every child zone must have at least 2 NS records").
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, The A and AAAA type flags indicates that the A and AAAA address glue
respectively, address glue records for in-bailiwick NS records within records for in-bailiwick NS records within the child zone should be
the child zone should be copied into the parent's delegation copied into the parent's delegation information.
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 9, line 34 skipping to change at page 9, line 36
4. Operational Considerations 4. Operational Considerations
There are a number of important operational aspects to consider when There are a number of important operational aspects to consider when
deploying a CSYNC RRType. deploying a CSYNC RRType.
4.1. Error Reporting 4.1. Error Reporting
There is no inline mechanism for a parental agent to report errors to There is no inline mechanism for a parental agent to report errors to
operators of child zones. Thus, the only error reporting mechanisms operators of child zones. Thus, the only error reporting mechanisms
must be out of band, such as through a web console or over email. must be out of band, such as through a web console or over email.
Child operators utilizing the "immediate" flag that fail to see an Parental agents SHOULD, at a minimum, at least log errors encountered
update within the parental agent's specified operational window when processing CSYNC records. Child operators utilizing the
should access the parental agent's error logging interface to "immediate" flag that fail to see an update within the parental
determine why an update failed to be processed. agent's specified operational window should access the parental
agent's error logging interface to determine why an update failed to
be processed.
4.2. Child Nameserver Selection 4.2. Child Nameserver Selection
Parental agents will need to poll child nameservers in search of Parental agents will need to poll child nameservers in search of
CSYNC records and related data records. CSYNC records and related data records.
Parental agents MAY perform best-possible verification by querying Parental agents MAY perform best-possible verification by querying
all NS records for available data to determine which has the most all NS records for available data to determine which has the most
recent SOA and CSYNC version (in an ideal world, they would all be recent SOA and CSYNC version (in an ideal world, they would all be
equal, but this is not possible in practice due to synchronization equal, but this is not possible in practice due to synchronization
delays and transfer failures). delays and transfer failures).
Parental agents MAY offer a configuration interface to allow child Parental agents MAY offer a configuration interface to allow child
operators to specify which nameserver should be considered the master operators to specify which nameserver should be considered the master
to send data queries too. This master MAY be a different nameserver to send data queries too. Note that this master could be a different
than the publically listed nameservers in the NS set (i.e., it may be nameserver than the publically listed nameservers in the NS set
a "hidden master"). (i.e., it may be a "hidden master").
Parental agents MAY offer a programmatic interface to let children Parental agents with a large number of clients may choose to offer a
indicate that new CSYNC records and data are available for polling. programmatic interface to let their children indicate that new CSYNC
records and data are available for polling rather than polling every
child on a frequent basis.
4.3. Out-of-balliwick NS Records 4.3. Out-of-balliwick NS Records
When a zone contains NS records where the domain-name pointed at does When a zone contains NS records where the domain-name pointed at does
not fall within the zone itself, there is no way for the parent to not fall within the zone itself, there is no way for the parent to
safely update the associated glue records. Thus, the child DNS safely update the associated glue records. Thus, the child DNS
operator MAY indicate that the NS records should be synchronized, and operator MAY indicate that the NS records should be synchronized, and
may set any glue record flags (A, AAAA) as well, but the parent will MAY set any glue record flags (A, AAAA) as well, but the parent will
only update those glue records which are below the child's delegation only update those glue records which are below the child's delegation
point. point.
Children deploying NS records pointing to domain-names within their Children deploying NS records pointing to domain-names within their
own children (the "grandchildren") SHOULD ensure the grandchildren's own children (the "grandchildren") SHOULD ensure the grandchildren's
associated glue records are properly set before publishing the CSYNC associated glue records are properly set before publishing the CSYNC
record. I.e., it is imperative that proper communication and record. I.e., it is imperative that proper communication and
synchronization exist between the child and the grandchild. synchronization exist between the child and the grandchild.
4.4. Documented Parental Agent Type Support 4.4. Documented Parental Agent Type Support
skipping to change at page 11, line 29 skipping to change at page 11, line 34
designed to synchronize DNSSEC security records, such as DS pointers. designed to synchronize DNSSEC security records, such as DS pointers.
For such a solution, please see the complimentary solution For such a solution, please see the complimentary solution
[I-D.ietf-dnsop-delegation-trust-maintainance] for maintaining [I-D.ietf-dnsop-delegation-trust-maintainance] for maintaining
security delegation information. security delegation information.
6. IANA Considerations 6. IANA Considerations
This document defines a new DNS Resource Record Type, named "CSYNC". This document defines a new DNS Resource Record Type, named "CSYNC".
The IANA is requested to assign a code point from the "Resource The IANA is requested to assign a code point from the "Resource
Record (RR) TYPEs" sub-registry of the "Domain Name System (DNS) Record (RR) TYPEs" sub-registry of the "Domain Name System (DNS)
Parameters" registry Parameters" registry (http://www.iana.org/assignments/dns-parameters)
(http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)
for this record. for this record.
TYPE Value Meaning Reference TYPE Value Meaning Reference
----- ------ -------------------------- ----------- ----- ------ -------------------------- -----------
CSYNC TBA Child To Parent Synchronization [This document] CSYNC TBD Child To Parent Synchronization [This document]
[ To be removed prior to publication: The CDS (59), CDNSKEY (60) and
the CSYNC records are all conceptually similar - if the code-point 61
happens to still be Unassigned when the IANA processes this, it would
be nice if that could be used for this.]
The IANA is also requested to create and maintain a sub-registry (the The IANA is also requested to create and maintain a sub-registry (the
"Child Synchronization (CSYNC) Flags" registry) of the "Domain Name "Child Synchronization (CSYNC) Flags" registry) of the "Domain Name
System (DNS) Parameters" registry. The initial values for this System (DNS) Parameters" registry. The initial values for this
registry are below. Assignment of new flag values are subject to registry are below. Assignment of new flag values are subject to
"RFC Required" specifications [RFC5226]. "RFC Required" specifications [RFC5226].
This registry will hold a set of single-bit "Flags" for use in the This registry will hold a set of single-bit "Flags" for use in the
CSYNC record within the 16 bit Flags field. Thus, a maximum of 16 CSYNC record within the 16 bit Flags field. Thus, a maximum of 16
flags may be defined. flags may be defined.
The initial assignments in this registry are: The initial assignments in this registry are:
Bit Flag Description Reference Bit Flag Description Reference
---- ------ ------------- ----------- ---- ------ ------------- -----------
Bit 0 immediate Immediately process this [This document, Bit 0 immediate Immediately process this [This document,
CSYNC record. Section 3] CSYNC record. Section 3]
Bit 1 soaminimum Require a SOA serial [This document, Bit 1 soaminimum Require a SOA serial [This document,
number greater than the Section 2.1.1.1] number greater than the Section 2.1.1.1]
one specified. one specified.
For new assignments to be made to this registry, a new RFC must be
published via a Standards Action.
7. Acknowledgments 7. Acknowledgments
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, who the author held many conversations also goes out to Ed Lewis, with whom the author held many
with about the issues surrounding parent/child relationships and conversations with about the issues surrounding parent/child
synchronization. Much of the work in this document is derived from relationships and synchronization. Much of the work in this document
the careful existing analysis of these three esteemed colleagues. is derived from the careful existing analysis of these three esteemed
Thank you to the following people who have contributed text to the colleagues. Thank you to the following people who have contributed
document: Matthijs Mekking and Petr Spacek. text to the document: Matthijs Mekking and Petr Spacek.
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. 22 change blocks. 
68 lines changed or deleted 70 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/