DNSOP W. Hardaker
Internet-Draft Parsons, Inc.
Intended status: Standards Track July 14, 2013
Expires: January 15, 2014
Child To Parent Synchronization in DNS
draft-hardaker-dnsop-csync-01
Abstract
This document specifies how a child zone in the DNS can publish a
record that can indicate that a parental agent may copy and process
certain records from the child zone. The existence and change of the
record may be monitored by a parental agent to either assist in
transferring or automatically transfer data from the child to the
parent.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 15, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Hardaker Expires January 15, 2014 [Page 1]
Internet-Draft Child To Parent Synchronization in DNS July 2013
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used in This Document . . . . . . . . . . . . 3
2. Definition of the CSYNC RRType . . . . . . . . . . . . . . . . 4
2.1. The CSYNC Resource Record Format . . . . . . . . . . . . . 4
2.1.1. The CSYNC Resource Record Wire Format . . . . . . . . 4
2.1.2. The CSYNC Presentation Format . . . . . . . . . . . . 6
2.1.3. CSYNC RR Example . . . . . . . . . . . . . . . . . . . 6
2.2. CSYNC Data Processing . . . . . . . . . . . . . . . . . . 6
2.2.1. Processing Procedure . . . . . . . . . . . . . . . . . 7
2.2.2. CSYNC Record Types . . . . . . . . . . . . . . . . . . 7
2.3. Operational Considerations . . . . . . . . . . . . . . . . 10
2.3.1. Error Reporting . . . . . . . . . . . . . . . . . . . 10
2.3.2. Child Nameserver Selection . . . . . . . . . . . . . . 11
2.3.3. Documented Parental Agent Type Support . . . . . . . . 11
2.3.4. Other Considerations . . . . . . . . . . . . . . . . . 12
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Hardaker Expires January 15, 2014 [Page 2]
Internet-Draft Child To Parent Synchronization in DNS July 2013
1. Introduction
[Up front note: this document is very rough in wording. It is
offered as a starting point to see if there is interest in pursuing
the concepts contained herein before significant work is done on
wording refinements]
This document specifies how a child zone in the DNS can publish a
record that can indicate that a parental agent may copy and process
certain records from the child zone. The existence and change of the
record may be monitored by a parental agent to either assist in
transferring or automatically transfer data from the child to the
parent.
Some resource records (RRs) in a parent zone are typically expected
to be in-sync with the data in the child's zone. The most common
records that should match are the nameserver (NS) records and any
necessary associated address (A and AAAA) "glue" records.
Additionally, the children frequently have DNSKEY records which
require corresponding DS record(s) in the parent. These records are
referred to as "delegation records".
It has been traditionally challenging for children to keep delegation
records within a parent's delegation record set up to date. This
difficult has usually derived from simple operator laziness or the
complexities of maintaining a large number of DNS zones. Having an
automated mechanism to update a parent's set of delegation records
will greatly ease the child zone operator's maintenance burden and
improve the robustness of the DNS as a whole.
This draft introduces a new RR type (RRType) named "CSYNC" that
indicates which delegation records within a child should be processed
into the parent's DNS zone data.
1.1. Terminology Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document is aimed at the case where there is an organizational
separation of the child and parent. In this case there are many
different operating situations. A common case is the Registrant/
Registrar/Registry relationship. In this case the parent consists of
Registrar and Registry, with different rules on what each can do or
not do. To remain operating model neutral we will use the neutral
word "Parental Agent" as the entity that uses results of DNS queries
to inject delegation changes into the parent zone. The entity that
Hardaker Expires January 15, 2014 [Page 3]
Internet-Draft Child To Parent Synchronization in DNS July 2013
inserts the changes in the the DNS is called "DNS Publisher".
2. Definition of the CSYNC RRType
The CSYNC RRType contains, in its RDATA component, these parts: an
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 parent
agent to modify the DNS delegation records for the child within the
parent's zone. Children wanting a parental agent to perform a
synchronization MUST publish a CSYNC record at the apex of the child
zone. Parent agent implementations MAY choose to query child zones
for this record and process the data indicated by the Type Bit Map
field in the RDATA of the CSYNC record. How the data is processed is
later described in Section Section 2.2.
Parental agents MUST process the entire set of child data requested
(i.e., all record types indicated along with all of the necessary
records to support processing of that type) or else parent agents
MUST NOT process any data records at all. Errors due to unsupported
Type Bit Map bits or otherwise nonpunishable data SHALL result in no
change to the parent zone's delegation information for the child.
Parental agents SHOULD ignore a child's CSYNC RDATA set if multiple
CSYNC resource records are found; only a single CSYNC record should
be expected.
The parental agent MUST perform DNSSEC validation of the CSYNC RRType
data and MUST perform DNSSEC validation of any data to be copied from
the child to the parent. Parents MUST not process any data if any of
the validation results indicate any anything other than "Secure"
[RFC4034].
2.1. The CSYNC Resource Record Format
2.1.1. The CSYNC Resource Record Wire Format
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type Bit Map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Map (continued) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hardaker Expires January 15, 2014 [Page 4]
Internet-Draft Child To Parent Synchronization in DNS July 2013
2.1.1.1. The SOA Serial Field
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 agent
querying children's authoritative servers MUST NOT act on data from
zones advertising an SOA serial number less than this value. A
special value of 0 indicates that no such restriction is in place.
Note that a child zone's current SOA serial number maybe greater than
the number contained in the CSYNC record. A child SHOULD update 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
associated address record is changed). A child MAY choose to update
the SOA Serial field to always match the current SOA serial field.
Parental agents MAY cache SOA serial numbers from data they use and
refuse to process data from zones older than the last instance they
pulled data from.
2.1.1.2. The Flags Field
The Flags field contains 16 bits of flags defining operations that
affect the processing of the CSYNC record. The flags defined in this
document are as follows:
0x00 0x01: "immediate"
The definitions for how the flags are to be used can be found later
in Section Section 2.2.
The remaining flags are reserved for use by future specifications.
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
flag that is unknown to or unsupported by the parental agent.
2.1.1.2.1. The Type Bit Map Field
The Type Bit Map field indicates the record types to be processed by
the parental agent, according to the procedures in Section
Section 2.2. 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. If a bit has been set that a parental agent
implementation does not understand, the parental agent MUST NOT act
upon the data. Specifically, a parental agent must not copy data
blindly; A specification must exist [insert long debate here over
level of specification required; IMHO: proposed IETF standard since a
bit can only be used once] that defines how the data should be
processed for a given bit.
Hardaker Expires January 15, 2014 [Page 5]
Internet-Draft Child To Parent Synchronization in DNS July 2013
2.1.2. The CSYNC Presentation Format
The CSYNC presentation format is as follows:
The SOA Serial 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
mnemonics. When the mnemonic is not known, the TYPE
representation described in [RFC3597], Section 5, MUST be used.
2.1.3. CSYNC RR Example
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
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
in hexadecimal).
example.com. 3600 IN CSYNC 66 1 A NS AAAA
The RDATA component of the example CSYNC RR would be encoded on the
wire as follows:
0x00 0x00 0x00 0x42 (SOA Serial)
0x00 0x01 (Flags)
0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map)
2.2. CSYNC Data Processing
The CSYNC data must be processed as an "all or nothing" type
operation. If a parental agent fails to query for any of the
required records from the child, the whole operation MUST be aborted.
(Note that a query resulting in "no records exist" as proven by NSEC
or NSEC3 is to be considered successful).
Parental agents MAY:
Process the CSYNC record immediately after noticing it if the
"immediate" flag is set. If the "immediate" flag is not set, the
parental agent MUST not act until the zone administrator approves
the operation through an out-of-band mechanism (such as through a
web interface).
Require that the child zone administrator approve the operation
through an out-of-band mechanism (such as through a web
interface). I.e., a parental agent MAY choose not to support the
Hardaker Expires January 15, 2014 [Page 6]
Internet-Draft Child To Parent Synchronization in DNS July 2013
"immediate" flag.
Note: how the approval is done out-of-band is outside the scope of
this document and likely specific to a particular parental agent.
2.2.1. Processing Procedure
The following shows a sequence of steps that SHOULD be used when
collecting and processing CSYNC records from a child zone. Because
DNS queries are not allowed to contain more than one question at a
time, a sequence of requests will be needed. To ensure a single host
is being addressed, DNS over TCP SHOULD be used to avoid conversing
with multiple nodes at an anycast address.
1. Query for the child zone's SOA record
2. Query for the child zone's CSYNC record
3. Query for the child zone's data records, as required by the CSYNC
record's Type Bit Map field
4. Query for the child zone's SOA record again
If the SOA records from the first and last steps have different
serial numbers, then this CSYNC record set MUST NOT be processed.
If the SOA serial number(s) are less than the CSYNC record's SOA
Serial Field, the record MUST NOT be processed. If state is being
kept and the SOA serial number is less than the last time a CSYNC
record was processed, this CSYNC record SHOULD NOT be processed.
If DNSSEC fails to validate all of the data returned as "secure",
this CSYNC record MUST NOT be processed.
See the "Operational Consideration" section (Section Section 2.3) for
additional guidance about processing.
2.2.2. CSYNC Record Types
This document defines how the following record types may be processed
if the CSYNC Type Bit Map field indicates they should be processed.
2.2.2.1. The NS type
The NS type flag indicates that the NS records from the child zone
should be copied into the parent's delegation information records for
the child.
Hardaker Expires January 15, 2014 [Page 7]
Internet-Draft Child To Parent Synchronization in DNS July 2013
NS records found within the child's zone should be copied verbatim
and the result published within the parent zone should be a matching
set of NS records. Note: if NS records in the parent's delegation
records for the child contain records that have been removed in the
child's NS set, then they should be removed in the parent's set as
well.
Parental agents MAY refuse to perform NS updates if the replacement
records fail to meet NS record policies required by the parent zone
(e.g. "every child zone must have at least 2 NS records").
2.2.2.2. The A and AAAA types
The A and AAAA type flags indicates that the A and AAAA,
respectively, address glue records for in-bailiwick NS records within
the child zone should be copied into the parent's delegation
information.
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
child that are in-bailiwick.
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
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
appropriate NSEC or NSEC3 records), then the result in the parent's
delegation records for the child should be an empty set.
The procedure for querying for A and AAAA records MUST occur after
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
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
ones pulled from the child during processing. For 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 search
for.
2.2.2.3. The DNSKEY type
[Editors note: originally I was going to present this draft with no
support for DS records as the CDS draft existed and looked like a
mechansim that better covered all the DS specific usage cases.
However, I've added this section as a discussion point for another
mechansim based on conversations with IETF members. CSYNC may or may
not be sufficient and opinions are sought about whether CSYNC is a
viable mechansim for DS replacement or not.]
Hardaker Expires January 15, 2014 [Page 8]
Internet-Draft Child To Parent Synchronization in DNS July 2013
The DNSKEY type bit indicates that the DNSKEY records in the child
with the SEP bit set and the REVOKE bit cleared should be used to
create a new set of DS records for inclusion in the parent's
delegation records for the child zone.
A query should be sent to the child zone to obtain all the DNSKEY
records within the zone, and DS records should be generated for the
appropriate keys.
The DNSKEY type bit MUST NOT be set when the owner/maintainer of the
DNSKEY records for a zone that don't contain a set SEP bit is
different than the owner/maintainer of the DNSKEY records with the
SEP bit set. Organizationally, if the maintainers of the DNSKEY
records used to sign the entire contents of the zone are different
than the keys intended for the purpose of a secure-entry-point, it is
important than only the maintainers of the SEP bit set of DNSKEYs may
replace pointers to the SEP bit set of DNSKEYs.
Note: this DS change mechansim does not provide the client with the
ability to select (in-band) the DS algorithms used in the parent.
The DS type bit should be used instead if both the parent and child
wish the child to be able to select the DS algorithm(s) to be used.
Children that wish to do so should use the DS type bit instead, if
their parental agent supports it.
Note: this DS change mechansim does not let children publish DS
records that point to not-yet-published DNSKEYs. Children that wish
to do so should use the DS type bit instead, if their parental agent
supports it.
2.2.2.4. The DS type
[Editors note: originally I was going to present this draft with no
support for DS records as the CDS draft existed and looked like a
mechansim that better covered all the DS specific usage cases.
However, I've added this section as a discussion point for another
mechansim based on conversations with IETF members. CSYNC may or may
not be sufficient and opinions are sought about whether CSYNC is a
viable mechansim for DS replacement or not.]
The DS type bit indicates that the child has created and published DS
records within the child's zone (i.e., below the cut-point) and these
records should be copied into the parent's delegation records for the
child zone.
A query should be sent to the child zone to obtain all the DS records
within the zone, and the DS records should found should be copied
into the parent zone's delegation records for the child zone.
Hardaker Expires January 15, 2014 [Page 9]
Internet-Draft Child To Parent Synchronization in DNS July 2013
The DNSKEY type bit MUST NOT be set when the owner/maintainer of the
DNSKEY records for a zone that don't contain a set SEP bit is
different than the owner/maintainer of the DNSKEY records with the
SEP bit set. Organizationally, if the maintainers of the DNSKEY
records used to sign the entire contents of the zone are different
than the keys intended for the purpose of a secure-entry-point, it is
important than only the maintainers of the SEP bit set of DNSKEYs may
replace pointers to the SEP bit set of DNSKEYs.
Parental agents MUST check that at least one of the to-be-published
DS records within the new set points to a "secure" DNSSEC-validated
DNSKEY record. IE, updating of the DS record set within the parent
zone MUST not be done if the parental agent determines it will no
longer be possible to validate the zone data within the child. [XXX:
yes, a discussion is needed about algorithm and other support
differences].
Note: this DS change mechansim does not let the parent select the
algorithms for the DS record to be used. The parent MAY choose not
to support the DS type bit if they wish to establish policy for DS
algorithm usage within their children's zones. In this case, the
parental agent should support the DNSKEY type bit instead.
Note: this DS change mechansim lets children publish DS records that
may point to unpublished DNSKEY records.
[Editors note: I'm not sure it's safe to reuse the DS record type
here. Having two different DS sets at a parent and child is
questionably safe from a validator's point of view. It's unclear the
effect that it might have on existing deployed code, and it would
seem safer to me to publish a new record type, such as the CDS type,
for querying child DS records rather than reusing the existing DS
type. Opinions desired.]
[One option would be to publish the DS records at a separate
location, such as _ds._dns.example.com]
2.3. Operational Considerations
There are a number of important things to consider when deploying a
CSYNC RRType.
2.3.1. Error Reporting
There is no inline mechanism for a parental agent to report errors to
child zones. Thus, the only error reporting mechanisms 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 update
Hardaker Expires January 15, 2014 [Page 10]
Internet-Draft Child To Parent Synchronization in DNS July 2013
within the parental agent's specified operational window should
access the parental agent's log interface to determine why an update
failed to be processed.
2.3.2. Child Nameserver Selection
Parental agents will need to poll child nameservers in search of
CSYNC records and any other data required for processing a CSYNC
record.
Parental agents MAY perform best-possible verification by querying
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
equal but this is not possible in practice due to synchronization
delays and transfer failures).
Parental agents MAY offer a configuration interface to allow child
operators to specify which nameserver should be considered the master
to send data queries too. Child operators should be encouraged to
make use of this configuration interface.
2.3.3. Documented Parental Agent Type Support
Parental agents that support processing CSYNC records SHOULD publicly
document the following minimum processing characteristics:
The fact that they support CSYNC processing
The Type Bit Map bits they support
The frequency with which they poll clients (which MAY be
configurable by the client)
If they support the "immediate" flag
If they poll a child's single nameserver, a configured list of
nameservers, or all of the advertised nameservers when querying
records
If they support SOA serial number caching to avoid issues with
regression and/or replay
Where errors for CSYNC processing are published
Hardaker Expires January 15, 2014 [Page 11]
Internet-Draft Child To Parent Synchronization in DNS July 2013
2.3.4. Other Considerations
TBD
XXX: Discuss complete replacement scenarios and if allowed.
XXX: Polling frequency discussion
XXX: differences between DS and DNSKEY type bits
3. Security Considerations
TBD
XXX: mention over and over that DNSSEC validation is required for
every request
XXX: discussion on DNSSEC checking requirements for both before and
after changes take place.
XXX: mention that DS records for SEP-bit DNSKEYs being updating by
CSYNC records signed by non-SEP bits should be carefully considered
before being used.
4. IANA Considerations
TBD
5. Acknowledgments
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
document, as well as the definition for "Parental Agent" and "DNS
Publisher" definitions. A thank you also goes out to Ed Lewis, who
the author held many conversations with about the issues surrounding
parent/child relationships and synchronization. Much of the work in
this document is derived from the careful existing analysis of these
three esteemed colleagues.
6. References
Hardaker Expires January 15, 2014 [Page 12]
Internet-Draft Child To Parent Synchronization in DNS July 2013
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
6.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Author's Address
Wes Hardaker
Parsons, Inc.
P.O. Box 382
Davis, CA 95617
US
Phone: +1 530 792 1913
Email: ietf@hardakers.net
Hardaker Expires January 15, 2014 [Page 13]