rfc9250xml2.original.xml   rfc9250.xml 
<?xml version="1.0" encoding="us-ascii"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc [
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.11 --> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc sortrefs="yes"?> -ietf-dprive-dnsoquic-11" category="std" obsoletes="" number="9250" updates="" s
<?rfc symrefs="yes"?> ubmissionType="IETF" xml:lang="en" consensus="true" tocInclude="true" sortRefs="
<?rfc comments="yes"?> true" symRefs="true" version="3">
<rfc ipr="trust200902" docName="draft-ietf-dprive-dnsoquic-12" category="std">
<front> <front>
<title abbrev="DNS over Dedicated QUIC">DNS over Dedicated QUIC Connections< /title> <title abbrev="DNS over Dedicated QUIC">DNS over Dedicated QUIC Connections< /title>
<seriesInfo name="RFC" value="9250"/>
<author initials="C." surname="Huitema" fullname="Christian Huitema"> <author initials="C" surname="Huitema" fullname="Christian Huitema">
<organization>Private Octopus Inc.</organization> <organization>Private Octopus Inc.</organization>
<address> <address>
<postal> <postal>
<street>427 Golfcourse Rd</street> <street>427 Golfcourse Rd</street>
<city>Friday Harbor</city> <city>Friday Harbor</city>
<code>WA 98250</code> <code>WA 98250</code>
<country>USA</country> <country>USA</country>
</postal> </postal>
<email>huitema@huitema.net</email> <email>huitema@huitema.net</email>
</address> </address>
</author> </author>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson"> <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<organization>Sinodun IT</organization> <organization>Sinodun IT</organization>
<address> <address>
<postal> <postal>
<street>Oxford Science Park</street> <street>Oxford Science Park</street>
<city>Oxford</city> <city>Oxford</city>
<code>OX4 4GA</code> <code>OX4 4GA</code>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>sara@sinodun.com</email> <email>sara@sinodun.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Mankin" fullname="Allison Mankin"> <author initials="A." surname="Mankin" fullname="Allison Mankin">
<organization>Salesforce</organization> <organization>Salesforce</organization>
<address> <address>
<email>allison.mankin@gmail.com</email> <email>allison.mankin@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022" month="May"/>
<area>Internet</area>
<workgroup>DNS PRIVate Exchange</workgroup>
<date year="2022" month="April" day="20"/> <keyword>DNS</keyword>
<keyword>QUIC</keyword>
<area>Transport</area> <keyword>DNS over QUIC</keyword>
<keyword>Encrypted DNS</keyword>
<keyword>Internet-Draft</keyword> <keyword>DoQ</keyword>
<abstract> <abstract>
<t>This document describes the use of QUIC to provide transport confidenti
<t>This document describes the use of QUIC to provide transport confidentiality ality for DNS.
for DNS.
The encryption provided by QUIC has similar properties to those provided by TLS, 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 while QUIC transport eliminates the head-of-line blocking issues inherent with
TCP and provides more efficient packet loss recovery than UDP. DNS over QUIC TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC
(DoQ) has privacy properties similar to DNS over TLS (DoT) specified in (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in
RFC7858, and latency characteristics similar to classic DNS over UDP. This RFC 7858, and latency characteristics similar to classic DNS over UDP. This
specification describes the use of DNS over QUIC as a general-purpose transport specification describes the use of DoQ as a general-purpose transport
for DNS and includes the use of DNS over QUIC for stub to recursive, for DNS and includes the use of DoQ for stub to recursive,
recursive to authoritative, and zone transfer scenarios.</t> recursive to authoritative, and zone transfer scenarios.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>Domain Name System (DNS) concepts are specified in "Domain names - conc
<t>Domain Name System (DNS) concepts are specified in &quot;Domain names - conce epts and
pts and facilities" <xref target="RFC1034" format="default"/>. The transmission of DNS q
facilities&quot; <xref target="RFC1034"/>. The transmission of DNS queries and r ueries and responses over
esponses over UDP and TCP is specified in "Domain names - implementation and specification"
UDP and TCP is specified in &quot;Domain names - implementation and specificatio <xref target="RFC1035" format="default"/>.</t>
n&quot; <t>This document presents a mapping of the DNS protocol over the
<xref target="RFC1035"/>.</t> QUIC transport <xref target="RFC9000" format="default"/> <xref target="RFC9001"
format="default"/>. DNS over QUIC is referred to here as DoQ,
<t>This document presents a mapping of the DNS protocol over the in line with "DNS Terminology" <xref target="I-D.ietf-dnsop-rfc8499bis" format="
QUIC transport <xref target="RFC9000"/> <xref target="RFC9001"/>. DNS over QUIC default"/>.</t>
is referred to here as DoQ, <t>The goals of the DoQ mapping are:</t>
in line with &quot;DNS Terminology&quot; <xref target="I-D.ietf-dnsop-rfc8499bis <ol spacing="normal" type="1"><li>Provide the same DNS privacy protection
"/>.</t> as DoT
<xref target="RFC7858" format="default"/>. This includes an option for the clien
<t>The goals of the DoQ mapping are:</t> t to
<t><list style="numbers">
<t>Provide the same DNS privacy protection as DNS over TLS (DoT)
<xref target="RFC7858"/>. This includes an option for the client to
authenticate the server by means of an authentication domain authenticate the server by means of an authentication domain
name as specified in &quot;Usage Profiles for DNS over TLS and DNS name as specified in "Usage Profiles for DNS over TLS and DNS
over DTLS&quot; <xref target="RFC8310"/>.</t> over DTLS" <xref target="RFC8310" format="default"/>.</li>
<t>Provide an improved level of source address validation for DNS <li>Provide an improved level of source address validation for DNS
servers compared to classic DNS over UDP.</t> servers compared to classic DNS over UDP.</li>
<t>Provide a transport that does not impose path MTU limitations on the <li>Provide a transport that does not impose path MTU limitations on the
size of DNS responses it can send.</t> size of DNS responses it can send.</li>
</list></t> </ol>
<t>In order to achieve these goals, and to support ongoing work on encrypt
<t>In order to achieve these goals, and to support ongoing work on encryption of ion of
DNS, the scope of this document includes</t> DNS, the scope of this document includes:</t>
<t><list style="symbols">
<t>the &quot;stub to recursive resolver&quot; scenario</t>
<t>the &quot;recursive resolver to authoritative nameserver&quot; scenario and
</t>
<t>the &quot;nameserver to nameserver&quot; scenario (mainly used for zone tra
nsfers (XFR) <xref target="RFC1995"/>, <xref target="RFC5936"/>).</t>
</list></t>
<t>In other words, this document specifies QUIC as a general-purpose <ul spacing="normal">
<li>the "stub to recursive resolver" scenario (also called the "stub to
recursive" scenario in this document)</li>
<li>the "recursive resolver to authoritative nameserver" scenario (also
called the “recursive to authoritative” scenario in this document), and</li>
<li>the "nameserver to nameserver" scenario (mainly used for zone transf
ers (XFR) <xref target="RFC1995" format="default"/> <xref target="RFC5936" forma
t="default"/>).</li>
</ul>
<t>In other words, this document specifies QUIC as a general-purpose
transport for DNS.</t> transport for DNS.</t>
<t>The specific non-goals of this document are:</t>
<t>The specific non-goals of this document are:</t> <ol spacing="normal" type="1"><li>No attempt is made to evade potential bl
ocking of DoQ
<t><list style="numbers"> traffic by middleboxes.</li>
<t>No attempt is made to evade potential blocking of DNS over QUIC <li>No attempt to support server-initiated transactions, which are used
traffic by middleboxes.</t> only in
<t>No attempt to support server-initiated transactions, which are used only in DNS Stateful Operations (DSO) <xref target="RFC8490" format="default"/>.</li>
DNS Stateful Operations (DSO) <xref target="RFC8490"/>.</t> </ol>
</list></t> <t>Specifying the transmission of an application over QUIC requires specif
ying how
<t>Specifying the transmission of an application over QUIC requires specifying h the application's messages are mapped to QUIC streams, and generally how the
ow application will use QUIC. This is done for HTTP in "Hypertext Transfer
the application&#39;s messages are mapped to QUIC streams, and generally how the Protocol Version 3 (HTTP/3)" <xref target="I-D.ietf-quic-http" format="default"/
application will use QUIC. This is done for HTTP in &quot;Hypertext Transfer >. The purpose of this
Protocol Version 3 (HTTP/3)&quot;<xref target="I-D.ietf-quic-http"/>. The purpos
e of this
document is to define the way DNS messages can be transmitted over QUIC.</t> document is to define the way DNS messages can be transmitted over QUIC.</t>
<t>DNS over HTTP <xref target="RFC8484"/> can be used with HTTP/3 to get some of <t>DNS over HTTPS (DoH) <xref target="RFC8484" format="default"/> can be used wi
the th HTTP/3 to get some of the
benefits of QUIC. However, a lightweight direct mapping for DNS over QUIC can benefits of QUIC. However, a lightweight direct mapping for DoQ can
be regarded as a more natural fit for both the recursive to authoritative and be regarded as a more natural fit for both the recursive to authoritative and
zone transfer scenarios which rarely involve intermediaries. In these zone transfer scenarios, which rarely involve intermediaries. In these
scenarios, the additional overhead of HTTP is not offset by, e.g., benefits of scenarios, the additional overhead of HTTP is not offset by, for example, benefi
ts of
HTTP proxying and caching behavior.</t> HTTP proxying and caching behavior.</t>
<t>In this document, <xref target="design-considerations" format="default"
/> presents the reasoning that guided
the proposed design. <xref target="specifications" format="default"/> specifies
the actual mapping of DoQ.
<xref target="implementation-requirements" format="default"/> presents guideline
s on the implementation,
usage, and deployment of DoQ.</t>
</section>
<section anchor="key-words" numbered="true" toc="default">
<name>Key Words</name>
<t>In this document, <xref target="design-considerations"/> presents the reasoni <t>
ng that guided The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
the proposed design. <xref target="specifications"/> specifies the actual mappin "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
g of DoQ. NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref target="implementation-requirements"/> presents guidelines on the implemen "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
tation, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
usage and deployment of DoQ.</t> to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
</section> as shown here.
<section anchor="key-words"><name>Key Words</name> </t>
<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;, and &quot;OPTIONAL&quot; in this document are to be interpreted
as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
</section>
<section anchor="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>
</section> </section>
<section anchor="design-considerations"><name>Design Considerations</name>
<t>This section and its subsections present the design guidelines that were used <section anchor="design-considerations" numbered="true" toc="default">
for DoQ. Whilst all other sections in this document are normative, this section <name>Design Considerations</name>
<t>This section and its subsections present the design guidelines that wer
e used
for DoQ. While all other sections in this document are normative, this section
is informative in nature.</t> is informative in nature.</t>
<section anchor="provide-dns-privacy" numbered="true" toc="default">
<section anchor="provide-dns-privacy"><name>Provide DNS Privacy</name> <name>Provide DNS Privacy</name>
<t>DoT <xref target="RFC7858" format="default"/> defines how to mitigate
<t>DoT <xref target="RFC7858"/> defines how to mitigate some of the issues descr some of the issues described in "DNS
ibed in &quot;DNS Privacy Considerations" <xref target="RFC9076" format="default"/> by specifying
Privacy Considerations&quot; <xref target="RFC9076"/> by specifying how to trans how to transmit DNS messages
mit DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS over DTLS" <xref target="
over TLS. The &quot;Usage Profiles for DNS over TLS and DNS over DTLS&quot; <xre RFC8310" format="default"/>
f target="RFC8310"/> specify Strict and Opportunistic usage profiles for DoT including how stub
specify Strict and Opportunistic Usage Profiles for DoT including how stub
resolvers can authenticate recursive resolvers.</t> resolvers can authenticate recursive resolvers.</t>
<t>QUIC connection setup includes the negotiation of security parameters using <t>QUIC connection setup includes the negotiation of security parameters using
TLS, as specified in &quot;Using TLS to Secure QUIC&quot; <xref target="RFC9001" />, TLS, as specified in "Using TLS to Secure QUIC" <xref target="RFC9001" format="d efault"/>,
enabling encryption of the QUIC transport. Transmitting DNS messages over QUIC enabling encryption of the QUIC transport. Transmitting DNS messages over QUIC
will provide essentially the same privacy protections as DoT <xref target="RFC78 will provide essentially the same privacy protections as DoT <xref target="RFC78
58"/> 58" format="default"/>
including Strict and Opportunistic Usage Profiles <xref target="RFC8310"/>. Furt including Strict and Opportunistic usage profiles <xref target="RFC8310" format=
her "default"/>. Further
discussion on this is provided in <xref target="privacy-considerations"/>.</t> discussion on this is provided in <xref target="privacy-considerations" format="
default"/>.</t>
</section> </section>
<section anchor="design-for-minimum-latency"><name>Design for Minimum Latency</n <section anchor="design-for-minimum-latency" numbered="true" toc="default"
ame> >
<name>Design for Minimum Latency</name>
<t>QUIC is specifically designed to reduce protocol-induced delays, with feature <t>QUIC is specifically designed to reduce protocol-induced delays, with
s features
such as:</t> such as:</t>
<ol spacing="normal" type="1"><li>Support for 0-RTT data during session
<t><list style="numbers"> resumption.</li>
<t>Support for 0-RTT data during session resumption.</t> <li>Support for advanced packet-loss recovery procedures as specified
<t>Support for advanced packet loss recovery procedures as specified in in
&quot;QUIC Loss Detection and Congestion Control&quot; <xref target="RFC9002"/>. "QUIC Loss Detection and Congestion Control" <xref target="RFC9002" format="defa
</t> ult"/>.</li>
<t>Mitigation of head-of-line blocking by allowing parallel <li>Mitigation of head-of-line blocking by allowing parallel
delivery of data on multiple streams.</t> delivery of data on multiple streams.</li>
</list></t> </ol>
<t>This mapping of DNS to QUIC will take advantage of these features in
<t>This mapping of DNS to QUIC will take advantage of these features in
three ways:</t> three ways:</t>
<ol spacing="normal" type="1"><li>Optional support for sending 0-RTT dat
<t><list style="numbers"> a during session resumption
<t>Optional support for sending 0-RTT data during session resumption
(the security and privacy implications of this are discussed (the security and privacy implications of this are discussed
in later sections).</t> in later sections).</li>
<t>Long-lived QUIC connections over which multiple DNS transactions <li>Long-lived QUIC connections over which multiple DNS transactions
are performed, are performed,
generating the sustained traffic required to benefit from generating the sustained traffic required to benefit from
advanced recovery features.</t> advanced recovery features.</li>
<t>Mapping of each DNS Query/Response transaction to a separate stream, <li>Mapping of each DNS Query/Response transaction to a separate strea
m,
to mitigate head-of-line blocking. This enables servers to respond to mitigate head-of-line blocking. This enables servers to respond
to queries &quot;out of order&quot;. It also enables clients to process to queries "out of order". It also enables clients to process
responses as soon as they arrive, without having to wait for in responses as soon as they arrive, without having to wait for in-order delivery o
order delivery of responses previously posted by the server.</t> f responses previously posted by the server.</li>
</list></t> </ol>
<t>These considerations are reflected in the mapping of DNS traffic
<t>These considerations are reflected in the mapping of DNS traffic to QUIC streams in <xref target="stream-mapping-and-usage" format="default"/>.</
to QUIC streams in <xref target="stream-mapping-and-usage"/>.</t> t>
</section>
</section> <section anchor="middlebox-considerations" numbered="true" toc="default">
<section anchor="middlebox-considerations"><name>Middlebox Considerations</name> <name>Middlebox Considerations</name>
<t>Using QUIC might allow a protocol to disguise its purpose from device
<t>Using QUIC might allow a protocol to disguise its purpose from devices on the s on the
network path using encryption and traffic analysis resistance techniques like network path using encryption and traffic analysis resistance techniques like
padding, traffic pacing, and traffic shaping. This specification does not padding, traffic pacing, and traffic shaping. This specification does not
include any measures that are designed to avoid such classification -- include any measures that are designed to avoid such classification;
the padding mechanisms defined in <xref target="padding"/> are intended to obfus the padding mechanisms defined in <xref target="padding" format="default"/> are
cate the specific intended to obfuscate the specific
records contained in DNS queries and responses, but not the fact that this is DN S traffic. records contained in DNS queries and responses, but not the fact that this is DN S traffic.
Consequently, firewalls and other middleboxes might Consequently, firewalls and other middleboxes might
be able to distinguish DoQ from other protocols that use QUIC, like HTTP, and be able to distinguish DoQ from other protocols that use QUIC, like HTTP, and
apply different treatment.</t> apply different treatment.</t>
<t>The lack of measures in this specification to avoid protocol classifi
<t>The lack of measures in this specification to avoid protocol classification i cation is
s
not an endorsement of such practices.</t> not an endorsement of such practices.</t>
</section>
</section> <section anchor="no-server-initiated-transactions" numbered="true" toc="de
<section anchor="no-server-initiated-transactions"><name>No Server-Initiated Tra fault">
nsactions</name> <name>No Server-Initiated Transactions</name>
<t>As stated in <xref target="introduction" format="default"/>, this doc
<t>As stated in <xref target="introduction"/>, this document does not specify su ument does not specify support for
pport for
server-initiated transactions within established DoQ connections. That is, only server-initiated transactions within established DoQ connections. That is, only
the initiator of the DoQ connection may send queries over the connection.</t> the initiator of the DoQ connection may send queries over the connection.</t>
<t>DSO does support server-initiated transactions within existing connec
<t>DSO does support server-initiated transactions within existing connections. tions.
However, DoQ as defined here does not meet the criteria for an applicable 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, transport for DSO because it does not guarantee in-order delivery of messages;
see <xref section="4.2" sectionFormat="of" target="RFC8490"/>.</t> see <xref section="4.2" sectionFormat="of" target="RFC8490" format="default"/>.<
/t>
</section> </section>
</section> </section>
<section anchor="specifications"><name>Specifications</name> <section anchor="specifications" numbered="true" toc="default">
<name>Specifications</name>
<section anchor="connection-establishment"><name>Connection Establishment</name> <section anchor="connection-establishment" numbered="true" toc="default">
<name>Connection Establishment</name>
<t>DoQ connections are established as described in the QUIC transport <t>DoQ connections are established as described in the QUIC transport
specification <xref target="RFC9000"/>. During connection establishment, DoQ sup specification <xref target="RFC9000" format="default"/>. During connection estab
port is lishment, DoQ support is
indicated by selecting the Application-Layer Protocol Negotiation (ALPN) token & indicated by selecting the Application-Layer Protocol Negotiation (ALPN) token "
quot;doq&quot; in the crypto handshake.</t> doq" in the crypto handshake.</t>
<section anchor="draft-version-identification"><name>Draft Version Identificatio
n</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 Selection</name>
<t>By default, a DNS server that supports DoQ MUST listen for and accept QUIC <section anchor="port-selection" numbered="true" toc="default">
connections on the dedicated UDP port TBD (number to be defined in <name>Port Selection</name>
<xref target="iana-considerations"/>), unless there is a mutual agreement to <t>By default, a DNS server that supports DoQ <bcp14>MUST</bcp14> list
en for and accept QUIC
connections on the dedicated UDP port 853 (<xref target="iana-considerations" fo
rmat="default"/>), unless there is a mutual agreement to
use another port.</t> use another port.</t>
<t>By default, a DNS client desiring to use DoQ with a particular serv
<t>By default, a DNS client desiring to use DoQ with a particular server MUST er <bcp14>MUST</bcp14>
establish a QUIC connection to UDP port TBD on the server, unless there is a establish a QUIC connection to UDP port 853 on the server, unless there is a
mutual agreement to use another port.</t> mutual agreement to use another port.</t>
<t>DoQ connections <bcp14>MUST NOT</bcp14> use UDP port 53. This recom
<t>DoQ connections MUST NOT use UDP port 53. This recommendation against use of mendation against use of
port 53 for DoQ is to avoid confusion between DoQ and the use of DNS over UDP port 53 for DoQ is to avoid confusion between DoQ and the use of DNS over UDP
<xref target="RFC1035"/>. The risk of confusion exists even if two parties agree d on <xref 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 port 53, as other parties without knowledge of that agreement might still
try to use that port.</t> try to use that port.</t>
<t>In the stub to recursive scenario, the use of port 443 as a mutually agreed <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 alternative port can be operationally beneficial, since port 443 is
used by many services using QUIC and HTTP-3 and thus less likely 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 to be blocked than other ports. Several mechanisms for stubs to discover
recursives offering encrypted transports, including the use of custom ports, are recursives offering encrypted transports, including the use of custom ports, are
the subject of ongoing work.</t> the subject of ongoing work.</t>
</section>
</section>
</section> <section anchor="stream-mapping-and-usage" numbered="true" toc="default">
</section> <name>Stream Mapping and Usage</name>
<section anchor="stream-mapping-and-usage"><name>Stream Mapping and Usage</name> <t>The mapping of DNS traffic over QUIC streams takes advantage of the Q
UIC stream
<t>The mapping of DNS traffic over QUIC streams takes advantage of the QUIC stre features detailed in <xref section="2" sectionFormat="of" target="RFC9000" forma
am t="default"/>, the QUIC transport specification.</t>
features detailed in <xref section="2" sectionFormat="of" target="RFC9000"/>, th <t>DNS query/response traffic <xref target="RFC1034" format="default"/>
e QUIC transport specification.</t> <xref target="RFC1035" format="default"/>
<t>DNS query/response traffic <xref target="RFC1034"/>, <xref target="RFC1035"/>
follows a simple pattern in which the client sends a query, and the 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 server provides one or more responses (multiple responses can occur in zone
transfers).</t> transfers).</t>
<t>The mapping specified here requires that the client select a separate
<t>The mapping specified here requires that the client selects a separate QUIC QUIC
stream for each query. The server then uses the same stream to provide all the stream for each query. The server then uses the same stream to provide all the
response messages for that query. In order that multiple responses can be response messages for that query. In order for multiple responses to be
parsed, a 2-octet length field is used in exactly the same way as the 2-octet 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"/>. The practical re sult of this length field defined for DNS over TCP <xref 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 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> TCP connection that would manage exactly one query.</t>
<t>All DNS messages (queries and responses) sent over DoQ connections <b
<t>All DNS messages (queries and responses) sent over DoQ connections MUST be cp14>MUST</bcp14> be
encoded as a 2-octet length field followed by the message content as specified encoded as a 2-octet length field followed by the message content as specified
in <xref target="RFC1035"/>.</t> in <xref target="RFC1035" format="default"/>.</t>
<t>The client <bcp14>MUST</bcp14> select the next available client-initi
<t>The client MUST select the next available client-initiated bidirectional stre ated bidirectional stream
am
for each subsequent query on a QUIC connection, in conformance with the QUIC for each subsequent query on a QUIC connection, in conformance with the QUIC
transport specification <xref target="RFC9000"/>. Packet losses and other networ transport specification <xref target="RFC9000" format="default"/>. Packet losses
k events might and other network events might
cause queries to arrive in a different order. Servers SHOULD process queries cause queries to arrive in a different order. Servers <bcp14>SHOULD</bcp14> proc
ess queries
as they arrive, as not doing so would cause unnecessary delays.</t> as they arrive, as not doing so would cause unnecessary delays.</t>
<t>The client <bcp14>MUST</bcp14> send the DNS query over the selected s
<t>The client MUST send the DNS query over the selected stream, and MUST indicat tream and <bcp14>MUST</bcp14> indicate
e
through the STREAM FIN mechanism that no further data will be sent on that through the STREAM FIN mechanism that no further data will be sent on that
stream.</t> stream.</t>
<t>The server <bcp14>MUST</bcp14> send the response(s) on the same strea
<t>The server MUST send the response(s) on the same stream and MUST indicate, af m and <bcp14>MUST</bcp14> indicate, after
ter
the last response, through the STREAM FIN mechanism that no further data will be the last response, through the STREAM FIN mechanism that no further data will be
sent on that stream.</t> sent on that stream.</t>
<t>Therefore, a single DNS transaction consumes a single bidirectional c
<t>Therefore, a single DNS transaction consumes a single bidirectional client-in lient-initiated stream.
itiated stream. This means that the client's first query occurs on QUIC stream 0, the second on
This means that the client&#39;s first query occurs on QUIC stream 0, the second 4, and so on (see <xref section="2.1" sectionFormat="of" target="RFC9000" format
on ="default"/>).</t>
4, and so on (see <xref section="2.1" sectionFormat="of" target="RFC9000"/>.</t> <t>Servers <bcp14>MAY</bcp14> defer processing of a query until the STRE
AM FIN has been indicated
<t>Servers MAY defer processing of a query until the STREAM FIN has been indicat
ed
on the stream selected by the client.</t> on the stream selected by the client.</t>
<t>Servers and clients <bcp14>MAY</bcp14> monitor the number
of "dangling" streams. These are open streams where the following events have no
t
occurred after implementation-defined timeouts:</t>
<ul spacing="normal">
<li>the expected queries or responses have not been received or,</li>
<li>the expected queries or responses have been received but not the S
TREAM FIN</li>
</ul>
<t>Implementations <bcp14>MAY</bcp14> impose a limit on the number of
such dangling streams. If limits are encountered, implementations <bcp14>
MAY</bcp14> close the connection.</t>
<t>Servers and clients MAY monitor the number <section anchor="dns-message-ids" numbered="true" toc="default">
of &quot;dangling&quot; streams. These are open streams where the following even <name>DNS Message IDs</name>
ts have not <t>When sending queries over a QUIC connection, the DNS Message ID <bc
occurred after implementation defined timeouts:</t> p14>MUST</bcp14> be set to
0. The stream mapping for DoQ allows for unambiguous correlation of queries
<t><list style="symbols"> and responses, so the Message ID field is not required.</t>
<t>the expected queries or responses have not been received or,</t> <t>This has implications for proxying DoQ messages to and from other t
<t>the expected queries or responses have been received but not the STREAM FIN ransports.
</t>
</list></t>
<t>Implementations MAY impose a limit on the number of
such dangling streams. If limits are encountered, implementations MAY close the
connection.</t>
<section anchor="dns-message-ids"><name>DNS Message IDs</name>
<t>When sending queries over a QUIC connection, the DNS Message ID MUST be set t
o
zero. The stream mapping for DoQ allows for unambiguous correlation of queries
and responses and so the Message ID field is not required.</t>
<t>This has implications for proxying DoQ message to and from other transports.
For example, proxies may have to manage the fact that DoQ can support a larger 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., DNS over TCP number of outstanding queries on a single connection than, for example, DNS over TCP,
because DoQ is not limited by the Message ID space. This issue already exists fo r DoH, because DoQ is not limited by the Message ID space. This issue already exists fo r DoH,
where a Message ID of 0 is recommended.</t> where a Message ID of 0 is recommended.</t>
<t>When forwarding a DNS message from DoQ over another transport, a DN
<t>When forwarding a DNS message from DoQ over another transport, a DNS Message S Message ID
ID <bcp14>MUST</bcp14> be generated according to the rules of the protocol that is
MUST be generated according to the rules of the protocol that is in use. When in use. When
forwarding a DNS message from another transport over DoQ, the Message ID MUST forwarding a DNS message from another transport over DoQ, the Message ID <bcp14>
be set to zero.</t> MUST</bcp14>
be set to 0.</t>
</section> </section>
</section> </section>
<section anchor="doq-error-codes"><name>DoQ Error Codes</name> <section 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 strea <t>The following error codes are defined for use when abruptly terminati
ms, ng streams,
and used as application protocol error codes when for use as application protocol error codes when
aborting reading of streams, or immediately closing connections:</t> aborting reading of streams, or for immediately closing connections:</t>
<dl>
<dl> <dt>
<dt>
DOQ_NO_ERROR (0x0): </dt> DOQ_NO_ERROR (0x0): </dt>
<dd> <dd>
<t>No error. This is used when the connection or stream needs to be closed, <t>No error. This is used when the connection or stream needs to be
but closed, but
there is no error to signal.</t> there is no error to signal.</t>
</dd> </dd>
<dt> <dt>
DOQ_INTERNAL_ERROR (0x1): </dt> DOQ_INTERNAL_ERROR (0x1): </dt>
<dd> <dd>
<t>The DoQ implementation encountered an internal error and is incapable of <t>The DoQ implementation encountered an internal error and is incap
able of
pursuing the transaction or the connection.</t> pursuing the transaction or the connection.</t>
</dd> </dd>
<dt> <dt>
DOQ_PROTOCOL_ERROR (0x2): </dt> DOQ_PROTOCOL_ERROR (0x2): </dt>
<dd> <dd>
<t>The DoQ implementation encountered a protocol error and is forcibly abort <t>The DoQ implementation encountered a protocol error and is forcib
ing ly aborting
the connection.</t> the connection.</t>
</dd> </dd>
<dt> <dt>
DOQ_REQUEST_CANCELLED (0x3): </dt> DOQ_REQUEST_CANCELLED (0x3): </dt>
<dd> <dd>
<t>A DoQ client uses this to signal that it wants to cancel an <t>A DoQ client uses this to signal that it wants to cancel an
outstanding transaction.</t> outstanding transaction.</t>
</dd> </dd>
<dt> <dt>
DOQ_EXCESSIVE_LOAD (0x4): </dt> DOQ_EXCESSIVE_LOAD (0x4): </dt>
<dd> <dd>
<t>A DoQ implementation uses this to signal when closing a connection due to <t>A DoQ implementation uses this to signal when closing a connectio
excessive load.</t> n due to excessive load.</t>
</dd> </dd>
<dt> <dt>
DOQ_UNSPECIFIED_ERROR (0x5): </dt> DOQ_UNSPECIFIED_ERROR (0x5): </dt>
<dd> <dd>
<t>A DoQ implementation uses this in the absence of a more specific error co <t>A DoQ implementation uses this in the absence of a more specific
de.</t> error code.</t>
</dd> </dd>
<dt> <dt>
DOQ_ERROR_RESERVED (0xd098ea5e): </dt> DOQ_ERROR_RESERVED (0xd098ea5e): </dt>
<dd> <dd>
<t>Alternative error code used for tests.</t> <t>An alternative error code used for tests.</t>
</dd> </dd>
</dl> </dl>
<t>See <xref target="iana-error-codes" format="default"/> for details on
<t>See <xref target="iana-error-codes"/> for details on registering new error co registering new error codes.</t>
des.</t> <section anchor="transaction-cancellation" numbered="true" toc="default"
>
<section anchor="transaction-cancellation"><name>Transaction Cancellation</name> <name>Transaction Cancellation</name>
<t>In QUIC, sending STOP_SENDING requests that a peer cease transmissi
<t>In QUIC, sending STOP_SENDING requests that a peer cease transmission on a on on a
stream. If a DoQ client wishes to cancel an outstanding request, it MUST issue stream. If a DoQ client wishes to cancel an outstanding request, it <bcp14>MUST<
a QUIC STOP_SENDING, and it SHOULD use the error code DOQ_REQUEST_CANCELLED. /bcp14> issue
It MAY use a more specific error code registered according to <xref target="iana a QUIC STOP_SENDING, and it <bcp14>SHOULD</bcp14> use the error code DOQ_REQUEST
-error-codes"/>. _CANCELLED.
It <bcp14>MAY</bcp14> use a more specific error code registered according to <xr
ef target="iana-error-codes" format="default"/>.
The STOP_SENDING request may be sent at The STOP_SENDING request may be sent at
any time but will have no effect if the server response has already been 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. sent, in which case the client will simply discard the incoming response.
The corresponding DNS transaction MUST be abandoned.</t> The corresponding DNS transaction <bcp14>MUST</bcp14> be abandoned.</t>
<t>Servers that receive STOP_SENDING act in accordance with <xref sect
<t>Servers that receive STOP_SENDING act in accordance with <xref section="3.5" ion="3.5" sectionFormat="of" target="RFC9000" format="default"/>.
sectionFormat="of" target="RFC9000"/>. Servers <bcp14>SHOULD NOT</bcp14> continue processing a DNS transaction if they
Servers SHOULD NOT continue processing a DNS transaction if they receive a STOP_ receive a STOP_SENDING.</t>
SENDING.</t> <t>Servers <bcp14>MAY</bcp14> impose implementation limits on the tota
l number or rate of cancellation requests.
<t>Servers MAY impose implementation limits on the total number or rate of reque If limits are encountered, servers <bcp14>MAY</bcp14> close the connection. In t
st cancellations. his case,
If limits are encountered, servers MAY close the connection. In this case, servers wanting to help client debugging <bcp14>MAY</bcp14> use the error code D
servers wanting to help client debugging MAY use the error code DOQ_EXCESSIVE_LO OQ_EXCESSIVE_LOAD.
AD.
There is always a trade-off between helping good faith clients debug issues There is always a trade-off between helping good faith clients debug issues
and allowing denial-of-service attackers to test server defenses, so depending and allowing denial-of-service attackers to test server defenses; depending
on circumstances servers might very well choose to send different error codes.</ t> 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
<t>Note that this mechanism provides a way for secondaries to cancel a single zo single zone
ne
transfer occurring on a given stream without having to close the QUIC transfer occurring on a given stream without having to close the QUIC
connection.</t> connection.</t>
<t>Servers <bcp14>MUST NOT</bcp14> continue processing a DNS transacti
on if they receive a RESET_STREAM
request from the client before the client indicates the STREAM FIN. The server <
bcp14>MUST</bcp14>
issue a RESET_STREAM to indicate that the transaction is abandoned unless:</t>
<ul spacing="normal">
<li>it has already done so for another reason or</li>
<li>it has already both sent the response and indicated the STREAM F
IN.</li>
</ul>
</section>
<section anchor="transaction-errors" numbered="true" toc="default">
<name>Transaction Errors</name>
<t>Servers normally complete transactions by sending a DNS response (o
r responses)
on the transaction's stream, including cases where the DNS response indicates a
DNS error.
<t>Servers MUST NOT continue processing a DNS transaction if they receive a RESE For example, a client <bcp14>SHOULD</bcp14> be notified of a Server Failure
T_STREAM (SERVFAIL, <xref target="RFC1035"/>) through a response with the Response Code s
request from the client before the client indicates the STREAM FIN. The server M et to
UST SERVFAIL.
issue a RESET_STREAM to indicate that the transaction is abandoned unless</t>
<t><list style="symbols">
<t>it has already done so for another reason or</t>
<t>it has already both sent the response and indicated the STREAM FIN.</t>
</list></t>
</section>
<section anchor="transaction-errors"><name>Transaction Errors</name>
<t>Servers normally complete transactions by sending a DNS response (or response
s)
on the transaction&#39;s stream, including cases where the DNS response indicate
s a
DNS error. For example, a Server Failure (SERVFAIL, <xref target="RFC1035"/>) SH
OULD be
notified to the client by sending back a response with the Response Code set to
SERVFAIL.</t>
<t>If a server is incapable of sending a DNS response due to an internal error, </t>
it <t>If a server is incapable of sending a DNS response due to an intern
SHOULD issue a QUIC RESET_STREAM frame. The error code SHOULD be set to DOQ_INTE al error, it
RNAL_ERROR. The <bcp14>SHOULD</bcp14> issue a QUIC RESET_STREAM frame. The error code <bcp14>SHO
corresponding DNS transaction MUST be abandoned. Clients MAY limit the number of ULD</bcp14> be set to DOQ_INTERNAL_ERROR. The
unsolicited QUIC Stream Resets received on a connection before choosing to close corresponding DNS transaction <bcp14>MUST</bcp14> be abandoned. Clients <bcp14>M
the AY</bcp14> limit the number of
connection.</t> unsolicited QUIC 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 <t>Note that this mechanism provides a way for primaries to abort a si ngle zone
transfer occurring on a given stream without having to close the QUIC transfer occurring on a given stream without having to close the QUIC
connection.</t> connection.</t>
</section>
<section anchor="protocol-errors" numbered="true" toc="default">
<name>Protocol Errors</name>
<t>Other error scenarios can occur due to malformed, incomplete, or un
expected
messages during a transaction. These include (but are not limited to):</t>
<ul spacing="normal">
<li>a client or server receives a message with a non-zero Message ID
</li>
<li>a client or server receives a STREAM FIN before receiving all th
e bytes for a
message indicated in the 2-octet length field</li>
<li>a client receives a STREAM FIN before receiving all the expected
responses</li>
<li>a server receives more than one query on a stream</li>
<li>a client receives a different number of responses on a stream th
an expected
(e.g., multiple responses to a query for an A record)</li>
<li>a client receives a STOP_SENDING request</li>
<li>the client or server does not indicate the expected STREAM FIN a
fter
sending requests or responses (see <xref target="stream-mapping-and-usage" forma
t="default"/>)</li>
<li>an implementation receives a message containing the edns-tcp-kee
palive
EDNS(0) Option <xref target="RFC7828" format="default"/> (see
<xref target="resource-management" format="default"/>)</li>
<li>a client or a server attempts to open a unidirectional QUIC stre
am</li>
<li>a server attempts to open a server-initiated bidirectional QUIC
stream</li>
</section> <li>a server receives a "replayable" transaction in 0-RTT data (for servers not
<section anchor="protocol-errors"><name>Protocol Errors</name> willing to
handle this case, see <xref target="session-resumption-and-0-rtt" format="defau
<t>Other error scenarios can occur due to malformed, incomplete or unexpected lt"/>)
messages during a transaction. These include (but are not limited to)</t> </li>
<t><list style="symbols">
<t>a client or server receives a message with a non-zero Message ID</t>
<t>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 client receives a STREAM FIN before receiving all the expected responses<
/t>
<t>a server receives more than one query on a stream</t>
<t>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 client receives a STOP_SENDING request</t>
<t>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 implementation receives a message containing the edns-tcp-keepalive
EDNS(0) Option <xref target="RFC7828"/> (see
<xref target="resource-management"/>)</t>
<t>a client or a server attempts to open a unidirectional QUIC stream</t>
<t>a server attempts to open a server-initiated bidirectional QUIC stream</t>
<t>receiving a &quot;replayable&quot; transaction in O-RTT data (for servers n
ot willing to
handle this case - see section <xref target="session-resumption-and-0-rtt"/>)<
/t>
</list></t>
<t>If a peer encounters such an error condition it is considered a fatal error. </ul>
It <t>If a peer encounters such an error condition, it is considered a fa
SHOULD forcibly abort the connection using QUIC&#39;s CONNECTION_CLOSE mechanism tal error. It
, <bcp14>SHOULD</bcp14> forcibly abort the connection using QUIC's CONNECTION_CLOS
and SHOULD use the DoQ error code DOQ_PROTOCOL_ERROR. In some cases, it MAY E mechanism
and <bcp14>SHOULD</bcp14> use the DoQ error code DOQ_PROTOCOL_ERROR. In some cas
es, it <bcp14>MAY</bcp14>
instead silently abandon the connection, which uses fewer of the local resources instead silently abandon the connection, which uses fewer of the local resources
but makes debugging at the offending node more difficult.</t> but makes debugging at the offending node more difficult.</t>
<t>It is noted that the restrictions on use of the above EDNS(0) optio
<t>It is noted that the restrictions on use of the above EDNS(0) options has n has
implications for proxying message from TCP/DoT/DoH over DoQ.</t> implications for proxying messages from TCP/DoT/DoH over DoQ.</t>
</section>
</section> <section anchor="alternative-error-codes" numbered="true" toc="default">
<section anchor="alternative-error-codes"><name>Alternative error codes</name> <name>Alternative Error Codes</name>
<t>This specification describes specific error codes in Sections <xref
<t>This specification suggests specific error codes in <xref target="transaction target="transaction-cancellation" format="counter"/>,
-cancellation"/>, <xref target="transaction-errors" format="counter"/>, and <xref target="protocol
<xref target="transaction-errors"/>, and <xref target="protocol-errors"/>. These -errors" format="counter"/>. These error codes are meant
error codes are meant
to facilitate investigation of failures and other incidents. New error to facilitate investigation of failures and other incidents. New error
codes may be defined in future versions of DoQ, or registered as specified codes may be defined in future versions of DoQ or registered as specified
in <xref target="iana-error-codes"/>.</t> in <xref target="iana-error-codes" format="default"/>.</t>
<t>Because new error codes can be defined without negotiation, use of
<t>Because new error codes can be defined without negotiation, use of an error an error
code in an unexpected context or receipt of an unknown error code MUST be code in an unexpected context or receipt of an unknown error code <bcp14>MUST</b
cp14> be
treated as equivalent to DOQ_UNSPECIFIED_ERROR.</t> treated as equivalent to DOQ_UNSPECIFIED_ERROR.</t>
<t>Implementations <bcp14>MAY</bcp14> wish to test the support for the
<t>Implementations MAY wish to test the support for the error code extension error code extension
mechanism by using error codes not listed in this document, or they MAY use mechanism by using error codes not listed in this document, or they <bcp14>MAY</
bcp14> use
DOQ_ERROR_RESERVED.</t> DOQ_ERROR_RESERVED.</t>
</section>
</section>
</section> <section anchor="connection-management" numbered="true" toc="default">
</section> <name>Connection Management</name>
<section anchor="connection-management"><name>Connection Management</name> <t><xref section="10" sectionFormat="of" target="RFC9000" format="defaul
t"/>, the QUIC transport specification, specifies that
<t><xref section="10" sectionFormat="of" target="RFC9000"/>, the QUIC transport
specification, specifies that
connections can be closed in three ways:</t> connections can be closed in three ways:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>idle timeout</li>
<t>idle timeout</t> <li>immediate close</li>
<t>immediate close</t> <li>stateless reset</li>
<t>stateless reset</t> </ul>
</list></t> <t>Clients and servers implementing DoQ <bcp14>SHOULD</bcp14> negotiate
use of the idle timeout.
<t>Clients and servers implementing DoQ SHOULD negotiate use of the idle timeout
.
Closing on idle timeout is done without any packet exchange, which minimizes Closing on idle timeout is done without any packet exchange, which minimizes
protocol overhead. Per <xref section="10.1" sectionFormat="of" target="RFC9000"/ >, the QUIC transport specification, the protocol overhead. Per <xref section="10.1" sectionFormat="of" target="RFC9000" format="default"/>, the QUIC transport specification, the
effective value of the idle timeout is computed as the minimum of the values 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 advertised by the two endpoints. Practical considerations on setting the idle
timeout are discussed in <xref target="resource-management"/>.</t> timeout are discussed in <xref target="resource-management" format="default"/>.<
/t>
<t>Clients SHOULD monitor the idle time incurred on their connection to the <t>Clients <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 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 been received. When a client prepares to send a new DNS query to the server, it
SHOULD check whether the idle time is sufficiently lower than the idle timer. If <bcp14>SHOULD</bcp14> check whether the idle time is sufficiently lower than the
it idle timer. If it
is, the client SHOULD send the DNS query over the existing connection. If not, is, the client <bcp14>SHOULD</bcp14> send the DNS query over the existing connec
the client SHOULD establish a new connection and send the query over that tion. If not,
the client <bcp14>SHOULD</bcp14> establish a new connection and send the query o
ver that
connection.</t> connection.</t>
<t>Clients <bcp14>MAY</bcp14> discard their connections to the server be
<t>Clients MAY discard their connections to the server before the idle timeout fore the idle timeout
expires. A client that has outstanding queries SHOULD close the connection expires. A client that has outstanding queries <bcp14>SHOULD</bcp14> close the c
explicitly using QUIC&#39;s CONNECTION_CLOSE mechanism and the DoQ error code onnection
explicitly using QUIC's CONNECTION_CLOSE mechanism and the DoQ error code
DOQ_NO_ERROR.</t> DOQ_NO_ERROR.</t>
<t>Clients and servers <bcp14>MAY</bcp14> close the connection for a var
<t>Clients and servers MAY close the connection for a variety of other iety of other
reasons, indicated using QUIC&#39;s CONNECTION_CLOSE. Client and servers reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers
that send packets over a connection discarded by their peer might that send packets over a connection discarded by their peer might
receive a stateless reset indication. If a connection fails, all the receive a stateless reset indication. If a connection fails, all the
in progress transaction on that connection MUST be abandoned.</t> in-progress transactions on that connection <bcp14>MUST</bcp14> be abandoned.</t
>
</section> </section>
<section anchor="session-resumption-and-0-rtt"><name>Session Resumption and 0-RT <section anchor="session-resumption-and-0-rtt" numbered="true" toc="defaul
T</name> t">
<name>Session Resumption and 0-RTT</name>
<t>A client MAY take advantage of the session resumption and 0-RTT mechanisms su <t>A client <bcp14>MAY</bcp14> take advantage of the session resumption
pported by and 0-RTT mechanisms supported by
QUIC transport <xref target="RFC9000"/> and QUIC TLS <xref target="RFC9001"/>, i QUIC transport <xref target="RFC9000" format="default"/> and QUIC TLS <xref targ
f the server supports them. et="RFC9001" format="default"/> if the server supports them.
Clients SHOULD consider Clients <bcp14>SHOULD</bcp14> consider
potential privacy issues associated with session resumption before deciding to u se potential privacy issues associated with session resumption before deciding to u se
this mechanism and specifically evaluate the trade-offs presented in the various sections of this document. this mechanism and specifically evaluate the trade-offs presented in the various sections of this document.
The privacy issues are detailed in <xref target="privacy-issues-with-0-rtt-data" The privacy issues are detailed in Sections <xref target="privacy-issues-with-0-
/> rtt-data" format="counter"/>
and <xref target="privacy-issues-with-session-resumption"/>, and <xref target="privacy-issues-with-session-resumption" format="counter"/>,
and the implementation considerations are discussed in and the implementation considerations are discussed in
<xref target="using-0-rtt-and-session-resumption"/>.</t> <xref target="using-0-rtt-and-session-resumption" format="default"/>.</t>
<t>The 0-RTT mechanism <bcp14>MUST NOT</bcp14> be used to send DNS reque
<t>The 0-RTT mechanism MUST NOT be used to send DNS requests that are not sts that are not
&quot;replayable&quot; transactions. In this specification, only transactions th "replayable" transactions. In this specification, only transactions that have
at have an OPCODE of QUERY or NOTIFY are considered replayable; therefore, other OPCODES
an OPCODE of QUERY or NOTIFY are considered replayable and therefore other OPCOD <bcp14>MUST NOT</bcp14>
ES MUST NOT be sent in 0-RTT data. See <xref target="the-notify-service" format="default"/>
be sent in 0-RTT data. See <xref target="the-notify-service"/> for a detailed di for a detailed discussion of why NOTIFY is
scussion of why NOTIFY is
included here.</t> included here.</t>
<t>Servers <bcp14>MAY</bcp14> support session resumption, and <bcp14>MAY
<t>Servers MAY support session resumption, and MAY do that with or without suppo </bcp14> do that with or without supporting
rting 0-RTT, using the mechanisms described in <xref section="4.6.1" sectionFormat="of
0-RTT, using the mechanisms described in <xref section="4.6.1" sectionFormat="of " target="RFC9001" format="default"/>.
" target="RFC9001"/>. Servers supporting 0-RTT <bcp14>MUST NOT</bcp14> immediately process
Servers supporting 0-RTT MUST NOT immediately process non-replayable transactions received in 0-RTT data but instead
non-replayable transactions received in 0-RTT data, but instead <bcp14>MUST</bcp14> adopt one of the following behaviors:</t>
MUST adopt one of the following behaviours:</t> <ul spacing="normal">
<li>Queue the offending transaction and only process it after the QUIC
<t><list style="symbols"> handshake
<t>Queue the offending transaction and only process it after the QUIC handshak has been completed, as defined in <xref section="4.1.1" sectionFormat="of" targe
e t="RFC9001" format="default"/>.</li>
has been completed, as defined in <xref section="4.1.1" sectionFormat="of" targe <li>Reply to the offending transaction with a response code REFUSED an
t="RFC9001"/>.</t> d
<t>Reply to the offending transaction with a response code REFUSED and an Extended DNS Error Code (EDE) "Too Early" using the extended RCODE
an Extended DNS Error Code (EDE) &quot;Too Early&quot;, using the extended RCODE mechanisms defined in <xref target="RFC6891" format="default"/> and the extended
mechanisms defined in <xref target="RFC6891"/> and the extended DNS errros defin DNS errors defined in <xref target="RFC8914" format="default"/>; see
ed in <xref target="RFC8914"/>; see <xref target="reservation-of-extended-dns-error-code-too-early" format="default"
<xref target="reservation-of-extended-dns-error-code-too-early"/>.</t> />.</li>
<t>Close the connection with the error code DOQ_PROTOCOL_ERROR.</t> <li>Close the connection with the error code DOQ_PROTOCOL_ERROR.</li>
</list></t> </ul>
</section>
</section> <section anchor="message-sizes" numbered="true" toc="default">
<section anchor="message-sizes"><name>Message Sizes</name> <name>Message Sizes</name>
<t>DoQ queries and responses are sent on QUIC streams, which in theory c
<t>DoQ Queries and Responses are sent on QUIC streams, which in theory can carry an carry
up to 2^62 bytes. However, DNS messages are restricted in practice to a maximum up to 2<sup>62</sup> bytes. However, DNS messages are restricted in practice to
size of 65535 bytes. This maximum size is enforced by the use of a two-octet a maximum
message length field in DNS over TCP <xref target="RFC1035"/> and DNS over TLS size of 65535 bytes. This maximum size is enforced by the use of a 2-octet
<xref target="RFC7858"/>, and by the definition of the &quot;application/dns-mes message length field in DNS over TCP <xref target="RFC1035" format="default"/> a
sage&quot; for DNS nd DoT
over HTTP <xref target="RFC8484"/>. DoQ enforces the same restriction.</t> <xref target="RFC7858" format="default"/>, and by the definition of the "applica
tion/dns-message" for DoH <xref target="RFC8484" format="default"/>. DoQ enforce
<t>The Extension Mechanisms for DNS (EDNS) <xref target="RFC6891"/> allow peers s the same restriction.</t>
to specify the <t>The Extension Mechanisms for DNS (EDNS(0)) <xref target="RFC6891" for
mat="default"/> allow peers to specify the
UDP message size. This parameter is ignored by DoQ. DoQ implementations always UDP message size. This parameter is ignored by DoQ. DoQ implementations always
assume that the maximum message size is 65535 bytes.</t> assume that the maximum message size is 65535 bytes.</t>
</section>
</section>
</section> <section anchor="implementation-requirements" numbered="true" toc="default">
</section> <name>Implementation Requirements</name>
<section anchor="implementation-requirements"><name>Implementation Requirements<
/name>
<section anchor="authentication"><name>Authentication</name>
<t>For the stub to recursive resolver scenario, the authentication requirements <section anchor="authentication" numbered="true" toc="default">
are the same as described in DoT <xref target="RFC7858"/> and &quot;Usage Profil <name>Authentication</name>
es for DNS over <t>For the stub to recursive scenario, the authentication requirements
TLS and DNS over DTLS&quot; <xref target="RFC8310"/>. <xref target="RFC8932"/> s are the same as described in DoT <xref target="RFC7858" format="default"/> and "
tates that DNS privacy Usage Profiles for DNS over
services SHOULD provide credentials that clients can use to authenticate the TLS and DNS over DTLS" <xref target="RFC8310" format="default"/>. <xref target="
RFC8932" format="default"/> states that DNS privacy
services <bcp14>SHOULD</bcp14> provide credentials that clients can use to authe
nticate the
server. Given this, and to align with the authentication model for DoH, DoQ stub s server. Given this, and to align with the authentication model for DoH, DoQ stub s
SHOULD use a Strict authentication profile. Client authentication for the encryp ted <bcp14>SHOULD</bcp14> use a Strict usage profile. Client authentication for the encrypted
stub to recursive scenario is not described in any DNS RFC.</t> stub to recursive scenario is not described in any DNS RFC.</t>
<t>For zone transfer, the authentication requirements are the same as de
<t>For zone transfer, the authentication requirements are the same as described scribed in
in <xref target="RFC9103" format="default"/>.</t>
<xref target="RFC9103"/>.</t> <t>For the recursive to authoritative scenario, authentication
requirements are unspecified at the time of writing and are the subject of
<t>For the recursive resolver to authoritative nameserver scenario, authenticati
on
requirements are unspecified at the time of writing and are the subject on
ongoing work in the DPRIVE WG.</t> ongoing work in the DPRIVE WG.</t>
</section>
</section> <section anchor="fallback-to-other-protocols-on-connection-failure" number
<section anchor="fallback-to-other-protocols-on-connection-failure"><name>Fallba ed="true" toc="default">
ck to Other Protocols on Connection Failure</name> <name>Fallback to Other Protocols on Connection Failure</name>
<t>If the establishment of the DoQ connection fails, clients <bcp14>MAY<
<t>If the establishment of the DoQ connection fails, clients MAY attempt to /bcp14> attempt to
fall back to DoT and then potentially clear text, as specified in DoT fall back to DoT and then potentially cleartext, as specified in DoT
<xref target="RFC7858"/> and &quot;Usage Profiles for DNS over TLS and DNS over <xref target="RFC7858" format="default"/> and "Usage Profiles for DNS over TLS a
DTLS&quot; nd DNS over DTLS"
<xref target="RFC8310"/>, depending on their privacy profile.</t> <xref target="RFC8310" format="default"/>, depending on their usage profile.</t>
<t>DNS clients <bcp14>SHOULD</bcp14> remember server IP addresses that d
<t>DNS clients SHOULD remember server IP addresses that don&#39;t support DoQ. on't support DoQ.
Mobile clients might also remember the lack of DoQ support by Mobile clients might also remember the lack of DoQ support by
given IP addresses on a per-context basis (e.g.per network or provisioning domai given IP addresses on a per-context basis (e.g., per network or provisioning dom
n).</t> ain).</t>
<t>Timeouts, connection refusals, and QUIC handshake failures are indica
<t>Timeouts, connection refusals, and QUIC handshake failures are indicators tors
that a server does not support DoQ. Clients SHOULD NOT attempt DoQ queries to a that a server does not support DoQ. Clients <bcp14>SHOULD NOT</bcp14> attempt D
oQ queries to a
server that does not support DoQ for a reasonable period (such as one hour per 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 profile server). DNS clients following an out-of-band key-pinned usage profile
(<xref target="RFC7858"/>) MAY be more aggressive about retrying after DoQ conne <xref target="RFC7858" format="default"/> <bcp14>MAY</bcp14> be more aggressive
ction failures.</t> about retrying after DoQ connection failures.</t>
</section>
</section> <section anchor="address-validation" numbered="true" toc="default">
<section anchor="address-validation"><name>Address Validation</name> <name>Address Validation</name>
<t><xref section="8" sectionFormat="of" target="RFC9000" format="default
<t><xref section="8" sectionFormat="of" target="RFC9000"/>, the QUIC transport s "/>, the QUIC transport specification, defines Address
pecification, defines Address
Validation procedures to avoid servers being used in address amplification Validation procedures to avoid servers being used in address amplification
attacks. DoQ implementations MUST conform to this specification, which limits attacks. DoQ implementations <bcp14>MUST</bcp14> conform to this specification,
the worst case amplification to a factor 3.</t> which limits
the worst-case amplification to a factor 3.</t>
<t>DoQ implementations SHOULD consider configuring servers to use the Address <t>DoQ implementations <bcp14>SHOULD</bcp14> consider configuring server
Validation using Retry Packets procedure defined in <xref section="8.1.2" sectio s to use the Address
nFormat="of" target="RFC9000"/>, the QUIC Validation using Retry Packets procedure defined in <xref section="8.1.2" sectio
nFormat="of" target="RFC9000" format="default"/>, the QUIC
transport specification. This procedure imposes a 1-RTT delay for transport specification. This procedure imposes a 1-RTT delay for
verifying the return routability of the source address of a client, similar to verifying the return routability of the source address of a client, similar to
the DNS Cookies mechanism <xref target="RFC7873"/>.</t> the DNS Cookies mechanism <xref target="RFC7873" format="default"/>.</t>
<t>DoQ implementations that configure Address Validation using Retry Pac
<t>DoQ implementations that configure Address Validation using Retry Packets kets
SHOULD implement the Address Validation for Future Connections procedure <bcp14>SHOULD</bcp14> implement the Address Validation for Future Connections pr
defined in <xref section="8.1.3" sectionFormat="of" target="RFC9000"/>, the QUIC ocedure
transport specification. defined in <xref section="8.1.3" sectionFormat="of" target="RFC9000" format="def
ault"/>, the QUIC transport specification.
This defines how servers can send NEW_TOKEN frames to clients after the client This defines how servers can send NEW_TOKEN frames to clients after the client
address is validated, in order to avoid the 1-RTT penalty during subsequent address is validated in order to avoid the 1-RTT penalty during subsequent
connections by the client from the same address.</t> connections by the client from the same address.</t>
</section>
</section> <section anchor="padding" numbered="true" toc="default">
<section anchor="padding"><name>Padding</name> <name>Padding</name>
<t>Implementations <bcp14>MUST</bcp14> protect against the traffic analy
<t>Implementations MUST protect against the traffic analysis attacks described i sis attacks described in
n <xref target="traffic-analysis" format="default"/> by the judicious injection of
<xref target="traffic-analysis"/> by the judicious injection of padding. This padding. This
could be done either by padding individual DNS messages using the could be done either by padding individual DNS messages using the
EDNS(0) Padding Option <xref target="RFC7830"/> or by padding QUIC packets (see EDNS(0) Padding Option <xref target="RFC7830" format="default"/> or by padding Q
<xref section="19.1" sectionFormat="of" target="RFC9000"/>.</t> UIC packets (see
<xref section="19.1" sectionFormat="of" target="RFC9000" format="default"/>).</t
<t>In theory, padding at the QUIC packet level could result in better performanc >
e for the equivalent <t>In theory, padding at the QUIC packet level could result in better pe
rformance for the equivalent
protection, because the amount of padding can take into account non-DNS frames 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 such as acknowledgements or flow control updates, and also because QUIC packets
can carry multiple DNS messages. However, applications can only control the 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 amount of padding in QUIC packets if the implementation of QUIC exposes adequate APIs. This leads
to the following recommendation:</t> to the following recommendations:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>If the implementation of QUIC exposes APIs to set a padding policy
<t>if the implementation of QUIC exposes APIs to set a padding policy, ,
DNS over QUIC SHOULD use that API to align the packet length to a small set of DoQ <bcp14>SHOULD</bcp14> use that API to align the packet length to a small set
fixed sizes.</t> of
<t>if padding at the QUIC packet level is not available or not used, fixed sizes.</li>
DNS over QUIC MUST ensure that all DNS queries and responses are padded to <li>If padding at the QUIC packet level is not available or not used,
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 a small set of fixed sizes, using the EDNS(0) padding extension as specified
in <xref target="RFC7830"/>.</t> in <xref target="RFC7830" format="default"/>.</li>
</list></t> </ul>
<t>Implementations might choose not to use a QUIC API for padding if it
<t>Implementation might choose not to use a QUIC API for padding if it is is
significantly simpler to re-use existing DNS message padding logic which is significantly simpler to reuse existing DNS message padding logic that is
applied to other encrypted transports.</t> applied to other encrypted transports.</t>
<t>In the absence of a standard policy for padding sizes, implementation
<t>In the absence of a standard policy for padding sizes, implementations SHOULD s <bcp14>SHOULD</bcp14>
follow the recommendations of the Experimental status &quot;Padding Policies for follow the recommendations of the Experimental status "Padding Policies for
Extension Mechanisms for DNS (EDNS(0))&quot; <xref target="RFC8467"/>. While Exp Extension Mechanisms for DNS (EDNS(0))" <xref target="RFC8467" format="default"/
erimental, >. While Experimental,
these recommendations are referenced because they are implemented and deployed these recommendations are referenced because they are implemented and deployed
for DoT, and provide a way for implementations to be fully compliant with this for DoT and provide a way for implementations to be fully compliant with this
specification.</t> specification.</t>
</section>
</section> <section anchor="connection-handling" numbered="true" toc="default">
<section anchor="connection-handling"><name>Connection Handling</name> <name>Connection Handling</name>
<t>"DNS Transport over TCP - Implementation Requirements" <xref target="
<t>&quot;DNS Transport over TCP - Implementation Requirements&quot; <xref target RFC7766" format="default"/> provides
="RFC7766"/> provides
updated guidance on DNS over TCP, some of which is applicable to DoQ. This 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 provides similar advice on connection handling for DoQ.</t>
<section anchor="connection-reuse" numbered="true" toc="default">
<section anchor="connection-reuse"><name>Connection Reuse</name> <name>Connection Reuse</name>
<t>Historic implementations of DNS clients are known to open and close
<t>Historic implementations of DNS clients are known to open and close TCP TCP
connections for each DNS query. To amortize connection setup costs, both connections for each DNS query. To amortize connection setup costs, both
clients and servers SHOULD support connection reuse by sending multiple queries clients and servers <bcp14>SHOULD</bcp14> support connection reuse by sending mu ltiple queries
and responses over a single persistent QUIC connection.</t> and responses over a single persistent QUIC connection.</t>
<t>In order to achieve performance on par with UDP, DNS clients <bcp14
<t>In order to achieve performance on par with UDP, DNS clients SHOULD send thei >SHOULD</bcp14> send their
r
queries concurrently over the QUIC streams on a QUIC connection. That is, when 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 a DNS client sends multiple queries to a server over a QUIC connection, it
SHOULD NOT wait for an outstanding reply before sending the next query.</t> <bcp14>SHOULD NOT</bcp14> wait for an outstanding reply before sending the next
query.</t>
</section> </section>
<section anchor="resource-management"><name>Resource Management</name> <section anchor="resource-management" numbered="true" toc="default">
<name>Resource Management</name>
<t>Proper management of established and idle connections is important to the <t>Proper management of established and idle connections is important
to the
healthy operation of a DNS server.</t> healthy operation of a DNS server.</t>
<t>An implementation of DoQ <bcp14>SHOULD</bcp14> follow best practice
<t>An implementation of DoQ SHOULD follow best practices similar to those s similar to those
specified for DNS over TCP <xref target="RFC7766"/>, in particular with regard t specified for DNS over TCP <xref target="RFC7766" format="default"/>, in particu
o:</t> lar with regard to:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Concurrent Connections (<xref section="6.2.2" sectionFormat="of"
<t>Concurrent Connections (<xref section="6.2.2" sectionFormat="of" target="RF target="RFC7766" format="default"/>, updated by <xref section="6.4" sectionForm
C7766"/>, updated by <xref section="6.4" sectionFormat="of" target="RFC9103"/>)< at="of" target="RFC9103" format="default"/>)</li>
/t> <li>Security Considerations (<xref section="10" sectionFormat="of" t
<t>Security Considerations (<xref section="10" sectionFormat="of" target="RFC7 arget="RFC7766" format="default"/>)</li>
766"/>)</t> </ul>
</list></t> <t>Failure to do so may lead to resource exhaustion and denial of serv
ice.</t>
<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 <bcp14>
SHOULD</bcp14> use the idle
<t>Clients that want to maintain long duration DoQ connections SHOULD use the id timeout mechanisms defined in <xref section="10.1" sectionFormat="of" target="RF
le C9000" format="default"/>, the QUIC transport
timeout mechanisms defined in <xref section="10.1" sectionFormat="of" target="RF specification. Clients and servers <bcp14>MUST NOT</bcp14> send the edns-tcp-kee
C9000"/>, the QUIC transport palive EDNS(0)
specification. Clients and servers MUST NOT send the edns-tcp-keepalive EDNS(0) Option <xref target="RFC7828" format="default"/> in any messages sent on a DoQ c
Option <xref target="RFC7828"/> in any messages sent on a DoQ connection (becaus onnection (because it is
e it is
specific to the use of TCP/TLS as a transport).</t> specific to the use of TCP/TLS as a transport).</t>
<t>This document does not make specific recommendations for timeout va
<t>This document does not make specific recommendations for timeout values on id lues on idle
le
connections. Clients and servers should reuse and/or close connections connections. Clients and servers should reuse and/or close connections
depending on the level of available resources. Timeouts may be longer during depending on the level of available resources. Timeouts may be longer during
periods of low activity and shorter during periods of high activity.</t> periods of low activity and shorter during periods of high activity.</t>
</section>
</section> <section anchor="using-0-rtt-and-session-resumption" numbered="true" toc
<section anchor="using-0-rtt-and-session-resumption"><name>Using 0-RTT and Sessi ="default">
on Resumption</name> <name>Using 0-RTT and Session Resumption</name>
<t>Using 0-RTT for DoQ has many compelling advantages. Clients
<t>Using 0-RTT for DNS over QUIC has many compelling advantages. Clients
can establish connections and send queries without incurring a connection can establish connections and send queries without incurring a connection
delay. Servers can thus negotiate low values of the connection delay. Servers can thus negotiate low values of the connection
timers, which reduces the total number of connections that they need to 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 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> latency penalties if new connections are required for a query.</t>
<t>Session resumption and 0-RTT data transmission create
<t>Session resumption and 0-RTT data transmission create privacy risks detailed in Sections <xref target="privacy-issues-with-0-rtt-data
privacy risks detailed in " format="counter"/> and <xref target="privacy-issues-with-session-resumption" f
<xref target="privacy-issues-with-session-resumption"/> and <xref target="privac ormat="counter" />.
y-issues-with-0-rtt-data"/>.
The following recommendations are meant to reduce the privacy The following recommendations are meant to reduce the privacy
risks while enjoying the performance benefits of 0-RTT data, subject to the risks while enjoying the performance benefits of 0-RTT data, subject to the
restrictions specified in <xref target="session-resumption-and-0-rtt"/>.</t> restrictions specified in <xref target="session-resumption-and-0-rtt" format="de
fault"/>.</t>
<t>Clients SHOULD use resumption tickets only once, as specified in Appendix C.4 <t>Clients <bcp14>SHOULD</bcp14> use resumption tickets only once, as
to <xref target="RFC8446"/>. By default, clients SHOULD NOT use session resumpti specified in <xref target="RFC8446" sectionFormat="of" section="C.4" />. By
on if the default, clients <bcp14>SHOULD NOT</bcp14> use session resumption if the
client&#39;s connectivity has changed.</t> client's connectivity has changed.</t>
<t>Clients could receive address validation tokens from the server usi
<t>Clients could receive address validation tokens from the server using the ng the
NEW_TOKEN mechanism; see <xref section="8" sectionFormat="of" target="RFC9000"/> NEW_TOKEN mechanism; see <xref section="8" sectionFormat="of" target="RFC9000" f
. The associated tracking ormat="default"/>. The associated tracking
risks are mentioned in <xref target="privacy-issues-with-address-validation-toke risks are mentioned in <xref target="privacy-issues-with-address-validation-toke
ns"/>. ns" format="default"/>.
Clients SHOULD only use the address validation tokens when they are also using s Clients <bcp14>SHOULD</bcp14> only use the address validation tokens when they a
ession re also using session
resumption, thus avoiding additional tracking risks.</t> resumption thus avoiding additional tracking risks.</t>
<t>Servers <bcp14>SHOULD</bcp14> issue session resumption tickets with
<t>Servers SHOULD issue session resumption tickets with a sufficiently long life a sufficiently long lifetime (e.g., 6 hours),
time (e.g., 6 hours), so that clients are not tempted to either keep the connection alive or frequentl
so that clients are not tempted to either keep connection alive or frequently po y poll the server
ll the server
to renew session resumption tickets. to renew session resumption tickets.
Servers SHOULD implement the anti-replay mechanisms specified in <xref section=" Servers <bcp14>SHOULD</bcp14> implement the anti-replay mechanisms specified in
8" sectionFormat="of" target="RFC8446"/>.</t> <xref section="8" sectionFormat="of" target="RFC8446" format="default"/>.</t>
</section>
</section> <section anchor="controlling-connection-migration-for-privacy" numbered=
<section anchor="controlling-connection-migration-for-privacy"><name>Controlling "true" toc="default">
Connection Migration For Privacy</name> <name>Controlling Connection Migration for Privacy</name>
<t>DoQ implementations might consider using the connection migration f
<t>DoQ implementations might consider using the connection migration features de eatures defined
fined in <xref section="9" sectionFormat="of" target="RFC9000" format="default"/>. The
in <xref section="9" sectionFormat="of" target="RFC9000"/>. These features enabl se features enable connections to continue operating
e connections to continue operating as the client's connectivity changes.
as the client&#39;s connectivity changes. As detailed in <xref target="privacy-issues-with-long-duration-sessions" format=
As detailed in <xref target="privacy-issues-with-long-duration-sessions"/>, thes "default"/>, these features
e features trade off privacy for latency. By default, clients <bcp14>SHOULD</bcp14> be conf
trade off privacy for latency. By default, clients SHOULD be configured igured
to prioritize privacy and start new sessions if their connectivity changes.</t> to prioritize privacy and start new sessions if their connectivity changes.</t>
</section>
</section> </section>
</section> <section anchor="processing-queries-in-parallel" numbered="true" toc="defa
<section anchor="processing-queries-in-parallel"><name>Processing Queries in Par ult">
allel</name> <name>Processing Queries in Parallel</name>
<t>As specified in <xref section="7" sectionFormat="of" target="RFC7766"
<t>As specified in <xref section="7" sectionFormat="of" target="RFC7766"/> &quot format="default"/> "DNS Transport over TCP - Implementation
;DNS Transport over TCP - Implementation Requirements", resolvers are <bcp14>RECOMMENDED</bcp14> to support the preparing
Requirements&quot;, resolvers are RECOMMENDED to support the preparing
of responses in parallel and sending them out of order. In DoQ, they do that by 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 sending responses on their specific stream as soon as possible, without waiting
for availability of responses for previously opened streams.</t> for availability of responses for previously opened streams.</t>
</section>
</section> <section anchor="zone-transfer" numbered="true" toc="default">
<section anchor="zone-transfer"><name>Zone transfer</name> <name>Zone Transfer</name>
<t><xref target="RFC9103" format="default"/> specifies zone transfer ove
<t><xref target="RFC9103"/> specifies zone transfer over TLS (XoT) r TLS (XoT)
and includes updates to <xref target="RFC1995"/> (IXFR), <xref target="RFC5936"/ and includes updates to <xref target="RFC1995" format="default"/> (IXFR), <xref
> (AXFR) and target="RFC5936" format="default"/> (AXFR), and
<xref target="RFC7766"/>. Considerations relating to the re-use of XoT connectio <xref target="RFC7766" format="default"/>. Considerations relating to the reuse
ns of XoT connections
described there apply analogously to zone transfers performed using DoQ described there apply analogously to zone transfers performed using DoQ
connections. One reason for re-iterating such specific guidance is the connections. One reason for reiterating such specific guidance is the
lack of effective connection re-use in existing TCP/TLS zone transfer lack of effective connection reuse in existing TCP/TLS zone transfer
implementations today. The following recommendations apply:</t> implementations today. The following recommendations apply:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>DoQ servers <bcp14>MUST</bcp14> be able to handle multiple concurr
<t>DoQ servers MUST be able to handle multiple concurrent IXFR requests on a ent IXFR requests on a
single QUIC connection</t> single QUIC connection.</li>
<t>DoQ servers MUST be able to handle multiple concurrent AXFR requests on a <li>DoQ servers <bcp14>MUST</bcp14> be able to handle multiple concurr
single QUIC connection</t> ent AXFR requests on a
<t>DoQ implementations SHOULD single QUIC connection.</li>
<list style="symbols"> <li>
<t>use the same QUIC connection for both AXFR and IXFR requests to the sam <t>DoQ implementations <bcp14>SHOULD</bcp14>
e </t>
primary</t> <ul spacing="normal">
<t>send those requests in parallel as soon as they are queued i.e. do not <li>use the same QUIC connection for both AXFR and IXFR requests t
wait o the same
primary</li>
<li>send those requests in parallel as soon as they are queued, i.
e., do not wait
for a response before sending the next query on the connection for a response before sending the next query on the connection
(this is analogous to pipelining requests on a TCP/TLS connection)</t> (this is analogous to pipelining requests on a TCP/TLS connection)</li>
<t>send the response(s) for each request as soon as they are available i.e <li>send the response(s) for each request as soon as they are avai
. lable, i.e.,
response streams MAY be sent intermingled</t> response streams <bcp14>MAY</bcp14> be sent intermingled</li>
</list></t> </ul>
</list></t> </li>
</ul>
</section> </section>
<section anchor="flow-control-mechanisms"><name>Flow Control Mechanisms</name> <section anchor="flow-control-mechanisms" numbered="true" toc="default">
<name>Flow Control Mechanisms</name>
<t>Servers and Clients manage flow control using the mechanisms defined in <t>Servers and clients manage flow control using the mechanisms defined
<xref section="4" sectionFormat="of" target="RFC9000"/>. These mechanisms allow in
clients and servers to specify <xref section="4" sectionFormat="of" 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, 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, and how much data can be sent on the union of all streams. For DoQ,
controlling how many streams are created allows servers to control how many controlling how many streams are created allows servers to control how many
new requests the client can send on a given connection.</t> new requests the client can send on a given connection.</t>
<t>Flow control exists to protect endpoint resources.
<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 For servers, global and per-stream flow control limits control how much data can be sent by
clients. The same mechanisms clients. The same mechanisms
allow clients to control how much data can be sent by servers. 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 small will unnecessarily limit performance.
Values that are too large might expose endpoints to overload or memory exhaustio n. Values that are too large might expose endpoints to overload or memory exhaustio n.
Implementations or deployments will need to adjust flow control limits to Implementations or deployments will need to adjust flow control limits to
balance these concerns. In particular, zone transfer implementations will need t o control balance these concerns. In particular, zone transfer implementations will need t o control
these limits carefully to ensure both large and concurrent zone transfers are we ll managed.</t> these limits carefully to ensure both large and concurrent zone transfers are we ll managed.</t>
<t>Initial values of parameters control how many requests and how much d
<t>Initial values of parameters control how many requests and how much data can ata can be
be
sent by clients and servers at the beginning of the connection. These values sent by clients and servers at the beginning of the connection. These values
are specified in transport parameters exchanged during the connection handshake. are specified in transport parameters exchanged during the connection handshake.
The parameter values received in the initial connection also control how many re quests and The parameter values received in the initial connection also control how many re quests and
how much data can be sent by clients using 0-RTT data in a resumed connection. 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 Using too small values of these initial parameters would restrict the
usefulness of allowing 0-RTT data.</t> usefulness of allowing 0-RTT data.</t>
</section>
</section>
</section> <section anchor="security-considerations" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<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 ha
ve
released a suite of open source tools that support DoQ:
<list style="numbers">
<t><eref target="https://github.com/AdguardTeam/DnsLibs">AdGuard C++ DNS l
ibraries</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> S
imple 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> Qu
icdoq 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 imple
mentation 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://ad
guard.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 Considerations</name>
<t>A Threat Analysis of the Domain Name System is found in <xref target="RFC3833 <t>A Threat Analysis of the Domain Name System is found in <xref target="R
"/>. FC3833" format="default"/>.
This analysis was written before the development of DoT, DoH and DoQ, and This analysis was written before the development of DoT, DoH, and DoQ, and
probably needs to be updated.</t> probably needs to be updated.</t>
<t>The security considerations of DoQ should be comparable to those of DoT
<t>The security considerations of DoQ should be comparable to those of DoT <xref target="RFC7858" format="default"/>. DoT as specified in <xref target="RFC
<xref target="RFC7858"/>. DoT as specified in <xref target="RFC7858"/> only addr 7858" format="default"/> only addresses the stub to recursive scenario, but the
esses the stub to considerations about person-in-the-middle
recursive resolver scenario, but the considerations about person-in-the-middle attacks, middleboxes, and caching of data from cleartext connections also
attacks, middleboxes and caching of data from clear text connections also
apply for DoQ to the resolver to authoritative server scenario. apply for DoQ to the resolver to authoritative server scenario.
As stated in <xref target="authentication"/> the authentication requirements for As stated in <xref target="authentication" format="default"/>, the authenticatio
securing zone transfer using DoQ are the same as those for zone transfer over D n requirements for securing zone transfer using DoQ are the same as those for zo
oT, therefore the general security considerations are entirely analogous to thos ne transfer over DoT; therefore, the general security considerations are entirel
e described in <xref target="RFC9103"/>.</t> y analogous to those described in <xref target="RFC9103" format="default"/>.</t>
<t>DoQ relies on QUIC, which itself relies on TLS 1.3 and thus supports by
<t>DoQ relies on QUIC, which itself relies on TLS 1.3 and thus supports by defau default
lt the protections against downgrade attacks described in <xref target="BCP195" for
the protections against downgrade attacks described in <xref target="BCP195"/>. mat="default"/>.
QUIC specific issues and their mitigations are described in QUIC-specific issues and their mitigations are described in
<xref section="21" sectionFormat="of" target="RFC9000"/>.</t> <xref section="21" sectionFormat="of" target="RFC9000" format="default"/>.</t>
</section>
</section> <section anchor="privacy-considerations" numbered="true" toc="default">
<section anchor="privacy-considerations"><name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>The general considerations of encrypted transports provided in "DNS Pri
<t>The general considerations of encrypted transports provided in &quot;DNS Priv vacy
acy Considerations" <xref target="RFC9076" format="default"/> apply to DoQ. The spec
Considerations&quot; <xref target="RFC9076"/> apply to DoQ. The specific ific
considerations provided there do not differ between DoT and DoQ, and are not considerations provided there do not differ between DoT and DoQ, and they are no
discussed further here. Similarly, &quot;Recommendations for DNS Privacy Service t
Operators&quot; <xref target="RFC8932"/> (which covers operational, policy, and discussed further here. Similarly, "Recommendations for DNS Privacy Service
security Operators" <xref target="RFC8932" format="default"/> (which covers operational,
policy, and security
considerations for DNS privacy services) is also applicable to DoQ services.</t> considerations for DNS privacy services) is also applicable to DoQ services.</t>
<t>QUIC incorporates the mechanisms of TLS 1.3 <xref target="RFC8446" form
<t>QUIC incorporates the mechanisms of TLS 1.3 <xref target="RFC8446"/> and this at="default"/>, and this enables QUIC
enables QUIC transmission of "0-RTT" data. This can provide interesting latency gains, but
transmission of &quot;0-RTT&quot; data. This can provide interesting latency gai
ns, but
it raises two concerns:</t> it raises two concerns:</t>
<ol spacing="normal" type="1"><li>Adversaries could replay the 0-RTT data
<t><list style="numbers"> and infer its content
<t>Adversaries could replay the 0-RTT data and infer its content from the behavior of the receiving server.</li>
from the behavior of the receiving server.</t> <li>The 0-RTT mechanism relies on TLS session resumption, which can prov
<t>The 0-RTT mechanism relies on TLS session resumption, which can provide ide
linkability between successive client sessions.</t> linkability between successive client sessions.</li>
</list></t> </ol>
<t>These issues are developed in Sections <xref
<t>These issues are developed in <xref target="privacy-issues-with-0-rtt-data"/> target="privacy-issues-with-0-rtt-data"
and format="counter"/> and <xref
<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 Issues With 0-RTT <section anchor="privacy-issues-with-0-rtt-data" numbered="true" toc="defa
data</name> ult">
<name>Privacy Issues with 0-RTT data</name>
<t>The 0-RTT data can be replayed by adversaries. That data may trigger queries <t>The 0-RTT data can be replayed by adversaries. That data may trigger
by queries by
a recursive resolver to authoritative resolvers. Adversaries may be able to a recursive resolver to authoritative resolvers. Adversaries may be able to
pick a time at which the recursive resolver outgoing traffic is observable, and pick a time at which the recursive resolver outgoing traffic is observable and
thus find out what name was queried for in the 0-RTT data.</t> 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
<t>This risk is in fact a subset of the general problem of observing the behavio behavior
r of the recursive resolver discussed in "DNS Privacy Considerations"
of the recursive resolver discussed in &quot;DNS Privacy Considerations&quot; <xref target="RFC9076" format="default"/>. The attack is partially mitigated by
<xref target="RFC9076"/>. The attack is partially mitigated by reducing the obse reducing the observability
rvability
of this traffic. The mandatory replay protection mechanisms in of this traffic. The mandatory replay protection mechanisms in
TLS 1.3 <xref target="RFC8446"/> limit but do not eliminate the risk of replay. TLS 1.3 <xref target="RFC8446" format="default"/> limit but do not eliminate the risk of replay.
0-RTT packets can only be replayed within a narrow window, 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 tr ansmission.</t> which is only wide enough to account for variations in clock skew and network tr ansmission.</t>
<t>The recommendation for TLS 1.3 <xref target="RFC8446" format="default
<t>The recommendation for TLS 1.3 <xref target="RFC8446"/> is that the capabilit "/> is that the capability to use 0-RTT
y to use 0-RTT data should be turned off by default and only enabled if the user clearly
data should be turned off by default, and only enabled if the user clearly
understands the associated risks. In the case of DoQ, allowing 0-RTT data understands the associated risks. In the case of DoQ, allowing 0-RTT data
provides significant performance gains, and there is a concern that a provides significant performance gains, and there is a concern that a
recommendation to not use it would simply be ignored. Instead, a set of recommendation to not use it would simply be ignored. Instead, a set of
practical recommendations is provided in <xref target="session-resumption-and-0- practical recommendations is provided in Sections <xref target="session-resumpti
rtt"/> and on-and-0-rtt" format="counter"/> and
<xref target="using-0-rtt-and-session-resumption"/>.</t> <xref target="using-0-rtt-and-session-resumption" format="counter"/>.</t>
<t>The specifications in <xref target="session-resumption-and-0-rtt" for
<t>The specifications in <xref target="session-resumption-and-0-rtt"/> block the mat="default"/> block the most obvious
most obvious risks of replay attacks, as they only allow for transactions that will
risks of replay attacks, as they only allows for transactions that will
not change the long-term state of the server.</t> not change the long-term state of the server.</t>
<t>The attacks described above apply to the stub resolver to recursive r
<t>The attacks described above apply to the stub resolver to recursive esolver scenario, but similar attacks might be envisaged in the
resolver scenario, but similar attacks might be envisaged in the
recursive resolver to authoritative resolver scenario, and the recursive resolver to authoritative resolver scenario, and the
same mitigations apply.</t> same mitigations apply.</t>
</section>
</section> <section anchor="privacy-issues-with-session-resumption" numbered="true" t
<section anchor="privacy-issues-with-session-resumption"><name>Privacy Issues Wi oc="default">
th Session Resumption</name> <name>Privacy Issues with Session Resumption</name>
<t>The QUIC session resumption mechanism reduces the cost of re-establis
<t>The QUIC session resumption mechanism reduces the cost of re-establishing ses hing sessions
sions
and enables 0-RTT data. There is a linkability issue associated with session 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 pat h resumption, if the same resumption token is used several times. Attackers on pat h
between client and server could observe repeated usage of the token and 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> use that to track the client over time or over multiple locations.</t>
<t>The session resumption mechanism allows servers to correlate the resu
<t>The session resumption mechanism allows servers to correlate the resumed sess med sessions
ions with the initial sessions and thus to track the client. This creates a virtual
with the initial 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 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 server to identify the client. Servers can most probably do that already if
the client address remains constant, but session resumption tickets also enable the client address remains constant, but session resumption tickets also enable
tracking after changes of the client&#39;s address.</t> tracking after changes of the client's address.</t>
<t>The recommendations in <xref target="using-0-rtt-and-session-resumpti
<t>The recommendations in <xref target="using-0-rtt-and-session-resumption"/> ar on" format="default"/> are designed to
e designed to
mitigate these risks. Using session tickets only once mitigates mitigate these risks. Using session tickets only once mitigates
the risk of tracking by third parties. Refusing to resume a session if addresses 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 change mitigates the incremental risk of tracking by the server (but the risk of
tracking by IP address remains).</t> tracking by IP address remains).</t>
<t>The privacy trade-offs here may be context specific. Stub resolvers w
<t>The privacy trade-offs here may be context specific. Stub resolvers will have ill have a strong
a strong
motivation to prefer privacy over latency since they often change location. Howe ver, motivation to prefer privacy over latency since they often change location. Howe ver,
recursive resolvers that use a small set of static IP addresses are more likely to prefer the reduced 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 u se latency provided by session resumption and may consider this a valid reason to u se
resumption tickets even if the IP address changed between sessions.</t> resumption tickets even if the IP address changed between sessions.</t>
<t>Encrypted zone transfer (<xref target="RFC9103"/>) explicitly does
<t>Encrypted zone transfer (RFC9103) explicitly does not attempt to hide the identity of the parties involved in the transfer; at the
not attempt to hide the identity of the parties involved in the transfer, but at same time, such transfers are not particularly latency sensitive. This means tha
the t
same time such transfers are not particularly latency sensitive. This means that
applications supporting zone transfers may decide to apply the same applications supporting zone transfers may decide to apply the same
protections as stub to recursive applications.</t> protections as stub to recursive applications.</t>
</section>
</section> <section anchor="privacy-issues-with-address-validation-tokens" numbered="
<section anchor="privacy-issues-with-address-validation-tokens"><name>Privacy Is true" toc="default">
sues With Address Validation Tokens</name> <name>Privacy Issues with Address Validation Tokens</name>
<t>QUIC specifies address validation mechanisms in <xref section="8" sec
<t>QUIC specifies address validation mechanisms in <xref section="8" sectionForm tionFormat="of" target="RFC9000" format="default"/>. Use
at="of" target="RFC9000"/>. Use
of an address validation token allows QUIC servers to avoid an extra RTT for 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. 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 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 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 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 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 quite often for IPv6). There is a linkability risk if clients mistakenly use
address validation tokens after unknowingly moving to a new location.</t> address validation tokens after unknowingly moving to a new location.</t>
<t>The recommendations in <xref target="using-0-rtt-and-session-resumpti
<t>The recommendations in <xref target="using-0-rtt-and-session-resumption"/> mi on" format="default"/> mitigates
tigates
this risk by tying the usage of the NEW_TOKEN to that of session resumption, 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 though this recommendation does not cover the case where the client is unaware
of the address change.</t> of the address change.</t>
</section>
</section> <section anchor="privacy-issues-with-long-duration-sessions" numbered="tru
<section anchor="privacy-issues-with-long-duration-sessions"><name>Privacy Issue e" toc="default">
s With Long Duration Sessions</name> <name>Privacy Issues with Long Duration Sessions</name>
<t>A potential alternative to session resumption is the use of long dura
<t>A potential alternative to session resumption is the use of long duration ses tion sessions:
sions:
if a session remains open for a long time, new queries can be sent without incur ring if a session remains open for a long time, new queries can be sent without incur ring
connection establishment delays. It is worth pointing out that the two solutions have connection establishment delays. It is worth pointing out that the two solutions have
similar privacy characteristics. Session resumption may allow servers to keep tr ack similar privacy characteristics. Session resumption may allow servers to keep tr ack
of the IP addresses of clients, but long duration sessions have the same effect. </t> 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 conne
<t>In particular, a DoQ implementation might take advantage of the connection mi ction migration
gration features of QUIC to maintain a session even if the client's connectivity changes
features of QUIC to maintain a session even if the client&#39;s connectivity cha ,
nges, for example, if the client migrates from a Wi-Fi connection to a cellular networ
for example if the client migrates from a Wi-Fi connection to a cellular network k
connection, and then to another Wi-Fi connection. The server would be 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 able to track the client location by monitoring the succession of IP addresses
used by the long duration connection.</t> used by the long duration connection.</t>
<t>The recommendation in <xref target="controlling-connection-migration-
<t>The recommendation in <xref target="controlling-connection-migration-for-priv for-privacy" format="default"/> mitigates
acy"/> mitigates
the privacy concerns related to long duration sessions using multiple client add resses.</t> the privacy concerns related to long duration sessions using multiple client add resses.</t>
</section>
</section> <section anchor="traffic-analysis" numbered="true" toc="default">
<section anchor="traffic-analysis"><name>Traffic Analysis</name> <name>Traffic Analysis</name>
<t>Even though QUIC packets are encrypted, adversaries can gain informat
<t>Even though QUIC packets are encrypted, adversaries can gain information from ion from
observing packet lengths, in both queries and responses, as well as packet 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 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 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 QUIC STREAM fra simple mapping of one query or response per packet, or "one QUIC STREAM frame
me per packet", then the succession of packet lengths may provide enough
per packet&quot;, then the succession of packet lengths may provide enough
information to identify the requested site.</t> information to identify the requested site.</t>
<t>Implementations <bcp14>SHOULD</bcp14> use the mechanisms defined in <
<t>Implementations SHOULD use the mechanisms defined in <xref target="padding"/> xref target="padding" format="default"/> to mitigate
to mitigate
this attack.</t> this attack.</t>
</section>
</section> </section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations"><name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="registration-of-doq-identification-string" numbered="true
<section anchor="registration-of-doq-identification-string"><name>Registration o " toc="default">
f DoQ Identification String</name> <name>Registration of a DoQ Identification String</name>
<t>This document creates a new registration for the identification of Do
<t>This document creates a new registration for the identification of DoQ in the Q in the
&quot;Application Layer Protocol Negotiation (ALPN) Protocol IDs&quot; registry "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry
<xref target="RFC7301"/>.</t> <xref target="RFC7301" format="default"/>.</t>
<t>The "doq" string identifies DoQ:</t>
<t>The &quot;doq&quot; string identifies DoQ:</t> <dl>
<dt>
<dl>
<dt>
Protocol: </dt> Protocol: </dt>
<dd> <dd>
<t>DoQ</t> <t>DoQ</t>
</dd> </dd>
<dt> <dt>
Identification Sequence: </dt> Identification Sequence: </dt>
<dd> <dd>
<t>0x64 0x6F 0x71 (&quot;doq&quot;)</t> <t>0x64 0x6F 0x71 ("doq")</t>
</dd> </dd>
<dt> <dt>
Specification: </dt> Specification: </dt>
<dd> <dd>
<t>This document</t> <t>This document</t>
</dd> </dd>
</dl> </dl>
</section>
</section> <section anchor="reservation-of-dedicated-port" numbered="true" toc="defau
<section anchor="reservation-of-dedicated-port"><name>Reservation of Dedicated P lt">
ort</name> <name>Reservation of a Dedicated Port</name>
<t>For both TCP and UDP, port 853 is currently reserved for "DNS query-r
<t>For both TCP and UDP port 853 is currently reserved for &#39;DNS query-respon esponse
se protocol run over TLS/DTLS" <xref target="RFC7858" format="default"/>.</t>
protocol run over TLS/DTLS&#39; <xref target="RFC7858"/>.</t> <t>However, the specification for DNS over DTLS (DoD)
<xref target="RFC8094" format="default"/> is experimental, limited to stub to re
<t>However, the specification for DNS over DTLS (DoD) solver, and no
<xref target="RFC8094"/> is experimental, limited to stub to resolver, and no implementations or deployments currently exist to the authors' knowledge (even t
implementations or deployments currently exist to the authors&#39; knowledge (ev hough
en though
several years have passed since the specification was published).</t> several years have passed since the specification was published).</t>
<t>This specification additionally reserves the use of UDP port 853 for
<t>This specification proposes to additionally reserve the use of UDP port 853 f DoQ. QUIC version 1 was designed to be able to coexist with other protocols on
or the same port, including DTLS; see <xref section="17.2" sectionFormat="of" targe
DoQ. QUIC version 1 was designed to be able to co-exist with other protocols on t="RFC9000" format="default"/>. This means
the same port, including DTLS , see <xref section="17.2" sectionFormat="of" targ that deployments that serve DoD and DoQ (QUIC version 1) on the
et="RFC9000"/>. This means
that deployments that serve DNS over DTLS and DNS over QUIC (QUIC version 1) on
the
same port will be able to demultiplex the two due to the second most 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 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-b it-grease"/>) signatures of future versions or extensions (e.g., <xref target="I-D.ietf-quic-b it-grease" format="default"/>)
of QUIC and DTLS before deploying them to serve DNS on the same port.</t> of QUIC and DTLS before deploying them to serve DNS on the same port.</t>
<t>IANA has updated the following value in the "Service Name and Transpo
<t>IANA is requested to update the following value in the &quot;Service Name and rt
Transport Protocol Port Number Registry" in the System range. The registry for that range
Protocol Port Number Registry&quot; in the System Range. The registry for that r requires IETF Review or IESG Approval <xref target="RFC6335" format="default"/>.
ange </t>
requires IETF Review or IESG Approval <xref target="RFC6335"/>.</t> <dl>
<dt>
<dl>
<dt>
Service Name: </dt> Service Name: </dt>
<dd> <dd>
<t>domain-s</t> <t>domain-s</t>
</dd> </dd>
<dt> <dt>
Port Number: </dt> Port Number: </dt>
<dd> <dd>
<t>853</t> <t>853</t>
</dd> </dd>
<dt> <dt>
Transport Protocol(s): </dt> Transport Protocol(s): </dt>
<dd> <dd>
<t>UDP</t> <t>UDP</t>
</dd> </dd>
<dt> <dt>
Assignee: </dt> Assignee: </dt>
<dd> <dd>
<t>IESG</t> <t>IESG</t>
</dd> </dd>
<dt> <dt>
Contact: </dt> Contact: </dt>
<dd> <dd>
<t>IETF Chair</t> <t>IETF Chair</t>
</dd> </dd>
<dt> <dt>
Description: </dt> Description: </dt>
<dd> <dd>
<t>DNS query-response protocol run over DTLS or QUIC</t> <t>DNS query-response protocol run over DTLS or QUIC</t>
</dd> </dd>
<dt> <dt>
Reference: </dt> Reference: </dt>
<dd> <dd>
<t><xref target="RFC7858"/><xref target="RFC8094"/> This document</t> <t><xref target="RFC7858" format="default"/><xref target="RFC8094" f
</dd> ormat="default"/> This document</t>
</dl> </dd>
</dl>
<t>Additionally, IANA is requested to update the Description field for the <t>Additionally, IANA has updated the Description field for the
corresponding TCP port 853 allocation to be &#39;DNS query-response protocol run corresponding TCP port 853 allocation to be "DNS query-response protocol run
over TLS&#39; and to remove <xref target="RFC8094"/> from the TCP allocation&#39 over TLS" and removed <xref target="RFC8094"/> from the TCP allocation's Referen
;s Reference field ce field for consistency and clarity.</t>
for consistency and clarity.</t>
<t>(UPDATE ON IANA REQUEST: THIS SENTENCE TO BE REMOVED BEFORE PUBLICATION) Revi
ew by the port experts on 13th December 2021 determined that the proposed update
s to the existing port allocation were acceptable and will be made when this doc
ument is approved for publication.</t>
</section>
<section anchor="reservation-of-extended-dns-error-code-too-early"><name>Reserva
tion of Extended DNS Error Code Too Early</name>
<t>IANA is requested to add the following value to
the Extended DNS Error Codes registry <xref target="RFC8914"/>:</t>
<dl> </section>
<dt> <section anchor="reservation-of-extended-dns-error-code-too-early" numbere
d="true" toc="default">
<name>Reservation of an Extended DNS Error Code: Too Early</name>
<t>IANA has registered the following value in
the "Extended DNS Error Codes" registry <xref target="RFC8914" format="default"/
>:</t>
<dl>
<dt>
INFO-CODE: </dt> INFO-CODE: </dt>
<dd> <dd>
<t>TBD</t> <t>26</t>
</dd> </dd>
<dt> <dt>
Purpose: </dt> Purpose: </dt>
<dd> <dd>
<t>Too Early</t> <t>Too Early</t>
</dd> </dd>
<dt> <dt>
Reference: </dt> Reference: </dt>
<dd> <dd>
<t>This document</t> <t>This document</t>
</dd> </dd>
</dl> </dl>
</section>
</section> <section anchor="iana-error-codes" numbered="true" toc="default">
<section anchor="iana-error-codes"><name>DNS over QUIC Error Codes Registry</nam <name>DNS-over-QUIC Error Codes Registry</name>
e>
<t>IANA [SHALL add/has added] a registry for &quot;DNS over QUIC Error Codes&quo
t; on the
&quot;Domain Name System (DNS) Parameters&quot; web page.</t>
<t>The &quot;DNS over QUIC Error Codes&quot; registry governs a 62-bit space. Th <t>IANA has added a registry for "DNS-over-QUIC Error Codes" on the
is space is "Domain Name System (DNS) Parameters" web page.</t>
<t>The "DNS-over-QUIC Error Codes" registry governs a 62-bit space. This
space is
split into three regions that are governed by different policies:</t> split into three regions that are governed by different policies:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Permanent registrations for values between 0x00 and 0x3f (in hexad
<t>Permanent registrations for values between 0x00 and 0x3f (in hexadecimal; ecimal;
inclusive), which are assigned using Standards Action or IESG Approval as inclusive), which are assigned using Standards Action or IESG Approval as
defined in Section <xref target="RFC8126" section="4.9" sectionFormat="bare"/> a defined in Sections <xref target="RFC8126" section="4.9" sectionFormat="bare"/>
nd Section <xref target="RFC8126" section="4.10" sectionFormat="bare"/> of <xref and <xref target="RFC8126" section="4.10" sectionFormat="bare"/> of <xref targe
target="RFC8126"/></t> t="RFC8126" format="default"/></li>
<t>Permanent registrations for values larger than 0x3f, which are assigned <li>Permanent registrations for values larger than 0x3f, which are ass
using the Specification Required policy (<xref target="RFC8126"/>)</t> igned
<t>Provisional registrations for values larger than 0x3f, which require Expert using the Specification Required policy (<xref target="RFC8126" format="default"
Review, as defined in <xref section="4.5" sectionFormat="of" target="RFC8126"/>. />)</li>
</t> <li>Provisional registrations for values larger than 0x3f, which requi
</list></t> re Expert
Review, as defined in <xref section="4.5" sectionFormat="of" target="RFC8126" fo
<t>Provisional reservations share the range of values larger than 0x3f rmat="default"/>.</li>
with some permanent registrations. This is by design, to enable conversion </ul>
<t>Provisional reservations share the range of values larger than 0x3f
with some permanent registrations. This is by design to enable conversion
of provisional registrations into permanent registrations without requiring of provisional registrations into permanent registrations without requiring
changes in deployed systems. (This design is aligned with the principles changes in deployed systems. (This design is aligned with the principles
set in <xref section="22" sectionFormat="of" target="RFC9000"/>.)</t> set in <xref section="22" sectionFormat="of" target="RFC9000" format="default"/>
.)</t>
<t>Registrations in this registry MUST include the following fields:</t> <t>Registrations in this registry <bcp14>MUST</bcp14> include the follow
ing fields:</t>
<dl> <dl>
<dt> <dt>
Value: </dt> Value: </dt>
<dd> <dd>
<t>The assigned codepoint.</t> <t>The assigned codepoint</t>
</dd> </dd>
<dt> <dt>
Status: </dt> Status: </dt>
<dd> <dd>
<t>&quot;Permanent&quot; or &quot;Provisional&quot;.</t> <t>"Permanent" or "Provisional"</t>
</dd> </dd>
<dt> <dt>
Contact: </dt> Contact: </dt>
<dd> <dd>
<t>Contact details for the registrant.</t> <t>Contact details for the registrant</t>
</dd> </dd>
</dl> </dl>
<t>In addition, permanent registrations <bcp14>MUST</bcp14> include:</t>
<t>In addition, permanent registrations MUST include:</t> <dl>
<dt>
<dl>
<dt>
Error: </dt> Error: </dt>
<dd> <dd>
<t>A short mnemonic for the parameter.</t> <t>A short mnemonic for the parameter</t>
</dd> </dd>
<dt> <dt>
Specification: </dt> Specification: </dt>
<dd> <dd>
<t>A reference to a publicly available specification for the value (optional <t>A reference to a publicly available specification for the value (
for provisional registrations).</t> optional for provisional registrations)</t>
</dd> </dd>
<dt> <dt>
Description: </dt> Description: </dt>
<dd> <dd>
<t>A brief description of the error code semantics, which MAY be a summary i <t>A brief description of the error code semantics, which <bcp14>MAY
f a </bcp14> be a summary if a
specification reference is provided.</t> specification reference is provided</t>
</dd> </dd>
</dl> </dl>
<t>Provisional registrations of codepoints are intended to allow for pri
<t>Provisional registrations of codepoints are intended to allow for private use vate use
and experimentation with extensions to DNS over QUIC. However, and experimentation with extensions to DoQ. However,
provisional registrations could be reclaimed and reassigned for another purpose. provisional registrations could be reclaimed and reassigned for other purposes.
In addition to the parameters listed above, provisional registrations MUST inclu In addition to the parameters listed above, provisional registrations <bcp14>MUS
de:</t> T</bcp14> include:</t>
<dl>
<dl> <dt>
<dt>
Date: </dt> Date: </dt>
<dd> <dd>
<t>The date of last update to the registration.</t> <t>The date of last update to the registration</t>
</dd> </dd>
</dl> </dl>
<t>A request to update the date on any provisional
<t>A request to update the date on any provisional
registration can be made without review from the designated expert(s).</t> registration can be made without review from the designated expert(s).</t>
<t>The initial content of this registry is shown in <xref target="iana-e
<t>The initial contents of this registry are shown in <xref target="iana-error-t rror-table" format="default"/> and all
able"/> and all
entries share the following fields:</t> entries share the following fields:</t>
<dl>
<dl> <dt>
<dt>
Status: </dt> Status: </dt>
<dd> <dd>
<t>Permanent</t> <t>Permanent</t>
</dd> </dd>
<dt> <dt>
Contact: </dt> Contact: </dt>
<dd> <dd>
<t>DPRIVE WG</t> <t>DPRIVE WG</t>
</dd> </dd>
<dt> <dt>
Specification: </dt> Specification: </dt>
<dd> <dd>
<t><xref target="doq-error-codes"/></t> <t><xref target="doq-error-codes" format="default"/></t>
</dd> </dd>
</dl> </dl>
<table anchor="iana-error-table" align="center">
<texttable title="Initial DNS over QUIC Error Codes Entries" anchor="iana-error- <name>Initial DNS-over-QUIC Error Codes Entries</name>
table"> <thead>
<ttcol align='left'>Value</ttcol> <tr>
<ttcol align='left'>Error</ttcol> <th align="left">Value</th>
<ttcol align='left'>Description</ttcol> <th align="left">Error</th>
<c>0x0</c> <th align="left">Description</th>
<c>DOQ_NO_ERROR</c> </tr>
<c>No error</c> </thead>
<c>0x1</c> <tbody>
<c>DOQ_INTERNAL_ERROR</c> <tr>
<c>Implementation error</c> <td align="left">0x0</td>
<c>0x2</c> <td align="left">DOQ_NO_ERROR</td>
<c>DOQ_PROTOCOL_ERROR</c> <td align="left">No error</td>
<c>Generic protocol violation</c> </tr>
<c>0x3</c> <tr>
<c>DOQ_REQUEST_CANCELLED</c> <td align="left">0x1</td>
<c>Request cancelled by client</c> <td align="left">DOQ_INTERNAL_ERROR</td>
<c>0x4</c> <td align="left">Implementation error</td>
<c>DOQ_EXCESSIVE_LOAD</c> </tr>
<c>Closing a connection for excessive load</c> <tr>
<c>0x5</c> <td align="left">0x2</td>
<c>DOQ_UNSPECIFIED_ERROR</c> <td align="left">DOQ_PROTOCOL_ERROR</td>
<c>No error reason specified</c> <td align="left">Generic protocol violation</td>
<c>0xd098ea5e</c> </tr>
<c>DOQ_ERROR_RESERVED</c> <tr>
<c>Alternative error code used for tests</c> <td align="left">0x3</td>
</texttable> <td align="left">DOQ_REQUEST_CANCELLED</td>
<td align="left">Request cancelled by client</td>
</section> </tr>
</section> <tr>
<section anchor="acknowledgements"><name>Acknowledgements</name> <td align="left">0x4</td>
<td align="left">DOQ_EXCESSIVE_LOAD</td>
<t>This document liberally borrows text from the HTTP-3 specification <td align="left">Closing a connection for excessive load</td>
<xref target="I-D.ietf-quic-http"/> edited by Mike Bishop, and from the DoT spec </tr>
ification <tr>
<xref target="RFC7858"/> authored by Zi Hu, Liang Zhu, John Heidemann, Allison M <td align="left">0x5</td>
ankin, <td align="left">DOQ_UNSPECIFIED_ERROR</td>
Duane Wessels, and Paul Hoffman.</t> <td align="left">No error reason specified</td>
</tr>
<t>The privacy issue with 0-RTT data and session resumption were analyzed by Dan <tr>
iel <td align="left">0xd098ea5e</td>
Kahn Gillmor (DKG) in a message to the IETF &quot;DPRIVE&quot; working group <xr <td align="left">DOQ_ERROR_RESERVED</td>
ef target="DNS0RTT"/>.</t> <td align="left">Alternative error code used for tests</td>
</tr>
<t>Thanks to Tony Finch for an extensive review of the initial version of this </tbody>
draft, and to Robert Evans for the discussion of 0-RTT privacy issues. </table>
Early reviews by Paul Hoffman and Martin Thomson and interoperability tests </section>
conducted by Stephane Bortzmeyer helped improve the definition of the protocol.< </section>
/t>
<t>Thanks also to Martin Thomson and Martin Duke for their later reviews focussi
ng
on the low level QUIC details which helped clarify several aspects of DoQ. Thank
s
to Andrey Meshkov, Loganaden Velvindron, Lucas Pardue, Matt Joras, Mirja Kuelewi
nd,
Brian Trammell and Phillip Hallam-Baker for their reviews and contributions.</t>
</section>
</middle> </middle>
<back> <back>
<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 title='Normative References'> <references>
<name>References</name>
<reference anchor='RFC1034' target='https://www.rfc-editor.org/info/rfc1034'> <references>
<front> <name>Normative References</name>
<title>Domain names - concepts and facilities</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname='P.V. Mockapetris' initials='P.V.' surname='Mockapetris'><organ FC.1034.xml"/>
ization/></author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date month='November' year='1987'/> FC.1035.xml"/>
<abstract><t>This RFC is the revised basic definition of The Domain Name System. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
It obsoletes RFC-882. This memo describes the domain style names and their us FC.9000.xml"/>
ed for host address look up and electronic mail forwarding. It discusses the cl <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ients and servers in the domain name system and the protocol used between them.< FC.9001.xml"/>
/t></abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.7858.xml"/>
<seriesInfo name='STD' value='13'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name='RFC' value='1034'/> FC.8310.xml"/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.1995.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor='RFC1035' target='https://www.rfc-editor.org/info/rfc1035'> FC.2119.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Domain names - implementation and specification</title> FC.8174.xml"/>
<author fullname='P.V. Mockapetris' initials='P.V.' surname='Mockapetris'><organ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ization/></author> FC.6891.xml"/>
<date month='November' year='1987'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<abstract><t>This RFC is the revised specification of the protocol and format us FC.8914.xml"/>
ed in the implementation of the Domain Name System. It obsoletes RFC-883. This <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
memo documents the details of the domain name client - server communication.</t> FC.9103.xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.7830.xml"/>
<seriesInfo name='STD' value='13'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name='RFC' value='1035'/> FC.8467.xml"/>
<seriesInfo name='DOI' value='10.17487/RFC1035'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.7766.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor='RFC9000' target='https://www.rfc-editor.org/info/rfc9000'> FC.8446.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> FC.5936.xml"/>
<author fullname='J. Iyengar' initials='J.' role='editor' surname='Iyengar'><org <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
anization/></author> FC.7301.xml"/>
<author fullname='M. Thomson' initials='M.' role='editor' surname='Thomson'><org <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
anization/></author> FC.8126.xml"/>
<date month='May' year='2021'/> </references>
<abstract><t>This document defines the core of the QUIC transport protocol. QUI <references>
C provides applications with flow-controlled streams for structured communicatio <name>Informative References</name>
n, low-latency connection establishment, and network path migration. QUIC includ <reference anchor="DNS0RTT" target="https://www.ietf.org/mail-archive/we
es security measures that ensure confidentiality, integrity, and availability in b/dns-privacy/current/msg01276.html">
a range of deployment circumstances. Accompanying documents describe the integ <front>
ration of TLS for key negotiation, loss detection, and an exemplary congestion c <title>DNS + 0-RTT</title>
ontrol algorithm.</t></abstract> <author initials="D." surname="Kahn Gillmor" fullname="Daniel Kahn G
</front> illmor">
<seriesInfo name='RFC' value='9000'/> <organization/>
<seriesInfo name='DOI' value='10.17487/RFC9000'/> </author>
</reference> <date year="2016" month="April" day="06"/>
</front>
<reference anchor='RFC9001' target='https://www.rfc-editor.org/info/rfc9001'> <seriesInfo name="Message" value="to DNS-Privacy WG mailing list"/>
<front> </reference>
<title>Using TLS to Secure QUIC</title>
<author fullname='M. Thomson' initials='M.' role='editor' surname='Thomson'><org
anization/></author>
<author fullname='S. Turner' initials='S.' role='editor' surname='Turner'><organ
ization/></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/></aut
hor>
<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></a
uthor>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
uthor>
<date month='May' year='2016'/>
<abstract><t>This document describes the use of Transport Layer Security (TLS) t
o 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 securin
g 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-authoritat
ive 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/></a
uthor>
<author fullname='T. Reddy' initials='T.' surname='Reddy'><organization/></autho
r>
<date month='March' year='2018'/>
<abstract><t>This document discusses usage profiles, based on one or more authen
tication mechanisms, which can be used for DNS over Transport Layer Security (TL
S) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS trans
actions 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 serv
er. Additionally, it defines (D)TLS protocol profiles for DNS clients and serve
rs 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 a
n 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/></a
uthor>
<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 Comm
unity, 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/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</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/></autho
r>
<author fullname='M. Graff' initials='M.' surname='Graff'><organization/></autho
r>
<author fullname='P. Vixie' initials='P.' surname='Vixie'><organization/></autho
r>
<date month='April' year='2013'/>
<abstract><t>The Domain Name System's wire protocol includes a number of fixed f
ields whose range has been or soon will be exhausted and does not allow requesto
rs to advertise their capabilities to responders. This document describes backw
ard-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 implementatio
ns. It also obsoletes RFC 2673 (&quot;Binary Labels in the Domain Name System&q
uot;) and adds considerations on the use of extended labels in the DNS.</t></abs
tract>
</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/></aut
hor>
<author fullname='E. Hunt' initials='E.' surname='Hunt'><organization/></author>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut
hor>
<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 inf
ormation about the cause of DNS errors. Though created primarily to extend SERVF
AIL to provide additional information about the cause of DNS and DNSSEC failures
, the Extended DNS Errors option defined in this document allows all response ty
pes to contain extended error information. Extended DNS Error information does n
ot 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/></aut
hor>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/
></author>
<author fullname='S. Sahib' initials='S.' surname='Sahib'><organization/></autho
r>
<author fullname='P. Aras' initials='P.' surname='Aras'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></aut
hor>
<date month='August' year='2021'/>
<abstract><t>DNS zone transfers are transmitted in cleartext, which gives attack
ers the opportunity to collect the content of a zone by eavesdropping on network
connections. The DNS Transaction Signature (TSIG) mechanism is specified to res
trict direct zone transfer to authorized clients only, but it does not add confi
dentiality. This document specifies the use of TLS, rather than cleartext, to pr
event 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 rec
ommended 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, whi
ch allows DNS clients and servers to pad request and response messages by a vari
able 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 Mec
hanisms for DNS (EDNS(0)) but does not specify the actual padding length for spe
cific applications. This memo lists the possible options (&quot;padding policie
s&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/></aut
hor>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></aut
hor>
<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></a
uthor>
<date month='March' year='2016'/>
<abstract><t>This document specifies the requirement for support of TCP as a tra
nsport protocol for DNS implementations and provides guidelines towards DNS-over
-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5
966 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 mess
age 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/></autho
r>
<author fullname='A. Hoenes' initials='A.' role='editor' surname='Hoenes'><organ
ization/></author>
<date month='June' year='2010'/>
<abstract><t>The standard means within the Domain Name System protocol for maint
aining coherence among a zone's authoritative name servers consists of three mec
hanisms. 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 i
n detail, thereby forcing implementations intended to be compliant to make assum
ptions, impeding interoperability. Yet today we have a satisfactory set of impl
ementations 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 Ext
ension</title>
<author fullname='S. Friedl' initials='S.' surname='Friedl'><organization/></aut
hor>
<author fullname='A. Popov' initials='A.' surname='Popov'><organization/></autho
r>
<author fullname='A. Langley' initials='A.' surname='Langley'><organization/></a
uthor>
<author fullname='E. Stephan' initials='E.' surname='Stephan'><organization/></a
uthor>
<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 instanc
es in which multiple application protocols are supported on the same TCP or UDP
port, this extension allows the application layer to negotiate which protocol wi
ll 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/></aut
hor>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></aut
hor>
<date month='June' year='2017'/>
<abstract><t>Many protocols make use of points of extensibility that use constan
ts to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their alloc
ations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma
ke assignments in a given registry prudently, guidance describing the conditions
under which new values should be assigned, as well as when and how modification
s 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 addre
sses the various issues that are likely in the operation of a registry.</t><t>Th
is 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>
</references>
<references title='Informative References'>
<reference anchor="DNS0RTT" target="https://www.ietf.org/mail-archive/web/dns-pr
ivacy/current/msg01276.html">
<front>
<title>DNS + 0-RTT</title>
<author initials="D." surname="Kahn Gillmor" fullname="Daniel Kahn Gillmor">
<organization></organization>
</author>
<date year="2016" month="April" day="06"/>
</front>
<seriesInfo name="Message" value="to DNS-Privacy WG mailing list"/>
</reference>
<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-0
3.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/></aut
hor>
<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/></autho
r>
<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 sessio
n 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, provid
ing 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'>
<front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
<author fullname='Mike Bishop'>
<organization>Akamai</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/></a
uthor>
<author fullname='P. McManus' initials='P.' surname='McManus'><organization/></a
uthor>
<date month='October' year='2018'/>
<abstract><t>This document defines a protocol for sending DNS queries and gettin
g 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'><o
rganization/></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 cur
rent privacy practices. It is intended to be an analysis of the present situatio
n and does not prescribe solutions. This document obsoletes RFC 7626.</t></abstr
act>
</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'><org
anization/></author>
<author fullname='I. Swett' initials='I.' role='editor' surname='Swett'><organiz
ation/></author>
<date month='May' year='2021'/>
<abstract><t>This document describes loss detection and congestion control mecha
nisms 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/></a
uthor>
<author fullname='J. Abley' initials='J.' surname='Abley'><organization/></autho
r>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/
></author>
<author fullname='R. Bellis' initials='R.' surname='Bellis'><organization/></aut
hor>
<date month='April' year='2016'/>
<abstract><t>DNS messages between clients and servers may be received over eithe
r UDP or TCP. UDP transport involves keeping less state on a busy server, but c
an cause truncation and retries over TCP. Additionally, UDP can be exploited fo
r reflection attacks. Using TCP would reduce retransmits and amplification. Ho
wever, 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 a
llowing the state associated with TCP transport to be managed effectively with m
inimal 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'><organizatio
n/></author>
<author fullname='R. van Rijswijk-Deij' initials='R.' surname='van Rijswijk-Deij
'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></aut
hor>
<date month='October' year='2020'/>
<abstract><t>This document presents operational, policy, and security considerat
ions for DNS recursive resolver operators who choose to offer DNS privacy servic
es. With these recommendations, the operator can make deliberate decisions rega
rding which services to provide, as well as understanding how those decisions an
d the alternatives impact the privacy of users. </t><t>This document also presen
ts a non-normative framework to assist writers of a Recursive operator Privacy S
tatement, analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Prac
tice 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'> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-dns
<front> op-rfc8499bis.xml"/>
<title>Domain Name System (DNS) Cookies</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organiz
ation/></author>
<author fullname='M. Andrews' initials='M.' surname='Andrews'><organization/></a
uthor>
<date month='May' year='2016'/>
<abstract><t>DNS Cookies are a lightweight DNS transaction security mechanism th
at provides limited protection to DNS servers and clients against a variety of i
ncreasingly common denial-of-service and amplification/ forgery or cache poisoni
ng attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Netw
ork Address Translation - Protocol Translation), and anycast and can be incremen
tally deployed. (Since DNS Cookies are only returned to the IP address from whic
h 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'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8490.xml"/>
<title>Improving Awareness of Running Code: The Implementation Status Section</t
itle>
<author fullname='Y. Sheffer' initials='Y.' surname='Sheffer'><organization/></a
uthor>
<author fullname='A. Farrel' initials='A.' surname='Farrel'><organization/></aut
hor>
<date month='July' year='2016'/>
<abstract><t>This document describes a simple process that allows authors of Int
ernet-Drafts to record the status of known implementations by including an Imple
mentation Status section. This will allow reviewers and working groups to assig
n due consideration to documents that have the benefit of running code, which ma
y 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 docum
ents, and working groups are invited to think about applying the process to all
of their protocol specifications. This document obsoletes RFC 6982, advancing i
t 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'> <reference anchor="I-D.ietf-quic-http" target="https://datatracker.ietf.org/doc/ html/draft-ietf-quic-http-34">
<front> <front>
<title>Threat Analysis of the Domain Name System (DNS)</title> <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
<author fullname='D. Atkins' initials='D.' surname='Atkins'><organization/></aut <author initials='M' surname='Bishop' fullname='Mike Bishop' role='editor'>
hor> <organization/>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></a </author>
uthor> <date day='2' month='February' year='2021'/>
<date month='August' year='2004'/>
<abstract><t>Although the DNS Security Extensions (DNSSEC) have been under devel
opment 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 drawba
cks, this cart-before-the-horse situation has made it difficult to determine whe
ther DNSSEC meets its design goals, since its design goals are not well specifie
d. 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 i
n defending against these threats. This memo provides information for the Inter
net community.</t></abstract>
</front> </front>
<seriesInfo name='RFC' value='3833'/> <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
<seriesInfo name='DOI' value='10.17487/RFC3833'/>
</reference>
<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 Data
gram Transport Layer Security (DTLS)</title>
<author fullname='Y. Sheffer' initials='Y.' surname='Sheffer'><organization/></a
uthor>
<author fullname='R. Holz' initials='R.' surname='Holz'><organization/></author>
<author fullname='P. Saint-Andre' initials='P.' surname='Saint-Andre'><organizat
ion/></author>
<date month='May' year='2015'/>
<abstract><t>Transport Layer Security (TLS) and Datagram Transport Layer Securit
y (DTLS) are widely used to protect data exchanged over application protocols su
ch as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several se
rious attacks on TLS have emerged, including attacks on its most commonly used c
ipher suites and their modes of operation. This document provides recommendatio
ns for improving the security of deployed services that use TLS and DTLS. The re
commendations 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>
<!-- 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/></a
uthor>
<date month='March' year='2021'/>
<abstract><t>This document formally deprecates Transport Layer Security (TLS) ve
rsions 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 recommend
ed 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 (subse
quently being obsoleted by TLS version 1.3 in 2018), providing sufficient time t
o transition away from older versions. Removing support for older versions from
implementations reduces the attack surface, reduces opportunity for misconfigura
tion, 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 no
rmatively 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 i
s 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>
</referencegroup>
<reference anchor='RFC8094' target='https://www.rfc-editor.org/info/rfc8094'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8484.xml"/>
<title>DNS over Datagram Transport Layer Security (DTLS)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname='T. Reddy' initials='T.' surname='Reddy'><organization/></autho FC.9076.xml"/>
r> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author fullname='D. Wing' initials='D.' surname='Wing'><organization/></author> FC.9002.xml"/>
<author fullname='P. Patil' initials='P.' surname='Patil'><organization/></autho <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
r> FC.7828.xml"/>
<date month='February' year='2017'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<abstract><t>DNS queries and responses are visible to network elements on the pa FC.8932.xml"/>
th between the DNS client and its server. These queries and responses can conta <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
in privacy-sensitive information, which is valuable to protect.</t><t>This docum FC.7873.xml"/>
ent proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to pro
tect against passive listeners and certain active attacks. As latency is critic
al for DNS, this proposal also discusses mechanisms to reduce DTLS round trips a
nd 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 se
nd
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'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.3833.xml"/>
<title>Internet Assigned Numbers Authority (IANA) Procedures for the Management <referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/
of the Service Name and Transport Protocol Port Number Registry</title> bcp195">
<author fullname='M. Cotton' initials='M.' surname='Cotton'><organization/></aut
hor>
<author fullname='L. Eggert' initials='L.' surname='Eggert'><organization/></aut
hor>
<author fullname='J. Touch' initials='J.' surname='Touch'><organization/></autho
r>
<author fullname='M. Westerlund' initials='M.' surname='Westerlund'><organizatio
n/></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 Num
bers Authority (IANA) uses when handling assignment and other requests related t
o the Service Name and Transport Protocol Port Number registry. It also discuss
es 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 de
fined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates th
e IANA service name and port assignment procedures for UDP-Lite, the Datagram Co
ngestion 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 Prac
tice.</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'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.
<front> xml"/>
<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
<author fullname='P. Vixie' initials='P.' surname='Vixie'><organization/></autho
r>
<date month='August' year='1996'/>
<abstract><t>This memo describes the NOTIFY opcode for DNS, by which a master se
rver 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.8996.
xml"/>
</referencegroup>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8094.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-qu
ic-bit-grease.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6335.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1996.xml"/>
</references>
</references> </references>
<section anchor="the-notify-service"><name>The NOTIFY Service</name> <section 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 <t>This appendix discusses why it is considered acceptable to send NOTIFY
(see <xref target="RFC1996"/>) in 0-RTT data.</t> (see <xref target="RFC1996" format="default"/>) in 0-RTT data.</t>
<t><xref target="session-resumption-and-0-rtt" format="default"/> says "Th
<t><xref target="session-resumption-and-0-rtt"/> says &quot;The 0-RTT mechanism e 0-RTT mechanism <bcp14>MUST NOT</bcp14>
SHOULD NOT be used to send DNS requests that are not "replayable" transactions". This
be used to send DNS requests that are not &quot;replayable&quot; transactions&qu
ot;. This
specification supports sending a NOTIFY in 0-RTT data because specification supports sending a NOTIFY in 0-RTT data because
although a NOTIFY technically changes the state of the receiving server, the although a NOTIFY technically changes the state of the receiving server, the
effect of replaying NOTIFYs has negligible impact in practice.</t> effect of replaying NOTIFYs has negligible impact in practice.</t>
<t>NOTIFY messages prompt a secondary to either send an SOA query or an XF
<t>NOTIFY messages prompt a secondary to either send an SOA query or an XFR R
request to the primary on the basis that a newer version of the zone is 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 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 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 t he primary. For this reason, most implementations have some form of throttling of t he
SOA/XFR queries triggered by the receipt of one or more NOTIFYs.</t> SOA/XFR queries triggered by the receipt of one or more NOTIFYs.</t>
<t><xref target="RFC9103" format="default"/> describes the privacy risks a
<t><xref target="RFC9103"/> describes the privacy risks associated with both NOT ssociated with both NOTIFY and SOA queries
IFY and SOA queries
and does not include addressing those risks within the scope of encrypting zone 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 - transfers. Given this, the privacy benefit of using DoQ for NOTIFY is not clear,
but for the same reason, sending NOTIFY as 0-RTT data has no privacy risk above but for the same reason, sending NOTIFY as 0-RTT data has no privacy risk above
that of sending it using cleartext DNS.</t> that of sending it using cleartext DNS.</t>
</section>
</section> <section anchor="acknowledgements" numbered="false" toc="default">
<section anchor="notable-changes-from-previous-versions"><name>Notable Changes F <name>Acknowledgements</name>
rom Previous Versions</name> <t>This document liberally borrows text from the HTTP/3 specification
<t>(RFC EDITOR NOTE: THIS SECTION TO BE REMOVED BEFORE PUBLICATION)</t> <xref target="I-D.ietf-quic-http" format="default"/> edited by <contact fu
llname="Mike
<section anchor="stream-mapping-incompatibility-with-draft-02"><name>Stream Mapp Bishop"/> and from the DoT specification <xref target="RFC7858"
ing Incompatibility With Draft-02</name> format="default"/> authored by <contact fullname="Zi Hu"/>, <contact fulln
<t>Versions prior to -02 of this specification ame="Liang Zhu"/>, <contact fullname="John Heidemann"/>, <contact fullname="Alli
proposed a simpler mapping scheme of queries and responses to QUIc stream, son
which omitted the 2 byte length field and Mankin"/>, <contact fullname="Duane Wessels"/>, and <contact fullname="Pau
supported only a single response on a given stream. The more complex mapping l Hoffman"/>.</t>
in <xref target="stream-mapping-and-usage"/> was adopted to specifically cater f <t>The privacy issue with 0-RTT data and session resumption was
or XFR support, however, it breaks analyzed by <contact fullname="Daniel Kahn Gillmor"/> (DKG) in a message t
compatibility with earlier versions.</t> o the IETF DPRIVE
Working Group <xref target="DNS0RTT" format="default"/>.</t>
</section> <t>Thanks to <contact fullname="Tony Finch"/> for an extensive review of t
</section> he initial draft version
of this document, and to <contact fullname="Robert Evans"/> for the discus
sion of 0-RTT privacy
issues. Early reviews by <contact fullname="Paul Hoffman"/> and <contact
fullname="Martin Thomson"/> and
interoperability tests conducted by Stephane Bortzmeyer helped improve
the definition of the protocol.</t>
<t>Thanks also to <contact fullname="Martin Thomson"/> and <contact fullna
me="Martin Duke"/> for their later reviews
focusing on the low-level QUIC details, which helped clarify several
aspects of DoQ. Thanks to <contact fullname="Andrey Meshkov"/>, <contact f
ullname="Loganaden Velvindron"/>, <contact fullname="Lucas
Pardue"/>, <contact fullname="Matt Joras"/>, <contact fullname="Mirja Kuel
ewind"/>, <contact fullname="Brian Trammell"/>, and <contact fullname="Phillip
Hallam-Baker"/> for their reviews and contributions.</t>
</section>
</back> </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> </rfc>
 End of changes. 207 change blocks. 
2515 lines changed or deleted 1261 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/