<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.11 --> version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dprive-dnsoquic-12" category="std"> docName="draft-ietf-dprive-dnsoquic-11" category="std" obsoletes="" number="9250" updates="" submissionType="IETF" xml:lang="en" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="DNS over Dedicated QUIC">DNS over Dedicated QUIC Connections</title>
    <seriesInfo name="RFC" value="9250"/>
    <author initials="C." initials="C" surname="Huitema" fullname="Christian Huitema">
      <organization>Private Octopus Inc.</organization>
      <address>
        <postal>
          <street>427 Golfcourse Rd</street>
          <city>Friday Harbor</city>
          <code>WA 98250</code>
          <country>USA</country>
        </postal>
        <email>huitema@huitema.net</email>
      </address>
    </author>
    <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
      <organization>Sinodun IT</organization>
      <address>
        <postal>
          <street>Oxford Science Park</street>
          <city>Oxford</city>
          <code>OX4 4GA</code>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>sara@sinodun.com</email>
      </address>
    </author>
    <author initials="A." surname="Mankin" fullname="Allison Mankin">
      <organization>Salesforce</organization>
      <address>
        <email>allison.mankin@gmail.com</email>
      </address>
    </author>
    <date year="2022" month="April" day="20"/>

    <area>Transport</area>

    <keyword>Internet-Draft</keyword> month="May"/>
    <area>Internet</area>
    <workgroup>DNS PRIVate Exchange</workgroup>

<keyword>DNS</keyword>
<keyword>QUIC</keyword>
<keyword>DNS over QUIC</keyword>
<keyword>Encrypted DNS</keyword>
<keyword>DoQ</keyword>

    <abstract>
      <t>This document describes the use of QUIC to provide transport confidentiality for DNS.
The encryption provided by QUIC has similar properties to those provided by TLS,
while QUIC transport eliminates the head-of-line blocking issues inherent with
TCP and provides more efficient packet loss packet-loss recovery than UDP. DNS over QUIC
(DoQ) has privacy properties similar to DNS over TLS (DoT) specified in
RFC7858,
RFC 7858, and latency characteristics similar to classic DNS over UDP. This
specification describes the use of DNS over QUIC DoQ as a general-purpose transport
for DNS and includes the use of DNS over QUIC DoQ for stub to recursive,
recursive to authoritative, and zone transfer scenarios.</t>
    </abstract>

  </front>

  <middle>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Domain Name System (DNS) concepts are specified in &quot;Domain "Domain names - concepts and
facilities&quot;
facilities" <xref target="RFC1034"/>. target="RFC1034" format="default"/>. The transmission of DNS queries and responses over
UDP and TCP is specified in &quot;Domain "Domain names - implementation and specification&quot; specification"
<xref target="RFC1035"/>.</t> target="RFC1035" format="default"/>.</t>
      <t>This document presents a mapping of the DNS protocol over the
QUIC transport <xref target="RFC9000"/> target="RFC9000" format="default"/> <xref target="RFC9001"/>. target="RFC9001" format="default"/>. DNS over QUIC is referred to here as DoQ,
in line with &quot;DNS Terminology&quot; "DNS Terminology" <xref target="I-D.ietf-dnsop-rfc8499bis"/>.</t> target="I-D.ietf-dnsop-rfc8499bis" format="default"/>.</t>
      <t>The goals of the DoQ mapping are:</t>

<t><list style="numbers">
  <t>Provide
      <ol spacing="normal" type="1"><li>Provide the same DNS privacy protection as DNS over TLS (DoT) DoT
<xref target="RFC7858"/>. target="RFC7858" format="default"/>. This includes an option for the client to
authenticate the server by means of an authentication domain
name as specified in &quot;Usage "Usage Profiles for DNS over TLS and DNS
over DTLS&quot; DTLS" <xref target="RFC8310"/>.</t>
  <t>Provide target="RFC8310" format="default"/>.</li>
        <li>Provide an improved level of source address validation for DNS
servers compared to classic DNS over UDP.</t>
  <t>Provide UDP.</li>
        <li>Provide a transport that does not impose path MTU limitations on the
size of DNS responses it can send.</t>
</list></t> send.</li>
      </ol>
      <t>In order to achieve these goals, and to support ongoing work on encryption of
DNS, the scope of this document includes</t>

<t><list style="symbols">
  <t>the &quot;stub includes:</t>

      <ul spacing="normal">
        <li>the "stub to recursive resolver&quot; scenario</t>
  <t>the &quot;recursive resolver" scenario (also called the "stub to recursive" scenario in this document)</li>
        <li>the "recursive resolver to authoritative nameserver&quot; nameserver" scenario (also called the “recursive to authoritative” scenario and</t>
  <t>the &quot;nameserver in this document), and</li>
        <li>the "nameserver to nameserver&quot; nameserver" scenario (mainly used for zone transfers (XFR) <xref target="RFC1995"/>, target="RFC1995" format="default"/> <xref target="RFC5936"/>).</t>
</list></t> target="RFC5936" format="default"/>).</li>
      </ul>
      <t>In other words, this document specifies QUIC as a general-purpose
transport for DNS.</t>
      <t>The specific non-goals of this document are:</t>

<t><list style="numbers">
  <t>No
      <ol spacing="normal" type="1"><li>No attempt is made to evade potential blocking of DNS over QUIC DoQ
traffic by middleboxes.</t>
  <t>No middleboxes.</li>
        <li>No attempt to support server-initiated transactions, which are used only in
DNS Stateful Operations (DSO) <xref target="RFC8490"/>.</t>
</list></t> target="RFC8490" format="default"/>.</li>
      </ol>
      <t>Specifying the transmission of an application over QUIC requires specifying how
the application&#39;s application's messages are mapped to QUIC streams, and generally how the
application will use QUIC. This is done for HTTP in &quot;Hypertext "Hypertext Transfer
Protocol Version 3 (HTTP/3)&quot;<xref target="I-D.ietf-quic-http"/>. (HTTP/3)" <xref target="I-D.ietf-quic-http" format="default"/>. The purpose of this
document is to define the way DNS messages can be transmitted over QUIC.</t>

<t>DNS over HTTP HTTPS (DoH) <xref target="RFC8484"/> target="RFC8484" format="default"/> can be used with HTTP/3 to get some of the
benefits of QUIC. However, a lightweight direct mapping for DNS over QUIC DoQ can
be regarded as a more natural fit for both the recursive to authoritative and
zone transfer scenarios scenarios, which rarely involve intermediaries. In these
scenarios, the additional overhead of HTTP is not offset by, e.g., for example, benefits of
HTTP proxying and caching behavior.</t>
      <t>In this document, <xref target="design-considerations"/> target="design-considerations" format="default"/> presents the reasoning that guided
the proposed design. <xref target="specifications"/> target="specifications" format="default"/> specifies the actual mapping of DoQ.
<xref target="implementation-requirements"/> target="implementation-requirements" format="default"/> presents guidelines on the implementation,
usage
usage, and deployment of DoQ.</t>
    </section>
    <section anchor="key-words"><name>Key anchor="key-words" numbered="true" toc="default">
      <name>Key Words</name>

<t>The

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

</section>
<section anchor="document-work-via-github"><name>Document work via GitHub</name>

<t>(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)The GitHub
repository for this document is at https://github.com/huitema/dnsoquic.
Proposed text and editorial changes are very much welcomed there, but any
functional changes should always first be discussed on the IETF DPRIVE WG
(dns-privacy) mailing list.</t> here.
        </t>

    </section>

    <section anchor="design-considerations"><name>Design anchor="design-considerations" numbered="true" toc="default">
      <name>Design Considerations</name>
      <t>This section and its subsections present the design guidelines that were used
for DoQ. Whilst While all other sections in this document are normative, this section
is informative in nature.</t>
      <section anchor="provide-dns-privacy"><name>Provide anchor="provide-dns-privacy" numbered="true" toc="default">
        <name>Provide DNS Privacy</name>
        <t>DoT <xref target="RFC7858"/> target="RFC7858" format="default"/> defines how to mitigate some of the issues described in &quot;DNS "DNS
Privacy Considerations&quot; Considerations" <xref target="RFC9076"/> target="RFC9076" format="default"/> by specifying how to transmit DNS messages
over TLS. The &quot;Usage "Usage Profiles for DNS over TLS and DNS over DTLS&quot; DTLS" <xref target="RFC8310"/> target="RFC8310" format="default"/>
specify Strict and Opportunistic Usage Profiles usage profiles for DoT including how stub
resolvers can authenticate recursive resolvers.</t>

<t>QUIC connection setup includes the negotiation of security parameters using
TLS, as specified in &quot;Using "Using TLS to Secure QUIC&quot; QUIC" <xref target="RFC9001"/>, target="RFC9001" format="default"/>,
enabling encryption of the QUIC transport. Transmitting DNS messages over QUIC
will provide essentially the same privacy protections as DoT <xref target="RFC7858"/> target="RFC7858" format="default"/>
including Strict and Opportunistic Usage Profiles usage profiles <xref target="RFC8310"/>. target="RFC8310" format="default"/>. Further
discussion on this is provided in <xref target="privacy-considerations"/>.</t> target="privacy-considerations" format="default"/>.</t>
      </section>
      <section anchor="design-for-minimum-latency"><name>Design anchor="design-for-minimum-latency" numbered="true" toc="default">
        <name>Design for Minimum Latency</name>
        <t>QUIC is specifically designed to reduce protocol-induced delays, with features
such as:</t>

<t><list style="numbers">
  <t>Support
        <ol spacing="normal" type="1"><li>Support for 0-RTT data during session resumption.</t>
  <t>Support resumption.</li>
          <li>Support for advanced packet loss packet-loss recovery procedures as specified in
&quot;QUIC
"QUIC Loss Detection and Congestion Control&quot; Control" <xref target="RFC9002"/>.</t>
  <t>Mitigation target="RFC9002" format="default"/>.</li>
          <li>Mitigation of head-of-line blocking by allowing parallel
delivery of data on multiple streams.</t>
</list></t> streams.</li>
        </ol>
        <t>This mapping of DNS to QUIC will take advantage of these features in
three ways:</t>

<t><list style="numbers">
  <t>Optional
        <ol spacing="normal" type="1"><li>Optional support for sending 0-RTT data during session resumption
(the security and privacy implications of this are discussed
in later sections).</t>
  <t>Long-lived sections).</li>
          <li>Long-lived QUIC connections over which multiple DNS transactions
are performed,
generating the sustained traffic required to benefit from
advanced recovery features.</t>
  <t>Mapping features.</li>
          <li>Mapping of each DNS Query/Response transaction to a separate stream,
to mitigate head-of-line blocking. This enables servers to respond
to queries &quot;out "out of order&quot;. order". It also enables clients to process
responses as soon as they arrive, without having to wait for in
order in-order delivery of responses previously posted by the server.</t>
</list></t> server.</li>
        </ol>
        <t>These considerations are reflected in the mapping of DNS traffic
to QUIC streams in <xref target="stream-mapping-and-usage"/>.</t> target="stream-mapping-and-usage" format="default"/>.</t>
      </section>
      <section anchor="middlebox-considerations"><name>Middlebox anchor="middlebox-considerations" numbered="true" toc="default">
        <name>Middlebox Considerations</name>
        <t>Using QUIC might allow a protocol to disguise its purpose from devices on the
network path using encryption and traffic analysis resistance techniques like
padding, traffic pacing, and traffic shaping. This specification does not
include any measures that are designed to avoid such classification -- classification;
the padding mechanisms defined in <xref target="padding"/> target="padding" format="default"/> are intended to obfuscate the specific
records contained in DNS queries and responses, but not the fact that this is DNS traffic.
Consequently, firewalls and other middleboxes might
be able to distinguish DoQ from other protocols that use QUIC, like HTTP, and
apply different treatment.</t>
        <t>The lack of measures in this specification to avoid protocol classification is
not an endorsement of such practices.</t>
      </section>
      <section anchor="no-server-initiated-transactions"><name>No anchor="no-server-initiated-transactions" numbered="true" toc="default">
        <name>No Server-Initiated Transactions</name>
        <t>As stated in <xref target="introduction"/>, target="introduction" format="default"/>, this document does not specify support for
server-initiated transactions within established DoQ connections. That is, only
the initiator of the DoQ connection may send queries over the connection.</t>
        <t>DSO does support server-initiated transactions within existing connections.
However, DoQ as defined here does not meet the criteria for an applicable
transport for DSO because it does not guarantee in-order delivery of messages, messages;
see <xref section="4.2" sectionFormat="of" target="RFC8490"/>.</t> target="RFC8490" format="default"/>.</t>
      </section>
    </section>
    <section anchor="specifications"><name>Specifications</name> anchor="specifications" numbered="true" toc="default">
      <name>Specifications</name>
      <section anchor="connection-establishment"><name>Connection anchor="connection-establishment" numbered="true" toc="default">
        <name>Connection Establishment</name>
        <t>DoQ connections are established as described in the QUIC transport
specification <xref target="RFC9000"/>. target="RFC9000" format="default"/>. During connection establishment, DoQ support is
indicated by selecting the Application-Layer Protocol Negotiation (ALPN) token &quot;doq&quot; "doq" in the crypto handshake.</t>

        <section anchor="draft-version-identification"><name>Draft Version Identification</name>

<t>(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) Only
implementations of the final, published RFC can identify themselves as &quot;doq&quot;.
Until such an RFC exists, implementations MUST NOT identify themselves using
this string.</t>

<t>Implementations of draft versions of the protocol MUST add the string &quot;-&quot; and
the corresponding draft number to the identifier. For example,
draft-ietf-dprive-dnsoquic-00 is identified using the string &quot;doq-i00&quot;.</t>

</section>
<section anchor="port-selection"><name>Port anchor="port-selection" numbered="true" toc="default">
          <name>Port Selection</name>
          <t>By default, a DNS server that supports DoQ MUST <bcp14>MUST</bcp14> listen for and accept QUIC
connections on the dedicated UDP port TBD (number to be defined in
<xref target="iana-considerations"/>), 853 (<xref target="iana-considerations" format="default"/>), unless there is a mutual agreement to
use another port.</t>
          <t>By default, a DNS client desiring to use DoQ with a particular server MUST <bcp14>MUST</bcp14>
establish a QUIC connection to UDP port TBD 853 on the server, unless there is a
mutual agreement to use another port.</t>
          <t>DoQ connections MUST NOT <bcp14>MUST NOT</bcp14> use UDP port 53. This recommendation against use of
port 53 for DoQ is to avoid confusion between DoQ and the use of DNS over UDP
<xref target="RFC1035"/>. target="RFC1035" format="default"/>. The risk of confusion exists even if two parties agreed on
port 53, as other parties without knowledge of that agreement might still
try to use that port.</t>

<t>In the stub to recursive scenario, the use of port 443 as a mutually agreed
alternative port can be operationally beneficial, since port 443 is
used by many services using QUIC and HTTP-3 and is thus less likely
to be blocked than other ports. Several mechanisms for stubs to discover
recursives offering encrypted transports, including the use of custom ports, are
the subject of ongoing work.</t>
        </section>
      </section>

      <section anchor="stream-mapping-and-usage"><name>Stream anchor="stream-mapping-and-usage" numbered="true" toc="default">
        <name>Stream Mapping and Usage</name>
        <t>The mapping of DNS traffic over QUIC streams takes advantage of the QUIC stream
features detailed in <xref section="2" sectionFormat="of" target="RFC9000"/>, target="RFC9000" format="default"/>, the QUIC transport specification.</t>
        <t>DNS query/response traffic <xref target="RFC1034"/>, target="RFC1034" format="default"/> <xref target="RFC1035"/> target="RFC1035" format="default"/>
follows a simple pattern in which the client sends a query, and the
server provides one or more responses (multiple responses can occur in zone
transfers).</t>
        <t>The mapping specified here requires that the client selects select a separate QUIC
stream for each query. The server then uses the same stream to provide all the
response messages for that query. In order that for multiple responses can to be
parsed, a 2-octet length field is used in exactly the same way as the 2-octet
length field defined for DNS over TCP <xref target="RFC1035"/>. target="RFC1035" format="default"/>. The practical result of this
is that the content of each QUIC stream is exactly the same as the content of a
TCP connection that would manage exactly one query.</t>
        <t>All DNS messages (queries and responses) sent over DoQ connections MUST <bcp14>MUST</bcp14> be
encoded as a 2-octet length field followed by the message content as specified
in <xref target="RFC1035"/>.</t> target="RFC1035" format="default"/>.</t>
        <t>The client MUST <bcp14>MUST</bcp14> select the next available client-initiated bidirectional stream
for each subsequent query on a QUIC connection, in conformance with the QUIC
transport specification <xref target="RFC9000"/>. target="RFC9000" format="default"/>. Packet losses and other network events might
cause queries to arrive in a different order. Servers SHOULD <bcp14>SHOULD</bcp14> process queries
as they arrive, as not doing so would cause unnecessary delays.</t>
        <t>The client MUST <bcp14>MUST</bcp14> send the DNS query over the selected stream, stream and MUST <bcp14>MUST</bcp14> indicate
through the STREAM FIN mechanism that no further data will be sent on that
stream.</t>
        <t>The server MUST <bcp14>MUST</bcp14> send the response(s) on the same stream and MUST <bcp14>MUST</bcp14> indicate, after
the last response, through the STREAM FIN mechanism that no further data will be
sent on that stream.</t>
        <t>Therefore, a single DNS transaction consumes a single bidirectional client-initiated stream.
This means that the client&#39;s client's first query occurs on QUIC stream 0, the second on
4, and so on (see <xref section="2.1" sectionFormat="of" target="RFC9000"/>.</t> target="RFC9000" format="default"/>).</t>
        <t>Servers MAY <bcp14>MAY</bcp14> defer processing of a query until the STREAM FIN has been indicated
on the stream selected by the client.</t>
        <t>Servers and clients MAY <bcp14>MAY</bcp14> monitor the number
of &quot;dangling&quot; "dangling" streams. These are open streams where the following events have not
occurred after implementation defined implementation-defined timeouts:</t>

<t><list style="symbols">
  <t>the
        <ul spacing="normal">
          <li>the expected queries or responses have not been received or,</t>
  <t>the or,</li>
          <li>the expected queries or responses have been received but not the STREAM FIN</t>
</list></t> FIN</li>
        </ul>
        <t>Implementations MAY <bcp14>MAY</bcp14> impose a limit on the number of
	such dangling streams. If limits are encountered, implementations MAY <bcp14>MAY</bcp14> close the connection.</t>

        <section anchor="dns-message-ids"><name>DNS anchor="dns-message-ids" numbered="true" toc="default">
          <name>DNS Message IDs</name>
          <t>When sending queries over a QUIC connection, the DNS Message ID MUST <bcp14>MUST</bcp14> be set to
zero.
0. The stream mapping for DoQ allows for unambiguous correlation of queries
and responses and responses, so the Message ID field is not required.</t>
          <t>This has implications for proxying DoQ message messages to and from other transports.
For example, proxies may have to manage the fact that DoQ can support a larger
number of outstanding queries on a single connection than e.g., than, for example, DNS over TCP TCP,
because DoQ is not limited by the Message ID space. This issue already exists for DoH,
where a Message ID of 0 is recommended.</t>
          <t>When forwarding a DNS message from DoQ over another transport, a DNS Message ID
MUST
<bcp14>MUST</bcp14> be generated according to the rules of the protocol that is in use. When
forwarding a DNS message from another transport over DoQ, the Message ID MUST <bcp14>MUST</bcp14>
be set to zero.</t> 0.</t>
        </section>
      </section>
      <section anchor="doq-error-codes"><name>DoQ anchor="doq-error-codes" numbered="true" toc="default">
        <name>DoQ Error Codes</name>
        <t>The following error codes are defined for use when abruptly terminating streams,
and used
for use as application protocol error codes when
aborting reading of streams, or for immediately closing connections:</t>
        <dl>
          <dt>
DOQ_NO_ERROR (0x0):  </dt>
          <dd>
            <t>No error.  This is used when the connection or stream needs to be closed, but
there is no error to signal.</t>
          </dd>
          <dt>
DOQ_INTERNAL_ERROR (0x1):  </dt>
          <dd>
            <t>The DoQ implementation encountered an internal error and is incapable of
