draft-ietf-dnsop-ns-revalidation.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.7.17 (Ruby 3.2.3) -->


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

<!ENTITY RFC1034 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2181 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC8109 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8109.xml">
<!ENTITY RFC8806 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml">
<!ENTITY RFC8914 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml">
<!ENTITY RFC8976 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8976.xml">
<!ENTITY RFC9567 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9567.xml">
<!ENTITY I-D.fujiwara-dnsop-resolver-update SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.fujiwara-dnsop-resolver-update.xml">
<!ENTITY I-D.vixie-dnsext-resimprove SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.vixie-dnsext-resimprove.xml">
<!ENTITY I-D.wijngaards-dnsext-resolver-side-mitigation SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.wijngaards-dnsext-resolver-side-mitigation.xml">
<!ENTITY RFC2119 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
]>


<rfc ipr="trust200902" docName="draft-ietf-dnsop-ns-revalidation-07" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="DNS Delegation Revalidation">Delegation Revalidation by DNS Resolvers</title>

    <author initials="S." surname="Huque" fullname="Shumon Huque">
      <organization>Salesforce</organization>
      <address>
        <email>shuque@gmail.com</email>
      </address>
    </author>
    <author initials="P." surname="Vixie" fullname="Paul Vixie">
      <organization>SIE Europe, U.G.</organization>
      <address>
        <email>paul@redbarn.org</email>
      </address>
    </author>
    <author initials="W." surname="Toorop" fullname="Willem Toorop">
      <organization>NLnet Labs</organization>
      <address>
        <postal>
          <street>Science Park 400</street>
          <city>Amsterdam</city>
          <code>1098 XH</code>
          <country>Netherlands</country>
        </postal>
        <email>willem@nlnetlabs.nl</email>
      </address>
    </author>

    <date year="2024" month="July" day="08"/>

    <area>Operations and Management Area</area>
    <workgroup>Domain Name System Operations</workgroup>
    <keyword>Internet-Draft</keyword> <keyword>DNS</keyword> <keyword>Resolver</keyword> <keyword>Delegation</keyword> <keyword>Revalidation</keyword> <keyword>Authoritative</keyword> <keyword>Name Server Record</keyword> <keyword>NS</keyword> <keyword>Parent</keyword> <keyword>Child</keyword> <keyword>Resource Record Set</keyword>

    <abstract>


<?line 137?>

