draft-ietf-dnsop-child-syncronization-00.txt   draft-ietf-dnsop-child-syncronization-01.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Parsons, Inc. Internet-Draft Parsons, Inc.
Intended status: Standards Track February 14, 2014 Intended status: Standards Track May 13, 2014
Expires: August 18, 2014 Expires: November 14, 2014
Child To Parent Synchronization in DNS Child To Parent Synchronization in DNS
draft-ietf-dnsop-child-syncronization-00 draft-ietf-dnsop-child-syncronization-01
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 it may copy and process
certain records from the child zone. The existence and change of the certain records from the child zone. The existence of and value
record may be monitored by a parental agent, after which the parent change of the record may be monitored by a parental agent and acted
may act on the data appropriately. on as appropriate.
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 August 18, 2014. This Internet-Draft will expire on November 14, 2014.
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 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . 4 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
2.2. CSYNC Data Processing . . . . . . . . . . . . . . . . . . 7 3. CSYNC Data Processing . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Processing Procedure . . . . . . . . . . . . . . . . . 7 3.1. Processing Procedure . . . . . . . . . . . . . . . . . . . 7
2.2.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . 8 3.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . . . 8
2.3. Operational Considerations . . . . . . . . . . . . . . . . 9 3.2.1. The NS type . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Error Reporting . . . . . . . . . . . . . . . . . . . 9 3.2.2. The A and AAAA types . . . . . . . . . . . . . . . . . 8
2.3.2. Child Nameserver Selection . . . . . . . . . . . . . . 9 4. Operational Considerations . . . . . . . . . . . . . . . . . . 9
2.3.3. Documented Parental Agent Type Support . . . . . . . . 10 4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 9
2.3.4. Other Considerations . . . . . . . . . . . . . . . . . 10 4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.4. Documented Parental Agent Type Support . . . . . . . . . . 10
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document specifies how a child zone in the DNS can publish a This document specifies how a child zone in the DNS ([RFC1034],
record to indicate to a parental agent that it may copy and process [RFC1035]) can publish a record to indicate to a parental agent that
certain records from the child zone. The existence and change of the it may copy and process certain records from the child zone. The
record may be monitored by a parental agent, after which the parent existence of and value change of the record may be monitored by a
may act on the data appropriately. parental agent and acted on as appropriate.
Some resource records (RRs) in a parent zone are typically expected 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 to be in-sync with the source data in the child's zone. The most
common records, to date, that should match are the nameserver (NS) common records that should match, to date, are the nameserver (NS)
records and any necessary associated address "glue" records (A and records and any necessary associated address records (A and AAAA),
AAAA). These records are referred to as "delegation records". also known as "glue records". These records are referred to as
"delegation records".
It has been traditionally challenging for children to update their It has been traditionally challenging for child DNS operators to
delegation records within the parent's set in a timely fashion. This update their delegation records within the parent's set in a timely
difficulty is frequently from simple operator laziness or because of fashion. This difficulty is frequently from simple operator laziness
the complexities of maintaining a large number of DNS zones. Having or because of the complexities of maintaining a large number of DNS
an automated mechanism for signaling updates will greatly ease the zones. Having an automated mechanism for signaling updates will
child zone operator's maintenance burden and improve the robustness greatly ease the child zone operator's maintenance burden and improve
of the DNS as a whole. the robustness of the DNS as a whole.
This draft introduces a new RR type (RRType) named "CSYNC" that This draft introduces a new Resource Record Type (RRType) named
indicates which delegation records published by a child should be "CSYNC" that indicates which delegation records published by a child
processed by a parental agent and used to update the parent zone's DNS operator should be processed by a parental agent and used to
DNS data. update the parent zone's DNS data.
This specification does not address how to perform bootstrapping This specification was not designed to synchronize DNSSEC security
operations to get the required initial DNSSEC-secured operating records, such as DS RRsets. For a solution to this problem, see the
environment in place. Additionally, this specification was not complimentary solution
designed to synchronize DNSSEC security records, such as DS pointers. [I-D.ietf-dnsop-delegation-trust-maintainance], which is designed to
For such a solution, please see the complimentary solution maintain security delegation information. In addition, this
[I-D.kumari-ogud-dnsop-cds] for maintaining security delegation specification does not address how to perform bootstrapping
information. operations, including to get the required initial DNSSEC-secured
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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document is aimed at the case where there is an organizational Terminology describing relationships between the interacting roles
separation of the child and parent. In this case there are many involved in this document are defined in the following list:
different operating situations. A common case is the Registrant/
Registrar/Registry relationship, used by many Top Level Domains in Child: The entity on record that has the delegation of the domain
the DNS. In this case, the parent consists of Registrar and from the parent
Registry, with different rules about what each can do or not do. To
remain operating model neutral we will use the neutral word "Parental Parent: The domain in which the child is registered
Agent" as the entity that uses results of DNS queries discussed in
this document to update the delegation records into the parent zone. Child DNS operator: The entity that maintains and publishes the zone
The entity that performs the changes in the the DNS is called "DNS information for the child DNS
Publisher".
Parental agent: The entity that the child has relationship with, to
change its delegation information
2. Definition of the CSYNC RRType 2. Definition of the CSYNC RRType
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 for the child agent in order to modify the DNS delegation records within the
within the parent's zone. Children wanting a parental agent to parent's zone for the child DNS operator. Child DNS operators
perform the synchronization steps outlined in this document MUST wanting a parental agent to perform the synchronization steps
publish a CSYNC record at the apex of the child zone. Parental agent outlined in this document MUST publish a CSYNC record at the apex of
implementations MAY choose to query child zones for this record and the child zone. Parental agent implementations MAY choose to query
process DNS record data as indicated by the Type Bit Map field in the child zones for this record and process DNS record data as indicated
RDATA of the CSYNC record. How the data is processed is described by the Type Bit Map field in the RDATA of the CSYNC record. How the
later in Section Section 2.2. data is processed is described in Section 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 expected. only a single CSYNC record should ever be present.
The parental agent MUST perform DNSSEC validation of the CSYNC RRType The parental agent MUST perform DNSSEC validation ([RFC4033],
data and MUST perform DNSSEC validation of any data to be copied from [RFC4034], [RFC4035]), of the CSYNC RRType data and MUST perform
the child to the parent. Parents MUST not process any data from any DNSSEC validation of any data to be copied from the Child to the
of these records if any of the validation results indicate any Parent. Parents MUST NOT process any data from any of these records
anything other than "Secure" [RFC4034]. if any of the validation results indicate any 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. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOA Serial | | SOA Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type Bit Map / | Flags | Type Bit Map /
skipping to change at page 5, line 18 skipping to change at page 5, line 21
| SOA Serial | | SOA Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type Bit Map / | Flags | Type Bit Map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Map (continued) / / Type Bit Map (continued) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1.1. The SOA Serial Field 2.1.1.1. The SOA Serial Field
The SOA Serial field contains a copy of the 32-bit SOA serial number The SOA Serial field contains a copy of the 32-bit SOA serial number
from the child zone. If the value is non-zero, parental agents from the child zone. If the soaminimum flag is set, parental agents
querying children's authoritative servers MUST NOT act on data from querying children's authoritative servers MUST NOT act on data from
zones advertising an SOA serial number less than this value. A zones advertising an SOA serial number less than this value. See
special value of 0 indicates that no such restriction is in place. [RFC1982] for properly implementing "less than" logic. If the
soaminimum flag is not set, parental agents MUST ignore the value in
the SOA Serial Field. Clients can set the field to any value if the
soaminimum flag is unset, such as the number zero.
Note that a child zone's current SOA serial number may be greater Note that a child zone's current SOA serial number may be greater
than the number indicated by the CSYNC record. A child SHOULD update than the number indicated by the CSYNC record. A child SHOULD update
the SOA Serial field in the CSYNC record every time the data being the SOA Serial field in the CSYNC record every time the data being
referenced by the CSYNC record is changed (e.g. an NS record or referenced by the CSYNC record is changed (e.g. an NS record or
associated address record is changed). A child MAY choose to update associated address record is changed). A child MAY choose to update
the SOA Serial field to always match the current SOA serial field. the SOA Serial field to always match the current SOA serial field.
Parental agents MAY cache SOA serial numbers from data they use and Parental agents MAY cache SOA serial numbers from data they use and
refuse to process data from zones older than the last instance they refuse to process data from zones older than the last instance they
pulled data from. pulled data from.
2.1.1.2. The Flags Field 2.1.1.2. The Flags Field
The Flags field contains 16 bits of flags defining operations that The Flags field contains 16 bits of boolean flags that define
affect the processing of the CSYNC record. The flags defined in this operations which affect the processing of the CSYNC record. The
document are as follows: flags defined in this document are as follows:
0x00 0x01: "immediate" 0x00 0x01: "immediate"
0x00 0x02: "soaminimum"
The definitions for how the flags are to be used can be found later The definitions for how the flags are to be used can be found later
in Section Section 2.2. in Section Section 3.
The remaining flags are reserved for use by future specifications. The remaining flags are reserved for use by future specifications.
Undefined flags MUST be set to 0 by CSYNC publishers. Parental Undefined flags MUST be set to 0 by CSYNC publishers. Parental
agents MUST NOT process a CSYNC record if it contains a 1 value for a agents MUST NOT process a CSYNC record if it contains a 1 value for a
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 the parental agent, according to the procedures in Section Section 3.
Section 2.2. The Type Bit Map field is encoded in the same way as The Type Bit Map field is encoded in the same way as the Type Bit
the Type Bit Maps field of the NSEC record, described in [RFC4034], Maps field of the NSEC record, described in [RFC4034], Section 4.1.2.
Section 4.1.2. If a bit has been set that a parental agent If a bit has been set that a parental agent implementation does not
implementation does not understand, the parental agent MUST NOT act understand, the parental agent MUST NOT act upon the record.
upon the record. Specifically: a parental agent must not copy data Specifically: a parental agent must not copy data blindly; An IETF
blindly; An IETF proposed (or higher) standard specification must proposed (or higher) standard specification must exist that defines
exist that defines how the data should be processed for a given bit. how the data should be processed for a given bit.
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 6, line 40 skipping to change at page 6, line 45
representations as well. representations as well.
2.1.3. CSYNC RR Example 2.1.3. CSYNC RR Example
The following CSYNC RR shows an example entry for "example.com" that The following CSYNC RR shows an example entry for "example.com" that
indicates the NS, A and AAAA bits are set and should be processed by indicates the NS, A and AAAA bits are set and should be processed by
the parental agent for example.com. The parental agent should pull the parental agent for example.com. The parental agent should pull
data only from a zone using a minimum SOA serial number of 66 (0x42 data only from a zone using a minimum SOA serial number of 66 (0x42
in hexadecimal). in hexadecimal).
example.com. 3600 IN CSYNC 66 1 A NS AAAA example.com. 3600 IN CSYNC 66 3 A NS AAAA
The RDATA component of the example CSYNC RR would be encoded on the The RDATA component of the example CSYNC RR would be encoded on the
wire as follows: wire as follows:
0x00 0x00 0x00 0x42 (SOA Serial) 0x00 0x00 0x00 0x42 (SOA Serial)
0x00 0x01 (Flags [the immediate bit is set]) 0x00 0x03 (Flags = immediate | soaminimum)
0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map) 0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map)
2.2. CSYNC Data Processing 3. CSYNC Data Processing
The CSYNC record and associated data must be processed as an "all or The CSYNC record and associated data must be processed as an "all or
nothing" operation set. If a parental agent fails to successfully nothing" operation set. If a parental agent fails to successfully
query for any of the required records, the whole operation MUST be query for any of the required records, the whole operation MUST be
aborted. (Note that a query resulting in "no records exist" as aborted. (Note that a query resulting in "no records exist" as
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 after noticing it if the Process the CSYNC record immediately if the "immediate" flag is
"immediate" flag is set. If the "immediate" flag is not set, the set. If the "immediate" flag is not set, the parental agent MUST
parental agent MUST not act until the zone administrator approves NOT act until the zone administrator approves the operation
the operation through an out-of-band mechanism (such as through through an out-of-band mechanism (such as through pushing a button
pushing a button via a web interface). via a web interface).
Require that the child zone administrator approve the operation Require that the child zone administrator approve 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). I.e., a parental agent MAY choose not to via a web interface). I.e., a parental agent MAY choose not to
support the "immediate" flag. support the "immediate" flag.
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.
2.2.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
transaction request, all DNS queries should be sent to a single transaction request, all DNS queries should be sent to a single
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.
skipping to change at page 7, line 51 skipping to change at page 7, line 51
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, then the CSYNC record obtained in the second set MUST
NOT be processed. 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, the record MUST NOT be processed. If state is SOA Serial Field [RFC1982], the record MUST NOT be processed. If
being kept by the parental agent and the SOA serial number is less state is being kept by the parental agent and the SOA serial number
than the last time a CSYNC record was processed, this CSYNC record is less than the last time a CSYNC record was processed, this CSYNC
SHOULD NOT be processed. Similarly, if state is being kept by the record SHOULD NOT be processed. Similarly, if state is being kept by
parental agent and the SOA Serial Field of the CSYNC record is less the parental agent and the SOA Serial Field of the CSYNC record is
than the SOA Serial Field of the CSYNC record from last time, then less than the SOA Serial Field of the CSYNC record from last time,
this CSYNC record SHOULD NOT be processed. then this CSYNC record SHOULD NOT be processed.
If DNSSEC fails to validate all of the data returned for these If a failure occurs of any kind while trying to obtain any of the
queries as "secure", then this CSYNC record MUST NOT be processed. required data, or if DNSSEC fails to validate all of the data
returned for these queries as "secure", then this CSYNC record MUST
NOT be processed.
See the "Operational Consideration" section (Section Section 2.3) for See the "Operational Consideration" section (Section Section 4) for
additional guidance about processing. additional guidance about processing.
2.2.2. CSYNC Record Types 3.2. CSYNC Record Types
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 should be processed. if the CSYNC Type Bit Map field indicates they are to be processed.
2.2.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 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 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 record within their set, this record should be added to the parent
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").
2.2.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,
respectively, address glue records for in-bailiwick NS records within respectively, address glue records for in-bailiwick NS records within
the child zone should be copied into the parent's delegation the child zone should be 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
delegation records for the child should be an empty set. delegation records for the child should be an empty set.
The procedure for querying for A and AAAA records MUST occur after The procedure for querying for A and AAAA records MUST occur after
the procedure, if required, for querying for NS records as defined in the procedure, if required, for querying for NS records as defined in
Section Section 2.2.2.1. This ensures that the right set NS records Section Section 3.2.1. This ensures that the right set of NS records
is used as provided by the current NS set of the child. I.e, for is used as provided by the current NS set of the child. I.e., for
CSYNC records that have the NS bit set, the NS set used should be the CSYNC records that have the NS bit set, the NS set used should be the
ones pulled from the child while processing the CSYNC record. For one pulled from the child while processing the CSYNC record. For
CSYNC records without the NS bit set, the existing NS records within CSYNC records without the NS bit set, the existing NS records within
the parent should be used to determine which A and/or AAAA records to the parent should be used to determine which A and/or AAAA records to
update. update.
2.3. Operational Considerations 4. Operational Considerations
There are a number of important things to consider when deploying a There are a number of important operational aspects to consider when
CSYNC RRType. deploying a CSYNC RRType.
2.3.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 Child operators utilizing the "immediate" flag that fail to see an
update within the parental agent's specified operational window update within the parental agent's specified operational window
should access the parental agent's error logging interface to should access the parental agent's error logging interface to
determine why an update failed to be processed. determine why an update failed to be processed.
2.3.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 not be one of the to send data queries too. This master MAY be a different nameserver
publically listed nameservers in the NS set (i.e., it may be a than the publically listed nameservers in the NS set (i.e., it may be
"hidden master"). a "hidden master").
2.3.3. Documented Parental Agent Type Support Parental agents MAY offer a programmatic interface to let children
indicate that new CSYNC records and data are available for polling.
4.3. Out-of-balliwick NS Records
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
safely update the associated glue records. Thus, the child DNS
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
only update those glue records which are below the child's delegation
point.
Children deploying NS records pointing to domain-names within their
own children (the "grandchildren") SHOULD ensure the grandchildren's
associated glue records are properly set before publishing the CSYNC
record. I.e., it is imperative that proper communication and
synchronization exist between the child and the grandchild.
4.4. Documented Parental Agent Type Support
Parental agents that support processing CSYNC records SHOULD publicly Parental agents that support processing CSYNC records SHOULD publicly
document the following minimum processing characteristics: document the following minimum processing characteristics:
The fact that they support CSYNC processing The fact that they support CSYNC processing
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)
skipping to change at page 10, line 27 skipping to change at page 11, line 4
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".
2.3.4. Other Considerations 5. Security Considerations
XXX: Discuss complete replacement scenarios and if allowed.
3. 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.
This specification does not address how to perform bootstrapping This specification does not address how to perform bootstrapping
operations to get the required initial DNSSEC-secured operating operations to get the required initial DNSSEC-secured operating
environment in place. Additionally, this specification was not environment in place. Additionally, this specification was not
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.kumari-ogud-dnsop-cds] for maintaining security delegation [I-D.ietf-dnsop-delegation-trust-maintainance] for maintaining
information. security delegation information.
4. IANA Considerations 6. IANA Considerations
TBD This document defines a set of single-bit "Flags" for use in the
CSYNC record within the 16 bit Flags field. Thus, a maximum of 16
flags may be defined. The two initial flags defined by this document
are:
5. Acknowledgments 0x00 0x01: "immediate"
0x00 0x02: "soaminimum"
Assignment of new flag values are subject to "RFC Required"
specifications [RFC5226].
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 "Parental Agent" and "DNS document, as well as the definition for the "parental agent"
Publisher" definitions. A thank you also goes out to Ed Lewis, who definition. A thank you also goes out to Ed Lewis, who the author
the author held many conversations with about the issues surrounding held many conversations with about the issues surrounding parent/
parent/child relationships and synchronization. Much of the work in child relationships and synchronization. Much of the work in this
this document is derived from the careful existing analysis of these document is derived from the careful existing analysis of these three
three esteemed colleagues. esteemed colleagues. Thank you to the following people who have
contributed 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.
6. References 8. References
6.1. Normative References 8.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
6.2. Informative References 8.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[I-D.kumari-ogud-dnsop-cds] [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[I-D.ietf-dnsop-delegation-trust-maintainance]
Kumari, W., Gudmundsson, O., and G. Barwood, "Automating Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC delegation trust maintenance", DNSSEC Delegation Trust Maintenance",
draft-kumari-ogud-dnsop-cds-05 (work in progress), draft-ietf-dnsop-delegation-trust-maintainance-13 (work in
October 2013. progress), May 2014.
Author's Address Author's Address
Wes Hardaker Wes Hardaker
Parsons, Inc. Parsons, Inc.
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
US US
Phone: +1 530 792 1913 Phone: +1 530 792 1913
 End of changes. 57 change blocks. 
155 lines changed or deleted 204 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/