draft-johani-dnsop-delegation-mgmt-via-ddns-01.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 2.6.10) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-johani-dnsop-delegation-mgmt-via-ddns-01" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="DDNS Updates of Delegation Information">Automating DNS Delegation Management via DDNS</title>

    <author initials="J." surname="Stenstam" fullname="Johan Stenstam">
      <organization>The Swedish Internet Foundation</organization>
      <address>
        <postal>
          <country>Sweden</country>
        </postal>
        <email>johan.stenstam@internetstiftelsen.se</email>
      </address>
    </author>

    <date />

    <area>Internet</area>
    <workgroup>DNSOP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Delegation information (i.e. the NS RRset, possible glue, possible DS
records) should always be kept in sync between child zone and parent
zone. However, in practice that is not always the case.</t>

<t>When the delegation information is not in sync the child zone is
usually working fine, but without the amount of redundancy that the
zone owner likely expects to have. Hence, should any further problems
ensue it could have catastropic consequences.</t>

<t>The DNS name space has lived with this problem for decades and it
never goes away. Or, rather, it will never go away until a fully
automated mechanism for how to keep the information in sync
automatically is deployed.</t>

<t>This document proposes such a mechanism.</t>

<t>TO BE REMOVED: This document is being collaborated on in Github at:
<eref target="https://github.com/johanix/draft-johani-dnsop-delegation-mgmt-via-ddns">https://github.com/johanix/draft-johani-dnsop-delegation-mgmt-via-ddns</eref>.
The most recent working version of the document, open issues, etc, should all be
available there.  The author (gratefully) accept pull requests.</t>



    </abstract>



  </front>

  <middle>


<section anchor="introduction"><name>Introduction</name>

<t>For DNSSEC signed child zones with TLD registries as parents there is 
an emerging trend towards running so-called "CDS scanners" and "CSYNC 
scanners" by the parent.</t>