pursuing the transaction or the connection.</t>
          </dd>
          <dt>
DOQ_PROTOCOL_ERROR (0x2):  </dt>
          <dd>
            <t>The DoQ implementation encountered a protocol error and is forcibly aborting
the connection.</t>
          </dd>
          <dt>
DOQ_REQUEST_CANCELLED (0x3):  </dt>
          <dd>
            <t>A DoQ client uses this to signal that it wants to cancel an
outstanding transaction.</t>
          </dd>
          <dt>
DOQ_EXCESSIVE_LOAD (0x4):  </dt>
          <dd>
            <t>A DoQ implementation uses this to signal when closing a connection due to excessive load.</t>
          </dd>
          <dt>
DOQ_UNSPECIFIED_ERROR (0x5):  </dt>
          <dd>
            <t>A DoQ implementation uses this in the absence of a more specific error code.</t>
          </dd>
          <dt>
DOQ_ERROR_RESERVED (0xd098ea5e):  </dt>
          <dd>
    <t>Alternative
            <t>An alternative error code used for tests.</t>
          </dd>
        </dl>
        <t>See <xref target="iana-error-codes"/> target="iana-error-codes" format="default"/> for details on registering new error codes.</t>
        <section anchor="transaction-cancellation"><name>Transaction anchor="transaction-cancellation" numbered="true" toc="default">
          <name>Transaction Cancellation</name>
          <t>In QUIC, sending STOP_SENDING requests that a peer cease transmission on a
stream. If a DoQ client wishes to cancel an outstanding request, it MUST <bcp14>MUST</bcp14> issue
a QUIC STOP_SENDING, and it SHOULD <bcp14>SHOULD</bcp14> use the error code DOQ_REQUEST_CANCELLED.
It MAY <bcp14>MAY</bcp14> use a more specific error code registered according to <xref target="iana-error-codes"/>. target="iana-error-codes" format="default"/>.
The STOP_SENDING request may be sent at
any time but will have no effect if the server response has already been
sent, in which case the client will simply discard the incoming response.
The corresponding DNS transaction MUST <bcp14>MUST</bcp14> be abandoned.</t>
          <t>Servers that receive STOP_SENDING act in accordance with <xref section="3.5" sectionFormat="of" target="RFC9000"/>. target="RFC9000" format="default"/>.
Servers SHOULD NOT <bcp14>SHOULD NOT</bcp14> continue processing a DNS transaction if they receive a STOP_SENDING.</t>
          <t>Servers MAY <bcp14>MAY</bcp14> impose implementation limits on the total number or rate of request cancellations. cancellation requests.
If limits are encountered, servers MAY <bcp14>MAY</bcp14> close the connection. In this case,
servers wanting to help client debugging MAY <bcp14>MAY</bcp14> use the error code DOQ_EXCESSIVE_LOAD.
There is always a trade-off between helping good faith clients debug issues
and allowing denial-of-service attackers to test server defenses, so defenses; depending
on circumstances servers might very well choose to send different error codes.</t>
          <t>Note that this mechanism provides a way for secondaries to cancel a single zone
transfer occurring on a given stream without having to close the QUIC
connection.</t>
          <t>Servers MUST NOT <bcp14>MUST NOT</bcp14> continue processing a DNS transaction if they receive a RESET_STREAM
request from the client before the client indicates the STREAM FIN. The server MUST <bcp14>MUST</bcp14>
issue a RESET_STREAM to indicate that the transaction is abandoned unless</t>

<t><list style="symbols">
  <t>it unless:</t>
          <ul spacing="normal">
            <li>it has already done so for another reason or</t>
  <t>it or</li>
            <li>it has already both sent the response and indicated the STREAM FIN.</t>
</list></t> FIN.</li>
          </ul>
        </section>
        <section anchor="transaction-errors"><name>Transaction anchor="transaction-errors" numbered="true" toc="default">
          <name>Transaction Errors</name>
          <t>Servers normally complete transactions by sending a DNS response (or responses)
on the transaction&#39;s transaction's stream, including cases where the DNS response indicates a
DNS error.

For example, a client <bcp14>SHOULD</bcp14> be notified of a Server Failure
(SERVFAIL, <xref target="RFC1035"/>) SHOULD be
notified to the client by sending back through a response with the Response Code set to
SERVFAIL.</t>
SERVFAIL.

</t>
          <t>If a server is incapable of sending a DNS response due to an internal error, it
SHOULD
<bcp14>SHOULD</bcp14> issue a QUIC RESET_STREAM frame. The error code SHOULD <bcp14>SHOULD</bcp14> be set to DOQ_INTERNAL_ERROR. The
corresponding DNS transaction MUST <bcp14>MUST</bcp14> be abandoned. Clients MAY <bcp14>MAY</bcp14> limit the number of
unsolicited QUIC Stream Resets RESET_STREAM frames received on a connection before choosing to close the
	  connection.</t>

          <t>Note that this mechanism provides a way for primaries to abort a single zone
transfer occurring on a given stream without having to close the QUIC
connection.</t>
        </section>
        <section anchor="protocol-errors"><name>Protocol anchor="protocol-errors" numbered="true" toc="default">
          <name>Protocol Errors</name>
          <t>Other error scenarios can occur due to malformed, incomplete incomplete, or unexpected
messages during a transaction. These include (but are not limited to)</t>

<t><list style="symbols">
  <t>a to):</t>
          <ul spacing="normal">
            <li>a client or server receives a message with a non-zero Message ID</t>
  <t>a ID</li>
            <li>a client or server receives a STREAM FIN before receiving all the bytes for a
message indicated in the 2-octet length field</t>
  <t>a field</li>
            <li>a client receives a STREAM FIN before receiving all the expected responses</t>
  <t>a responses</li>
            <li>a server receives more than one query on a stream</t>
  <t>a stream</li>
            <li>a client receives a different number of responses on a stream than expected
(e.g., multiple responses to a query for an A record)</t>
  <t>a record)</li>
            <li>a client receives a STOP_SENDING request</t>
  <t>the request</li>
            <li>the client or server does not indicate the expected STREAM FIN after
sending requests or responses (see <xref target="stream-mapping-and-usage"/>).</t>
  <t>an target="stream-mapping-and-usage" format="default"/>)</li>
            <li>an implementation receives a message containing the edns-tcp-keepalive
EDNS(0) Option <xref target="RFC7828"/> target="RFC7828" format="default"/> (see
<xref target="resource-management"/>)</t>
  <t>a target="resource-management" format="default"/>)</li>
            <li>a client or a server attempts to open a unidirectional QUIC stream</t>
  <t>a stream</li>
            <li>a server attempts to open a server-initiated bidirectional QUIC stream</t>
  <t>receiving stream</li>

<li>a server receives a &quot;replayable&quot; "replayable" transaction in O-RTT 0-RTT data (for servers not willing to
 handle this case - case, see section <xref target="session-resumption-and-0-rtt"/>)</t>
</list></t> target="session-resumption-and-0-rtt" format="default"/>)
</li>

          </ul>
          <t>If a peer encounters such an error condition condition, it is considered a fatal error. It
SHOULD
<bcp14>SHOULD</bcp14> forcibly abort the connection using QUIC&#39;s QUIC's CONNECTION_CLOSE mechanism, mechanism
and SHOULD <bcp14>SHOULD</bcp14> use the DoQ error code DOQ_PROTOCOL_ERROR. In some cases, it MAY <bcp14>MAY</bcp14>
instead silently abandon the connection, which uses fewer of the local resources
but makes debugging at the offending node more difficult.</t>
          <t>It is noted that the restrictions on use of the above EDNS(0) options option has
implications for proxying message messages from TCP/DoT/DoH over DoQ.</t>
        </section>
        <section anchor="alternative-error-codes"><name>Alternative error codes</name> anchor="alternative-error-codes" numbered="true" toc="default">
          <name>Alternative Error Codes</name>
          <t>This specification suggests describes specific error codes in Sections <xref target="transaction-cancellation"/>, target="transaction-cancellation" format="counter"/>,
<xref target="transaction-errors"/>, target="transaction-errors" format="counter"/>, and <xref target="protocol-errors"/>. target="protocol-errors"  format="counter"/>. These error codes are meant
to facilitate investigation of failures and other incidents. New error
codes may be defined in future versions of DoQ, DoQ or registered as specified
in <xref target="iana-error-codes"/>.</t> target="iana-error-codes" format="default"/>.</t>
          <t>Because new error codes can be defined without negotiation, use of an error
code in an unexpected context or receipt of an unknown error code MUST <bcp14>MUST</bcp14> be
treated as equivalent to DOQ_UNSPECIFIED_ERROR.</t>
          <t>Implementations MAY <bcp14>MAY</bcp14> wish to test the support for the error code extension
mechanism by using error codes not listed in this document, or they MAY <bcp14>MAY</bcp14> use
DOQ_ERROR_RESERVED.</t>
        </section>
      </section>

      <section anchor="connection-management"><name>Connection anchor="connection-management" numbered="true" toc="default">
        <name>Connection Management</name>
        <t><xref section="10" sectionFormat="of" target="RFC9000"/>, target="RFC9000" format="default"/>, the QUIC transport specification, specifies that
connections can be closed in three ways:</t>

<t><list style="symbols">
  <t>idle timeout</t>
  <t>immediate close</t>
  <t>stateless reset</t>
</list></t>
        <ul spacing="normal">
          <li>idle timeout</li>
          <li>immediate close</li>
          <li>stateless reset</li>
        </ul>
        <t>Clients and servers implementing DoQ SHOULD <bcp14>SHOULD</bcp14> negotiate use of the idle timeout.
Closing on idle timeout is done without any packet exchange, which minimizes
protocol overhead. Per <xref section="10.1" sectionFormat="of" target="RFC9000"/>, target="RFC9000" format="default"/>, the QUIC transport specification, the
effective value of the idle timeout is computed as the minimum of the values
advertised by the two endpoints. Practical considerations on setting the idle
timeout are discussed in <xref target="resource-management"/>.</t> target="resource-management" format="default"/>.</t>
        <t>Clients SHOULD <bcp14>SHOULD</bcp14> monitor the idle time incurred on their connection to the
server, defined by the time spent since the last packet from the server has
been received. When a client prepares to send a new DNS query to the server, it
SHOULD
<bcp14>SHOULD</bcp14> check whether the idle time is sufficiently lower than the idle timer. If it
is, the client SHOULD <bcp14>SHOULD</bcp14> send the DNS query over the existing connection. If not,
the client SHOULD <bcp14>SHOULD</bcp14> establish a new connection and send the query over that
connection.</t>
        <t>Clients MAY <bcp14>MAY</bcp14> discard their connections to the server before the idle timeout
expires. A client that has outstanding queries SHOULD <bcp14>SHOULD</bcp14> close the connection
explicitly using QUIC&#39;s QUIC's CONNECTION_CLOSE mechanism and the DoQ error code
DOQ_NO_ERROR.</t>
        <t>Clients and servers MAY <bcp14>MAY</bcp14> close the connection for a variety of other
reasons, indicated using QUIC&#39;s QUIC's CONNECTION_CLOSE. Client and servers
that send packets over a connection discarded by their peer might
receive a stateless reset indication. If a connection fails, all the
in progress transaction
in-progress transactions on that connection MUST <bcp14>MUST</bcp14> be abandoned.</t>
      </section>
      <section anchor="session-resumption-and-0-rtt"><name>Session anchor="session-resumption-and-0-rtt" numbered="true" toc="default">
        <name>Session Resumption and 0-RTT</name>
        <t>A client MAY <bcp14>MAY</bcp14> take advantage of the session resumption and 0-RTT mechanisms supported by
QUIC transport <xref target="RFC9000"/> target="RFC9000" format="default"/> and QUIC TLS <xref target="RFC9001"/>, target="RFC9001" format="default"/> if the server supports them.
Clients SHOULD <bcp14>SHOULD</bcp14> consider
potential privacy issues associated with session resumption before deciding to use
this mechanism and specifically evaluate the trade-offs presented in the various sections of this document.
The privacy issues are detailed in Sections <xref target="privacy-issues-with-0-rtt-data"/> target="privacy-issues-with-0-rtt-data" format="counter"/>
and <xref target="privacy-issues-with-session-resumption"/>, target="privacy-issues-with-session-resumption" format="counter"/>,
and the implementation considerations are discussed in
<xref target="using-0-rtt-and-session-resumption"/>.</t> target="using-0-rtt-and-session-resumption" format="default"/>.</t>
        <t>The 0-RTT mechanism MUST NOT <bcp14>MUST NOT</bcp14> be used to send DNS requests that are not
&quot;replayable&quot;
"replayable" transactions. In this specification, only transactions that have
an OPCODE of QUERY or NOTIFY are considered replayable and therefore replayable; therefore, other OPCODES MUST NOT <bcp14>MUST NOT</bcp14>
be sent in 0-RTT data. See <xref target="the-notify-service"/> target="the-notify-service" format="default"/> for a detailed discussion of why NOTIFY is
included here.</t>
        <t>Servers MAY <bcp14>MAY</bcp14> support session resumption, and MAY <bcp14>MAY</bcp14> do that with or without supporting
0-RTT, using the mechanisms described in <xref section="4.6.1" sectionFormat="of" target="RFC9001"/>. target="RFC9001" format="default"/>.
Servers supporting 0-RTT MUST NOT <bcp14>MUST NOT</bcp14> immediately process
non-replayable transactions received in 0-RTT data, data but instead
MUST
<bcp14>MUST</bcp14> adopt one of the following behaviours:</t>

<t><list style="symbols">
  <t>Queue behaviors:</t>
        <ul spacing="normal">
          <li>Queue the offending transaction and only process it after the QUIC handshake
has been completed, as defined in <xref section="4.1.1" sectionFormat="of" target="RFC9001"/>.</t>
  <t>Reply target="RFC9001" format="default"/>.</li>
          <li>Reply to the offending transaction with a response code REFUSED and
an Extended DNS Error Code (EDE) &quot;Too Early&quot;, "Too Early" using the extended RCODE
mechanisms defined in <xref target="RFC6891"/> target="RFC6891" format="default"/> and the extended DNS errros errors defined in <xref target="RFC8914"/>; target="RFC8914" format="default"/>; see
<xref target="reservation-of-extended-dns-error-code-too-early"/>.</t>
  <t>Close target="reservation-of-extended-dns-error-code-too-early" format="default"/>.</li>
          <li>Close the connection with the error code DOQ_PROTOCOL_ERROR.</t>
</list></t> DOQ_PROTOCOL_ERROR.</li>
        </ul>
      </section>
      <section anchor="message-sizes"><name>Message anchor="message-sizes" numbered="true" toc="default">
        <name>Message Sizes</name>
        <t>DoQ Queries queries and Responses responses are sent on QUIC streams, which in theory can carry
up to 2^62 2<sup>62</sup> bytes. However, DNS messages are restricted in practice to a maximum
size of 65535 bytes. This maximum size is enforced by the use of a two-octet 2-octet
message length field in DNS over TCP <xref target="RFC1035"/> target="RFC1035" format="default"/> and DNS over TLS DoT
<xref target="RFC7858"/>, target="RFC7858" format="default"/>, and by the definition of the &quot;application/dns-message&quot; "application/dns-message" for DNS
over HTTP DoH <xref target="RFC8484"/>. target="RFC8484" format="default"/>. DoQ enforces the same restriction.</t>
        <t>The Extension Mechanisms for DNS (EDNS) (EDNS(0)) <xref target="RFC6891"/> target="RFC6891" format="default"/> allow peers to specify the
UDP message size. This parameter is ignored by DoQ. DoQ implementations always
assume that the maximum message size is 65535 bytes.</t>
      </section>
    </section>

    <section anchor="implementation-requirements"><name>Implementation anchor="implementation-requirements" numbered="true" toc="default">
      <name>Implementation Requirements</name>

      <section anchor="authentication"><name>Authentication</name> anchor="authentication" numbered="true" toc="default">
        <name>Authentication</name>
        <t>For the stub to recursive resolver scenario, the authentication requirements
are the same as described in DoT <xref target="RFC7858"/> target="RFC7858" format="default"/> and &quot;Usage "Usage Profiles for DNS over
TLS and DNS over DTLS&quot; DTLS" <xref target="RFC8310"/>. target="RFC8310" format="default"/>. <xref target="RFC8932"/> target="RFC8932" format="default"/> states that DNS privacy
services SHOULD <bcp14>SHOULD</bcp14> provide credentials that clients can use to authenticate the
server. Given this, and to align with the authentication model for DoH, DoQ stubs
SHOULD
<bcp14>SHOULD</bcp14> use a Strict authentication usage profile. Client authentication for the encrypted
stub to recursive scenario is not described in any DNS RFC.</t>
        <t>For zone transfer, the authentication requirements are the same as described in
<xref target="RFC9103"/>.</t> target="RFC9103" format="default"/>.</t>
        <t>For the recursive resolver to authoritative nameserver scenario, authentication
requirements are unspecified at the time of writing and are the subject on of
ongoing work in the DPRIVE WG.</t>
      </section>
      <section anchor="fallback-to-other-protocols-on-connection-failure"><name>Fallback anchor="fallback-to-other-protocols-on-connection-failure" numbered="true" toc="default">
        <name>Fallback to Other Protocols on Connection Failure</name>
        <t>If the establishment of the DoQ connection fails, clients MAY <bcp14>MAY</bcp14> attempt to
fall back to DoT and then potentially clear text, cleartext, as specified in DoT
<xref target="RFC7858"/> target="RFC7858" format="default"/> and &quot;Usage "Usage Profiles for DNS over TLS and DNS over DTLS&quot; DTLS"
<xref target="RFC8310"/>, target="RFC8310" format="default"/>, depending on their privacy usage profile.</t>
        <t>DNS clients SHOULD <bcp14>SHOULD</bcp14> remember server IP addresses that don&#39;t don't support DoQ.
