draft-ietf-dnsop-qdcount-is-one-04.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-qdcount-is-one-04" category="std" consensus="true" submissionType="IETF" updates="1035" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <front>
    <title>In the DNS, QDCOUNT is (usually) One</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-qdcount-is-one-04"/>
    <author initials="R." surname="Bellis" fullname="Ray Bellis">
      <organization abbrev="ISC">Internet Systems Consortium, Inc.</organization>
      <address>
        <postal>
          <street>PO Box 360</street>
          <city>Newmarket</city>
          <code>NH 03857</code>
          <country>US</country>
        </postal>
        <phone>+1 650 423 1300</phone>
        <email>ray@isc.org</email>
      </address>
    </author>
    <author initials="J." surname="Abley" fullname="Joe Abley">
      <organization>Cloudflare</organization>
      <address>
        <postal>
          <city>Amsterdam</city>
          <country>NL</country>
        </postal>
        <phone>+31 6 45 56 36 34</phone>
        <email>jabley@cloudflare.com</email>
      </address>
    </author>
    <date year="2024" month="June" day="22"/>
    <area>Internet</area>
    <workgroup>DNSOP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 40?>

<t>This document updates RFC 1035 by constraining the allowed value of the
QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum
of one, and specifies the required behaviour when values that are not
allowed are encountered.</t>
    </abstract>
  </front>
  <middle>
    <?line 47?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The DNS protocol <xref target="RFC1034"/><xref target="RFC1035"/> includes a parameter
QDCOUNT in the DNS message header, whose value is specified to mean
the number of questions in the Question Section of a DNS message.</t>
      <t>In a general sense it seems perfectly plausible for the QDCOUNT
parameter, an unsigned 16-bit value, to take a considerable range
of values. However, in the specific case of messages that encode
DNS queries and responses (messages with OPCODE = 0) there are other
limitations inherent in the protocol that constrain values of QDCOUNT
to be either 0 or 1. In particular, several parameters specified
for DNS response messages such as AA and RCODE have no defined
meaning when the message contains multiple queries, since there is
no way to signal which question those parameters relate to.</t>
      <t>In this document we briefly survey the existing written DNS
specification; we provide a description of the semantic and practical
requirements for DNS queries that naturally constrain the allowable
values of QDCOUNT; and we update the DNS base specification to
clarify the allowable values of the QDCODE parameter in the specific
case of DNS messages with OPCODE = 0.</t>
    </section>
    <section anchor="terminology-used-in-this-document">
      <name>Terminology used in this document</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 anchor="qdcount-is-usually-one">
      <name>QDCOUNT is (usually) One</name>
      <t>A brief summary of the guidance provided in the existing DNS
specification (<xref target="RFC1035"/> and many other documents) for the use
of QDCOUNT can be found in <xref target="Survey"/>.  While the specification is
clear in many cases, in the specific case of OPCODE = 0 there is
some ambiguity which this document aims to eliminate.</t>
    </section>
    <section anchor="updates-to-rfc-1035">
      <name>Updates to RFC 1035</name>
      <t>A DNS message with OPCODE = 0 MUST NOT include a QDCOUNT parameter
whose value is greater than 1. It follows that the Question Section
of a DNS message with OPCODE = 0 MUST NOT contain more than one
question.</t>
      <t>A DNS message with OPCODE = 0 and QDCOUNT &gt; 1 MUST be treated as
an incorrectly-formatted message.  The value of the RCODE parameter
in the response message MUST be set to 1 (FORMERR).</t>
      <t>Middleboxes (e.g. firewalls) that process DNS messages in order