<t>This document recommends improved DNS <xref target="RFC1034"/> <xref target="RFC1035"/> resolver behavior with respect to the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution.
When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut.
The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache.
Resolvers should also periodically revalidate the child delegation by re-querying the parent zone at the expiration of the TTL of the parent side NS RRset.</t>



    </abstract>

    <note title="About This Document" removeInRFC="true">
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        DNSOP Working Group mailing list (<eref target="mailto:dnsop@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/dnsop/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dnsop/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/shuque/ns-revalidation"/>.</t>
    </note>


  </front>

  <middle>


<?line 144?>

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

<t>This document recommends improved DNS resolver behavior with respect to the processing of NS record sets during iterative resolution.
The first recommendation is that resolvers, when following a referral response from an authoritative server to a child zone, should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut.
The address records in the additional section from the referral response (as glue) or authoritative NS response that match the names of the NS RRset should similarly be required if they are cached non-authoritatively.
The authoritative answers from those queries should replace the cached non-authoritative A and AAAA RRsets.
The second recommendation is to revalidate the delegation by re-querying the parent zone at the expiration of the TTL of the parent side NS RRset.</t>

<section anchor="terminology"><name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 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="motivation"><name>Motivation</name>

<t>There is wide variability in the behavior of deployed DNS resolvers today with respect to how they process delegation records.
Some of them prefer the parent NS set, some prefer the child, and for others, what they preferentially cache depends on the dynamic state of queries and responses they have processed.
This document aims to bring more commonality and predictability by standardizing the behavior in a way that comports with the DNS protocol.
Another goal is to improve DNS security.</t>

<t>The delegation NS RRset at the bottom of the parent zone and the apex NS RRset in the child zone are unsynchronized in the DNS protocol.
<xref section="4.2.2" sectionFormat="of" target="RFC1034"/> says "The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so.".
But for a variety of reasons they could not be.
Officially, a child zone's apex NS RRset is authoritative and thus has a higher cache credibility than the parent's delegation NS RRset, which is non-authoritative glue (Sections <xref target="RFC2181" section="5.4.1" sectionFormat="bare">Ranking data</xref> and <xref target="RFC2181" section="6.1" sectionFormat="bare">Zone authority</xref> of <xref target="RFC2181"/>).
Hence the NS RRset "below the zone cut" should immediately replace the parent's delegating NS RRset in cache when an iterative caching DNS resolver crosses a zone boundary.
However, this can only happen if (1) the resolver receives the authoritative NS RRset in the Authority section of a response from the child zone, which is not mandatory, or (2) if the resolver explicitly issues an NS RRset query to the child zone as part of its iterative resolution algorithm.
In the absence of this, it is possible for an iterative caching resolver to never learn the authoritative NS RRset for a zone, unless a downstream client of the resolver explicitly issues such an NS query, which is not something that normal enduser applications do, and thus cannot be relied upon to occur with any regularity.</t>

<t>Increasingly, there is a trend towards minimizing unnecessary data in DNS responses.
Several popular DNS implementations default to such a configuration (see "minimal-responses" in BIND and NSD).
So, they may never include the authoritative NS RRset in the Authority section of their responses.</t>

<t>A common reason that zone owners want to ensure that resolvers place the authoritative NS RRset preferentially in their cache is that the TTLs may differ between the parent and child side of the zone cut.
Some DNS Top Level Domains (TLDs) only support long fixed TTLs in their delegation NS sets.
This inhibits a child zone owner's ability to make more rapid changes to their nameserver configuration using a shorter TTL, if resolvers have no systematic mechanism to observe and cache the child NS RRset.</t>

<t>Similarly, a child zone owner may also choose to have longer TTLs in their delegation NS sets and address records to decrease the attack window for cache poisoning attacks.
For example, at the time of writing, root-servers.net has a TTL of 6 weeks for the root server identifier address records, where the TTL in the priming response is 6 days.</t>

<t>A child zone's delegation still needs to be periodically revalidated at the parent to make sure that the parent zone has not legitimately re-delegated the zone to a different set of nameservers, or even removed the delegation.
Otherwise, resolvers that refresh the TTL of a child NS RRset on subsequent queries or due to pre-fetching, may cling to those nameservers long after they have been re-delegated elsewhere.
This leads to the second recommendation in this document, "Delegation Revalidation" - Resolvers should record the TTL of the parent's delegating NS RRset, and use it to trigger a revalidation action.
Attacks exploiting lack of this revalidation have been described in <xref target="GHOST1"/>, <xref target="GHOST2"/>.</t>

</section>
<section anchor="upgrade-ns"><name>Upgrading NS RRset Credibility</name>

<t>When a referral response is received during iteration, a validation query SHOULD be sent in parallel with the resolution of the triggering query, to the delegated nameservers for the newly discovered zone cut.
Note that validating resolvers today, when following a secure referral, already need to dispatch a query to the delegated nameservers for the DNSKEY RRset, so this validation query could be sent in parallel with that DNSKEY query.</t>

<t>A validation query consists of a query for the child's apex NS RRset, sent to the newly discovered delegation's nameservers.
Normal iterative logic applies to the processing of responses to validation queries, including storing the results in cache, trying the next server on SERVFAIL or timeout, and so on.
Positive responses to this validation query will be cached with an authoritative data ranking.
Successive queries directed to the same zone will be directed to the nameservers listed in the child's apex, due to the ranking of this answer.
If the validation query fails, the parent NS RRset will remain the one with the highest ranking and will be used for successive queries.</t>

<t>The triggering query to the child may contain the NS RRset in the authority section as well.
This NS RRset however has a lower trustworthiness than the set from the direct query (<xref section="5.4.1" sectionFormat="of" target="RFC2181"/>), so regardless of the order in which the responses are received, the NS RRset from the answer section from the direct child's apex NS RRset query will be stored in the cache eventually.</t>

<t>When a resolver detects that the child's apex NS RRset contains different nameservers than the non-authoritative version at the parent side of the zone cut, it MAY report the mismatch using DNS Error Reporting <xref target="RFC9567"/> on the Report-Channel for the child zone, as well as on the Report-Channel for the parent zone, with an extended DNS error code of TBD <xref target="IANA"/>.</t>

<t>Additional validation queries for the "glue" address RRs of referral responses (if not already authoritatively present in cache) SHOULD be sent with the validation query for the NS RRset as well.
Positive responses will be cached authoritatively and replace the non authoritative "glue" entries.
Successive queries directed to the same zone will be directed to the authoritative nameservers denoted in the referral response.</t>

<t>The names from the NS RRset from a validating NS query may differ from the names in NS RRset in the referral response.
Outstanding validation queries for "glue" address RRs that do not match names in the authoritative NS RRset may be discarded, or they may be left running to completion.
Their result will no longer be used in queries for the zone.
Outstanding validation queries for "glue" address RRs that do match names in the authoritative NS RRset MUST be left running to completion.
They do not need to be re-queried after reception of the authoritative NS RRset (see <xref target="upgrade-addresses"></xref>).</t>

<t>Resolvers may choose to delay the response to the triggering query until both the triggering query and the validation query have been answered.
In practice, we expect many implementations may answer the triggering query in advance of the validation query for performance reasons.
An additional reason is that there are unfortunately a number of nameservers in the field that (incorrectly) fail to properly answer explicit queries for zone apex NS records, and thus the revalidation logic may need to be applied lazily and opportunistically to deal with them.
In cases where the delegated nameservers respond incorrectly to an NS query, the resolver SHOULD abandon this algorithm for the zone in question and fall back to using only the information from the parent's referral response.</t>

<t>If the resolver chooses to delay the response, and there are no nameserver names in common between the child's apex NS RRset and the parent's delegation NS RRset, then the responses received from forwarding the triggering query to the parent's delegated nameservers SHOULD be discarded after validation, and this query should be forwarded again to the child's apex nameservers.</t>

</section>
<section anchor="upgrade-addresses"><name>Upgrading A and AAAA RRset Credibility</name>
<t>Authoritative responses for a zone's NS RRset at the apex can contain additional addresses.
A NS RRset validation response is such an example of such responses.
A priming response is another example of an authoritative zone's NS RRset response <xref target="RFC8109"/>.</t>

<t>Additional addresses in authoritative NS RRset responses SHOULD be validated if they are not already authoritatively in cache.
Only when such additional addresses are DNSSEC verifiable, (because the complete RRset is included, including a verifiable signature for the RRset), such additional addresses can be cached authoritatively immediately without additional validation queries.
DNSSEC validation is enough validation in those cases.
Otherwise, the addresses cannot be assumed to be complete or even authoritatively present in the same zone, and additional validation queries SHOULD be made for these addresses.</t>

<t>Note that there may be outstanding address validation queries for the names of the authoritative NS RRset (from referral address validation queries).
In those cases no new validation queries need to be made.</t>

<t>Resolvers may choose to delay the response to a triggering query until it can be verified that the answer came from a name server listening on an authoritatively acquired address for an authoritatively acquired name.
This would offer the most trustworthy responses with the least risk for forgery or eavesdropping.</t>

</section>
<section anchor="revalidation"><name>Delegation Revalidation</name>

<t>The essence of this mechanism is re-validation of all delegation metadata that directly or indirectly supports an owner name in cache.
This requires a cache to remember the delegated name server names for each zone cut as received from the parent (delegating) zone's name servers, and also the TTL of that NS RRset, and the TTL of the associated DS RRset (if seen).</t>

<t>A delegation under re-validation is called a "re-validation point" and is "still valid" if its parent zone's servers still respond to an in-zone question with a referral to the re-validation point, and if that referral overlaps with the previously cached referral by at least one name server name, and the DS RRset (if seen) overlaps the previously cached DS RRset (if also seen) by at least one delegated signer.</t>

<t>If the response is not a referral or refers to a different zone than before, then the shape of the delegation hierarchy has changed.
If the response is a referral to the re-validation point but to a wholly novel NS RRset or a wholly novel DS RRset, then the authority for that zone has changed.
For clarity, this includes transitions between empty and non-empty DS RRsets.</t>

<t>If the shape of the delegation hierarchy or the authority for a zone has been found to change, then currently cached data whose owner names are at or below that re-validation point MUST NOT be used.
Such non-use can be by directed garbage collection or lazy generational garbage collection or some other method befitting the architecture of the cache.
What matters is that the cache behave as though this data was removed.</t>

<t>Since re-validation can discover changes in the shape of the delegation hierarchy it is more efficient to re-validate from the top (root) downward (to the owner name) since an upper level re-validation may obviate lower level re-validations.
What matters is that the supporting chain of delegations from the root to the owner name be demonstrably valid; further specifics are implementation details.</t>

<t>Re-validation MUST be triggered when delegation meta-data has been cached for a period at most exceeding the delegating NS or DS (if seen) RRset TTL.
If the corresponding child zone's apex NS RRset TTL is smaller than the delegating NS RRset TTL, revalidation MUST happen at that interval instead.
However, resolvers SHOULD impose a sensible minimum TTL floor they are willing to endure to avoid potential computational DoS attacks inflicted by zones with very short TTLs.</t>

<t>In normal operations this meta-data can be quickly re-validated with no further work.
However, when re-delegation or take-down occurs, a re-validating cache will discover this within one delegation TTL period, allowing the rapid expulsion of old data from the cache.</t>

</section>
<section anchor="IANA"><name>IANA Considerations</name>

<t>IANA is requested to assign a value to the "Extended DNS Error Codes" registry <xref target="RFC8914"/>.</t>

<texttable>
      <ttcol align='left'>INFO-CODE</ttcol>
      <ttcol align='left'>Purpose</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>TBD</c>
      <c>referral NS RRset mismatch</c>
      <c>[this document]</c>
</texttable>

</section>
<section anchor="Security"><name>Security and Privacy Considerations</name>

<section anchor="impact"><name>DNSSEC protection of infrastructure data</name>

<t>Referral response NS RRsets and glue, and the additional addresses from authoritative NS RRset responses (such as the root priming response), are not protected with DNSSEC signatures.
An attacker that is able to alter the unsigned A and AAAA RRsets in the additional section of referral and authoritative NS RRset responses, can fool a resolver into taking addresses under the control of the attacker to be authoritative for the zone.
Such an attacker can redirect all traffic to the zone (of the referral or authoritative NS RRset response) to a rogue name server.</t>

<t>A rogue name server can view all queries from the resolver to that zone and alter all unsigned parts of responses, such as the parent side NS RRsets and glue of further referral responses.
Resolvers following referrals from a rogue name server, that do not revalidate those referral responses, can subsequently be fooled into taking addresses under the control of the attacker to be authoritative for those delegations as well.
The higher up the DNS tree, the more impact such an attack has.
An attacker controlling a rogue name server for the root has potentially complete control over the entire domain name space and can alter all unsigned parts undetected.</t>

<t>Revalidating referral and authoritative NS RRset responses enables to defend against the above described attack with DNSSEC signed infrastructure RRsets.
Unlike cache poisoning defences that leverage increase entropy to protect the transaction, revalidation of NS RRsets and addresses also provides protection against on-path attacks.</t>

<t>Since December 6, 2023, the root zone contains a DNSSEC signed cryptographic message digest <xref target="RFC8976"/><xref target="ROOT-ZONEMD"/>, covering all root zone data.
This includes all non-authoritative data such as the A and AAAA RRsets for the IP addresses of the root server identifiers, as well as the NS RRsets and glue that make up the delegations.
A root zone local to the resolver <xref target="RFC8806"/> with a verified and validated ZONEMD RRset, would provide protection similarly strong to revalidating the root and the top level domains.</t>

</section>
<section anchor="cache-poisoning-protection"><name>Cache poisoning protection</name>

<t>In <xref target="DNS-CACHE-INJECTIONS"/> an overview is given of 18 cache poisoning attacks from which 13 can be remedied with delegation revalidation.
The paper provides recommendations for handling records in DNS response with respect to an earlier version of the idea presented in this document <xref target="I-D.wijngaards-dnsext-resolver-side-mitigation"/>.</t>

<t><xref target="upgrade-ns">Upgrading NS RRset Credibility</xref> allows resolvers to cache and utilize the authoritative child apex NS RRset in preference to the non-authoritative parent NS RRset.
However, it is important to implement the steps described in <xref target="revalidation">Delegation Revalidation</xref> at the expiration of the parent's delegating TTL.
Otherwise, the operator of a malicious child zone, originally delegated to, but subsequently delegated away from, can cause resolvers that refresh TTLs on subsequent NS set queries, or that pre-fetch NS queries, to never learn of the redelegated zone <xref target="GHOST1"/>, <xref target="GHOST2"/>.</t>

</section>
<section anchor="other-considerations"><name>Other considerations</name>
<t>An implementation may wish to consider limiting revalidation to delegations that cross administrative boundaries such as anywhere in .ip6.arpa and .in-addr.arpa as well as any so-called "public suffix" such as the root zone, top level zones such as ".com" or ".net", and effective top level zones such as ".ad.jp" or ".co.uk".</t>

<t>Some resolvers do not adhere to Sections <xref target="RFC2181" section="5.4.1" sectionFormat="bare"/> and <xref target="RFC2181" section="6.1" sectionFormat="bare"/> of <xref target="RFC2181"/>, and only use the non-authoritative parent side NS RRsets and glue returned in referral responses for contacting authoritative name servers <xref target="I-D.fujiwara-dnsop-resolver-update"/>.
As a consequence, they are not susceptible to many of the cache poisoning attacks enumerated in <xref target="DNS-CACHE-INJECTIONS"/> that are based upon the relative trustworthiness of DNS data.
Such resolvers are also not susceptible to the GHOST domain attacks <xref target="GHOST1"/>, <xref target="GHOST2"/>.
Such resolvers will however never benefit from DNSSEC protection of infrastructure RRsets and are susceptible to query redirection attacks.</t>

</section>
</section>


  </middle>

  <back>


    <references title='Normative References' anchor="sec-normative-references">

&RFC1034;
&RFC1035;
&RFC2181;
&RFC8109;
&RFC8806;
&RFC8914;
&RFC8976;
&RFC9567;


    </references>

    <references title='Informative References' anchor="sec-informative-references">

&I-D.fujiwara-dnsop-resolver-update;
&I-D.vixie-dnsext-resimprove;
&I-D.wijngaards-dnsext-resolver-side-mitigation;
<reference anchor="GHOST1" target="https://www.ndss-symposium.org/ndss2012/">
  <front>
    <title>Ghost Domain Names: Revoked Yet Still Resolvable</title>
    <author initials="J." surname="Jiang" fullname="J Jiang">
      <organization></organization>
    </author>
    <author initials="J." surname="Liang" fullname="J Liang">
      <organization></organization>
    </author>
    <author initials="K." surname="Li" fullname="K Li">
      <organization></organization>
    </author>
    <author initials="J." surname="Li" fullname="J Li">
      <organization></organization>
    </author>
    <author initials="H." surname="Duan" fullname="H Duan">
      <organization></organization>
    </author>
    <author initials="J." surname="Wu" fullname="J Wu">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="GHOST2" target="https://www.ndss-symposium.org/ndss-paper/ghost-domain-reloaded-vulnerable-links-in-domain-name-delegation-and-revocation/">
  <front>
    <title>Ghost Domain Reloaded: Vulnerable Links in Domain Name Delegation and Revocation</title>
    <author initials="X." surname="Li" fullname="Xiang Li">
      <organization></organization>
    </author>
    <author initials="B." surname="Liu" fullname="Baojun Liu">
      <organization></organization>
    </author>
    <author initials="X." surname="Bai" fullname="Xuesong Bai">
      <organization></organization>
    </author>
    <author initials="M." surname="Zhang" fullname="Mingming Zhang">
      <organization></organization>
    </author>
    <author initials="Q." surname="Zhang" fullname="Qifan Zhang">
      <organization></organization>
    </author>
    <author initials="Z." surname="Li" fullname="Zhou Li">
      <organization></organization>
    </author>
    <author initials="H." surname="Duan" fullname="Haixin Duan">
      <organization></organization>
    </author>
    <author initials="Q." surname="Li" fullname="Qi Li">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="DNS-CACHE-INJECTIONS" target="https://ieeexplore.ieee.org/abstract/document/8057202">
  <front>
    <title>Internet-Wide Study of DNS Cache Injections</title>
    <author initials="A." surname="Klein" fullname="Amit Klein">
      <organization></organization>
    </author>
    <author initials="H." surname="Shulman" fullname="Haya Shulman">
      <organization></organization>
    </author>
    <author initials="M." surname="Waidner" fullname="Michael Waidner">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="ROOT-ZONEMD" target="https://lists.dns-oarc.net/pipermail/dns-operations/2023-December/022388.html">
  <front>
    <title>Root zone operational announcement: introducing ZONEMD for the root zone</title>
    <author initials="D." surname="Wessels" fullname="Duane Wessels">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
&RFC2119;
&RFC8174;


    </references>


<?line 321?>

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

<t>Wouter Wijngaards proposed explicitly obtaining authoritative child NS data in <xref target="I-D.wijngaards-dnsext-resolver-side-mitigation"/>.
This behavior has been implemented in the Unbound DNS resolver via the "harden-referral-path" option.
The combination of child NS fetch and revalidating the child delegation was originally proposed in <xref target="I-D.vixie-dnsext-resimprove"/>, by Paul Vixie, Rodney Joffe, and Frederico Neves.</t>

<t>The authors would like to thank Ralph Dolmans who was an early collaborator on this work, as well as the many members of the IETF DNS Operations Working Group for helpful comments and discussion.</t>

</section>
<section anchor="implementation-status"><name>Implementation status</name>

<t><strong>Note to the RFC Editor</strong>: please remove this entire appendix before publication.</t>

<t><list style="symbols">
  <t>The Unbound resolver software has delegation revalidation as described in this document implemented since version 1.1 (released August 29, 2008).
It is enabled with a configuration option <spanx style="verb">harden-referral-path: yes</spanx> which is disabled by default.  <vspace blankLines='1'/>
"Redhat Enterprise Linux has been running Unbound with the <spanx style="verb">harden-referral-path:</spanx> option set to <spanx style="verb">yes</spanx> for years without problems", as mentioned by Paul Wouters during dnsop workgroup session at the IETF 119.</t>
  <t>The Knot Resolver software revalidates the priming response as part of priming the root zone since version 1.5.1 (released December 12, 2017)</t>
</list></t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA9Vc628bN7b/rr+C8H6oXUiK7aZ5+OJi69hu4zaxU9vZbNtd
oNQMJbEeDWeHM1bU1P/7ngfJ4TzkJN3FBW6AovI8yMPD8/idB2cymYwqXWXq
SJyqTC1kpU0urtSdzHTKf8w24vTiGq5Zk92p0o7kbFaquyO6uuWlUWqSXK5g
1LSU82qiVTWfpLk1xSS3kzJ6crL/dAS/4MnD/cPH8Ndk/9lopIvySFRlbavD
/f3n+4cjW89W2lp4odoU8PD52c23I1kqeSQuC1XSUFbIPBWvZS4XaqXyShzD
/dF6AZSaldS5uACKxPXGVmoVvTW6XR+NhJiI87xSZa6qySnSTJdgifR/v3i+
GNbs7kXrxgvHdbU0pa7gyp2iKzyxKmEEeDwxZcqXefA3sI6c5ztZ6iwNM9Zl
otzz8HY1SmR1JGyVju5UXiskelGauqCduHwDf8IqM2A58vkbZPnUlAt8SlfL
egavLut/1epRZwdGo0IfiV8qk4yFNWVVqrmFX5sV/vjnaCRpOcQi+E8Indsj
cT0VL3EwusI7fb2sVyAGzWWYXOb6d5oEbstM2bmBJdFNxbQySd8s8K9pYlbt
Wd5Mxd/0ex3P8kbWWXSxM8f5mTirS1OosXg7/W4az1TAi9+UKp3JMnd8iWZ6
NxU3xsCb0VTvdJaBpETX27NdvAJhEa/kzNJNC5xTsEHXiVY5bBxs6614vL9P
NxNdbY7E8Qpkr0zliq+ZFGY52H/+TPz9pbtS51UJD16oaqnKDOTZxmtYE0Xf
5BlMnMG80zwbjXJTrkjUjujRq29PDva/ehz/8XX44/Dg2UH44xlM3fzxbP9J
88fzg8fRH0+bO8+/fvL0CPQzn7dnPZ+cTuf1b3otS+kUvXQ6M6kLUvDw3B3u
Hj6k3lf4lF4VpYkHWuvf8oWUZWqjp3gsq1M1WelKswLyO9+9vLy+cevCf5Us
F7gTy6oq7NGjR+v1egqctBMQ6sJYXa9QAB7hpcP9g8NHzYtsCXe+WxpbxVYD
JATU3NyqVPwEe35dwUY4oyBnmdoJIzTK4v9Not9esr4X32uZL1p3SAy/n/bu
DL//auv73TtD7/8AT/Vf/mHavrxt5i3TfuTNl+K0lnn/3ZfT7o3hed/Vg/O6
yyQCh39KBCaFBF/waIF7Pklpz0HeMiNTlU7uatC1Evd4kun81k7gpnsGCZuk
wRdMQFnRrpqE/vyIUF25CY7E38IMwEOYAVbW8leRh0X3dhVm+Fyh+zsKxuD2
/f0Ttu+FNL/VOTw3sA0vpp3rg9PXoC5AwAs5TEH7+tAIr3W+WMF/4ufloPC/
nvbuDA3zo57LfNsYP37aGD8vTT3Iyp8/RRMkGMD8P1KHH/Xg7D+G2QERTE6O
T16eTc4vvj87uTm/vLjerh1aKfW+yEyppviTVAPcS1XKpHoEUK5GOPXo2f7X
TwGk9QQ74KZ3YJzBNtbpRpg5wcMTmSwVAKvfVEJY63Nl9hhMvfghU3qAU8fT
3p1hbm8kYpNstYXd/XvDwpcspcrEO6nTnIBgZySQvvje1eXlzeTny4uz16fb
+Z5pW9kp+LiJkWUyBR4+KjQYI/T2j+hyQKmPgPNfTU5VolYzsFb7h4dfPXs2
XVarrLcfV8ZU4neTKxFelxkYjxzQRULI+AhIrkqT1gmpE1EpwKMLQB2i9K9/
7mah3CrxTlmrMttn0Ok03BtNJhPhBWw0ullqK7yYiRIA7wp+pWAKGRmkJEsf
Pjhoc38ffn8Nvz02EDO1lHcaVrEGvIuXC5A6URlaFQyUwOy4XpDNGJDvXlzv
0SAEt0uG27tXV3vCqsriL/z/nkjrEt/WFfH0TvHENbJ3Onq3VDlwMMvMGh+S
cHOuyhL4jnTA/ikxL80KdsEx04UHMAcRAVRKkSD6J9aPacV+ZRZgsqnhFiqp
BiiZbQSg5nJDK2uPh5EaEixkxXcL9R5XjL+b8cmVJKScFTIfzFFBFBNydSwL
Q4HrIRZSnCIQgvkRaaykrqawh0rsHtO4x/BvT8g0BfotD0EzEDlpqp1AWrYJ
zJceuziY661N5naNDPHCipJnPTWe4LHnF0BLnckS2DXD7Zog0zSIEw5dW/gB
Ky1VkUlcNAwAy4P7lgUIL8B24uZgILqG0Gipc1xSKfNbEoWceTgdXXV3SmbW
CNA+bVKdyAwoCCGXivaigQ8YZjsKNzh2xHDeMN5OkADNKu0XfXPzyv+MN8jz
YsrKttJpmqnR6NzpPY0w8O/DX8AymPvR/0b/PlVB/5QiXnuNIyl5UMdQxOa6
tBEFzAkgrlrKqtGXsVj/t/Xx/4cGeqVjnn5U68jc9xizK61YZLXag3i3v7bw
GLEcYsBkuV0Ttyjiv2oNkbjQ9PBGwKqYFanIEUjHU2Ybt7IWHcEM8CoMkMO6
HRQwVuttY4vGXjkzxXMBj0yeDkmZ6arx/4kC3wAi0LnJzGKDyuz/Ea23wL81
7fXO67fXNztj/r+4uKTfV2c/vj2/OjvF39cvj1+9Cj/8E9cvL9++Om1+NW+e
XL5+fXZxyi/DVdG59Pr4J/gfcnDn8g0izONXOyxxsbXAzQW+wb5rxIkg5BVa
YHhC2aTUM5SDXLw4eSMOHoNf/ytlKQ6ek5P/K2UpnqLHR4XmyUwOYsR/svQU
hZIlDgJ2Fva6gN3NwARIkoV1LpagVMDF0WsDmy63WT60favwRGwB0f7BECgA
a9yZO1lqOdOZrjZewYLFg41MQfLMpmMTUXZSuelZRCCQV+HMYixQTomno2uz
8vq+clYiFheYhp0ePhbdJmPDPEN3aTClRKaRRXETDE6lyUOxNQLyybQ7k5Nu
QLF1ImyFIg9EeD2TpCHeWdN4wINg31U67bgNqVekQTMy8SuDSg/6hVYJOYnj
AUHgLivPXNAomBb0r0z1716nAqtxw8VabtgQwVAFeOjIdyP7gZjKJCabjo5z
Wr9YGDB1rMrOedGDoPLgeqrNlDY73oWuOZ+ZqgKj09bYYNGDwQ+vOQmJLT+s
vM7tJk+Wpcn176wBfZI/fLh2xvrx9HB6iFM2CNjKDag823wwDhqxdGVKssBA
4pKmCtYQAHhdOpPt7DNSi1YeyQSZgPAGjHl5yy+jBQrGHLwLm2jYapiH9pI2
n5IU1kx3pqMX8AwKmSTtUBVFgKWSFtPyJBwJEQK7ADs4HV3O5+BGUezGLUf7
he2yz/ZMP3K5tiBtcEss9QK3lWU3QflxwgNrjZ3mF3ZoU8du5TBL3zsQd3bD
Lljx9fTx9AACAgf/wAnIPaLnCV7+mfbWjbDZc9uFGdf7+73p6CU79tg57sxU
xvof3PhO2DHwPKkGnSPo2Piy3mqAkFjWmBEEf2D9DZDC6/hsC6glpbEEtXn+
GQSIoGygBC8B98IDY7blCYxEVneJtjZHv717sOfQgxsKjJWCeexDgMhJua+P
bAIYAVbJDjBr60xrnxB1oFM2JQgPyNzu4Z6DEg05EU7T1tZkrxpCHHQzPc20
yN8K6dEYswzAUHAyCyR+uZoCmObVziztLamLBgurSWwL4K3GtB7pxdBeBGqB
khz5LTLwZPlDLGQdY5bUeYYeQ4KJXedYfZArkWQa9dN8lB22BnYyT4gbHQ6j
L6mWbHPBZlCNIYP4KIWwqUSXC8O5oltqxo1SJphmqBjlZRhq1QU6EiNMAgaW
jbPMUaQXNQBCtrjneYKmAmZDc1B5Zysh8FI4sFljLUCgmVuxI6jzXKGXAWEl
NaSkaQRO0WkiQ4HmwhQ4E90Gi59RAsSTruayzsgRMz/Qxs31onYIbdcqJXZo
XplNwuCEcl6cX5zSui+uT/fQRzs4sgKPxJup8ySrU/VnNQJu6DJe0ejYOUxn
WHlrONGzzhFjrGVOi1GRuW8QSGNEtlDTwQNMnPbG1UdZDrNaWmmq53OK+Kq1
Uq0gheIbUq3hcIVADW7KjSnEK2BY5tLeVuzevDq1e2xybF2gX4dIHLZ9rt+D
SNHkgbi2VfcgniKqJfiCyrb8C3MKvYx3EwbWcasYj5QAHpFqmS+UdfYBpqDQ
huPCtnzUloNLsNklaDdSNkZT1PCcIFEO4kVVZ3grESuFE2i7IrWY0cCtaNCb
pCgCuPbx03hgNbQRlHBIlgZDIcSVOC/yjKl6kF+caelEjjBGqkgtnchUlUxu
QYFzsDZkhpjcwmgQRWIDPQHc/9agwZGoa2OPmirNEHYNUgcPjynLOGGmWkx8
OnfugqEnAsTp1rZzkm4LQJpAQuca7VCbaAr7SxWiKqddRalXztyygwHheAJm
Y+N0KgYfEXcsFflypZgbYNK25HNSv0gn+V6k2pArRoq4VjSTMBewY+W9vK8m
qbTRFUpEsJZRaKjIuDcSackFgvqgVVhRLqYdlwLWQou61hZ2IwpH2DbM4coy
DkNlR/gwDrA1SCl4ibwK6B/mTGuiDozGZK4q8mhjEkXwQeg3jAvMI1pZi+W8
4gjFRQwzRcRHq1eZVWsO20iVwS2mXh+3ReeduBPi0y29KTtRP0eULqAk1GA8
Pgy2xj6LiO4eSSv1ArVNiri5QsiEN+GYtYM8sSEdEBkqlAMN7ZcatrSC5A8f
uNJ9fz/2vw/v70GI3xaLUqYtKHgSQWGIbGt6Qk1y287t9f+NOJc9lDEjMgnm
pZ1MncHYXEQrYITlMgoz3LScvB1wFLQHbH0I0yJo5bjuOInDO2jidr4RkFim
QipYrTN0SDYBLcD0UuNrLkzlNNGTGKEvF5oP5AwpKGwyZLDEDAxiuiGjQBZS
24ISYLINKR8mFJzeD2c/hVS1YQHoMY8Dpgd4B8txQ9ELZMwGRqGgzbJu8zVP
CGl6N+Ia83xuJT2mNoYFXoxWh0wmjNjA3MwswN0RVgzetJP+jRIIpks7vDR2
GAqftoD3fQ4AXgPYZkO8AxLSJN1y9T74Chjq+uzqb98en79Ck4VeyNROdYHx
qJhvjNUe4ze0DG8J9t/gjriEokOzHThFeNSVCADm1Amt967JUKYatKhiCSKD
hsUoElY/fveJlgnFEDxtpRXcFo69SSYWuSDV2xfOmELMwjrWW9pcakyatdNK
bEqIKhft432m1Kkvxd+YknfzIWf9MqjEgsJme0xweZauqrdjMnImBtC6m7gL
m2UPNoNfXassc24jPL/kcNZhjOGiTsgXUJjlQ1DeCUdckwtwqYBWiE+qDHEN
xCoUlzlrBm6FYgEXXznx9TUuMi9sUsftNQYSeOf6iXtH2qASd+QVdSeSGQJu
CBmqGqHMNDL5Ll5MVQVjR4B/eBa3OTYCKLGoBpb2cyt4nzasBY6GIgUKp18f
/4RZEAwE8N4K0DPZXQbgGEWclaXB5kp8Bq9RhRi71e7vfSqTb05OgKocrGjL
CrqQ2skP/v/hlyI0Nw52AAwP4BGX+VVEEPb44YpuXpwCSefHF8fksI+bgkzf
6oVJdjADtRNXUtlm9kqluxBzIJ70/qlTQUGM5p0Ibf5e1zMHde7bBUdLkwb1
KjZgODv2sUsGZw2bMDQ3XdvpVuzqsP8l69meIhZQiCRMZEx7nHVWiktbQfHa
KipjTOGzKXFsHN7jYXTes2MD817WFaW+cdAtEjIgHaSuqXE5MlSQMOcDYT/S
SmyzCdguNESmbHIZcCdTczDwdZ47XI+59kyFoixnKTCPQjsA0a4LPL0L0H3R
xg37T1f56SukitjHF7LxvPP4rtM1QHELmusihqtb5qTc0S//3A3Q2y1B2b09
kKsmAiEvFwJ3wFdy0/ISXox7vrKGMDjjfP3gfV+P6Ol0E16wb8FazTnWnzFY
SdCgUZ0SvcsKk3XdtBnlG9grDU6MlZn0Toac6BazAuE0dRHn1HZDpQKs08TV
apfoilJPpa+fwKtVnXPoLEVeY1tUJzT2UjHXKkt5hF0AlKZE+5Bt9gj0cAyL
nVJZWJVPl7YkkTPEzv+FjEPIfPKWRQtl+MvpwCBOjIZTiP1+184iGkpw1VjC
cakFEgPZxEicak4kmdiQ4RgOMlhqUOfCOimHEGd6W6lh5wnkDGgxLogOOe6W
vjo9tqEXdY4F1xlGsTADu2LK2eELoUM8hiwhnh6ytOednDXrhB1WCs94Lw9g
dKIsXbAJLl8apyeHkYzXlYeLRdVS5S0yooCYFglrxly1D0W2wdvuLJ09bJxz
sMnO+DTi5RkAu8VDu0TGTHki8KUFQWfTX3grcovyB92OiG15hGDMPpZOCGmF
1qmYiIFNReOLCLHHvTNYfvJhQGQbAglgNJoXIwWM8xa+3OHykmgo6FKUXj8e
TBRKVzeOXuxFfF3iw/sEQvGYRRf0BdrJVg47kIZFjTw0Kce4d+Yh6Nf0qF36
vgnHjCFqcDQAr9dnJ4jQ9VxjX/pY7M5UImuXCXZOUzUFWlfoSONwXUYDAK5f
gKXGXIq3J/QuhkxbScFd3w4l4/IomkmDNeqHQPV05NfV3ALSAQDWi2XrYu7y
lmRvW9lTksiYQFfqktbWq2DiA398XvYBNN4CsGOfiH8gNGhEYQVq6NlpVawN
UbqLDaSDcSZCWx5PPRB9tBq6toGcdvPm9lH3XLU0MJYstloPERC5S1zkZ4Ml
uQ0qgUN3UsWyqdImwHWeP8HNcLgeGeATSZR1ydnD9QwAOvLE9bR5Frii79bn
cHCXpliT4TZz37ezwnMiTXpi0wqwfGMqACMwEdre0kzw3wLXiSIH4M6mAGgK
yj+Nth3rbLqeYtSy1ZxzJIQSFpW6o1oW5YYn0fhoKAEeRH50pSpJyTEG8Nqh
E2rlCX+5eh/V67m6RdvQmLEbzpYTG6m2x1UzTL2sqDd+AByJFi6YE5eSZUgx
YEzb9uNRiL/b5P73vKWPxnQQkMpvreqBrDqlgk5tAYyGSTSReBrUCaw6hA35
HuVyI9bVeUqhx6RtvRAuosyJnfatwui82qFZ4akdrmTR/R10HFgUjRIYsCCP
PPhJjyEZN+p8QowK0I/THY3W+4xjnwReuHbsCC9gKjmTRSTOYBLvtKmt70JL
m4dnGwQDLO9IRnc/G+b22djMNDxJ6w3aQn6tO2cjTejJMI0aodUAFcgNR6ss
+bft1vC4rrckSwSyqCJcaZeAeLyERPu/1KqUZbLcUAqTC9TpdIiIT9oXMasr
pmq9NBhx5Abr703Nr+zeOu1j4Cb7yh5DRsXNQCHWghNu9HDNRA4sAFdKsLma
I0oP0NWqcK2AmDLkv/zUtuH6x9nkfFibRtkQSNHvHPudKA9A5Lq1JXWJ29RI
CdmsNbmuxiIxVpLEK9/GRTLeZ7bvx/X5EEprLWmFNblDckmzTZO4WshyJhcI
JUC/XUNIiTHjRixU3pzpGX6O+kAZtWITj8GgYK6rykclyCGN+V0EZL7Hj43r
O9fTXVH0HOd/ycpS7yW1SSHiWix5R5k/ZEOpAE39ChzUx8zAdfpCUuix0J8q
99xTRV0ainoHXZGqmSNqHKtMIXaxZ2CPeqMwGhK7Th2aLdwDbUYygS5wOtR9
haLephoBh5ndoaF2hYOBp+wDnHMODZkPi9Y5twj7FUZpRepx6BFJUSDwFRu8
AEtv2Iz/j5jXJe0wdhIDlElYHtuZGkzjY1mHEFS8KJ8PczgJS1lLKja3fPWE
NjZoi9MGViRuhUD5J7Si3icA2ryAtavl8DyocGOT2cSAJwz2izIV5HKYS1ub
QampA7zUCv1e2dQXhnohqRenlZChVbsWRtocWXFP+h2WLYHBEEBFrY9NfdiB
bo0nhxXVhXOX+qbWsHpFhM0z4/OmuBWYC3VpRmyb4y54eWd0Cmah4iYrihXq
yqvzqbn2XTSYP8k0GQMwDNzLS97yzsX6Ja2QbGLu2/Oa04IenflNdDYGQFNy
y60mTSRJwwIa9xIFoPM2YgNJRhmfdCbjKm/hEnbXU2MfoqBYJXAbuREV8UTQ
eqIK50M1yFuajhxkocIyuyvBcyETe7LU+6LOrMOVJnNGuekUZfM1wgKLOMGS
dxpY0W7xpxLMEMh1LztwqawrIABMA5fPWf6murpzFpd6uPZ0YlJsDSzVApux
Ny74f37wmIL/P6KDG/Hv3r+hm3+M/hDnF99eTk4uT8/EH+JNXZIoDvz7A1C+
P0UUrrVnP/oTs2P9yk8QAEZTQfD1uD/EP35pteH845/d2T9/7aNr15xPwOBN
qe9kshna5Q9/8U9+UlZq5FMC2HLf9F2C5pUA/MqaHSQJWnM6blXIpLofDRA6
+A8tb7eNxrPNhh78BsMOpkI4Hv1YlmiXcym2cSbdfNbeOKSL3JK9+jtGhDyN
S8STLVIO3CG4xGQOKkXmOrjwHAMi4rR/lOqBs2dxEXPwlGdnaWOyX3NjsrhG
jQcV0Q5F6QzgAkdK7FXwrGMW4q2wGE7Et+Zsl6WuXbIwvILTYx6UCu4Y1YIv
RhDizQHByt3QdN0EAB9Z2R6D8NIs6lZgQ+Ff7yqRcafVmkgI6ZrmIF/TTd6g
cQ5OcbvwpbBd2OZuWx04Phdn4+C3dRKtkVd80buLfjk6Pg7btFP557w499c3
btUvWwft0Nj1J2K5aLoT+XghygkVHf/b4oFExMgtajZR/hxKXXAoCjzDzwGN
XUKHoRlYjpCIdv20gK7aqubIytyp1Z4MtDpiEZsFMIEBi089hsXdudXiI2jM
+MMiPGAhE994nG+XEeQYmwqCka0Gus/QYaAArYcr58yxr5+qE9al32Z4Eqvp
dgztxm3jRPvaMs8+NHybZ/rWxylNUzJNlSiHxzM6E7DAdJJrbcZOA1NsXBGw
olN5VLiB2JRbNzsgks8sR/oQJc/pzHdp7ujwVORU/EIh4Csk5k58p7SLk/xX
HcSTMX4F7atxs8OcovJtNrLDi6TcFJVZAERaUmO5tbi4VC+wI8vhj6dP7u/h
Z/M5CuweJThGIobpnjAR+rrQPe/CdEkl/W7/DnnF2GD07b+X1PM3EY+8jRzs
57atBpy41SIyPe7YMey107VIJadkNv1qMpPEWRBnHZktz/af4KFSzmSFbDBO
0gBj910Mf1CMsrRue+Pdbc42g1QaRvxlrCdhwd7JY3jKUSTrI0rCSUdwmwke
wBoE/j98GPrYC6wOM6iwNPIYsKMLjcUI2ICDZ9t699k0c6PawVc+asDEaqo9
VGgdUG0Ug60gfUqp0YF2jzaLBMRsacbmI5xRj4/u9I7IYtUO2Iv9/r5rzEkR
zCF9NcV38cQnTj98+LyviRFQ/+XhZuqooSO3exyq2FYvsWMudYdX8M7vQ2du
OMjtnRTtfwKgr3qd9swoVOMciaaDsO4kUEgIcC6iUkXn4PUvW+oDsM54e/e2
n18fapKn6L5TOePolM9IS9Bg7LAweGQs6r+DVS50Tr4sOgthxpSwbDn65rbE
M8AouAwHuFC55aADHYVpn2jgQzBNx7HPZYZzDb5xgu52TuoFyNeQQ6Zna6c+
8YSbskPsMqjgCAo62ZwVnR/H4xomjCAyvdLOG0deimtjAanwCWk87BmfFkZh
ckc+dTgRiJZ2w00mIB1TXTyZyrKQJM5TnVPh311pTDU2CVkzceWInaKeZXhk
vAaM/H5H9OIS3uvGCrqjyu6xHfwO5A7uww4eDHKfGFDzOZrDO/XAezKd/la4
NxMzrW930MViNrQRB4cuZcp9NEb0zvf6A71xc2/05QFfBt+qmNswc6kAsDCC
GerhpCNV6OgT2s5+02Io0rBZe/hriyhsx5YPNLKkJ8p/L8GFgLa21MnmYjrq
9IqzwQPuQeVgWEtZ+eMoWxwPiRtOM5M2HAElNcl4Od3ea/e1MIYf164vw20Y
pdkRWQ3QjIOScnlg6wndpn+dsSk75ZvDWa9nKsdkOXvCT8kPxFCwVF0Kufzs
Y0fuePbgD7Scuqcg2Etuc7MG3eEP17ZzVpR36D7RT3CMRu9MjRj+XfB31Ndm
cAui879mhliyL2Lh2Jc/T/tnvCdBx/CFhpA6Doas6bV9m5PpaZ9Hv9OS02tL
7F/CzzCymhBsBsUuGqQBNmIGnsJvSqCeTTZ3GncwWO+TS1iziDxO4FZY/JYv
laJUzTbRp2jH4sqkOejW91jFZ2PxLTqFUidGXIBg+QMPzHNf86eQhcP1/FZc
yayAaMfg1+iw0c8QgQ7+bKjIA2GS86EO62CytoeaSZW5GB4QN34wmZgdfS75
HbyMzPkOvyLM4ExlxbymvDQLIq4E07c1fXsZv6Jy3nZK+F2Q2rZkte22JvzE
lozcaPTll9yuwtoMFlecpRqW+OWXR6LIKEjjuhIv2AWylMVP9XtXQhXschwS
HX0pbiIRC+Jlzbxao5Iupd2GY3tfpmlDyliSuXrkMekBfgMCLJwim3dcL8DE
icPnGNHtP9vDTxGfV9xxhHGwPzzUOVDMEi5+HZL/I7FR9tfmmD5sC4+ElUM+
yA5LF2LnSqVogM/4czuAv/DDovX7Rh19B7RnUCjDD8/7qycLcRLs069EB4rL
BiTThv4r0A2gZ2V3SCCRSfAS00eqwvYpfOSL/BYJMH3FGka38ZEQEtiDg+dT
t5s/oP2/6m1lkybyRf5OD1/0TQd/rx1dd7fx69ZGhtj84BC38uDp3mj0b3g1
Nlg1XQAA

-->

</rfc>