Diff: rfc9539xml2.original.xml

	rfc9539xml2.original.xml	rfc9539.xml
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 2.6
	.10) -->


	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">


	]>	]>


	<rfc ipr="trust200902" docName="draft-ietf-dprive-unilateral-probing-13" categor	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	y="exp" submissionType="IETF">	-ietf-dprive-unilateral-probing-13" number="9539" submissionType="IETF" category
		="exp" consensus="true" tocInclude="true" symRefs="true" updates="" obsoletes=""
		xml:lang="en" version="3">

		<!-- xml2rfc v2v3 conversion 3.18.2 -->
	<front>	<front>
	<title abbrev="Unilateral Encrypted Authoritative DNS">Unilateral Opportunis tic Deployment of Encrypted Recursive-to-Authoritative DNS</title>	<title abbrev="Unilateral Encrypted Authoritative DNS">Unilateral Opportunis tic Deployment of Encrypted Recursive-to-Authoritative DNS</title>

		<seriesInfo name="RFC" value="9539"/>
	<author initials="D. K." surname="Gillmor" fullname="Daniel Kahn Gillmor" ro le="editor">	<author initials="D. K." surname="Gillmor" fullname="Daniel Kahn Gillmor" ro le="editor">
	<organization abbrev="ACLU">American Civil Liberties Union</organization>	<organization abbrev="ACLU">American Civil Liberties Union</organization>
	<address>	<address>
	<postal>	<postal>
	<street>125 Broad St.</street>	<street>125 Broad St.</street>

	<city>New York, NY</city>	<city>New York</city>
	<code>10004</code>	<region>NY</region>
	<country>USA</country>	<code>10004</code>
		<country>United States of America</country>
	</postal>	</postal>
	<email>dkg@fifthhorseman.net</email>	<email>dkg@fifthhorseman.net</email>
	</address>	</address>
	</author>	</author>
	<author initials="J." surname="Salazar" fullname="Joey Salazar" role="editor ">	<author initials="J." surname="Salazar" fullname="Joey Salazar" role="editor ">

	<organization></organization>	<organization/>
	<address>	<address>
	<postal>	<postal>
	<city>Alajuela</city>	<city>Alajuela</city>
	<code>20201</code>	<code>20201</code>

	<country>CR</country>	<country>Costa Rica</country>
	</postal>	</postal>
	<email>joeygsal@gmail.com</email>	<email>joeygsal@gmail.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="P." surname="Hoffman" fullname="Paul Hoffman" role="editor ">	<author initials="P." surname="Hoffman" fullname="Paul Hoffman" role="editor ">
	<organization>ICANN</organization>	<organization>ICANN</organization>
	<address>	<address>
	<postal>	<postal>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>paul.hoffman@icann.org</email>	<email>paul.hoffman@icann.org</email>
	</address>	</address>
	</author>	</author>

		<date year="2024" month="February"/>
	<date year="2023" month="October" day="23"/>

	<area>int</area>	<area>int</area>
	<workgroup>dprive</workgroup>	<workgroup>dprive</workgroup>

	<keyword>Internet-Draft</keyword>


	<abstract>	<keyword>DNS over TLS</keyword>
		<keyword>DNS over QUIC</keyword>
		<keyword>DoT</keyword>
		<keyword>DoQ</keyword>
		<keyword>encryption</keyword>
		<keyword>unilateral</keyword>
		<keyword>recursive</keyword>
		<keyword>authoritative</keyword>
		<keyword>DNS</keyword>


	<?line 51?>	<abstract>

	<t>This document sets out steps that DNS servers (recursive resolvers and author itative servers) can take unilaterally (without any coordination with other peer s) to defend DNS query privacy against a passive network monitor.	<t>This document sets out steps that DNS servers (recursive resolvers and author itative servers) can take unilaterally (without any coordination with other peer s) to defend DNS query privacy against a passive network monitor.

	The steps in this document can be defeated by an active attacker, but should be	The protections provided by the guidance in this document can be defeated by an
	simpler and less risky to deploy than more powerful defenses.</t>	active attacker, but they should be simpler and less risky to deploy than more p
		owerful defenses.</t>
	<t>The goal of this document is to simplify and speed deployment of opportunisti	<t>The goal of this document is to simplify and speed up deployment of opp
	c encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem	ortunistic encrypted transport in the recursive-to-authoritative hop of the DNS
	.	ecosystem.
	Wider easy deployment of the underlying encrypted transport on an opportunistic	Wider easy deployment of the underlying encrypted transport on an opportunistic
	basis may facilitate the future specification of stronger cryptographic protecti	basis may facilitate the future specification of stronger cryptographic protecti
	ons against more powerful attacks.</t>	ons against more-powerful attacks.</t>

	</abstract>	</abstract>


	<note title="About This Document" removeInRFC="true">
	<t>
	The latest revision of this draft can be found at <eref target="https://
	dkg.gitlab.io/dprive-unilateral-probing/"/>.
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	DPRIVE Working Group mailing list (<eref target="mailto:dns-privacy@ietf
	.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/dns-privacy/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dns-pri
	vacy/"/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://gitlab.com/dkg/dprive-unilateral-probing"/>.</t>
	</note>

	</front>	</front>


	<middle>	<middle>


	<?line 59?>	<section anchor="introduction">
		<name>Introduction</name>
	<section anchor="introduction"><name>Introduction</name>	<t>This document aims to provide guidance to DNS implementers and operator
		s who want to simply enable protection against passive network observers.</t>
	<t>This document aims to provide guidance to DNS implementers and operators who	<t>In particular, it focuses on mechanisms that can be adopted
	want to simply enable protection against passive network observers.</t>	unilaterally by recursive resolvers and authoritative servers, without
		any explicit coordination with the other parties. This guidance
	<t>In particular, it focuses on mechanisms that can be adopted unilaterally by r	provides opportunistic security (see <xref target="RFC7435"/>), that is,
	ecursive resolvers and authoritative servers, without any explicit coordination	encrypting things that would otherwise be in the clear, without
	with the other parties.	interfering with or weakening stronger forms of security.</t>
	This guidance provides opportunistic security (see <xref target="RFC7435"/>) --	<t>This document also briefly introduces (but does not try to specify) how
	encrypting things that would otherwise be in the clear, without interfering with	a future protocol might permit defense against an active attacker in <xref targ
	or weakening stronger forms of security.</t>	et="adding-auth"/>.</t>
		<t>The protocol described here offers three concrete advantages to the DNS
	<t>The document also briefly introduces (but does not try to specify) how a futu	ecosystem:</t>
	re protocol might permit defense against an active attacker in <xref target="add	<ul spacing="normal">
	ing-auth"/>.</t>	<li>
		<t>Protection from passive attackers of DNS queries in transit between
	<t>The protocol described here offers three concrete advantages to the DNS ecosy	recursive and authoritative servers.</t>
	stem:</t>	</li>
		<li>
	<t><list style="symbols">	<t>A road map for gaining real-world experience at scale with encrypte
	<t>Protection from passive attackers of DNS queries in transit between recursi	d protections of this traffic.</t>
	ve and authoritative servers.</t>	</li>
	<t>A roadmap for gaining real-world experience at scale with encrypted protect	<li>
	ions of this traffic.</t>	<t>A bridge to some possible future protection against a more powerful
	<t>A bridge to some possible future protection against a more powerful attacke	attacker.</t>
	r.</t>	</li>
	</list></t>	</ul>
		<section anchor="requirements-language">
	<section anchor="requirements-language"><name>Requirements Language</name>	<name>Requirements Language</name>
		<t>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	nterpreted as	be interpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	only when, they	when, and only when, they appear in all capitals, as shown here.
	appear in all capitals, as shown here.</t>	</t>

	<?line -18?>

	</section>
	<section anchor="terminology"><name>Terminology</name>

	<dl>
	<dt>Unilateral:</dt>
	<dd>
	<t>capable of opportunistic probing without external coordination with any o
	f the other parties</t>
	</dd>
	<dt>Do53:</dt>
	<dd>
	<t>traditional cleartext DNS over port 53 (<xref target="RFC1035"/>)</t>
	</dd>
	<dt>DoQ:</dt>
	<dd>
	<t>DNS-over-QUIC (<xref target="RFC9250"/>)</t>
	</dd>
	<dt>DoT:</dt>
	<dd>
	<t>DNS-over-TLS (<xref target="RFC7858"/>)</t>
	</dd>
	<dt>Encrypted transports:</dt>
	<dd>
	<t>DoQ and DoT collectively</t>
	</dd>
	</dl>

	</section>
	</section>
	<section anchor="priorities"><name>Priorities</name>


	<t>This document aims to mitigate potential impacts of the described protocol an d to aid implementors in selecting between possible DNS protocol choices.</t>	</section>


	<section anchor="minimizing-negative-impacts"><name>Minimizing Negative Impacts<	<section anchor="terminology">
	/name>	<name>Terminology</name>
		<dl>
		<dt>Unilateral:</dt>
		<dd>
		<t>Capable of opportunistic probing without external coordination wi
		th any of the other parties.</t>
		</dd>
		<dt>Do53:</dt>
		<dd>
		<t>DNS over port 53 (<xref target="RFC1035"/>) for traditional clear
		text transport.</t>
		</dd>
		<dt>DoQ:</dt>
		<dd>
		<t>DNS over QUIC (<xref target="RFC9250"/>).</t>
		</dd>
		<dt>DoT:</dt>
		<dd>
		<t>DNS over TLS (<xref target="RFC7858"/>).</t>
		</dd>
		<dt>Encrypted transports:</dt>
		<dd>
		<t>DoQ and DoT, collectively.</t>
		</dd>
		</dl>
		</section>
		</section>
		<section anchor="priorities">


	<t>The protocol described in this document aims to minimize potentially negative	<name>Priorities</name>
	impacts caused by the probing of encrypted transports for the systems that adop	<t>The protocol described in this document was developed with two prioriti
	t these guidelines, for the parties that they communicate with, and for uninvolv	es: minimizing negative impacts and retaining flexibility in the underlying encr
	ed third parties.	ypted transport protocol.</t>
		<section anchor="minimizing-negative-impacts">
		<name>Minimizing Negative Impacts</name>
		<t>The protocol described in this document aims to minimize potentially
		negative impacts caused by the probing of encrypted transports for the systems t
		hat adopt the protocol, for the parties that those systems communicate with, and
		for uninvolved third parties.
	The negative impacts that this protocol specifically tries to minimize are:</t>	The negative impacts that this protocol specifically tries to minimize are:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>
	<t>excessive bandwidth use</t>	<t>excessive bandwidth use,</t>
	<t>excessive use of computational resources (CPU and memory in particular)</t>	</li>
	<t>the potential for amplification attacks (where DNS resolution infrastructur	<li>
	e is wielded as part of a DoS attack)</t>	<t>excessive use of computational resources (CPU and memory in parti
	</list></t>	cular), and</t>
		</li>
	</section>	<li>
	<section anchor="protocol-choices"><name>Protocol Choices</name>	<t>the potential for amplification attacks (where DNS resolution inf
		rastructure is wielded as part of a DoS attack).</t>
	<t>Although this document focuses specifically on strategies used by DNS servers	</li>
	, it does not go into detail on the specific protocols used because those protoc	</ul>
	ols, in particular DoT and DoQ, are described in other documents.	</section>
		<section anchor="protocol-choices">
		<name>Protocol Choices</name>
		<t>Although this document focuses specifically on strategies used by DNS
		servers, it does not go into detail on the specific protocols used because thos
		e protocols, in particular DoT and DoQ, are described in other documents.
	The DoT specification (<xref target="RFC7858"/>) says that it:</t>	The DoT specification (<xref target="RFC7858"/>) says that it:</t>


	<ul empty="true"><li>	<blockquote>...focuses on securing stub-to-recursive traffic, as per the
	<t>focuses on securing stub-to-recursive traffic, as per the charter of the DP	charter of the DPRIVE Working Group. It does not prevent future
	RIVE Working Group. It does not prevent future applications of the protocol to	applications of the protocol to recursive-to-authoritative
	recursive-to-authoritative traffic.</t>	traffic.</blockquote>
	</li></ul>

	<t>It further says:</t>


	<ul empty="true"><li>	<t>It further says:</t>
	<t>It might work equally between recursive clients and authoritative servers.<
	/t>
	</li></ul>


	<t>The DoQ specification (<xref target="RFC9250"/>) says:</t>	<blockquote>It might work equally between recursive clients and
		authoritative servers...</blockquote>


	<ul empty="true"><li>	<t>The DoQ specification (<xref target="RFC9250"/>) says:</t>
	<t>For the recursive to authoritative scenario, authentication requirements ar
	e unspecified at the time of writing and are the subject of ongoing work in the
	DPRIVE WG.</t>
	</li></ul>


	<t>The protocol described in this document specifies the use of DoT and DoQ with	<blockquote>For the recursive to authoritative scenario,
	out authentication of the server.</t>	authentication requirements are unspecified at the time of writing and
		are the subject of ongoing work in the DPRIVE WG.</blockquote>


	<t>This document does not pursue the use of DNS-over-HTTPS, commonly called DoH	<t>The protocol described in this document specifies the use of DoT and
	(<xref target="RFC8484"/>), in this context because a DoH client needs to know t	DoQ without authentication of the server.</t>
	he path part of a DoH endpoint URL, and there are currently no mechanisms for a	<t>This document does not pursue the use of DNS over HTTPS, commonly cal
	DNS recursive resolver to predict the path on its own, in an opportunistic or un	led "DoH" (<xref target="RFC8484"/>), in this context because a DoH client needs
	ilateral fashion, without incurring an excessive use of resources.	to know the path part of a DoH endpoint URL. Currently, there are no mechanisms
		for a DNS recursive resolver to predict the path on its own, in an opportunisti
		c or unilateral fashion, without incurring an excessive use of resources.
	If such mechanisms are later defined, the protocol in this document can be updat ed to accommodate them.</t>	If such mechanisms are later defined, the protocol in this document can be updat ed to accommodate them.</t>

		</section>
		</section>
		<section anchor="authoritative-guidance">
		<name>Guidance for Authoritative Servers</name>
		<t>The protocol described in this document is <bcp14>OPTIONAL</bcp14> for
		authoritative servers.
		An authoritative server choosing to implement the protocol described in this doc
		ument <bcp14>MUST</bcp14> implement at least one of either
		DoT or DoQ on port 853.</t>
		<t>An authoritative server choosing to implement the protocol described in
		this document <bcp14>MAY</bcp14> require clients to use Application-Layer Proto
		col Negotiation (ALPN) (see <xref target="RFC7301"/>).
		The ALPN strings the client will use are given in <xref target="recursive-
		requirements"/>.</t>


	</section>	<t>An authoritative server implementing DoT or DoQ <bcp14>MUST</bcp14> pop
	</section>	ulate the response from the same authoritative zone data as the unencrypted DNS
	<section anchor="authoritative-guidance"><name>Guidance for Authoritative Server	transports.
	s</name>	Encrypted transports have their own characteristic response size that might be d
		ifferent from the unencrypted DNS transports, so response sizes and related opti
	<t>The protocol described in this document is <bcp14>OPTIONAL</bcp14> for author	ons (e.g., Extension Mechanisms for DNS (EDNS0)) and flags (e.g., the TrunCation
	itative servers.	(TC) bit) might vary based on the transport.
	An authoritative server choosing to implement the protocol described in this doc
	ument <bcp14>MUST</bcp14> implement at least one
	of DoT or DoQ on port 853.</t>

	<t>An authoritative server choosing to implement the protocol described in this
	document <bcp14>MAY</bcp14> require clients to use ALPN (Application-Layer Proto
	col Negotiation, <xref target="RFC7301"/>).
	The ALPN strings the client will use are given in <xref target="recursive-requir
	ements"/>.</t>

	<t>An authoritative server implementing DoT or DoQ <bcp14>MUST</bcp14> populate
	the response from the same authoritative zone data as the unencryped DNS transpo
	rts.
	Encrypted transports have their own characteristic response size that might be d
	ifferent from the unencrypted DNS transports, so response sizes and related opti
	ons (e.g., EDNS0) and flags (e.g., TC bit) might vary based on the transport.
	In other words, the content of the responses to a particular query <bcp14>MUST</ bcp14> be the same regardless of the type of transport.</t>	In other words, the content of the responses to a particular query <bcp14>MUST</ bcp14> be the same regardless of the type of transport.</t>

		<section anchor="authoritative-pools">
	<section anchor="authoritative-pools"><name>Pooled Authoritative Servers Behind	<name>Pooled Authoritative Servers behind a Load Balancer</name>
	a Load Balancer</name>	<t>Some authoritative DNS servers are structured as a pool of authoritat
		ives standing behind a load balancer that runs on a single IP address, forwardin
	<t>Some authoritative DNS servers are structured as a pool of authoritatives sta	g queries to members of the pool.
	nding behind a load-balancer that runs on a single IP address, forwarding querie
	s to members of the pool.
	In such a deployment, individual members of the pool typically get updated indep endently from each other.</t>	In such a deployment, individual members of the pool typically get updated indep endently from each other.</t>

		<t>A recursive resolver following the guidance in <xref target="recursiv
	<t>A recursive resolver following the guidance in <xref target="recursive-guidan	e-guidance"/> and interacting with such a pool likely does not know that it is a
	ce"/> and interacting with such a pool likely does not know that it is a pool.	pool.
	If some members of the pool follow the protocol specified in this document while others do not, the recursive client might see the pool as a single authoritativ e server that sometimes offers and sometimes refuses encrypted transport.</t>	If some members of the pool follow the protocol specified in this document while others do not, the recursive client might see the pool as a single authoritativ e server that sometimes offers and sometimes refuses encrypted transport.</t>

		<t>To avoid incurring additional minor timeouts for such a recursive res
	<t>To avoid incurring additional minor timeouts for such a recursive resolver, t	olver, the pool operator <bcp14>SHOULD</bcp14>:</t>
	he pool operator <bcp14>SHOULD</bcp14>:</t>	<ul spacing="normal">
		<li>
	<t><list style="symbols">	<t>ensure that all members of the pool enable the same encrypted tra
	<t>ensure that all members of the pool enable the same encrypted transport(s)	nsport(s) within the span of a few seconds (such as within 30 seconds), or</t>
	within the span of a few seconds (such as within 30 seconds), or</t>	</li>
	<t>ensure that the load balancer maps client requests to pool members based on	<li>
	client IP addresses, or</t>	<t>ensure that the load balancer maps client requests to pool member
	<t>use a load-balancer that forwards queries/connections on encrypted transpor	s based on client IP addresses, or</t>
	ts to only those members of the pool known (e.g., via monitoring) to support the	</li>
	given encrypted transport.</t>	<li>
	</list></t>	<t>use a load balancer that forwards queries/connections on encrypte
		d transports to only those members of the pool known (e.g., via monitoring) to s
	<t>Similar concerns apply to authoritative servers responding from an anycast IP	upport the given encrypted transport.</t>
	address.	</li>
		</ul>
		<t>Similar concerns apply to authoritative servers responding from an an
		ycast IP address.
	As long as the pool of servers is in a heterogeneous state, any flapping route t hat switches a given client IP address to a different responder risks incurring an additional timeout.	As long as the pool of servers is in a heterogeneous state, any flapping route t hat switches a given client IP address to a different responder risks incurring an additional timeout.
	Frequent changes of routing for anycast listening IP addresses are also likely t o cause problems for TLS, TCP, or QUIC connection state as well, so stable route s are important to ensure that the service remains available and responsive.	Frequent changes of routing for anycast listening IP addresses are also likely t o cause problems for TLS, TCP, or QUIC connection state as well, so stable route s are important to ensure that the service remains available and responsive.
	The servers in a pool can share session information to increase the likelihood o f successful resumptions.</t>	The servers in a pool can share session information to increase the likelihood o f successful resumptions.</t>

		</section>
	</section>	<section anchor="authentication">
	<section anchor="authentication"><name>Authentication</name>	<name>Authentication</name>
		<t>For unilateral deployment, an authoritative server does not need to o
	<t>For unilateral deployment, an authoritative server does not need to offer any	ffer any particular form of authentication.</t>
	particular form of authentication.</t>	<t>One simple deployment approach would just be to provide a self-issued
		, regularly updated X.509 certificate.
	<t>One simple deployment approach would just be to provide a self-issued, regula
	rly-updated X.509 certificate.
	Whether the certificates used are short-lived or long-lived is up to the deploym ent.	Whether the certificates used are short-lived or long-lived is up to the deploym ent.

	This mechanism is supported by many TLS and QUIC clients, and will be acceptable for any opportunistic connection.	This mechanism is supported by many TLS and QUIC clients and will be acceptable for any opportunistic connection.
	The server could provide a normal PKI-based certificate, but there is no advanta ge to doing so at this time.</t>	The server could provide a normal PKI-based certificate, but there is no advanta ge to doing so at this time.</t>

		</section>
	</section>	<section anchor="authoritative-sni">
	<section anchor="authoritative-sni"><name>Server Name Indication</name>	<name>Server Name Indication</name>
		<t>An authoritative DNS server that wants to handle unilateral queries <
	<t>An authoritative DNS server that wants to handle unilateral queries <bcp14>MA	bcp14>MAY</bcp14> rely on Server Name Indication (SNI) to select alternate serve
	Y</bcp14> rely on Server Name Indication (SNI) to select alternate server creden	r credentials.
	tials.	However, such a server <bcp14>MUST NOT</bcp14> serve resource records that diffe
	However, such a server <bcp14>MUST NOT</bcp14> serve resource records that diffe	r based on SNI (or on the lack of an SNI) provided by the client because a probi
	r based on SNI (or on the lack of SNI) provided by the client, because a probing	ng recursive resolver that offers SNI might or might not have used the right ser
	recursive resolver that offers SNI might or might not have used the right serve	ver name to get the records it is looking for.</t>
	r name to get the records it is looking for.</t>	</section>
		<section anchor="authoritative-resource-exhaustion">
	</section>	<name>Resource Exhaustion</name>
	<section anchor="authoritative-resource-exhaustion"><name>Resource Exhaustion</n	<t>A well-behaved recursive resolver may keep an encrypted connection op
	ame>	en to an authoritative server to amortize the costs of connection setup for both
		parties.</t>
	<t>A well-behaved recursive resolver may keep an encrypted connection open to an	<t>However, some authoritative servers may have insufficient resources a
	authoritative server, to amortize the costs of connection setup for both partie	vailable to keep many connections open concurrently.</t>
	s.</t>	<t>To keep resources under control, authoritative servers should proacti
		vely manage their encrypted connections.
	<t>However, some authoritative servers may have insufficient resources available	<xref section="5.5" sectionFormat="of" target="RFC9250"/> offers useful guidance
	to keep many connections open concurrently.</t>	for servers managing DoQ connections.

	<t>To keep resources under control, authoritative servers should proactively man
	age their encrypted connections.
	<xref section="5.5" sectionFormat="of" target="RFC9250"/> ("Connection Handling"
	) offers useful guidance for servers managing DoQ connections.
	<xref section="3.4" sectionFormat="of" target="RFC7858"/> offers useful guidance for servers managing DoT connections.</t>	<xref section="3.4" sectionFormat="of" target="RFC7858"/> offers useful guidance for servers managing DoT connections.</t>

		<t>An authoritative server facing unforeseen resource exhaustion <bcp14>
	<t>An authoritative server facing unforeseen resource exhaustion <bcp14>SHOULD</	SHOULD</bcp14> cleanly close open connections from recursive resolvers based on
	bcp14> cleanly close open connections from recursive resolvers based on the auth	the authoritative server's preferred prioritization.</t>
	oritative's preferred prioritization.</t>	<t>In the case of unanticipated resource exhaustion, close connections u
		ntil resources are back in control.
	<t>In the case of unanticipated resource exhaustion, close connections until res
	ources are back in control.
	A reasonable prioritization scheme would be to close connections with no outstan ding queries, ordered by idle time (longest idle time gets closed first), then c lose connections with outstanding queries, ordered by age of outstanding query ( oldest outstanding query gets closed first).</t>	A reasonable prioritization scheme would be to close connections with no outstan ding queries, ordered by idle time (longest idle time gets closed first), then c lose connections with outstanding queries, ordered by age of outstanding query ( oldest outstanding query gets closed first).</t>

		<t>When resources are especially tight, the authoritative server may als
	<t>When resources are especially tight, the authoritative server may also declin	o decline to accept new connections over encrypted transport.</t>
	e to accept new connections over encrypted transport.</t>	</section>
		<section anchor="pad-responses-to-mitigate-traffic-analysis">
	</section>	<name>Pad Responses to Mitigate Traffic Analysis</name>
	<section anchor="pad-responses-to-mitigate-traffic-analysis"><name>Pad Responses	<t>To increase the anonymity set for each response, the authoritative se
	to Mitigate Traffic Analysis</name>	rver <bcp14>SHOULD</bcp14> use a sensible padding mechanism for all responses it
		sends when possible.
	<t>To increase the anonymity set for each response, the authoritative server <bc	The ability for the authoritative server to add padding might be limited, such a
	p14>SHOULD</bcp14> use a sensible padding mechanism for all responses it sends w	s by not receiving an EDNS0 option in the query.
	hen possible.	Specifically, a DoT server <bcp14>SHOULD</bcp14> use EDNS0 padding <xref target=
	The ability for the authoritative server to add padding might be limited, such a	"RFC7830"/> if possible, and a DoQ server <bcp14>SHOULD</bcp14> follow the guida
	s by not receiving an EDNS(0) option in the query.	nce in <xref section="5.4" sectionFormat="of" target="RFC9250"/>.
	Specifically, a DoT server <bcp14>SHOULD</bcp14> use EDNS(0) padding <xref targe
	t="RFC7830"/> if possible, and a DoQ server <bcp14>SHOULD</bcp14> follow the gui
	dance in <xref section="5.4" sectionFormat="of" target="RFC9250"/>.
	How much to pad is out of scope of this document, but a reasonable suggestion ca n be found in <xref target="RFC8467"/>.</t>	How much to pad is out of scope of this document, but a reasonable suggestion ca n be found in <xref target="RFC8467"/>.</t>

		</section>
	</section>	</section>
	</section>	<section anchor="recursive-guidance">
	<section anchor="recursive-guidance"><name>Guidance for Recursive Resolvers</nam	<name>Guidance for Recursive Resolvers</name>
	e>	<t>The protocol described in this document is <bcp14>OPTIONAL</bcp14> for
		recursive resolvers.
	<t>The protocol described in this document is <bcp14>OPTIONAL</bcp14> for recurs
	ive resolvers.
	This section outlines a probing policy suitable for unilateral adoption by any r ecursive resolver.	This section outlines a probing policy suitable for unilateral adoption by any r ecursive resolver.
	Following this policy should not result in failed resolutions or significant del ays.</t>	Following this policy should not result in failed resolutions or significant del ays.</t>

		<section anchor="high-level-overview">
		<name>High-Level Overview</name>


	<section anchor="high-level-overview"><name>High-level Overview</name>	<t>In addition to querying on Do53, the recursive resolver will try DoT,
		DoQ, or both concurrently.
	<t>In addition to querying on Do53, the recursive resolver will try either or bo
	th of DoT and DoQ concurrently.
	The recursive resolver remembers what opportunistic encrypted transport protocol s have worked recently based on a (clientIP, serverIP, protocol) tuple.</t>	The recursive resolver remembers what opportunistic encrypted transport protocol s have worked recently based on a (clientIP, serverIP, protocol) tuple.</t>

		<t>If a query needs to go to a given authoritative server, and the recur
	<t>If a query needs to go to a given authoritative server, and the recursive res	sive resolver remembers a recent successful encrypted transport to that server,
	olver remembers a recent successful encrypted transport to that server, then it	then it doesn't send the query over Do53 at all.
	doesn't send the query over Do53 at all.
	Rather, it only sends the query using the encrypted transport protocol that was recently shown to be good.</t>	Rather, it only sends the query using the encrypted transport protocol that was recently shown to be good.</t>

	<t>If the encrypted transport protocol fails, the recursive resolver falls back to Do53 for that serverIP.	<t>If the encrypted transport protocol fails, the recursive resolver falls back to Do53 for that serverIP.

	When any encrypted transport fails, the recursive resolver remembers that failur e for a reasonable amount of time to avoid flooding a non-compatible server with requests that it cannot accept.	When any encrypted transport fails, the recursive resolver remembers that failur e for a reasonable amount of time to avoid flooding an incompatible server with requests that it cannot accept.
	The description of how an encrypted transport protocol fails is in <xref target= "establish-encrypted"/> and the sections following that.</t>	The description of how an encrypted transport protocol fails is in <xref target= "establish-encrypted"/> and the sections following that.</t>

		<t>See the subsections below for a more detailed description of this pro
	<t>See the subsections below for a more detailed description of this protocol.</	tocol.</t>
	t>	</section>
		<section anchor="maintaining-authoritative-state-by-ip-address">
	</section>	<name>Maintaining Authoritative State by IP Address</name>
	<section anchor="maintaining-authoritative-state-by-ip-address"><name>Maintainin	<t>In designing a probing strategy, the recursive resolver could record
	g Authoritative State by IP Address</name>	its knowledge about any given authoritative server with different strategies, in
		cluding at least:</t>
	<t>In designing a probing strategy, the recursive resolver could record its know	<ul spacing="normal">
	ledge about any given authoritative server with different strategies, including	<li>
	at least:</t>	<t>the authoritative server's IP address,</t>
		</li>
	<t><list style="symbols">	<li>
	<t>the authoritative server's IP address,</t>	<t>the authoritative server's name (the NS record used), or</t>
	<t>the authoritative server's name (the NS record used), or</t>	</li>
	<t>the zone that contains the record being looked up.</t>	<li>
	</list></t>	<t>the zone that contains the record being looked up.</t>
		</li>
	<t>This document encourages the first strategy, to minimize timeouts or accident	</ul>
	al delays,	<t>This document encourages the first strategy, to minimize timeouts or
		accidental delays,
	and does not describe the other two strategies.</t>	and does not describe the other two strategies.</t>

		<t>A timeout (accidental delay) is most likely to happen when the recurs
	<t>A timeout (accidental delay) is most likely to happen when the recursive clie	ive client believes that the authoritative server offers encrypted transport, bu
	nt believes that the authoritative server offers encrypted transport, but the ac	t the actual server reached declines encrypted transport (or worse, filters the
	tual server reached declines encrypted transport (or worse, filters the incoming	incoming traffic and does not even respond with an ICMP destination port unreach
	traffic and does not even respond with an ICMP destination port unreachable mes	able message, such as during rate limiting).</t>
	sage, such as during rate limiting).</t>	<t>By associating the state with the authoritative IP address, the clien
		t can minimize the number of accidental delays introduced (see also Sections <xr
	<t>By associating the state with the authoritative IP address, the client can mi	ef target="authoritative-pools" format="counter"/> and <xref target="conn-state"
	nimize the number of accidental delays introduced (see also <xref target="author	format="counter"/>).</t>
	itative-pools"/> and <xref target="conn-state"/>).</t>	<t>For example, consider an authoritative server named <tt>ns0.example.c
		om</tt> that is served by two installations: one at <tt>2001:db8::7</tt> that fo
	<t>For example, consider an authoritative server named <spanx style="verb">ns0.e	llows this guidance and one at <tt>2001:db8::8</tt> that is a legacy (cleartext
	xample.com</spanx> that is served by two installations, one at <spanx style="ver	port 53-only) deployment.
	b">2001:db8::7</spanx> that follows this guidance, and one at <spanx style="verb	A recursive client who associates state with the NS name and reaches <tt>2001:db
	">2001:db8::8</spanx> that is a legacy (cleartext port 53-only) deployment.	8::7</tt> first will "learn" that <tt>ns0.example.com</tt> supports encrypted tr
	A recursive client who associates state with the <spanx style="verb">NS</spanx>	ansport.
	name and reaches <spanx style="verb">2001:db8::7</spanx> first will "learn" that	A subsequent query over encrypted transport dispatched to <tt>2001:db8::8</tt> w
	<spanx style="verb">ns0.example.com</spanx> supports encrypted transport.	ould fail, potentially delaying the response.</t>
	A subsequent query over encrypted transport dispatched to <spanx style="verb">20	</section>
	01:db8::8</spanx> would fail, potentially delaying the response.</t>	<section anchor="overall-recursive-resolver-settings">
		<name>Overall Recursive Resolver Settings</name>
	</section>	<t>A recursive resolver implementing the protocol in this document needs
	<section anchor="overall-recursive-resolver-settings"><name>Overall Recursive Re	to set system-wide values for some default parameters.
	solver Settings</name>

	<t>A recursive resolver implementing the protocol in this document needs to set
	system-wide values for some default parameters.
	These parameters may be set independently for each supported encrypted transport , though a simple implementation may keep the parameters constant across encrypt ed transports.</t>	These parameters may be set independently for each supported encrypted transport , though a simple implementation may keep the parameters constant across encrypt ed transports.</t>


	<texttable title="Recursive resolver system parameters per encrypted transport">	<table>
	<ttcol align='left'>Name</ttcol>	<name>Recursive Resolver System Parameters per Encrypted Transport</na
	<ttcol align='left'>Description</ttcol>	me>
	<ttcol align='left'>Suggested Default</ttcol>	<thead>
	<c><spanx style="verb">persistence</spanx></c>	<tr>
	<c>How long should the recursive resolver remember successful encrypted tr	<th align="left">Name</th>
	ansport connections?</c>	<th align="left">Description</th>
	<c>3 days (259200 seconds)</c>	<th align="left">Suggested Default</th>
	<c><spanx style="verb">damping</spanx></c>	</tr>
	<c>How long should the recursive resolver remember unsuccessful encrypted	</thead>
	transport connections?</c>	<tbody>
	<c>1 day (86400 seconds)</c>	<tr>
	<c><spanx style="verb">timeout</spanx></c>	<td align="left">
	<c>How long should the recursive resolver wait for an initiated encrypted	<tt>persistence</tt></td>
	connection to complete?</c>	<td align="left">How long the recursive resolver remembers a succe
	<c>4 seconds</c>	ssful encrypted transport connection</td>
	</texttable>	<td align="left">3 days (259200 seconds)</td>
		</tr>
	<t>This document uses the notation <spanx style="verb"><transport>-foo</sp	<tr>
	anx> to refer to the <spanx style="verb">foo</spanx> parameter for the encrypted	<td align="left">
	transport <spanx style="verb"><transport></spanx>.	<tt>damping</tt></td>
	For example, <spanx style="verb">DoT-persistence</spanx> would indicate the leng	<td align="left">How long the recursive resolver remembers an unsu
	th of time that the recursive resolver will remember that an authoritative serve	ccessful encrypted transport connection</td>
	r had a successful connection over <spanx style="verb">DoT</spanx>.	<td align="left">1 day (86400 seconds)</td>
	Additionally, when describing an arbitrary encrypted transport, we use <spanx st	</tr>
	yle="verb">E</spanx> in place of <spanx style="verb"><transport></spanx> t	<tr>
	o generically mean whatever encrypted transport is in use.	<td align="left">
	For example, when handling a query sent over encrypted transport <spanx style="v	<tt>timeout</tt></td>
	erb">E</spanx>, a reference to <spanx style="verb">E-timeout</spanx> should be u	<td align="left">How long the recursive resolver waits for an init
	nderstood to mean <spanx style="verb">DoT-timeout</spanx> if the query is sent o	iated encrypted connection to complete</td>
	ver <spanx style="verb">DoT</spanx>, and to mean <spanx style="verb">DoQ-timeout	<td align="left">4 seconds</td>
	</spanx> if the query is sent over <spanx style="verb">DoQ</spanx>.</t>	</tr>
		</tbody>
	<t>This document also assumes that the recursive resolver maintains a list of ou	</table>
	tstanding cleartext queries destined for the authoritative server's IP address <	<t>This document uses the notation <tt><transport>-foo</tt> to ref
	spanx style="verb">X</spanx>.	er to the <tt>foo</tt> parameter for the encrypted transport <tt><transport&g
	This list is referred to as <spanx style="verb">Do53-queries[X]</spanx>.	t;</tt>.
		For example, <tt>DoT-persistence</tt> would indicate the length of time that the
		recursive resolver will remember that an authoritative server had a successful
		connection over DoT.
		Additionally, when describing an arbitrary encrypted transport, we use <tt>E</tt
		> in place of <tt><transport></tt> to generically mean whatever encrypted
		transport is in use.
		For example, when handling a query sent over encrypted transport <tt>E</tt>, a r
		eference to <tt>E-timeout</tt> should be understood to mean <tt>DoT-timeout</tt>
		if the query is sent over DoT, and to mean <tt>DoQ-timeout</tt> if the query is
		sent over DoQ.</t>
		<t>This document also assumes that the recursive resolver maintains a li
		st of outstanding cleartext queries destined for the authoritative server's IP a
		ddress <tt>X</tt>.
		This list is referred to as "<tt>Do53-queries[X]</tt>"
	This document does not attempt to describe the specific operation of sending and receiving cleartext DNS queries (Do53) for a recursive resolver.	This document does not attempt to describe the specific operation of sending and receiving cleartext DNS queries (Do53) for a recursive resolver.
	Instead it describes a "bolt-on" mechanism that extends the recursive resolver's operation on a few simple hooks into the recursive resolver's existing handling of Do53.</t>	Instead it describes a "bolt-on" mechanism that extends the recursive resolver's operation on a few simple hooks into the recursive resolver's existing handling of Do53.</t>

		<t>Implementers or deployers of DNS recursive resolvers that follow the
		strategies in this document are encouraged to publish their preferred values of
		these parameters.</t>
		</section>


	<t>Implementers or deployers of DNS recursive resolvers that follow the strategi	<section anchor="recursive-requirements">
	es in this document are encouraged to publish their preferred values of these pa	<name>Recursive Resolver Requirements</name>
	rameters.</t>	<t>To follow the strategies in this document, a recursive resolver <bcp1
		4>MUST</bcp14> implement at least one of either DoT or DoQ in its capacity as a
	</section>	client of authoritative nameservers.
	<section anchor="recursive-requirements"><name>Recursive Resolver Requirements</
	name>

	<t>To follow this guidance, a recursive resolver <bcp14>MUST</bcp14> implement a
	t least one of either DoT or DoQ in its capacity as a client of authoritative na
	meservers.
	A recursive resolver <bcp14>SHOULD</bcp14> implement the client side of DoT.	A recursive resolver <bcp14>SHOULD</bcp14> implement the client side of DoT.
	A recursive resolver <bcp14>SHOULD</bcp14> implement the client side of DoQ.</t>	A recursive resolver <bcp14>SHOULD</bcp14> implement the client side of DoQ.</t>

		<t>DoT queries from the recursive resolver <bcp14>MUST</bcp14> target TC
		P port 853 using an ALPN of "<tt>dot</tt>".
		DoQ queries from the recursive resolver <bcp14>MUST</bcp14> target UDP port 853
		using an ALPN of "<tt>doq</tt>".</t>
		<t>While this document focuses on the recursive-to-authoritative hop, a
		recursive resolver implementing the strategies in this document <bcp14>SHOULD</b
		cp14> also accept queries from its clients over some encrypted transport unless
		it only accepts queries from the localhost.</t>
		</section>
		<section anchor="conn-state">
		<name>Authoritative Server Encrypted Transport Connection State</name>
		<t>The recursive resolver <bcp14>SHOULD</bcp14> keep a record of the sta
		te for each authoritative server it contacts, indexed by the IP address of the a
		uthoritative server and the encrypted transports supported by the recursive reso
		lver.</t>


	<t>DoT queries from the recursive resolver <bcp14>MUST</bcp14> target TCP port 8	<t>Note that the recursive resolver might record this per-authoritative-
	53, using an ALPN of "<spanx style="verb">dot</spanx>".	IP state for each source IP address it uses as it sends its queries.
	DoQ queries from the recursive resolver <bcp14>MUST</bcp14> target UDP port 853,	For example, if a recursive resolver can send a packet to authoritative servers
	using an ALPN of "<spanx style="verb">doq</spanx>".</t>	from IP addresses <tt>2001:db8::100</tt> and <tt>2001:db8::200</tt>, it could ke
		ep two distinct sets of per-authoritative-IP state: one for each source address
	<t>While this document focuses on the recursive-to-authoritative hop, a recursiv	it uses, if the recursive resolver knows the addresses in use.
	e resolver implementing these strategies <bcp14>SHOULD</bcp14> also accept queri
	es from its clients over some encrypted transport unless it only accepts queries
	from localhost.</t>

	</section>
	<section anchor="conn-state"><name>Authoritative Server Encrypted Transport Conn
	ection State</name>

	<t>The recursive resolver <bcp14>SHOULD</bcp14> keep a record of the state for e
	ach authoritative server it contacts, indexed by the IP address of the authorita
	tive server and the encrypted transports supported by the recursive resolver.</t
	>

	<t>Note that the recursive resolver might record this per-authoritative-IP state
	for each source IP address it uses as it sends its queries.
	For example, if a recursive resolver can send a packet to authoritative servers
	from IP addresses <spanx style="verb">2001:db8::100</spanx> and <spanx style="ve
	rb">2001:db8::200</spanx>, it could keep two distinct sets of per-authoritative-
	IP state, one for each source address it uses, if the recursive resolver knows t
	he addresses in use.
	Keeping these state tables distinct for each source address makes it possible fo r a pooled authoritative server behind a load balancer to do a partial rollout w hile minimizing accidental timeouts (see <xref target="authoritative-pools"/>).< /t>	Keeping these state tables distinct for each source address makes it possible fo r a pooled authoritative server behind a load balancer to do a partial rollout w hile minimizing accidental timeouts (see <xref target="authoritative-pools"/>).< /t>

	<t>In addition to tracking the state of connection attempts and outcomes, a recu rsive resolver <bcp14>SHOULD</bcp14> record the state of established sessions fo r encrypted protocols.	<t>In addition to tracking the state of connection attempts and outcomes, a recu rsive resolver <bcp14>SHOULD</bcp14> record the state of established sessions fo r encrypted protocols.

	The details of how sessions are identified is dependent on the transport protoco l implementation (such as TLS session ticket or TLS session ID, QUIC connection ID, and so on).	The details of how sessions are identified are dependent on the transport protoc ol implementation (such as a TLS session ticket or TLS session ID, a QUIC connec tion ID, and so on).
	The use of session resumption as recommended here is limited somewhat because th e tickets are only stored within the context defined by the (clientIP, serverIP, protocols) tuples used to track client-server interaction by the recursive reso lver in a table like the one below.	The use of session resumption as recommended here is limited somewhat because th e tickets are only stored within the context defined by the (clientIP, serverIP, protocols) tuples used to track client-server interaction by the recursive reso lver in a table like the one below.
	However, session resumption still offers the ability to optimize the handshake i n some circumstances.</t>	However, session resumption still offers the ability to optimize the handshake i n some circumstances.</t>

		<t>Each record should contain the following fields for each supported en
		crypted transport, each of which would initially be <tt>null</tt>:</t>
		<table>
		<name>Recursive Resolver State per-Authoritative-IP and per-Encrypted
		Transport</name>
		<thead>
		<tr>
		<th align="left">Name</th>
		<th align="left">Description</th>
		<th align="left">Retain Across Restart</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left">
		<tt>session</tt></td>
		<td align="left">The associated state of any existing established
		session (the structure of this value is dependent on the encrypted transport imp
		lementation). If <tt>session</tt> is not <tt>null</tt>, it may be in one of two
		states: <tt>pending</tt> or <tt>established</tt>.</td>
		<td align="left">no</td>
		</tr>
		<tr>
		<td align="left">
		<tt>initiated</tt></td>
		<td align="left">Timestamp of the most recent connection attempt</
		td>
		<td align="left">yes</td>
		</tr>
		<tr>
		<td align="left">
		<tt>completed</tt></td>
		<td align="left">Timestamp of the most recent completed handshake
		(which can include one where an existing session is resumed)</td>
		<td align="left">yes</td>
		</tr>
		<tr>
		<td align="left">
		<tt>status</tt></td>
		<td align="left">Enumerated value of <tt>success</tt>, <tt>fail</t
		t>, or <tt>timeout</tt> associated with the <tt>completed</tt> handshake</td>
		<td align="left">yes</td>
		</tr>
		<tr>
		<td align="left">
		<tt>last-response</tt></td>
		<td align="left">A timestamp of the most recent response received
		on the connection</td>
		<td align="left">yes</td>
		</tr>
		<tr>
		<td align="left">
		<tt>resumptions</tt></td>
		<td align="left">A stack of resumption tickets (and associated par
		ameters) that could be used to resume a prior successful session</td>
		<td align="left">yes</td>
		</tr>
		<tr>
		<td align="left">
		<tt>queries</tt></td>
		<td align="left">A queue of queries intended for this authoritativ
		e server, each of which has additional status of <tt>early</tt>, <tt>unsent</tt>
		, or <tt>sent</tt></td>
		<td align="left">no</td>
		</tr>
		<tr>
		<td align="left">
		<tt>last-activity</tt></td>
		<td align="left">A timestamp of the most recent activity on the co
		nnection</td>
		<td align="left">no</td>
		</tr>
		</tbody>
		</table>
		<t>Note that the <tt>session</tt> fields in aggregate constitute a pool
		of open connections to different servers.</t>
		<t>With the exception of the <tt>session</tt>, <tt>queries</tt>, and <tt
		>last-activity</tt> fields, this cache information should be kept across restart
		of the server unless explicitly cleared by administrative action.</t>
		<t>This document uses the notation <tt>E-foo[X]</tt> to indicate the val
		ue of field <tt>foo</tt> for encrypted transport <tt>E</tt> to IP address <tt>X<
		/tt>.</t>
		<t>For example, <tt>DoT-initiated[192.0.2.4]</tt> represents the timesta
		mp when the most recent DoT connection packet was sent to IP address <tt>192.0.2
		.4</tt>.</t>
		<t>This document uses the notation <tt>any-E-queries</tt> to indicate an
		y query on an encrypted transport.</t>
		</section>
		<section anchor="probing-policy">
		<name>Probing Policy</name>
		<t>When a recursive resolver discovers the need for an authoritative loo
		kup to an authoritative DNS server using that server's IP address <tt>X</tt>, it
		retrieves the connection state records described in <xref target="conn-state"/>
		associated with <tt>X</tt> from its cache.</t>


	<t>Each record should contain the following fields for each supported encrypted	<t>Some of the subsections that follow offer pseudocode that corresponds
	transport, each of which would initially be <spanx style="verb">null</spanx>:</t	roughly to an asynchronous programming model for a recursive resolver's interac
	>	tions with authoritative servers.
		All subsections also presume that the time of the discovery of the need for look
	<texttable title="Recursive resolver state per authoritative IP, per encrypted t	up is time <tt>T0</tt>.</t>
	ransport">	<t>If any of the records discussed here are absent, they are treated as <tt>null
	<ttcol align='left'>Name</ttcol>	</tt>.</t>
	<ttcol align='left'>Description</ttcol>
	<ttcol align='left'>Retain Across Restart</ttcol>
	<c><spanx style="verb">session</spanx></c>
	<c>The associated state of any existing, established session (the structur
	e of this value is dependent on the encrypted transport implementation). If <sp
	anx style="verb">session</spanx> is not <spanx style="verb">null</spanx>, it may
	be in one of two states: <spanx style="verb">pending</spanx> or <spanx style="v
	erb">established</spanx></c>
	<c>no</c>
	<c><spanx style="verb">initiated</spanx></c>
	<c>Timestamp of most recent connection attempt</c>
	<c>yes</c>
	<c><spanx style="verb">completed</spanx></c>
	<c>Timestamp of most recent completed handshake (which can include one whe
	re an existing session is resumed)</c>
	<c>yes</c>
	<c><spanx style="verb">status</spanx></c>
	<c>Enumerated value of <spanx style="verb">success</spanx> or <spanx style
	="verb">fail</spanx> or <spanx style="verb">timeout</spanx>, associated with the
	<spanx style="verb">completed</spanx> handshake</c>
	<c>yes</c>
	<c><spanx style="verb">last-response</spanx></c>
	<c>A timestamp of the most recent response received on the connection</c>
	<c>yes</c>
	<c><spanx style="verb">resumptions</spanx></c>
	<c>A stack of resumption tickets (and associated parameters) that could be
	used to resume a prior successful session</c>
	<c>yes</c>
	<c><spanx style="verb">queries</spanx></c>
	<c>A queue of queries intended for this authoritative server, each of whic
	h has additional status <spanx style="verb">early</spanx>, <spanx style="verb">u
	nsent</spanx>, or <spanx style="verb">sent</spanx></c>
	<c>no</c>
	<c><spanx style="verb">last-activity</spanx></c>
	<c>A timestamp of the most recent activity on the connection</c>
	<c>no</c>
	</texttable>

	<t>Note that the <spanx style="verb">session</spanx> fields in aggregate constit
	ute a pool of open connections to different servers.</t>

	<t>With the exception of the <spanx style="verb">session</spanx>, <spanx style="
	verb">queries</spanx>, and <spanx style="verb">last-activity</spanx> fields, thi
	s cache information should be kept across restart of the server unless explicitl
	y cleared by administrative action.</t>

	<t>This document uses the notation <spanx style="verb">E-foo[X]</spanx> to indic
	ate the value of field <spanx style="verb">foo</spanx> for encrypted transport <
	spanx style="verb">E</spanx> to IP address <spanx style="verb">X</spanx>.</t>

	<t>For example, <spanx style="verb">DoT-initiated[192.0.2.4]</spanx> represents
	the timestamp when the most recent DoT connection packet was sent to IP address
	192.0.2.4.</t>

	<t>This document uses the notation <spanx style="verb">any-E-queries</spanx> to
	indicate any query on an encrypted transport.</t>

	</section>
	<section anchor="probing-policy"><name>Probing Policy</name>

	<t>When a recursive resolver discovers the need for an authoritative lookup to a
	n authoritative DNS server using that servers's IP address <spanx style="verb">X
	</spanx>, it retrieves the connection state records described in <xref target="c
	onn-state"/> associated with <spanx style="verb">X</spanx> from its cache.</t>

	<t>The subsections that follow offer pseudocode that corresponds roughly to an a
	synchronous programming model for a recursive resolver's interactions with autho
	ritative servers.
	The following subsections also presume that the time of the discovery of the nee
	d for lookup is time <spanx style="verb">T0</spanx>.</t>

	<t>If any of the records discussed here are absent, they are treated as <spanx s
	tyle="verb">null</spanx>.</t>

	<t>The recursive resolver must decide whether to initially send a query over Do5
	3, or over any of the supported encrypted transports (DoT or DoQ).</t>

	<t>Note that a recursive resolver might initiate this query via any or all of th
	e known transports.
	When multiple queries are sent, the initial packets for each connection can be s
	ent concurrently, similar to "Happy Eyeballs" (<xref target="RFC8305"/>).
	However, unlike Happy Eyeballs, when one transport succeeds, the other connectio
	ns do not need to be terminated, but can instead be continued to establish wheth
	er the IP address <spanx style="verb">X</spanx> is capable of communicating on t
	he relevant transport.</t>

	<section anchor="sending-a-query-over-do53"><name>Sending a Query over Do53</nam
	e>

	<t>For any of the supported encrypted transports <spanx style="verb">E</spanx>,
	if either of the following holds true, the recursive resolver <bcp14>SHOULD NOT<
	/bcp14> send a query to <spanx style="verb">X</spanx> over Do53:</t>

	<t><list style="symbols">
	<t><spanx style="verb">E-session[X]</spanx> is in the <spanx style="verb">esta
	blished</spanx> state, or</t>
	<t><spanx style="verb">E-status[X]</spanx> is <spanx style="verb">success</spa
	nx>, and <spanx style="verb">(T0 - E-last-response[X]) < persistence</spanx><
	/t>
	</list></t>

	<t>This indicates that one successful connection to a server that the client the
	n closed cleanly would result in the client not sending the next query over Do53
	.</t>

	<t>Otherwise, if there is no outstanding session for any encrypted transport, an
	d the last successful encrypted transport connection was long ago, the recursive
	resolver sends a query to <spanx style="verb">X</spanx> over Do53.
	When it does so, it inserts a handle for the query in <spanx style="verb">Do53-q
	ueries[X]</spanx>.</t>

	</section>
	<section anchor="receiving-a-response-over-do53"><name>Receiving a Response over
	Do53</name>

	<t>When any response <spanx style="verb">R</spanx> (a well-formed DNS response,
	asynchronous timeout, asynchronous destination port unreachable, etc) for query
	<spanx style="verb">Q</spanx> arrives at the recursive resolver in cleartext sen
	t over Do53 from authoritative server with IP address <spanx style="verb">X</spa
	nx>, the recursive resolver should:</t>

	<t>If <spanx style="verb">Q</spanx> is not in <spanx style="verb">Do53-queries[X
	]</spanx>:</t>

	<t><list style="symbols">
	<t>Process <spanx style="verb">R</spanx> no further (do not respond to a clear
	text response to a query that is not outstanding)</t>
	</list></t>

	<t>Otherwise, if <spanx style="verb">Q</spanx> was marked as already processed:<
	/t>

	<t><list style="symbols">
	<t>Remove <spanx style="verb">Q</spanx> from <spanx style="verb">Do53-queries[
	X]</spanx></t>
	<t>Discard any content from the response and process <spanx style="verb">R</sp
	anx> no further</t>
	</list></t>

	<t>If <spanx style="verb">R</spanx> is a well-formed DNS response:</t>

	<t><list style="symbols">
	<t>Remove <spanx style="verb">Q</spanx> from <spanx style="verb">Do53-queries[
	X]</spanx></t>
	<t><spanx style="verb">R</spanx> is further processed by the recursive resolve
	r</t>
	<t>For each supported encrypted transport <spanx style="verb">E</spanx>:
	<list style="symbols">
	<t>If <spanx style="verb">Q</spanx> is in <spanx style="verb">E-queries[X]
	</spanx>:
	<list style="symbols">
	<t>Mark <spanx style="verb">Q</spanx> as already processed</t>
	</list></t>
	</list></t>
	</list></t>

	<t>But if <spanx style="verb">R</spanx> is malformed, or a failure (e.g., a time
	out or destination port unreachable):</t>

	<t><list style="symbols">
	<t>if <spanx style="verb">Q</spanx> is not in any of <spanx style="verb">any-E
	-queries[X]</spanx>:
	<list style="symbols">
	<t>Treat this as a failed query (i.e., follow the resolver's policy for un
	responsive or non-compliant authoritatives, such as falling back to another auth
	oritative server, returning <spanx style="verb">SERVFAIL</spanx> to the requesti
	ng client, and so on)</t>
	</list></t>
	</list></t>

	</section>
	<section anchor="initiating-a-connection-over-encrypted-transport"><name>Initiat
	ing a Connection over Encrypted Transport</name>

	<t>If any <spanx style="verb">E-session[X]</spanx> is in the <spanx style="verb"
	>established</spanx> state, the recursive resolver <bcp14>SHOULD NOT</bcp14> ini
	tiate a new or resume a previous connection to <spanx style="verb">X</spanx> ove
	r Do53 or <spanx style="verb">E</spanx>, but should instead send queries to <spa
	nx style="verb">X</spanx> through the existing session (see <xref target="sendin
	g"/>).</t>

	<t>If the recursive resolver prefers one encrypted transport over another, but o
	nly the unpreferred encrypted transport is in the <spanx style="verb">establishe
	d</spanx> state, it <bcp14>MAY</bcp14> also initiate a new connection to <spanx
	style="verb">X</spanx> over its preferred encrypted transport while concurrently
	sending the query over the <spanx style="verb">established</spanx> encrypted tr
	ansport <spanx style="verb">E</spanx>.</t>

	<t>Before considering whether to initiate a new connection over an encrypted tra
	nsport, the timer should be examined, and its state possibly refreshed, for encr
	ypted transport <spanx style="verb">E</spanx> to authoritative IP address <spanx
	style="verb">X</spanx>:</t>

	<t><list style="symbols">
	<t>if <spanx style="verb">E-session[X]</spanx> is in state <spanx style="verb"
	>pending</spanx>, and</t>
	<t><spanx style="verb">T0 - E-initiated[X] > E-timeout</spanx>, then
	<list style="symbols">
	<t>set <spanx style="verb">E-session[X]</spanx> to <spanx style="verb">nul
	l</spanx> and</t>
	<t>set <spanx style="verb">E-status[X]</spanx> to <spanx style="verb">time
	out</spanx></t>
	</list></t>
	</list></t>

	<t>When resources are available to attempt a new encrypted transport, the recurs
	ive resolver should only initiate a new connection to <spanx style="verb">X</spa
	nx> over <spanx style="verb">E</spanx> as long as one of the following holds tru
	e:</t>

	<t><list style="symbols">
	<t><spanx style="verb">E-status[X]</spanx> is <spanx style="verb">success</spa
	nx>, or</t>
	<t><spanx style="verb">E-status[X]</spanx> is either <spanx style="verb">fail<
	/spanx> or <spanx style="verb">timeout</spanx>, and <spanx style="verb">(T0 - E-
	completed[X]) > damping</spanx>, or</t>
	<t><spanx style="verb">E-status[X]</spanx> is <spanx style="verb">null</spanx>
	and <spanx style="verb">E-initiated[X]</spanx> is <spanx style="verb">null</spa
	nx></t>
	</list></t>

	<t>When initiating a session to <spanx style="verb">X</spanx> over encrypted tra
	nsport <spanx style="verb">E</spanx>, if <spanx style="verb">E-resumptions[X]</s
	panx> is not empty, one ticket should be popped off the stack and used to try to
	resume a previous session.
	Otherwise, the initial Client Hello handshake should not try to resume any sessi
	on.</t>

	<t>When initiating a connection, the recursive resolver should take the followin
	g steps:</t>

	<t><list style="symbols">
	<t>set <spanx style="verb">E-initiated[X]</spanx> to <spanx style="verb">T0</s
	panx></t>
	<t>store a handle for the new session (which should have <spanx style="verb">p
	ending</spanx> state) in <spanx style="verb">E-session[X]</spanx></t>
	<t>insert a handle for the query that prompted this connection in <spanx style
	="verb">E-queries[X]</spanx>, with status <spanx style="verb">unsent</spanx> or
	<spanx style="verb">early</spanx>, as appropriate (see below).</t>
	</list></t>


	<section anchor="early-data"><name>Early Data</name>	<t>The recursive resolver must decide whether to initially send a query
		over Do53, or over either of the supported encrypted transports (DoT or DoQ).</t
		>
		<t>Note that a recursive resolver might initiate this query via any or a
		ll of the known transports.
		When multiple queries are sent, the initial packets for each connection can be s
		ent concurrently, similar to the method used in the document known as "Happy Eye
		balls" (<xref target="RFC8305"/>).
		However, unlike Happy Eyeballs, when one transport succeeds, the other connectio
		ns do not need to be terminated; instead they can be continued to establish whet
		her the IP address <tt>X</tt> is capable of communicating on the relevant transp
		ort.</t>
		<section anchor="sending-a-query-over-do53">
		<name>Sending a Query over Do53</name>
		<t>For any of the supported encrypted transports <tt>E</tt>, the recur
		sive resolver <bcp14>SHOULD NOT</bcp14> send a query to <tt>X</tt> over Do53 if
		either of the following holds true:</t>


	<t>Modern encrypted transports like TLS 1.3 offer the chance to send "early data	<ul spacing="normal">
	" from the client in the initial Client Hello in some contexts.	<li>
		<t><tt>E-session[X]</tt> is in the <tt>established</tt> state, or<
		/t>
		</li>
		<li>
		<t><tt>E-status[X]</tt> is <tt>success</tt> and <tt>(T0 - E-last-re
		sponse[X]) < persistence</tt>.</t>
		</li>
		</ul>
		<t>This indicates that one successful connection to a server that the
		client then closed cleanly would result in the client not sending the next query
		over Do53.</t>
		<t>Otherwise, if there is no outstanding session for any encrypted tra
		nsport, and the last successful encrypted transport connection was long ago, the
		recursive resolver sends a query to <tt>X</tt> over Do53.
		When it does so, it inserts a handle for the query in <tt>Do53-queries[X]</tt>.<
		/t>
		</section>
		<section anchor="receiving-a-response-over-do53">
		<name>Receiving a Response over Do53</name>
		<t>When any response <tt>R</tt> (a well-formed DNS response, asynchron
		ous timeout, asynchronous destination port unreachable, etc.) for query <tt>Q</t
		t> arrives at the recursive resolver in cleartext sent over Do53 from an authori
		tative server with IP address <tt>X</tt>, the recursive resolver should perform
		the following.</t>
		<t>If <tt>Q</tt> is not in <tt>Do53-queries[X]</tt>:</t>
		<ul spacing="normal">
		<li>
		<t>process <tt>R</tt> no further (do not respond to a cleartext re
		sponse to a query that is not outstanding).</t>
		</li>
		</ul>
		<t>Otherwise, if <tt>Q</tt> was marked as already processed:</t>
		<ul spacing="normal">
		<li>
		<t>remove <tt>Q</tt> from <tt>Do53-queries[X]</tt>,</t>
		</li>
		<li>
		<t>discard any content from the response, and process <tt>R</tt> n
		o further.</t>
		</li>
		</ul>
		<t>If <tt>R</tt> is a well-formed DNS response:</t>
		<ul spacing="normal">
		<li>
		<t>remove <tt>Q</tt> from <tt>Do53-queries[X]</tt>,</t>
		</li>
		<li>
		<t>process <tt>R</tt> further, and</t>
		</li>
		<li>
		<t>for each supported encrypted transport <tt>E</tt>:
		</t>
		<ul spacing="normal">
		<li>
		<t>if <tt>Q</tt> is in <tt>E-queries[X]</tt>, then
		</t>
		<ul spacing="normal">
		<li>
		<t>mark <tt>Q</tt> as already processed.</t>
		</li>
		</ul>
		</li>
		</ul>
		</li>
		</ul>
		<t>However, if <tt>R</tt> is malformed or a failure (e.g., a timeout o
		r destination port unreachable), and</t>
		<ul spacing="normal">
		<li>
		<t>if <tt>Q</tt> is not in any of <tt>any-E-queries[X]</tt>, then
		</t>
		<ul spacing="normal">
		<li>
		<t>treat this as a failed query (i.e., follow the resolver's p
		olicy for unresponsive or non-compliant authoritatives, such as falling back to
		another authoritative server, returning <tt>SERVFAIL</tt> to the requesting clie
		nt, and so on).</t>
		</li>
		</ul>
		</li>
		</ul>
		</section>
		<section anchor="initiating-a-connection-over-encrypted-transport">
		<name>Initiating a Connection over Encrypted Transport</name>
		<t>If any <tt>E-session[X]</tt> is in the <tt>established</tt> state,
		the recursive resolver <bcp14>SHOULD NOT</bcp14> initiate a new connection or re
		sume a previous connection to <tt>X</tt> over Do53 or <tt>E</tt>, but should ins
		tead send queries to <tt>X</tt> through the existing session (see <xref target="
		sending"/>).</t>
		<t>If the recursive resolver prefers one encrypted transport over anot
		her, but only the unpreferred encrypted transport is in the <tt>established</tt>
		state, it <bcp14>MAY</bcp14> also initiate a new connection to <tt>X</tt> over
		its preferred encrypted transport while concurrently sending the query over the
		<tt>established</tt> encrypted transport <tt>E</tt>.</t>
		<t>Before considering whether to initiate a new connection over an enc
		rypted transport, the timer should be examined, and its state possibly refreshed
		, for encrypted transport <tt>E</tt> to authoritative IP address <tt>X</tt>.</t>
		<ul spacing="normal">
		<li>
		<t>If <tt>E-session[X]</tt> is in state <tt>pending</tt>, and</t>
		</li>
		<li>
		<t><tt>T0 - E-initiated[X] > E-timeout</tt>, then
		</t>
		<ul spacing="normal">
		<li>
		<t>set <tt>E-session[X]</tt> to <tt>null</tt>, and</t>
		</li>
		<li>
		<t>set <tt>E-status[X]</tt> to <tt>timeout</tt>.</t>
		</li>
		</ul>
		</li>
		</ul>
		<t>When resources are available to attempt a new encrypted transport,
		the recursive resolver should only initiate a new connection to <tt>X</tt> over
		<tt>E</tt> as long as one of the following holds true:</t>
		<ul spacing="normal">
		<li>
		<t><tt>E-status[X]</tt> is <tt>success</tt>, or</t>
		</li>
		<li>
		<t><tt>E-status[X]</tt> is either <tt>fail</tt> or <tt>timeout</tt
		> and <tt>(T0 - E-completed[X]) > damping</tt>, or</t>
		</li>
		<li>
		<t><tt>E-status[X]</tt> is <tt>null</tt> and <tt>E-initiated[X]</t
		t> is <tt>null</tt>.</t>
		</li>
		</ul>
		<t>When initiating a session to <tt>X</tt> over encrypted transport <t
		t>E</tt>, if <tt>E-resumptions[X]</tt> is not empty, one ticket should be popped
		off the stack and used to try to resume a previous session.
		Otherwise, the initial ClientHello handshake should not try to resume any sessio
		n.</t>
		<t>When initiating a connection, the recursive resolver should take th
		e following steps:</t>
		<ul spacing="normal">
		<li>
		<t>set <tt>E-initiated[X]</tt> to <tt>T0</tt>,</t>
		</li>
		<li>
		<t>store a handle for the new session (which should have <tt>pendi
		ng</tt> state) in <tt>E-session[X]</tt>, and</t>
		</li>
		<li>
		<t>insert a handle for the query that prompted this connection in
		<tt>E-queries[X]</tt>, with status <tt>unsent</tt> or <tt>early</tt>, as appropr
		iate (see below).</t>
		</li>
		</ul>
		<section anchor="early-data">
		<name>Early Data</name>
		<t>Modern encrypted transports like TLS 1.3 offer the chance to send
		"early data" from the client in the initial ClientHello in some contexts.
	A recursive resolver that initiates a connection over an encrypted transport acc ording to this guidance in a context where early data is possible <bcp14>SHOULD< /bcp14> send the DNS query that prompted the connection in the early data, accor ding to the sending guidance in <xref target="sending"/>.</t>	A recursive resolver that initiates a connection over an encrypted transport acc ording to this guidance in a context where early data is possible <bcp14>SHOULD< /bcp14> send the DNS query that prompted the connection in the early data, accor ding to the sending guidance in <xref target="sending"/>.</t>

		<t>If it does so, the status of <tt>Q</tt> in <tt>E-queries[X]</tt>
		should be set to <tt>early</tt> instead of <tt>unsent</tt>.</t>
		</section>
		<section anchor="resumption">
		<name>Resumption Tickets</name>
		<t>When initiating a new connection (whether by resuming an old sess
		ion or not), the recursive resolver <bcp14>SHOULD</bcp14> request a session resu
		mption ticket from the authoritative server.
		If the authoritative server supplies a resumption ticket, the recursive resolver
		pushes it into the stack at <tt>E-resumptions[X]</tt>.</t>
		</section>
		<section anchor="recursive-sni">
		<name>Server Name Indication</name>
		<t>For modern encrypted transports like TLS 1.3, most client impleme
		ntations expect to send a Server Name Indication (SNI) in the ClientHello.</t>
		<t>There are two complications with selecting or sending an SNI in t
		his unilateral probing.</t>
		<ul spacing="normal">
		<li>
		<t>Some authoritative servers are known by more than one name; s
		electing a single name to use for a given connection may be difficult or impossi
		ble.</t>
		</li>
		<li>
		<t>In most configurations, the contents of the SNI field are exp
		osed on the wire to a passive adversary.
		This potentially reveals additional information about which query is being made
		based on the NS of the query itself.</t>
		</li>
		</ul>
		<t>To avoid additional leakage and complexity, a recursive resolver
		following this guidance <bcp14>SHOULD NOT</bcp14> send an SNI to the authoritati
		ve server when attempting encrypted transport.</t>
		<t>If the recursive resolver needs to send an SNI to the authoritati
		ve server for some reason not found in this document, using Encrypted ClientHell
		o (<xref target="I-D.ietf-tls-esni"/>) would reduce leakage.</t>
		</section>
		<section anchor="authoritative-server-authentication">
		<name>Authoritative Server Authentication</name>
		<t>Because this probing policy is unilateral and opportunistic, the
		client connecting under this policy <bcp14>MUST</bcp14> accept any certificate p
		resented by the server.
		If the client cannot verify the server's identity, it <bcp14>MAY</bcp14> use tha
		t information for reporting, logging, or other analysis purposes; however, it <b
		cp14>MUST NOT</bcp14> reject the connection due to the authentication failure, a
		s the result would be falling back to cleartext, which would leak the content of
		the session to a passive network monitor.</t>
		</section>
		</section>
		<section anchor="establish-encrypted">
		<name>Establishing an Encrypted Transport Connection</name>
		<t>When an encrypted transport connection actually completes (e.g., th
		e TLS handshake completes) at time <tt>T1</tt>, the recursive resolver sets <tt>
		E-completed[X]</tt> to <tt>T1</tt> and does the following.</t>
		<t>If the handshake completed successfully, the recursive resolver:</t
		>
		<ul spacing="normal">
		<li>
		<t>updates <tt>E-session[X]</tt> so that it is in state <tt>establ
		ished</tt>,</t>
		</li>
		<li>
		<t>sets <tt>E-status[X]</tt> to <tt>success</tt>,</t>
		</li>
		<li>
		<t>sets <tt>E-last-response[X]</tt> to <tt>T1</tt>,</t>
		</li>
		<li>
		<t>sets <tt>E-completed[X]</tt> to <tt>T1</tt>, and</t>
		</li>
		<li>
		<t>for each query <tt>Q</tt> in <tt>E-queries[X]</tt>:
		</t>
		<ul spacing="normal">
		<li>
		<t>if early data was accepted and <tt>Q</tt> is <tt>early</tt>
		, then
		</t>
		<ul spacing="normal">
		<li>
		<t>sets the status of <tt>Q</tt> to <tt>sent</tt>.</t>
		</li>
		</ul>
		</li>
		<li>
		<t>Otherwise:
		</t>
		<ul spacing="normal">
		<li>
		<t>sends <tt>Q</tt> through the session (see <xref target=
		"sending"/>) and sets the status of <tt>Q</tt> to <tt>sent</tt>.</t>
		</li>
		</ul>
		</li>
		</ul>
		</li>
		</ul>
		</section>
		<section anchor="failing-to-establish-an-encrypted-transport-connection"
		>
		<name>Failing to Establish an Encrypted Transport Connection</name>
		<t>If, at time <tt>T2</tt>, an encrypted transport handshake completes
		with a failure (e.g., a TLS alert):</t>
		<ul spacing="normal">
		<li>
		<t>set <tt>E-session[X]</tt> to <tt>null</tt>,</t>
		</li>
		<li>
		<t>set <tt>E-status[X]</tt> to <tt>fail</tt>,</t>
		</li>
		<li>
		<t>set <tt>E-completed[X]</tt> to <tt>T2</tt>, and</t>
		</li>
		<li>
		<t>for each query <tt>Q</tt> in <tt>E-queries[X]</tt>:
		</t>
		<ul spacing="normal">
		<li>
		<t>if <tt>Q</tt> is not present in any other <tt>any-E-queries
		[X]</tt> or in <tt>Do53-queries[X]</tt>, add <tt>Q</tt> to <tt>Do53-queries[X]</
		tt> and send query <tt>Q</tt> to <tt>X</tt> over Do53.</t>
		</li>
		</ul>
		</li>
		</ul>
		<t>Note that this failure will trigger the recursive resolver to fall
		back to cleartext queries to the authoritative server at IP address <tt>X</tt>.
		It will retry encrypted transport to <tt>X</tt> once the <tt>damping</tt> timer
		has elapsed.</t>
		</section>
		<section anchor="e-failure">
		<name>Encrypted Transport Failure</name>
		<t>Once established, an encrypted transport might fail for a number of
		reasons (e.g., decryption failure or improper protocol sequence).</t>
		<t>If this happens:</t>
		<ul spacing="normal">
		<li>
		<t>set <tt>E-session[X]</tt> to <tt>null</tt>,</t>
		</li>
		<li>
		<t>set <tt>E-status[X]</tt> to <tt>fail</tt>, and</t>
		</li>
		<li>
		<t>for each query <tt>Q</tt> in <tt>E-queries[X]</tt>:
		</t>
		<ul spacing="normal">
		<li>
		<t>if <tt>Q</tt> is not present in any other <tt>any-E-queries
		[X]</tt> or in <tt>Do53-queries[X]</tt>, add <tt>Q</tt> to <tt>Do53-queries[X]</
		tt> and send query <tt>Q</tt> to <tt>X</tt> over Do53.</t>
		</li>
		</ul>
		</li>
		</ul>
		<t>Note that this failure will trigger the recursive resolver to fall
		back to cleartext queries to the authoritative server at IP address <tt>X</tt>.
		It will retry encrypted transport to <tt>X</tt> once the <tt>damping</tt> timer
		has elapsed.</t>
		</section>
		<section anchor="e-shutdown">
		<name>Handling Clean Shutdown of an Encrypted Transport Connection</na
		me>
		<t>At time <tt>T3</tt>, the recursive resolver may find that authorita
		tive server <tt>X</tt> cleanly closes an existing outstanding connection (most l
		ikely due to resource exhaustion, see <xref target="authoritative-resource-exhau
		stion"/>).</t>
		<t>When this happens:</t>
		<ul spacing="normal">
		<li>
		<t>set <tt>E-session[X]</tt> to <tt>null</tt>, and</t>
		</li>
		<li>
		<t>for each query <tt>Q</tt> in <tt>E-queries[X]</tt>:
		</t>
		<ul spacing="normal">
		<li>
		<t>if <tt>Q</tt> is not present in any other <tt>any-E-queries
		[X]</tt> or in <tt>Do53-queries[X]</tt>, add <tt>Q</tt> to <tt>Do53-queries[X]</
		tt> and send query <tt>Q</tt> to <tt>X</tt> over Do53.</t>
		</li>
		</ul>
		</li>
		</ul>
		<t>Note that this premature shutdown will trigger the recursive resolv
		er to fall back to cleartext queries to the authoritative server at IP address <
		tt>X</tt>.
		Any subsequent query to <tt>X</tt> will retry the encrypted connection promptly.
		</t>
		</section>
		<section anchor="sending">
		<name>Sending a Query over Encrypted Transport</name>


	<t>If it does so, the status of <spanx style="verb">Q</spanx> in <spanx style="v	<t>When sending a query to an authoritative server over encrypted tran
	erb">E-queries[X]</spanx> should be set to <spanx style="verb">early</spanx> ins	sport at time <tt>T4</tt>, the recursive resolver should take a few reasonable s
	tead of <spanx style="verb">unsent</spanx>.</t>	teps to ensure privacy and efficiency.
		After sending query <tt>Q</tt>, the recursive resolver should:</t>
	</section>	<ul>
	<section anchor="resumption"><name>Resumption Tickets</name>	<li>Ensure that <tt>Q</tt>'s state in <tt>E-queries[X]</tt> is set to <tt>sent</
		tt>.</li>
	<t>When initiating a new connection (whether by resuming an old session or not),	<li>Set <tt>E-last-activity[X]</tt> to <tt>T4</tt>.</li>
	the recursive resolver <bcp14>SHOULD</bcp14> request a session resumption ticke	</ul>
	t from the authoritative server.
	If the authoritative server supplies a resumption ticket, the recursive resolver
	pushes it into the stack at <spanx style="verb">E-resumptions[X]</spanx>.</t>

	</section>
	<section anchor="recursive-sni"><name>Server Name Indication</name>

	<t>For modern encrypted transports like TLS 1.3, most client implementations exp
	ect to send a Server Name Indication (SNI) in the Client Hello.</t>

	<t>There are two complications with selecting or sending SNI in this unilateral
	probing:</t>

	<t><list style="symbols">
	<t>Some authoritative servers are known by more than one name; selecting a sin
	gle name to use for a given connection may be difficult or impossible.</t>
	<t>In most configurations, the contents of the SNI field is exposed on the wir
	e to a passive adversary.
	This potentially reveals additional information about which query is being made,
	based on the NS of the query itself.</t>
	</list></t>

	<t>To avoid additional leakage and complexity, a recursive resolver following th
	is guidance <bcp14>SHOULD NOT</bcp14> send SNI to the authoritative when attempt
	ing encrypted transport.</t>

	<t>If the recursive resolver needs to send SNI to the authoritative for some rea
	son not found in this document, using Encrypted Client Hello (<xref target="I-D.
	ietf-tls-esni"/>) would reduce leakage.</t>

	</section>
	<section anchor="authoritative-server-authentication"><name>Authoritative Server
	Authentication</name>

	<t>Because this probing policy is unilateral and opportunistic, the client conne
	cting under this policy <bcp14>MUST</bcp14> accept any certificate presented by
	the server.
	If the client cannot verify the server's identity, it <bcp14>MAY</bcp14> use tha
	t information for reporting, logging, or other analysis purposes.
	But it <bcp14>MUST NOT</bcp14> reject the connection due to the authentication f
	ailure, as the result would be falling back to cleartext, which would leak the c
	ontent of the session to a passive network monitor.</t>

	</section>
	</section>
	<section anchor="establish-encrypted"><name>Establishing an Encrypted Transport
	Connection</name>

	<t>When an encrypted transport connection actually completes (e.g., the TLS hand
	shake completes) at time <spanx style="verb">T1</spanx>, the recursive resolver
	sets <spanx style="verb">E-completed[X]</spanx> to <spanx style="verb">T1</spanx
	> and does the following:</t>

	<t>If the handshake completed successfully:</t>

	<t><list style="symbols">
	<t>update <spanx style="verb">E-session[X]</spanx> so that it is in state <spa
	nx style="verb">established</spanx></t>
	<t>set <spanx style="verb">E-status[X]</spanx> to <spanx style="verb">success<
	/spanx></t>
	<t>set <spanx style="verb">E-last-response[X]</spanx> to <spanx style="verb">T
	1</spanx></t>
	<t>set <spanx style="verb">E-completed[X]</spanx> to <spanx style="verb">T1</s
	panx></t>
	<t>for each query <spanx style="verb">Q</spanx> in <spanx style="verb">E-queri
	es[X]</spanx>:
	<list style="symbols">
	<t>if early data was accepted and <spanx style="verb">Q</spanx> is <spanx
	style="verb">early</spanx>,
	<list style="symbols">
	<t>set the status of <spanx style="verb">Q</spanx> to <spanx style="ve
	rb">sent</spanx></t>
	</list></t>
	<t>otherwise:
	<list style="symbols">
	<t>send <spanx style="verb">Q</spanx> through the session (see <xref t
	arget="sending"/>), and set the status of <spanx style="verb">Q</spanx> to <span
	x style="verb">sent</spanx></t>
	</list></t>
	</list></t>
	</list></t>

	</section>
	<section anchor="failing-to-establish-an-encrypted-transport-connection"><name>F
	ailing to Establish an Encrypted Transport Connection</name>

	<t>If, at time <spanx style="verb">T2</spanx> an encrypted transport handshake c
	ompletes with a failure (e.g., a TLS alert),</t>

	<t><list style="symbols">
	<t>set <spanx style="verb">E-session[X]</spanx> to <spanx style="verb">null</s
	panx></t>
	<t>set <spanx style="verb">E-status[X]</spanx> to <spanx style="verb">fail</sp
	anx></t>
	<t>set <spanx style="verb">E-completed[X]</spanx> to <spanx style="verb">T2</s
	panx></t>
	<t>for each query <spanx style="verb">Q</spanx> in <spanx style="verb">E-queri
	es[X]</spanx>:
	<list style="symbols">
	<t>if <spanx style="verb">Q</spanx> is not present in any other <spanx sty
	le="verb">any-E-queries[X]</spanx> or in <spanx style="verb">Do53-queries[X]</sp
	anx>, add <spanx style="verb">Q</spanx> to <spanx style="verb">Do53-queries[X]</
	spanx> and send query <spanx style="verb">Q</spanx> to <spanx style="verb">X</sp
	anx> over Do53.</t>
	</list></t>
	</list></t>

	<t>Note that this failure will trigger the recursive resolver to fall back to cl
	eartext queries to the authoritative server at IP address <spanx style="verb">X<
	/spanx>.
	It will retry encrypted transport to <spanx style="verb">X</spanx> once the <spa
	nx style="verb">damping</spanx> timer has elapsed.</t>

	</section>
	<section anchor="e-failure"><name>Encrypted Transport Failure</name>

	<t>Once established, an encrypted transport might fail for a number of reasons (
	e.g., decryption failure, or improper protocol sequence).</t>

	<t>If this happens:</t>

	<t><list style="symbols">
	<t>set <spanx style="verb">E-session[X]</spanx> to <spanx style="verb">null</s
	panx></t>
	<t>set <spanx style="verb">E-status[X]</spanx> to <spanx style="verb">fail</sp
	anx></t>
	<t>for each query <spanx style="verb">Q</spanx> in <spanx style="verb">E-queri
	es[X]</spanx>:
	<list style="symbols">
	<t>if <spanx style="verb">Q</spanx> is not present in any other <spanx sty
	le="verb">any-E-queries[X]</spanx> or in <spanx style="verb">Do53-queries[X]</sp
	anx>, add <spanx style="verb">Q</spanx> to <spanx style="verb">Do53-queries[X]</
	spanx> and send query <spanx style="verb">Q</spanx> to <spanx style="verb">X</sp
	anx> over Do53.</t>
	</list></t>
	</list></t>

	<t>Note that this failure will trigger the recursive resolver to fall back to cl
	eartext queries to the authoritative server at IP address <spanx style="verb">X<
	/spanx>.
	It will retry encrypted transport to <spanx style="verb">X</spanx> once the <spa
	nx style="verb">damping</spanx> timer has elapsed.</t>

	</section>
	<section anchor="e-shutdown"><name>Handling Clean Shutdown of an Encrypted Trans
	port Connection</name>

	<t>At time <spanx style="verb">T3</spanx>, the recursive resolver may find that
	authoritative server <spanx style="verb">X</spanx> cleanly closes an existing ou
	tstanding connection (most likely due to resource exhaustion, see <xref target="
	authoritative-resource-exhaustion"/>).</t>

	<t>When this happens:</t>

	<t><list style="symbols">
	<t>set <spanx style="verb">E-session[X]</spanx> to <spanx style="verb">null</s
	panx></t>
	<t>for each query <spanx style="verb">Q</spanx> in <spanx style="verb">E-queri
	es[X]</spanx>:
	<list style="symbols">
	<t>if <spanx style="verb">Q</spanx> is not present in any other <spanx sty
	le="verb">any-E-queries[X]</spanx> or in <spanx style="verb">Do53-queries[X]</sp
	anx>, add <spanx style="verb">Q</spanx> to <spanx style="verb">Do53-queries[X]</
	spanx> and send query <spanx style="verb">Q</spanx> to <spanx style="verb">X</sp
	anx> over Do53.</t>
	</list></t>
	</list></t>

	<t>Note that this premature shutdown will trigger the recursive resolver to fall
	back to cleartext queries to the authoritative server at IP address <spanx styl
	e="verb">X</spanx>.
	Any subsequent query to <spanx style="verb">X</spanx> will retry the encrypted c
	onnection promptly.</t>

	</section>
	<section anchor="sending"><name>Sending a Query over Encrypted Transport</name>

	<t>When sending a query to an authoritative server over encrypted transport at t
	ime <spanx style="verb">T4</spanx>, the recursive resolver should take a few rea
	sonable steps to ensure privacy and efficiency.</t>

	<t>After sending query <spanx style="verb">Q</spanx>, the recursive resolver sho
	uld ensure that <spanx style="verb">Q</spanx>'s state in <spanx style="verb">E-q
	ueries[X]</spanx> is set to <spanx style="verb">sent</spanx>.</t>

	<t>The recursive resolver also sets <spanx style="verb">E-last-activity[X]</span
	x> to <spanx style="verb">T4</spanx>.</t>

	<t>In addition, the recursive resolver should consider the guidance in the follo
	wing sections.</t>

	<section anchor="pad-queries-to-mitigate-traffic-analysis"><name>Pad Queries to
	Mitigate Traffic Analysis</name>


	<t>To increase the anonymity set for each query, the recursive resolver <bcp14>S	<t>The recursive resolver should also consider the guidance in the following sub
	HOULD</bcp14> use a sensible padding mechanism for all queries it sends.	sections.</t>
	Specifically, a DoT client <bcp14>SHOULD</bcp14> use EDNS(0) padding <xref targe	<section anchor="pad-queries-to-mitigate-traffic-analysis">
	t="RFC7830"/>, and a DoQ client <bcp14>SHOULD</bcp14> follow the guidance in <xr	<name>Pad Queries to Mitigate Traffic Analysis</name>
	ef section="5.4" sectionFormat="of" target="RFC9250"/>.	<t>To increase the anonymity set for each query, the recursive resol
		ver <bcp14>SHOULD</bcp14> use a sensible padding mechanism for all queries it se
		nds.
		Specifically, a DoT client <bcp14>SHOULD</bcp14> use EDNS0 padding <xref target=
		"RFC7830"/>, and a DoQ client <bcp14>SHOULD</bcp14> follow the guidance in <xref
		section="5.4" sectionFormat="of" target="RFC9250"/>.
	How much to pad is out of scope of this document, but a reasonable suggestion ca n be found in <xref target="RFC8467"/>.</t>	How much to pad is out of scope of this document, but a reasonable suggestion ca n be found in <xref target="RFC8467"/>.</t>

		</section>
	</section>	<section anchor="send-queries-in-separate-channels">
	<section anchor="send-queries-in-separate-channels"><name>Send Queries in Separa	<name>Send Queries in Separate Channels</name>
	te Channels</name>	<t>When multiple queries are multiplexed on a single encrypted trans
		port to a single authoritative server, the recursive resolver <bcp14>SHOULD</bcp
	<t>When multiple queries are multiplexed on a single encrypted transport to a si	14> pipeline queries and <bcp14>MUST</bcp14> be capable of receiving responses o
	ngle authoritative server, the recursive resolver <bcp14>SHOULD</bcp14> pipeline	ut of order.
	queries and <bcp14>MUST</bcp14> be capable of receiving responses out of order.
	For guidance on how to best achieve this on a given encrypted transport, see <xr ef section="6.2.1.1" sectionFormat="of" target="RFC7766"/> (for DoT) and <xref s ection="5.6" sectionFormat="of" target="RFC9250"/> (for DoQ).</t>	For guidance on how to best achieve this on a given encrypted transport, see <xr ef section="6.2.1.1" sectionFormat="of" target="RFC7766"/> (for DoT) and <xref s ection="5.6" sectionFormat="of" target="RFC9250"/> (for DoQ).</t>

		</section>
	</section>	</section>
	</section>	<section anchor="receiving-encrypted">
	<section anchor="receiving-encrypted"><name>Receiving a Response over Encrypted	<name>Receiving a Response over Encrypted Transport</name>
	Transport</name>	<t>Even though session-level events on encrypted transports like clean
		shutdown (see <xref target="e-shutdown"/>) or encrypted transport failure (see
	<t>Even though session-level events on encrypted transports like clean shutdown	<xref target="e-failure"/>) can happen, some events happen on encrypted transpor
	(see <xref target="e-shutdown"/>) or encrypted transport failure (see <xref targ	ts that are specific to a query and are not session-wide.
	et="e-failure"/>) can happen, some events happen on encrypted transport that are
	specific to a query, not session-wide.
	This subsection describes how the recursive resolver deals with events related t o a specific query.</t>	This subsection describes how the recursive resolver deals with events related t o a specific query.</t>

		<t>When a query-specific response <tt>R</tt> (a well-formed DNS respon
	<t>When a query-specific response <spanx style="verb">R</spanx> (a well-formed D	se or an asynchronous timeout) associated with query <tt>Q</tt> arrives at the r
	NS response or an asynchronous timeout) associated with query <spanx style="verb	ecursive resolver over encrypted transport <tt>E</tt> from an authoritative serv
	">Q</spanx> arrives at the recursive resolver over encrypted transport <spanx st	er with IP address <tt>X</tt> at time <tt>T5</tt>, the recursive resolver should
	yle="verb">E</spanx> from authoritative server with IP address <spanx style="ver	perform the following.</t>
	b">X</spanx> at time <spanx style="verb">T5</spanx>, the recursive resolver shou	<t>If <tt>Q</tt> is not in <tt>E-queries[X]</tt>:</t>
	ld:</t>	<ul spacing="normal">
		<li>
	<t>If <spanx style="verb">Q</spanx> is not in <spanx style="verb">E-queries[X]</	<t>discard the response and process <tt>R</tt> no further (do not
	spanx>:</t>	respond to an encrypted response to a query that is not outstanding).</t>
		</li>
	<t><list style="symbols">	</ul>
	<t>Discard the response and process <spanx style="verb">R</spanx> no further (	<t>Otherwise:</t>
	do not respond to an encrypted response to a query that is not outstanding)</t>	<ul spacing="normal">
	</list></t>	<li>
		<t>remove <tt>Q</tt> from <tt>E-queries[X]</tt>,</t>
	<t>Otherwise:</t>	</li>
		<li>
	<t><list style="symbols">	<t>set <tt>E-last-activity[X]</tt> to <tt>T5</tt>, and</t>
	<t>Remove <spanx style="verb">Q</spanx> from <spanx style="verb">E-queries[X]<	</li>
	/spanx></t>	<li>
	<t>Set <spanx style="verb">E-last-activity[X]</spanx> to <spanx style="verb">T	<t>set <tt>E-last-response[X]</tt> to <tt>T5</tt>.</t>
	5</spanx></t>	</li>
	<t>Set <spanx style="verb">E-last-response[X]</spanx> to <spanx style="verb">T	</ul>
	5</spanx></t>	<t>If <tt>Q</tt> was marked as already processed:</t>
	</list></t>	<ul spacing="normal">
		<li>
	<t>If <spanx style="verb">Q</spanx> was marked as already processed:</t>	<t>discard the response and process the response no further.</t>
		</li>
	<t><list style="symbols">	</ul>
	<t>Discard the response and process the response no further</t>	<t>If <tt>R</tt> is a well-formed DNS response:</t>
	</list></t>	<ul spacing="normal">
		<li>
	<t>If <spanx style="verb">R</spanx> is a well-formed DNS response:</t>	<t>process <tt>R</tt> further, and</t>
		</li>
	<t><list style="symbols">	<li>
	<t><spanx style="verb">R</spanx> is further processed by the recursive resolve	<t>for each supported encrypted transport <tt>N</tt> other than <t
	r</t>	t>E</tt>:
	<t>For each supported encrypted transport <spanx style="verb">N</spanx> other	</t>
	than <spanx style="verb">E</spanx>:	<ul spacing="normal">
	<list style="symbols">	<li>
	<t>If <spanx style="verb">Q</spanx> is in <spanx style="verb">N-queries[X]	<t>if <tt>Q</tt> is in <tt>N-queries[X]</tt>, then
	</spanx>:	</t>
	<list style="symbols">	<ul spacing="normal">
	<t>Mark <spanx style="verb">Q</spanx> as already processed</t>	<li>
	</list></t>	<t>mark <tt>Q</tt> as already processed.</t>
	</list></t>	</li>
	<t>If <spanx style="verb">Q</spanx> is in <spanx style="verb">Do53-queries[X]<	</ul>
	/spanx>:	</li>
	<list style="symbols">	</ul>
	<t>Mark <spanx style="verb">Q</spanx> as already processed</t>	</li>
	</list></t>	<li>
	</list></t>	<t>If <tt>Q</tt> is in <tt>Do53-queries[X]</tt>:
		</t>
	<t>But if <spanx style="verb">R</spanx> is malformed, or a failure (e.g., timeou	<ul spacing="normal">
	t):</t>	<li>
		<t>mark <tt>Q</tt> as already processed.</t>
	<t><list style="symbols">	</li>
	<t>If <spanx style="verb">Q</spanx> is not in <spanx style="verb">Do53-queries	</ul>
	[X]</spanx> or in any of <spanx style="verb">any-E-queries[X]</spanx>:	</li>
	<list style="symbols">	</ul>
	<t>Treat this as a failed query (i.e., follow the resolver's policy for un	<t>However, if <tt>R</tt> is malformed or a failure (e.g., timeout), a
	responsive or non-compliant authoritatives, such as falling back to another auth	nd</t>
	oritative server, returning <spanx style="verb">SERVFAIL</spanx> to the requesti	<ul spacing="normal">
	ng client, and so on)</t>	<li>
	</list></t>	<t>if <tt>Q</tt> is not in <tt>Do53-queries[X]</tt> or in any of <
	</list></t>	tt>any-E-queries[X]</tt>, then
		</t>
	</section>	<ul spacing="normal">
	<section anchor="recursive-resource-exhaustion"><name>Resource Exhaustion</name>	<li>
		<t>treat this as a failed query (i.e., follow the resolver's p
	<t>To keep resources under control, a recursive resolver should proactively mana	olicy for unresponsive or non-compliant authoritative servers, such as falling b
	ge outstanding encrypted connections.	ack to another authoritative server, returning <tt>SERVFAIL</tt> to the requesti
		ng client, and so on).</t>
		</li>
		</ul>
		</li>
		</ul>
		</section>
		<section anchor="recursive-resource-exhaustion">
		<name>Resource Exhaustion</name>
		<t>To keep resources under control, a recursive resolver should proact
		ively manage outstanding encrypted connections.
	<xref section="5.5" sectionFormat="of" target="RFC9250"/> offers useful guidance for clients managing DoQ connections.	<xref section="5.5" sectionFormat="of" target="RFC9250"/> offers useful guidance for clients managing DoQ connections.
	<xref section="3.4" sectionFormat="of" target="RFC7858"/> offers useful guidance for clients managing DoT connections.</t>	<xref section="3.4" sectionFormat="of" target="RFC7858"/> offers useful guidance for clients managing DoT connections.</t>

		<t>Even with sensible connection management, a recursive resolver doin
		g unilateral probing may find resources unexpectedly scarce and may need to clos
		e some outstanding connections.</t>
		<t>In such a situation, the recursive resolver <bcp14>SHOULD</bcp14> u
		se a reasonable prioritization scheme to close outstanding connections.</t>


	<t>Even with sensible connection management, a recursive resolver doing unilater	<t>One reasonable prioritization scheme would be to close outstanding
	al probing may find resources unexpectedly scarce, and may need to close some ou	<tt>established</tt> sessions based on <tt>E-last-activity[X]</tt> (i.e, the old
	tstanding connections.</t>	est timestamp gets closed first).</t>
		<t>Note that when resources are limited, a recursive resolver followin
	<t>In such a situation, the recursive resolver <bcp14>SHOULD</bcp14> use a reaso	g this guidance may also choose not to initiate new connections for encrypted tr
	nable prioritization scheme to close outstanding connections.</t>	ansport.</t>
		</section>
	<t>One reasonable prioritization scheme would be:</t>	<section anchor="maintaining-connections">
		<name>Maintaining Connections</name>
	<t><list style="symbols">	<t>Some recursive resolvers looking to amortize connection costs and m
	<t>close outstanding <spanx style="verb">established</spanx> sessions based on	inimize latency <bcp14>MAY</bcp14> choose to synthesize queries to a particular
	<spanx style="verb">E-last-activity[X]</spanx> (oldest timestamp gets closed fi	authoritative server to keep an encrypted transport session active.</t>
	rst)</t>	<t>A recursive resolver that adopts this approach should try to align
	</list></t>	the synthesized queries with other optimizations.

	<t>Note that when resources are limited, a recursive resolver following this gui
	dance may also choose not to initiate new connections for encrypted transport.</
	t>

	</section>
	<section anchor="maintaining-connections"><name>Maintaining Connections</name>

	<t>Some recursive resolvers looking to amortize connection costs and to minimize
	latency <bcp14>MAY</bcp14> choose to synthesize queries to a particular authori
	tative server to keep an encrypted transport session active.</t>

	<t>A recursive resolver that adopts this approach should try to align the synthe
	sized queries with other optimizations.
	For example, a recursive resolver that "pre-fetches" a particular resource recor d to keep its cache "hot" can send that query over an established encrypted tran sport session.</t>	For example, a recursive resolver that "pre-fetches" a particular resource recor d to keep its cache "hot" can send that query over an established encrypted tran sport session.</t>

		</section>
	</section>	<section anchor="additional-tuning">
	<section anchor="additional-tuning"><name>Additional Tuning</name>	<name>Additional Tuning</name>
		<t>A recursive resolver's state table for an authoritative server can
	<t>A recursive resolver's state table for an authoritative server can contain ad	contain additional information beyond what is described above.
	ditional information beyond what is described above.
	The recursive resolver might use that additional state to change the way it inte racts with the authoritative server in the future.	The recursive resolver might use that additional state to change the way it inte racts with the authoritative server in the future.

	Some examples of additional state include:</t>	Some examples of additional states include the following.</t>
		<ul spacing="normal">
	<t><list style="symbols">	<li>
	<t>Whether the server accepts "early data" over a transport such as DoQ;</t>	<t>Whether the server accepts "early data" over a transport such a
	<t>Whether the server fails to respond to queries after the handshake succeeds	s DoQ.</t>
	;</t>	</li>
	<t>Tracking the round trip time of queries to the server;</t>	<li>
	<t>Tracking the number of timeouts (compared to the number of successful queri	<t>Whether the server fails to respond to queries after the handsh
	es).</t>	ake succeeds.</t>
	</list></t>	</li>
		<li>
	</section>	<t>Tracking the round-trip time of queries to the server.</t>
	</section>	</li>
	</section>	<li>
	<section anchor="iana-considerations"><name>IANA Considerations</name>	<t>Tracking the number of timeouts (compared to the number of succ
		essful queries).</t>
	<t>This document has no IANA considerations.</t>	</li>
		</ul>
	</section>	</section>
	<section anchor="privacy-considerations"><name>Privacy Considerations</name>	</section>
		</section>
	<section anchor="sni-considerations"><name>Server Name Indication</name>	<section anchor="iana-considerations">
		<name>IANA Considerations</name>
	<t>A recursive resolver querying an authoritative server over DoT or DoQ that se	<t>This document has no IANA actions.</t>
	nds Server Name Indication (SNI) in the clear in the cryptographic handshake lea	</section>
	ks information about the intended query to a passive network observer.</t>	<section anchor="privacy-considerations">
		<name>Privacy Considerations</name>
	<t>In particular, if two different zones refer to the same nameserver IP address	<section anchor="sni-considerations">
	es via differently-named NS records, a passive network observer can distinguish	<name>Server Name Indication</name>
	the queries to one zone from the queries to the other.</t>	<t>A recursive resolver querying an authoritative server over DoT or DoQ
		that sends a Server Name Indication (SNI) in the clear in the cryptographic han
	<t>Omitting SNI entirely, or using Encrypted Client Hello to hide the intended S	dshake leaks information about the intended query to a passive network observer.
	NI, avoids this additional leakage.	</t>
		<t>In particular, if two different zones refer to the same nameserver IP
		addresses via differently named NS records, a passive network observer can dist
		inguish the queries to one zone from the queries to the other.</t>
		<t>Omitting SNI entirely, or using Encrypted ClientHello to hide the int
		ended SNI, avoids this additional leakage.
	However, a series of queries that leak this information is still an improvement over cleartext.</t>	However, a series of queries that leak this information is still an improvement over cleartext.</t>

		</section>
	</section>	<section anchor="modeling-the-probability-of-encryption">
	<section anchor="modelling-the-probability-of-encryption"><name>Modelling the Pr	<name>Modeling the Probability of Encryption</name>
	obability of Encryption</name>	<t>Given that there are many parameter choices that can be made by recur
		sive resolvers and authoritative servers, it is reasonable to consider the proba
	<t>Given that there are many parameter choices that can be made by recursive res	bility that queries would be encrypted.
	olvers and authoritative servers, it is reasonable to consider the probability t	Such a measurement would also certainly be affected by the types of queries bein
	hat queries would be encrypted.	g sent by the recursive resolver, which, in turn, is also related to the types o
	Such a measurement would also certainly be affected by the types of queries bein	f queries that are sent to the recursive resolver by the stub resolvers and forw
	g sent by the recursive resolver, which in turn is also related to the types of	arders downstream.
	queries that are sent to the recursive resolver by the stub resolvers and forwar
	ders downstream.
	Doing this type of research would be valuable to the DNS community after initial implementation by a variety of recursive resolvers and authoritative servers be cause it would help assess the overall DNS privacy value of implementing the pro tocol.	Doing this type of research would be valuable to the DNS community after initial implementation by a variety of recursive resolvers and authoritative servers be cause it would help assess the overall DNS privacy value of implementing the pro tocol.
	Thus, it would be useful if recursive resolvers and authoritative servers report ed percentages of queries sent and received over the different transports.</t>	Thus, it would be useful if recursive resolvers and authoritative servers report ed percentages of queries sent and received over the different transports.</t>

		</section>
	</section>	</section>
	</section>	<section anchor="security-considerations">
	<section anchor="security-considerations"><name>Security Considerations</name>	<name>Security Considerations</name>
		<t>The guidance in this document provides defense against passive network
	<t>The guidance in this document provides defense against passive network monito	monitors for most queries.
	rs for most queries.
	It does not defend against active attackers.	It does not defend against active attackers.

	It can also leak some queries and their responses due to "happy eyeballs" optimi	It can also leak some queries and their responses due to Happy Eyeballs optimiza
	zations when the recursive resolver's cache is cold.</t>	tions (<xref target="RFC8305"/>) when the recursive resolver's cache is cold.</t
		>
	<t>Implementation of the guidance in this document should increase deployment of	<t>Implementation of the guidance in this document should increase deploym
	opportunistic encrypted DNS transport between recursive resolvers and authorita	ent of opportunistic encrypted DNS transport between recursive resolvers and aut
	tive servers at little operational risk.</t>	horitative servers at little operational risk.</t>
		<t>However, implementers cannot rely on the guidance in this document for
	<t>However, implementers cannot rely on the guidance in this document for robust	robust defense against active attackers: they should treat it as a stepping ston
	defense against active attackers, but should treat it as a stepping stone en ro	e en route to stronger defense.</t>
	ute to stronger defense.</t>	<t>In particular, a recursive resolver following the guidance in this docu
		ment can easily be forced by an active attacker to fall back to cleartext DNS qu
	<t>In particular, a recursive resolver following this guidance can easily be for	eries.
	ced by an active attacker to fall back to cleartext DNS queries.
	Or, an active attacker could position itself as a machine-in-the-middle, which t he recursive resolver would not defend against or detect due to lack of server a uthentication.	Or, an active attacker could position itself as a machine-in-the-middle, which t he recursive resolver would not defend against or detect due to lack of server a uthentication.
	Defending against these attacks without risking additional unexpected protocol f ailures would require signaling and coordination that are out of scope for this document.</t>	Defending against these attacks without risking additional unexpected protocol f ailures would require signaling and coordination that are out of scope for this document.</t>

		<t>This guidance is only one part of operating a privacy-preserving DNS ec
	<t>This guidance is only one part of operating a privacy-preserving DNS ecosyste	osystem.
	m.	A privacy-preserving recursive resolver should adopt other practices as well, su
	A privacy-preserving recursive resolver should adopt other practices as well, su	ch as QNAME minimization (<xref target="RFC9156"/>), local root zone (<xref targ
	ch as QNAME minimization (<xref target="RFC9156"/>), local root zone (<xref targ	et="RFC8806"/>), etc., to reduce the overall leakage of query information that c
	et="RFC8806"/>), etc, to reduce the overall leakage of query information that co	ould infringe on the client's privacy.</t>
	uld infringe on the client's privacy.</t>	</section>
		<section anchor="operational-considerations">
	</section>	<name>Operational Considerations</name>
	<section anchor="operational-considerations"><name>Operational Considerations</n	<t>As recursive resolvers implement this protocol, authoritative servers w
	ame>	ill see more probing on port 853 of IP addresses that are associated with NS rec
		ords.
	<t>As recursive resolvers implement this protocol, authoritative servers will se	Such probing of an authoritative server should generally not cause any significa
	e more probing on port 853 of IP addresses that are associated with NS records.	nt problems. If the authoritative server is not supporting this protocol, it wi
	Such probing of an authoritative server should generally not cause any significa	ll not respond on port 853; if it is supporting this protocol, it will act accor
	nt problems: if the authoritative server is not supporting this protocol, it wil	dingly.</t>
	l not respond on port 853, and if it is supporting this protocol, it will act ac	<t>However, a system that is a public recursive resolver that supports DoT
	cordingly.</t>	and/or DoQ may also have an IP address that is associated with NS records.

	<t>However, a system that is a public recursive resolver that supports DoT and/o
	r DoQ may also have an IP address that is associated with NS records.
	This could be accidental (such as a glue record with the wrong target address) o r intentional.	This could be accidental (such as a glue record with the wrong target address) o r intentional.

	In such a case, a recursive resolver following this protocol will look for autho	In such a case, a recursive resolver following this protocol will look for autho
	ritative answers to ports 53 and 853 on that IP address, and DNS server answerin	ritative answers to ports 53 and 853 on that IP address. Additionally, the DNS s
	g on port 853 would need to be able to differentiate queries for recursive answe	erver answering on port 853 would need to be able to differentiate queries for r
	rs from queries for authoritative answers, for example by having the authoritati	ecursive answers from queries for authoritative answers (e.g., by having the aut
	ve server handle all queries that have the Recursion Desired (RD) flag unset.</t	horitative server handle all queries that have the Recursion Desired (RD) flag u
	>	nset).</t>
		<t>As discussed in <xref target="security-considerations"/>, the protocol
	<t>As discussed in <xref target="security-considerations"/>, the protocol descri	described in this document provides no defense against active attackers.
	bed in this document provides no defense against active attackers.	On a network where a captive portal is operating, some communications may be act
	On a network where a captive portal is operating, some communications may be act	ively intercepted (e.g., when the network tries to redirect a user to complete a
	ively intercepted, e.g., when the network tries to redirect a user to complete a	n interaction with a captive portal server).
	n interaction with a captive portal server.
	A recursive resolver operating on a node that performs captive portal detection and Internet connectivity checks <bcp14>SHOULD</bcp14> delay encrypted transport probes to authoritative servers until after the node's Internet connectivity ch eck policy has been satisfied.</t>	A recursive resolver operating on a node that performs captive portal detection and Internet connectivity checks <bcp14>SHOULD</bcp14> delay encrypted transport probes to authoritative servers until after the node's Internet connectivity ch eck policy has been satisfied.</t>

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

	<t>Many people contributed to the development of this document beyond the author
	s, including
	Alexander Mayrhofer,
	Brian Dickson,
	Christian Huitema,
	Dhruv Dhody,
	Eric Nygren,
	Erik Kline,
	Florian Obser,
	Haoyu Song,
	Jim Reid,
	Kris Shrishak,
	Peter Thomassen,
	Peter van Dijk,
	Ralf Weber,
	Rich Salz,
	Robert Evans,
	Sara Dickinson,
	Scott Hollenbeck,
	Stephane Bortzmeyer,
	Yorgos Thessalonikefs,
	and the DPRIVE working group.</t>

	</section>

	</middle>	</middle>


	<back>	<back>


	<references title='Normative References' anchor="sec-normative-references">	<displayreference target="I-D.ietf-dnsop-dns-error-reporting" to="DNS-ER"/>
		<displayreference target="I-D.ietf-tls-esni" to="TLS-ECH"/>
	<reference anchor="RFC2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to signify the
	requirements in the specification. These words are often capitalized. This docu
	ment defines these words as they should be interpreted in IETF documents. This d
	ocument specifies an Internet Best Current Practices for the Internet Community,
	and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>

	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protocol specif
	ications. This document aims to reduce the ambiguity by clarifying that only UPP
	ERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>

	<reference anchor="RFC9250">
	<front>
	<title>DNS over Dedicated QUIC Connections</title>
	<author fullname="C. Huitema" initials="C." surname="Huitema"/>
	<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
	<author fullname="A. Mankin" initials="A." surname="Mankin"/>
	<date month="May" year="2022"/>
	<abstract>
	<t>This document describes the use of QUIC to provide transport confidenti
	ality for DNS. The encryption provided by QUIC has similar properties to those p
	rovided by TLS, while QUIC transport eliminates the head-of-line blocking issues
	inherent with TCP and provides more efficient packet-loss recovery than UDP. DN
	S over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified
	in RFC 7858, and latency characteristics similar to classic DNS over UDP. This
	specification describes the use of DoQ as a general-purpose transport for DNS an
	d includes the use of DoQ for stub to recursive, recursive to authoritative, and
	zone transfer scenarios.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9250"/>
	<seriesInfo name="DOI" value="10.17487/RFC9250"/>
	</reference>

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

	<reference anchor="RFC7301">
	<front>
	<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation
	Extension</title>
	<author fullname="S. Friedl" initials="S." surname="Friedl"/>
	<author fullname="A. Popov" initials="A." surname="Popov"/>
	<author fullname="A. Langley" initials="A." surname="Langley"/>
	<author fullname="E. Stephan" initials="E." surname="Stephan"/>
	<date month="July" year="2014"/>
	<abstract>
	<t>This document describes a Transport Layer Security (TLS) extension for
	application-layer protocol negotiation within the TLS handshake. For instances i
	n which multiple application protocols are supported on the same TCP or UDP port
	, this extension allows the application layer to negotiate which protocol will b
	e used within the TLS connection.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7301"/>
	<seriesInfo name="DOI" value="10.17487/RFC7301"/>
	</reference>

	</references>

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

	<reference anchor="RFC7435">
	<front>
	<title>Opportunistic Security: Some Protection Most of the Time</title>
	<author fullname="V. Dukhovni" initials="V." surname="Dukhovni"/>
	<date month="December" year="2014"/>
	<abstract>
	<t>This document defines the concept "Opportunistic Security" in the conte
	xt of communications protocols. Protocol designs based on Opportunistic Security
	use encryption even when authentication is not available, and use authenticatio
	n when possible, thereby removing barriers to the widespread use of encryption o
	n the Internet.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7435"/>
	<seriesInfo name="DOI" value="10.17487/RFC7435"/>
	</reference>

	<reference anchor="RFC1035">
	<front>
	<title>Domain names - implementation and specification</title>
	<author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
	<date month="November" year="1987"/>
	<abstract>
	<t>This RFC is the revised specification of the protocol and format used i
	n the implementation of the Domain Name System. It obsoletes RFC-883. This memo
	documents the details of the domain name client - server communication.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="13"/>
	<seriesInfo name="RFC" value="1035"/>
	<seriesInfo name="DOI" value="10.17487/RFC1035"/>
	</reference>

	<reference anchor="RFC8484">
	<front>
	<title>DNS Queries over HTTPS (DoH)</title>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<author fullname="P. McManus" initials="P." surname="McManus"/>
	<date month="October" year="2018"/>
	<abstract>
	<t>This document defines a protocol for sending DNS queries and getting DN
	S responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exch
	ange.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8484"/>
	<seriesInfo name="DOI" value="10.17487/RFC8484"/>
	</reference>

	<reference anchor="RFC7830">
	<front>
	<title>The EDNS(0) Padding Option</title>
	<author fullname="A. Mayrhofer" initials="A." surname="Mayrhofer"/>
	<date month="May" year="2016"/>
	<abstract>
	<t>This document specifies the EDNS(0) "Padding" option, which allows DNS
	clients and servers to pad request and response messages by a variable number of
	octets.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7830"/>
	<seriesInfo name="DOI" value="10.17487/RFC7830"/>
	</reference>

	<reference anchor="RFC8467">
	<front>
	<title>Padding Policies for Extension Mechanisms for DNS (EDNS(0))</title>
	<author fullname="A. Mayrhofer" initials="A." surname="Mayrhofer"/>
	<date month="October" year="2018"/>
	<abstract>
	<t>RFC 7830 specifies the "Padding" option for Extension Mechanisms for DN
	S (EDNS(0)) but does not specify the actual padding length for specific applicat
	ions. This memo lists the possible options ("padding policies"), discusses the i
	mplications 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="RFC8305">
	<front>
	<title>Happy Eyeballs Version 2: Better Connectivity Using Concurrency</titl
	e>
	<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
	<author fullname="T. Pauly" initials="T." surname="Pauly"/>
	<date month="December" year="2017"/>
	<abstract>
	<t>Many communication protocols operating over the modern Internet use hos
	tnames. These often resolve to multiple IP addresses, each of which may have dif
	ferent performance and connectivity characteristics. Since specific addresses or
	address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a net
	work, clients that attempt multiple connections in parallel have a chance of est
	ablishing a connection more quickly. This document specifies requirements for al
	gorithms that reduce this user-visible delay and provides an example algorithm,
	referred to as "Happy Eyeballs". This document obsoletes the original algorithm
	description in RFC 6555.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8305"/>
	<seriesInfo name="DOI" value="10.17487/RFC8305"/>
	</reference>

	<reference anchor="I-D.ietf-tls-esni">
	<front>
	<title>TLS Encrypted Client Hello</title>
	<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
	<organization>RTFM, Inc.</organization>
	</author>
	<author fullname="Kazuho Oku" initials="K." surname="Oku">
	<organization>Fastly</organization>
	</author>
	<author fullname="Nick Sullivan" initials="N." surname="Sullivan">
	<organization>Cloudflare</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
	<organization>Cloudflare</organization>
	</author>
	<date day="9" month="October" year="2023"/>
	<abstract>
	<t> This document describes a mechanism in Transport Layer Security (T
	LS)
	for encrypting a ClientHello message under a server public key.

	Discussion Venues

	This note is to be removed before publishing as an RFC.

	Source for this draft and an issue tracker can be found at
	https://github.com/tlswg/draft-ietf-tls-esni
	(https://github.com/tlswg/draft-ietf-tls-esni).

	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-17"/>

	</reference>

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

	<reference anchor="RFC9156">
	<front>
	<title>DNS Query Name Minimisation to Improve Privacy</title>
	<author fullname="S. Bortzmeyer" initials="S." surname="Bortzmeyer"/>
	<author fullname="R. Dolmans" initials="R." surname="Dolmans"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<date month="November" year="2021"/>
	<abstract>
	<t>This document describes a technique called "QNAME minimisation" to impr
	ove DNS privacy, where the DNS resolver no longer always sends the full original
	QNAME and original QTYPE to the upstream name server. This document obsoletes R
	FC 7816.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9156"/>
	<seriesInfo name="DOI" value="10.17487/RFC9156"/>
	</reference>

	<reference anchor="RFC8806">
	<front>
	<title>Running a Root Server Local to a Resolver</title>
	<author fullname="W. Kumari" initials="W." surname="Kumari"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<date month="June" year="2020"/>
	<abstract>
	<t>Some DNS recursive resolvers have longer-than-desired round-trip times
	to the closest DNS root server; those resolvers may have difficulty getting resp
	onses from the root servers, such as during a network attack. Some DNS recursive
	resolver operators want to prevent snooping by third parties of requests sent t
	o DNS root servers. In both cases, resolvers can greatly decrease the round-trip
	time and prevent observation of requests by serving a copy of the full root zon
	e on the same server, such as on a loopback address or in the resolver software.
	This document shows how to start and maintain such a copy of the root zone that
	does not cause problems for other users of the DNS, at the cost of adding some
	operational fragility for the operator.</t>
	<t>This document obsoletes RFC 7706.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8806"/>
	<seriesInfo name="DOI" value="10.17487/RFC8806"/>
	</reference>

	<reference anchor="MTA-STS">
	<front>
	<title>SMTP MTA Strict Transport Security (MTA-STS)</title>
	<author fullname="D. Margolis" initials="D." surname="Margolis"/>
	<author fullname="M. Risher" initials="M." surname="Risher"/>
	<author fullname="B. Ramakrishnan" initials="B." surname="Ramakrishnan"/>
	<author fullname="A. Brotman" initials="A." surname="Brotman"/>
	<author fullname="J. Jones" initials="J." surname="Jones"/>
	<date month="September" year="2018"/>
	<abstract>
	<t>SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling ma
	il service providers (SPs) to declare their ability to receive Transport Layer S
	ecurity (TLS) secure SMTP connections and to specify whether sending SMTP server
	s should refuse to deliver to MX hosts that do not offer TLS with a trusted serv
	er certificate.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8461"/>
	<seriesInfo name="DOI" value="10.17487/RFC8461"/>
	</reference>

	<reference anchor="DANE-SMTP">
	<front>
	<title>SMTP Security via Opportunistic DNS-Based Authentication of Named Ent
	ities (DANE) Transport Layer Security (TLS)</title>
	<author fullname="V. Dukhovni" initials="V." surname="Dukhovni"/>
	<author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
	<date month="October" year="2015"/>
	<abstract>
	<t>This memo describes a downgrade-resistant protocol for SMTP transport s
	ecurity between Message Transfer Agents (MTAs), based on the DNS-Based Authentic
	ation of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enable
	s an incremental transition of the Internet email backbone to one using encrypte
	d and authenticated Transport Layer Security (TLS).</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7672"/>
	<seriesInfo name="DOI" value="10.17487/RFC7672"/>
	</reference>

	<reference anchor="TLSRPT">
	<front>
	<title>SMTP TLS Reporting</title>
	<author fullname="D. Margolis" initials="D." surname="Margolis"/>
	<author fullname="A. Brotman" initials="A." surname="Brotman"/>
	<author fullname="B. Ramakrishnan" initials="B." surname="Ramakrishnan"/>
	<author fullname="J. Jones" initials="J." surname="Jones"/>
	<author fullname="M. Risher" initials="M." surname="Risher"/>
	<date month="September" year="2018"/>
	<abstract>
	<t>A number of protocols exist for establishing encrypted channels between
	SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication
	of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). The
	se protocols can fail due to misconfiguration or active attack, leading to undel
	ivered messages or delivery over unencrypted or unauthenticated channels. This d
	ocument describes a reporting mechanism and format by which sending systems can
	share statistics and specific information about potential failures with recipien
	t domains. Recipient domains can then use this information to both detect potent
	ial attacks and diagnose unintentional misconfigurations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8460"/>
	<seriesInfo name="DOI" value="10.17487/RFC8460"/>
	</reference>

	<reference anchor="DNS-Error-Reporting">
	<front>
	<title>DNS Error Reporting</title>
	<author fullname="Roy Arends" initials="R." surname="Arends">
	<organization>ICANN</organization>
	</author>
	<author fullname="Matt Larson" initials="M." surname="Larson">
	<organization>ICANN</organization>
	</author>
	<date day="11" month="October" year="2023"/>
	<abstract>
	<t> DNS error reporting is a lightweight reporting mechanism that
	provides the operator of an authoritative server with reports on DNS
	resource records that fail to resolve or validate. A domain owner or
	DNS hosting organization can use these reports to improve domain
	hosting. The reports are based on extended DNS errors as described
	in RFC 8914.


	When a domain name fails to resolve or validate due to a	<references>
	misconfiguration or an attack, the operator of the authoritative	<name>References</name>
	server may be unaware of this. To mitigate this lack of feedback,	<references anchor="sec-normative-references">
	this document describes a method for a validating recursive resolver	<name>Normative References</name>
	to automatically signal an error to a monitoring agent specified by	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	the authoritative server.	119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		301.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		858.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		250.xml"/>


	</t>	</references>
	</abstract>	<references anchor="sec-informative-references">
	</front>	<name>Informative References</name>
	<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-dns-error-reporting	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
	-06"/>	035.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		435.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		672.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		766.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		830.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		305.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		460.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		461.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		467.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		484.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		806.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		102.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		156.xml"/>


	</reference>	<!-- [I-D.ietf-tls-esni] IESG state I-D Exists -->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
		etf-tls-esni.xml"/>


	<reference anchor="RFC9102">	<!-- [I-D.ietf-dnsop-dns-error-reporting] IESG state Waiting for AD Go-Ahead -->
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	<title>TLS DNSSEC Chain Extension</title>	ietf-dnsop-dns-error-reporting.xml"/>
	<author fullname="V. Dukhovni" initials="V." surname="Dukhovni"/>
	<author fullname="S. Huque" initials="S." surname="Huque"/>
	<author fullname="W. Toorop" initials="W." surname="Toorop"/>
	<author fullname="P. Wouters" initials="P." surname="Wouters"/>
	<author fullname="M. Shore" initials="M." surname="Shore"/>
	<date month="August" year="2021"/>
	<abstract>
	<t>This document describes an experimental TLS extension for the in-band t
	ransport of the complete set of records that can be validated by DNSSEC and that
	are needed to perform DNS-Based Authentication of Named Entities (DANE) of a TL
	S server. This extension obviates the need to perform separate, out-of-band DNS
	lookups. When the requisite DNS records do not exist, the extension conveys a de
	nial-of-existence proof that can be validated.</t>
	<t>This experimental extension is developed outside the IETF and is publis
	hed here to guide implementation of the extension and to ensure interoperability
	among implementations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9102"/>
	<seriesInfo name="DOI" value="10.17487/RFC9102"/>
	</reference>


		</references>
	</references>	</references>


	<?line 671?>	<section anchor="assessing-the-experiment">
		<name>Assessing the Experiment</name>
	<section anchor="early-implementations"><name>Early Implementations</name>	<t>This document is an Experimental RFC.

	<t>[ RFC Editor: please remove this section before publication ]</t>

	<t>This appendix lists some of the implementations of the protocol as it finishe
	d working group last call in the DPRIVE Working Group.
	This list reflects reporting from the DNS community.</t>

	<t><list style="symbols">
	<t>The Unbound resolver has initial experimental code paths to probe over DoT<
	/t>
	<t>The Drink authoritative server supports DoT</t>
	<t>The check-soa tool can probe over DoT</t>
	<t>The Bleau tool can probe over DoT through RIPE Atlas probes</t>
	<t>The PowerDNS Recursor resolver can probe over DoT</t>
	<t>Nameservers for various DNS zones support DoT. These include the root zone
	(one of the 13 root server identifiers), a social media site, some DNS software
	developers, and others</t>
	</list></t>

	</section>
	<section anchor="assessing-the-experiment"><name>Assessing the Experiment</name>

	<t>This document is published as an experimental RFC.
	In order to assess the success of the experiment, some key metrics could be coll ected by the technical community about the deployment of the protocol in this do cument.	In order to assess the success of the experiment, some key metrics could be coll ected by the technical community about the deployment of the protocol in this do cument.
	These metrics will be collected in recursive resolvers, authoritative servers, a nd the networks containing them.	These metrics will be collected in recursive resolvers, authoritative servers, a nd the networks containing them.

	Some key metrics include:</t>	Some key metrics include the following.</t>
		<ul spacing="normal">
	<t><list style="symbols">	<li>
	<t>Comparison of the CPU and memory use between Do53 and encrypted transports<	<t>Comparison of the CPU and memory use between Do53 and encrypted tra
	/t>	nsports.</t>
	<t>Comparison of the query response rates between Do53 and encrypted transport	</li>
	s</t>	<li>
	<t>Measurement of server authentication successes and failures</t>	<t>Comparison of the query response rates between Do53 and encrypted t
	<t>Measurement and descriptions of observed attack traffic, if any</t>	ransports.</t>
	<t>Comparison of transactional bandwidth (ingress/egress, packets per second,	</li>
	bytes per second) between Do53 and encrypted transports</t>	<li>
	</list></t>	<t>Measurement of server authentication successes and failures.</t>
		</li>
	</section>	<li>
	<section anchor="adding-auth"><name>Defense Against Active Attackers</name>	<t>Measurement and descriptions of observed attack traffic, if any.</t
		>
	<t>The protocol described in this document provides no defense against active at	</li>
	tackers.	<li>
		<t>Comparison of transactional bandwidth (ingress/egress, packets per
		second, bytes per second) between Do53 and encrypted transports.</t>
		</li>
		</ul>
		</section>
		<section anchor="adding-auth">
		<name>Defense against Active Attackers</name>
		<t>The protocol described in this document provides no defense against act
		ive attackers.
	A future protocol for recursive-to-authoritative DNS might want to provide such protection.</t>	A future protocol for recursive-to-authoritative DNS might want to provide such protection.</t>

		<t>This appendix assumes that the use case for that future protocol is a r
	<t>This appendix assumes that the use case for that future protocol is a recursi	ecursive resolver that wants to prevent an active attack on communication betwee
	ve resolver that wants to prevent an active attack on communication between it a	n it and an authoritative server that has committed to offering encrypted DNS tr
	nd an authoritative server that has committed to offering encrypted DNS transpor	ansport.
	t.	An inherent part of this use case is that the recursive resolver would want to r
	An inherent part of this use case is that the recursive resolver would want to r	espond with a <tt>SERVFAIL</tt> response to its client if it cannot make an auth
	espond with a <spanx style="verb">SERVFAIL</spanx> response to its client if it	enticated encrypted connection to any of the authoritative nameservers for a nam
	cannot make an authenticated encrypted connection to any of the authoritative na	e.</t>
	meservers for a name.</t>	<t>However, an authoritative server that merely offers encrypted transport
		(for example, by following the guidance in <xref target="authoritative-guidance
	<t>However, an authoritative server that merely offers encrypted transport (for	"/>) has made no such commitment, and no recursive resolver that prioritizes del
	example, by following the guidance in <xref target="authoritative-guidance"/>) h	ivery of DNS records to its clients would want to "fail closed" unilaterally.</t
	as made no such commitment, and no recursive resolver that prioritizes delivery	>
	of DNS records to its clients would want to "fail closed" unilaterally.</t>	<t>Therefore, such a future protocol would need at least three major disti
		nctions from the protocol described in this document:</t>
	<t>So such a future protocol would need at least three major distinctions from t	<ul spacing="normal">
	he protocol described in this document:</t>	<li>
		<t>A signaling mechanism that tells the recursive resolver that the au
	<t><list style="symbols">	thoritative server intends to offer authenticated encryption.</t>
	<t>A signaling mechanism that tells the recursive resolver that the authoritat	</li>
	ive server intends to offer authenticated encryption</t>	<li>
	<t>Authentication of the authoritative server</t>	<t>Authentication of the authoritative server.</t>
	<t>A way to combine defense against an active attacker with the defenses descr	</li>
	ibed in this document</t>	<li>
	</list></t>	<t>A way to combine defense against an active attacker with the defens
		es described in this document.</t>
	<t>This can be thought of as a DNS analog to <xref target="MTA-STS"/> or <xref t	</li>
	arget="DANE-SMTP"/>.</t>	</ul>
		<t>This can be thought of as a DNS analog to <xref target="RFC8461"/> or <
	<section anchor="signaling-mechanism-properties"><name>Signaling Mechanism Prope	xref target="RFC7672"/>.</t>
	rties</name>	<section anchor="signaling-mechanism-properties">
		<name>Signaling Mechanism Properties</name>
	<t>To defend against an active attacker, the signaling mechanism needs to be abl	<t>To defend against an active attacker, the signaling mechanism needs t
	e to indicate that the recursive resolver should "fail closed" if it cannot auth	o be able to indicate that the recursive resolver should fail closed if it canno
	enticate the server for a particular query.</t>	t authenticate the server for a particular query.</t>
		<t>The signaling mechanism itself would have to be resistant to downgrad
	<t>The signaling mechanism itself would have to be resistant to downgrade attack	e attacks from active attackers.</t>
	s from active attackers.</t>	<t>One open question is how such a signal should be scoped.
		While this document scopes opportunistic state about encrypted transport based o
	<t>One open question is how such a signal should be scoped.	n the IP addresses of the client and server, signaled intent to offer encrypted
	While this document scopes opportunistic state about encrypted transport based o	transport is more likely to be scoped by the queried zone in the DNS or by the n
	n the IP addresses of the client and server, signaled intent to offer encrypted	ameserver name than by the IP address.</t>
	transport is more likely to be scoped by queried zone in the DNS, or by nameserv	<t>A reasonable authoritative server operator or zone administrator prob
	er name than by IP address.</t>	ably doesn't want to risk breaking anything when they first enable the signal.

	<t>A reasonable authoritative server operator or zone administrator probably doe
	sn't want to risk breaking anything when they first enable the signal.
	Therefore, a signaling mechanism should probably also offer a means to report pr oblems to the authoritative server operator without the client failing closed.	Therefore, a signaling mechanism should probably also offer a means to report pr oblems to the authoritative server operator without the client failing closed.

	Such a mechanism is likely to be similar to <xref target="TLSRPT"/> or <xref tar	Such a mechanism is likely to be similar to those described in <xref target="RFC
	get="DNS-Error-Reporting"/>.</t>	8460"/> or <xref target="I-D.ietf-dnsop-dns-error-reporting"/>.</t>
		</section>
	</section>	<section anchor="authentication-of-authoritative-server">
	<section anchor="authentication-of-authoritative-server"><name>Authentication of	<name>Authentication of Authoritative Servers</name>
	Authoritative Server</name>	<t>Forms of server authentication might include:</t>
		<ul spacing="normal">
	<t>Forms of server authentication might include:</t>	<li>
		<t>An X.509 certificate issued by a widely known certification autho
	<t><list style="symbols">	rity associated with the common NS names used for this authoritative server.</t>
	<t>an X.509 Certificate issued by a widely-known certification authority assoc	</li>
	iated with the common NS names used for this authoritative server</t>	<li>
	<t>DANE authentication (to avoid infinite recursion, the DNS records necessary	<t>DNS-Based Authentication of Named Entities (DANE) (to avoid infin
	to authenticate could be transmitted in the TLS handshake using the DNSSEC Chai	ite recursion, the DNS records necessary to authenticate could be transmitted in
	n Extension (see <xref target="RFC9102"/>))</t>	the TLS handshake using the DNSSEC chain extension (see <xref target="RFC9102"/
	</list></t>	>)).</t>
		</li>
	<t>A recursive resolver would have to verify the server's identity.	</ul>
		<t>A recursive resolver would have to verify the server's identity.
	When doing so, the identity would presumably be based on the NS name used for a given query or the IP address of the server.</t>	When doing so, the identity would presumably be based on the NS name used for a given query or the IP address of the server.</t>

		</section>
	</section>	<section anchor="combining-protocols">
	<section anchor="combining-protocols"><name>Combining Protocols</name>	<name>Combining Protocols</name>
		<t>If this protocol gains reasonable adoption, and a newer protocol that
	<t>If this protocol gains reasonable adoption, and a newer protocol that can off	can offer defense against an active attacker were available, deployment is like
	er defense against an active attacker were available, deployment is likely to be	ly to be staggered and incomplete.
	staggered and incomplete.	This means that an operator that wants to maximize confidentiality for their use
	This means that an operator that want to maximize confidentiality for their user	rs will want to use both protocols together.</t>
	s will want to use both protocols together.</t>	<t>Any new stronger protocol should consider how it interacts with the o
		pportunistic protocol defined here, so that operators are not faced with the cho
	<t>Any new stronger protocol should consider how it interacts with the opportuni	ice between widespread opportunistic protection against passive attackers (this
	stic protocol defined here, so that operators are not faced with the choice betw	document) and more narrowly targeted protection against active attackers.</t>
	een widespread opportunistic protection against passive attackers (this document	</section>
	) and more narrowly-targeted protection against active attackers.</t>	</section>
		<section anchor="acknowledgements" numbered="false">
	</section>	<name>Acknowledgements</name>
	</section>	<t>Many people contributed to the development of this document beyond the
	<section anchor="document-considerations"><name>Document Considerations</name>	authors, including
		<contact fullname="Alexander Mayrhofer"/>,
	<t>[ RFC Editor: please remove this section before publication ]</t>	<contact fullname="Brian Dickson"/>,
		<contact fullname="Christian Huitema"/>,
	<section anchor="document-history"><name>Document History</name>	<contact fullname="Dhruv Dhody"/>,
		<contact fullname="Eric Nygren"/>,
	<section anchor="substantive-changes-from-12-to-13"><name>Substantive Changes fr	<contact fullname="Erik Kline"/>,
	om -12 to -13</name>	<contact fullname="Florian Obser"/>,
		<contact fullname="Haoyu Song"/>,
	<t><list style="symbols">	<contact fullname="Jim Reid"/>,
	<t>Changes based on IESG review</t>	<contact fullname="Kris Shrishak"/>,
	</list></t>	<contact fullname="Peter Thomassen"/>,
		<contact fullname="Peter van Dijk"/>,
	</section>	<contact fullname="Ralf Weber"/>,
	<section anchor="substantive-changes-from-11-to-12"><name>Substantive Changes fr	<contact fullname="Rich Salz"/>,
	om -11 to -12</name>	<contact fullname="Robert Evans"/>,
		<contact fullname="Sara Dickinson"/>,
	<t><list style="symbols">	<contact fullname="Scott Hollenbeck"/>,
	<t>Editorial changes received during IETF Last Call</t>	<contact fullname="Stephane Bortzmeyer"/>,
	</list></t>	<contact fullname="Yorgos Thessalonikefs"/>,
		and the DPRIVE Working Group.</t>
	</section>	</section>
	<section anchor="substantive-changes-from-10-to-11"><name>Substantive Changes fr
	om -10 to -11</name>

	<t><list style="symbols">
	<t>Editorial changes to prepare for IETF Last Call</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-09-to-10"><name>Substantive Changes fr
	om -09 to -10</name>

	<t><list style="symbols">
	<t>Responded to AD review from Eric Vyncke</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-08-to-09"><name>Substantive Changes fr
	om -08 to -09</name>

	<t><list style="symbols">
	<t>Added section with metrics for assessing the experiment</t>
	<t>Updated the definition of unsuccessful responses to encrypted queries</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-07-to-08"><name>Substantive Changes fr
	om -07 to -08</name>

	<t><list style="symbols">
	<t>Changed status to Experimental</t>
	<t>Added operational considerations section</t>
	<t>Many many editorial updates</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-06-to-07"><name>Substantive Changes fr
	om -06 to -07</name>

	<t><list style="symbols">
	<t>Updated how to handle responses from encrypted transports that are slower t
	hat Do53</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-05-to-06"><name>Substantive Changes fr
	om -05 to -06</name>

	<t><list style="symbols">
	<t>Clarified the optinality of the protocol</t>
	<t>Spelled out the current scope of DoT and DoQ</t>
	<t>Clarified that responses must be the same on all transports</t>
	<t>Loosened requirement for the resolver to know all its addresses</t>
	<t>Changed examples of unsuccessful responses to timeouts and connection faile
	d</t>
	<t>Expanded acknowledgements</t>
	<t>Added preliminary implementation status</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-03-to-04"><name>Substantive Changes fr
	om -03 to -04</name>

	<t><list style="symbols">
	<t>Clarified that "completed handshake" in Table 2 also includes resumed sessi
	ons.</t>
	<t>In Section 4.6.1, specified not to use Do53 even when the last successful c
	onnection is far in the past.</t>
	<t>In Section 4.6.3, clarified that an established connection in the establish
	ed state should not be resumed prematurely.</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-02-to-03"><name>Substantive Changes fr
	om -02 to -03</name>

	<t><list style="symbols">
	<t>Added an Additional Tuning section on recursive resolvers recording other d
	ata about an authoritative server's capabilities for future interactions (thank
	you again Sara Dickinson!).
	Feedback from operators on how the extra information would be used by a recursiv
	e resolver that retains such an expanded state table is particularly welcome.</t
	>
	<t>Added more text about sharing session state information.</t>
	<t>Added section on modelling the probability of encryption as a future task.<
	/t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-01-to-02"><name>Substantive Changes fr
	om -01 to -02</name>

	<t><list style="symbols">
	<t>Removed EDNS Client Subnet recommendations from the probing policy: recursi
	ve resolvers implementing the guidance provided in this draft intend to enhance
	privacy for their users' queries, and although ECS is a valuable feature, it rep
	resents a privacy risk. Therefore, a future document encompassing a "how to add
	privacy" approach could serve for better discussion on this discrepancy (thank y
	ou Puneet Sood!).</t>
	<t>Added text on padding queries and responses to mitigate traffic analysis (t
	hank you Sara Dickinson!).</t>
	<t>Put draft on standards track</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-00-to-01"><name>Substantive Changes fr
	om -00 to -01</name>

	<t><list style="symbols">
	<t>Moved discussion of non-opportunistic encryption to an appendix</t>
	<t>Clarify state transitions when sending over encrypted transport</t>
	<t>Introduced new field <spanx style="verb">E-last-response[X]</spanx> for com
	parison with persistence</t>
	</list></t>

	</section>
	<section anchor="substantive-changes-from-01-to-02-now-draft-ietf-dprive-unilate
	ral-probing-00"><name>Substantive Changes from -01 to -02 (now draft-ietf-dprive
	-unilateral-probing-00)</name>

	<t><list style="symbols">
	<t>Clarify that deployment to a pool does not need to be strictly simultaneous
	</t>
	<t>Explain why authoritatives need to serve the same records regardless of SNI
	</t>
	<t>Defer to external, protocol-specific references for resource management</t>
	<t>Clarify that probed connections must not fail due to authentication failure
	</t>
	</list></t>

	</section>
	<section anchor="draft-dkgjsal-dprive-unilateral-probing-substantive-changes-fro
	m-00-to-01"><name>draft-dkgjsal-dprive-unilateral-probing Substantive Changes fr
	om -00 to -01</name>

	<t><list style="symbols">
	<t>Fallback to cleartext when encrypted transport fails.</t>
	<t>Reduce default <spanx style="verb">timeout</spanx> to 4s</t>
	<t>Clarify SNI guidance: OK for selecting server credentials, not OK for chang
	ing answers</t>
	<t>Document ALPN and port numbers</t>
	<t>Justify sorting recursive resolver state by authoritative IP address</t>
	</list></t>

	</section>
	</section>
	</section>

	</back>	</back>


	<!-- ##markdown-source:
	H4sIAAAAAAAAA+196XLjVrLmfz4FrvzD0gRJS7XYZd3eZEnlUrsWVUlut6On
	YwQRhyRcIMAGQLHo6nqXeZZ5sskvM88CEKBU7ntjbkzc/uFWgcBZ8+Ty5XJG
	o9GgTuvMHEc/5mkW16aMs+jNclmU9SpPqzqdRGdmmRWbhcnrqJhG5/mk3Cxr
	k0TvzGRVVumdGdXF6GRVz4syreOaHkRnr68G8e1tae4a7fpvt19PikkeL2gc
	SRlP61Fq6ukoWZZofuVaGC3L4jbNZ6Ojx4MJPZoV5eY4Mh+Wg0G6LI+julxV
	9aPDw28PHw3i0sTHUZrXg3VRvp+VxWpJjXOLg/dmQw+T4+gip3ZzU4/O0Oug
	Wt0u0qpKi/x6s6SxXJxfPx/cmXxljgdRpG3snV2+u/jL+R49qfmtvZ+oAxpV
	9D1ewPNFnGb0PMmrETqMJ5s/YULjopzh57iczOnneV0vq+OvvsLbeEQjG9vX
	vsKDr27LYl2Zr4J2vsL3pVkWwfcz2sD4djwpFl8l72df9a4aPsWjqg4+pi/G
	2kBa9H9L/Q6qOs6T/xVnRU6T3phqMIh5G7E2o4j+E9FyV8fR2Tj6YRx9n2bZ
	oij5sezsWZynJot+iOd541ea7nF0sjBlOonz6DS9S7PoZXpryjo1FeinyPm9
	qi6NobEfPXoafVcWcRJd1WP+ZZLWRAevzTr6mbZiGL3+WR4XCXV7dHh4+ET/
	vcprUMyPVyf8wNLoyenLH/mBkZ2jRfnTNJ3Wc5pdRc/yMdEIv1AWOCsmSWse
	/MjP+s/j6CrO4l/jcMp/Lsym8VhGepLFv6xMFgejfHT46PCoOcrTd+GYfqGm
	ZlWc/WmGf2O37xnQ5Th6UUynNPpgQJfxKms85sW/OD15/bp7ibT3JX03nst3
	f8I+5aDS7RGk+bQoF3ysjwe5/3M0GtFq0w7Gk3owuJ6nVUQnfsVcpTJ1FRUr
	+qM2yyqq53ENlkDPyztTVtF+aTkNUX5VZPyQSDGKG1xEXz+IQEV1/N5Enoyz
	TbS/Tult6iXONzRNOv5pTh8WeYQfoqKemzJaGm6hLqLETA11gXH8Y2XKTaQH
	MIpnMS0vNUNrUvGgiDbAYqJFkWMNxjQ9o3NJaSSNuWJst4Zbj8EIb6nBPKJF
	QUNxXceT96YcRrdYDRptluDtKl0sMxod5pyZqorKtHq/kVGCN2PJcuq+NNGy
	WJtySnvM469MNR7wcGYF8V9i383R0N/UCDefTjfcfkVLkGi7lucXDXlgHBen
	3cwr/CTzxPYEIqG5O/NiKf0zu4/MpKg2tEaL8eCnNKG5mbjatLrFu6ucfsw2
	4K5d/dLu0cyb47uNK5rXIt5E03iSZhiA4bamq3pFS0QznKRTomHefOqHqLLI
	ZzQGbr+YlfFyTu0Q56vNBC9VbtObayz7hSUGeS/SJMnMYPAFpEpZJCv+tk3s
	cbrgRafW72ji0WyVJnE+MXiGheGtxpuWyIslETCRVRWt50W0jqkNu2cbWpP4
	NjPBUN1I28RZ3Or5oNFe5PQzcdfJiuTOMErraErDI2LBei7MhKgprRZ6EpVi
	46TgtW+cKaLezzqbwyg8hCS3s5QYYsdpxHbpiYxZDIxlGd1q6fJVrb2vMBpi
	sdF+ZUz08eMf3z0//ebJ46efPh1EtEVKQqAmOgj5TKe45oPG/a3TymC6StCT
	zGCF7KhTbMuUBBU1IFyjjNaGWE2OJ46OwAIrpiwdjh5CTwRZVUS3ZWqmtIip
	UgtNZh/nPinor7ygbS75jAu9bg7oCK2J6ygVY8uLSZER2c3mtN2mXNBK6qn3
	TGqLt2BmHz/GSQI1Cpv06ZOOzrVIyzopSf4mES0I7cN0ik2t5yR9aatoCU0N
	ergjUoxnhql561gf05mILj1ZTsti4WjSjoXXyHJYyHqsOs42zeSW6NaYPKCv
	XqoaU1cnERSCRbzE4keYPXaEVMBsRORPu0vEhj5AO7Tj1SSmY8Nb6NlKeOAt
	q6ThTIlXSBe0Y8mMT2pVLMAHaDo4fsGWtE5h3MkxDMmIwRdfkAb9j1Va8mmv
	opdxPlvRespmkIYaQUWtor1XP15d7w3l/6PXb/jvd+dvf7x4d36Gv69enLx8
	6f4Y6BtXL978+PLM/+W/PH3z6tX56zP5mJ5GjUeDvVcnP9MvWO29N5fXF29e
	n7zc2xZkpF5jIfio0KFYgihof6qBpx765rvTy//zv4+eEMX9G53ER0dH3376
	pP94dvTNE/rHem5y6a3I6TDIP4mcNoN4uaTDh1aI1xAbWtK2Z8RC4gqicZ0z
	ddJC/o+/YWX+fhz97nayPHryB32ACTce2jVrPOQ1236y9bEsYsejjm7cajae
	t1a6Od6Tnxv/tusePPzdH7M0N9Ho6Nkf/zBg6rnGkc+LrJhtBgNvZR0PjrFY
	LBe2ZLdq846hmQ+wf0g12GbB4NAqhBuceDA4K54+Ri90Nkjpow/wPRhlTc3x
	eS7u8D4E9NPH0b6w4aNDZsP4/C2+pvdGeG9Eu3KKl0AU3z56eqgvXTdeun55
	Zd/55tnTZ/zO+bZCUPFHxVsmKGqD5pVlhjlgtoFovixT8A+eR7dgJjaazqAy
	LOk053VKkyNZS1y0ssvhKdyxTHRH38Zp4gU4RDYRb2V4ALTolqU5voGlck1M
	5kU6YX2N9vYV8a9F+iu+em1mwu0uZBS9zHr7iLoZcWPBjOig5bZZO7lJTBoA
	K6S1tM+EQlPu0Lsq5rJ4T7i9ylHWEfC4Er3GgGTpxNqXlYLkZZxx2p7FgmgT
	tjxTnXACvE9P8zvoEwlmVSahImC2R69N0vTdyjg9D9OtWb6Ei0EMjIWU+UCr
	zgLmlvpepwnRPq1E8yd6gKWg4S5Xdaw0D4VnVbLcPr38kUe+MMTvIdIDBesA
	TfH0HUFhgjEr3VYNVVWSrBSWuaAM1qdW/CtZVWVM6gWplBA0NMs1WdIJM1zu
	CYOLieCvtKEDpqJLuxSnQluDwUmGcz+btyjFqn+NJaN+Ya/VZoals8QRGGas
	OTptZVZAEsAkqclixNdMH9qi2xbbkmF6o3eKylMzmgyXjo+wHOW3QxY5DXIX
	vmRnoaSBT5oqfpNvRFW8UXpJa6KAPwS6r+hrrMqtbmHDeO1DFQEWP6RJiHY4
	B88rnV3DuFDUQIPGUXQRLBKJyTtecNEYSMRlOkrHXRz90lrusKecYjK4QHMl
	LwWmhinRI1ELWfUnLUO09S2VapKlrHvsUK10Td92r6nya9fxcz3pwboV7ZYn
	ZLQQFx7ycxwIbbIMtSHs9SrXPkHnzDCiOl3wQVyDh9Ma88BLMe+q1e0vxGlZ
	6OWzgsUcpq+qvN2d7/vV3S0OavuvxBYVJhDQpDdnmlPRrZRFHLcljacGWqOV
	abRt5d2L6+vLqyHzR9aLcCQN+nxh5emzJ89IfzoYulGTas4C2B6tmN+WLSaG
	aRLmf+9zsiKEGROjC3nHC+L0yZLWrY5+fPdSOHHN3AgrTPtZUkOQHEVoIzIr
	U37VtgTFzjVJOql9l2BnkKXrnIe+Zb4L77eQ8TSu5rSioQmGkcjebzNox5LH
	gwsyv1aTeThWzIMbhp1EoikZNk9cH1qzWiYM1oCWJ7wliWIKC4jr6HtrlWIx
	mtD2lWJYH79onIKRNWQ/PZwY6W+rF8qqdx/Yk7zzF+gXRcWWb+F1lOb8d3TO
	GrX/jI4jKXwVABgz0DNRlHwkilw0v2dPH9Pi/CeN5uRnyy4cD6OGQAQnLy9f
	R/snnrGOXsYb6tDJQtKnChLCNVOV2iLfPD48orMkAoRbIMmn+IDtgSiQzBA+
	WNTrjOaSiy3tmXTIwdis7pu9mzFWIFg7XuVlsVxlFrMigl4WsOjZgGamEhML
	bLb6K+1CRCQZQzgJaiZKmxEA0+tt406lOZrHd9xdWuJcslwjrYrsZT6RbgwV
	9CaWnCJdAGSmQAdYpNkB2s7rrd6HZDc3WxPRU5qMzxdpjywJ9814Nh5G5/T1
	4YFohFk8c8+vT6PbtD7QQdzFpHDdxlAqVOdwHY6BdImSwLa0HHfmkx5htONh
	CopD5UNwX96TW+PXviTds0wYh9Um4Abiv33HrH4VRbbl67IM4TszTyG8opdw
	ZHwXZ+AG5RafWFIbFTGJq2Jr10OIHCTp9EPWCmkm9Cnz9vAr0vHgxRFzREeQ
	0QhGt3YEvL/lKmeFKI5wSMlUubgk7T6htRJ1fh2X3IYFbqBYm8WtQjqi7BYZ
	rz8z4TiAdsH2k/QuTUgr6foKy6kq6MzUjvnSR2ZJEkqEEFObiScK3OOsdQmg
	KZl/xVrwvgBrbZ1bx4w/MbExoBGLzcamsE6BB5el78mU9DJc5Slrk2DRsZ35
	VECirgnKqJrczqs6W9xuPU8zNcLxFN0OW1qWsig5EYA+XV9MCrqJnbyIx46h
	QreqLNrHrgD3sDRTVpE7TEFoN3Ru7gqYvl42Jw4ZAEZRsuJG4lv0BV3P7f0a
	+nFb2DsSmEVMtbxalcqBgAl1ra0i4u60dgx5vzrgfU2tiRLnogNNzRomQJGT
	qrQvg6zsm48P7U+kchVlazRoB8cocsdoES8ruy2QC6YSGcWDtAN3bEtf9KcM
	ZjP3IppcxxHVU1jZM/gVDS538GXebbbTAFidFLOra/1Az7nltHdpbL1atKvs
	F6tWrK3JeWIh2E0UV2Rlg4kCMDYlXChLOCy2zQHlYMKGmanw2QZynW8m0DH8
	qpB2U9FagMCqgFSmrpWUIZc4mhs6wsXM5ER0zPJqM2REiwTJcsnQMFGjbl5F
	WzyZQxbpjLZ2Q0SDl3U6WNoKeOKqplIa0L5S/XjwnEkAGiXpojM+ZjwCni50
	OZ1qRhJXnAkhKTB7Z5+Bch8ajuj4gGkyo2r49csrCMdLUE7EqJonCVkDpmeT
	ZSyI6QlOCi+EdEFqCW2eepja5I0lTic4qwtg23TkEbaAFkSEsxRFCIO4P+2G
	5JZxQpeu5iyoDIdYRM5XDLkN9GBSkk4pZ5cnmpKSmPD2riZQ9IGgU0erhegJ
	ImVPGqbXYPC8aUCEcifuUcccM4eVxGcEG830EqgDGKyVp75DGsSb3LpoQwcm
	0VlZQECJd+mXVcUKU+D6i4ENTkdpRUYgmSKkV6CfbDOyIu+v46eH30YTBEKw
	4U1r+xNR9tzCD/4HRVV4dWl+9ShLgZzRUuC06L/ocKyW1lvjR6quNWcn4T09
	5QL5LLAQAGCx0UJXonOLjch6MTyEtEdLoSkl6ZZl56kxpBGEHGRJsCgcNZBF
	lz9cjIQ/BvMUz7hYpSn2zPuh2B3OVj/RtgUDcQCFTETvil5DJlwQn1FLva1v
	VXn6qUNv97qWegxjNTloyUgVDAnOqkRiowiO1tP5/tXrC2GqjBHTEWc0vvZL
	Q8qcQIZE7C+KtWEZqeJT37G+Dvm3s4AhXdl/xOMV1uXlDXUc7dMmqcacxZP3
	IG0ej+6Eg4Jls4cBrmDB4S6LH72pDoFORCOhnuQPHDI2NphcWYdRlYXnghgV
	rAf0PlVweA6iWmVF8V4ZpvWf6VzPP8xpaJ0batdjZNw72GBmgyNSgWOcjI6J
	IH7gvTFLhhmchAsYKikozLZ6mMqQf1sQ+YvRBLujEh9CyJVNvRKX5W2hcAxj
	3MFmbyv+lrdiiLyYxI5XAANV2bCotOfQwH0wl4XEvgR6AiYBEW3RHVHn+GXf
	EAdhsN1UFtmwZzQarsJMT/wt6I4PJhuWXYtIM/348UrX4un4KVbHw4rR/t6p
	X6oXOGmIYjuw9EU0BIkwC9EXvzbUtVjXb/s6fDx+YjsUbPgzG75uNtxr7SMM
	hT5YQdyZShBYJVxPlKrnsiONAb8MGprdH7dhrBt1xVw0LODGML6ET8TQxEr2
	WIn/61crvC400CEWAG2VxxBt6ZIFUMc4hzqycFAr+iR0h0AM3YKlpLmlmjHb
	Z3FV2ICVcBhRReoXkfnaBjxBv9nqhU0x4vgwI6wNq8wWGg+RqPCsFAyZgeJ9
	CD9SvINHM8SacdtJNE3Lqj5gmyPv6+++zkDfAJxbr22Iu2YJut7+ZXsItA0/
	zQOykBU0bBKK9wpMcri9tZbCwAlYP0zMhN3EglSSOCaVZt088Xi/W2UHZBEj
	rjcARF5Zb+i1+BuiE9JrN1VaMZ9oqGxxXuSbBYJviKvxmWH73OIrO4avpC/C
	pSLFk72jSwlSCRQTViuyLIBsUogOmGuIG3COVVEv4lsEf22c97Hb+oUGkfi+
	LK6VkflSQyuzZuDthoUXHT2T3qmmD4Bq//BAcSvraOBdHg+uAl/akAH26475
	2ibsADRk6dlj8L906qYkqlYsnphGKwGY0MQ3PF990uSrrEpEC0wM2mjMmiGw
	dWjak0KxrBCCELUrDk9wtZrhaKEDRcmnxYrBk8j6J77+hkHQFj7uwsZZfGeK
	jneAMb8dGe/gj6rkVlZ4r2r2TQfKzLLI0gnR7ir1Omyg1rFvG59yxGZX3BtZ
	eQHaBE+0tiiCUainWmUcLTkl0awMVny8FZSkKp3lTDPwEpks3qiN84LIcpSR
	QpBFb+5gh5k1c25ramIfmezYZZ9HiNBoQ0ROs2F9HbFlJmVTwiofLddWUyu4
	7m4LYLdgCGtW/O4NFPVuYNZc4KAT/UtgPSfF4mhf9M4LMmeF4PGX/Zy05tUS
	Bx04W6yM1fm4ZoUY7GLNd2tn6t3aPalYRxYaoF2zYpsqrr3qB26kzvH8S+FR
	njcID8YeRQJkjQfvYmwFO9QZnxGm5r9YVRbD3LWo1jap/IJKpJQEas3ImpYV
	u7chkGfVS0FTGnMlEh5Rq5iIMFm3BBeXYxFpHOfZ0dPuDvwOCNRFLwOLEF9j
	wIRIv14pkp+K5SBA5JRMBWansCbzEcI2aPeZbQnvZNnuYTmFbxHWTqdUJKfQ
	vHCdpfXqcghmJ+TVWjtFoj5+NAyzpNV85D5SmFlAFavXBawjZvzMOK+2e+nW
	gNPLKnBcocRacLx2Y5iNQBiNKIpTMpMlLLLlkWBkiNjaxWV0IpATMxdqE+yI
	V9EySQ0I2fTunBjzYrexnxd4Io1wBnlsA3/7z6VsjAfafAAKvAaTbCW7qt7H
	YxtZ09UUqb2B02L3i2x37uMF8WNj8LBQLdSLX9jJJhHRBa9kFZiotDUYGCxU
	xEgvt3z+tPmk2km4LELRofeFqxkEJjmoHPs8maRAABjIgjwYDkA6DrCyQjHy
	YXr1ugiWjR0j2mK0327uAGS6KBh4tMDiHHGXuShUnU4GosLU3AVhXN07qbZU
	x1FxIA5ik+EE0i9K6ItMzBMRzl3HDKjFGlk5Q1rErBYeAY2HDjkfH9VTG8uE
	oBsL2troxuji9NUlFrC2YY/c/irnYTB7WRDl0JZ5JTCR6CAsrmiIQMVpib8j
	naCqigncysqnBW91wezNJQq9aYGHGYqUJwOEua3ABRl0bBOCDxtPJNid9f+P
	H7vch8JvPn6EHTDigbGzm6FS8wGBaAahJqR3Jwx7dm8oDkkS3eTV4Vg/QhLS
	jXLPSl4T1GgN04A6yjKJbRoiTgDH9ubR4eHRcXL77Pj4mxvrxwDnq4RnWeXP
	RgS3P3rmu4uJB8yQkLPvY0815HQEGXrQgDhPtukY6RR210zV3rCb11c3whcE
	3o7ZQ9Acv5xi1qf2MIZ8T0a3vUaKp/Z40E6Ey4uHIFARuug/SSuSZXxO6LA2
	l0bsZ8ifYSPWkynGEqY1nkQsQJ2ESbWtlUdXpgY1Vz2u1UYMw+4wGqeYwTCU
	iNHRGmDvXZyRBBZ8BThXYqYxFORlXNLK16q3I5zUP2FjF0lRpm77hK3J6dHr
	Tu6jIZCxBe3dTIQNOORPQ1Ztvzgg7ByJJyVZZZ0ONlrUj8cRZ9T+fu/d9qLJ
	5MNWl937vPdpwGjxP6OzQLT/M7oSswuhFbJWSD3652ik/x3cUHsVO5Em5obe
	h6XHDjO1Qu5RuO5TdAMk4Y/U+uMoASvaf/T0WyJE5yAd3CRE+0QXv2UEq/zz
	xnCEMUT7z75+0hiByrzPGME6Tmv1XBBhpYgRalBQANsCnypANbXBEJ7YfttS
	n53mzMgLJa6b37mJ/GE0LYobCfOcChTBjIefOgpx8EXXUoSt3Yyb/PyGjLlR
	gxqEPaTif1A3m8lnYvqJAm0lep/Z6HZJfPA9kmIeA6oItjGEzfECxkbjPXGe
	UkAkrHGoQmNdqeVtSjMsO20I+kLi/m7ObzhsOIsnDF00VkXcCTknF4MXLkyc
	s7Fq+jisaO4rcMjGgvL45opCO6Oz4lCivrZoaEM2WViflSy/m/ORI06f48kY
	e1XD4cnBNDRK3kH3ajoN7EEWt7ZjXs2hzUGwn7594Kdvb7aUVVYlSDSuFqGW
	1+kkSVUVjtl13YZCvWS2XjHRt0yyE5VrqO7RzV9vFL3hLtIqcmg2DL4KkyCZ
	rz387a9/t69vB9zGNXHfZS2Zs4Hm7KLUJerE5oUamYUoABb3a2a62HntYwwH
	zkLdxoYuSHgYQG1eaceq7d0WWU36yl4Ac/KKIzPHYgDb7X1ZhUPNbeyKyLM5
	WSGVBOP3fm0+AKOh6TiCZviHYzYvwhTUolQ9KkjX6/I/BLqc6r8udaAzd8wZ
	RLyLyxXbyOoq8u4KVRAkQKWhBlgP4Jba0kiqC4HFRnQmw9duuE3Ns4vSd8S/
	co6MQGlBKGcqYc7IxELOv8RhqebZDspjPdMH8Hb1r2BvM1RWm4Parujdv/T1
	2zHnXTmadhGdfetRxyU8tdenly7kd6hQFfEgjqOlhvdukqK+2Rsj8euz2/7x
	7N62/4G2Bz9xkFx3WkvxkOz0no1vq7lVg7R1YYVhisOlMUMmAQ1QZobLam6X
	pFjlHFFqAUBprGq2lhUkw+ZkrvvIl3ZgaVBj5dq1HXhRBez5+EVgCg76wF2d
	nHjBLdBhUxu4Hadxd0c5K1QyqRm9ScwHH1QQ8HdtsbMJi5N1BrM1glS6aYkW
	6nVR71ZsxOej0xPkzJRN+hjRcFszVsdoMI9U9b04cEulfgtb2kQ67aY3DpMy
	7OtZIlW47g+ZY5poxIkF5uDR4eENL1/wjP66Gcq2QOsQI4ds9YRlwcRW4pju
	WACx5Nur0FqCodU4OuYHPFCkmh+2Vbd+oAGFx4y1VCAxlR9iX9eL+L34A31W
	NsvipQRhd1JXIwLah25yIJENBUeeH8TEysbhLnxqZgDKONBOCw90wjAH4y2v
	DQqivG9iRs0IEVVZtBbEqia7AwvcSTt6YB0pBy06GJrWQuPvxO5upr+za8Yi
	3zUD2Yp6u484UJCjkiRaGTqd2uBbAfgBJtC0sV10LcLKbDxgnTK9SySje3px
	NtwKZsQziVCmLjVtQzOA7Gc+TjASf0ixWGCUWtSAtUl28TJLZu+Vz0k0OhaZ
	rXhk6gIKSRA3bPOtNJfIMqGdfqtKHVcar2cJQGXEyDJOG4Au7saek8ShleKr
	BHorEHBuxEsQhottrwidpSzzhR28rxyxj/SKAyChHVZz1NJBJjNk1yQtSbpC
	w5dk5XPx8TPFqTWj+LgA3c6vMUXGavVgkEZi+6c4dC6GUqxySWWMbvJVlt0c
	3we48AEAyNJGYIefC728MzyrE0F/3uFElQH80vifPBrc6NoDheCQBAs3Jv5k
	SiUU0caHXedUHBM++9f6d1g37jx/nVZt4wAeIC+VLGU3vlQMJFlUlhEKsyHN
	VnRccSwAKz2ObpZiG93gtN4Eg8ZM82Jw4wAUnjqSCGoSfGiG3Q3qVt3mc/Q2
	KovdWHjlvu/1rYBQ94ViJoziwGMkp0LyqjlnUC0fF4ZcydEwyYHtHdNcVej6
	PKcfSt4xWW/gC4psyOQBt8pf1t4ehvvsAeVgSn602mFGtsTIIrPoV5w2btJo
	IJy4S6ISu9RHfgUrqk0HAdPScFVrtGfAECy72+coEz96b28dWN+XxSuUf8nS
	sYswLRr4oV1fHYeqQTIG+oespa/8Ugt3FlwA+H6n277JFuawqny4vWwb0SOi
	qGkbblY5oI4bDoi/4T+VPHm9OU6RuN4D1tu+2rnM1GBLy/TnSrkeePVshsyx
	2giQnNbIP/BZWluRftBCvB/UpWP/ZOkJua+BwzfolCZuF1vEZHu6MqihrPME
	no1GLL4Hpd7DoFG4uxSG18xttmaLLeXEgYu0/Bocl0BZYnOJC/ho7Pf9IOk5
	oFEgOZIXEACW7hDyHBQsbeoxDfQNDbSxpA6c1LGrvx19+2h8OH40fkKdl2aJ
	gE0O9Z6bgEKcczSkkWZAqNXeEY3BeFtzIK6bhywHiYjR+cgdoHBNID3UY5T3
	RCaMbS0IRlUvJSjp4xe2lKZEKX3SEMROvZKU70lxZ3UFTpJQnLx5SOH+lgyD
	rZ+CAHoby+KCRaotvI8FUGlQtONOV2MrlcXGhjfiwpo+zi0+TE0HdjkIX4sB
	hFEWIZIliSDLyqxof4rEBQCU6kyukD4zm2tiE1TNTT6Zl0WOtCNa4RmxT3ZL
	L+jjrBce/LIKdT4NPe3J775uaFXhwBmFWCpDdrzIlkzgpA/dSFfZx+2lbp2m
	TEQ314c3GlzlywC5FadWVlVlVWlOTrqtOEywRlEXLshQSn1DwLOsU4x7YYYF
	MmMSA1MKB0uCGIpA2VNzuBU7xUy9uNM8HcuVdimVjNJagO6gAQ10kr0AA5Y1
	CLeUQSAvjnuVeFTtXFLnQmcgH6nFKqtT4LJW1kkOlC6Xnafyi0BBDiheIywr
	1ZlcXN4QkC+n2dGC7b2Il8tNdL4xt4jP2nOFIh4fPmXb01kExLRhMDTfVwcH
	R7k4Dsri3NjMaQkwCYWUZKO6vCnA6VyVKubYWYR5iB4m2PetGE1pvpLXnd7o
	970JDeG8plVYzsoXDNJQRyHMzNxx2lqD5yHpRxH86G2TeEQGPJxw2I+TOpxX
	P/LHcF5AypOKbnojo3y5sCZBwyNE03RD46AmkoAqzVkKppUNLm7q2haSKfUT
	1n/sF05NVSVg//owGkXno4auSS8fRL+LQj+hCiQrYpQhgi66PXocahkmRwXg
	cu1C6xOX2bDWEDEbChu8DlqyXhdhTx/q9rlHwl2tlRot0OSywULnk9U/bTJa
	p5lpAUYsysOd3yzVJQ91VvTuuECAffus3MGWUKoKFnp0VAwILraZZdZPps67
	vMvbxbT+zkemuxD+kOBdOKazHW7e3ZDCL5lQ0P60XoMP2G9IM7VuWk93xU+R
	tl5PxCcmo795e0PMr+QyBP14LJJGnI/NuyolzJRTg3sDB9taRN/GsIJ7zPIN
	Y1Ljt2txbR3LCbdJC0ZEZqst7Sv3s4FlfBD80N0683MlAg1ewmcBrR60aRqj
	Ao0tYo6PhpmT0bomKEPMYzEJj+ydWdDi8Ou8NFvjp3fOSFzHZaJ1j6X2ReB+
	0UHiICw75ynL9O5Ggq76qOXBw9GW7CK6+fQjXfTR8wehRmDTUozcb2zK5kRj
	R1G0ehS9oqUViuxY3MHgO9QacvNexJnMmbWO2EUka5587EIs2V3afyQOeJnS
	NtmpIGoq+nawo+gaypRaxZX2TvPWRKN0bMbD0PUaaJWagiC5DD5HG8O0gdFZ
	yjFNjSIhPuIRod5cLESDveNclIBu65xU9lXJIcM3V+fv/vL85OLlTeTc0Bxt
	LS70VPOxLYQrLOxCVC3hYaetmJEOx5ZTUD9PXN4voJ3OF3P+FKeUOJjD3KXg
	fE0J2GDtDDdAYwjKeFsdiGV/UDYFH9bzUovymW14Sh0KKhbVidDrXhHXecXi
	urNgtijMvIkyPq0HgQgU73fvj4vpXdVUyjKxEdJav56lghG2u0vxuIQab0M9
	CDSD7WH18AdE6xokYrqAVy7z0rY7usaua9cXVCimVhnAJ8AYpMwYl5WpbZCp
	uqggiqe0c3O8cQ+G0Rc/jNV0PKXrFEiPDq/loYALqzLogY+//j36Q+RDkySJ
	hdkPIi1bbWMb2azj5sKXvAqKd2xrnQmOjfxki//Kqvcuca80Fzp+GOFhTWNf
	SMTi2z0avVPI+7TrbvVbTYVufDjUxx0uzLr4HyIbO9mr17uFx2/hBgY/64Kn
	IUd1frZgKXqD1oSeAvDYts/x9PRsI65gddp5ol8WS9QdK6YuUIAkBwbrPV6b
	FnCsHFXHNw51odBCPhUj4QVpIEUAoQf5da2m841vs2tBPHncR1x8nUSTQPiC
	B6YNJf3mTmCRrw+h8LDncFuhz83a83iBs7UzzozzHhY+wQeRajLBKcSpZ3Oh
	z1pgbZN0moVssBaJtCdiSzMaarUrRdEVPBcPjyLqcSV1TZYlnzKWTexvPBAr
	5IvoHG9GZ3EdDwavCmKvPZWIGIGAn/do/FhhNjYE5/YyBBaUe9wx17bb80qr
	WosqjTrJw7krxUnbF1Yl+rhuXNUgiV3snstASgU01m7CmwnYLWt9w+J18pOI
	OC1UAxRU4XDJgf6ukfbGmda+saLgGh22h2OclGxmBDsdQlSI0PS0wQIrdviz
	dtomj/BCEglLUbJwug2+VKqx5PDO+5iu1ceEmDz78FPXsWxx7n0rnPm2CfpS
	Y8CIQbsDxPqs5vLvjIxgHTTghVs+ME9lXSru2KpenTYojJOMEb7tdnuHtlxV
	c4lccRGbyjPrDg5s17W3nI0PcpNSNrCcFg88h0PxZ9jj1fAYs48HRWrs0Yx3
	V7VRKg0PpUDAihjDmyzmh61/LMzHVUsvSkfFKCRjg0iDlGz1YDAP7qiPGNZG
	FGgWtYwKqWklQCfiLv896NNVyrOFaBAOIqC9VgbzZKn+cfjoUCCKTT8U0LIl
	CGhQF7kuaJFP09mqtMlQLnok90XlMUfxaaW81EVQzmOdlsZWp9QbNBJMLUad
	gSi6lmRzn++DItOkh4eu0dC/J4mYInJcTLgkMC7iBDWWwloiKOffiB+vUbUq
	LPsXdJOZ+D1KYkDei17zIa03PeFK02a6vONVbaQUS6Mno7nDDFir4thzQ9BO
	YynIS9rVjUtPksxj1jRcsYNWnQRxbnlbtSGUAMhfjM74krdRnVUjgzP66cBB
	okjns2toT3pnlGe76Nl3LnRJEn/DigbNQyNXCgVp+s0MRKVvLleTGHXFa0Mc
	l6tRrgwm+bpckTpKPYzT4pc+wxGrR7/gvin/HhxgHFMGYlFLUubD8tnTrpR3
	wPA5XCYrZjP+A74gASa0PgmKa+MQkeRnKKf2hbJKw3XCW2I1WZlw+4Nq3gr2
	DG3RQYWuXbWaNkbiIMBhI3oJ+xoefe9Jd2r5jjvFGCA5twauLUCyO9j34xdd
	2ecOCr4P5Jbs3GzjwmxcBV4MGzLDK+HulQNGdsWHeLQDgjXsVWkYP6o0H934
	5N2Gyn3szvJ2v0kA3mcbFglSRa9tuVZaqiGtmwZyiB0M+sxZa/P5F9rOFDcH
	/0rnFOln5+jz4HgnWMm2faBCAheWUwhkGFagYIlWSWd8Uy3ybbWOpwENjVt2
	d14d+6+0xRCU6sWiFMO7pyem3ed0ilRDdWR8Pw1jy4cBST266SPcDlpUP/o2
	WsvFDDNiXzSBwILrRDh6iYEN+53b/OiztzmAhZWjOnhY0IQthJjVjg7HxZDr
	Gtl9aP+q25Ynwai2HVSNqCZg9rqOWkEmnc1M+7oHb1kVzBe3mWIIfvZq0nG9
	FbVzUdsUxLo7H9BNgA1I4IEuC1WAOUSLmSxeknJj+WkH7T3XSRLzHOmEP6HG
	J6qgeR4x7CNDCRrAh6o4+hx+UR8cE02MXEYXShjRIUvkdgWloTkzfGIc8ptW
	WqWhgT/8Nur9b/L8r0uetuQhaZFI6ryar+oEdgxHDT9A+I8q/QIVLx0Lfdwv
	lfnSzJThiLjunjqm0KhRWDWCahvZn4ENHxYZUU2rs7hgV/aEfTEs4fnJFc37
	3OPw/xHBL1GLWe40taTx/4T2TwC0titY6PCDQ1E3QtPDUElGurj4aG/UThe1
	f/zCaiJKCy5j14+hL0e9F/32usaT+yIIBBaW3NuwNJ5cY+xKaLubg2l7jdZp
	nWCyJ9PaeJTD7fx9vYaVuen1L61baRux41zv2mti/UF47LazSnkjXNirM09u
	mvlL943TVZTBayES2QLSfQVVNnhRg/KtJ8R/vQIlL+x90OCDi0+6iHXN8euu
	9Kj27gMrPYbVHZtf/tev7mhPrNuzFPWukThAe3ZKi5ebrBrsCIW0Dz/Yyn+K
	wfXI0J23Wdy3y8t0yZcS+gHQwO0NL0GYoU/3L12tUV1DLv4qyZxuR2jYyJHj
	CEjAy5M5ApdllXlKvTclWIlnt/Pr8aPx0fgIHTF5fPP11yiEPOWg1esDLeTk
	N//rdsnkqQ9v3R0V1s1Q3cQbgMH5HQtatgdVrmo5Sr7Orv++CUaXWV3wIkqN
	yEA7+XQQ9Xi/neVmv7Ea+Se55l3kvlbJ1rFoAbPuIalmE1wDHoRnDTUAUSaI
	CkW2bKiLsg6KN8xduM12wDzDr3K9sAzKXnEkBGy71lKxNvSe/zlyvz40UC/S
	WPyOaL2DrRD4z4nE2+Uh/rxQvECqPv1NcXnnW0F5NqztgVFsndF6IYn8xnC9
	7ri381bQ21WAFm0L1qftV7YBJXrFrspD4gLvXZzGD78p1u8/NY7v9Y2tZghX
	TU9Y3+vPD+trN7Ed7vkfHRpoDyKv2f3xpmo+/HdAoEqvrgsewpIuXZc7XN97
	gcEOpbXj/oLQpv0NtxjsuFTAlgb5D7+toKPh9m0FLNPV56pKb8O7ianrtTmd
	Iq4QJ1HbG+sxhHD5xXdsEgTwEWOyBR7xrs0dkQL8LMi7QYRKrA97+0lar+Kd
	VkhDsb/37gE3gv7Occ/Pg+8w4PO+3WIrdNIWVXAe104hYe8S8AmI23cIhODA
	ejvWztWz/yxPrLtXgK/rNBJjFYRIti8X6AliVF00LEHsgapKLzfsKiplb3yp
	g6tUwrQovlHF1j2zhVNBkDnclSc/23HDxbvJiU74BssA5Wjc99h3QcD2NTBB
	gpR6RoRn9F1D6G9H1zqn7nIoCyQoWJGlM72Uzg3XRwvLhRTMbbVIQ6yk2Uho
	7dxhHsHesiQN2vBlZ3vNuTswzhYP0Wm7RMlob17Ue748DTcYBOBifYLaBTvW
	SqnBF/+LrnHZ+6x77Ry6Ed4s1XOnbJy72hM9oQ+3ZsMlgFWv87mj8W1hry7r
	zQR0DulWyrkwD77YTcI14o2G83BGZ9VXBdhV+xBAhK8EH8th0M1kX9pWb1rW
	gDlMeB+YBei0dFQjdk72qJnZx/KcJM6/9zQkhcxre2UrE4Wzmxm6avpibbIg
	t3cdFrYpGTyoy3Tp0lFbUKN0uf2l9574Cjtczl3L/zXfCRK4tH22g6OLk9cn
	YDkMR8XKdZpp10DfSQ/mNyeNN7mFS8Xw2o3sCsWq8nTUbOpTD39wdzfsRCuD
	6nKaPY38sodEYTHC6/6Bg4nM5OWcjEy/fYhPqDoChSTGUsszeFx1K1ShuHX3
	nV/kAW+RJL11WM4AtdS1jKMjAIzf18Fr1rVCvq37OtuMpBS1q9XO9ZD6hsNs
	QcpHkVyTGoMh9SEOjGu7u8C/FmnaC2bfkAStbTgawkNwuxsr/TuDfqiVeZqY
	5jJSE0OJnrICYSuGKsjX5fTKVLiBG9xcahC+l+/DbQNgwQV+kHoLb+KdFP1j
	InJgv14LgLz0zJ42FAmwpYCoL50Ru+G/TwUDiu31ewzd6RWJWqqWpG06sWNT
	3BARZRK5uS3eGfTsitkbanhGoG2BxYZ48jIYqpNFLCVd9oXdD+KpojMuqLmV
	VIDU10S5MSVkhpQVionKJkEcE+52biy8BMqxK6jX0rWBPzhxZP+wNZ3x3dcO
	Beps24NTWjGiR7W1MVb16ra1nHorrNwUvM4r5OEvUHrRKXf2smq4s0gTn/sF
	Q20Nu9Y2HlnzrVHAkjm+DbZu1fNCsQ/cxJ0aoZzP2m1XeCu12zI32RLIlUUq
	QLnA3jEi601xlUB6C5FDnK+EltZB2RpIh/RzhygxZ6iIY0pU+4hnzZ3jDfOF
	YqHM27Qkz/YadcIhOGgEWNptydT2l4SSSu9nhPYyNYzrzFCCt+6LHRO1nB2w
	rhThRR3eITHleF5tRTRZhFWiIEEpL+MwywW04DhspIUIes1lWz1Urh7evTlX
	GDCuIkFDbe26YiLQ+rQuDVIWsiSsSuvq8267lcJlcnl36iAKrmblcjvdNxU1
	LqwngqnXcl/f59AKGDOJisz4Gr2oIphW78OLHdOwyq7GRdr7QnfPjGMgi1sp
	m9EkgfbmNVIQuSYHToPcCV4buQm5qiVZ0F6JzNeH4OK80ja/LdE/y4oE8dAW
	pMJgafQTLQ+Ut8e7wzUdFFseD96Uw66v9SbZopLyihKpLLNdwCeTm1Gaj2hx
	R4s0SaSmN9h0D5ddu7yi1hHhJN8aMaRK6Pb+VKuBt24IPuPPWb/TFmqucCkD
	F/sAmhZIhN/yyoCHTpoXDJEYq1zYMNc15svD4swWrJ4UnBGitytbudLwA7pS
	W5aybC0iT3qVpNWBQJZa/ElpWq8FYl484tiIkt1M2CdSyuSiA2TddLzTj76x
	jaw27pLL4UykoqreWq1Gy9vXJ6/OrcWv+q74Jb89evo1xyVyrVwi6UK0TVcM
	5dmh/E5W8FBsGw66DqWMDWJX9r5pXlTtq6DRYySPGlcUjNU+vm6TpzyOwOXf
	BDygzehPqk7WEtZpDi5y6rt5lUMs4CDj5AaLw9ns82fIR5429WlHD23vkFep
	VWlyrU17bRPdOi6yz+HCODF6VTACQ4I77ex15ce2QGy3QSxySV0Ejp/4ZUg1
	1ip05wTT1XTbqSqR97cTT4KMLg5DCVVvubLDXzvDtconvSCLu+pFL9P7Sk02
	h6Vxeh/uHwqul7eN79iOa0nfUz0mKD3raqnG0QwqkSI4DnRYg5nbetra44H4
	GThlBJQ5DpBVXAX7MA7vOBKvIsA6wWcam0qydM2lw4pI1gXX3tH+MF3qeQrv
	Q+L7B321MPm8TdDKmn3ZIau3OmWL8UlXPbtxKaQdERt84SudA9fUbAFkILZo
	/6ym2XP7BadihrEiPEned3ylZUpxT6OpUgAZ++/ODqJpFgNQrwz48ElYZkuT
	90RbbEMKn4YNpXfXPZlOc8yLezUHErI55+KJLqnlMxEjwe9hJ2AGVF4eDG3G
	pavQBCVP06ScT4VRMQleJybMLjKnB9rOamt+09rQ+uB0QnEvxQiUMGu5pcXX
	ydVQ79b4LCLRibp4ScYxGrmr70bPwfCrdmsi9BkZISK9QO80ZIdIc4FIUloh
	0tX5wDcv9V0XeKsYdCdTlzuVPcyG0aFOXn+n1rcHJOsWWmtFLVYo0szWxsnE
	XcXHVyAMBq/YejfFUlw/tOqkLHrrNEGAR7G0GnOTlBRI9YcgvKBvcJLReWGf
	26t4U84LOpLDwXdlSnt2ltLyFPlwcDovoXzToxerlDhsPByczcvVXXQ2L5LN
	cHBeEpN9vZnRYeZ/vI9+QOTOcPA8K7ilNwB4hoMXcbFZRVfE44aDP6cLOl1p
	Mhz8QI1HV+hiHr8fDi4Zn7ieFwtYlbl9cMcD+oVeeBeTpviTuUWL76ATXsXZ
	r/QnbRJt1jm9WA0HV3EZ8wToxGAKV5OirqMXxBRNTjYsNXNFSjWdfxN9R3v8
	64IsH2rv56KcFRUKAFdVnJFR9t5M9SI/NrMv31385ZyvQuWUXVLDcX/gaDRi
	NRh7J0nVTQuINvB//i0ilSY6T2DmHUfLjA2dUoIR6vC+21speSGiSxSZv6uy
	x9EySfqBb1ep1AEn0rmdAaqPHauRSvdT1PgE5t+YgVTUQkycxR11nj/pW9/L
	PP3FLqWZIg/T2tpcM9pCcg0ognMrYSP/mN8ysOxONEjfIhTQm8t0ITKSazcu
	43oucghnz2Gq2tgZCZn3/Xm9VqTr23ziRlURU3u0EjBxOlv9jvZk1fdOZHNs
	3l1cnkcnNS2Z8gX9+pLUkBJzF5EhdWj8PQFbPb7294iw1AIig2ggNCGYq06F
	7wphinTuBAXqnb4cVMU4eiw/WP3MVn8vqwPWkKCzZNGCmDX7ZY1KApbixbRe
	x6XjJixQOQcROn7FjIlxHitSz922tRF6zumz/qVYw86DPaajwGoMB+gxY/UA
	kjoG7IT8dzrU9wY3QxEHnAQ61gQHu4EFmskcki0LYTGHkTcBhsZBaUtie6ud
	7ZL1p0aPaSfo0GMB+DJ2KkEr6wfTVV2oWymcZuhFOmWPSlp5XOX08kfx0BMz
	4fuHjQND5OLivLtSYmdjYkW5cKOSay08tLlXAWjbZ2Lb/VU4yhrIra85q9CX
	dGdqUC9BooqPvT5U7ufIN9vTwdBE5YgBU+TJOk1I89inlYb++pWZiRpry3ku
	OcIbt8MNiYwwcf/k4IGLQIfkTNW1E1XXTkRdO7HqWvTxC4kr5ns7PuPu9M/T
	CU/UTRmAEaFqvX2xDniAeE/XsUDa2qFYG2jGNMpCO3G0df8YaBC2ib9ruj2W
	tNrh/Eb/yv05JnMLQIo4oiBQXt3upEI7fQawavcVf53WqkJxdE4zZKgBLiJt
	grZjLtDw0pXWTis/03T39WtiBdmFLRv324YBV2Foo7+RSC1khR4XnMqQhwfL
	9N9+GFRO7b3Jyua/0ZOGRb1rFRdGINDeu4MlwNnFOtxuGjZpO0i+mUdkf0Pw
	8JyDKBOOfWRKlL1buDC0vOilJBf4wxh8Ri9IQeUzb643V7pq7dQepwdK+M5e
	EEPF0MNVYQ3xNnkHRq+7f4w0CAA/8S9F6e7IkVAcqzo9gAmwDDgJAMTWXXS1
	wX3vfdlEO2+BFo9n5Q5EN33BwzhqFTXYdS8UDxdhFmIQ3iKif4t5bePDDhLR
	d6sda6LsSL2YEvsuN7eByWCrUWmg4Nikjx//+Or6ZHR1ffV7SY04QnReiedn
	J6/PR1evri/xyzdff/NIkyaiK7fYr9xiX3LiZ03GLwcxth0zWxPSsj0d2+Yq
	WwTQSFBHv5+lKJjXpNAGowg3sBEtItct+ZAiG9x+3TNGhefXvuaVjJfGkspF
	u8BzijUJVhxUC5ZL3PmWZOLoPL5EQaJKxQ/ONxfZgMEZh9D4IkYAwZNx581x
	/FvV8hJJ9I0ofF2sqVE2pYG3Fo0iGJLrJwGyMiqmv1p9vnJOeiowMsTrL2t3
	0wAnFLQpEf3dGl2vrzhEgX4OgiukvA1Cq+m5H6mGrzmfe3coCqMmqLdRSk/B
	LQ9FqX55xB0Vpsq/9HIfzo3olloXF0e+qedaeZFHutHbtI26+x3RjKVoEOzX
	odvGJiX50F3pmmFWZTd8H6qCSQ54AQa9M8nRTdK6ZoLtm2ohAzkdQXCBI+yq
	tUO+RjtxhOuXV+8ur5VRHHpG8fpqdF6WRTl6Z83f37taMUleFUv8d2T4FWch
	W26yzTq7ysZwNahF1a9G24r33jIgEvnr+Onht9FpUOwlJdVMXXgRsmSyzUgK
	LPmKMAyS6RA2nffhQODSS8RImTClPODO21+Q10DstD3o/doWIkpzYBG1Y2w2
	ODgUzKTEAIbRIKaQlzm7jw+cKnJ6jJrFTlbOWqWWr85PkeZGL57jytawToY4
	pA6J5x8c9ER+Nbnfrro4Wi9c4q5tyTb7o7Yjlz/wGaB5tMs48al3y2yT0jSG
	c6v2fuOeF6GyUxa16P/S3mfmKxI4PYPFVYONwKnHmyFZjrlZh+UNXLSQnNiH
	yHETVg8dhpb31tmrY6RCa6UUomyFjxV4Uuagl1m7U+8MBg4sjj9IYDGX8Uqk
	yhbWXIstpiWD02rF26/YYi7qub/6jZ7OjMaSIWOaC0BaT7sv9tDKnYUE6w4m
	bQqnQM2T6+jANIeu3I2dmkSDcwWreNI4jhy75UweHOtqWXJVv61+LAjeijtx
	0hg3lgXSVLIWWXLlMfGvNfELcUepV7vVXodwJwPYiua2D/VfBUG/CNp+kaJY
	50bT0Fe3rIZgLKcc3avKx+joEXZ4dPSYsRP9yZ22i/Or7yPUNDXrexs6koYe
	oSGZAZC0ib7kYomSFVuSF+fXz6OXUPtPyVi4t/FDafyou3GxhBFIy4T8eW2T
	QOC2DyX7jQ1PMXtPznTu8iaj+H/Z5LSR97b5jNs8/JatkQTt2Z1jKrXAFTOv
	Bmbo4Tz68kcu+5RYPZ/hYBGJqzyID/bBSpyob5Ut9djdO9ZvZKzPPAUktvwR
	ChwFuKSbTBgM1PTh2XkCr4JlzWGVxu2YFLK6f0xfy5i+GQSroGnJ6pP0k+ZP
	OlN2fQxiBvRZ/i1XSNzT/1Pp/2teE1J45IJQYVWoiG/DSkOrFImPSzIvDV9u
	KpxIan37ZHV1pMOL3mo5roMp8T1C9kJ3iDqwFK6GEaCJL5EPkhsXNeMCqup5
	aNMWXDGSP4cZ7zT5YLfDEP1+ynJR6xKT4zAUydjDwfywjPnsxG3/nKUbOqXI
	3smhs7TCLoXi7t2Yx7IxT9obg5SQjisU96D1XLPofmTrubNG6C5KdIlLY6ly
	aXPUnoy/Hh8NbX6zSWzCEIQhQ5yGk86sv7d96UpY5BaZhi5knSRM3dHV4yEp
	4Y3ptLJQOqrmhvdrsj0XlI8W45Mn6Eqr+Kok/esr4uDwsWdcuKK8nd/iuFnR
	HVAoGiq7ozn+iYu9ibXZg5l9qVcjIQraxjAoaNS4Tmwfpt77aFOsRMZGTUfm
	vx2MB8+NSTjojqfktQVb2YC5LJ2kRixUGFWr5kAfQFTy5amVGuPsuRGyD5N7
	oEU6/AA3BZkM1x2P3bJK9VaEA8q6ELmW4V0JNj/GDXG8JUpg5TRi3pfNmHeP
	SGlqraxnHXP05j2EIOL88JHPCU+47ofNCKBP4bt3txHH21hdULnzeHdw2Bbk
	qch6gGWV8bRWCE7E3FxflBDqlgL7pZV+qqhnWvHh/PRKoHUXID41fDb0mj53
	SaILCJRg16hhuOtCOojFsC4eixSPkV7GkgpVkrSVPZ8mJ7YZUz2PmtRU+O81
	REb3VeZMj6DWIAMwoPvLVW5o5a+KIgG5W6pgWkJgkRZlCYOaG3x8YavQqIPI
	1xkNOtk+ViPquNZ9EPqkTWd8uBTX/m56Eg3ukDW4V0xN4YynnLLdGcnsYHrn
	T3Gsf2OPHMRiGkRi2zpEfVUfmP+SvYJ4yYStF72Ds6toASche88ZK3DBJWMP
	PknRPuQwL+BIoBAQhxl50HxkL7I8PDwYBLNkthNYhpKzBEe8i3wP4scq6JZ8
	v0iKejRxTlK7EvGcgWOu55tWSrz7WqjSaR0WaMBlr2WSqSl99foC8IXNeCKy
	MyVRkL8ZPCz7wRFsExe3ppmZPiW7PUuOA2hkpIsyJGZemtkw5e66trIXssTJ
	+9kvFa1p7yo/lFqfk+q0HcTNdNZX54WViXcSjkuKe4wau+7ODLTzpAomjiQs
	y/mOozc/SJVmV8nb5n6R5S8GeyXFXfRFNoIEh+QgP+yNZUwnLy9fS60MjEyS
	C/HCn1FgAMdHg1O60HM+WbctUglQlcH/BWi9pFdxyQAA


	</rfc>	</rfc>

End of changes. 83 change blocks.
	2213 lines changed or deleted	1276 lines changed or added
This html diff was produced by rfcdiff 1.48.