<t>These scanners detect publication of CDS records (the child signalling
a desire for an update to the DS RRset in the parent) and/or a CSYNC
record (the child signalling a desire for an update to the NS RRset
or, possibly, in-bailiwick glue in the parent.</t>

<t>The scanners have a number of drawbacks, including being inefficient
and slow. They are only applicable to DNSSEC-signed child zones and
they add significant complexity to the parent operations. But given
that, they do work.</t>

<t>Generalized DNS Notifications (see
draft-ietf-dnsop-generalized-notify-00) propose a method to
alleviate the inefficiency and slowness of scanners. But the DNSSEC
requirement and the complexity remain.</t>

<t>This document proposes an alternative mechanism to automate the
updating of delegation information in the parent zone for a child
zone based on DNS Dynamic Updates secured with SIG(0) signatures.</t>

<t>This alternative mechanism shares the property of being efficient
and provide rapid convergence (similar to generalized notifications in
conjuction with scanners). Furthermore, it has the advantages of not
requiring any scanners in the parent at all and also not being
dependent on the child (and parent) being DNSSEC-signed.</t>

<t>Knowledge of DNS NOTIFY <xref target="RFC1996"/> and DNS Dynamic Updates
<xref target="RFC2136"/> and <xref target="RFC3007"/> is assumed. DNS SIG(0) transaction
signatures are documented in <xref target="RFC2931"/>. In addition this
Internet-Draft borrows heavily from the thoughts and problem statement
from the Internet-Draft on Generalized DNS Notifications (work in progress).</t>

<section anchor="requirements-notation"><name>Requirements Notation</name>

<t>The key words "<strong>MUST</strong>", "<strong>MUST NOT</strong>", "<strong>REQUIRED</strong>", "<strong>SHALL</strong>",
"<strong>SHALL NOT</strong>", "<strong>SHOULD</strong>", "<strong>SHOULD NOT</strong>", "<strong>RECOMMENDED</strong>",
"<strong>NOT RECOMMENDED</strong>", "<strong>MAY</strong>", and "<strong>OPTIONAL</strong>" in this document
are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>

</section>
</section>
<section anchor="is-there-a-use-case"><name>Is there a Use Case?</name>

<t>Because of the drawbacks of CDS and CSYNC scanners they are unlikely
to be able to fully automate the maintenance of delegation information
in all parent zones. The primary reasons are the hard requirement on
DNSSEC in the child zones and the complexity cost of operating the
scanner infrastructure. In practice, scanners are likely mostly
realistic for parent zones that are operated by well-resourced
registries.</t>

<t>All the parts of the DNS name space where the parent is smaller and
more resource constrained would be able to automate the delegation
management via this mechanism without the requirement of operating
scanners. Also all parts of the name space where there are child zones
that are not DNSSEC-signed would be able to use this.</t>

<t>Obviously, also well-resourced parent zones with DNSSEC-signed child
zones would be able to use this DNS UPDATE-based mechanism, but in those
cases scanners plus generalized notifications would also work.</t>

</section>
<section anchor="dns-notify-versus-dns-update"><name>DNS NOTIFY versus DNS UPDATE</name>

<t>DNS NOTIFY and DNS UPDATE messages share several properties
and are used to address similar issues.</t>

<section anchor="similarities-between-notify-and-update"><name>Similarities between NOTIFY and UPDATE</name>

<t>Both NOTIFY and UPDATE are "push" rather than "pull" messages and
therefore very efficient.</t>

<t>Both NOTIFY and UPDATE are messages, in DNS packet format. They are
used by one party (the sender) to inform another party (the recipient)
that some piece of DNS information has changed and that as a
consequence of this change the recipient of the message may want to
also make a change to its DNS data.</t>

<t>A NOTIFY (as per <xref target="RFC1996"/>) is only a hint and the recipient may
ignore it. But if the recipient does listen to the NOTIFY it should
make its own lookups to verify what has changed and whether that
should trigger any changes in the DNS data provided by the recipient.</t>

</section>
<section anchor="generalized-notify-vs-original-notify"><name>Generalized NOTIFY vs original NOTIFY</name>

<t>This is a proposed extension to the use of <xref target="RFC1996"/> NOTIFY. The
extension covers using NOTIFY(CSYNC) to signal the publication of a CSYNC
record in the child zone (prompting the parent zone to look it up and
make a decison on whether to update the delegation information for the
child zone based upon what is found. Another type is NOTIFY(CDS) which
does the same, except it is used to prompt the parent to decide
whether to update the child DS RRset (or not).</t>

<t>A generalized NOTIFY is typically sent across a zone cut (from child
to parent) and the recipient is likely a CSYNC or CDS scanner. In this
case it is essentially a message that says:</t>

<figure><artwork><![CDATA[
"the delegation information for this child has changed; I suggest
that you go and check it out yourself"
]]></artwork></figure>

</section>
<section anchor="differencies-between-notify-and-update"><name>Differencies between NOTIFY and UPDATE</name>

<t>The difference between the UPDATE and the NOTIFY is that the UPDATE
contains the exact change that should (in the opinion of the sender)
be applied to the recipients DNS data. Furthermore, for secure Dynamic
Updates, the message also contains proof why the update should be
trusted (in the form of a digital signature by a key that the
recipient trusts).</t>

<t>In this document the term "Dynamic Update" or "DNS UPDATE" implies
secure dynamic update. Furthermore this document implies that the
signature algorithms are always based on asymmetric crypto keys, using
the same algorithms as are being used for DNSSEC. I.e. by using the
right algorithm the resulting signatures will be as strong as
DNSSEC-signatures.</t>

<t>DNS UPDATEs can be used to update any information in a zone (subject
to the policy of the recipient). But in the special case where the
data that is updated is the delegation information for a child zone
and it is sent across a zone cut (i.e. the child sends it to the
parent), it acts as a glorified generalized NOTIFY.</t>

<t>The DNS UPDATE in this case is essentially a message that says:</t>

<figure><artwork><![CDATA[
"the delegation information for this child zone has changed; here
is the exact change; here is the proof that the change is
authentic, please verify this signature"
]]></artwork></figure>

</section>
</section>
<section anchor="terminology"><name>Terminology</name>

<dl>
  <dt>SIG(0)</dt>
  <dd>
    <t>An assymmetric signing algorithm that allows the recipient to only
need to know the public key to verify a signature created by the
senders private key.</t>
  </dd>
</dl>

</section>
<section anchor="updating-delegation-information-via-dns-updates"><name>Updating Delegation Information via DNS UPDATEs.</name>

<t>This is not a new idea. There is lots of prior art and prior
documents, including the expired draft-andrews-dnsop-update-parent-zones-04.</t>

<t>The functionality to update delegation information in the parent zone
via DNS UPDATE has been available for years in a least one DNS
implementation (BIND9). However, while DNS UPDATE is used extensively
inside organisations it has not seen much use across organisational
boundaries. And zone cuts, almost by definition, usually cuts across
such boundaries.</t>

<t>When sending a DNS UPDATE it is necessary to know where to send
it. Inside an organisation this information is usually readily
available. But outside the organisation it is not. And even if the
sender would know where to send the update, it is not at all clear
that the destination is reachable to the sender (the parent primary is
likely to be protected by firewalls and other measures).</t>

<t>This constitutes a problem for using DNS UPDATES across zone cuts.</t>

<t>Another concern is that traditionally DNS UPDATEs are sent to a
primary nameserver, and if the update signture verifies the update is
automatically applied to the DNS zone. This is often not an acceptable
mechanism. The recipient may, for good reason, require additional
policy checks and likely an audit trail. Finally, the change should in
many cases not be applied to the running zone but rather to some sort
of provisioning system or a database.</t>

<t>This creates another problem for using DNS UPDATEs for managing
delegation information.</t>

<t>Both problems are addressed by the proposed mechanism for locating the
recipient of a generalized NOTIFY.</t>

</section>
<section anchor="locating-the-target-for-a-generalized-notify-andor-dns-update"><name>Locating the Target for a generalized NOTIFY and/or DNS UPDATE.</name>

<t>The generalized notifications I-D proposes a new RR type, tentatively
with the mnemonic DSYNC that has the following format:</t>

<figure><artwork><![CDATA[
{parent zone}   IN  DSYNC  {RRtype} {scheme} {port} {target}
]]></artwork></figure>

<t>where {parent zone} is the domain name of the parent zone and
{target} is the domain name of the recipient of the NOTIFY. {RRtype}
is typically "CDS" or "CSYNC" in the case where delegation
information should be updated (there are also other uses of
generalized notifications). Finally, {scheme} is a number to indicate
the type of notification mechanism to use. Scheme=1 is defined as
"send a generalized NOTIFY to {target} on port {port}".</t>

<t>This document proposes the definition of a new {scheme} for the same
record that is used for generalized NOTIFY. Scheme=2 is here defined
as "send a DNS UPDATE".</t>

<t>Example for a parent zone that announce support for DNS UPDATE as a
mechanism for delegation synchronization:</t>

<figure><artwork><![CDATA[
parent.  IN DSYNC ANY 2 5302 ddns-receiver.parent.
]]></artwork></figure>

<t>This record is looked up, typically by the child primary nameserver,
at the time that the delegation information for the child zone changes
in some way that would prompt an update in the parent zone. The
interpretation is:</t>

<t><spanx style="verb">Send a DNS UPDATE to ddns-receiver.parent. on port 5302</spanx></t>

<t>Apart from defining a new scheme to specify the mechanism "UPDATE"
(rather than "NOTIFY") this document does not say anything about what
Qname to look up or what RR type. The UPDATE mechanism should use
exactly the same method oof locating the target of the UPDATE as is
used for generalized NOTIFY.</t>

<t>This lookup addresses the first issue with using DNS UPDATE across
organizational boundaries.</t>

</section>
<section anchor="limitation-of-scope-for-the-proposed-mechanism"><name>Limitation of Scope for the Proposed Mechanism</name>

<t>DNS UPDATE is in wide use all over the world, for all sorts of 
purposes. It is not in wide use (if used at all) across organizational 
boundaries. This document only address the specific case of a child 
zone that makes a change in its DNS information that will require an 
update of the corresponding information in the parent zone. This 
includes:</t>

<t><list style="symbols">
  <t>changes to the NS RRset</t>
  <t>changes to glue (if any)</t>
  <t>changes to the DS RRset (if any)</t>
</list></t>

<t>Only for those specific cases is the descibed mechanism proposed.</t>

</section>
<section anchor="the-dns-update-receiver"><name>The DNS UPDATE Receiver</name>

<t>While the simplest design is to send the DNS UPDATEs to the primary
name server of the parent it will in most cases be more interesting to
send them to a separate UPDATE Receiver.</t>

<section anchor="processing-the-update-in-the-dns-update-receiver"><name>Processing the UPDATE in the DNS UPDATE Receiver</name>

<t>The receiver of the DNS UPDATE messages should implement a suitably 
strict policy for what updates are accepted (typically only allowing 
updates to the NS RRset, glue and DS RRset).</t>

<t>Furthermore, it is strongly recommended that the policy is further
tightened by only allowing updates to the delegation information of a
child zone with the exact same name as the name of the SIG(0) key the
signed the UPDATE request. I.e. an UPDATE request for the delegation
information for the zone <spanx style="verb">child.parent.</spanx> should only be processed if
it is signed by a SIG(0) key with the name <spanx style="verb">child.parent.</spanx> and the
signature verifies correctly.</t>

<t>Once the UPDATE has been verified to be correctly signed by a known
key with the correct name and also adhere to the update policy it
should be subjected to the same set of correctness tests as CDS/CSYNC
scanner would have performed. If these requirements are also fulfilled
the change may be applied to the parent zone in whatever manner the
parent zone is maintained (as a text file, data in a database, via and
API, etc).</t>

</section>
</section>
<section anchor="interpretation-of-the-response-to-the-dns-update"><name>Interpretation of the response to the DNS UPDATE.</name>

<t>All DNS transactions are designed as a pair of messages and this is
true also for DNS UPDATE. The interpretation of the different
responses to DNS UPDATE are fully documented in <xref target="RFC2136"/>, section
2.2.</t>

<section anchor="rcode-noerror"><name>RCODE NOERROR</name>

<t>A response with rcode=0 ("NOERROR") should be interpreted as a
confirmation that the DNS UPDATE has been received and
accepted. I.e. the change to the parent DNS data should be expected to
be published in the parent zone at some future time.</t>

</section>
<section anchor="rcode-refused"><name>RCODE REFUSED</name>

<t>A response with rcode=5 ("REFUSED") should be interpreted as a
permanent signal that DNS UPDATEs are not supported by the
receiver. This would indicate a parent misconfiguration, as the UPDATE
should not be sent unless the parent has announced support for DNS
UPDATE via publication of an appropriate target location record.</t>

</section>
<section anchor="rcode-badkey"><name>RCODE BADKEY</name>

<t>A response with rcode=17 ("BADKEY") should be interpreted as a
definitive statement that the DNS UPDATE Receiver does not have access
to the public SIG(0) key needed for signature verification. In this
case the child should fall back to bootstrap of the SIG(0) public key
into the DNS UPDATE Receiver, see below.</t>

</section>
<section anchor="no-response-to-a-dns-update"><name>No response to a DNS UPDATE</name>

<t>The case of no response is more complex, as it is not possible to know
whether the DNS UPDATE actually reached the reciever (or was lost in
transit) or the response was not sent (or lost in transit).</t>

<t>For this reason it is suggested that a lack of response is left as
implementation dependent. That way the implementation has sufficient
freedom do chose a sensible approach. Eg. if the sender of the DNS
UPDATE (like the primary nameserver of the child zone) only serves a
single child, then resending the DNS UPDATE once or twice may be ok
(to ensure that the lack of response is not due to packets being lost
in transit). On the other hand, if the sender serves a large number of
child zones below the same parent zone, then it may already know that
the receiver for the DNS UPDATEs is not responding for any of the
child zones, and then resending the update immediately is likely
pointless.</t>

</section>
</section>
<section anchor="management-of-sig0-public-keys"><name>Management of SIG(0) Public Keys</name>

<t>Only the child should have access to the SIG(0) private key. The
corresponding SIG(0) public key can be published in DNS, but it
doesn't have have to be. The SIG(0) public key only needs to be
available to the parent DNS UPDATE Receiver. Keeping all the public
SIG(0) keys for different child zones in some sort of database is
perfectly fine.</t>

<section anchor="bootstrapping-the-sig0-public-key-into-the-dns-update-receiver"><name>Bootstrapping the SIG(0) Public Key Into the DNS UPDATE Receiver</name>

<t>Bootstrap is simpler if the child zone is signed. Therefore the signed
and unsigned cases are described separately.</t>

<section anchor="child-zone-is-dnssec-signed"><name>Child zone is DNSSEC-signed</name>

<t>If the child zone is DNSSEC-signed, then the preferred mechanism is to
publish the public SIG(0) key as a KEY record at the child apex. This
can then be looked up and validated by the DNS UPDATE Receiver.</t>

<figure><artwork><![CDATA[
child.parent. IN KEY ...
child.parent. IN RRSIG KEY ...
]]></artwork></figure>

<t>However, the receiver should have access to the key at the time of
receiving the update, it should not have to do DNS lookups and DNSSEC
validation in response to a DNS UPDATE message (that might open up for
various types of attacks). Therefore the proposal is to trigger the
parent reciver to lookup and validate the key by issuing a DNS UPDATE
that only contains an addition (no delete) of the KEY record from the
child zone:</t>

<figure><artwork><![CDATA[
ADD child.parent. {ttl} IN KEY ...
]]></artwork></figure>

<t>When receiving such a message the reciever SHOULD put that key into a
queue for later look up of the corresponding KEY record and validation
of the DNSSEC-signature. In case of validation failure (or absence of
a DNSSEC signature) the SIG(0) SHOULD NOT be added to the set of keys
that the receiver knows and trust. If the validation succeeds the key
should be added to the set of keys stored locally at the receiver.</t>

</section>
<section anchor="child-zone-is-unsigned"><name>Child zone is unsigned</name>

<t>In the absence of a DNSSEC-based validation path some alternative
mechanism will have ot be found. The primary audience for this DNS
UPDATE based synchronization mechanism is "non-registries". In those
cases there is by definition some mechanism in place to communicate
information from the child to the parent, be it email, a web form,
pieces of paper or something else. The same mechanism can be extended
to also be used to communicate the initial SIG(0) public key from the
child to the parent.</t>

<t>Should a "registry" parent want to support this mechanism (as a
service to its unsigned children) then the interface is usually EPP
<xref target="RFC5730"/> and would require the implementation of a new EPP
extension, which is clearly doable.</t>

</section>
</section>
<section anchor="rolling-the-sig0-key"><name>Rolling the SIG(0) Key</name>

<t>Once the parent DNS UPDATE Receiver has the key, the child can update 
it via a DNS UPDATE just like updating the NS RRset, the DS RRset or 
the glue in the parent zone (assuming a suitable DNS UPDATE policy in 
the parent). I.e. only the initial bootstrapping of the key is an
issue.</t>

<t>Note, however, that the alternative of re-bootstrapping (by whatever
bootstrapping mechanism was used) in case of a key compromise may be a
better alternative to the parent supporting key rollover for child
SIG(0) keys. The decision of whether to allow key rollover via DNS
UPDATE is left as parent-side policy.</t>

</section>
</section>
<section anchor="security-considerations"><name>Security Considerations.</name>

<t>Any fully automatic mechanism to update the contents of a DNS zone
opens up a potential vulnerability should the mechanism not be
implemented correctly.</t>

<t>In this case the definition of "correct" is a question for the
receiver of the DNS UPDATE. The receiver should validate the
authenticity of the DNS UPDATE and then do the same checks and
verifications as a CDS or CSYNC scanner does. The difference from the
scanner is only in the validation: single SIG(0) signature by a key
that the receiver trusts vs DNSSEC signature that chains back to a
DNSSEC trust anchor that a scanner trusts.</t>

</section>
<section anchor="iana-considerations"><name>IANA Considerations.</name>

<t>None.</t>

<t><vspace blankLines='999' /></t>

</section>
<section anchor="acknowledgements"><name>Acknowledgements.</name>

<t><list style="symbols">
  <t>Peter Thomassen and I together came up with the location mechanism
for the generalized notifications, which this draft relies upon.</t>
  <t>Mark Andrews provided the initial inspiration for writing some code
to experiment with the combination of the location mechanism from
the generalised notifications with DNS UPDATEs across zone cuts.</t>
</list></t>

</section>


  </middle>

  <back>


    <references title='Normative References'>



<reference anchor='RFC1996' target='https://www.rfc-editor.org/info/rfc1996'>
  <front>
    <title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
    <author fullname='P. Vixie' initials='P.' surname='Vixie'/>
    <date month='August' year='1996'/>
    <abstract>
      <t>This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='1996'/>
  <seriesInfo name='DOI' value='10.17487/RFC1996'/>
</reference>

<reference anchor='RFC2136' target='https://www.rfc-editor.org/info/rfc2136'>
  <front>
    <title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
    <author fullname='P. Vixie' initials='P.' role='editor' surname='Vixie'/>
    <author fullname='S. Thomson' initials='S.' surname='Thomson'/>
    <author fullname='Y. Rekhter' initials='Y.' surname='Rekhter'/>
    <author fullname='J. Bound' initials='J.' surname='Bound'/>
    <date month='April' year='1997'/>
    <abstract>
      <t>Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='2136'/>
  <seriesInfo name='DOI' value='10.17487/RFC2136'/>
</reference>

<reference anchor='RFC3007' target='https://www.rfc-editor.org/info/rfc3007'>
  <front>
    <title>Secure Domain Name System (DNS) Dynamic Update</title>
    <author fullname='B. Wellington' initials='B.' surname='Wellington'/>
    <date month='November' year='2000'/>
    <abstract>
      <t>This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='3007'/>
  <seriesInfo name='DOI' value='10.17487/RFC3007'/>
</reference>

<reference anchor='RFC2931' target='https://www.rfc-editor.org/info/rfc2931'>
  <front>
    <title>DNS Request and Transaction Signatures ( SIG(0)s )</title>
    <author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'/>
    <date month='September' year='2000'/>
    <abstract>
      <t>This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='2931'/>
  <seriesInfo name='DOI' value='10.17487/RFC2931'/>
</reference>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
    <date month='March' year='1997'/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='14'/>
  <seriesInfo name='RFC' value='2119'/>
  <seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname='B. Leiba' initials='B.' surname='Leiba'/>
    <date month='May' year='2017'/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='14'/>
  <seriesInfo name='RFC' value='8174'/>
  <seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference anchor='RFC5730' target='https://www.rfc-editor.org/info/rfc5730'>
  <front>
    <title>Extensible Provisioning Protocol (EPP)</title>
    <author fullname='S. Hollenbeck' initials='S.' surname='Hollenbeck'/>
    <date month='August' year='2009'/>
    <abstract>
      <t>This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='STD' value='69'/>
  <seriesInfo name='RFC' value='5730'/>
  <seriesInfo name='DOI' value='10.17487/RFC5730'/>
</reference>




    </references>



<section anchor="change-history-to-be-removed-before-publication"><name>Change History (to be removed before publication)</name>

<t><list style="symbols">
  <t>draft-johani-dnsop-delegation-mgmt-via-ddns-01</t>
</list></t>

<ul empty="true"><li>
  <t>Expand the description of how to interpret different RCODE responses
to the UPDATE. Expand the description of bootstrapping
alternatives. Change the mnemonic of the RR type used from "NOTIFY"
to "DSYNC" in the examples.</t>
</li></ul>

<t><list style="symbols">
  <t>draft-johani-dnsop-delegation-mgmt-via-ddns-00</t>
</list></t>

<ul empty="true"><li>
  <t>Initial public draft.</t>
</li></ul>

</section>


  </back>

<!-- ##markdown-source:
H4sIALhOSmUAA7VcbZPbRnL+Pr9iQn/IUkXSkuyL401dktXu2t6zpdXtSrly
XV3FIDAk4QUBHAZYiqfSf08/3fMGkivHVYk/3C1JYF56up9++mU0n89VX/aV
OdeTi6Fvtllf1mt99eZeX5nKrOljU+vXWZ2tzdbUvX4sM31FP09Utlx25vGc
P+n3bZH1xupmlb53U6+abst/q6LJ62xL8xRdturnvzabrC7nRW2bdl6EV+bb
9baf0yTzgn6aP3+hMO65/nh18e76k8rpw7rp9ufa9oVSZdud674bbP/y+fNv
n79UWWeyc5q2N11terVruod11wztOXZ0+1b/hb7A/r7Hl+rB7OmJIr4wv8La
lLJ9Vhf/nVVNTVPvjVVtea7/2jf5TNum6zuzsvTXfos//qZUNvSbpjtXeq40
/VfW9lz/aaHve1PTSFv+Uvb+J+x6/EPTrUkQ/+Ddn+t3G6Pvd6Yo7SasSn/X
DHUhUsQbOX3sIQM8aOQ7s83K6lyzVBfWjf+fpRvB9uWqN5U19JtRqpZDeTTn
JEJ/RPxpPp/rbGn7LstJDMlJlvEk9Vm5MAvd00rp4O/urOlnum2sLZeV0etq
MMnHq3vVmZyEbKfabpqhKnRW7bK91UujH0zb08gkyTqnz/3OmFrnm5Ie+geJ
XtMh6JaOtO4VPi/0D83OPJpuhpdarLHMDS0ko1Gsrpvej4215Zk1C6X+sqEx
8bk4vRn3ol8FvxlXUFo12CGrqr3eOdVZlTVtcDn0elfSsdP/451si0OB+nem
wGnV+V5WRr/y6nWzq02nq/LB0GjmQ2vynlba6E32iK2ZOqdxvYzqvV4NHb3b
0UYbkuTWKjrUgZbUQwHoGbxHu+wzOq6mLXP6urbm7wMGsrRzqBJME5qnbZuR
qDaZpQU8moLXTkuj3bvhNYmEZJRnBVkxBF/2qoaw9brBNyTXhb4l0XcZVjXD
OnZlVWn/ED+iSQhlpTNaPMkMhgFEofm2Joe9W5ln0+yw8wdjWpbe6EDkJPy7
Zc7Sp4UWpq2avSl4a/jc5ANDEu2A9I0WaYd8Q3OHufDkrX51re+uX9/+1/UV
zCt9sYQW4kzzpqqyZdPxUmUN35OAhqXO+nP1103ft/b8yy/X/N0ib7ZfCnx9
+PJ3gNnfzv5vxpku+Gi3je1J2XJsxOsmnYSFDEkNWeXdRme6aQ1UnfSHgMv0
eVQ0OsGlUdkjwUcGg8XhkjoyEAmu6bM1BMMnOtVZnsNqW/pEs5O22R7KBuDY
lkVREbx8AeTqmmLIGbLUdzQGKeL99aW25bomEUcLs6KJ7366otHWJalyCW2z
zu6trAcnpQg4yQV1a2yUIJhUtG92GSGL7oa6xre2mUNbaILJ5dW9tnlWk8nZ
Cevz5PL+5zeXWsVvl3uWksy00Gwx1oTXSOF6slHa6rIiLeydYDGygzR9FuEC
O6O5aRkqozdtSauGqtOqB/aNUHg8fuUwE0oWp59ijV/iec3rdKh5egb9+Rk8
KqumC0i8B2bOl3TK5a7MHximxytwiBF2z/CS6XrYLsm+aeOkortllj9YDJVX
Q4GViP0QJK5WZV4CqSFrWzW7BVRor2lssiiy4KxtIUbWscbpw/yEPtD7quc3
C9lzSSNnNVBv21bmQ9nv/UZl4VDujo/HLvQrwuM1IVytAL4zzSMVDVsI7fB7
Q3vLqvIfNCmw8U3T8/D8tj6zxiixxNL0K2eH6/jOvMbz+/nz51OPOow3ZCbQ
RgXlIzPtjUM1LxXyBV4stEVmSV7OsuResJpEomBUdLQMUHiJFSBuvYOnr5/G
QNKGrILXZ5ee4C7JzMMx+yTWGRwejvYJ35jqhzhEVjg5L/FqS3KzjJlMGffk
bMgTeTZoTT503tvc33x/RnJjNe7paysmR7s4vWC7oXnFl2N3pqPd01pF48b6
Rr8/loUh39SWBfwgAeEafpCOtNwSsnXYfnKQuh4dfFkreulXASxZrT+f6UJ/
J45423SG3R68KPv84pH0kogxHyiN6M6OLZQceDClsRyznlEX684q2zD94E0p
8nAEa6zSdcJEziIPmrrtj8yHlOHHutkR7q0NE3Ao9u27m+9+1h8//tPdd5cv
vv32Xz594hlPnJKSh16++Mo/JF989fz5N/QFzoccx5bm4bfdMRJFrG0mCB+P
lM3dKyWJmXbuRv/2qxefPi3IM8CuS5Yz6IcaU29NTrhrdoQ+JnssCTVWXbNl
UYBqrTe9cBPPWYjk9mwpKjx3MB5N8xs2D2QQPtmsaQdwr+qLL/RdNEOLV4R+
M0RS2AA8IfyfPHv2+v39u2fPJjP/NyTvP99d//n9zd31lf98/8PFTz/hg/If
0qfvf7h9/9PV+NN4tMvb16+v31zJgBiDftUHX/M6Ln7mP9ntPXt2+/bdze2b
C8wsqpgAByIm2MYScEWSazuDc8vg/WzelUs5xFeXb/WLr/1ZvnjxLSmGfPjX
F998/emT2hHNlgkZ7OWjwHjbGrK/smatz8lCe1L7GaYgDrKrNRMOZg3e22f6
PQHrJSHLfyj1ijjpYE3gNN4LeV+MOcW1B3vrveMZaqHbSnbonQ9TmREaaoAq
RU0ZMONJQFRuEwkgWnZzpDzlNuuAzpmFVrFUNyDc5MNTRKdBHBUqUxMPru8Q
7nOwPFqQ83GgPoTdbqdYWwf6T8A1gLXdxLBoFsWBxbiwA6SRxEHLrIhrEQYA
z9PtSMzCTptnpOMnmrQzVTUn42iGLjeFikyNzu2CBOLQrbf+lA7ijh0fa4KB
pIF2C2/Zsb8HtGo/PscxBC8lmMGOWWpydqNTi8ektuMUBSt59CVpqDY6jkSy
KrrkC+CyO+m4qVMbgrZ2o1NUQYIA9jHPOdoNFBtLJTneLh/LZrBgauwWxjIf
HxJ7qBMUSrmfn5qGz+X9W+RS5uK4g4gkpGWlJB6hED3bqEJtNdjP+M+diyVs
IFpfpF4IYcmQTq5U8qt3S/ITrcha9qns/4lCPGJSTwFI59jjs3VjA1CJogBw
a+/qJc4BuyAcv5cvS7wZcgzJzH5BrxoS6dH3PM+kHexm4gJfGEiNr6pqEtfq
SGtnVtBkWvE+MhQs5DOj+zE4qQE5kII9UHggqBNZtOLtkjGCdUEv9xIcWFCG
bgpBCFTRBI0kDuJDFE2ULRYzFfW0DakyfZEHwpDyPhAcqMUanoAxCRpNu1RJ
ikGsovRP6tE03mTc5gheCURA4pkkk5psswfDRFLepbX3oiBESTKgipfWGWJB
2kzKZKbADwkq9KZMeHKcnyZUZBg4jbIXjl2uDp4pkNgADiJD5EInmZRInsTH
iteJtcFTVU3zMLSctKEjpkCAcCDrj8RF4OA1pVcuzia0XK8Z7fbu2UAL/a49
iy18YBpWKowk5THesGhdNHBJcaH7yjFqkDYfExTafEBCkCmXbNP50xE7lPdZ
31R8IW9gvPQCXI88csbelhVOQlIB9nGUfBDGHjk7fUar27beo41iDBoYksYp
DK34B9GWggRiMX4dZdyE4PfpHB+cHNxmMr2g39DyUJI/XCHLStjvrKfft5x3
8Ju+up/So2W+Uaw3bHrkEGYkXc6IlDyIxyTZXbo1+hLrL4w6vXZZXMgOnNGa
aSVTtoX18dHTXLRClx2zHFfkHcX6JCbeYE4af8asWDwD1hQzDQeWUFpPENy5
kVrpJIXCzILpOvyC2yqZNr1b8gKyYOkCL9nenitOTE9+81wYQkpOaAY7+jd9
o+1AFmN7HoVH3TcD5xlreDuTs4LAqdP3nTXVasJmclWuVgTEdf4bgA/aVvhn
TXgSy/Xo7OSUSNwldP0gBIc98RTRBvOBmFdEw8xjiD5z2t+0ZZ1k5xxwK/hp
5EZEcUYHk0DiOAqF5CS49tGcctHcbIS7jLVhlaSUNPduI/DidM8tcmkUF1JM
XC87E7blgjCGWHuM3QFRGQdCIccdtYnH4Tjq5iDakEiONqEn4yB0AoWbRBZA
gcoWIrHK7bJwj8uiR9I4mMK9GBcWF51Va4LLfrMVTuwLET6Dkdn9dmsIqXOd
d/uWE9R7EiiDn/IGPxpFBpKYnE1/FXKdZDMok5CgBDxZRiWFsHEAd9h2qBgH
kzCaM+tQDGI1fdcgoWBVQvhcAkV4lIiMbIeIyTLSIne+8DgHSR0HEWd2WP5q
8l75dFpDCL736hkpg3OfohS2pe+zissrkQYrdmC+EiMzF2Ixn7X+LHEJSqoO
HBs8gWeh8OQyomRBFq/IBpQDOE7SZKiu4Hz0uiJpr2BexzCalEmc0fsAWYDu
/wHleDcjqIMQpXB4DCTyq/9FDDigkMMagmW8jWw9lprPiK4bLN+RFJ48aA1Q
Ur8j0ynrpmrWe6Uko6POyfUh1ROMgJOvUL1EXyV5hQzN2IPQCYCQ0UJqI+r3
UKPIE5iBgEUgTlmCJTmFo32gPTSEICPwqnyECtOrHFK89ynL0yVmqU1Hg1hE
MsS1QVraTpMDzpjkiFSrRuI7mgrq2PUuv0SflIeUUcJbDqgtkdaUVDG90Jmd
ddli0f25qOKc47H586+dnq2GmjNmpIOSxXY2+r/Ov6rxFlmPlnBbsYADddub
TNKOmYYm9Bwz0GsK4MiRr6vkvrp5c/XtNCmsEsOpxvbgOI2jhI/IppAvQbZV
KtfW51CFCEPSFivaohgHounsOH06q9SSa9qcQyC9K4KRIzNUcW2L1KEwK3KZ
eAMoLHVYPOPGVFzwS0Zy5V7oj5RJ0o1IkZhCHjLhbh9U1GFYw28pBAs3sj1C
03TNYkYHpWO/KNLgokTB0x+DYCaxEx6KvX86Vukr1rJ5kn3t4hMlyu9C6uMV
Jq57FofxSeWcjrtTASAK4k9lHVZLqyTIcDmBSEEkRHRa5jNZBCqOEkrujKAH
1TAx0xWp/47mk5SV8OUtKRqc0tSbHadxyn5AISAblZnFIcazufc6EpQArNfx
cBomN10d6VeXSf6YBZ/6P0kXCBhlym8EWRtrOtZu9jCrEfshFGIQYlwqHbF3
P5IMxlXoA56GyaUxweNMs0IwyQdSu1Ip5K1iSZrThaM4VdjcumkKlz6c+RRV
SJWTvTjnzMRXxO4ZO01E0MSCKStiRiVLZpZ6CMfxSk6T7bUkd6TucMQ9XS1V
oiTSYZ/2aCRpgP4XxYBJwSpCRGYueyKOW80OHUxgKb0XogaM7jZmJT6jCJa/
5VSe1ENOweLCpVN8X4RwOckBxeA5BL/jzoOqyWMadZSuyE7Tgy/0T8kr+l3W
rSU5c/IFX8WNW3LI/3Tu7GZ+lVTv2Efd3XH0SUcoSM2g6zo2iNvXZktizylW
RKTW+xSEUHY4Z25TYXE5evIxcSGf6PPNG+3e1h/v7jDXJ/3Rkm5t8UdLR0z/
1/NWPykl+DMew1O7BolzyYw63phG8ojd/TifeeUobeRzEX5xahTtorgvAQPH
qpOQXYiUNEkMp4gdYp1AUc9iDpdjJdHRwXJNTz15atPEzoLgOOni6uWcjSvw
uOHIgbMJUiUMo4yLszTnQt/zUH98If0uK06BE/OfMPKfVDh6M0iYhsTZuROc
PF0kFt/gfatoPxQvbMVlTDjg8TmcwO59nHPCXvwGXuJBdxK8C0UK6neRhHm0
xOsPGUiJM6lRHojZZl2Tf6cA3Q4tb241Mi9JS45tPIENdBJtKH7y/XViDr7j
A3YgZnDx5mf9Uv/hq+cvNfcdoq+GzK5bJL0R7EAlm2U5QcUJpFmimA56hOef
8D/KueW+3BqdOOnPJa3SqMElDlGGYixGwxUPI2TB5ZxiP8gxf5T0Xqj0eWZA
cvnl/vBwOGN1ShhBzyCvX8hTI9EslVpRKqZe0CdRJ/YdCBtXe5ec8Kc1cWqg
zkbJdVGmyfQgsue8G/PLDG5vT79ipiVyQEjiqT8zqPj04dACIzi75wBVnG+o
M8RGAxYf6bXi0KvaB933vR0Iu1LXocXkPF5FXeSGwaftw+mRJJKD03LYXXa2
l+KFFHgOvaNnvWnHKEXiI/5L7qrcln3Iw97nTWuCLr31TvF12HyaQtBMcGny
QlLEYJTI//K7u6arCuEq+B48gCMn1Q4dowoR50BH01HOiHGxTISjTscBQdjG
KCIY45ak+l2VJyQhVsjTZJLJ9nkEFYEDOWMbSwxlHUoMqZWJ+ZSumY05V62V
sx93umTzNHPbSFDx+QDNLV1JwGjsOQn4Wcj4HzRo6fFP3JMFaZFuT/XxazE3
HJ5RtxCNHC+akUaCsTEBY3Ou5Eed9/SIq2T6IAdy5wwe4VQpPYEorhFKk4Ki
82wtdDyJSFIO59NJAoBKyqaMgAccwbeQkhg54pNFL9Hb2Ll+BA5g1igb+amk
k4kGpEFwSAdrdmU/0nQEet5c0+TOya1K95/2UJfWsY/rkkKmfSiNxQwleP5e
K5TF0TMobH3lAWhwDVHMMzgsYO4RPIdouOduyj9+oC8zUREumLqvptjvYYNS
6bOGHJnmzXaLOK+ILsctD0UPeVX1yEya2lcY09UcLOYJdwUjTAssga5KNovB
lDXBMdWU/7mWIkknS8LWFOm5uUZTl1IlCx1/H/DtCdrnf+aF/cKL9L7sF3+c
vGeJc3MJJMqVcrKU9XDKO1lq2CFv5XBYVzxIss8hwmQ8gZtB1b/OTbrTkNBx
Txcu/A7vjFaD9ECtRotxDzpZ+x6zrPA5hCS89VoQipRLsCxOCcd40Ir1sqtz
Y3MLY4/GXxwmkfEvpdbnu1J2sT29NR2OAThzw2dtR/0XNhLv1VCtSvTuqiRu
Rdn4OERNOWIp9TvuQd/K9DET7Hv4pbtHGkrOOCfcmw+kNYRtMym9cqrMR64z
TiQidrl4e8Pt0tOF62pOaVMIXuAarEmTAiH0Q3MMvki65VyPnHHnyMtps5Ih
J+0ncPkmi7KMl9E4smTYLk8uyhe20JIoy7Ou6zZtPZA+qJPtetwMOEONia3p
5eKla4u7vL26JjZzfXd3e4fSZNg+a2CXN4X543N9NnGPTKZJ0HXQYcbtBMR6
Uld8ALrBHBwwc4FdeQR1eJAozFhDQmU9LkHuXbAuofDGuWm7McUJV659n8Rq
YPsFa0+FcHf93fv766unhPAHEoJ75PNCIBshzcWsoZye9UeJLea9EgLFVHlg
5sI6di7LI3FnjKa2pWVJrwfpk555EHZlTLc4lxDiFNpQV55suUFwFD4YKw6j
MeXOC4Zz2AlQw36JbnTSGC3EWch0U7uQKpXrq4urH69/fkqsL74hucojnxer
j28JhUKb6EkdCxQgxBfS+p7DD4TamBQxEvhHncMR/UOMl60dFM2TspUsesV3
L7L8gSG+aXo0vbUHPjEWTxC1HSJMWDssFXVI9N2zKN80I2BK4zphOp4518mD
QEowL9d/yGoSU8zhTpfLnMc+hvGaCOZCUjzfmNhrwCCNvoYdriGB8JW1YmQs
+6l2PjqeeSgm1NIN4d7Q/o2F3CzpJTBH4tRzH2kc8IQn0xWEzFez4kYrs0JP
02FFJLRgw6QQGmQSDB48BmOwQ+hBX3WkDAh/GzpiuRRgUS2BtFj5SRALfb1e
+OyzS7xHlukN6AxZ3ZQ+J/mDEI8EljUV2sI/Q+fBdyv3ACeAYV++GnJwTA33
cJH8drhE5zxt86DO6Hhx06xLUhSnBIizKQbWBulY85epcE4qPSd96/ofWFsI
qGltYzn4DdBEhA7xzolKu2NZuyMnSZDabbXkdDq5SlRj9r4AmfWqT5m9J4Mp
wLrtJFGeXKzxxfB0HTNP7Q5l65MuxLYLQJ3cWnMNyG1D5gtIZSaR3KdFjC6m
/lZM/Uezty6uO4KMBJi8q/M4kZRKOcczDlqP0MQ3C4wcIInEtYH23ORU/7PD
Qv4fJqJCOo6HYz0EJFp5Lr1RduSTj0K2H41ppdKcNpOpiLZSGAisZtQ17bNh
yEhw77ajceBO4J9Cm5GFFGh85aG29Sd3dACgek9iLcoPHqw5OgA0dF6jR5dH
HVl39eZV0/lYes0pUdKjofb9uxz7OmroGu99jMuRwhe09MvR4KMGYKVuTi1g
9IyzE0EXQ6LsRjkBDumV04gnvB7TVfK9PhUaOhEwadaaD0JFFNSLJyMdC7lS
tpzHrCqLpN5/UiMkTzsKqZCsxcSLxeL0j3d3tM7wiAol7ZH1P21IvLskP0vo
I2+N7XsWm0MjV0CmVNi1bxF1Tc240OU27PJFT3nl0FpyJtkr7hTia5skN9Ic
GqZDfzgnMjnxlvU97kFMD7VLUjvEIyVF4ztPk7AIzvhRihQ+E5kcTJDGcs/Z
yMNKupSX2eBDZ1mWXOs5qxsOxHu4J9HJRGH8RZ0EUl1W/uLq6uBQP/Z99Sk9
dynvx2MJF359V05CNNwFmnZwrA87YgqVqb8PZpCkaEX77WK6+FS+L1X2KCUE
RdF7j9qymPd5epUc/ooAEV4VXCZbWtdDrbL0biwPME1BKd4D4ki4KJLQXKJy
wGMs+QdNh/tzgST68XwAnq6IxJcLZMuJJ3mApyYiLt0ANcDfuSI+nvUkTnmM
c/2AJtm99rt31xGSxbUZbuE13HAXrgeq9EoHOQu2PglbXPvuu4Q6oS7OE4UW
rIRpyYQHBaIxGk7qpp7Hyy4Tx+jj/YjetxGNelVk1clItJkKt0Z69GJut0Mt
dcFRisrfXxOzGPnMGcc3vfwbD0Q/9M4sub47U9zCLw1MGbrkEYw0qFnwHcnK
On/tShl+Qc73c0tPYbg3mPMLSfNgsk7hv9gaYcqx5z8w6NHKSR3u3T1zPXGC
3E88FXAXAkIseXBnhzM1CtSwzMMVgegvMRsNM40+jUPAFQSddOZcv33rLjj+
4ZuvnrsLjhIo+4z/CX4fKqJ4PXTDz6QBHMNzow0nT7jbR8LXRm5nJ9YLLpEk
+Z7mQKGCTyKdJYqQx2oespGcmErf/5VMmzmmDvd5xxnjUeGA1IPJ8PHtb9cR
yjc9BfBdTnvkn33GsJZhXL+lS8M0nrJ6XVmOiJZDS4Zh4JLiShdJ7k0Dr7qJ
7tphSnormGOP+XjAs+U+5P7U+KcEJTIpWE+x6FgtYgZMUS7pbmljnlEtTQ+H
kE49pq9OVzEJxujQb+GjCmm0T0irGB/fWnBKlbT+c359PIhr7vMIFaNUN/uc
m8nkEDiOuEdzNFoJLxvuWfPX4NE9tR9fcyRrHbcbJDcPGlx9lGpeFpqaFMiH
ZdZGU/bSBKsfhwpFzWXJHYz+csuoqCtppBhYw1hDxlvHpvCQFRl3IkzcwxPp
p+AEf3qJ4+kSTeitGlG9lNao0CNb9vvjAWJkVyTJ79hypdL0jusuxi0JXJZI
b6ByJskdfrxhEIAy3N50l5icIUbfd65dIH94ZT603Z/w99J1jytBh3xCTIqO
B0zNJ5wyfw+V36Pd5Zum8wkTv0IZU5LfF28ujtXsTcNR1Vz+w3MX+YO/i84Z
/gXqn28NrOrdhhQR7dQs5xtaxVqsIYeYSdFCESNkB4NWEUP0gfuTTTkenqVr
gK9/d4bvAuCeDy/kddY9oOMSDbvxvlUKWiSjtuxi3WiHq4P8b4tAFZoC/cnI
kHwgd1tyBJ+UXrZL323pdOt4I6wGGCPZiT2+UOkueMYU8HGDJP7JFZwmpH4p
6e8fStAz3PljZ96ZbYOc+VKCgyQxO4Uwfuc/xKX+XV9/aP2lGIlSW79Z9y/6
hCxsEqtLVjfUIWgYB6neap8edYTq9GKCy2Rfl/HiYeiJc3J3DR+uVwmG55tK
ZPrJ1ahzzEgPkijr7xLLcw253DjlcbSIRwDU/Q985o8zXk0AAA==

-->

</rfc>