One document matched: draft-mekking-dnsop-auto-cpsync-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc strict="yes"?>
<rfc ipr="trust200902" category="std" docName="draft-mekking-dnsop-auto-cpsync-01">
<front>
<title abbrev="Child Parent Synchronization"> Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE </title>

        <author fullname="Matthijs Mekking" initials="W.M." surname="Mekking">
                <organization> NLnet Labs </organization>
                <address>
                        <postal>
                                <street>Science Park 140</street>
                                <code>1098 XG</code>
                                <city>Amsterdam</city>
                                <country>The Netherlands</country>
                        </postal>
                        <email> matthijs@nlnetlabs.nl </email>
                </address>
        </author>

<date month="December" year="2010"/>
<area> Internet Area </area>
<workgroup> Domain Name System Operations </workgroup>
<keyword>DNS</keyword>
<keyword>DNSSEC</keyword>

<abstract><t> 
  This document proposes a way to synchronise existing trust anchors
  automatically between a child zone and its parent. The protocol can
  be used for other Resource Records that are required to delegate
  from a parent to a child such as NS and glue records. The
  synchronization allows for a third party to be involved, thus the
  protocol is suitable for both cases, whether you have to communicate
  to the registry or to the registrar.
</t></abstract>

<note title="Requirements Language">
<t>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  <xref target="RFC2119">RFC 2119</xref>.</t>
</note>

</front>
<middle>
<section title="Introduction">

<t>
This memo defines a way to synchronise existing trust anchors
automatically between a child zone and its parent. The protocol can
be used for other Resource Records that are required to delegate
from a parent to a child such as NS and glue records. The
synchronization allows for a third party to be involved, thus the
protocol is suitable for both cases, whether you have to communicate
to the registry or to the registrar.
</t>

<t>
To create a DNSSEC <xref target="RFC4035">RFC 4035</xref> chain of
trust, child zones must submit their DNSKEYs, or hashes of their
DNSKEYs, to their parent zone. The parent zone publishes the hashes
of the DNSKEYs in the form of a DS record. The DNSKEY RRset at the
child may change over time. In order to keep the chain of trust
intact, the DS records at the parent zone also needs to be updated.
The rolling of the keys with the SEP bit on is one of the few tasks
in DNSSEC that yet has to be fully automated.
</t>

<t>
The DNS UPDATE mechanism <xref target="RFC2136">RFC 2136</xref>
can be used to push zone changes to the parent.
</t>

<t>
To bootstrap the communication channel, information must be exchanged
in order to detect service location and granting update privileges.
A new or existing child zone is in need of a communication channel
with the parent. This can be a direct channel or a channel through a
third party:
</t>

<t>
  <list>
    <t> 
If the parent allows for direct communication channel with child zones,
the parent can share the required data to set up the channel to the
child zone. Once the child has the required credentials, it can use
the direct communication channel with the parent to request zone
changes related to its delegation.
    </t>
    <t> 
If a third party is involved, the third party acts on behalf of the
parent. In this case, the third party will give out the required
credentials to set up the communication channel.
    </t>
  </list>
</t>

<t>
Allowing for a third party in the communication channel ensures
flexibility of the service location.
</t>

<t>
Please note that the document only describes the front end of the
synchronization service. The first reason for that is that it is
not necessary to write down how the DNS UPDATE is processed after
it is accepted. It is merely a goal to provide a way for the child
zone to automatically update the records at the zone cut. The
second reason is that flexibility is needed in order to fit the
protocol into the multifarious policies that exist among the great
number of registrars.
</t>

<t>
Thus, it is not required that the DNS UPDATE immediately updates
the name server. Thus, it would still be possible to monitor the
incoming updates with the tools of your choice. It is not a 
replacement of your RR provisioning system. The records in the DNS
UPDATE can be converted into any kind of format. 
</t>

</section>

<section title="Service Discovery" anchor="sd">

<t>
The service location is handed out during bootstrap. If this
information is missing or incorrect, the normal guidelines for sending
DNS UPDATE messages SHOULD be followed.
</t>

