<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="info" docName="draft-wouters-dnsop-secure-update-use-cases-00.txt" ipr="trust200902">

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Secure parent-child DNS update use cases">Secure parent-child DNS update use cases</title>
    <author fullname="Paul Wouters" initials="P." surname="Wouters">
      <organization>Red Hat</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>pwouters@redhat.com</email>
      </address>
    </author>

    <date year="2012" />


    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
         in the current day and month for you. If the year is not the current one, it is 
         to specify at least a month (xml2rfc assumes day="1" if not specified for the 
         purpose of calculating the expiry date).  With drafts it is normally sufficient to 
         specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Security</area>

    <workgroup>DNSOP</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
         If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>DNSOP</keyword>
    <keyword>DNSSEC</keyword>
    <keyword>Automatic DNS parent-child updates</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
DNS zone administrators occasionally need to update data published by
a parent zone, such as NS and DS records.  Traditionally these updates
have happened out-of-band: through DNS registrar interfaces, EPP, websites,
or manually by operators.  Some updates could also be done using DNS Dynamic Update
<xref target="RFC2136"/>.
</t>
<t>
The IETF's DNSOP working group is considering proposing additional
mechanisms for such updates, possibly leveraging DNSSEC for
authentication.
</t>
<t>
This document presents some use cases to drive this design work.
</t>

    </abstract>
  </front>

   <middle>
<section anchor="intro" title="Introduction">
       <t>
Existing mechanisms for child-to-parent communication in DNS have some
constraints that limit their utility.  In particular, they require an
authentication, which typically requires an extra credential to be    
exchanged between parent and child.  With the advent of DNSSEC, it    
might be possible to use DNSSEC to authenticate these updates.
</t>
<t>
Furthermore, current mechanisms such as dynamic update also require that
the child zone be able to reach the master server for the parent zone.
In environments with hidden masters, offline DNSSEC signers or other
network architecture constraints, this is not always be feasible.
</t>

<t>
This document identifies the main targets and use cases for automated
updates and the concerns related to such automation.
</t>
<t>
[Note: While the document describes the use-cases with the zone, not the name server,
 as actor, this should not be taken to mean the signaling must be within the zone ]
</t>
</section>
	  
      <section title="Terminology" anchor="terminology">
        <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&nbsp;2119</xref>.</t>

      </section>

<section title="DNS records with use cases for automated updates">
  <t>
This document limits the scope of use cases to those DNS records that 
relate to the parent-child relationship itself. Policies for the TTL could be
dictated by the parent or the child, depending on the relationship.
  </t>
    <section title="The DS RRset">
    <t>
The DS record needs to be updated when the child zone performs a Key
Signing Key rollover. The parent name server cannot necessarily confirm
the updated information by looking into the child zone, for example when
the child zone has a spare, unpublished, DNSKEY record. Some parents
want to receive DNSKEYs and create the DS record based on the received
record. Other parents do not want to be responsible for creating any
data for the child, and want to receive ready-made DS records, optionally
restrained by the parent's choices of valid algorithms.
    </t>
    </section>
  
    <section title="The NS RRset">
    <t>
Both the child and the parent have a copy of the NS RRset. These RRsets
are supposed to be identical. If they differ, it is referred as a "Lame
Delegation". Keeping these sets synchronized would result in fewer lame
delegations. Modifying the NS RRset is more complicated, as it could
involve talking to name servers who do not yet know about the zone.
    </t>
    </section>

    <section title="Glue records">
    <t>
Glue records are A or AAAA records that are needed to resolve an NS record
that has a recursive relationship. For example, if the NS record for example.com
points to ns.example.com, then a glue record is added to the parent zone (.com)
for ns.example.com. Note that ns.example.com could be used in NS records for
other zones as well.
    </t>
    </section>
</section>


    <section title="Use cases" anchor="usecases">
