draft-johani-dnsop-delegation-mgmt-via-ddns-02.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-02" 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>I-D.ietf-dnsop-generalized-notify-01 proposes 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="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 I-D.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>Section 3 of I-D.ietf-dnsop-generalized-notify-01 proposes a new RR
type, tentatively with the mnemonic DSYNC that has the following
format:</t>

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

<t>where {target} is the domain name of the recipient of the NOTIFY
message. {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>Apart from defining a new scheme to specify the mechanism "UPDATE"
(rather than the mechanism "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 of 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>

<t>Example 1: a parent zone announces support for DNS UPDATE as a
mechanism for delegation synchronization for all child zones:</t>

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

<t>Example 2: a parent zone announces support different DNS UPDATE
targets on a per-child basis</t>

<figure><artwork><![CDATA[
childA._dsync.parent.  IN DSYNC ANY 2 5302 ddns-receiver.registrar1.
childB._dsync.parent.  IN DSYNC ANY 2 5302 ddns-receiver.registrar3.
childC._dsync.parent.  IN DSYNC ANY 2 5302 ddns-receiver.registrar2.
]]></artwork></figure>

<t>The DSYNC RRset 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. When the {scheme} is "2" (for DNS UPDATE) the interpretation is:</t>

<t><spanx style="verb">Send a DNS UPDATE to {target} on port 5302</spanx></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 most likely model is that
the target of the DNS UPDATE is operated by the registrar (or possibly
that the DNS UPDATE is forwarded to the registrar). The registrar
performs its normal verifications of a change and then transforms the
update into an EPP <xref target="RFC5730"/> transaction to communicate it to the
registry.</t>

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

<t>Once the parent (or registrar) 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 signatures that chain back to a
DNSSEC trust anchor that the validator 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>Update the references to the (updated) I-D for generalized
notifications.</t>
</li></ul>

<ul empty="true"><li>
  <t>Remove duplicated descriptions between the two drafts. It is
sufficient that the generalized notification draft describes the
mechanics.</t>
</li></ul>

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

<ul empty="true"><li>
  <t>Change the RRtype from the original "NOTIFY" to the proposed "DSYNC"</t>
</li></ul>

<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:
H4sIAE2c4GUAA61cbXPjxpH+Pr9ijv5w4pZI70tyPusqudNKsq3YK22k3Uu5
UqkYBIYULBCgMYC4zNb+9+unu2cwoKj1+XL5EC9JYKanX59+Gc1mM9OVXeVO
7OS075p11pX1yp5f3dpzV7kVfWxq+yars5Vbu7qzD2Vmz+nnickWi9Y9nPAn
+35TZJ3ztlmm713Wy6Zd879N0eR1tqZ9ijZbdrOfm7usLmdF7ZvNrIivzNar
dTejTWYF/TR7/tJg3RP78fz03cUnk9OHVdPuTqzvCmPKTXtiu7b33cvnz7+m
h7PWZSe0befa2nVm27T3q7bpNyc40fVb+xf6Auf7Fl+ae7ejJ4rhhdk5aDPG
d1ld/D2rmpq23jlvNuWJ/WvX5MfWN23XuqWnf+3W+MffjMn67q5pT4ydGUv/
K2t/Yv80t7edq2mlNX8pZ/8TTj3+oWlXxIh/8OlP7Ls7Z2+3rij9XaTKftP0
dSFcxBs5fezAAzzo5Du3zsrqxDJX517X/69SV/Bduexc5R395oypRSgP7oRY
GETEn2azmc0WvmuznNiQSLIcJGmPyrmb244oJcHf3HjXHdtN4325qJxdVb1L
Pp7fmtblxGQ/tf6u6avCZtU223m7cPbebTpamThZ5/S52zpX2/yupIf+Qay3
JAS7IZHWncHnuf2u2boH1x7jpQ1oLHNHhGS0ird104W1QVueeTc35i93tCY+
F4cPoy8GKvjNgYLSm973WVXt7FZVZ1nWdMBF39ltSWKn/+KdbA2hQP1bV0Ba
db4TyuhXpt4229q1tirvHa3mPmxc3hGljb3LHnA0V+e0buBRvbPLvqV3Wzpo
Q5xce0NC7YmkDgpAz+A9OmWXkbiaTZnT17V3v/RYyNPJoUowTWie9ZuMWHWX
eSLgwRVMO5FGp9flLbGEeJRnBVkxGF92pgaz7arBN8TXub0m1rcZqDoGHduy
qmx4iB+xxISyshkRTzyDYcCj0H5rl8Pevexz12xx8nvnNsy9kUBEEuHdMmfu
E6GF21TNzhV8NHxu8p5dEp2A9I2I9H1+R3vHvfDktX19YW8u3lz/98U5zCt9
sYQWQqZ5U1XZommZVKHhW2JQv7BZd2L+etd1G3/y5Zcr/m6eN+svxX19+PI3
OLO/Hf3/rDOds2jXje9I2XIcJOgmScKDh6SGrPJ60GPbbBxUnfSHHJfr8kHR
SIILZ7IHch8ZDBbCJXVkRyR+zR6twBiW6NRmeQ6r3dAn2p20zXdQNjiOdVkU
FbmXL+C52qboc3ZZ5htagxTx9uLM+nJVE4sHC/Oiie9+OKfVViWpcglt82r3
XuiBpAw5TgpB7QoHJRdMKto124w8i237usa3vplBW2iDydn5rfV5VpPJ+Qnr
8+Ts9serM2uGbxc75pLsNLdsMd7F10jhOrJROuqiIi3slLFYWV2aPRrcBU5G
exMZJqM3fUlUQ9WJ6p5jIxQej5+rz4SSDdtPQeOXeN4yneo1D+9gP79D8Mqm
aaMn3sFnzhYk5XJb5vfspscUqMeIp2f3ktm6Xy/IvungpKLbRZbfeyyVV30B
SsR+yCUul2VewlOD175qtnOo0M7S2mRRZMHZZgM2so41qg+zA/pA75uO3yzk
zCWtnNXweutN5T6U3S4cVAiHcrcsHj+3r8kfr8jD1QbO99jySkXDFkInvJyd
z0vXLdXEVo6OmlXlP1wxoyhQLnez5y8GfwJXQhYARYOhOLLAzhlxWOHA5ObD
iYl6BkCBhUJNJ24Y2g97IamtA5tYtsOpWgTx+mn3RoLOKgR0jtaJSwV56mk5
3LA6QC6Q2hNhLxW9xDrWJRGFBKwFRVB2h4wGdxRHKMgEoOdd3rchkNxefnv0
fCoa2tHXXqyJTnGYYH9H+0qYxulcS6cnWkWZxqpEvz+UhaOwsykLhDjycSuE
OHvkyzU5rRbHTwRpWZBqsJ4Oauiln8UXCbVBPtO5/UZi7LppHUc0BEgO58UD
qRxhXhYorWhEdmx8FJujlYz5mHXsUEF3VvmGkQUfylDwIo/F2lonIONogDhT
Pf7IMkgZvq+bLbm0lWNsTZK4un53+c2P9uPHf7n55uzF11//26dPvOMBKRl5
6OWLV+Eh+eLV8+df0ReQD8WENe3Db6sYCf3VPhPnPYiULTkoJbGZTq6rf/3q
xadPc3L6MNmS+QxkYcao2lJ8bZstORaXPZTkEJZts2ZWAEWt7jqBHQGOEH7t
xFLic3vr0TbfJmJn1oxEfwSjF6jYrOgEiJzmiy/szWCGHq8IsmbvRxkBXAW5
9smzZ2/e37579mxyHP4NzofPNxd/fn95c3EePt9+d/rDD/hgwof06dvvrt//
cD7+NF7t7PrNm4urc1kQa9Cvdu9rpuP0R/4nR7Rnz67fvru8vjrFzqKKieNA
MgTbWMBdEec2rYPcMgQ2n7flQoT4+uytffG7IMsXL74mxZAP//7iq999+mS2
hKBlQ/bj8lE89GbjyP7KmrU+JwvtSO2PsQXBi21tGUswIAiBPLPvKcSekWf5
T2NeE9zsvYtwJQSYEGaxp0TtaG9diCl9LUjayAlDXGGUMvKGFk6VEqIMPuNJ
h2j0EIlD9BzBSHnKddbCO2ceWsVcvQOWpvCceHTijlE/X6YmHqPavrvPAeCI
IA1fQDXku/WkoK0FsifH1QOQXQ4Zz/HADhCjGQXwILGDyKwIRpEPgD9PjyPp
CMdj3pHETwho66pqRsbR9G3uCjOAMJLbKTFEvVvng5T2UootizXxgaSBfo1o
2XIoh2u1YX1OUci9lAj6WwagiexGUhvEZNbj6gMr+RBL0ixsJI6Es2YIyafw
yyrp4VCHDgRtbUdSNJGDcOxjCPPoNFBskEp8vF48lE3vAcI4LIx5PhYSR6gD
6Mjoz09tw3J5/xZlkpkE7sgiyVZZKQlHGCTGflChTdX7z8TPraYJPmKoL9Io
hIyjTzc3Jvk1hCX5iSjynmMqx3+CEA/YNEAA0jmO+GzdOABUoijguG0I9ZLC
AF2QH7+VL0u8GcsHyc6BoNcNsfTR97zPZNP7u4nmtDCQGl9V1WSgVfFo65bQ
ZKJ4NyAUEPKZ1cMaXK8AH0jB7gn5i9cZALLh45IxAnVBL3eC+z0gQzsFI8RV
0QaN1ASGhyhRKDcgZirq6RtSZfoij4AhxX0AOFCLFSIB+yRoNJ3SJNUDsYoy
PGlH2wST0cOReyUnAnzeNYbVZJ3dOwaS8i7R3omCECTJ4FUCt46Q5tFhUiQz
hf+QfMHelYBU6jiH/WlDQ4YBaZSdYOxyufdMgZoF/CCKP5oVyaYE8iT1NUwn
aEOkqprmvt9wPYZETIkA+YGse8Qucg5BUzqjKTR5y9WKvd1On42wMJw6oNgi
5JyRUkEk5+VySRpW57+iyYhHRXjWxSexYlA7ZVc4rY9FqLAIybkjByw4132g
kDKIOQvMsUd6gmZT1klFQTXSwAEhnxMrHZ0okfUYXiMeSdYQYKpRmHo8UihW
okglcY723t4J3zTRVSIXlIyh+OsGetlK6AXKkMsV4MiQlID3GSO8WJcbFIbX
YYB4uQejBKLSIexkjK4nlg40GdwbIbA1WOKNnrLQx4XoETf2ttAXB8IGorNq
1ZCLu1tLsA/F05CaZX63piS1Rfmv3W24qLYjhvYeYY9FhtCWriILSbLBjmcZ
6zMEM1DaJUbx+8KjkrD5sIAK2/cVQ5YkP+BqIBSD3HXXNsiUvEkimWaGEiCE
ZWRc5HEXg79X+cKU9rLVTJLUI98vfnZ5Z0IJoKnKfBfUc/CF6hdEKfyGvs8q
LgkP8d2wZYbqsexciMU8WS1OcmSmx0illEEPJ4B523gfiM2JhKFYrlUcsiCP
V+QARpM/zj4zVIQhH7uqiNtLmFcamcWok9KuGn1A/nw++i8ZEq1ZcuE0i3Yl
5k3ac2K4ZTD5lXNqBIi18MQX/gcje2l2PHYk8mv4RQw4eiH1NZQe4m1UGEFq
fkw4xIF89b68edSaCVDHOzKdsm6qZrUzRlJVc2JPYQODEXDBCKqX6Ktk5Ug9
x0GCJIBIQ4TUTtTvvkZhGkRzzU+cRYwIWeJLcsLZXfTntIR4Rvir8gEqTK8y
VnofajGH22LSTxsMIlR/Qj+DSNtaihwZowXhatUIcKWtoI5tp4kzfTLBpYyK
dCKgTYl6DSpg9Hjrtl6LYKL5M1HEGcPM2fPfqZYt+5oLAaSBUndTC/1fl5XM
+ICsRQsEraHkDGXbUSLpxc6hBx1DIXrNwDUyoNfe0+vLq/Ovp0kraEsaOrYG
L+7EfUAbrHxAkkiRBEUk6bX5UBqS+A4+e1C0RvsAeFqtOH06q8yCu3CcGpHW
FdHEkfBWXI0nZSjckgIm3oAPls4RntE1DbcokpW0QQXtkcJuehBpaxGSIwNu
d1FB1YM1/JYBBrqU45EvTWkWI9prdgWiSH+LEi2aIAbxmJRJ8VIc+9O1ytBj
k8MT72uFXUZUXzOFxxQmgft4WCbUynISd2uieygc5a51pJaoJIehqc4AQAT5
qpaFBJ1ciqbCUhIgx4P6vRjpkpR/S/tJJi4gek2KhpA0DUbH2WnZ9R3XftPG
mITDQTa3QUeiEgDYKjinZXLX1gP4ajMpizHj0+gnWZC4osyEgyAZ9a5l7eb4
shxhH/JB7ILYK5VaRtUfiQfjvtkeSsPm0koNXqZZAiOzQGpt7oDfZmiicRVk
BL8Fy62aptCqyHHIvGMFkOxFQ3N+51DSwUFUPNiIHBMzpqwIF5XMmeM0PijC
Kzn731nJWaWc+gh5avdHatakwyGbayQXQsfesLskDI72GOOWHcHGteVwDhyw
kG6xqAH7dj8kW59RBM/fcoVCyryH3OJcs8TQyRUkJ6ntkBNonX+/V1o1+VAd
GmVh2WFw8IX9IXnFvsvaleScB18IfafhSLTErZNy+Sts81t7JohYNzem223I
3jvx3HDCoedMSL92axJDbs+5uNeFTEsAPEI1eCnsU7Dy8RdYxSf61+WV1ffs
x5sb7PLJfvSkZfj544aETf/p+NCfjBFPFD5HdNegKChVn33oGL4Q9hhFT/Nh
M6yx26h9odEoiQAXKiex9heh5hM6MeQwEXoeDUUnzoFE+3rPTQjzZIlmmlhQ
ZETph94dlw8KPC7NKxxD2xpxlXE3ifac21te6g8vpPe+5JodIfoJ+/SDqkRv
Rk7TkpCFSmTydFdLvH6ImqLXUKF4FMGiksiEtmhE7SF/OWAJ4QAv8SBzVk9h
SNXCKZL0DR4cdRVpTAhJHJJBjRDDPgXJxHKnKWtg2kQXMUdpLWnvGSFsMt3L
/rhYwSgko3hc7+hX7LtAVZOrEH9mRaW9UaUgdYG+8Q83NyxMcdGa36ddNtYw
IBqG59Uu8jE0NonbqX+xIj2oW1pT8L/GamNFulJFia5NLbpsfSeVO3EB+z40
YKN0EoqytRFKuviQAQjaFyeIzEnXMqtrei7n6Y8Na9xy5M2kuDV2qYlFYtTk
jpJV3VbcJGDJUPVVD/T3As/Ow7QA/JC4odOrH+1L+/tXz19anlnDTAY5vDY8
SswJ1L/8depDeadLa6oiFs8JP0pmMyGPghYGI2QoDN+czn87lVrxz9oX82Gh
1//MQq+Shc7+mYVeimI5fUHHJkTNSPn6zXHiiTWKCmcUSpkRlNJSTrl2NsGb
n8l/XdoNT0p7DCsw7cTLCO4lf7bedMkwxigV0vm1OIyW+unJy4k9Givt1MqQ
gXbtAhwmTfzpdt9vHfS64OpPDAXKddnF2ZXbvNm4eLi3AXC8idaRFmcsJw9k
soWTrIjMonlw8u62aaviOJoLMBbnpGbTt+zXKSmJUD9d5YjQLLsSwf/TcbIV
jX+UbY0jh1SHtTEQyztLVMAyaSaGCo0IjoWEYq8fqtJlHavSqdhFnqWONjGe
ra1RgSouoPhDO28aSdg+n/wq6UZScXIlxOBnUZP2xnXs+Cee0AG3KCJM7ePX
4hzR8Iy5BmtEvI3fY4wfSls+5+bv4BQD9OTGit2rLt2oXSJVLWVCDP0Y8mfk
1jGHtJJUJ8n2UnwcCnWJRVoxycDR0DhU1hMbOZsWoheYdGvVGDg5XKHTELaS
4RdakBaBkPZo1k4RaTqS6BDl0rLZwaPKLJgNHiltfT5uZUmiEsoUIKYvkUPt
rEEnFRNkkgktQ9judYaGkR6nXIz+oisTDVccHPTvkb4ci4pwj02/muK8+zMt
ZajHctafN+s1cuhi8IFKHj2nI6emQ83X1aEplVKzR8wT/hNGaJLaYYT+Uidk
CMKaoKg/ReI6hSKFeimFuyKVm44darGaLHT8ffRvSQv5kG9nwn5iIkN0+imI
k88sNYRckrRyaZSXQg83ExJS4wn5KPvLalsmqevH7J39CcAZGsV17tKTxmKZ
Pl1oaSO+M6IGpZfajIjRB5XXYSwpK0J9JikdBC2IfS3aR4vtQ67txXo5SdK1
eeqtwxgohEnp0JcywBgGGbbDsDIhF4gBfuaSZe1HLXs/pD7LvlqWmOQ0SU0A
ncbH6X8KpxBoSKt5Inkt2w819jDRLQMhMoNwxNX2zn0grSHfdizdOi5DhqrA
MZdo0QU+fXvJw7PTuc64ptE5ppEIDd6lBZeYVmOeAl8kA1Y6VuVUjkzOJivZ
5aQtaK3leTS8Ao/GWTu77fIgURFTmkCe1xnMtFstozMHJ7x4fuwY3Tu2ppfz
lzpJdXZ9fkFJwMXNzfUNOrvx+KyBbd4U7g/P7dFEH5lMk7R3byiJO9CUK6Sh
eM/pRnNQx8w9WRM8qPqDRGHGGhKbsQMJMoXPuoSWJlf9/Z0cfV+3Qmt92bP9
AkamTLi5+Ob97cX5U0z4PTFBH/k8E8hGSHOxq8z7CiP2i4acLUrGMDQhIoAW
1LHVCppk/kPisS49c3rVy9TscXDCmmwocVps4/JkX1cBbOkiEEVIXor91Muo
vGA4e9PTqP1tADfakid9JN+UHLSpdbA65evr0/PvL358iq0vviK+yiOfZ2uo
MJAXipOFB3UsQoCYlcsgdI44ELuO0h5K3D86SJof7/t4ORpPcPFYJKPUpCEo
RC95Ej/L79nFN02HDGizFxOHthRFtEceJtIOS0WHF1PYzMqrZuSY0vRBkE5A
znXyIDwlkJeOrLGaDOX7eMNHuxJmGI1w49y+iw2H/M4NwxzspI8AiXApBYCv
rA17xrKbWo3Rg8xjo4bkdsRlUS/9XX1jLvcM2E1KUTpgn35FPrQLgCezFZjM
F3WGg1ZuiTGY/W5TnNqFSSE1yCTJ3HsMxuD7OLa8bEkZUEJqSMTA4cCntXCL
lZ8YMbcXq3mo7GtTY0CZwYCOUDFP4XPSG4j5SERZU4Et/DN0Hni30ge4uA77
Cp2mPTE1PPZD/NviSpVG2ubeHJF4ce+oTXLmQwyEbIqetUGGnMLVGsjJpHKy
1zpZwtpCjppoG/MhHIA2Iu8w3EAw6UAla/eASRJPrUctuVVBoRKdrl1o7Wad
6VJkH8Bg6mD1OEmWJ9cswphBSsdxgHb7vA1VAELbBVyd3GHSmdVNQ+YLl8pI
IrldiRxdTP2tmPr3buc1r3vkMhLHFEJd8BNJExq4wIyT1kfeJIxhjAIgsUQn
BzsDZ1j/q/pC/j8GogI6Hi/HegiX6OW59H7Ro5j8KGX73rmN9PCrxNuawdtK
02WolKV6EcozqEjwuK/COGAn4E+BzagDi2t8HVztJkjukQAA9Z70tWjtBGfN
2QFcQxs0enSVUMG6dvKXTRty6RUXpUmP+jqMfHLuq9BQZ7VDjsuZwhdE+tlo
8dHMqDGXhwgYPaN2It7FESvbUU2AU3qjGvFE1GO4SrFX47aNMx7YNNu4DwJF
TC61cNaxWLxjy3nIqrJIJikOakRS4Yx1xMsr3ng+nx/+8eaG6IyPmDguMLL+
pw2JT5cUDMn7yFtj+z4e5gkHrEBLFIKuw1ShzsES740eWOtFT0XlOLRzJNUr
nsHiS3zEN9IcWqbFSDGX/7nwlnUdRuen+9olpR3CkVKiCcOKSVqEYPwgbaJQ
v08EE7mx2HENf39KQVr3bPBxZi9LboIcEaRAIt4hPIlOJgoT7nYkLlXL7afn
53tC/dh11adU7jI6MYglXv8M804J0NA7F5teUR9OxBAqM7/0rpeiaEXnbYcm
y6F6X6rsA5eQFA3RezTwxrgvwKtE+EtyiIiqwDLZwuvYrcnSm5K8wDR1SsPV
Ec6EiyJJzSUrh3scximipiP8aSKJSceQgKcUEftycdki8aQO8NRGhKUbeA3g
d542GO960E8FH6eTli45vQ2n1wn2hLhNhotbDY8yxhtlJr0FQMGCrU/SliXK
x+MLHJg54I3icFuCtGTD/W7QyBtO6qaeDfcjJoroh5H6LgxojeaAhOpkJTpM
hYsGHaZc1+u+ls7sqEQVrjyJWYxi5jHnN53c+Cf4YbduwWOvx4anvmU0LMNg
NZKRBp0+vlZXeY3X2gAMBGns53GpAhWXRuoLyVhmQqd2JkqMFx6I/HsGPaIc
gwV669hOlJG7SYACOkMec8m9ax5cqTGAhmUep8qHeIndaJnpENO4hhzvxpAL
CvM40gMPjc79oIORmOR6jKiz9qPYWMOFWnMoeywZmuBWcjoZra9PwyiNfjZa
D/N8Fv6jDNUoZ/ShmcHVjAg0GUrLi1247enUm9X24u1bLdv8/qtXzz99SqtN
+7IcxlCDODT1buSeceJ5gIOSAqUKDQwZzncwjw6DHaQdx4lm5EmnTO71jOLf
z71Kz8bLrKPaNwsxtkAUxD++1KxDw3zLUSKXFudHaVYofY4uZGs5qQnQO+j8
YgQYtVPO4YQDH/e5iYtXDdDB3QA7VFnSC7GcQ83GCx4tdrGGacY/Jd4uk378
FDQPXS9G8pStkw2WfqiXmoXrENjSrccwXG0Om2CNFjM4ITuSFmgCvkWLC4qs
4W8NxNS/kT7BeBEdADWDiWi2rbvPeOBQZMD50C3G5zFuetbwXGO43I0Ju934
hh95nfHgyiZiFqARLiqHuCLjqABRntEnbdnJmLR96CvMNCxKnnIN9zruUi8p
5bChQACnEyv3drg2EKs745mWiT48kckcblQkzQjzdKspzt+NIGsKz0ycoi67
3QGXFh1HkRTxh7E8M3Y5jOlx+5IoG12+5IqYCn+4gxIdfry4qPd31JqGGH5i
tSCxf1s8Xsw4gFvkXoZ98I9wkQ5Xknxop1A4y8IVTH6PTpffNe1gfEpME9aV
Qv7p1eljVbtqOEOcyf/w3Gl+H65ic7dijl7uWwfLendHyoihe+b1JVGyEovI
wWpSttiQiZXOqFmEdkMR4skRL55yzvUPtvCfCiEO8Y2RfsPjhc/sm6y9x2Qu
BruH60ap4yJkvinboQe2xc05/qsZUAeKkEQJqj0fKCyVXI1I2kjrRZjKVf16
fBBWBayRnMQ/vk+o9xuHcvbjQVr8MRFIFFw/k+D3XQmoiStvDExat25Q/19I
opMUmadgxm/6E1MvjPmjXulR3VPdjsngkU7oTTELuT8DRS+PTjjHcjdMny16
/psXcBaSx2+ECenFrW7bCL1hZIJeH4qJg+4+pRyqD6FOIJjgj0Esuajpb2fI
2XD1TwYfB1DaUA6JgcM40Db0+HWgZMIDOxOsc/FhE+6kJSyAFukfAYql+qSg
I6X/2KyiZXSH4BKfXnUUMunFJOgRg5NTxSFUVWidpdM5N5w1HE+21zMFv+Zk
pOv/wN7nYMulGqVCZ15gbv4HZFFBCI5NAAA=

-->

</rfc>