<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.3 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-rescorla-doh-cdisco-00" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.40.1 -->
  <front>
    <title abbrev="CNAME DoH Discovery">CNAME Discovery of Local DoH Resolvers</title>
    <seriesInfo name="Internet-Draft" value="draft-rescorla-doh-cdisco-00"/>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>Mozilla</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
    <author initials="J." surname="Livingood" fullname="Jason Livingood">
      <organization>Comcast</organization>
      <address>
        <email>jason_livingood@comcast.com</email>
      </address>
    </author>
    <date year="2020" month="June" day="25"/>
    <area>Internet</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This note describes a simple mechanism for determining whether an Internet Service
Provider (ISP) network is operating a DNS over HTTPS <xref target="RFC8484" format="default"/> server on it for users 
connected to that network.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/ekr/draft-rescorla-doh-cdisco">https://github.com/ekr/draft-rescorla-doh-cdisco</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Some applications perform their own name resolution rather than using
the system resolver, typically using an encrypted protocol such as DoH
<xref target="RFC8484" format="default"/>. These applications have the choice of using either the
same recursive resolver configured into the system or of using a
resolver chosen out of a preconfigured list of trusted resolvers in 
an application, such as in <xref target="DOHTRR" format="default"/>.</t>
      <t>If all of the trusted resolvers are publicly available, then there
are a number of mechanisms for choosing between them, for instance
randomly or based on performance. <xref target="I-D.arkko-abcd-distributed-resolver-selection" format="default"/>
describes a number of potential mechanisms. However, if the
list of trusted resolvers includes Internet Service Providers (ISPs)
and the client is on a network associated with such a provider,
then it may be desirable to preferentially select the resolver
associated with that provider. This provides the benefits both
of using a DNS resolver with a known policy and using a resolver
that has high quality local information about the local network
topology.</t>
      <t>This document describes a mechanism to address this situation. This
mechanism is being tested in the Firefox browser with Comcast's
resolvers.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</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" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="doh-resolver-discovery" numbered="true" toc="default">
      <name>DoH Resolver Discovery</name>
      <t>The basic mechanism described in this document is straightforward and has
been chosen for ease of implementation rather than architectural correctness.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
                                +--------------+
Provision CNAME                 |              |
doh.test -> resolver.example -> | ISP Resolver |
                                |              |
                                +--------------+
                                    ^      |
                                    |      |
                          doh.test? |      | resolver.example
                                    |      |
                                    |      v
                                +--------------+
                                |              |
                                |    Client    |
                                |              |
                                +--------------+
]]></artwork>
      <t>A network provider can publish the fact that it has an associated DoH
resolver on its network by configuring its own resolvers to serve a
CNAME record at a well known domain name which cannot be otherwise
registered. The current test deployment uses "doh.test" (see
<xref target="RFC2606" format="default"/> for the definition of .test). This CNAME points to the
domain name of the associated DoH resolver ("resolver.example" in the
diagram above).</t>
      <t>[[OPEN ISSUE: doh.test is probably the wrong domain. We may pick
something else later.]]</t>
      <t>A client which wishes to test for the presence of a DoH resolver on
the network takes the following steps:</t>
      <ol spacing="normal" type="1">
        <li>Do any testing for whether DoH should be disabled, such as looking
for canary domains <xref target="I-D.grover-add-policy-detection" format="default"/> or checking for
local enterprise configuration.</li>
        <li>Do a CNAME query for "doh.test" using either the system resolver
or by talking directly to the recursive resolver IP address configured
into the system.</li>
        <li>If the query succeeds, then look up the CNAME record value in the list
of preconfigured resolvers. If an exact match is found, then use the
resolver address for the matching preconfigured resolver.
Otherwise fall back to the ordinary DoH resolver selection logic.</li>
        <li>If the query fails, then no associated resolver is present;
fall back to the ordinary DoH resolver selection logic.</li>
      </ol>
      <t>As noted above, this mechanism was designed for ease of implementation.</t>
      <t>Comcast's resolvers and authoritative servers have been configured 
with some additional records to support the Firefox applications and potential 
future applications. The DNS behavior is as follows, where example.com is the 
domain used for naming provider services:</t>
      <ol spacing="normal" type="1">
        <li>doh.test IN CNAME doh-discovery.example.com</li>
        <li>doh-discovery.example.com must have at least one A and/or AAAA RR (address does not matter - can be 127.0.0.1)</li>
        <li>doh-discovery.example.com IN URI https://doh.example.com/dns-query (the ISP DoH URI - not currently used by Firefox as the URI is preconfigured in the application)</li>
      </ol>
      <t>The next few sections describe the reasoning for some of the design
