One document matched: draft-mekking-dnsop-auto-cpsync-00.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-00">
<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="June" 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 algorithm can
  be used for other Resource Records that are required to delegate
  from a parent to a child such as NS and glue records.
</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 algorithm can
be used for other Resource Records that are required to delegate
from a parent to a child such as NS and glue records.
</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 direct communication channel, information must be
exchanged in order to detect service location and granting update
privileges. A new or existing child zone can request a direct
communication channel with the parent. If the parent allows for direct
communication 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 can act on behalf of the
parent. In this case, the third party will give out the required
credentials to set up the communication channel.
</t>
<t>
It is RECOMMENDED that the direct communication channel is secured
with TSIG <xref target="RFC2845"/> or SIG0 <xref target="RFC2931"/>.
</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 is a subdomain of the child zone name and RRtype is
    glue specific. Currently those are records with RRtype A or AAAA.
    </t>
  </list>
</t>
<t>
This list may be expanded in the future, 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>
<t>
The service location may be handed out by the registrar during bootstrap
If this information is missing, the normal guidelines for sending DNS
UPDATE messages SHOULD be followed.
</t>
</section>

<section title="Update Mechanism" anchor="mechanism">
  <section title="Child Duties" 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>
  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="Parent Duties" anchor="parent">
  <t>
  When the master DNS server of the parent receives a DNS UPDATE from one
  of its children the following must be done:
  </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 title="Proxy considerations">
  <t>
  Some environments don't allow for direct communication between parent
  and child zone. In these case, the parent duties can be performed by a
  different party (for example, the registar). The third party will
  forward the update to the parent zone. In what format depends on local
  policy.
  </t>
  </section>
</section>

<section title="Example BIND9 Configuration" anchor="example">
<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 title="Security Considerations" anchor="sec">
<t> 
Automating the synchronization of (DNSSEC) records between the parent
and child created a new channel. We have recommended that this channel
should be secured with TSIG or SIG0. There is an advantage and a
disadvantage of the new security channel. The disadvantage is that you
create a new attack window for your DNSSEC credentials. If the automated
synchronization is used for updating DS records at the parent, you
SHOULD pick a cryptographically an equally strong or stronger TSIG/SIG0
key than 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> Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more. </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>