to eliminate unwanted traffic SHOULD treat messages with OPCODE =
0 and QDCOUNT &gt; 1 as malformed traffic and return a FORMERR response
as described above.  Such firewalls MUST NOT treat messages with
OPCODE = 0 and QDCOUNT = 0 as malformed.  See Section 4 of <xref target="RFC8906"/>
for further guidance.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document clarifies the DNS specification and aims to improve
interoperability between different DNS implementations. In general,
the elimination of ambiguity seems well-aligned with security
hygiene.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The clarifications in this document were prompted by questions posed
by Ted Lemon, which reminded the authors of earlier, similar questions
and motivated them to pick up their pens. Ondrej Sury, Warren Kumari,
Peter Thomassen, Mark Andrews, Lars-Johan Liman, Jim Reid and Niall
O'Reilly provided useful feedback.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
          <front>
            <title>Domain names - concepts and facilities</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1034"/>
          <seriesInfo name="DOI" value="10.17487/RFC1034"/>
        </reference>
        <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
          <front>
            <title>Domain names - implementation and specification</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <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" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <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="RFC3425" target="https://www.rfc-editor.org/info/rfc3425" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3425.xml">
          <front>
            <title>Obsoleting IQUERY</title>
            <author fullname="D. Lawrence" initials="D." surname="Lawrence"/>
            <date month="November" year="2002"/>
            <abstract>
              <t>The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3425"/>
          <seriesInfo name="DOI" value="10.17487/RFC3425"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC8906" target="https://www.rfc-editor.org/info/rfc8906" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8906.xml">
          <front>
            <title>A Common Operational Problem in DNS Servers: Failure to Communicate</title>
            <author fullname="M. Andrews" initials="M." surname="Andrews"/>
            <author fullname="R. Bellis" initials="R." surname="Bellis"/>
            <date month="September" year="2020"/>
            <abstract>
              <t>The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.</t>
              <t>This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.</t>
              <t>The document does not look at the DNS data itself, just the structure of the responses.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="231"/>
          <seriesInfo name="RFC" value="8906"/>
          <seriesInfo name="DOI" value="10.17487/RFC8906"/>
        </reference>
        <reference anchor="RFC7873" target="https://www.rfc-editor.org/info/rfc7873" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml">
          <front>
            <title>Domain Name System (DNS) Cookies</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="M. Andrews" initials="M." surname="Andrews"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7873"/>
          <seriesInfo name="DOI" value="10.17487/RFC7873"/>
        </reference>
        <reference anchor="RFC5936" target="https://www.rfc-editor.org/info/rfc5936" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml">
          <front>
            <title>DNS Zone Transfer Protocol (AXFR)</title>
            <author fullname="E. Lewis" initials="E." surname="Lewis"/>
            <author fullname="A. Hoenes" initials="A." role="editor" surname="Hoenes"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.</t>
              <t>The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5936"/>
          <seriesInfo name="DOI" value="10.17487/RFC5936"/>
        </reference>
        <reference anchor="RFC1996" target="https://www.rfc-editor.org/info/rfc1996" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml">
          <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" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml">
          <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="RFC8490" target="https://www.rfc-editor.org/info/rfc8490" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8490.xml">
          <front>
            <title>DNS Stateful Operations</title>
            <author fullname="R. Bellis" initials="R." surname="Bellis"/>
            <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
            <author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
            <author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
            <author fullname="T. Lemon" initials="T." surname="Lemon"/>
            <author fullname="T. Pusateri" initials="T." surname="Pusateri"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8490"/>
          <seriesInfo name="DOI" value="10.17487/RFC8490"/>
        </reference>
      </references>
    </references>
    <?line 125?>

<section anchor="Survey">
      <name>Guidance for the use of QDCOUNT in the DNS Specification</name>
      <t>The DNS Specification provides some guidance about the values of
QDCOUNT that are appropriate in various situations. A brief summary
of this guidance is collated below.</t>
      <section anchor="opcode-0-query-and-1-iquery">
        <name>OPCODE = 0 (QUERY) and 1 (IQUERY)</name>
        <t><xref target="RFC1035"/> significantly predates the use of the normative
requirements keywords specified in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>,
and parts of it are consequently somewhat open to interpretation.</t>
        <t>Section 4.1.2 ("Question section format") has this to say about
QDCOUNT:</t>
        <ul empty="true">
          <li>
            <t>The section contains QDCOUNT (usually 1) entries</t>
          </li>
        </ul>
        <t>The only documented exceptions within <xref target="RFC1035"/> relate to the IQuery
Opcode, where the request has "an empty question section" (QDCOUNT = 0),
and the response has "zero, one, or multiple domain names for the
specified resource as QNAMEs in the question section". The IQuery OpCode
was made obsolete in <xref target="RFC3425"/>.</t>
        <t>In the absence of clearly expressed normative requirements, we rely
on other text in <xref target="RFC1035"/> that makes use of the definite article
or other text that implies a singular question and, by implication,
QDCOUNT = 1.</t>
        <t>For example, Section 4.1:</t>
        <ul empty="true">
          <li>
            <t>the question for the name server</t>
          </li>
        </ul>
        <t>and:</t>
        <ul empty="true">
          <li>
            <t>The question section contains fields that describe a question to a
name server</t>
          </li>
        </ul>
        <t>and in Section 4.1.1. ("Header section format"):</t>
        <ul empty="true">
          <li>
            <t>AA Authoritative Answer - this bit is valid in responses,
   and specifies that the responding name server is an
   authority for the domain name in question section.</t>
          </li>
        </ul>
        <t>DNS Cookies <xref target="RFC7873"/> in Section 5.4 allow a client to receive