<t>
There are different kind of parent-child relationships. A very common relationship
is the TLD registry using a Registry-Registrar-Registrant model. In this model, the
child dictates the content to the parent. Another common parent-child relationship
is the corporate relationship where the head office dictates some parent zone content to
the child.
</t>

<section title="DNSSEC use cases in the Registant, Registrar, Registry model" anchor="case1">
  <section title="Registrar has not adopted DNSSEC">
<t>
Registrant running the child zone needs to convey their DS record to
the Registry running the parent zone. Registrant can only communicate to
the Registry using a Registrar. This Registrar does not support the EPP
option to convey the DS record from Registrant to Registry. By sending
an update via DNS to the Registry, Registrant bypasses the limitations
of the Registrar. This use case would require some kind of boot-strap.
</t>
  </section>
  <section title="Registrar supports DNSSEC tediously">
<t>
Registrar supports sending a DS record to the Registry via EPP. Registrant
needs to use a human-oriented website interface of Registrar, which is
very hard to automate and would break every time Registrar modifies their
website for Registrants.  By sending an update via DNS to the Registry,
Registrant bypasses the limitations of the Registrar.
</t>
  </section>
  <section title="sub-Registrar supports DNSSEC but Registrar does not">
<t>
Registrant can send DNSSEC updates to their (sub)Registrar, but the Registrar does
not support receiving updates from sub-Registrar and sub-Registrar cannot communicate
to Registry directly. The Registrant or sub-Registrar could bypass the limitations of
the Registrar by sending DNSSEC updates directly to the Registry.
</t>
  </section>
  <section title="Registrant not setup to talk EPP to Registrar">
<t>
Registrant is a lightweight entity using an off-the-shelve DNSSEC management solution.
They have no technical expertise to communicate using EPP to the Registrar or Registry.
Their DNS software could automate sending DNSSEC updates to the Registrar or Registry.
</t>
  </section>
 </section>

<section title="DNSSEC use cases with direct parent-child DNS server communication" anchor="case2">

  <section title="DNS management solution of different vendors cannot communicate">
<t>
Two different vendors have implemented non-standard, vendor-specific
methods for non-DNS parent-child interaction. The DNS administrator(s)
have different devices that cannot communicate with each other. If a
generic DNS method was standardized, devices could implement this method
and inter-operate with each other.
</t>
  </section>
  <section title="DNS management solution requires non-DNS traffic and new Authentication method">
<t>
A non-DNS method for updating DS records between parent and child has
been implemented.  This method requires a lot of overhead to deploy. A
new authentication method between parent and child is needed, for which
there is no standard, causing potential interoperability issues. Firewall
zones for DNS servers need to be updated to allow non-DNS traffic. If a
generic DNS method was standardized, devices could implement this method
and inter-operate with each other.
</t>
  </section>
  <section title="DNS Management GUI tools are lacking DNSSEC support">
<t>
The DNS administrator is both administrating parent and child zone using
one or more DNS management solutions. These solutions are running known
up to date name server software but the vendor has not yet adopted DNSSEC
in their GUI. A standardized solution not requiring additional GUI components
could support updates more readily.
</t>
  </section>
  <section title="DNS management solution does not handle when being both child and parent">
<t>
The DNS administrator uses a vendor product that does not automate adding the DS in
the parent zone, despite the child DNSKEY being available to it. The DNS administrator
needs to manually calculate the DS record and add it to the parent. They can no longer
run automated rollovers due to this required action that can only be performed manually.
If a generic DNS method was standardized, the device could send updates irrespective of
whether it also manages the parent zone without additional effort.
</t>
  </section>
 
  </section>

<section title="Non-DNSSEC related DNS record updates" anchor="case3">
  <section title="NS record and glue updates for the parent">
  <t>
Registrant has a difficult time keeping parent glue and NS RRsets up to
date due to using a manual process. After establishing an authenticated
relationship between parent and child using the DNSKEY/DS records, the
parent could update its glue records based on the child zone content,
either by regular polling, or by receiving a notification of the child to
update. The parent could distribute such a notification to its siblings.
  </t>
  </section>
  <section title="Parent changes its infrastructure">
  <t>