choices.</t>
      <t>Considering that many applications do not act as a DNS client and instead
use platform functions such as getaddrinfo, the domain of the associated
resolver SHOULD also have an A record, so the call to getaddrinfo does
not fail.</t>
      <section anchor="why-dns" numbered="true" toc="default">
        <name>Why DNS?</name>
        <t>There have been a number of discussions of using non-DNS mechanisms
resolver information, for instance as in Section 4 of
<xref target="I-D.pauly-add-resolver-discovery" format="default"/>. While arguably more
architecturally correct in terms of layering, they have a number of
deployment drawbacks:</t>
        <ul spacing="normal">
          <li>They require the client to have much tighter integration with the
operating system in order to query the data. By contrast, with
this mechanism, the client need only be able to do name resolution via
the system resolver, which it generally already is able to do via
standard APIs.</li>
          <li>They require new types of configuration which ISPs may not already
be set up to do. By contrast, configuring DNS records is generally
well understood.</li>
          <li>They rely on intermediate devices (e.g., NATs) being aware of the
configuration information and passing it onto clients. These
devices already do this with DNS information.</li>
        </ul>
        <t>For these reasons, DNS seems to be the easiest solution to deploy
quickly.</t>
      </section>
      <section anchor="why-a-cname" numbered="true" toc="default">
        <name>Why a CNAME?</name>
        <t>Most other proposed designs (e.g., <xref target="I-D.pp-add-resinfo" format="default"/> and
<xref target="I-D.pp-add-stub-upgrade" format="default"/>, and
<xref target="I-D.pauly-add-resolver-discovery" format="default"/>) use new RRtypes. While this may
be the right answer eventually, it is less convenient for immediate
deployment, for several reasons:</t>
        <ol spacing="normal" type="1">
          <li>It is somewhat more difficult (though not impossible) to look up
new RRTypes on the client and provision them on the ISP resolver.</li>
          <li>Some consumer-grade middleboxes (e.g., WiFI routers) may block
unknown RRTypes. The data here is quite old and limited, but still
not particularly promising.</li>
        </ol>
        <t>The choice to use a CNAME does have one major drawback: it does
not let us provide the URL template but only the name of the resolver.
This is not a problem for our system in practice because Firefox will
only connect to resolvers on a preconfigured list and thus
will use the CNAME as a lookup key for that list. The Mozilla team is working
to measure the rate of new RRType interference and may revise
this approach depending on the results of that.</t>
        <t>[[OPEN ISSUE: We are working to measure the rate of new RRType interference
and may revise this approach depending on the results of that.]]</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Because the initial request for discovery is done over insecure DNS
(Do53), a local attacker or malicious local resolver can substitute
their own response. However, because this mechanism only selects from
a list of preconfigured trusted resolvers, an attacker can only
redirect you to a different resolver out of that list, which by
definition is also trusted. Note: the URI field potentially has
different security properties depending on how it is used. As noted
above; Firefox does not use it.</t>
      <t>If the server which is redirected to is not
publicly available, this mechanism can be used as a DoS
attack. Application clients should test the selected server before committing to
it and otherwise fall back to their ordinary DoH selection logic.</t>
      <t>Any local discovery mechanism has potential privacy impacts: suppose