a valid Server Cookie without sending a specific question by sending
a request (QR = 0) with OPCODE = 0 and QDCOUNT = 0, with the resulting
response also containing no question.</t>
        <t>DNS Zone Transfer Protocol (AXFR) <xref target="RFC5936"/> in Section 2.2 allows
an authoritative server optionally to send a response message
(QR = 1) to a standard AXFR query (OPCODE = 0, QTYPE=252) with
QDCOUNT = 0 in the second or subsequent message of a multi-message
response.</t>
      </section>
      <section anchor="opcode-4-notify">
        <name>OPCODE = 4 (NOTIFY)</name>
        <t>DNS Notify <xref target="RFC1996"/> also lacks a clearly defined range of values
for QDCOUNT.  Section 3.7 says:</t>
        <ul empty="true">
          <li>
            <t>A NOTIFY request has QDCOUNT &gt; 0</t>
          </li>
        </ul>
        <t>but all other text in the RFC talks about the &lt;QNAME, QCLASS, QTYPE&gt;
tuple in the singular.</t>
      </section>
      <section anchor="opcode-5-update">
        <name>OPCODE = 5 (UPDATE)</name>
        <t>DNS Update <xref target="RFC2136"/> renames the QDCOUNT field to ZOCOUNT, but
the value is constrained to be one by Section 2.3 ("Zone Section"):</t>
        <ul empty="true">
          <li>
            <t>All records to be updated must be in the same zone, and therefore the
Zone Section is allowed to contain exactly one record.</t>
          </li>
        </ul>
      </section>
      <section anchor="opcode-6-dns-stateful-operations-dso">
        <name>OPCODE = 6 (DNS Stateful Operations, DSO)</name>
        <t>DNS Stateful Operations <xref target="RFC8490"/> (DSO - OpCode 6) attempts to
preserve compatibility with the standard DNS 12 octet header, and
does so by requiring that all four of the section count values be
set to zero.</t>
      </section>
      <section anchor="conclusion">
        <name>Conclusion</name>
        <t>There is no text in <xref target="RFC1035"/> that describes how other parameters
in the DNS message such as AA, RCODE should be interpreted in the
case where a message includes more than one question. An originator
of a query with QDCOUNT &gt; 1 can have no expectations of how it will
be processed, and the receiver of a response with QDCOUNT &gt; 1 has
no guidance for how it should be interpreted.</t>
        <t>The allowable values of QDCOUNT seem to be clearly specified for
OPCODE = 4 (NOTIFY), OPCODE = 5 (UPDATE) and OPCODE = 6 (DNS Stateful
Operations, DSO). OPCODE = 1 (IQUERY) is obsolete and OPCODE = 2
(STATUS) is not specified. OPCODE = 3 is reserved.</t>
        <t>However, the allowable values of QDCOUNT for OPCODE = 0 (QUERY) are
specified in <xref target="RFC1035"/> without the clarity of normative language,
and this looseness of language results in some ambiguity.</t>
      </section>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA41Z23IbNxJ9x1dglYelakmWqJtjZXNhJDm2VxJlUaps8gbO
