draft-ietf-dnsop-child-syncronization-01.txt   draft-ietf-dnsop-child-syncronization-02.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Parsons, Inc. Internet-Draft Parsons, Inc.
Intended status: Standards Track May 13, 2014 Intended status: Standards Track July 3, 2014
Expires: November 14, 2014 Expires: January 4, 2015
Child To Parent Synchronization in DNS Child To Parent Synchronization in DNS
draft-ietf-dnsop-child-syncronization-01 draft-ietf-dnsop-child-syncronization-02
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 of and value certain records from the child zone. The existence of and value
change of the record may be monitored by a parental agent and acted change of the record may be monitored by a parental agent and acted
on as appropriate. on as appropriate.
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 November 14, 2014. This Internet-Draft will expire on January 4, 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . 8
4. Operational Considerations . . . . . . . . . . . . . . . . . . 9 4. Operational Considerations . . . . . . . . . . . . . . . . . . 9
4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 9 4.1. Error Reporting . . . . . . . . . . . . . . . . . . . . . 9
4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 9 4.2. Child Nameserver Selection . . . . . . . . . . . . . . . . 9
4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 10 4.3. Out-of-balliwick NS Records . . . . . . . . . . . . . . . 10
4.4. Documented Parental Agent Type Support . . . . . . . . . . 10 4.4. Documented Parental Agent Type Support . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 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 it may 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 and value change of the record may be monitored by a
parental agent and acted on as appropriate. parental agent and acted on as appropriate.
Some resource records (RRs) in a parent zone are typically expected Currently today, some resource records (RRs) in a parent zone are
to be in-sync with the source data in the child's zone. The most typically expected to be in-sync with the source data in the child's
common records that should match, to date, are the nameserver (NS) zone. The most common records that should match are the nameserver
records and any necessary associated address records (A and AAAA), (NS) records and any necessary associated address records (A and
also known as "glue records". These records are referred to as AAAA), also known as "glue records". These records are referred to
"delegation records". as "delegation records".
It has been traditionally challenging for child DNS operators to It has been traditionally challenging for child DNS operators to
update their delegation records within the parent's set in a timely update their delegation records within the parent's set in a timely
fashion. This difficulty is frequently from simple operator laziness fashion. This difficulty is frequently from simple operator laziness
or because of the complexities of maintaining a large number of DNS or because of the complexities of maintaining a large number of DNS
zones. Having an automated mechanism for signaling updates will zones. Having an automated mechanism for signaling updates will
greatly ease the child zone operator's maintenance burden and improve greatly ease the child zone operator's maintenance burden and improve
the robustness of the DNS as a whole. the robustness 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
skipping to change at page 11, line 26 skipping to change at page 11, line 26
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.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 set of single-bit "Flags" for use in the This document defines a new DNS Resource Record Type, named "CSYNC".
The IANA is requested to assign a code point from the "Resource
Record (RR) TYPEs" sub-registry of the "Domain Name System (DNS)
Parameters" registry
(http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)
for this record.
TYPE Value Meaning Reference
----- ------ -------------------------- -----------
CSYNC TBA 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
"Child Synchronization (CSYNC) Flags" registry) of the "Domain Name
System (DNS) Parameters" registry. The initial values for this
registry are below. Assignment of new flag values are subject to
"RFC Required" specifications [RFC5226].
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. The two initial flags defined by this document flags may be defined.
are:
0x00 0x01: "immediate" The initial assignments in this registry are:
0x00 0x02: "soaminimum" Bit Flag Description Reference
---- ------ ------------- -----------
Bit 0 immediate Immediately process this [This document,
CSYNC record. Section 3]
Assignment of new flag values are subject to "RFC Required" Bit 1 soaminimum Require a SOA serial [This document,
specifications [RFC5226]. number greater than the Section 2.1.1.1]
one specified.
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. A thank you also goes out to Ed Lewis, who the author definition and significant contributions to the text. A thank you
held many conversations with about the issues surrounding parent/ also goes out to Ed Lewis, who the author held many conversations
child relationships and synchronization. Much of the work in this with about the issues surrounding parent/child relationships and
document is derived from the careful existing analysis of these three synchronization. Much of the work in this document is derived from
esteemed colleagues. Thank you to the following people who have the careful existing analysis of these three esteemed colleagues.
contributed text to the document: Matthijs Mekking and Petr Spacek. 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.
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.
skipping to change at page 12, line 48 skipping to change at page 13, line 28
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] [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-ietf-dnsop-delegation-trust-maintainance-13 (work in draft-ietf-dnsop-delegation-trust-maintainance-14 (work in
progress), May 2014. 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. 13 change blocks. 
27 lines changed or deleted 53 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/