Mobile clients might also remember the lack of DoQ support by
given IP addresses on a per-context basis (e.g.per (e.g., per network or provisioning domain).</t>
        <t>Timeouts, connection refusals, and QUIC handshake failures are indicators
that a server does not support DoQ.  Clients SHOULD NOT <bcp14>SHOULD NOT</bcp14> attempt DoQ queries to a
server that does not support DoQ for a reasonable period (such as one hour per
server).  DNS clients following an out-of-band key-pinned privacy usage profile
(<xref target="RFC7858"/>) MAY
<xref target="RFC7858" format="default"/> <bcp14>MAY</bcp14> be more aggressive about retrying after DoQ connection failures.</t>
      </section>
      <section anchor="address-validation"><name>Address anchor="address-validation" numbered="true" toc="default">
        <name>Address Validation</name>
        <t><xref section="8" sectionFormat="of" target="RFC9000"/>, target="RFC9000" format="default"/>, the QUIC transport specification, defines Address
Validation procedures to avoid servers being used in address amplification
attacks. DoQ implementations MUST <bcp14>MUST</bcp14> conform to this specification, which limits
the worst case worst-case amplification to a factor 3.</t>
        <t>DoQ implementations SHOULD <bcp14>SHOULD</bcp14> consider configuring servers to use the Address
Validation using Retry Packets procedure defined in <xref section="8.1.2" sectionFormat="of" target="RFC9000"/>, target="RFC9000" format="default"/>, the QUIC
transport specification. This procedure imposes a 1-RTT delay for
verifying the return routability of the source address of a client, similar to
the DNS Cookies mechanism <xref target="RFC7873"/>.</t> target="RFC7873" format="default"/>.</t>
        <t>DoQ implementations that configure Address Validation using Retry Packets
SHOULD
<bcp14>SHOULD</bcp14> implement the Address Validation for Future Connections procedure
defined in <xref section="8.1.3" sectionFormat="of" target="RFC9000"/>, target="RFC9000" format="default"/>, the QUIC transport specification.
This defines how servers can send NEW_TOKEN frames to clients after the client
address is validated, validated in order to avoid the 1-RTT penalty during subsequent
connections by the client from the same address.</t>
      </section>
      <section anchor="padding"><name>Padding</name> anchor="padding" numbered="true" toc="default">
        <name>Padding</name>
        <t>Implementations MUST <bcp14>MUST</bcp14> protect against the traffic analysis attacks described in
<xref target="traffic-analysis"/> target="traffic-analysis" format="default"/> by the judicious injection of padding. This
could be done either by padding individual DNS messages using the
EDNS(0) Padding Option <xref target="RFC7830"/> target="RFC7830" format="default"/> or by padding QUIC packets (see
<xref section="19.1" sectionFormat="of" target="RFC9000"/>.</t> target="RFC9000" format="default"/>).</t>
        <t>In theory, padding at the QUIC packet level could result in better performance for the equivalent
protection, because the amount of padding can take into account non-DNS frames
such as acknowledgements or flow control updates, and also because QUIC packets
can carry multiple DNS messages. However, applications can only control the
amount of padding in QUIC packets if the implementation of QUIC exposes adequate APIs. This leads
to the following recommendation:</t>

<t><list style="symbols">
  <t>if recommendations:</t>
        <ul spacing="normal">
          <li>If the implementation of QUIC exposes APIs to set a padding policy,
DNS over QUIC SHOULD
DoQ <bcp14>SHOULD</bcp14> use that API to align the packet length to a small set of
fixed sizes.</t>
  <t>if sizes.</li>
          <li>If padding at the QUIC packet level is not available or not used,
DNS over QUIC MUST
DoQ <bcp14>MUST</bcp14> ensure that all DNS queries and responses are padded to
a small set of fixed sizes, using the EDNS(0) padding extension as specified
in <xref target="RFC7830"/>.</t>
</list></t>

<t>Implementation target="RFC7830" format="default"/>.</li>
        </ul>
        <t>Implementations might choose not to use a QUIC API for padding if it is
significantly simpler to re-use reuse existing DNS message padding logic which that is
applied to other encrypted transports.</t>
        <t>In the absence of a standard policy for padding sizes, implementations SHOULD <bcp14>SHOULD</bcp14>
follow the recommendations of the Experimental status &quot;Padding "Padding Policies for
Extension Mechanisms for DNS (EDNS(0))&quot; (EDNS(0))" <xref target="RFC8467"/>. target="RFC8467" format="default"/>. While Experimental,
these recommendations are referenced because they are implemented and deployed
for DoT, DoT and provide a way for implementations to be fully compliant with this
specification.</t>
      </section>
      <section anchor="connection-handling"><name>Connection anchor="connection-handling" numbered="true" toc="default">
        <name>Connection Handling</name>

<t>&quot;DNS
        <t>"DNS Transport over TCP - Implementation Requirements&quot; Requirements" <xref target="RFC7766"/> target="RFC7766" format="default"/> provides
updated guidance on DNS over TCP, some of which is applicable to DoQ. This
section provides similar advice on connection handling for DoQ.</t>
        <section anchor="connection-reuse"><name>Connection anchor="connection-reuse" numbered="true" toc="default">
          <name>Connection Reuse</name>
          <t>Historic implementations of DNS clients are known to open and close TCP
connections for each DNS query. To amortize connection setup costs, both
clients and servers SHOULD <bcp14>SHOULD</bcp14> support connection reuse by sending multiple queries
and responses over a single persistent QUIC connection.</t>
          <t>In order to achieve performance on par with UDP, DNS clients SHOULD <bcp14>SHOULD</bcp14> send their
queries concurrently over the QUIC streams on a QUIC connection. That is, when
a DNS client sends multiple queries to a server over a QUIC connection, it
SHOULD NOT
<bcp14>SHOULD NOT</bcp14> wait for an outstanding reply before sending the next query.</t>
        </section>
        <section anchor="resource-management"><name>Resource anchor="resource-management" numbered="true" toc="default">
          <name>Resource Management</name>
          <t>Proper management of established and idle connections is important to the
healthy operation of a DNS server.</t>
          <t>An implementation of DoQ SHOULD <bcp14>SHOULD</bcp14> follow best practices similar to those
specified for DNS over TCP <xref target="RFC7766"/>, target="RFC7766" format="default"/>, in particular with regard to:</t>

<t><list style="symbols">
  <t>Concurrent
          <ul spacing="normal">
            <li>Concurrent Connections (<xref section="6.2.2" sectionFormat="of" target="RFC7766"/>, target="RFC7766" format="default"/>, updated by <xref section="6.4" sectionFormat="of" target="RFC9103"/>)</t>
  <t>Security target="RFC9103" format="default"/>)</li>
            <li>Security Considerations (<xref section="10" sectionFormat="of" target="RFC7766"/>)</t>
</list></t> target="RFC7766" format="default"/>)</li>
          </ul>
          <t>Failure to do so may lead to resource exhaustion and denial of service.</t>
          <t>Clients that want to maintain long duration DoQ connections SHOULD <bcp14>SHOULD</bcp14> use the idle
timeout mechanisms defined in <xref section="10.1" sectionFormat="of" target="RFC9000"/>, target="RFC9000" format="default"/>, the QUIC transport
specification. Clients and servers MUST NOT <bcp14>MUST NOT</bcp14> send the edns-tcp-keepalive EDNS(0)
Option <xref target="RFC7828"/> target="RFC7828" format="default"/> in any messages sent on a DoQ connection (because it is
specific to the use of TCP/TLS as a transport).</t>
          <t>This document does not make specific recommendations for timeout values on idle
connections. Clients and servers should reuse and/or close connections
depending on the level of available resources. Timeouts may be longer during
periods of low activity and shorter during periods of high activity.</t>
        </section>
        <section anchor="using-0-rtt-and-session-resumption"><name>Using anchor="using-0-rtt-and-session-resumption" numbered="true" toc="default">
          <name>Using 0-RTT and Session Resumption</name>
          <t>Using 0-RTT for DNS over QUIC DoQ has many compelling advantages. Clients
can establish connections and send queries without incurring a connection
delay. Servers can thus negotiate low values of the connection
timers, which reduces the total number of connections that they need to
manage. They can do that because the clients that use 0-RTT will not incur
latency penalties if new connections are required for a query.</t>
          <t>Session resumption and 0-RTT data transmission create
privacy risks detailed in Sections  <xref target="privacy-issues-with-session-resumption"/> target="privacy-issues-with-0-rtt-data" format="counter"/> and <xref target="privacy-issues-with-0-rtt-data"/>. target="privacy-issues-with-session-resumption" format="counter" />.
The following recommendations are meant to reduce the privacy
risks while enjoying the performance benefits of 0-RTT data, subject to the
restrictions specified in <xref target="session-resumption-and-0-rtt"/>.</t> target="session-resumption-and-0-rtt" format="default"/>.</t>
<t>Clients SHOULD <bcp14>SHOULD</bcp14> use resumption tickets only once, as
specified in Appendix C.4
to <xref target="RFC8446"/>. target="RFC8446" sectionFormat="of" section="C.4" />. By
default, clients SHOULD NOT <bcp14>SHOULD NOT</bcp14> use session resumption if the
client&#39;s
client's connectivity has changed.</t>
          <t>Clients could receive address validation tokens from the server using the
NEW_TOKEN mechanism; see <xref section="8" sectionFormat="of" target="RFC9000"/>. target="RFC9000" format="default"/>. The associated tracking
risks are mentioned in <xref target="privacy-issues-with-address-validation-tokens"/>. target="privacy-issues-with-address-validation-tokens" format="default"/>.
Clients SHOULD <bcp14>SHOULD</bcp14> only use the address validation tokens when they are also using session
resumption,
resumption thus avoiding additional tracking risks.</t>
          <t>Servers SHOULD <bcp14>SHOULD</bcp14> issue session resumption tickets with a sufficiently long lifetime (e.g., 6 hours),
so that clients are not tempted to either keep the connection alive or frequently poll the server
to renew session resumption tickets.
Servers SHOULD <bcp14>SHOULD</bcp14> implement the anti-replay mechanisms specified in <xref section="8" sectionFormat="of" target="RFC8446"/>.</t> target="RFC8446" format="default"/>.</t>
        </section>
        <section anchor="controlling-connection-migration-for-privacy"><name>Controlling anchor="controlling-connection-migration-for-privacy" numbered="true" toc="default">
          <name>Controlling Connection Migration For for Privacy</name>
          <t>DoQ implementations might consider using the connection migration features defined
in <xref section="9" sectionFormat="of" target="RFC9000"/>. target="RFC9000" format="default"/>. These features enable connections to continue operating
as the client&#39;s client's connectivity changes.
As detailed in <xref target="privacy-issues-with-long-duration-sessions"/>, target="privacy-issues-with-long-duration-sessions" format="default"/>, these features
trade off privacy for latency. By default, clients SHOULD <bcp14>SHOULD</bcp14> be configured
to prioritize privacy and start new sessions if their connectivity changes.</t>
        </section>
      </section>
      <section anchor="processing-queries-in-parallel"><name>Processing anchor="processing-queries-in-parallel" numbered="true" toc="default">
        <name>Processing Queries in Parallel</name>
        <t>As specified in <xref section="7" sectionFormat="of" target="RFC7766"/> &quot;DNS target="RFC7766" format="default"/> "DNS Transport over TCP - Implementation
Requirements&quot;,
Requirements", resolvers are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to support the preparing
of responses in parallel and sending them out of order. In DoQ, they do that by
sending responses on their specific stream as soon as possible, without waiting
for availability of responses for previously opened streams.</t>
      </section>
      <section anchor="zone-transfer"><name>Zone transfer</name> anchor="zone-transfer" numbered="true" toc="default">
        <name>Zone Transfer</name>
        <t><xref target="RFC9103"/> target="RFC9103" format="default"/> specifies zone transfer over TLS (XoT)
and includes updates to <xref target="RFC1995"/> target="RFC1995" format="default"/> (IXFR), <xref target="RFC5936"/> (AXFR) target="RFC5936" format="default"/> (AXFR), and
<xref target="RFC7766"/>. target="RFC7766" format="default"/>. Considerations relating to the re-use reuse of XoT connections
described there apply analogously to zone transfers performed using DoQ
connections. One reason for re-iterating reiterating such specific guidance is the
lack of effective connection re-use reuse in existing TCP/TLS zone transfer
implementations today. The following recommendations apply:</t>

<t><list style="symbols">
  <t>DoQ
        <ul spacing="normal">
          <li>DoQ servers MUST <bcp14>MUST</bcp14> be able to handle multiple concurrent IXFR requests on a
single QUIC connection</t>
  <t>DoQ connection.</li>
          <li>DoQ servers MUST <bcp14>MUST</bcp14> be able to handle multiple concurrent AXFR requests on a
single QUIC connection</t> connection.</li>
          <li>
            <t>DoQ implementations SHOULD
  <list style="symbols">
      <t>use <bcp14>SHOULD</bcp14>
            </t>
            <ul spacing="normal">
              <li>use the same QUIC connection for both AXFR and IXFR requests to the same
primary</t>
      <t>send
primary</li>
              <li>send those requests in parallel as soon as they are queued i.e. queued, i.e., do not wait
for a response before sending the next query on the connection
(this is analogous to pipelining requests on a TCP/TLS connection)</t>
      <t>send connection)</li>
              <li>send the response(s) for each request as soon as they are available i.e. available, i.e.,
response streams MAY <bcp14>MAY</bcp14> be sent intermingled</t>
    </list></t>
</list></t> intermingled</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="flow-control-mechanisms"><name>Flow anchor="flow-control-mechanisms" numbered="true" toc="default">
        <name>Flow Control Mechanisms</name>
        <t>Servers and Clients clients manage flow control using the mechanisms defined in
<xref section="4" sectionFormat="of" target="RFC9000"/>. target="RFC9000" format="default"/>. These mechanisms allow clients and servers to specify
how many streams can be created, how much data can be sent on a stream,
and how much data can be sent on the union of all streams. For DNS over QUIC, DoQ,
controlling how many streams are created allows servers to control how many
new requests the client can send on a given connection.</t>
        <t>Flow control exists to protect endpoint resources.
For servers, global and per-stream flow control limits control how much data can be sent by
clients. The same mechanisms
allow clients to control how much data can be sent by servers.
Values that are too small will unnecessarily limit performance.
Values that are too large might expose endpoints to overload or memory exhaustion.
Implementations or deployments will need to adjust flow control limits to
balance these concerns. In particular, zone transfer implementations will need to control
these limits carefully to ensure both large and concurrent zone transfers are well managed.</t>
        <t>Initial values of parameters control how many requests and how much data can be
sent by clients and servers at the beginning of the connection. These values
are specified in transport parameters exchanged during the connection handshake.
The parameter values received in the initial connection also control how many requests and
how much data can be sent by clients using 0-RTT data in a resumed connection.
Using too small values of these initial parameters would restrict the
usefulness of allowing 0-RTT data.</t>
      </section>
    </section>

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

<t>(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION) This section
records the status of known implementations of the protocol defined by this
specification at the time of posting of this Internet-Draft, and is based on a
proposal described in <xref target="RFC7942"/>.</t>

<t><list style="numbers">
  <t>AdGuard launched a DoQ recursive resolver service in December 2020. They have
released a suite of open source tools that support DoQ:
  <list style="numbers">
      <t><eref target="https://github.com/AdguardTeam/DnsLibs">AdGuard C++ DNS libraries</eref> A
DNS proxy library that supports all existing DNS protocols including
DNS-over-TLS, DNS-over-HTTPS, DNSCrypt and DNS-over-QUIC (experimental).</t>
      <t><eref target="https://github.com/AdguardTeam/dnsproxy">DNS Proxy</eref> A simple DNS proxy
server that supports all existing DNS protocols including DNS-over-TLS,
DNS-over-HTTPS, DNSCrypt, and DNS-over-QUIC. Moreover, it can work as a
DNS-over-HTTPS, DNS-over-TLS or DNS-over-QUIC server.</t>
      <t><eref target="https://github.com/AdguardTeam/coredns">CoreDNS fork for AdGuard DNS</eref>
Includes DNS-over-QUIC server-side support.</t>
      <t><eref target="https://github.com/ameshkov/dnslookup">dnslookup</eref> Simple command line
utility to make DNS lookups. Supports all known DNS protocols: plain DNS,
DoH, DoT, DoQ, DNSCrypt.</t>
    </list></t>
  <t><eref target="https://github.com/private-octopus/quicdoq">Quicdoq</eref> Quicdoq is a simple
 open source implementation of DoQ. It is written in C, based on
<eref target="https://github.com/private-octopus/picoquic">Picoquic</eref>.</t>
  <t><eref target="https://github.com/DNS-OARC/flamethrower/tree/dns-over-quic">Flamethrower</eref>
is an open source DNS performance and functional testing utility written in
C++ that has an experimental implementation of DoQ.</t>
  <t><eref target="https://github.com/aiortc/aioquic">aioquic</eref> is an implementation of QUIC in
Python. It includes example client and server for DoQ.</t>
</list></t>

<section anchor="performance-measurements"><name>Performance Measurements</name>

<t>To the authors&#39; knowledge, no benchmarking studies comparing DoT, DoH and DoQ
are published yet. However, anecdotal evidence from the <eref target="https://adguard.com/en/blog/dns-over-quic.html">AdGuard DoQ recursive
resolver deployment</eref> indicates
that it performs similarly (and possibly better) compared to the other
encrypted protocols, particularly in mobile environments. Reasons given for
this include that DoQ</t>

<t><list style="symbols">
  <t>Uses less bandwidth due to a more efficient handshake (and due to less per
message overhead when compared to DoH).</t>
  <t>Performs better in mobile environments due to the increased resilience to
packet loss</t>
  <t>Can maintain connections as users move between mobile networks via its
connection management</t>
</list></t>

</section>
</section>
<section anchor="security-considerations"><name>Security anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>A Threat Analysis of the Domain Name System is found in <xref target="RFC3833"/>. target="RFC3833" format="default"/>.
This analysis was written before the development of DoT, DoH DoH, and DoQ, and
probably needs to be updated.</t>
      <t>The security considerations of DoQ should be comparable to those of DoT
<xref target="RFC7858"/>. target="RFC7858" format="default"/>. DoT as specified in <xref target="RFC7858"/> target="RFC7858" format="default"/> only addresses the stub to recursive resolver scenario, but the considerations about person-in-the-middle
attacks, middleboxes middleboxes, and caching of data from clear text cleartext connections also
apply for DoQ to the resolver to authoritative server scenario.
As stated in <xref target="authentication"/> target="authentication" format="default"/>, the authentication requirements for securing zone transfer using DoQ are the same as those for zone transfer over DoT, therefore DoT; therefore, the general security considerations are entirely analogous to those described in <xref target="RFC9103"/>.</t> target="RFC9103" format="default"/>.</t>
      <t>DoQ relies on QUIC, which itself relies on TLS 1.3 and thus supports by default
the protections against downgrade attacks described in <xref target="BCP195"/>.
QUIC specific target="BCP195" format="default"/>.
QUIC-specific issues and their mitigations are described in
<xref section="21" sectionFormat="of" target="RFC9000"/>.</t> target="RFC9000" format="default"/>.</t>
    </section>
    <section anchor="privacy-considerations"><name>Privacy anchor="privacy-considerations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>The general considerations of encrypted transports provided in &quot;DNS "DNS Privacy
Considerations&quot;
Considerations" <xref target="RFC9076"/> target="RFC9076" format="default"/> apply to DoQ. The specific
considerations provided there do not differ between DoT and DoQ, and they are not
discussed further here. Similarly, &quot;Recommendations "Recommendations for DNS Privacy Service
Operators&quot;
Operators" <xref target="RFC8932"/> target="RFC8932" format="default"/> (which covers operational, policy, and security
considerations for DNS privacy services) is also applicable to DoQ services.</t>
      <t>QUIC incorporates the mechanisms of TLS 1.3 <xref target="RFC8446"/> target="RFC8446" format="default"/>, and this enables QUIC
transmission of &quot;0-RTT&quot; "0-RTT" data. This can provide interesting latency gains, but
it raises two concerns:</t>

<t><list style="numbers">
  <t>Adversaries
      <ol spacing="normal" type="1"><li>Adversaries could replay the 0-RTT data and infer its content
from the behavior of the receiving server.</t>
  <t>The server.</li>
        <li>The 0-RTT mechanism relies on TLS session resumption, which can provide
linkability between successive client sessions.</t>
</list></t> sessions.</li>
      </ol>
      <t>These issues are developed in Sections <xref target="privacy-issues-with-0-rtt-data"/>
      target="privacy-issues-with-0-rtt-data"
      format="counter"/> and <xref target="privacy-issues-with-session-resumption"/>.</t>
      target="privacy-issues-with-session-resumption"
      format="counter"/>.</t>
      <section anchor="privacy-issues-with-0-rtt-data"><name>Privacy anchor="privacy-issues-with-0-rtt-data" numbered="true" toc="default">
        <name>Privacy Issues With with 0-RTT data</name>
        <t>The 0-RTT data can be replayed by adversaries. That data may trigger queries by
a recursive resolver to authoritative resolvers. Adversaries may be able to
pick a time at which the recursive resolver outgoing traffic is observable, observable and
thus find out what name was queried for in the 0-RTT data.</t>
        <t>This risk is in fact a subset of the general problem of observing the behavior
of the recursive resolver discussed in &quot;DNS "DNS Privacy Considerations&quot; Considerations"
<xref target="RFC9076"/>. target="RFC9076" format="default"/>. The attack is partially mitigated by reducing the observability
of this traffic. The mandatory replay protection mechanisms in
TLS 1.3 <xref target="RFC8446"/> target="RFC8446" format="default"/> limit but do not eliminate the risk of replay.
0-RTT packets can only be replayed within a narrow window,
which is only wide enough to account for variations in clock skew and network transmission.</t>
        <t>The recommendation for TLS 1.3 <xref target="RFC8446"/> target="RFC8446" format="default"/> is that the capability to use 0-RTT
data should be turned off by default, default and only enabled if the user clearly
understands the associated risks. In the case of DoQ, allowing 0-RTT data
provides significant performance gains, and there is a concern that a
recommendation to not use it would simply be ignored. Instead, a set of
practical recommendations is provided in Sections <xref target="session-resumption-and-0-rtt"/> target="session-resumption-and-0-rtt" format="counter"/> and
<xref target="using-0-rtt-and-session-resumption"/>.</t> target="using-0-rtt-and-session-resumption" format="counter"/>.</t>
        <t>The specifications in <xref target="session-resumption-and-0-rtt"/> target="session-resumption-and-0-rtt" format="default"/> block the most obvious