gCSiuXkwI4px6V/yLfmyPd0AZoaUlOyDy5wb0H369OluaDAYiMpUiT6RHzJZ
LbU8u5r25aez08nd1a00VvZqW6skWe/KSaZFnEeZSvF2XKp5NTC6mg/izObF
4HMc5XWGW3aQZ3qwdyjqIlaVtidytHdwJIStZ6mx1uRZtS5ov/Pbd8IU5Yms
ytpW+3t7b/f2hSq1IlsqXWa6EqvFCVk0uZY/5+W9yRbypzKvC3G/al8anJEt
IlLVibRVLESUx3jzRNZ2oGxkjCjMiZByIKs84v/tOi313LrfeVnxhVB1tcxL
fhP/pDQZbL8Zyh91khjLt5zvN2rdvZmXi9YYOV3bSqdWnuYZLW3qtI+H0ZBf
VbNZqR/w9vSUry221jD7eiJ/zB/lwfEe345MtT6RV3qVqvIeKPC9PMbWV+/l
3sHXR2/8LQBe4s27KV8XSyB/Iv81ksdHe/Jw/0CODvbcijpVJjmRpVr/YGw0
hMmbbn4cyvEs0euOlx9z3bnHTp4meR3PE8SoY+Y4hcNlrNJNm64uNmw6gFHy
8EgeHcNLeXDYteo3Rdv8EDWrD6M8FWIwGAAwQKSiSojbJcgI+tWpzirpuSVv
3p0yveRsja0zetlkRBOiMmibr3QsH1RSa5nP6aYI1C5UCTdhOQAgislUW6sW
WHNlqqWcXJ9Ozs7lt3JP9j7dnd/8sgv2SCVT9WjSOhVYDY71pcpiaQsdmbnB
p7RrqT/XpsS2M71UDyavS7la6sxZQa+oSsJHmeWVCBbStc4YO41Ph8751MRx
ooX4ithV5nEdVcgegoLTVBZlDkbnifzy5R8AAjgcPj01v4+enuBalNQxdlWt
vw0Cpkn44LtcahXrsg+Dc6s9boA9OBgTBqlWmaAPszqdAT4g8RmOkWk2rPnJ
35BTzTbTS6q7EzyE3ii50JkuVSKtzrChqfCDkqfQ5RxfJmtZJKq2BvyQ87x0
azvzReMQBUHWmTWLDBaOjgczrMO298neSt2DCswOA+eIa8iDbKEphi4oQ/ke
YXigpbwD3uNIRsoydRp2cPwoVrEW5BB8Lyn0RIRS2wLb4Kr3Gpt2aXlEmyKe
00+RmNRUKsBHD8Fvb0YTYd61IXjgEuwKaMDRGThkaElwFliNhiTpQKkyUY2s
6gPbBwa7Qa4TWUHwkj/Bh9ZjW0dLqawcj9nJG3YF1CYKy1jPDWAXxArKO6Y6
mR4oBaMrmGxlWieVKQC+Rwz2gJ7a4wEtxWorKCs8oVDCztXSYOdALrxIpOwY
X+oEIoAPHJuqDYVYaTnDNnNwyNblg16zVfrRYDGyszRVpTnzRQg2B+Eb+hK4
P4AsoA2SJypNEUjM3IBsZQCV0ShInfBpInze0+ZWBjQDOzh+marqkmppJ5KN
ThEvxbO4fsObwCIneE3CzoiWG3YDBhEhzGa+3ly0Q5aQPojfhvx1GS8C4/9K
E4ckSre6TE2WJ/lijVKL1DNbMXBKdQ/oV3kZW7lzeTe93em7/+XVhH/fnH+6
+3Bzfka/p+/HFxfND/eGwMXk7sI/p1/tl6eTy8vzqzP3Me7KrVuX41+wACG4
M7m+/TC5Gl/sPLOSU9GljyH5LUrAEhPhXexnYDe++fH0Wo4OvdTuj0ZvIa/u
4uvRG+guM9/VgzxDiN0lkF1LVRRalbQIggJFKZDvCfiPLewyX2WSMoAhfbXv
EmPHZnA5RVOwDtFc1CZWlEWesXEIZ0P0ZwSXvY0SQQaDz2unRg0qdrcRXMRW
tIyE/RlhNUex4t2+fJlyfj09DaX8eWkSvcEntyfSO0oAAn3AuxHL7Oty2ym/
jT7YPAWt05mB09Xaq8NWKA2KB2KpSVSRbg7VO98s4EHoFwjQbuHbrvmBoaGC
QgmeNQ5iq0ou0LpSQiHXM1bfCiBRFvr0f6kwiu3C+LolXkhlmhNfaQ80ICKo
4/DvPKI4Bxe+kyO3LuJYsdXEdyQKuZuXJZfeAeKfqoqehaItJSV0t53y1aDF
xAd0u4o021m0yIjDSPbeTW4uz29udmH5JTc6s/yRKqceLoZyDiVdgf5212EH
ekdYaVOUsBd0BZt2I45OYAV5pl4FYwFxyqsGO/qKoonn+CA5U5UQBp2lXJGH
ilPv4h1ofBVdyUDnmj8QYlOqno07bThfMEe8Ei6+7phDq2rd9FaHFIsvX74n
KXq7d/z0xLV8Xpec0EEhOBPwSV1S8pyGboj7ju3u2tWR0NAS5pvZTMaFVDMp
SY8WrJ15QQ2WSWiLma5WGhU2NvO5a2poIbyecI10O3OP4pvAPneVIZCha2zy
3XWGK8xdA5W4Xo9jaL1PYrleGKxEjv75x4fx1fhvvFwCU/Qc/KaKnDkE0ji6
z/JVouOFK+aujHlMItVpdDf7jZJVOC2IexhH2qa4gEzEArdu8eRCp3nW9+qF
dsFkpNpcsXn+5EINpUwMtaMWYGDjdjGuZmlemQfOWnyXUhQKE92jR6BrU6J9
JmQnWVzq30DAct2XPyukdSb/U6N6mL645tJ/u8xTZS0VqktMmnJMX6wgyxeq
tIOPOYnMhYFe9+VHk8obbWKO/ZUBl8Xkn7hB3UxTe1Ap5nUi51rHMxXd+zGG
fhKuP4Va1SksnVanO49MN+j25StfYdrRZ/MFbwDKKZWIpiYiBWsnu00L1Aw/
zRiG4gzaloakgzvrEiMbVjJVHSi6VXsFSx8JftgIv9GkJxyRmYbiE4++emmG
JPSgfR/cpRAbpZjaXnYq48kHg6ArWy1UPHaxLBuk3EbHiTbLdVntsPZ/dC2u
O6IhgXlnHCbUnmJtzXYQpitCC8mdccaHLkn5wtMI0XA03Je9nabIWf/AVZKd
XU45ho6afPT6HKEQkxMhvuMCEz5rRocQtNATydEuRrCKOmtHCe64QirCc/0Y
6cIlH2kEdykdoJvBgQH9AHsR1UlBMx1lpi51M8nDE7Z6B6mgkdttXgczdxDc
Vqh3HaIbNZC//x3q2HdnBqB/MwzFyECYR0cuNiSGaEOINfK6JC4Dhavx5Xkz
Yj8zY8jYOWfkpDilAXXFZQPtSz6zeaIdxR0UB4f7gCJMTpQs0IGIWcadGgDV
j4iypc6+4Zzscq5PgwmwREZkvn2s9GMlt+HmXEsxhtsuj3lyNBWNwhigMPzA
+c4i/BFVCx6uaVZc1F0lpFTqk87yO04I+qKNxAiuvcOS+lFRyenLDkuZaRsg
BkmiOABRqE0pKJANJ7fhbsmJOCWxb/FC+YfB7diaS4VFtlcmlLqJg4axt/Oe
z1+e5Q1bgfF7zBWCTwsQinFmUXToWJMyig498B+UzvDazVlEH9/S0ePWQZVv
SN1rdF7atZBWUpn/0G+6bkDqcJZ22oYGwJNEn+b5PW3lOpM3X7854AOpxumj
4aEbUulwBlHOuDFE76lJ25T3ZOrscYtxMpOmg6pssmonh8aK2To8xiIhhXuf
btzpy1+1xbjuuxc8MpSkWKZJZExteQg8I5bLTv9NTv+KBJe3pcoseh55HY5v
euP/vrvZ9VAcvT043oRiH7LJUHAPrjai7AOSs5yx+JF2aurAnnXZwrk58meV
toJ3qowl7c5HEWvZa33vy0+3v1yff7t/tO9wEd2GM0xmGv7GJFm2nvmi0DT1
PLywlA2CBcGkrQp4KHtoej+8o5pHOF2hg5mvPSCjt28JEEY3QbNgmRFOg/z5
kjuxk82JHbe43lxuhx2QB8M3VFesSxjpttzQ8bbF3xNiBirRSL6pXTzWYE7E
kE6mNE3Ev1mAgdrpxXg69eh9J6qadDzA5WWK3f/zj8b/I9m7uz4b3557/91I
6v3fHzEh0J9xFegccjpxoWj+OuEbUDwUzKalcZ2HP0tyx7MzqoaasqBl1wGk
hZnpbwVFgevIN+4a3JfulAkNZg24Zq1XlOm/N+fdPJHP3RiqsU53aVYOf6pd
NclCKszHufSm23KLIMeyx30dWM895KQIbXtfnk0nHrYXHofJ5/DtHjDs4V0o
oit/8hgNFwZYlG1yUFA1o2yCVWmBr/2g0mR8ky+01Whf5lGFaTWcieOZiHNu
MgldVwjdnxqUo9GczvqbQ8JQJuqsCv3nDKXdzb/UDTgEMKNESW3DwT4fdZCw
vF5JQ5GxcgnxdNxtT0WFeX6s357g9v3AbiGjSbx95uU+dSeArg1SzRrNnxI2
zh9a/UM5gkqYBc1ueenONZzkML7d0ZpOkML5MXoMIOVDiY/IJVSyFQYLMdNh
7tdxw7xQIUqnPo0EPtsF2U5Hyovu1OFXf9H7oWslXzo3DcvSCOozJehT26ph
ffGC3vXlCyLAzrzGfbHN/WH7ajs7EE2arm5juX3Rm96Ob++mu45KVWtkZ6UD
eugTgnxv/gLy2uFxI0nA8aXJpuz2rUzc71vihsJdhUm64iPMtq9MoO81eBba
ZxiX5JibMzr1wZvhuS/L3AZvHgjCh/8ByJ+cu84eAAA=

-->

</rfc>