</section>

<section title="Access and Update Control" anchor="acl">

<t> 
The DNS UPDATE normally is used for granting update permissions to a
machine that is within the boundary of the same organization. This
document proposes to grant child zones the same permissions. However,
it MUST NOT be possible that a child zone updates information in the
parent zone that falls outside the administrative domain of the
corresponding delegation. For example, it MUST NOT be possible for a
child zone to update the data that the parent is authoritative for, or
update a delegation that is pointed to a different child zone. It MUST
only be able to update records that match one of the following:
</t>

<t>
  <list style="hanging">
    <t hangText="Or: "> 
    The owner name is equal the child zone name and RRtype is delegation
    specific. Currently those are records with RRtype NS or DS.
    </t>
    <t hangText="Or: "> 
    The owner name exists in the right side of the NS RRset belonging to
    the child zone and RRtype is is glue specific. Currently those are
    records with RRtype A or AAAA.
    </t>
  </list>
</t>

<t>
We can make a distinction here between
narrow and wide glue records. Narrow glue records are said to be
glue specific records with an owner name that is a subdomain of the
child zone. Wide glue records are glue specific records with an
owner name that is outside of the delegated child domain.
</t>

<t>
These updates MAY be refused if it conflicts with the local policy.
This list may be expanded, if there is need for more delegation related
zone content.
</t>

<t>
In case of adding or deleting delegation specific records, the DNSSEC
related RRs in the parent zone might need to be updated.
</t>

</section>