that a user uses their mobile device on ISP A, which redirects it to their
own resolver, and ISP B which does not.  In that case, the user's
DNS queries will be spread over both ISP A's resolver and one of
the public trusted resolvers, which could have an impact on the user's
privacy. This has to be balanced against the improvement obtained by
using a local resolver and the level of metadata leakage that currently occurs
to the ISP, but can be mitigated through trusted recursive resolver 
policies.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8484"/>
            <seriesInfo name="RFC" value="8484"/>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization/>
            </author>
            <author initials="P." surname="McManus" fullname="P. McManus">
              <organization/>
            </author>
            <date year="2018" month="October"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS.  Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
        </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>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC2606" target="https://www.rfc-editor.org/info/rfc2606">
          <front>
            <title>Reserved Top Level DNS Names</title>
            <seriesInfo name="DOI" value="10.17487/RFC2606"/>
            <seriesInfo name="RFC" value="2606"/>
            <seriesInfo name="BCP" value="32"/>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization/>
            </author>
            <author initials="A." surname="Panitz" fullname="A. Panitz">
              <organization/>
            </author>
            <date year="1999" month="June"/>
            <abstract>
              <t>To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like.  In addition, a few second level domain names reserved for use as examples are documented.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.grover-add-policy-detection" target="http://www.ietf.org/internet-drafts/draft-grover-add-policy-detection-00.txt">
          <front>
            <title>DNS Resolver-Based Policy Detection Domain</title>
            <seriesInfo name="Internet-Draft" value="draft-grover-add-policy-detection-00"/>
            <author initials="A" surname="Grover" fullname="Andy Grover">
              <organization/>
            </author>
            <author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
              <organization/>
            </author>
            <date month="July" day="8" year="2019"/>
            <abstract>
              <t>This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for the special-use domain name 'TBD.arpa' and designates this domain as a special-use domain name.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="DOHTRR" target="https://wiki.mozilla.org/Trusted_Recursive_Resolver">
          <front>
            <title>Trusted Recursive Resolver</title>
            <author initials="." surname="Mozilla">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="I-D.arkko-abcd-distributed-resolver-selection" target="http://www.ietf.org/internet-drafts/draft-arkko-abcd-distributed-resolver-selection-01.txt">
          <front>
            <title>Selecting Resolvers from a Set of Distributed DNS Resolvers</title>
            <seriesInfo name="Internet-Draft" value="draft-arkko-abcd-distributed-resolver-selection-01"/>
            <author initials="J" surname="Arkko" fullname="Jari Arkko">
              <organization/>
            </author>
            <author initials="M" surname="Thomson" fullname="Martin Thomson">
              <organization/>
            </author>
            <author initials="T" surname="Hardie" fullname="Ted Hardie">
              <organization/>
            </author>
            <date month="March" day="9" year="2020"/>
            <abstract>
              <t>This memo discusses the use of a set of different DNS resolvers to reduce privacy problems related to resolvers learning the Internet usage patterns of their clients.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.pauly-add-resolver-discovery" target="http://www.ietf.org/internet-drafts/draft-pauly-add-resolver-discovery-00.txt">
          <front>
            <title>Adaptive DNS Resolver Discovery</title>
            <seriesInfo name="Internet-Draft" value="draft-pauly-add-resolver-discovery-00"/>
            <author initials="T" surname="Pauly" fullname="Tommy Pauly">
              <organization/>
            </author>
            <author initials="E" surname="Kinnear" fullname="Eric Kinnear">
              <organization/>
            </author>
            <author initials="C" surname="Wood" fullname="Christopher Wood">
              <organization/>
            </author>
            <author initials="P" surname="McManus" fullname="Patrick McManus">
              <organization/>
            </author>
            <author initials="T" surname="Jensen" fullname="Tommy Jensen">
              <organization/>
            </author>
            <date month="May" day="20" year="2020"/>
            <abstract>
              <t>This document defines a method for dynamically discovering resolvers that support encrypted transports, and introduces the concept of a designating a resolver to be used for a subset of client queries based on domain.  This method is intended to work both for locally- hosted resolvers and resolvers accessible over the broader Internet.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.pp-add-resinfo" target="http://www.ietf.org/internet-drafts/draft-pp-add-resinfo-01.txt">
          <front>
            <title>DNS Resolver Information Self-publication</title>
            <seriesInfo name="Internet-Draft" value="draft-pp-add-resinfo-01"/>
            <author initials="P" surname="Sood" fullname="Puneet Sood">
              <organization/>
            </author>
            <author initials="P" surname="Hoffman" fullname="Paul Hoffman">
              <organization/>
            </author>
            <date month="May" day="14" year="2020"/>
            <abstract>
              <t>This document describes methods for DNS resolvers to self-publish information about themselves.  The information is returned as a JSON object.  The names in this object are defined in an IANA registry that allows for light-weight registration.  Applications and operating systems can use the methods defined here to get the information from resolvers in order to make choices about how to send future queries to those resolvers.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.pp-add-stub-upgrade" target="http://www.ietf.org/internet-drafts/draft-pp-add-stub-upgrade-01.txt">
          <front>
            <title>Upgrading Communication from Stub Resolvers to DoT or DoH</title>
            <seriesInfo name="Internet-Draft" value="draft-pp-add-stub-upgrade-01"/>
            <author initials="P" surname="Sood" fullname="Puneet Sood">
              <organization/>
            </author>
            <author initials="P" surname="Hoffman" fullname="Paul Hoffman">
              <organization/>
            </author>
            <date month="May" day="14" year="2020"/>
            <abstract>
              <t>This document describes methods for a DNS stub resolver to upgrade its communications with a known recursive resolver to include encrytion using DoT or DoH.  This protocol is designed for the scenario where the stub resolver already has the IP address of the recursive resolver.  Other protocols under develpment address scenarios where the stub resolver wants to discover recursive resolvers that use DoT or DoH. This document does not cover such discovery.</t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAmr9F4AA61aaXMbNxL9jl+BlT/EqpD0EW8OpnYT2ZLLStmSVpLLtZVk