risks of replay attacks, as they only allows allow for transactions that will
not change the long-term state of the server.</t>
        <t>The attacks described above apply to the stub resolver to recursive resolver scenario, but similar attacks might be envisaged in the
recursive resolver to authoritative resolver scenario, and the
same mitigations apply.</t>
      </section>
      <section anchor="privacy-issues-with-session-resumption"><name>Privacy anchor="privacy-issues-with-session-resumption" numbered="true" toc="default">
        <name>Privacy Issues With with Session Resumption</name>
        <t>The QUIC session resumption mechanism reduces the cost of re-establishing sessions
and enables 0-RTT data. There is a linkability issue associated with session
resumption, if the same resumption token is used several times. Attackers on path
between client and server could observe repeated usage of the token and
use that to track the client over time or over multiple locations.</t>
        <t>The session resumption mechanism allows servers to correlate the resumed sessions
with the initial sessions, sessions and thus to track the client. This creates a virtual
long duration session. The series of queries in that session can be used by the
server to identify the client. Servers can most probably do that already if
the client address remains constant, but session resumption tickets also enable
tracking after changes of the client&#39;s client's address.</t>
        <t>The recommendations in <xref target="using-0-rtt-and-session-resumption"/> target="using-0-rtt-and-session-resumption" format="default"/> are designed to
mitigate these risks. Using session tickets only once mitigates
the risk of tracking by third parties. Refusing to resume a session if addresses
change mitigates the incremental risk of tracking by the server (but the risk of
tracking by IP address remains).</t>
        <t>The privacy trade-offs here may be context specific. Stub resolvers will have a strong
motivation to prefer privacy over latency since they often change location. However,
recursive resolvers that use a small set of static IP addresses are more likely to prefer the reduced
latency provided by session resumption and may consider this a valid reason to use
resumption tickets even if the IP address changed between sessions.</t>
        <t>Encrypted zone transfer (RFC9103) (<xref target="RFC9103"/>) explicitly does
not attempt to hide the identity of the parties involved in the transfer, but transfer; at the
same time time, such transfers are not particularly latency sensitive. This means that
applications supporting zone transfers may decide to apply the same
protections as stub to recursive applications.</t>
      </section>

      <section anchor="privacy-issues-with-address-validation-tokens"><name>Privacy anchor="privacy-issues-with-address-validation-tokens" numbered="true" toc="default">
        <name>Privacy Issues With with Address Validation Tokens</name>
        <t>QUIC specifies address validation mechanisms in <xref section="8" sectionFormat="of" target="RFC9000"/>. target="RFC9000" format="default"/>. Use
of an address validation token allows QUIC servers to avoid an extra RTT for
new connections. Address validation tokens are typically tied to an IP address.
QUIC clients normally only use these tokens when setting up a new connection
from a previously used address. However, clients are not always aware that they
are using a new address. This could be due to NAT, or because the client does
not have an API available to check if the IP address has changed (which can be
quite often for IPv6). There is a linkability risk if clients mistakenly use
address validation tokens after unknowingly moving to a new location.</t>
        <t>The recommendations in <xref target="using-0-rtt-and-session-resumption"/> target="using-0-rtt-and-session-resumption" format="default"/> mitigates
this risk by tying the usage of the NEW_TOKEN to that of session resumption,
though this recommendation does not cover the case where the client is unaware
of the address change.</t>
      </section>
      <section anchor="privacy-issues-with-long-duration-sessions"><name>Privacy anchor="privacy-issues-with-long-duration-sessions" numbered="true" toc="default">
        <name>Privacy Issues With with Long Duration Sessions</name>
        <t>A potential alternative to session resumption is the use of long duration sessions:
if a session remains open for a long time, new queries can be sent without incurring
connection establishment delays. It is worth pointing out that the two solutions have
similar privacy characteristics. Session resumption may allow servers to keep track
of the IP addresses of clients, but long duration sessions have the same effect.</t>
        <t>In particular, a DoQ implementation might take advantage of the connection migration
features of QUIC to maintain a session even if the client&#39;s client's connectivity changes,
for example example, if the client migrates from a Wi-Fi connection to a cellular network
connection,
connection and then to another Wi-Fi connection. The server would be
able to track the client location by monitoring the succession of IP addresses
used by the long duration connection.</t>
        <t>The recommendation in <xref target="controlling-connection-migration-for-privacy"/> target="controlling-connection-migration-for-privacy" format="default"/> mitigates
the privacy concerns related to long duration sessions using multiple client addresses.</t>
      </section>
      <section anchor="traffic-analysis"><name>Traffic anchor="traffic-analysis" numbered="true" toc="default">
        <name>Traffic Analysis</name>
        <t>Even though QUIC packets are encrypted, adversaries can gain information from
observing packet lengths, in both queries and responses, as well as packet
timing. Many DNS requests are emitted by web browsers. Loading a specific web
page may require resolving dozens of DNS names. If an application adopts a
simple mapping of one query or response per packet, or &quot;one "one QUIC STREAM frame
per packet&quot;, packet", then the succession of packet lengths may provide enough
information to identify the requested site.</t>
        <t>Implementations SHOULD <bcp14>SHOULD</bcp14> use the mechanisms defined in <xref target="padding"/> target="padding" format="default"/> to mitigate
this attack.</t>
      </section>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="registration-of-doq-identification-string"><name>Registration anchor="registration-of-doq-identification-string" numbered="true" toc="default">
        <name>Registration of a DoQ Identification String</name>
        <t>This document creates a new registration for the identification of DoQ in the
&quot;Application Layer
"TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs&quot; IDs" registry
<xref target="RFC7301"/>.</t> target="RFC7301" format="default"/>.</t>
        <t>The &quot;doq&quot; "doq" string identifies DoQ:</t>
        <dl>
          <dt>
Protocol:  </dt>
          <dd>
            <t>DoQ</t>
          </dd>
          <dt>
Identification Sequence:  </dt>
          <dd>
            <t>0x64 0x6F 0x71 (&quot;doq&quot;)</t> ("doq")</t>
          </dd>
          <dt>
Specification:  </dt>
          <dd>
            <t>This document</t>
          </dd>
        </dl>
      </section>
      <section anchor="reservation-of-dedicated-port"><name>Reservation anchor="reservation-of-dedicated-port" numbered="true" toc="default">
        <name>Reservation of a Dedicated Port</name>
        <t>For both TCP and UDP UDP, port 853 is currently reserved for &#39;DNS "DNS query-response
protocol run over TLS/DTLS&#39; TLS/DTLS" <xref target="RFC7858"/>.</t> target="RFC7858" format="default"/>.</t>
        <t>However, the specification for DNS over DTLS (DoD)
<xref target="RFC8094"/> target="RFC8094" format="default"/> is experimental, limited to stub to resolver, and no
implementations or deployments currently exist to the authors&#39; authors' knowledge (even though
several years have passed since the specification was published).</t>
        <t>This specification proposes to additionally reserve reserves the use of UDP port 853 for
DoQ. QUIC version 1 was designed to be able to co-exist coexist with other protocols on
the same port, including DTLS , DTLS; see <xref section="17.2" sectionFormat="of" target="RFC9000"/>. target="RFC9000" format="default"/>. This means
that deployments that serve DNS over DTLS DoD and DNS over QUIC DoQ (QUIC version 1) on the
same port will be able to demultiplex the two due to the second most
significant bit in each UDP payload. Such deployments ought to check the
signatures of future versions or extensions (e.g., <xref target="I-D.ietf-quic-bit-grease"/>) target="I-D.ietf-quic-bit-grease" format="default"/>)
of QUIC and DTLS before deploying them to serve DNS on the same port.</t>
        <t>IANA is requested to update has updated the following value in the &quot;Service "Service Name and Transport
Protocol Port Number Registry&quot; Registry" in the System Range. range. The registry for that range
requires IETF Review or IESG Approval <xref target="RFC6335"/>.</t> target="RFC6335" format="default"/>.</t>
        <dl>
          <dt>
Service Name:  </dt>
          <dd>
            <t>domain-s</t>
          </dd>
          <dt>
Port Number:  </dt>
          <dd>
            <t>853</t>
          </dd>
          <dt>
Transport Protocol(s):  </dt>
          <dd>
            <t>UDP</t>
          </dd>
          <dt>
Assignee:  </dt>
          <dd>
            <t>IESG</t>
          </dd>
          <dt>
Contact:  </dt>
          <dd>
            <t>IETF Chair</t>
          </dd>
          <dt>
Description:  </dt>
          <dd>
            <t>DNS query-response protocol run over DTLS or QUIC</t>
          </dd>
          <dt>
Reference:  </dt>
          <dd>
            <t><xref target="RFC7858"/><xref target="RFC8094"/> target="RFC7858" format="default"/><xref target="RFC8094" format="default"/> This document</t>
          </dd>
        </dl>
        <t>Additionally, IANA is requested to update has updated the Description field for the
corresponding TCP port 853 allocation to be &#39;DNS "DNS query-response protocol run
over TLS&#39; TLS" and to remove removed <xref target="RFC8094"/> from the TCP allocation&#39;s allocation's Reference field for consistency and clarity.</t>

<t>(UPDATE ON IANA REQUEST: THIS SENTENCE TO BE REMOVED BEFORE PUBLICATION) Review by the port experts on 13th December 2021 determined that the proposed updates to the existing port allocation were acceptable and will be made when this document is approved for publication.</t>

      </section>
      <section anchor="reservation-of-extended-dns-error-code-too-early"><name>Reservation anchor="reservation-of-extended-dns-error-code-too-early" numbered="true" toc="default">
        <name>Reservation of an Extended DNS Error Code Code: Too Early</name>
        <t>IANA is requested to add has registered the following value to in
the Extended "Extended DNS Error Codes Codes" registry <xref target="RFC8914"/>:</t> target="RFC8914" format="default"/>:</t>
        <dl>
          <dt>
INFO-CODE:  </dt>
          <dd>
    <t>TBD</t>
            <t>26</t>
          </dd>
          <dt>
Purpose:  </dt>
          <dd>
            <t>Too Early</t>
          </dd>
          <dt>
Reference:  </dt>
          <dd>
            <t>This document</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-error-codes"><name>DNS over QUIC anchor="iana-error-codes" numbered="true" toc="default">
        <name>DNS-over-QUIC Error Codes Registry</name>

        <t>IANA [SHALL add/has added] has added a registry for &quot;DNS over QUIC "DNS-over-QUIC Error Codes&quot; Codes" on the
&quot;Domain
"Domain Name System (DNS) Parameters&quot; Parameters" web page.</t>
        <t>The &quot;DNS over QUIC "DNS-over-QUIC Error Codes&quot; Codes" registry governs a 62-bit space. This space is
split into three regions that are governed by different policies:</t>

<t><list style="symbols">
  <t>Permanent
        <ul spacing="normal">
          <li>Permanent registrations for values between 0x00 and 0x3f (in hexadecimal;
inclusive), which are assigned using Standards Action or IESG Approval as
defined in Section Sections <xref target="RFC8126" section="4.9"  sectionFormat="bare"/> and Section <xref target="RFC8126" section="4.10" sectionFormat="bare"/> of <xref target="RFC8126"/></t>
  <t>Permanent target="RFC8126" format="default"/></li>
          <li>Permanent registrations for values larger than 0x3f, which are assigned
using the Specification Required policy (<xref target="RFC8126"/>)</t>
  <t>Provisional target="RFC8126" format="default"/>)</li>
          <li>Provisional registrations for values larger than 0x3f, which require Expert
Review, as defined in <xref section="4.5" sectionFormat="of" target="RFC8126"/>.</t>
</list></t> target="RFC8126" format="default"/>.</li>
        </ul>
        <t>Provisional reservations share the range of values larger than 0x3f
with some permanent registrations. This is by design, design to enable conversion
of provisional registrations into permanent registrations without requiring
changes in deployed systems. (This design is aligned with the principles
set in <xref section="22" sectionFormat="of" target="RFC9000"/>.)</t> target="RFC9000" format="default"/>.)</t>
        <t>Registrations in this registry MUST <bcp14>MUST</bcp14> include the following fields:</t>
        <dl>
          <dt>
Value:  </dt>
          <dd>
            <t>The assigned codepoint.</t> codepoint</t>
          </dd>
          <dt>
Status:  </dt>
          <dd>
    <t>&quot;Permanent&quot;
            <t>"Permanent" or &quot;Provisional&quot;.</t> "Provisional"</t>
          </dd>
          <dt>
Contact:  </dt>
          <dd>
            <t>Contact details for the registrant.</t> registrant</t>
          </dd>
        </dl>
        <t>In addition, permanent registrations MUST <bcp14>MUST</bcp14> include:</t>
        <dl>
          <dt>
Error:  </dt>
          <dd>
            <t>A short mnemonic for the parameter.</t> parameter</t>
          </dd>
          <dt>
Specification:  </dt>
          <dd>
            <t>A reference to a publicly available specification for the value (optional for provisional registrations).</t> registrations)</t>
          </dd>
          <dt>
Description:  </dt>
          <dd>
            <t>A brief description of the error code semantics, which MAY <bcp14>MAY</bcp14> be a summary if a
specification reference is provided.</t> provided</t>
          </dd>
        </dl>
        <t>Provisional registrations of codepoints are intended to allow for private use
and experimentation with extensions to DNS over QUIC. DoQ.  However,
provisional registrations could be reclaimed and reassigned for another purpose. other purposes.
In addition to the parameters listed above, provisional registrations MUST <bcp14>MUST</bcp14> include:</t>
        <dl>
          <dt>
Date:  </dt>
          <dd>
            <t>The date of last update to the registration.</t> registration</t>
          </dd>
        </dl>
        <t>A request to update the date on any provisional
registration can be made without review from the designated expert(s).</t>
        <t>The initial contents content of this registry are is shown in <xref target="iana-error-table"/> target="iana-error-table" format="default"/> and all
entries share the following fields:</t>
        <dl>
          <dt>
Status:  </dt>
          <dd>
            <t>Permanent</t>
          </dd>
          <dt>
Contact:  </dt>
          <dd>
            <t>DPRIVE WG</t>
          </dd>
          <dt>
Specification:  </dt>
          <dd>
            <t><xref target="doq-error-codes"/></t> target="doq-error-codes" format="default"/></t>
          </dd>
        </dl>

<texttable title="Initial DNS over QUIC
        <table anchor="iana-error-table" align="center">
          <name>Initial DNS-over-QUIC Error Codes Entries" anchor="iana-error-table">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Error</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>0x0</c>
      <c>DOQ_NO_ERROR</c>
      <c>No error</c>
      <c>0x1</c>
      <c>DOQ_INTERNAL_ERROR</c>
      <c>Implementation error</c>
      <c>0x2</c>
      <c>DOQ_PROTOCOL_ERROR</c>
      <c>Generic Entries</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Error</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x0</td>
              <td align="left">DOQ_NO_ERROR</td>
              <td align="left">No error</td>
            </tr>
            <tr>
              <td align="left">0x1</td>
              <td align="left">DOQ_INTERNAL_ERROR</td>
              <td align="left">Implementation error</td>
            </tr>
            <tr>
              <td align="left">0x2</td>
              <td align="left">DOQ_PROTOCOL_ERROR</td>
              <td align="left">Generic protocol violation</c>
      <c>0x3</c>
      <c>DOQ_REQUEST_CANCELLED</c>
      <c>Request violation</td>
            </tr>
            <tr>
              <td align="left">0x3</td>
              <td align="left">DOQ_REQUEST_CANCELLED</td>
              <td align="left">Request cancelled by client</c>
      <c>0x4</c>
      <c>DOQ_EXCESSIVE_LOAD</c>
      <c>Closing client</td>
            </tr>
            <tr>
              <td align="left">0x4</td>
              <td align="left">DOQ_EXCESSIVE_LOAD</td>
              <td align="left">Closing a connection for excessive load</c>
      <c>0x5</c>
      <c>DOQ_UNSPECIFIED_ERROR</c>
      <c>No load</td>
            </tr>
            <tr>
              <td align="left">0x5</td>
              <td align="left">DOQ_UNSPECIFIED_ERROR</td>
              <td align="left">No error reason specified</c>
      <c>0xd098ea5e</c>
      <c>DOQ_ERROR_RESERVED</c>
      <c>Alternative specified</td>
            </tr>
            <tr>
              <td align="left">0xd098ea5e</td>
              <td align="left">DOQ_ERROR_RESERVED</td>
              <td align="left">Alternative error code used for tests</c>
</texttable> tests</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>This document liberally borrows text from the HTTP-3 specification
<xref target="I-D.ietf-quic-http"/> edited by Mike Bishop, and from the DoT specification
<xref target="RFC7858"/> authored by Zi Hu, Liang Zhu, John Heidemann, Allison Mankin,
Duane Wessels, and Paul Hoffman.</t>

<t>The privacy issue with 0-RTT data and session resumption were analyzed by Daniel
Kahn Gillmor (DKG) in a message to the IETF &quot;DPRIVE&quot; working group <xref target="DNS0RTT"/>.</t>

<t>Thanks to Tony Finch for an extensive review of the initial version of this
draft, and to Robert Evans for the discussion of 0-RTT privacy issues.
Early reviews by Paul Hoffman and Martin Thomson and interoperability tests
conducted by Stephane Bortzmeyer helped improve the definition of the protocol.</t>

<t>Thanks also to Martin Thomson and Martin Duke for their later reviews focussing
on the low level QUIC details which helped clarify several aspects of DoQ. Thanks
to Andrey Meshkov, Loganaden Velvindron, Lucas Pardue, Matt Joras, Mirja Kuelewind,
Brian Trammell and Phillip Hallam-Baker for their reviews and contributions.</t>

</section>

  </middle>
  <back>

    <references title='Normative References'>

<reference anchor='RFC1034' target='https://www.rfc-editor.org/info/rfc1034'>
<front>
<title>Domain names - concepts and facilities</title>
<author fullname='P.V. Mockapetris' initials='P.V.' surname='Mockapetris'><organization/></author>
<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'>
<front>
<title>Domain names - implementation and specification</title>
<author fullname='P.V. Mockapetris' initials='P.V.' surname='Mockapetris'><organization/></author>
<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='RFC9000' target='https://www.rfc-editor.org/info/rfc9000'>
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname='J. Iyengar' initials='J.' role='editor' surname='Iyengar'><organization/></author>
<author fullname='M. Thomson' initials='M.' role='editor' surname='Thomson'><organization/></author>
<date month='May' year='2021'/>
<abstract><t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t></abstract>
</front>
<seriesInfo name='RFC' value='9000'/>
<seriesInfo name='DOI' value='10.17487/RFC9000'/>
</reference>

<reference anchor='RFC9001' target='https://www.rfc-editor.org/info/rfc9001'>
<front>
<title>Using TLS to Secure QUIC</title>
<author fullname='M. Thomson' initials='M.' role='editor' surname='Thomson'><organization/></author>
<author fullname='S. Turner' initials='S.' role='editor' surname='Turner'><organization/></author>
<date month='May' year='2021'/>
<abstract><t>This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t></abstract>
</front>
<seriesInfo name='RFC' value='9001'/>
<seriesInfo name='DOI' value='10.17487/RFC9001'/>
</reference>

<reference anchor='RFC7858' target='https://www.rfc-editor.org/info/rfc7858'>
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</title>
<author fullname='Z. Hu' initials='Z.' surname='Hu'><organization/></author>
<author fullname='L. Zhu' initials='L.' surname='Zhu'><organization/></author>
<author fullname='J. Heidemann' initials='J.' surname='Heidemann'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></author>
<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></author>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<date month='May' year='2016'/>
<abstract><t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS.  Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626.  In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t><t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group.  It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t></abstract>
</front>
<seriesInfo name='RFC' value='7858'/>
<seriesInfo name='DOI' value='10.17487/RFC7858'/>
</reference>

<reference anchor='RFC8310' target='https://www.rfc-editor.org/info/rfc8310'>
<front>
<title>Usage Profiles for DNS over TLS and DNS over DTLS</title>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='D. Gillmor' initials='D.' surname='Gillmor'><organization/></author>
<author fullname='T. Reddy' initials='T.' surname='Reddy'><organization/></author>
<date month='March' year='2018'/>
<abstract><t>This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS).  These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS.  This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server.  Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS.  This document updates RFC 7858.</t></abstract>
</front>
<seriesInfo name='RFC' value='8310'/>
<seriesInfo name='DOI' value='10.17487/RFC8310'/>
</reference>