Parent name servers are pulling zones from different hidden primaries
run by different departments with hundreds of zones. The parent name
server infrastructure changes, and it wants to all its hidden primaries
to use a different NS RRset. The parent sends an update to the hidden
primaries to update the NS RRset for their zones. This category would
also cover dyndns solutions where clients send individual host record
updates to a parent that might change its location.
  </t>
  </section>
</section>

 </section>

<section title="Relationships of zones and name servers" anchor="relationships">
<t>
While the relationship between child zone and parent zone are well defined, in
practice the chain of DNS servers involved is more complicated. Often the
authoritative servers for the child zone do not communicate directly with
the authoritative servers of the parent zone. Any methods for signaling between
the child and parent zone should attempt to accommodate the listed infrastructure.
</t>

<section title="Hidden primary servers">
<t>
Zones could be updated with IXFR/AXFR using hidden primary servers. DNSSEC
signers often work this way. These primary name servers are usually
restricted via dedicated VPN links or firewalls, and may not be able
to determine or communicate with the required parent server for sending
or receiving updates.
</t>
</section>

<section title="Offline private keys">
<t>
Some DNSSEC signing solutions keep the private key inside an HSM or
otherwise keep the private keys offline. Updates would need to be able to be
generated offline, transported to an internet connected machine, and
then transmitted to the parent zone.
</t>
</section>

<section title="Parent infrastructure">
<t>
Some parent zones will require receiving updates for child zones directly
from the child name servers, facilitating their current use of firewalls
to restrict communication within the network. Other parent zones, such as
TLDs, will want to leave their current name server structure unchanged
and prefer updates for the child to a special name server dedicated to
receive these updates.
</t>
</section>

<section title="Update capability indicator">
<t>
Servers or zones that do not support or allow secure updates should not be
sent repetitive update requests.
</t>
</section>

<section title="Legalities">
<t>
Some deployments need to take legal restrictions into account. One such example
is the Registry, Registrar, Registrant model, where the Registrant and Registry
have no formal relationship with each other or are prohibited from communicating
directly with each other. In such situations, secure automated updates should not
be attempted.
</t>
</section>
</section>

<section title="The in-band update process" anchor="updates">
<t>
Depending on the appropriate process and relationship between parent and
child zone, there could be different requirements for the update process.
</t>

   <section title="No automatic updates">
<t>
Records must be added or modified by the administrator of the zone using an out-of-band method.
</t>
   </section>
   <section title="Automatic child to parent updates for the DS record only">
<t>
The child can send updates of its DS record to the parent, but cannot request
updates to the NS RRset or glue records. The parent must be able to reject DS
records that do not comply to its allowed selection of valid DNSKEY algorithms.
</t>
   </section>
   <section title="Fully-automatic child to parent updates">
<t>
The child can send updates of all its records hosted at the parent, including DS records,
NS records and glue records. The parent must be able to reject certain updates based on
local policy
</t>
   </section>
   <section title="Automatic parent to child updates">
<t>
The parent can send updates to the child for the NS records and glue records.
</t>
   </section>
   <section title="Fully-automatic child and parent synchronization">
<t>
Parent and child automatically synchronize with no interaction on the part of the operators.
This could be uni-directional of bi-directional.
</t>
   </section>
   <section title="Semi-automatic update">
<t>
Parent and child synchronize, but only on the request of the parent or child administrator.
</t>
   </section>

</section>

    <section title="Applicability of automated updates to DNS infrastructure records" anchor="applicability">
<t>
Automation and direct communication might not be appropriate in all scenarios.
Implementations should take note of the considerations in this section.
</t>
       <section title="Administrative Criteria">