<section title="Update Mechanism" anchor="mechanism">
  <section title="Update Request" anchor="child">
  <t>
  Updating the NS RRset or corresponding glue at the parent, an update can
  be sent at any time. Updating the DS RRset is part of key rollover, as
  described in RFC 4641 <xref target="RFC4641" />. When performing a key
  rollover that involves updating the RRset at the parent, the child
  introduces a new DNSKEY in its zone that represents the security entry
  point for determining the chain of trust. After a while, it will revoke
  and/or remove the previous security entry point. The timings when to 
  update the DS RRset at the parent are described in 
  <xref target="keytiming">draft-dnsop-morris-dnssec-key-timing</xref>.
  When updating the DS RRset at the parent automatically, these timing
  specifications SHOULD be followed. To determine the propagation delays
  described in this document, the child should poll the parent zone for
  a short time, until the DS is visible at all parent name servers.
  </t>
  <t>
  [Author's note] To discuss: 
  A child zone might be unable to reach all parent name servers.
  </t>
  <t>
  The child notifies the parent of the requested changes by sending a DNS
  UPDATE message. If it receives a NOERROR reply in return, the update is
  acknowledged by the parent zone. Otherwise, the child MAY retry
  transmitting the update. In order to prevent duplicate updates, it SHOULD
  follow the guidelines described in RFC 2136 <xref target="RFC2136"/>.
  </t>
  </section>

  <section title="Processing the Update" anchor="parent">
  <t>
  An incoming DNS UPDATE message is processed as follows:
  </t>
  <t>
    <list style="hanging">
    <t hangText="Step 1:"> Check the TSIG/SIG0 credentials. In case of
    TSIG, the parent should follow the TSIG processing described in
    section 3.2 of RFC 2845. In case of SIG0, the parent should follow the
    SIG0 processing described in section 3.2 of RFC 2931.
    </t>
    <t hangText="Step 2:"> Verify that the updates matches the update
    policy for child zones.</t>
    <t hangText="Step 3:"> If verified, send back DNS UPDATE OK.
    Otherwise, send back DNS UPDATE REFUSED.
    </t>
    <t hangText="Step 4:"> If verified, apply changes.
    How that is done is a matter of policy.
    </t>
    </list>
  </t>
  </section>

</section>

<section title="Examples" anchor="example">
  <section title="Example BIND9 Configuration" anchor="example1">
  <t>
  This is how a parent zone can configure a policy to enable a child zone
  synchronize delegation specific records. The first rule of the update
  policy grants children to update their DS and NS records in the parent
  zone, in this case example.com. The second rule of the update policy
  grants children to update the corresponding glue records.
  </t>

  <t>
  key cs.example.com. { <vspace blankLines="0" />
     algorithm HMAC-MD5; <vspace blankLines="0" />
     secret "secretforcs"; <vspace blankLines="0" />
  }
  </t>
  <t>
  key math.example.com. { <vspace blankLines="0" />
     algorithm HMAC-MD5; <vspace blankLines="0" />
     secret "secretformath"; <vspace blankLines="0" />
  }
  </t>
  <t>
  ...
  </t>
  <t>
  zone "example.com" { <vspace blankLines="0" />
    type master; <vspace blankLines="0" />
    file "example.com"; <vspace blankLines="0" />
    update-policy { grant *.example.com. self *.example.com. DS NS; }; <vspace blankLines="0" />
    update-policy { grant *.example.com. selfsub *.example.com. A AAAA; }; <vspace blankLines="0" />
  };
  </t>
  </section>
</section>

<section title="Security Considerations" anchor="sec">
<t> 
Automating the synchronization of (DNSSEC) records between the parent
and child creates a new communication channel. It is up to the policy of
the parent, or the third party acting on behalf of the parent, who is
allowed such privileges. A policy would usually include a form of access
control. It is recommended that it involves transaction authentication, 
for example TSIG <xref target="RFC2845"/> or SIG0 <xref target="RFC2931"/>.
</t>

<t>
In the jungle of the DNS, many stakeholders exist. The registrant of a
zone might not be the one that maintains the zone. That can possibly mean
that many stakeholders need to possess the security credentials in order
to use this synchronization channel. However, this problem exist with
any kind of transaction authentication.
</t>

<t>
The disadvantage of adding a new communication channel is that you create
a new attack window onto your DNS and DNSSEC records. When using this
synchronization method for your DNSSEC records, a cryptographically equally
strong, or stronger private key SHOULD be used, compared to the strength of
your DNSSEC keys.
</t>

<t>
The advantage is that if somehow your DNSSEC keys are compromised, you
can still use this channel to perform an emergency key rollover.
</t>
 
</section>

<section anchor="IANA" title="IANA Considerations">

<t> None. </t>

</section>

<section anchor="ack" title="Acknowledgments">

<t>
Mark Andrews,
Rickard Bellgrim,
Wolfgang Nagele,
Wouter Wijngaards.
</t>

</section>

<section anchor="changelog" title="Changelog">

<t>
01:
  <list>
    <t> 
- Make it clear that the solution is flexible and it
  can fit into many and diverse environments of 
  registrars.
    </t>
    <t>
- Short section about service discovery.
    </t>
    <t>
- Add text about narrow glue records.
    </t>
    <t>
- Add text about transaction authentication concerns
  with respect to many stakeholders involved.
    </t>
  </list>
</t>

<t>
00:
  <list>
    <t> 
- Initial document
    </t>
  </list>
</t>

</section>

</middle>

<back>
        <references title="Informative References">
                <?rfc include="reference.RFC.2136" ?>
                <?rfc include="reference.RFC.4641" ?>
		<reference anchor='keytiming'>
             	    <front>
			<title>DNSSEC Key Timing Considerations</title>
			<author initials='S.' surname='Morris' fullname='S. Morris'>
			<organization/>
			</author>
			<author initials='J.' surname='Ihren' fullname='J. Ihren'>
			<organization/>
			</author>
			<author initials='J.' surname='Dickinson' fullname='J. Dickinson'>
			<organization/>
			</author>
			<date year='2010' month='March'/>
		    </front>
		</reference>
        </references>

        <references title="Normative References">
                <?rfc include="reference.RFC.2119" ?>
                <?rfc include="reference.RFC.2845" ?>
                <?rfc include="reference.RFC.2931" ?>
                <?rfc include="reference.RFC.4035" ?>
        </references>
</back>
</rfc>