XZgZkEQ0M2AGGNGM4/3t+7obc1BSDm+FqUooDgbo43X360am06mKLpZ2rvee
nRy8OtKHLuT+2jZb7Rf6pc9NqQ/9C31ugy/xc9hTJssaez28gKf9S3uq8Hlt
KuxXNGYRp43Fk6Y008KvpnlB66YPH6rcRLv0zXauXb3wSrl1M9exaUN8/PDh
Vw8fK9NYM9fHdbRNbaO6stuNb4rhl+khba9UiKYu3prS1zhya4Nau7n+Pvp8
ooNvYmMXAd+2FX35USnTxpVv5kpPlcbH1WGuj2akHUvJP4r4R43Ld3/3zdLU
7hcTna/n+pX/xZXpia2MK+faXjXfNnFRzXJf8e87x3w30y/dtauX3hejc74z
wdc3nuye9MxXuQlxfNJP9NLbsnvp21yW8MGq9k2FV68t1NTnz589fvToqzlM
DEOPHmh9ePri8vxcvtMn4eCSvGAL6J63TcDq3vfDStMsbZzrVYzrMH/wYOOu
3KwSg8wg/IO0x9t+j7e39ug9MfpMxVKdaZWaTqfaZCE2JoevL1cu6NpHqwv4
pXGZDdro4Kp1aXVl8xWMFioNNbEAMKlcDfvozcrGlW20qXv06AvbXLvcqrPG
X7sCD+8fX5ztazwCzK40zvFr28BYeN/ow5MLTfDWLy4vzy70+/d/g1m/fPLl
kw8fdMBOeAIfushHt/glaJX7urY5GTJ6HVcmdpvPkl6VK4rSKnWPpGp80ebk
bqUufGW1Wa9LlzMAgoYk5DrsYh1O2tQMHd2QSVtaoiEpaYhjapwPoRX+Buzh
hErWQcaJjts1Ni3LrSwii9g6b7ZrEnPdeISNL3Vo85U2gQJbvX/fazrTlysb
boi2MsAHnZWvPOxJOUO2ti5JZFUQYTs0deJoWGjhlm2Ds13NRupFhhn7nYwa
3lj5YGvt20iPDUS2o01KF/j3mADcvRawvVbQdST5pNcSz96/l1CAjkodY+Oy
5H0gz+29kJj0us2wEcxorhGOJivthFbX9K/GUu6CcHVbZZb16KEZGCDQwrNm
GQBh5a1qwo8Af+Qz4LJBVvMVTsCPmQmQAF5OOKAFMwj9zfH0cGaaqys/NVle
TJFcI4KihbzTTt5psKVlYH34oMZRM0i3RkDV0SHPD3LO9Au/sYwZx4ZQv2fc
vGyx9a3g0l1wBY6usA8fFAKW0uFIjrKaZElRZ0LwuTO0/QbwSS4iYPI2E8U2
RphVZgvjURZwDVmfQgxYWMD4rAnsJnrzaZ2o6ub+HJXd7gRvCJT+DPxmZmu7
cDHozMeVGhDJCaFHJe9l9FVNkbn2QAaAAU27xf35fN4KmFu55Ur/3JrSxa0u
ucb22ZkskhHCSQB5luyjosfufrmdpVSIUttWZMixY4c8CKOYosDppAyWBxdb
PkBUVcNKPMwsCRstO9cxJvVzB5v6dzpr/CZ0iqZq9EnowzJQRruHB/U1mZ/S
Aql/CNPVjv8mea1GDddUxIPee/X64nJvIv/VJ6f8/fzoX6+Pz48O6fvFi4OX
L/sv3YqLF6evX+K5St+GN5+dvnp1dHIoL+NXfeOnVwf/xn9Iqr3Ts8vj05OD
l3uiJezQm5HiFkYDshxBGYgiY8BfnX3ZMk+fnelHTzRnRiqtqAGpIDz6AmlS
odzUcpavAUT5E+bcUv6xhoKcM0xu1i6aEvQEJ4QVgYeyx4xsOWZcA7kSMyId
gJkMztsRLu7ggpyO2gm0RaBrY5qC5QIEVUaJJ+VTyjwWSYbim4spvWxuFRbT
5CsXEVVtA1CCFyH7xhrwgsj/xWenlN/1+XS68/lUqm+gc4RK3vz8euNPuGo1
I4zq6T/7sJrZd4YZAH77VSPRDJb79Q9FunXCR+vwRy/Q5z9/dveRSL+3uDPD
N/3iW9b4q466tfj6rzfRRzuBX3gmReTPv/AxJ9zSgQGu1EFfrLq6gTiuhRCE
FWfNheG6g1TvJNtT6AyVh1hVXzqYNYZ+z2zbkyLKxvSI0sJQa5GdmG+CFEnE
EAGiqEby0huLrCJVCNzBuEQTNyuHMgopwZwpt3mK6I0LIBl2iaqOnFMwt9Ng
aFRAuQograxLv+U0AkaLnN2Bbk/fD9YqyXmPP3/4ORIgZRDSvehzPuUSXr6f
CqvIu/ZIrUEosVVjMRPh2rXUUGTv791EeErg2MWZZWMqKpvXdh/J6Ifvf/j+
9OzoBMng4vXRvA8XLfU9A2XY8mGbxsPMIsVMv7FMLECRr1QACUcuJSJbIjGW
EKiZ/fgjASCRFzEr7Liyog8d0NkBpQOJVfiw2VUEFJ9WdC6P5iqRjYUvS7+h
I+ETtFVKPZrhVcBny5vTE9q/a2doV5SNtiyYC7lATKgYiG3p/RV1AkAzs05T
GzT1omygkkX0cdlQZZmCJ0yFuUypc0qEUTNZtflVOpq2EkZipT4CRD1ghVko
9ViETv7+uaVJAp0/ws/NDuFmo0LnEO+F3qbkwwtHtYa85hOlu9VNHJ/1bGfo
CWinG70FRPxspo8FbSIeLJZbW4RE4slwul3zgp0ouzZlaztyRISYBV3caEMG
WkSnUIv1jjICuB384qgFaOsiHYXIYghjn16RTosOS/wiGeHuY2b08mkX08g+
SAKZya86U0Fwx57fQWHfFkDbpcvvMMoCnU1nkdqP47LfhMOJgB6/ZpT9v0cf
SFdfSARPhMQMBGcjDMwtayz5ba6CjXpuOu7XQHhk1uAiDz9Sx556V+FBg1mV
dB7cgxcFpzLgXQAg+bddr30TdwjyTktMBw49lVaLFoRpt22WdEtNRGYhhfNs
SxNSDoDZN0QFdcp0NNahBXRklzPbkIyB5CngSOUoSPOV8kef+o5PEpZpDld0
jHI2OoEi9zcf6gptn1gMtaaEB9AN1lYfkLoPIMYBPvr8XN/v4Ft4y24l/CJZ
6CkXSmSqR4+/mD3EP4/2CXO/fSIkfn1+3M+YSJPR4wdFHaaC1PtkF+J9BDN6
ZcrnpmrGww7YCtmkd5eYkpYKhHcmEVKGBm/tC+2u7Tvkd7uBgXNxdEe8U0ai
kVyXoxk/qaIJdJUMSAKjtA7kKm64iCdUlOJ3MFR4VoHyBhEIhkqqOwQvGhNY
UyhKH2vUJp4OLdo6CdZVgKWN5A1qLSciimDnVqkdCElqrNCW+OTtGj4W+NNE
Vdp3CnSEwmh/drcimSlvUA9zT79ZbUnwb9h+QPMQb+PxAzm/DYEF7zvs2tdT
0nmYSAwijjrl3aFJmuZcpOzyBNupNCVZm7bccpXrByM96Giy9Wbl0ECYZtky
N6g8T3FG7U657RoeRohtKpa2NFv2Y2rwxGKDcmpEoorGbCg5UmBOKf63MOvP
rWvseCQSk9krcmGkxo01jnYpBbYbXFDJGCaUqX6SaxvKAdhFQoOdbqKZ6adM
LdEMhjjhTbDBbp6djOWorU39K/DdjVgIlTcGj9fO8EZ3DBuFIIEDL21txYSm
RJgUW052w56yBw/yqUM9ODumKLlhoxqRF7dry2bf4RzpIJowMX/jwJGDsG1G
+T5yOafDbhhizLZlpiN53oVBamzCzBpVG1Ujel+MpaMRXS3zgsoWFE0IeE7A
+r6dLWcTfXJwGfbTfMVsaMYg8Yd9d/XYGQFREUGAShuAIyC9uCakOSxe7w7q
zFp4cSljhNQZ7QiZnwuhCF2yQpmhRSDzVUhzD3IknjmqGL2PyXCMYwVX5Ffl
luc9Et+J5yHGX3kqCUzpUIvWnnKupL7eEl0wrrtIJPlAM6Gs2n0WYptN2zVA
X9gPHyZpxR9H8j4zKsLK+TmjpQttgbrZqi5dU2hh27CBvJbmVi35ekLGxsoy
0Ug84HDgNFMlB4+iWhJQoEkpswQ2q1TeYxm/oBBsOMcjpSDXLRYub8tINcu3
yxWDFTTGw9MIiH2ydaKfSrS4FMzX4+BkcPSjE5oedwuoCg7EkCo63yZAk9BW
MBUbNN08ZP7dANI37vmxbnwLGAOsPF8F079SbS0NZRJEiAtlFJ5VkYbABDDv
Sxktla7CnygVWQsERVeWXBTWpomkuGkQLxC9coTsmVTWdHUA1cl5pucpNlE0
4hmV+YludVIOnZOb+opTUnz3k9tU2l8iSVdUGy2LwqmM+65RrzlYijtUuVyS
gTOcIRdJvm1G6XVNF1EkbGZzQ9J2lGJDmvIh6d6H1BlIKI+577itkIF4GxS9
33UDyQBc+AkMyF00OpV+gNgX3hRHpIsyqGqYIFJHyZc/HmndhDbVloasAJ0H
REnC4nk51U1IQS5vkE+QWDhWQEcab5BXAXZbF5SHEsagFRAcxIgm3tFvv7E8
Sk3S6I+TRu1Koz9SGurR7xEHQFKPW91xLZPm0E+T3+hVnlRw2KJYpua9zyWa
56hAnhfOEWhH5uzq/qH/+2f7E/YONcPgt8AkFfwGgoPEOd+G9Gy4ugKRCm2G
kIgIMjVc5WHFGqLZ0ZVL1gu50wcxvKR7QqeAIFKmv/PaxdatS5oJD6E6OUkW
2gycShprvfUtXxdwhuJblNHAQm7beuh1lT3bqtG4h5xEpDEdPdMnaIHmPc9e
OFuO2qJyy0Po4bTQOYxqh0WysGHX1yu/SbmZ2PxMdz2j4p7x6z4Q+7aDDOgI
nSq1temiNtESahFFebmhleBXd9/s7bghtTHcVAg59xdKbAuxBhbf1etuSMNt
mAhSyrFJogyCN5SkK+TOKBGjnCSHflh3q7sm+Iz76zva6rq7XBpQPahBk8mh
TV037trkW6pFyHBhLm0uJwOeLdKltswB5ejKZ1RWhYGQf6jyHHTQ6EwbyGWd
uGo8ypQLEnrpaXqnc9xM6+Na0IZeXi5W+fhPgiK6QsSW0MEZk9jdmsiPhCld
04kkoxFAuoqhnMOTN3HxXTGSJqXsra75EYN02SbJkayVJptkSaFPmSmpEQEu
ljRkE3djBxqycRPgs4gH3I2q7nrwRqLo7khL5IJSbo/RZVHFRdd9ZZY22abv
bn1OszCVZi7QXopvgikg5ZY8tomrhinHoPitGZriGaCz6Ubv+ODk4FYG3b15
JN1rLyuNtJ/0Lv8PDgRW2uYgJw5R2mJJrwT1fi4Nki3+sQdUB7v3AdueHp5i
h26lnan/ASKkrn2bJAAA

-->

</rfc>