<t>
There are many situations where automated updates would not be allowed, or in practice
could not be deployed in certain jurisdictions or corporate structures. Automatic update
solutions should allow for disabling any such updates to support these restricted deployments.
</t>
       <section title="Contractual obligations">
<t>
Some DNS deployments have contractual restrictions that prevents certain parties
from directly communicating with each other. For example, some TLDs using the RRR model
do not allow the Registry to talk to Registrants directly.
</t>
       </section>
       <section title="Company policy">
<t>
Corporations often separate duties to different individuals or
departments, sometimes across different jurisdictions . For example, a DNS
officer in one country might not have the authorization of the company
to update a DNS zone run by a subsidiary in other country. However, the
reverse policy could also be true, where a DNS officer in one country
running the parent zone must be able to update any child zone record of
a subsidiary in another country.
</t>
       </section>
       <section title="Separation of roles">
<t>
A Registrant (or "owner") of a zone might use a subcontractor to run
the infrastructure of its zone. It might not be appropriate for the
subcontractor to make any changes in the infrastructure of the zone,
despite being in possession of required private keys to send changes to
the parent. Similarly, a DNS administrator might be using a DNSSEC
signing service, but would not want to allow this signing service to
make any changes to the zone content other then signing the zone.
</t>
       </section>
       </section>

       <section title="Content criteria">
<t>
[ Note: With NS records, are there any cases where the NS and glue records in the
  parent zone should not be identical to those in the child zone?  What if
  the child name servers report different NS RRsets?]
</t>

<t>
When a DNS update is requested by the child zone, the parent zone could
check and see if such an update would cause (significant?) harm to the
child zone, and potentially refuse such an update.
</t>

   <section title="DS update changing a secure zone to become insecure">
   <t>
If a DS record deletion request would cause the last DS record in the
parent for that zone to be deleted, DNSSEC validation for the child zone
would change from secure to insecure. A parent zone might wish to refuse
such an update or require an additional confirmation.
   </t>
   </section>

   <section title="DS update changing a zone to become bogus">
   <t>
The parent zone has two DS records for a child zone. Only one of these
matches a DNSKEY record in the child zone. If a DS record deletion
request would cause the valid DS record in the parent zone to be deleted,
DNSSEC validation for the child zone would change from secure to bogus.
Similarly, if a child zone is is currently not signed, and the parent
zone receives a DS record addition request, DNSSEC validation for the
child zone would switch from insecure to bogus. A parent zone might wish
to refuse such an update or require an additional confirmation.
   </t>
   </section>

   <section title="DS update changing a zone to become secure">
   <t>
If a child zone becomes signed and automatically sends a DS addition
request to the parent zone, the child zone would change from insecure to
secure. This requires a sustained commitment by the child to maintain its
DNSSEC status by regularly resigning its RRSIG records. The operators
of the child zone might not be ready for such commitment, resulting in
the zone becoming bogus at a later state. A parent zone might wish
to refuse such an update or require an additional confirmation.
   </t>
   </section>

   <section title="NS update causing an outage">
   <t>
If a child zone sends an NS update to the parent, the parent zone could
check if the new NS records are properly configured to serve the child
zone, guaranteeing that no service interruption would be caused by
this update.  A parent zone might wish to ignore such an update without
an explicit override flag. This might be especially important to DNS
operators that are unaware of these new DNS update mechanism and believe
that changing zone content on the child would never cause any impacts
to the parents.
   </t>
   </section>
   </section>

    </section>


    <section title="Security Considerations" anchor="security">
	<t>
[Note: This currently overlaps with the section above]
	</t>

	<t>
An update of a DS record could change the authentication state of the parent-child
relationship and should be handled with care. [ Note: or require out-of-band signaling?]
	</t>
	
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This Internet Draft includes no request to IANA.</t>
    </section>

      <section title="Acknowledgements" anchor="acknowledgements">
      <t>[ Note: none yet ] </t>
      </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
</references>

<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml"?>
</references>

  </back>
</rfc>
