draft-ietf-dnsop-child-syncronization-03.txt   draft-ietf-dnsop-child-syncronization-04.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Parsons, Inc. Internet-Draft Parsons, Inc.
Intended status: Standards Track September 3, 2014 Intended status: Standards Track November 26, 2014
Expires: March 7, 2015 Expires: May 30, 2015
Child To Parent Synchronization in DNS Child To Parent Synchronization in DNS
draft-ietf-dnsop-child-syncronization-03 draft-ietf-dnsop-child-syncronization-04
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 March 7, 2015. This Internet-Draft will expire on May 30, 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. The A and AAAA types . . . . . . . . . . . . . . . . . 8 3.2.2. The A and AAAA types . . . . . . . . . . . . . . . . . 9
4. Operational Considerations . . . . . . . . . . . . . . . . . . 9 4. Operational Considerations . . . . . . . . . . . . . . . . . . 10
4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 9 4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10
4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 9 4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 10
4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 10 4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 11
4.4. Documented Parental Agent Type Support . . . . . . . . . . 10 4.4. Documented Parental Agent Type Support . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
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
can copy and process certain records from the child zone. The it can copy and process certain records from the child zone. The
existence of the record and any change in its value can be monitored existence of the record and any change in its value can be monitored
by a parental agent and acted on depending on local policy. 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".
skipping to change at page 3, line 35 skipping to change at page 3, line 35
child zone operator's maintenance burden and improve the robustness child zone operator's maintenance burden and improve 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
complementary solution complementary solution [RFC7344], which is designed to maintain
[I-D.ietf-dnsop-delegation-trust-maintainance], which is designed to security delegation information. In addition, this specification
maintain security delegation information. In addition, this does not address how to perform bootstrapping operations, including
specification does not address how to perform bootstrapping to get the required initial DNSSEC-secured operating environment in
operations, including to get the required initial DNSSEC-secured 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.
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].
Terminology describing relationships between the interacting roles Terminology describing relationships between the interacting roles
skipping to change at page 5, line 40 skipping to change at page 5, line 40
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.
Although Section 3.2 of [RFC1982] describes how to properly implement
a less-than comparison operation with SOA serial numbers that may
wrap beyond the 32-bit value in both the SOA record and the CSYNC
record, it is important than a child using the soaminimum flag must
not increment it's SOA serial number value more than 2^16 within the
period of time that a parent might wait between polling the child for
the CSYNC record.
2.1.1.2. The Flags Field 2.1.1.2. The Flags Field
The Flags field contains 16 bits of boolean flags that define The Flags field contains 16 bits of boolean flags that define
operations which affect the processing of the CSYNC record. The operations which affect the processing of the CSYNC record. The
flags defined in this document are as follows: flags defined in this document are as follows:
0x00 0x01: "immediate" 0x00 0x01: "immediate"
0x00 0x02: "soaminimum" 0x00 0x02: "soaminimum"
skipping to change at page 6, line 18 skipping to change at page 6, line 26
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 and must Specifically: a parental agent must not just copy the data and must
understand the semantics associated with an bit in the Type Bit Map understand the semantics associated with an bit in the Type Bit Map
field that has been set to 1. 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.
skipping to change at page 8, line 7 skipping to change at page 8, line 17
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 (for example, because the zone was edited and serial numbers (for example, because the zone was edited and
republished during the interval between steps 1 and 4), then the republished during the interval between steps 1 and 4), then the
CSYNC record obtained in the second set MUST NOT be processed. The CSYNC record obtained in the second set MUST NOT be processed. The
operation MAY be restarted or retried in the future. 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 soaminimum flag is set and the SOA serial numbers are equal
SOA Serial Field [RFC1982], the record MUST NOT be processed. If but less than the CSYNC record's SOA Serial Field [RFC1982], the
state is being kept by the parental agent and the SOA serial number record MUST NOT be processed. If state is being kept by the parental
is less than the last time a CSYNC record was processed, this CSYNC agent and the SOA serial number is less than the last time a CSYNC
record SHOULD NOT be processed. Similarly, if state is being kept by record was processed, this CSYNC record SHOULD NOT be processed.
the parental agent and the SOA Serial Field of the CSYNC record is Similarly, if state is being kept by the parental agent and the SOA
less than the SOA Serial Field of the CSYNC record from last time, Serial Field of the CSYNC record is less than the SOA Serial Field of
then this CSYNC record SHOULD NOT be processed. the CSYNC record from last time, then this CSYNC record SHOULD NOT be
processed.
If a failure occurs of any kind while trying to obtain any of the If a failure occurs of any kind while trying to obtain any of the
required data, or if DNSSEC fails to validate all of the data required data, or if DNSSEC fails to validate all of the data
returned for these queries as "secure", then this CSYNC record MUST returned for these queries as "secure", then this CSYNC record MUST
NOT be processed. NOT be processed.
See the "Operational Consideration" section (Section Section 4) for See the "Operational Consideration" section (Section Section 4) for
additional guidance about processing. additional guidance about processing.
3.2. CSYNC Record Types 3.2. CSYNC Record Types
skipping to change at page 8, line 45 skipping to change at page 9, line 8
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"). Parental
agents MUST NOT perform NS updates if there are no NS records
returned in a query, as verified by DNSSEC denial of existence
protection. This situation should never happen unless the child
nameservers are misconfigured.
Note that it is permissible for a child's nameserver to return a
CSYNC record that removes the queried nameserver itself from the
future NS or address set.
3.2.2. The A and AAAA types 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 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
delegation records for the child should be an empty set. delegation records for the child should be an empty set. However, if
the end result of processing would leave no glue records present in
the parent zone for any of the of the in-bailiwick NS records, then
the parent MUST NOT update the glue address records. I.E., if the
result of the processing would leave no in-bailiwick A or AAAA
records when there are in-bailiwick NS records, then processing of
the address records can not happen as it would leave the parent/child
relationship without any address linkage.
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 3.2.1. This ensures that the right set of 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
one 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.
skipping to change at page 9, line 36 skipping to change at page 10, line 15
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.
Parental agents SHOULD, at a minimum, at least log errors encountered Parental agents should, at a minimum, at least log errors encountered
when processing CSYNC records. Child operators utilizing the when processing CSYNC records. Child operators utilizing the
"immediate" flag that fail to see an update within the parental "immediate" flag that fail to see an update within the parental
agent's specified operational window should access the parental agent's specified operational window should access the parental
agent's error logging interface to determine why an update failed to agent's error logging interface to determine why an update failed to
be processed. 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. Note that this master could be a different to send data queries too. Note that this master could be a different
nameserver than the publically listed nameservers in the NS set nameserver than the publically listed nameservers in the NS set
(i.e., it may be a "hidden master"). (i.e., it may be a "hidden master").
Parental agents with a large number of clients may choose to offer a Parental agents with a large number of clients may choose to offer a
programmatic interface to let their children indicate that new CSYNC programmatic interface to let their children indicate that new CSYNC
records and data are available for polling rather than polling every records and data are available for polling rather than polling every
child on a frequent basis. child on a frequent basis.
Children that wish to phase out a nameserver will need to publish the
CSYNC record to the nameserver being removed and wait for the
parental agent to process the published record before turning off the
service. This is required because the child can not control which
nameserver in the existing NS set the parental agent may choose to
query when performing CSYNC processing.
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.
skipping to change at page 10, line 42 skipping to change at page 11, line 30
4.4. Documented Parental Agent Type Support 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)
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".
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
skipping to change at page 11, line 24 skipping to change at page 12, line 11
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 or the CSYNC record itself. Thus, implementations of this protocol
[I-D.ietf-dnsop-delegation-trust-maintainance] for maintaining MUST NOT use it to synchronize DS records, DNSKEY materials, CDS
security delegation information. records, CDNSKEY records, or CSYNC records. Similarly, future
documents extending this protocol MUST NOT offer the ability to
synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or
CSYNC records. For such a solution, please see the complimentary
solution [RFC7344] for maintaining security delegation information.
To ensure that an older CSYNC record making use of the soaminimum
flag can not be replayed to revert values, the SOA serial number MUST
NOT be incremented by more than 2^16 during the lifetime of the
signature window of the associated RRSIGs signing the SOA and CSYNC
records. Note that this is independent of whether or not the
increment causes the 2^32 bit serial number field to wrap.
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 (http://www.iana.org/assignments/dns-parameters) Parameters" registry (http://www.iana.org/assignments/dns-parameters)
for this record. for this record.
TYPE Value Meaning Reference TYPE Value Meaning Reference
skipping to change at page 12, line 16 skipping to change at page 13, line 14
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 For new assignments to be made to this registry, a new standards
published via a Standards Action. track 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, 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
skipping to change at page 13, line 25 skipping to change at page 14, line 25
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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[I-D.ietf-dnsop-delegation-trust-maintainance] [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344,
DNSSEC Delegation Trust Maintenance", September 2014.
draft-ietf-dnsop-delegation-trust-maintainance-14 (work in
progress), June 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. 20 change blocks. 
48 lines changed or deleted 88 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/