<reference anchor='RFC1995' target='https://www.rfc-editor.org/info/rfc1995'>
<front>
<title>Incremental Zone Transfer in DNS</title>
<author fullname='M. Ohta' initials='M.' surname='Ohta'><organization/></author>
<date month='August' year='1996'/>
<abstract><t>This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1995'/>
<seriesInfo name='DOI' value='10.17487/RFC1995'/>
</reference>

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

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<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='RFC6891' target='https://www.rfc-editor.org/info/rfc6891'>
<front>
<title>Extension Mechanisms for DNS (EDNS(0))</title>
<author fullname='J. Damas' initials='J.' surname='Damas'><organization/></author>
<author fullname='M. Graff' initials='M.' surname='Graff'><organization/></author>
<author fullname='P. Vixie' initials='P.' surname='Vixie'><organization/></author>
<date month='April' year='2013'/>
<abstract><t>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders.  This document describes backward-compatible mechanisms for allowing the protocol to grow.</t><t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations.  It also obsoletes RFC 2673 (&quot;Binary Labels in the Domain Name System&quot;) and adds considerations on the use of extended labels in the DNS.</t></abstract>
</front>
<seriesInfo name='STD' value='75'/>
<seriesInfo name='RFC' value='6891'/>
<seriesInfo name='DOI' value='10.17487/RFC6891'/>
</reference>

<reference anchor='RFC8914' target='https://www.rfc-editor.org/info/rfc8914'>
<front>
<title>Extended DNS Errors</title>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></author>
<author fullname='E. Hunt' initials='E.' surname='Hunt'><organization/></author>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></author>
<author fullname='W. Hardaker' initials='W.' surname='Hardaker'><organization/></author>
<author fullname='D. Lawrence' initials='D.' surname='Lawrence'><organization/></author>
<date month='October' year='2020'/>
<abstract><t>This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.</t></abstract>
</front>
<seriesInfo name='RFC' value='8914'/>
<seriesInfo name='DOI' value='10.17487/RFC8914'/>
</reference>

<reference anchor='RFC9103' target='https://www.rfc-editor.org/info/rfc9103'>
<front>
<title>DNS Zone Transfer over TLS</title>
<author fullname='W. Toorop' initials='W.' surname='Toorop'><organization/></author>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='S. Sahib' initials='S.' surname='Sahib'><organization/></author>
<author fullname='P. Aras' initials='P.' surname='Aras'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></author>
<date month='August' year='2021'/>
<abstract><t>DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport.</t></abstract>
</front>
<seriesInfo name='RFC' value='9103'/>
<seriesInfo name='DOI' value='10.17487/RFC9103'/>
</reference>

<reference anchor='RFC7830' target='https://www.rfc-editor.org/info/rfc7830'>
<front>
<title>The EDNS(0) Padding Option</title>
<author fullname='A. Mayrhofer' initials='A.' surname='Mayrhofer'><organization/></author>
<date month='May' year='2016'/>
<abstract><t>This document specifies the EDNS(0) &quot;Padding&quot; option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.</t></abstract>
</front>
<seriesInfo name='RFC' value='7830'/>
<seriesInfo name='DOI' value='10.17487/RFC7830'/>
</reference>

<reference anchor='RFC8467' target='https://www.rfc-editor.org/info/rfc8467'>
<front>
<title>Padding Policies for Extension Mechanisms for DNS (EDNS(0))</title>
<author fullname='A. Mayrhofer' initials='A.' surname='Mayrhofer'><organization/></author>
<date month='October' year='2018'/>
<abstract><t>RFC 7830 specifies the &quot;Padding&quot; option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications.  This memo lists the possible options (&quot;padding policies&quot;), discusses the implications of each option, and provides a recommended (experimental) option.</t></abstract>
</front>
<seriesInfo name='RFC' value='8467'/>
<seriesInfo name='DOI' value='10.17487/RFC8467'/>
</reference>

<reference anchor='RFC7766' target='https://www.rfc-editor.org/info/rfc7766'>
<front>
<title>DNS Transport over TCP - Implementation Requirements</title>
<author fullname='J. Dickinson' initials='J.' surname='Dickinson'><organization/></author>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='R. Bellis' initials='R.' surname='Bellis'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></author>
<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></author>
<date month='March' year='2016'/>
<abstract><t>This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.</t></abstract>
</front>
<seriesInfo name='RFC' value='7766'/>
<seriesInfo name='DOI' value='10.17487/RFC7766'/>
</reference>

<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<date month='August' year='2018'/>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>

<reference anchor='RFC5936' target='https://www.rfc-editor.org/info/rfc5936'>
<front>
<title>DNS Zone Transfer Protocol (AXFR)</title>
<author fullname='E. Lewis' initials='E.' surname='Lewis'><organization/></author>
<author fullname='A. Hoenes' initials='A.' role='editor' surname='Hoenes'><organization/></author>
<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='RFC7301' target='https://www.rfc-editor.org/info/rfc7301'>
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
<author fullname='S. Friedl' initials='S.' surname='Friedl'><organization/></author>
<author fullname='A. Popov' initials='A.' surname='Popov'><organization/></author>
<author fullname='A. Langley' initials='A.' surname='Langley'><organization/></author>
<author fullname='E. Stephan' initials='E.' surname='Stephan'><organization/></author>
<date month='July' year='2014'/>
<abstract><t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t></abstract>
</front>
<seriesInfo name='RFC' value='7301'/>
<seriesInfo name='DOI' value='10.17487/RFC7301'/>
</reference>

<reference anchor='RFC8126' target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></author>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></author>
<date month='June' year='2017'/>
<abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>
    <displayreference target="I-D.ietf-dnsop-rfc8499bis" to="DNS-TERMS"/>
    <displayreference target="I-D.ietf-quic-bit-grease" to="GREASING-QUIC"/>
    <displayreference target="I-D.ietf-quic-http" to="HTTP/3"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1995.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9103.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7830.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8467.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>

    <references title='Informative References'>
      <references>
        <name>Informative References</name>
        <reference anchor="DNS0RTT" target="https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html">
          <front>
            <title>DNS + 0-RTT</title>
            <author initials="D." surname="Kahn Gillmor" fullname="Daniel Kahn Gillmor">
      <organization></organization>
              <organization/>
            </author>
            <date year="2016" month="April" day="06"/>
          </front>
          <seriesInfo name="Message" value="to DNS-Privacy WG mailing list"/>
        </reference>

	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-dnsop-rfc8499bis.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8490.xml"/>

<reference anchor='I-D.ietf-dnsop-rfc8499bis'>
   <front>
      <title>DNS Terminology</title>
      <author fullname='Paul Hoffman'>
	 <organization>ICANN</organization>
      </author>
      <author fullname='Kazunori Fujiwara'>
	 <organization>Japan Registry Services Co., Ltd.</organization>
      </author>
      <date day='28' month='September' year='2021'/>
      <abstract>
	 <t>   The Domain Name System (DNS) is defined in literally dozens of
   different RFCs.  The terminology used by implementers and developers
   of DNS protocols, and by operators of DNS systems, has sometimes
   changed in the decades since the DNS was first defined.  This
   document gives current definitions for many of the terms used in the
   DNS in a single document.

   This document obsoletes RFC 8499 and updates RFC 2308.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-rfc8499bis-03'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-03.txt' type='TXT'/>
</reference>

<reference anchor='RFC8490' target='https://www.rfc-editor.org/info/rfc8490'>
<front>
<title>DNS Stateful Operations</title>
<author fullname='R. Bellis' initials='R.' surname='Bellis'><organization/></author>
<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/></author>
<author fullname='J. Dickinson' initials='J.' surname='Dickinson'><organization/></author>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='T. Lemon' initials='T.' surname='Lemon'><organization/></author>
<author fullname='T. Pusateri' initials='T.' surname='Pusateri'><organization/></author>
<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>

<reference anchor='I-D.ietf-quic-http'> anchor="I-D.ietf-quic-http" target="https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34">
<front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
<author initials='M' surname='Bishop' fullname='Mike Bishop'>
	 <organization>Akamai</organization> Bishop' role='editor'>
  <organization/>
</author>
<date day='2' month='February' year='2021'/>
      <abstract>
	 <t>The QUIC transport protocol has several features that are desirable
   in a transport for HTTP, such as stream multiplexing, per-stream flow
   control, and low-latency connection establishment.  This document
   describes a mapping of HTTP semantics over QUIC.  This document also
   identifies HTTP/2 features that are subsumed by QUIC, and describes
   how HTTP/2 extensions can be ported to HTTP/3.

DO NOT DEPLOY THIS VERSION OF HTTP

   DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC.  This
   version is still a work in progress.  For trial deployments, please
   use earlier versions.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic.

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-http.
	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-quic-http-34'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-quic-http-34.txt' type='TXT'/>
</reference>

<reference anchor='RFC8484' target='https://www.rfc-editor.org/info/rfc8484'>
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<author fullname='P. McManus' initials='P.' surname='McManus'><organization/></author>
<date month='October' year='2018'/>
<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>
<seriesInfo name='RFC' value='8484'/>
<seriesInfo name='DOI' value='10.17487/RFC8484'/>
</reference>

<reference anchor='RFC9076' target='https://www.rfc-editor.org/info/rfc9076'>
<front>
<title>DNS Privacy Considerations</title>
<author fullname='T. Wicinski' initials='T.' role='editor' surname='Wicinski'><organization/></author>
<date month='July' year='2021'/>
<abstract><t>This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626.</t></abstract>
</front>
<seriesInfo name='RFC' value='9076'/>
<seriesInfo name='DOI' value='10.17487/RFC9076'/>
</reference>

<reference anchor='RFC9002' target='https://www.rfc-editor.org/info/rfc9002'>
<front>
<title>QUIC Loss Detection and Congestion Control</title>
<author fullname='J. Iyengar' initials='J.' role='editor' surname='Iyengar'><organization/></author>
<author fullname='I. Swett' initials='I.' role='editor' surname='Swett'><organization/></author>
<date month='May' year='2021'/>
<abstract><t>This document describes loss detection and congestion control mechanisms for QUIC.</t></abstract>
</front>
<seriesInfo name='RFC' value='9002'/>
<seriesInfo name='DOI' value='10.17487/RFC9002'/>
</reference>

<reference anchor='RFC7828' target='https://www.rfc-editor.org/info/rfc7828'>
<front>
<title>The edns-tcp-keepalive EDNS0 Option</title>
<author fullname='P. Wouters' initials='P.' surname='Wouters'><organization/></author>
<author fullname='J. Abley' initials='J.' surname='Abley'><organization/></author>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='R. Bellis' initials='R.' surname='Bellis'><organization/></author>
<date month='April' year='2016'/>
<abstract><t>DNS messages between clients and servers may be received over either UDP or TCP.  UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP.  Additionally, UDP can be exploited for reflection attacks.  Using TCP would reduce retransmits and amplification.  However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.</t><t>This document defines an EDNS0 option (&quot;edns-tcp-keepalive&quot;) that allows DNS servers to signal a variable idle timeout.  This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.</t></abstract>
</front>
<seriesInfo name='RFC' value='7828'/>
<seriesInfo name='DOI' value='10.17487/RFC7828'/>
</reference>

<reference anchor='RFC8932' target='https://www.rfc-editor.org/info/rfc8932'>
<front>
<title>Recommendations for DNS Privacy Service Operators</title>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='B. Overeinder' initials='B.' surname='Overeinder'><organization/></author>
<author fullname='R. van Rijswijk-Deij' initials='R.' surname='van Rijswijk-Deij'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></author>
<date month='October' year='2020'/>
<abstract><t>This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services.  With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users. </t><t>This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841.</t></abstract>
</front>
<seriesInfo name='BCP' value='232'/>
<seriesInfo name='RFC' value='8932'/>
<seriesInfo name='DOI' value='10.17487/RFC8932'/>
</reference>

<reference anchor='RFC7873' target='https://www.rfc-editor.org/info/rfc7873'>
<front>
<title>Domain Name System (DNS) Cookies</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organization/></author>
<author fullname='M. Andrews' initials='M.' surname='Andrews'><organization/></author>
<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='RFC7942' target='https://www.rfc-editor.org/info/rfc7942'>
<front>
<title>Improving Awareness of Running Code: The Implementation Status Section</title>
<author fullname='Y. Sheffer' initials='Y.' surname='Sheffer'><organization/></author>
<author fullname='A. Farrel' initials='A.' surname='Farrel'><organization/></author>
<date month='July' year='2016'/>
<abstract><t>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section.  This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.</t><t>This process is not mandatory.  Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.  This document obsoletes RFC 6982, advancing it to a Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='205'/>
<seriesInfo name='RFC' value='7942'/>
<seriesInfo name='DOI' value='10.17487/RFC7942'/>
</reference>

<reference anchor='RFC3833' target='https://www.rfc-editor.org/info/rfc3833'>
<front>
<title>Threat Analysis of the Domain Name System (DNS)</title>
<author fullname='D. Atkins' initials='D.' surname='Atkins'><organization/></author>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></author>
<date month='August' year='2004'/>
<abstract><t>Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect.  Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified.  This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3833'/>
<seriesInfo name='DOI' value='10.17487/RFC3833'/> name="Internet-Draft" value="draft-ietf-quic-http-34"/>

</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9076.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9002.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7828.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8932.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3833.xml"/>
        <referencegroup anchor='BCP195' target='https://www.rfc-editor.org/info/bcp195'>
<!-- reference.RFC.7525.xml -->
<reference anchor='RFC7525' target='https://www.rfc-editor.org/info/rfc7525'>
<front>
<title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname='Y. Sheffer' initials='Y.' surname='Sheffer'><organization/></author>
<author fullname='R. Holz' initials='R.' surname='Holz'><organization/></author>
<author fullname='P. Saint-Andre' initials='P.' surname='Saint-Andre'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t></abstract>
</front>
<seriesInfo name='BCP' value='195'/>
<seriesInfo name='RFC' value='7525'/>
<seriesInfo name='DOI' value='10.17487/RFC7525'/>
</reference>
<!-- reference.RFC.8996.xml -->
<reference anchor='RFC8996' target='https://www.rfc-editor.org/info/rfc8996'>
<front>
<title>Deprecating TLS 1.0 and TLS 1.1</title>
<author fullname='K. Moriarty' initials='K.' surname='Moriarty'><organization/></author>
<author fullname='S. Farrell' initials='S.' surname='Farrell'><organization/></author>
<date month='March' year='2021'/>
<abstract><t>This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. </t><t>This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t><t>This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t></abstract>
</front>
<seriesInfo name='BCP' value='195'/>
<seriesInfo name='RFC' value='8996'/>
<seriesInfo name='DOI' value='10.17487/RFC8996'/>
</reference> anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
        </referencegroup>

<reference anchor='RFC8094' target='https://www.rfc-editor.org/info/rfc8094'>
<front>
<title>DNS over Datagram Transport Layer Security (DTLS)</title>
<author fullname='T. Reddy' initials='T.' surname='Reddy'><organization/></author>
<author fullname='D. Wing' initials='D.' surname='Wing'><organization/></author>
<author fullname='P. Patil' initials='P.' surname='Patil'><organization/></author>
<date month='February' year='2017'/>
<abstract><t>DNS queries and responses are visible to network elements on the path between the DNS client and its server.  These queries and responses can contain privacy-sensitive information, which is valuable to protect.</t><t>This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks.  As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size.  The proposed mechanism runs over port 853.</t></abstract>
</front>
<seriesInfo name='RFC' value='8094'/>
<seriesInfo name='DOI' value='10.17487/RFC8094'/>
</reference>

<reference anchor='I-D.ietf-quic-bit-grease'>
   <front>
      <title>Greasing the QUIC Bit</title>
      <author fullname='Martin Thomson'>
	 <organization>Mozilla</organization>
      </author>
      <date day='10' month='November' year='2021'/>
      <abstract>
	 <t>   This document describes a method for negotiating the ability to send
   an arbitrary value for the second-to-most significant bit in QUIC
   packets.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-quic-bit-grease-02'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-quic-bit-grease-02.txt' type='TXT'/>
</reference>

<reference anchor='RFC6335' target='https://www.rfc-editor.org/info/rfc6335'>
<front>
<title>Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry</title>
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></author>
<author fullname='L. Eggert' initials='L.' surname='Eggert'><organization/></author>
<author fullname='J. Touch' initials='J.' surname='Touch'><organization/></author>
<author fullname='M. Westerlund' initials='M.' surname='Westerlund'><organization/></author>
<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/></author>
<date month='August' year='2011'/>
<abstract><t>This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry.  It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.</t><t>This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP).  It also updates the DNS SRV specification to clarify what a service name is and how it is registered.  This memo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='165'/>
<seriesInfo name='RFC' value='6335'/>
<seriesInfo name='DOI' value='10.17487/RFC6335'/>
</reference>

<reference anchor='RFC1996' target='https://www.rfc-editor.org/info/rfc1996'>
<front>
<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
<author fullname='P. Vixie' initials='P.' surname='Vixie'><organization/></author>
<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>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-quic-bit-grease.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml"/>
      </references>
    </references>

    <section anchor="the-notify-service"><name>The anchor="the-notify-service" numbered="true" toc="default">
      <name>The NOTIFY Service</name>
      <t>This appendix discusses why it is considered acceptable to send NOTIFY
(see <xref target="RFC1996"/>) target="RFC1996" format="default"/>) in 0-RTT data.</t>
      <t><xref target="session-resumption-and-0-rtt"/> target="session-resumption-and-0-rtt" format="default"/> says &quot;The "The 0-RTT mechanism SHOULD NOT <bcp14>MUST NOT</bcp14>
be used to send DNS requests that are not &quot;replayable&quot; transactions&quot;. "replayable" transactions". This
specification supports sending a NOTIFY in 0-RTT data because
although a NOTIFY technically changes the state of the receiving server, the
effect of replaying NOTIFYs has negligible impact in practice.</t>
      <t>NOTIFY messages prompt a secondary to either send an SOA query or an XFR
request to the primary on the basis that a newer version of the zone is
available. It has long been recognized that NOTIFYs can be forged and, in
theory, used to cause a secondary to send repeated unnecessary requests to the
primary. For this reason, most implementations have some form of throttling of the
SOA/XFR queries triggered by the receipt of one or more NOTIFYs.</t>
      <t><xref target="RFC9103"/> target="RFC9103" format="default"/> describes the privacy risks associated with both NOTIFY and SOA queries
and does not include addressing those risks within the scope of encrypting zone
transfers. Given this, the privacy benefit of using DoQ for NOTIFY is not clear - clear,
but for the same reason, sending NOTIFY as 0-RTT data has no privacy risk above
that of sending it using cleartext DNS.</t>
    </section>

    <section anchor="notable-changes-from-previous-versions"><name>Notable Changes From Previous Versions</name>
<t>(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)</t>

<section anchor="stream-mapping-incompatibility-with-draft-02"><name>Stream Mapping Incompatibility With Draft-02</name>
<t>Versions prior to -02 of this anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>This document liberally borrows text from the HTTP/3 specification
proposed
      <xref target="I-D.ietf-quic-http" format="default"/> edited by <contact fullname="Mike
      Bishop"/> and from the DoT specification <xref target="RFC7858"
      format="default"/> authored by <contact fullname="Zi Hu"/>, <contact fullname="Liang Zhu"/>, <contact fullname="John Heidemann"/>, <contact fullname="Allison
      Mankin"/>, <contact fullname="Duane Wessels"/>, and <contact fullname="Paul Hoffman"/>.</t>
      <t>The privacy issue with 0-RTT data and session resumption was
      analyzed by <contact fullname="Daniel Kahn Gillmor"/> (DKG) in a simpler mapping scheme message to the IETF DPRIVE
      Working Group <xref target="DNS0RTT" format="default"/>.</t>
      <t>Thanks to <contact fullname="Tony Finch"/> for an extensive review of queries the initial draft version
      of this document, and responses to QUIc stream,
which omitted <contact fullname="Robert Evans"/> for the 2 byte length field discussion of 0-RTT privacy
      issues.  Early reviews by <contact fullname="Paul Hoffman"/> and <contact fullname="Martin Thomson"/> and
supported only a single response
      interoperability tests conducted by Stephane Bortzmeyer helped improve
      the definition of the protocol.</t>
      <t>Thanks also to <contact fullname="Martin Thomson"/> and <contact fullname="Martin Duke"/> for their later reviews
      focusing on a given stream. The more complex mapping
in <xref target="stream-mapping-and-usage"/> was adopted the low-level QUIC details, which helped clarify several
      aspects of DoQ. Thanks to specifically cater <contact fullname="Andrey Meshkov"/>, <contact fullname="Loganaden Velvindron"/>, <contact fullname="Lucas
      Pardue"/>, <contact fullname="Matt Joras"/>, <contact fullname="Mirja Kuelewind"/>, <contact fullname="Brian Trammell"/>, and <contact fullname="Phillip
      Hallam-Baker"/> for XFR support, however, it breaks
compatibility with earlier versions.</t>

</section> their reviews and contributions.</t>
    </section>

  </back>

<!-- ##markdown-source:
H4sIAIfJX2IAA7V96XfbVpbn9/dXYFQfIlWTtLzEid1nTrciybGmbEmR5EpV
9/TkgCQooUwCDABaZqryv8/93eUtIKQ4XTM5J4lIAm+57767L+Px2HVltyxe
Zyfn11n9qWiyk2JezvKumGc/fDg7zo7rqipmXVlXrcun06b49OCzDn/e1s32
ddZ2czevZ+f5ioaeN/miG5dFtxjP1035qRjPq7b+eVPOxk+fOdd2eTX/KV/W
FT27LVrnynXzOuuaTds9Ozx8dfjM5U2Rv85umrxq13XTuY/3r7OzqiuaqujG
JxjeuVk9L6vb19mmHeftrCzdunyd/WdXz0ZZS+80xaKlv7Yr+WNWr1ZF1bX/
5Vy+6e7q5rXL+J+x/j/Lyqp9nR1PsrebsitWuf++4k0d3zVl25V5tfN73dAq
LmmfBI3sYtbV601Lq51N/BMtraboXmcvnn2TfV8vF7N607RFdjX3T8zKjqD4
pinn+TZ7mzfTugm/1XOa/8ej7NW3z74+jL7eVB1g/+H6yH9J6yqXr7M7WeK/
6/8nBLbh7V5PspNy9pH+rqvehq/zJh/4kXd7XVb1fFNlZzc7e3yf387zZVFl
xwTuptj5/eLzom7m2fWsLKpZkV3mzcceFOSJ3vYv/vIie/H90cDu/9TffEsL
//dWVjihcx/e+dGEllrR5nrbPlouS9pv/0fZNm2spcXNiv6cubw1WfFb/36L
b3luQu6K3ljlHd0D4BzdpcOrmxtBvy5vbgGUu65bt6+fPLm/v5/g3kxouicY
Y5w3szt688l9MX1Ct2iM+5TPtk9mm6YhAD9ZtbeHT59983Jy162WMma43/+S
HY5pLv46xfo+NE4m2Z/yuyr7vlwuVxHuCUxO8qoslrtPzAnjX2fPDp++HB++
GB++5C/boimLFrv2k2Xvi7bNb+nZrsbCxpeyi+zH7zPsku5xRvCjSz0ej7N8
SriSz+jTzV3ZZkRWNri62bxoZ005Ldqsuyvo2hdZvRCaRaOum/pTOS+IiijN
IAypFvRNRXd2SXiV0Slg7gmNWmSEe812DSpnb86z6VZGu8vbrC1X5TJv8OO6
aLoSk9Y0b02zxi/cvLseufu7clnoSvz0xZKGqAhAsty7Ip+P68WY9lpk02WN
a3WblW27oQfK6q7AaWb3ZXfnbo4vM6KQNk+bEbhpxYtFiTvTZet89rHosmXd
tllTzECYtzQHUaYPJ5eTQKyZRO+f1D8c8JYUc+It2S7lVOQt2lFGL90cZO26
mJWLkjZK9+DqzfE333797YhXtqRtVTTU7C7HQRVMGWfJeLNl3rblLIzLa8OB
Oh2XmAfAP3iqyR4yWnye3RZV0eTL8XrTrHEKHtJOD5ZXVlaz5Wb+2GB4uu02
UyySoEeEmK7XyPk/8b3clbLjSytb/oW4lcy5oJHaWVHlTVm3E0HZVTmfLwvn
/gAu1RDhYQbq3ElN6F1lYIvZ9bYlWkywPb8+AHLOinVHG6OjjQGd7ek7uHlt
No6erOZukc/otuDs9rK///1/0KE8PXz+4tdfAVld3opwCnDVjf+84evIe2gK
AljV0ieAw9GJ8NfAN7pnj66iXK2XBW6hHBpeS45xz/nlfE3LcS5L7+6a5gb7
pYNc5es1cJ8WiEPCIgkliW/XSzkm+tb1LpMM/urw8PDXX8OHp9h4erolrgSd
UEPboIPEtQL60CUYESHO+PbhktEG6b2boqE7Wi/r2y3g+W9n45OJiC3E8tbj
ZjH79sWrV9Oy5S0BxLd1vmz90usf/G7oHF8TsX86yUgUUFJEj7Q4edmiv32d
iFe8rp1bxySTlqL3TY62bANi0zWvhXABkzHHbMlkoas9nQfRg2wmSygazEDE
alUQPLF4GiN6jG8hH7czko+1pfjwAfQbW1sQrWuNmIbFAyPoCx5BREX61pD0
2+dPDxmEzyLw0CIIq+gDzbAsPhF/oZW1JBmRVJDP54QwbfaJSPc897u1CWRL
LYS6da5HPUhwnHsezxhhFNFL4ig1baWqOyyEKXtOmPH+5kMG2i2oTvCqGCN5
3vIXT1HCZSqJ19BmCL/nNOEZnU8zL5gI5sS7i098DK3ijlAT+q3drHkhdXVb
A4Hu6+Yj5oo4U71wNNNITnFGVFsQL75XhhbO/ZEf29shbVhovSSA7HmqZc/u
PrND/IQAMLjD+0yKdIzwO94dfHofqLXcghzP+RgTWtpm+395c3Vg5OzVK6If
I/pEH75+9fzlr78eKFBpugZQmrejHhAMU9uH2YULJ+/lAL7QRsUIDapxdLvj
8eVu42qf0947ouLrDpRmlc+ZXRSf8MeaLjYLG4G995mPyGekvmBCXEhmG9P6
c9HK5YjGj1BEIDouK6L8rHzxZnJR0kYZiR+zO2YkDOEasJa7jMmv6SCLxWaZ
XRDXV5TeP7m+OFAqQxRO7uY1Q2KLdXcDzAQ0Y71eGsEIJLcpSLNrCiMYPMBd
fe8wSPTGVwQvkQKF6YFwys3lUaAe5Cu9Hnp4tA8aiG9fPPU9SaDM2/GikUcc
F2EVDvftzc0l06y3Wwg6xedONElCNndpnObPhHkY7Hm2j+efPD/YixkAK6uQ
yo23mtihyOHCDWTJcF4swFqw53vS4AB4v1sQh6kHaIcD9NAjuHsM4XXboXxL
XN3e5GNlriVLxYSkNhCxXOmCCjclkC3KrjWZmNTY+p5oT0MQJXJ2e9fdF/hv
NqezmnWebyWEnE+CJqXR6Fhv8wZSLl8nFkFJmt3QsWQ0D783pTvJW35YeGJS
8YDspIjbEDYwxn4CCaL/kzy5KuZlDrllQgKVkE/n3xOCSCyiBDrkIjVAvsbe
5fCFqteLRUtgmm5HWTG5nYyyCEiOHyT285kRFlg3A7mmv6fFXf6prBuhOwkp
AGEialveVmOSy1piKnql6LC8iCMQyUkdlLtEjOZ2A4WBrwTE7xoHKuNMaMRE
ksJQgaDxTmfdhnYZyU0keExI4EqFsrFeRDZzxOvhySH5GC/rSXMjt2HmDhjM
i/Wy3jJi2zyQav9UkK4G0itE8yN9ZEqc7b3/cH2zN5L/Z+cX/PfVKSHS1ekJ
/r5+e/Tunf/D6RPXby8+vDsJf4U3jy/evz89P5GX6dss+crtvT/6654Qib2L
y5uzi/Ojd3u47DsUG6g4VXQiUHSMyc60DRZqviPB9+kL5TzPnj595YXLb59+
g/t3TyKSTMZEVT4SALegRwUpOjQIkSnCnDXhOzN3IoNEsyqWPCcA3YmtiRn8
pzInDbp7u5k6t08TZacnZzcXV9j/6evs5u0ZEezTY+wru7nIvjul7b+/+PPp
Cf355uLqNLv88N27s+MjPHCAk9CxmoJwquzqZqtSYSIj0AXuvInhlujIZgrb
xBO1Dj0x69wE5FGQk6kmNk4XkYYFVyNlrzLizSrnakO3975Y0lB4AzumK7bB
e1u32FQzvZ72IgFms6RTWBKFJAmybNoOJzQv29mmFc7F2Hl2evMmO7m8Ovvz
afbj924/MnscJOYCgS9fI5gto+uopoPWJG1ohnQT2s1Uv2rtevCMchXji8K3
9r5QnioqJl2G7EdS9WnZOHQRSPx4gzhYmeVHRRZ92rFA781CGStaRFsZY/7g
5VXQZbWUQJW8SfQCZTmtsMiaZImuvIXMH3EFsy8kWA/Nx5kBJgXbns7w6vAb
ErwgoaQ8nW0gysYSHudMDxBm+aXawkOagpoItiS8NOVMEPGCZaFNxaaGbGgC
ApCIw7ZayMLORFvhw4l2tCv/QgwTJuit4HRm3WadGhaq4raGKKaiUYtxYGIi
ZYQE4A6TbVpahYN5aEiXwgoBB4LnNV4WWWYvUW1HjvjdlJE90Ql4Bal+PBEB
B8IFHk+kjyB8stxkdjL6WaTV5TYoqrtKaivac4p6LoD5Sw8o0QOzN5sGl8fp
1ed96fUp22BfI1j9/e+6ph1+K1dFbz/O/z3Jx6vNKnsnxik9yGDYmPFe5aqL
4Ema42ZWeOsDCdj4DCa4JAo1EpFrUfDNbF0Lcpe3pAlkUAWuVTjH1GxlhTU0
z+aECQQX0gt5W/TiZsUnB5vIs957+fxTXmHGQZMerYt+w9x9FBK76h5v8B3e
OSm6iNTRpaaT54/0Z9fUy3CxD5+JeQZ68XshGYpWwxZKogEEt/oefwO9l8tC
zMyAUsnrpHd56zTMarPsSpItTJyfKCGOZZfzay/0M0Z2+cdCINEBZQTBSdI2
wGO/3V1TsGTtwX+xVu7SRvCECo5pvuQ8ZBP7YiHR+ytWV7kDkJFMJPMqIWi6
51dOzedsDg2c4MBO+h0dwxgwUs9aoCl6K0X+9TBjyESanYyPKUmNAbMo5iP5
TvSjzlS1dtN2pGKLYsi6pYqCcxGCWOjNFo25QjzaeVQzWHvMCOdVkFTMS/th
Q08+uVKzR7xSlvpp/8CPzs5elxpzpkEMUwWOaR2EBDXt8PXEVHM/jpky9+oN
S6dsZtkjDQH8uK39EGIPa9UrMKOTlyGCxQbXqRYLHKQ5gnHDPBoXHoND/gds
a0I51XXs0oltJ8b9MCyJFKQ3bFoiMyRFdeIhCCY4sTgQ6FJSxifcFIsl4YYQ
PbzSvzFysK6nLguJlA9jfWVMWDxmid6I5HszM+xIScKJeMQVa4d81+kwvUUW
um3ZkmRE64YIZXowsInA8KmcebXCVUXHQi6b0ZgBxpyL7V6Knznd3G3Lxlr6
bwdsJJFzdleVP0NeWZYfC7eGhlfdjvxLRCT5czxQe5evAxL1PAtq3VN2BQWH
baAtUxWW8Pg+Rxwh/1SX84wpvdgT/WBwnEN7k0XRMJBqy3bVqhxm3Ep+J+EJ
Q0P5qOYydD1dbNpglNWVwu/AihThhN5hGudBw73I19BtMciCrp/sw1hnhCoT
h8MmOkB3YUkaMMnbxT0dr4wowmtkf5Lzh+KPS6THDgpDJ3/Hlm4+cXnPsEOh
aLaYER8cq+B8Smy1IZZbLhbi3gKedhCO1fi2JLYHDPeHYkJ0epD+YDxW9g6H
3nAASg7z6bxu2sI0WD7KNZxUQFS5DucQutiiduYtajcx3XVHtIIu7+xQy8in
A+NkKud7I7IJrRFHco+a7pje0AzEqyHotXf0OyAdMQogdg4VbsQqKOOgDkZE
KfJDRALrKt8yJ/QoZF6V6CHYna4vZO1fZGb0a/0saJEs0nlbE5aShzvB/hcP
oFVRCOKSMgKnYS5CkDcsEuL17bS0xmkxyzdMfcJItxtiNXS5AIzxLkk24XdE
8C/oAK8VMi8mz/BzbPX8Q3adWF8YQ0IMTHZqZ4OzhhaWHA/f8vj48p6ytSur
99yfsWdrkp2ItBIdZhHPL/C18ypbomwWjwNdrQALMaHgKFhMx+/yLUHI2z7P
I/Vl/+jd5fkBXbGPBWkm8/rnPVs2E+6aeGE1Jyr7UXRTkrgRfePNp2fsYLfd
/PM2jewCWJ7ap7y/jXAqX46IBRm0MRm0OnHzL5jZrggMn4TH83Ym7gP9thRK
QM/iHUZiulL9ecyINTigaHRCnjocE+yDuwvl4CcYSNp46Z5y8RTEJIQL8DjZ
3niPyaVc0UblHvwig1Wb1VT8K3z9FeQkUGRv6I4Un3OsYuQeCbs6PASN9G/O
lTvHayBYjcvDwz095ktg2LVgFA72O6hOi5xkVRiUwWfM6wP6pCjJjlbZIuwz
RaUXnO7FDE5sjRqL5eBKDTCGx3BKM3bffHeS7Yedw1DkGS1snyRC7OiEB6Ns
Uy3hOGRrFFu+SL5m82l+SyrESh2loCd5pcwMCvTQBtWvCvmgUXEQ72GLrBnm
UIiIr2wQ8qDQwN6dv7P0SN+aQIMkW1QAyOsDy3cDy88Glt8nTB6V8ayf8evn
KilB7EBAnDpX81uSPdpOIyacPqtmlR/UxyE8GGE1G777UxL3CjpjpvnVfDDk
gmZOIwPYPtSULfP9MJbcyIyYCN1mujL3tQAXFxk7h3HQlsUWFd28PmOC+8eq
vl8Wc1MjIeF5uImAS8xruSQuszU48lNiRFF7f7EbH+KdFqN4l7yeFy+eq4uE
D4rkHVmwy5eIVxQDnwQkiTenNj8cPyza2awEYaM7OSvCqJBq2PUDTyFkVyAJ
y9ubILYD8BC4xs/1DDYkPgOFIIpBYOCrw8oWG2lz86TyfZ3QFf8EV1ss0FqE
TKtSIOuIIUAGNI3kuUi6N1GBhxxFRrgIVqQydyQ/6iPENp1ortO/wRsFbS7y
g4ucds1qjddFsT22KonsOKwgRX4sU5FgX2h3DAzxM86bGuYFCeFLk/tMbDCh
Qbj0aICppwKrOvV+ZoW5iRRmXiG7tiVsZ+Q/0NVwixrKF1CpZcYEPQoohMWI
qSCK9oCAh0d5kpHdP5U3Q+gYPG90nOy+C4rqvrc5hO+AnfWMzhjTwWPnvIf+
YJKCPJiimEx5B7CqItEawT7a2DbADECgznjG1gXeg1AGz1SIDmxaNbeybVJf
ikL9YITHnj2Evc1TfCC0GB05xGTgywc2P4XKSarDHPT/2bgmbbyjq1TdwghY
Fss5LiTfRxaDSS6OTafw+oo5wd51ybvGvFJT+PFljAHqaRZthe4kjFXLzruc
yxjCNVTLzhtoImzGMneWp0uLXss5zjDmTOzyYBcNURvcFBsFSCSQJNWIgJ7Y
l/cHFdWDjJ0rYt8fYk0EbaIetXcwDwJcbkSwo+ikfhuxWdTxlY1D0G4CJvKU
go5qwId76xPdddZ25alI85mW4iZXE6NSCcNXdiOxYi1gARPf4fSgg8zg4OUB
XWeZwUiHe4B09PSBy2AXLmLF3Swt4Jed6e6iJtlxgGGzWYudlJESzjdhoipw
m6kDVi1l9rrrm8ZyUbzmTKPbWhFFptxgzziaZqu280Hoq4jgSWPQS+VkCO5q
OuSd8lum4MACXG9uBYDXN1enR++zN2fngW0J+lZ1thDfglh/2cA8LRQZBceV
/Fj8T5DbwhINjfcJj01Ai2jQzupowQui1MzSljnJUTYAeMU/sW4XrzuL190U
hFeYF0LD7a7xmG2MG8Ru+idSnN5BeRtd7PUcKdij51+Z01ZPD8yCJfiY+Bxq
uBrJl+w2dy/kNAlloG2m+vizydOEtSIKSdHy/dFfQTOFlwG5lNcrxyOcg1LX
gyrCnKcQSb1e7Oz4ZHUe0ZSgyMaiaTkORO3HWMKqruD/FqLByoijRezNcwIp
rWjPOzoyMe3CHkACXuWlj3tmkay91uZH0Vt7lyO+ji6VY1DCXM9o1A+2NdbR
lauChFy4QCT4rvi8lt14Q08T8TQ/PEOETr5gV0TdjL789fTV2PYYoL6rBQNw
GlGZSyil3SLV50jFYHXcwBigeLaQF9SyUnGaB0FwPqCs0yyzJYeC901bbKeg
C6FpB9nZSevcj5ApzEOUmMYGaLcRqjCCsS34g6FC/lI0tcosgltJRBVUIpHm
8HFT5atpebupN60o+EvvdfP0NonP1huDVUQr8FIIDsFcPOZiA+4nPitM7OOb
OFRZR+o4gDO25wbpfeJikwK/DzDBpMgIAXeOCAepAZp5PIJg1TZF547Ulsb5
E8+Ausj8SsBfBfqUiiKVhmzFspIzU6DqpAADY0u40BG02nU+K3x4YLuBwEgH
Nd+asikH9Rb5GxwmHr9M6z3MYj2ZAc0oRK/d5w1vI49FIQEoliZIVfVga2aF
MIszlFJ/XsF2klrGVmtPs1kWu1akTozCYO0ED4SlFJV7fGE76/HC2agPOTZi
eEzPGNPF206bO20agttxzUHHNyld458g1KmnNJJ5cWyIn8ryabNZs2zKwffi
xbToT74GLGNDKIxiPv3O4zkwnsuntBeMgbNVJuGDSeG4W3EwYYcYQ5CLnu2a
iOnJxQ8/nV/8dHp1dXGV7R9+Pjx47V7DS8BzTTIfYSpxmNhESnEyVpiZCFSk
+bdqr2LiNGeXjcuCSafSgTnCt7wlZjyRNZyd35xenR+9Cyt5yiu5URN/jy1E
xJFj6Tk9MjcIccgTpw3ka5ZxieZm8N61myTCN/c72HUQ0Joury5uLo4vojU9
++I19Q9Nl4T8uXIKO4menABnd26EEZ5e3/x0fHR+fPru3ekJpn/O0x8JwRHx
UvVEMVIJRPWCkD6Tqyd4Bhl8SWug2WJKFAFBpz39y/Hp9fXZn09/endxxHO+
iObsbXhobsYQQ7U8xpP5RuLFP7NAQ+R0WedznfbD+fXl6fHZm7PTkwDsr79k
ZrXX56SUQM9gIYkVfh/bHi4NYbPuElMQiK9Pr/4skJ0fvvq2yL8uZMrIeBXe
DiH8XdHCegTBCQIdW2P5uTFfzV9/5afEnMJkviluYRFms1FV3Mf3WBl25ILL
jvm0lupUOKvUvWjc+/rm4vKn69Pzk7Pz75kRYjVq78vWBZG1WZG3/Rh2oj0m
+0POyGMcuodDIUWUBE10khFwSkR/cBSnkkO8npFGG5pitVEBJYLiIHJP3FnH
Mg0bdx88QA/IPrMYOgTJdRyCFnN0U4xIJ4J5EfIly3isfaj4iLxDaM3lIrJT
e0mFpQ5jqxAWWWMZBYvVLDf5zOBMQ7N5a8umReJX4tQgwrESQMvIsvTUG9LX
cYx95lMCeV0xizZBnpFBJdcUApBZoBIz8IJmHrSS55OvU60kcz1lGXZ12CDK
alPE+km+s0QB29avJE/W0tN3VGbuXXSVh1WC7uqOSIxJVXQSsKpxFIqc6yy6
OXSzHpGn22jmQTk6s+h3HOLI2fMgqYpzd8VyHdwk083tLX4wJB7A+pS2TkST
ZT+HBAVzhta8GNeLhXcvYBIMe1vXRHtynJVpaDynBrmy6OBD1eZFVeZLBBup
0Rx5NTCmSGgRyJfhMrRMia1okcexFhoDxXFWNrPNSsJTQmSS+BHY1XxfIPj7
rmbg1WI/CIaWlMSd110RBWsEA4C31eZsRJQ4NmjPudlxjCSZpJxYZ0UPZ7rK
0vRt+cmrnwMBTeGke764GBfNd/TfxXGwlZufREV0hpkshUakYMomjPgb09rb
noaZmIZZOFV5PpkIu7MRgukiWWgbSIV62qBKl11CxjiPiFBBXJciNEs6B+7b
7vOcBeNDyT1llGxkc2v2NrTL8VisbsMZcOQ4HETIcVwWXZFGY0y3nhnmSTpi
th9r8Qdm/4he/qr1ZrbgqcEVj40VyZDhXHJ2bKhcnGiKuRoUszfE8RHQvA/J
4s3R2btRFjsAD4yGTguE7IgbQXUdQ4ywtykChPKwEm9D9WGIUERMJbcZ4Zhf
sNeBV9QTgx8CnApnO6I0eL7TRRveMddPkG+ByG9B1Ijm+b2aLrUr5/M77vcy
uuw4MlKJiSW1r2yqtibtqfR1XdSbRoArujYyB1WpiKq3kolan2Sk1OL3ELR1
U648OWO5//8/NfuDZFKIBmLX64Kvs5xQSEQLvi9FArp6GnArkoncQLbkmNXM
eQ+IhhjniS6h9kALPdznvJimSGwWXX0A+pMb4tdNkK/4eNitrHq5hhwgTRUK
eWxG+K0hIgupHq/8yKsWJxpduk4dZyhsY5MGAqZKxpCbJp7/d87qTZCeYvFg
/S2shFHglMwVpaYj8cwMLyBw4mCEikoghPfV3mQHm2X7YnsacBRypLMsQGPX
jjIJ4Tx4EAy70rcaYHfOLOSjBz4WASmCqPgbMk/LvBKU2HDV3P5wfPDBBKuu
+iLnAPppfKrZDgokZXWz9fhjUaxzRN7RYk6Jbu0fHmhsvk8ZeYZsJSzFobIB
Um2Q4z8WOyImpXX0cNijgGZDM+DZrp7TFUwcGbEf/4+PvrgT3zh9ZKAIV5Eo
v17mW/CPvVSgqLKLkGqwv/AnKacIZUcIFWLHEUiHyFqTqLMxjq/wSWp0TpKk
MA5JCnxWh+OmYxgJV2P91kvyrQ9sM7ZTSV4sxJSy9bHmbJBZ5J1xNYTNG1dL
LTJ941YINiHJ4fji/Fxi+X46fndxfRrIvtjuekovNOyeCpBalFjJ4Iw1lkBE
vz76q0M0EjJ623LJ8cvG+nqLs+R3NoYsivvCx8Qua/WgM7K1DvR3xZEgQVFR
ERHhLHKLKiySiQ1oByK74Bs669TYLAE0Xs7j1CeLYtu0PrKEoEhSsF0GKdbB
9nn3sH0+MdXeHF8+Oalv6N+33kirDG3YLuPzHRNXckvbZJowYEbQzIEImcex
5ojss/RXfrVFyAqOGWlZmjRlPxjH6xuB4UrsEIaktWtA1crqE/KTQu7RQoTG
2MVNnJPjFdtJdm72IifDqu0iCrxfbBC/k0RdsmGbqWGwl+yECwyZTNx36mXo
maksfsumNWkkSgYcGRrYdeQFs7WhikQHiV/43MnyiM6sO31pUyGCrYrvjEVL
cOy8bAKen0+oseZFyh3j4UBsKiRFmLm8/isBWCF7qqev0wJJL4YBLoh2063l
dURwEZGm9VJCki8v427NKDBge5z0Q67fe8bgXLDKPD38nVFYoySNPu+SuFM9
SzHRy7KjDDPS8ZhUi8MVH82JIG/QN5wfwIF2yCOmlZpAzq47ZQKerZoLTsmj
oUwRk414ygkNJ/I3CHn0gy90YdgHw51mDxafJdPaiOIKCZHlL0QdkvpKyMKa
ZJd0xWLg9jzxXwJeaARiHQQ1IoTcDO5FuNBqvVHs5UAezdXUx/nd1uXzTyhM
1gZ3HuJAiTav65IJwaUPjeqlUEmaro99x/TOpk9y9oTsDcogk3CGekyx89/v
CIRJnPXCjcqmF94bwvBGnlbYdvA+QRGxcRzr6QNG9Ai9jUSlGDCNxAcvrr4g
K60bRNaJYMrmp5zJVoixUdXaFhRU2dldQbo1afziFUy3CKnC6s0R80UQViNS
cvJgw4Z0GrPUohy6Kp3isZCfgTwSHoyIycjtDhWHVGODEcjlwulMySzJnY+O
l2NLgvE5OcE2hVhspUpoAtFyxDxOSP63+lsQDWAYGnJ0G9AH7KwYijX15fZL
ZS0fbp3KV4knczJMkh6y9oo6QzeRlttxEg2zYSeWL47qNVXw0UWaZSKe1En4
Es5I8NzHXcS+MTkQf1noVFjSldi2YFvsEV5bl+FPMibECkQba6BoyX7kW64s
ljg/NcAqenPItYCQZE0jvvISOu9Tqmw6jwoA8mBa80AechggjsFWvszQeLQY
Ht7m31FOICkf0HPZ+BQN+m416ZM6o6cuVLHyidBSQyJv23omehObIgZ2ondl
TlzCvFJg+T3zUFI7EBbOAuTflF1v//cVOoLxAciJEBpfc6NfqWuSsdeov3Je
UxzYbTUF5IEx9iNa1hiK3K+/OpNxdx/b1dEgK9t97OnRA4m+MSci6Ybvks4N
XW9oeI1U7OFIsNJbhShjAWLVTJyiYnhyDymybfD19Hg8171JLM9K5kjhJ25w
cXl8cXIqNadOr/4KaY9WdPbmrzxlpHuGiY12SQSjCvsyzrXfkzPXJB1XSOZH
0CrsGfTKmG3HW/PuqL85D+ccl5ZYEJvb2sI4a46NcnMt0pMlTriQDdnHbw1L
BfOoBQx8EWheE8b0XbiPeNWjKM8qyRiOMgTj7MSXsRSG6pZ+ZWFkhUdIVYvi
WyzdvWIM8hBPzs9bfhPQSmKxat1Ok9Rq6CWVp10h0EcrZG0aEZZ/2BSboqdK
x/TVF1CyIGNS8iXS0QuZPsvQ+RhOM7vOR3FGaQ9iT3cg9kcizvAuKxsfXpEa
U73tnxWeq9M3H65PTyRzucpOP2vyNu5TiHrK9k9PTg+yvZu6zk7zZrndi0+5
sJeugNDuoTRxkOmX3756qgQ8eVM9LE098A698uLXX/8VdiPHYiyhh6R41oux
jYC0v0ipHXd1PS6wUnZl/zE7HmL/3rPyuLlG6gmoseKalQtOPfshSgK4CmGM
TQi9Tqv8iYYidB1Vq6CPEftvtm6zxtE9+z8vn4lNOipkl+QdSNUEMcIIiCzN
W4y0q/wzVAxnNTtffv31869tSC1Kwk9IVU8uQcGlvb20bro8tBBN6TAzTZoW
UvUzOoK7K610RDxas+GkkI5QFJ2OD7s0iwi+2Ysi4Lj4t06/54uhDtcNnIhc
KNuJUmgim5XylFPT8elMk/wvLHn/lEsVp9jK9SEgmInKoSnvkK6QZGjwAUgV
yr4mEvvhbqu6EQhzOa3duCYLBXAkbxBPDwY3O614CgwZnysXYE5Z8FVUFI+R
9ygpfOs43pUh9GDh1F7yX69yblx1z+VNVPa3nwu+U8GLq9g9UirLfUGprImd
/Kvnz1A5sFP/ed7FZYedTx0M6R6cQzWj0xB5T1+y0ApcyE3rCzrGFYVVu51k
37NzDmKDr2qbL1GOyROTHqxWRFWWPu5WktmRaOgis3Hua0ql764FQkG/SH/2
BixLSXQPJ3Fa7HByOjCkAGIEy4lgRVK28jfPPnvs7PXWvyKiwPKcId3vq8Ab
IWK6ELezkE0VkvQsEqKUunD3NLLlU/o1Wx5m5ZJ6xCp4+2J8Qv/fEBVgzzyt
VRyql74giNScMq6iwQDsueDTiasZPFC+QpW2OAsj1MR1CyhzNjlulPLPKtTf
5UBfVGeEjXW3/Bq95H7XNXygYp2Lr+EoRA4Fu1BUTo1RV9JCZ6nmhVNj76Se
8dmlVb+2e0z651dethRfwPt6Wvq8tdbX7mnrMJyYlqS+Slw1gvRJcaonE7E3
dF1AYhDT9DRHeR52hK6jhLNac0vBMzjOiuuGc4KoZqeM4rMkIX/T+qrXqaQX
Gf0b72muzVqQ7/hEYwBkWU9/hSRsWILdxllwlhSblvyOhlPdQUwdLDHTlst6
nu1rzTeWgknCh0nCarocTLIsPs4gHUvoKCQyGA9QLHW8LivIcT2EcPsxHh4w
qk/VAZXfsp2CbR5T6BZN0TVSqpYl54FLowW8wOO0fPqfffn02JL+7e+29Fqp
SR3XhXHjInWhfpIqLdMC67WUWavpjoChUDFEwvLaYVGA9RDNoRSBfldDFUlS
ghzZcEh4ynGQ4CXxVCIWImWFTvu5lkzoz9gzh0gTkVurIedLk5l/cwAgogtc
4bQ0fbMNQBpWY74lNeahHPOHEkVNuvIjS/AoXPZPRatDIibXIKJFR3W9CY82
Dd1Mwql8WnJnFLNNpbX3WfQV7B5FnT2cGXSP6/oj5wZ5i4Rh8zfC5Ibga3Y2
BmoxgKhD8PPRVzZYDPv4XdzjN+IKjNpYBSC5B8H//Hen+Et/i6gGq29KoL0A
svPTH3+6ufjT6bkEh0kop5lkvfor3ziDeumbHkjwUdRMgO8WXpEDJnaTL+n0
rMKhT0pOHF1JomPkX2AhRebUorNSuWzAb4hLqBVBfaEQNdWlxdz0LvclH31u
bM9JZVmM8LcNEX026ZXV3yyXZmFF1rRdzIwzjeF4BRUuShY4pltfig2cg2RZ
FElJFESvlDtzxesWQ3yKaGLPYUetkzH56M1WvS/atveVvdrNWj0zRXbkh1Cp
KxpJu1zIfjS3v+QyKsAFrfHIAelemPWOXhdKso58RSyWSFeIA4mgxvjHxuey
4hYUHCjCcWMAj6CiFTOln33JFBEeaeYFVLyZFA7NNmugojJwljBs9hhGzuvv
aTlLO4y4Gv06ioHgwLuKo1xlOhzX7pbKKj0RtWz3rK3WDar4rJRwTvCDznJ0
eWY6P8mF89apbSiw7LQcjniAv2gODC2GV0490fWuEXq5HUm3r6gkSRIdQwhC
bwelCbN5RGHzgpTVRBgwj88ZXIvyM5K1YXmZ6DJ/E+NU3Qn1DuiQ8QU48+4i
+b4XFQryqfVYSz4MtxLi+qS0AjZA02DpiuP1xnYyu5K2dh9skAZpZMH0Jfd0
J65BZV8NwufsZK2PJLsBiDnSxlBpIYFRDslaTM7ZwykVVxrRF8d43zso40xK
G2VZ3xLhUyNWK90ptMwjk6ehwjieTKSZWuwqhCdSkCZZrIJtWEjRejGmR0b4
6/NFTz9DkOU3l2waIEq7Z1TwkuODRddxv20IotM68KaHFy+/genhR258Fs/C
vtt2d0Fa4xThmGxhCxRsK+K/bZGTGa0Pga+8fjOKO6JFgcU78gVnXi42PnK+
zLWtGguPrl+nJ408eYsQPWaC0h4qTZWFbW/8mH3JwPPNNy9fcgMGiYN2QkPn
XF+e6XudWgxHvma7YVRUEVH03B+UfjmLFvRB1iaZ5XNOcxGvk23oTjdkSeka
RRZt+aqAi869JWSvG8LpgdJ7sZaDs5IQJR9XyRUTcPmQoR2LHr5einf/0yZq
cKymg/Fup8b6rOaqfEiocLMB37WFFajmluiZwKYoccBzoeH8enU/awT6GmFj
LVeU6RUCeKCfU8yrcRa5uIBQ7WyUDej4Fp5QNs6IKNq6SQvHZRQVkRSuGqoq
E9UDleznuFKd1ITqb92qM7MO/FC9gxAXAk3aVz3eyYJcc8ky9twZqLFurqdj
JYKAYVcaYZMEc11y58EsBN1w+aK4eiZyZuZJLQCWiKHbNF0u8W4QEe4KEn3v
tqGWmtDSUJYQlYp2wprVEuKjXpl8ThEK5yvExi0MudujC7ajgdJN4bazrB7V
A2R8kB46NBZLFMf+yBPtZD+Ili8nz7wiaMMa8SDkjh98YSIomxQRP31tVczT
Is/x+D6GTgY/cM6ydVDprUbWE2IrISRpAW45xOLzHZFr78uT5DpJpWGzchRr
In5RPSrYhhA1TvwStqKNnlW/IFQvaDiJ3nrIg/a7Itd6ZD8bDIwxh6qPJdqN
cTexxQ1FuKsN2esf5vjK+7aa/aiibcSSzGOpbicEAbPhsY371h1Mdrqi+uq6
kPn9YH0GzCqFwlTC7Sy0MKbZw6DRxi1CZOmHJ3AQMsmPXnV9A2ho6hcETx+P
TXRM7YUWzQsUgbmPtVknBjhmP1yQHDGGVqGfltN0/tEsevSOZEH/rFIiKXEu
nm6OUN8J4bEy6PLMbkMseKS5/iIEikJC+n1gTwAZ60AhTi2pEmwhakaSLWBA
Ygn7dQIc225CiS7W6FDYMcSNAih2jIt+QBmH5nknq3S5EDdgmj28SOPe1NO2
5SIWEOaFUHNgt3hoLe4hVkBn8cXHlwJGTvSWVBbaorOOsWK0AAhIEE8D+UxI
1M4FYpM1nnL9WNwUZ18kuf4zDpZ2Zm9FvdGkuKP78uAeH+/+eMjQpFcLZUgA
5lD4qPFIF2KVnCxROgkX1d9qb6+LZY24yVscu2HuG+WOSW5C4vv4rRyT3RjY
DQvzHujE3iR+r+K6gLNi179ytGY68Dk7nrxwXJhAVIYXL6EyxGV2Z7s2fEw3
EFkmyrjzdcgMa5gm4H5K5PM8Wr+ZWTRucLehKJe8bndCboPZKNjvPBPiyIvs
IVO6pH9GgXJoY40eF3q6ggMV3nwsEk3XOg5rHctacT6946m1sabolQ9u0orW
iLLFZhzZp8LaxVFOTGrY2iiUzvfZs+3IfYoSxpPs2IHjM6zRsJtebDH06XJR
sH9SM+9esrelPRi5tk790pZDya4eUbnVJAguncQFM8eGPauxLgjQsZfRYTu+
iyBDDy96srPLxAqNYggaa5XEb6a3ro8vehu8NgbbF/OVOA2ivFV5Cd7iqA/Y
rlVdbSDmtAhmlrgrgB8uqnbLApVLlvhqF6XjZjzSZKUfMO0LBahATihvFUcH
r6y2hJug08Jvh2YCRcYmPRqRblXUixbnOHgUIV/e0wYuorznUdozLYJXYu64
yGwJFzz0VBuLuXhHIn4WYYwZI6Mg8nSH2tDNyidYoBRt9tLaKXG/iWGE+SYR
2LMvNUu4xCwxCv3N+P5ELRXjNrPCjpBPwPUv4mRZ0W14tV6YURxbZXE7Hg4k
tZpi2yAwIALFdMgoA1cA54VWq68Z2vOsawLbdBn15oFuivWxfCCCpfdihbEl
uc6344Glwte41EP5jzi8wyURGlHmUNq7NPTq/gt6dScd59VSnnmWJ72Ms/0z
9De2KgjS0zjbP+Kmxwg1jLXISV95k1KBUTk4MU7SXmkBPfHbnC6dlLPj3ivw
udS3AgSUcks7L/u+Ukoy6OBSbeCislamDFGaHY07tGYbXAj+6Lxti6sUF85C
D0KCUGKu4V3E7URM3UlWuNMIoqvnuVaKfkTUws5Z4+a4h1i/i9rbaDqut5YE
g0yGA4syqitOiVdbUc9y8t+f5Oh3T/KAGZjbUv3RCwHs2et3HfDdenlWoG26
R8t5oXdlvExLNmxteNWK67YIbyVUYaelFhugNiBoE9IhiBJwSjTdXpvBoi40
BvdRs5LplBFQdJR9633kUZ1rhJdrdPJMU+OhixuehYEOeltMy/96I6aVsRna
aFBwsVdbmd+ZGfQ0vkMD26X+IR33XIKqoNKpKBAZ4dPStCb9aQ3O1FM3HGoe
9czwYdODLD56S6I8h0ywIebTwectbQl0e5ZTKYmqI3aKr6TMK+ln+muwilib
OAz/6KNsFKnMyLdchmqxb/q6+sjNImFqZ4WclGB5tFKeNdqYAdJec2DzUSKF
96J7D38dSpQkNuM38blotVEpXM9OdMtojMwhHBGoaxllt8t6mgunRUyW1cuP
R9WqXsmaBwFIrFcPUssogT6Es3bpWffB8MCQttQJIl82cTe1rq7VASht2n1p
8BKyPheqiTTa4fe5dKwKteJoDUmg7HegqVE5kTsbFCvEjwcL5WS3KU8TtbVu
1TIhJg7Sbv62QW2qAdB2taNDyDVNU4xds6LRZJlg6h31ZIQ+mU7m0znUS2aH
mCNObiksWj2vTK0FEOxhCYyjx8MBNK5DJjRhzi6LkjO4goEoakzbx/KA4Q9d
RGeHPkQQ1Ok8LW7LisntjjnK6Isl+Ya6hprZ5cXZaJWWyzw3K19Pm4m6Ut2w
39yCzHXPcZYL25QVJIl+2O7e+QQa7tErYNDYRMZDfo7r7bMiKan+ni580IpK
dkMSA14bFhnB4d6CRSQmGpIVMXpClspCtEwKitKkBsLgr9n5+/+gP1fcV9s3
L5T4eXYv05LEP/hADy+fip6kRvc9s/2YZbTT9MhFCzjjCl1FN+ZuZCMrLTvN
tY14jngZeilf9pOt2GD/6oV0wX06yY7m32/go1nmm2rGPiiWtYayALSQIEKI
CbvYhPrs8Nmh2kc5JY65/rLgZcDOUUpxRqkIL74UOn6LtY9CUF+z0EDr+U9b
0PG//AvztmU5bbh01n/tD7RwP5qjFd78hvjDk5OqfVdOSWY5MglEMgDqz1sd
ZZvMy3w+jXMIjR19abhorDEI75h7WvtPSD6Rz8eIeLA4afmRxdD9IooPOBDp
6BltVLqb0+J+c2Nzog94kHZmrXH8zmx5g93IvmR/6cZ2dtvb32h3g5PsPcmt
tabXM5XgUGk4bh4Zzs+ZiRATQcxcmHjzOUHqmMbn2C0MC4HUcIS+/E3gzZBw
U7UHtpQz01eH5hxD9zT4hQXQ+8u6/rhZD86GgLK7j/WnJ/6xg+xajgmKGQCG
jr+2gE0n+jr7Bz/KUcpraEcVH50QkuTcXmfrZS4JV+GsJJfkZiSGBzuqiQOW
/bApZ/P658GFs2GnK5DbVa837ZOf5dmDTF+S/nGCcTxZfI8HfcvcjJjeQo5F
x30osuORJ0sY4z8vyxn35PuiFa31Ybo2OIc3S/CFuwblGAbfx5leHF0dP1lE
Tz4h8bHg/DE+bh4PS2GdKdkTgzryN3CbAKKLZv8t5CbZCYZdYjgQLF8DQeup
+eCjYWi5F7SpvHwYHvRb082e6CMHuuQHYvJkGZdb0lIrOQhDda1SafJ7kF+S
uBjURPFbfy8taTVv7Kb26T91034V+syNUCJ5WhDrIGWZbeNtR2SlkJInbEkz
1HwrpKP+gUWg0MRyW3RxeCRJC3P20hWI7+FoUPNQeN6QcCjnOVSQcgMwcyEF
DM2iejIlFTlFhcldt1oehBqfzkqnKyL4kAgST/dZIxGT3FYDVw90p6GMpxSO
CCFw/vKOIqmZ3i+REDYVh9ensqmrlWgpV1JyQhUrRKdpmXMppWj9JmDg+QBb
HxeDQKrFfTknodnqeEoeRWGuhijxhLehj/HLa66lZ0F+ViRHC7lHu6ND5Ip5
lwYajd0d3olNIfIn9M5WKh2WQEMWBVCSP7R4QoxIXoWoicQ3yu0HUH645r4s
UhtZZ9XsnDb7VObo0k3Dxpb/KAQH/W6H40RQvuLmDspxdmQB3T5BC0vKzqE5
Xm/brlhJHf9NFQlVz799/lzcoGqL4RHu80AMo1Iqc4QG1GuLAerfEOkeTXgz
zYFocVMFDYfx3Zt0L/16QJrzdGex43KKZpYTO5ZMnOSCTSSlbMccH2WLscct
ztDyqaPu0dRR5NerEpPUhODkHkSg1dW4rMb0yFjacltqzChp083KIOLQRBpm
hYMJREh5S/GGtBztw22Nabwp+aGMw1624STrN8ROsw8JKL+VG6lFrUWVS9Vl
b3neSaCUU1r0MzGtJN7NSCzdHqmki8ryQaSQCugdLSo2jAd86GkKScKmUNyl
9qyRbgQarNm1xXIR/QiRDgklvh2nF0en3v/kTBXyx6R5FXOSeG7ZizWUTAFM
/O748ukrbnAncpsZ4K3YiUUaEtZYhT0rgZJkZfgeXDvJDH8wZ+MOhbiJoLx7
44aCni1OlVe/JyK/ODLTsff0kr06/AbuEUHYEPkaAptcb14/fqe9xiWzl0u/
Rh1qbxLS4guihGos1n6NS4JAfBWWN8r2rgYiqaKNcJQO6YXugl2fJB7spSnZ
+9oJoWZ7SdT9dWR5AiqQCNb2N2jTmRfSMrlFGIINYydW2D9Dh6mSEWkBdB6+
tnpk60WomWKs1RB48dLXpSjN49tG2Wi+o8Yi22Ozw56WZ7mR2qY+Olms3Co1
WggQY7p0xSEpo8lLJqP3tbevvWbFnJQcACzXaFkxg7CbvfPFcJj6iROOLW9q
EAWnYweDCU5ar8QXBw3FXX206DPu87NbZSe910NFYazRhd81z00az0fzTBoa
tpuZNX7xEbviRBZ2BhNQXLKIeeSX1ixSX+KXhjWZY1qQ6kym/RHxGQG0cd2h
2AIm5yC2mzycksYm85MI6uua8hYhfRb0Nt26/Isy3r23epIggQYKKqI70o1Q
G55NRIg59R1yB6YgHitZ7ZazBuFmytVT2Lks3dc3aHAIsz7czNyWUTq7WldM
CUpTi2Jib5Oe2uhqLf14uDFaLjl5Ps/dKCfkmmXBxQ9lDWbfNDR1AU37G0kK
Gcb0tEer91xMTzUwiTlKJjU5NFFemYScJYel2WIMPIzCzgxvCj8ZEKo9KN7W
bmbgaDGFIXYzSGHEGwC5SKl2gW8qqwRmTcJl7IlUVPIpYD5zLMZHYDtbX0lu
IdWXPlfEUNHgTdMq+I17UKaikracIUMOZ4sKY0p3S+7hRPBqPxb3TGQsBz6m
gSqH9tqpY6jBLSctfNGRwJtCfOSk4/sTJFdk68J6gI4ocYt6q6kk5Hlu+WpQ
EkQWXG4dCeh0exC9L2Q/Ck2TEK5MM5I4W9qK5g6YlF2UbuLTphJTgVJ1X9xL
bCdK0tW943pg6mpLQ+NWXbxj7Q1EG9daMVgjV6XiZqeSBhe3SE6Zc5lKHL8V
76hE83dUYUvM1O0XzcHN14Xt1iTi1VOOStGYQI/gmRf3zbMsmkboIrlbhg2u
JXTR0GgjibpGsBR8yyKxh8KDyugCJYhlS6lZ7cUur9XERHrA4pCqNz4VSYcX
D95UtGKo1uaOGdKUHuQCcdUT63LOPsxYvsXCH2ZpQzHfNz7dZjf0L2b/IXh6
xqeH8xr7MO8ohlJyjExaiqvW3YQLEYsF2kxkuK5iEpFplRy1iJOPUERwp29M
2MKABCsdMURwTt/viDOUujtnYsiuFUzEK6H4TE4LLfQZVa6UyXBffPoqEKXJ
FbeteD+fJbttVFPzwS8oyd4FaedxwA+556VxamHaK/vXPPB9zSHzotkvo6CJ
DSzYhFaOCsAJfSqbbpMvXZqyooP5TkSl+O1+DtF8WuNU489FUNqEUsa+CEmd
cVlzrZrlVxHH+jOZ8NYPi6GzfkPlIq6PazG/pGmDArNahkwpvZEPx+Ky6iDY
6nxgr5Ql0NhF78q1EM5QL2CX5ykp/BJKatooEXjNM1AhRN2gypo+xAHKu4Hn
XnSRqh8mLfitiF8RebUQdgq2Ky421tNG0Ic5ioxPV8wbdZySUz9DMOGpOXt4
Nm852Tdjjz7n4udC3R07tAOFqKl4UQ1Uphwq+FppHmNBhDQxiW6jvn0cXUMI
7FZ1V37y3HbdaEdtmYevp6llviA1IilhrlMg2K0NNuoB6h2lf/Tyv8GESN5O
ig1xHDysNsvyYyEMR1cmNxskdx5SRoyfc9jJYBoIAOSjn1lOzSUI3oIXtRLt
wDVAL26jr9HJWPSBV92ConbqzRypWWpf7UUHWVTQGdlZzKFDCavsrpxbohsI
QSjAopiK9giAqg9eCDXIuItQF3igFBRHhEIaEIIZE1u7P2VkeYO9Wg1E3+jd
JYUZonqjvXgTwJor/IqVXSQGix1MTFrtQE29eJKH+fVAaZcbTmRwidGraIdS
HhLN45FcjQ+EENJ14aG8CWNCkYM0qnLELi6CS6ZZY66XzjTx29jNx2BT53at
BZA7rR2Qx0W51L5nUSa+H1yc8dEWSYKHlcDfrHeqpDvpAR3HREubZZ0sOKD6
iRbWmfE+t3oQoBHsw9poQ0BM5QcSduprtogL5PzohltB7CaOhRsihKviig0h
oBKMnyvV797RKO/HG9kkYOlnDbzoxH9EL316efCgHCZ6+yKqptaiforC2T2c
VSPcUnp2IJJzC+eMMhiBiiee/yzLjJmdmRrAc3yaWCKrhcylToUHztXdsV05
hNTfSmmEvg7r80pnPjudtcTQI9C6Nrbobw/0MLtFSkQfvubvIGKdmIh1bZKc
Owq1/Aj9QsMbrrOymxvWmuIr2aIDYlv72pWLiNmbsMS+bwlD5vdATkd8cD5N
P4r52knajGLle5UNOYGz9dEAREnvMo5fZLfNpgtWABg+iYduBCE4iMjUKGPT
BEbou7Sglgg6giQGBOdcVcWYTnFGFIsedjJpzT+P8sJYhkEn99KrHxLPL3UR
4hjIfKhHtSiAw5Xwh1KTnE8zMp9+nEQezi9m2o8mGI04TcTc/8kbOmuhGYA5
oeT4Tdnr5ZFnaInECf1q/YnO3Ouj8qi2Cu0PkzQvvVe66Lwnsq8/GcXA7db+
I3bFzXwslvf4KF2kaPSOMYlLHjBVMQmKgqbH4YWxP5cxQXGs6NgjRkFqNfO9
5KwIR3sApYRxhKyIRJWxpKkbNdWaN5okLyk3yyQrqQelvY1FLBvFNmm+wLBN
wUUAFir2OTpxF2yvSdUlbnUh4beDBY/YPsMBt0hP4jeRcM31yt5bEdkQRYqV
reD/5vO5L6bZtCGZgo3b7+pcG5F6Lx494Na4JbjQ6kJVKVvKbf5ShKIsXBlW
ul5UsWQlpdsRfqbRctr5jy3OoYFi1MYbZTlkL8ym9/CUdjYP3U1deGpvpHi/
g5YpLHkb5gwSk6uLD6KvDSvcuGJUVww0seqVinioOoQWUIJnuvboKqxTjFMT
DoU4Ozo/2nFycvUS9AwLlUVA2s5knQZiFClGoaC0GEMwI0juQDSM1XQr03F0
dLWL7R1Fp/gu30aldbPz0Gcs2z96d3l+EH47O2n3bLqtZZQ9l4L4fOv35vXP
e1AKuQaWLgFBgAg9dTbOa/daImv6m+UE2lmB3w8/v3yB/7yh/3zzNNvnkQ+c
u44No3gwgYyC1der530X1lHmEjU6OAWC7x0yGnHnUFGcA2S//fo5d5HyBXOk
8r06ZL7y9YXGHqFDy6tmU/m0vSco3PtVFpdgn2TOedm36xt402oQJ5z5d1Kf
HKh35dvDVy/Eqh8Hu42iBq+RCiSasjCNqt5JbetlKYS9cgCrGWV3I9Cy/SKQ
RWdGwG2RN8q61zn7i0LDqXSHcG/5YDRfXiR9RoKptZSQzwcP5xALYMmhQS1i
Fz4Tk0/Sni97ypNGFqA4ZW5Wj2XH0lyDeeo6Ki/tvCiCWeIe1nw8o16G/tNv
eqVVY8VXYt1isKsVD3tKjz2p/yxxzemeDjRVyfm1iT0m2tq8MJb32ct+UYyY
dH1n619cnS6bllwnkrPQGLr5FtkvCJZFakK0eqBAF1QmXg0NFGSqnT6JTai8
11ryPeH22fhkUhbdgiMEx7SA8S2Hr6FmkIlmDBGAxrf9wUJ8VjAL6x6OVZYc
Gyg7aC+rHUbyYaTh6C5+NuR3Smc5tYXsabiFRKNhDT4d2pMxpifZuVQ5UVq+
3bMRNILtinWTTEQieURpdI6oBPrRqqq32dnpzRsa6FNJRB3q5On19yhzQXyN
rpqQgpfPn3NQjovXBzIoFbLHxFiiVeEHuh902Xzyiy1+vz3Ar3TQyAvnK8Lj
YFKHqBliX518QYs6vsvLxrkTduSsjfQOEMRdeniisecc1+GurDgf3o8JZELp
ejT9KKIFo+y3TjRapHbOUJ7Y634O8u8pCJSaUL+ZLtMQtY8354zYf2U9CUjb
g3Mr2YgPDWFe4+cgNcIDQptbL6SprhSI0yoAM1IIpMKQ2/9weXJ0c5pdnMv+
r05/+HB6fePzas5vTs+PT78gsUbRS4V43j8zFUlcffqciGGcdvIUdRM4g7SI
utIqoZ7Hyej43idB8LgRTO85VZwEuHXnmzMZ2VohDE0rh8RCjpQnJORX/svc
I66o2OPzDzXS8R10HiAGxGkGKYHWoH5g2DZc57hnDkk5Z+dvLsZoy8PSyXcn
dCM3DcDFn8NikquwK8WkXCCe+MpP/IedxrK6x//9n9dvj969w96ecJw8Cqf+
F+eLRTRo78E59ozL7A0E5e5zv5ZLnz22x/oG1AmTAh8Z1y/gFg/AupW9fAbS
T7JAPjN7Mf8tVcuWzJYYwdA6Fe97xzTUHhlH9J7Qin2tVUc5P/+yQPRAwZmw
QVRuNRSDk+PMAH/4+fBQSj59fr7I9mnnd6TWwxC9ypf/Ki29YGE+sIAszstu
VcQQhfNaS6222ZHWmu7T8rwdLhH+YvJKi4f5xlNWSu/bp89e/vrrF+6GEzq1
kyY2MrRYFxK5E5naSo36SrH7it+8gANegbVm4MiI37kG0za5nGvnhB491nvr
6wQCE1Yjouk9DUABOYvtZcaK9x5YjLhxuRzqehicioilhtMCZiPJm7XCNCrd
QFBZPwgQxtwHpvCWPgEJW/rUJUogsNK0Wcu3jha0r7XgsRaJyhSs8y7pdYNu
1iT30b3hlpURHJ/1xNMDEKB0pWaf1QvKRSZCNkRMIJll4W5xWrXQr+gagBSx
GRJyCudr4pE9j7h7rPxHx7g3SUQO/VNL9rRepzXoVWoYNB1h9CCE4z3QcpkS
YYYjqe6XraoC1q+Zn8LnxE4GVM2jzNcWFqudsCSEz3hHwq5eh2GFo+xLk/Z8
aU3Zh5EG2lFP0jrKpk1ZLDSSZm0sj3luaKTWFivUiZr5mnxaCQIRgitU2WD3
M+p/JIsMm4rCmnbuWQxWLumnZ2x9VZRLcp1xGIhli5xnJv4NRK0E9VXEAmBu
pBkgrjhmHZMseIMfvmPeC9QUJDGVK63wCk1CEVJqzKqSJ8x4EiOQyS9RRrR2
GueApdEjF7yHYSe0XbsPc42L4s7LJqDWCSarMHPky36koqyMIAU/oyW4xOKj
vgMRozxFYSnPi59CNNgIItLevo8GiFLWO9HuFj1CwKn0d5xs3Wtmz8KcBnHT
qTt6ny2ZgRAP0IxAETxBSG6/7wI1cAP//vd5/XMi8BBLdP/ImA5l/1BRY+if
fyR6wcDv7h+vx/yP/X/on8d+499pLSRCyHxRl2T6eF7rVZVnntojZyS6X50f
vfMP9lLq45ee2Utpu0T68nsE/RId8yrKp7JeygDy6nN7VTWHn46PSGF4947U
hH8wyy+4m00FR4QIU2oul9df2Ounfzk+vb6mA/rp3cUR3rUO8mlHZNb4LQqd
i2jIOF/rMB/Ory9Pj8/enJ2e7EJIoylCctQ/sozfnh+++rbIvy5sLXiRNnR9
evVn3sdR5MWL6CK7LZgUs7H8H+7vr7M/9NE468puWfzPPatq8bD8fSpYvvcr
bLtHvc4WfVPtspzCUoZY0xrBwq3kTvmbiUzt8fOUIrsd0wjSLOmeFfNSLfzv
y49F9l1J13Itpj4/IJJQdkaLupCxZU8G+Y8ye7sZZe8IFLfZf9zRn/+rvquy
twUxALqYxFePlkQH6Sje59XHshq5kw3d1+xHuE+s29ZlvlkSlV4s6I1egJFE
Ht6n0f4aELjjWhQVEU6YX7RzY14RyXB/ymlJ35OuuKID2D/50/cHUvnC0iiV
orKZYk9oxx5nxgMpb5t6syaqQYd5SAtQOzVthnnNTU109Q0R7zurQq68iEOO
xAyzSIL9zAynNNLNQ10IGu+qprPustNPeRWElrRDsEaXJ52jJ441Qp2SBc4Y
qNIOGD7QithKvWo1GomTXjjPx8K7gd1wHM43M0WT665Y3+HIviNp55dVseXU
oyVne6xYt1b20O8JanQkwIsD+WiTAyvRr042H31PmVIivhq/qUXNUEDFPy3b
TDKClG7mC2ayngguukY2gCy2PuY0B2J3lnfJiSC0NNRRPKrmTbFFy1iUCCCc
rm8Jl+ak0f25gE9r3kBMfLeZkZ5Bmut8Q0z9fd51hPFNTpj8vmz+lmd/2hTL
AtH8I/ddQ7cCRr/Vip1wwPQ7wsJynb2l65yvxt/lHzWzW/ZrO9U6OkQjphsN
QCLOwM0EQTBwQbRHtKV0aTKrFbS15IuW+0lz9e64x3VkRum0FbeM5/bFJv1v
UhQQ2lqvsTXKD/5GFHmLKJy9m4EUpVA+131xK/DswVbge9p2KRVFfQ6jlWfL
fT/teCMW4ONQnp/9tP65jtZbacCTaVMSZh5FqfcTs9gl4yTmIITK43cZVYKA
quKWNK6S66+t1lBQom7ABFtdga/MTncIoXi5Wty5LoovI8twIwy7vjgKjlL6
/Jc3Vy4SBlWtY+FdL460TNTuhVVxj2pEMVkqJJQO/WJMK+EIEWyBHeXc9hr+
+duq/MXMerZRlSYJrW9FjobrA4Yw7jplpy7hVb2d8ZZCVLcvyRVVO9LK0boj
qaymwiZY/khikvs+K/YvsbLOHfp4l0SfumUoBOUIjk9Qa9B3o5CssBCvwGe+
7sw5jZpecCfovie9ypyWstDaCUQFvvuh9OxMtH70sN7okVo/EB/iZMq0RiCI
+aW2UGRLK2JsnRFhj5JdLUDS+QDJtC1uvEit3o23Q9IzyJTvTC/xVpzIPXYI
yTFepZH/chR2BW1ncbKB3Ic6AYzoSi7EgcnrZafL4AlZ+CFywfm/57WQsWO9
p28gw1xq6CARbvEe/dPFpNicei3F7d5riMJZxan6Xam8kwPFuMrT+PCZs6ml
PC+wlr71ilEqXXlbeO67O1kcRDu7K6Sw1HBPKxqXeN/MlygU3ldrHAcORJqT
p33AkRuhdLLQ5CzfYsa7KqKSgTK6ptIB5aXj/WdbptRllqfG+h2zBI71o7tw
zwbk2upg++0ziWUmD/zB5dNlcU3GwioVTWngj5BLYniL5k9iTxnIF13C/wsO
5sZ8OdwAAA==

-->

</rfc>