<?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 [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dprive-unilateral-probing-13" number="9539" submissionType="IETF" category="exp"submissionType="IETF">consensus="true" tocInclude="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3"> <!-- xml2rfc v2v3 conversion 3.18.2 --> <front> <title abbrev="Unilateral Encrypted Authoritative DNS">Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS</title> <seriesInfo name="RFC" value="9539"/> <author initials="D. K." surname="Gillmor" fullname="Daniel Kahn Gillmor" role="editor"> <organization abbrev="ACLU">American Civil Liberties Union</organization> <address> <postal> <street>125 Broad St.</street> <city>NewYork, NY</city>York</city> <region>NY</region> <code>10004</code><country>USA</country><country>United States of America</country> </postal> <email>dkg@fifthhorseman.net</email> </address> </author> <author initials="J." surname="Salazar" fullname="Joey Salazar" role="editor"><organization></organization><organization/> <address> <postal> <city>Alajuela</city> <code>20201</code><country>CR</country><country>Costa Rica</country> </postal> <email>joeygsal@gmail.com</email> </address> </author> <author initials="P." surname="Hoffman" fullname="Paul Hoffman" role="editor"> <organization>ICANN</organization> <address> <postal><country>USA</country><country>United States of America</country> </postal> <email>paul.hoffman@icann.org</email> </address> </author> <dateyear="2023" month="October" day="23"/>year="2024" month="February"/> <area>int</area> <workgroup>dprive</workgroup><keyword>Internet-Draft</keyword><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> <abstract><?line 51?><t>This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. Thestepsprotections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses.</t> <t>The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections againstmore powerfulmore-powerful attacks.</t> </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/browse/dns-privacy/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dns-privacy/"/>. </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> <middle><?line 59?><sectionanchor="introduction"><name>Introduction</name>anchor="introduction"> <name>Introduction</name> <t>This document aims to provide guidance to DNS implementers and operators who want to simply enable protection against passive network observers.</t> <t>In particular, it focuses on mechanisms that can be adopted unilaterally by recursive resolvers and authoritative servers, without any explicit coordination with the other parties. This guidance provides opportunistic security (see <xreftarget="RFC7435"/>) --target="RFC7435"/>), that is, encrypting things that would otherwise be in the clear, without interfering with or weakening stronger forms of security.</t><t>The<t>This document also briefly introduces (but does not try to specify) how a future protocol might permit defense against an active attacker in <xref target="adding-auth"/>.</t> <t>The protocol described here offers three concrete advantages to the DNS ecosystem:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Protection from passive attackers of DNS queries in transit between recursive and authoritative servers.</t> </li> <li> <t>Aroadmaproad map for gaining real-world experience at scale with encrypted protections of this traffic.</t> </li> <li> <t>A bridge to some possible future protection against a more powerful attacker.</t></list></t></li> </ul> <sectionanchor="requirements-language"><name>Requirementsanchor="requirements-language"> <name>Requirements Language</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <sectionanchor="terminology"><name>Terminology</name>anchor="terminology"> <name>Terminology</name> <dl> <dt>Unilateral:</dt> <dd><t>capable<t>Capable of opportunistic probing without external coordination with any of the otherparties</t>parties.</t> </dd> <dt>Do53:</dt> <dd><t>traditional cleartext DNS<t>DNS over port 53 (<xreftarget="RFC1035"/>)</t>target="RFC1035"/>) for traditional cleartext transport.</t> </dd> <dt>DoQ:</dt> <dd><t>DNS-over-QUIC<t>DNS over QUIC (<xreftarget="RFC9250"/>)</t>target="RFC9250"/>).</t> </dd> <dt>DoT:</dt> <dd><t>DNS-over-TLS<t>DNS over TLS (<xreftarget="RFC7858"/>)</t>target="RFC7858"/>).</t> </dd> <dt>Encrypted transports:</dt> <dd> <t>DoQ andDoT collectively</t>DoT, collectively.</t> </dd> </dl> </section> </section> <sectionanchor="priorities"><name>Priorities</name> <t>Thisanchor="priorities"> <name>Priorities</name> <t>The protocol described in this documentaims to mitigate potentialwas developed with two priorities: minimizing negative impactsof the described protocolandto aid implementorsretaining flexibility inselecting between possible DNS protocol choices.</t>the underlying encrypted transport protocol.</t> <sectionanchor="minimizing-negative-impacts"><name>Minimizinganchor="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 that adoptthese guidelines,the protocol, for the parties thattheythose systems communicate with, and for uninvolved third parties. The negative impacts that this protocol specifically tries to minimize are:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>excessive bandwidthuse</t>use,</t> </li> <li> <t>excessive use of computational resources (CPU and memory inparticular)</t>particular), and</t> </li> <li> <t>the potential for amplification attacks (where DNS resolution infrastructure is wielded as part of a DoSattack)</t> </list></t>attack).</t> </li> </ul> </section> <sectionanchor="protocol-choices"><name>Protocolanchor="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 those protocols, in particular DoT and DoQ, are described in other documents. The DoT specification (<xref target="RFC7858"/>) says that it:</t><ul empty="true"><li> <t>focuses<blockquote>...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-authoritativetraffic.</t> </li></ul>traffic.</blockquote> <t>It further says:</t><ul empty="true"><li> <t>It<blockquote>It might work equally between recursive clients and authoritativeservers.</t> </li></ul>servers...</blockquote> <t>The DoQ specification (<xref target="RFC9250"/>) says:</t><ul empty="true"><li> <t>For<blockquote>For the recursive to authoritative scenario, authentication requirements are unspecified at the time of writing and are the subject of ongoing work in the DPRIVEWG.</t> </li></ul>WG.</blockquote> <t>The protocol described in this document specifies the use of DoT and DoQ without authentication of the server.</t> <t>This document does not pursue the use ofDNS-over-HTTPS,DNS over HTTPS, commonly calledDoH"DoH" (<xref target="RFC8484"/>), in this context because a DoH client needs to know the path part of a DoH endpointURL, andURL. Currently, there arecurrentlyno mechanisms for a DNS recursive resolver to predict the path on its own, in an opportunistic or unilateral fashion, without incurring an excessive use of resources. If such mechanisms are later defined, the protocol in this document can be updated to accommodate them.</t> </section> </section> <sectionanchor="authoritative-guidance"><name>Guidanceanchor="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 document <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 useALPN (Application-LayerApplication-Layer ProtocolNegotiation,Negotiation (ALPN) (see <xref target="RFC7301"/>). The ALPN strings the client will use are given in <xref target="recursive-requirements"/>.</t> <t>An authoritative server implementing DoT or DoQ <bcp14>MUST</bcp14> populate the response from the same authoritative zone data as theunencrypedunencrypted DNS transports. Encrypted transports have their own characteristic response size that might be different from the unencrypted DNS transports, so response sizes and related options (e.g.,EDNS0)Extension Mechanisms for DNS (EDNS0)) and flags (e.g.,TCthe TrunCation (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> <sectionanchor="authoritative-pools"><name>Pooledanchor="authoritative-pools"> <name>Pooled Authoritative ServersBehindbehind a Load Balancer</name> <t>Some authoritative DNS servers are structured as a pool of authoritatives standing behind aload-balancerload balancer that runs on a single IP address, forwarding queries to members of the pool. In such a deployment, individual members of the pool typically get updated independently from each other.</t> <t>A recursive resolver following the guidance in <xref target="recursive-guidance"/> and interacting with such a pool likely does not know that it is a 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 authoritative server that sometimes offers and sometimes refuses encrypted transport.</t> <t>To avoid incurring additional minor timeouts for such a recursive resolver, the pool operator <bcp14>SHOULD</bcp14>:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>ensure that all members of the pool enable the same encrypted transport(s) within the span of a few seconds (such as within 30 seconds), or</t> </li> <li> <t>ensure that the load balancer maps client requests to pool members based on client IP addresses, or</t> </li> <li> <t>use aload-balancerload balancer that forwards queries/connections on encrypted transports to only those members of the pool known (e.g., via monitoring) to support the given encrypted transport.</t></list></t></li> </ul> <t>Similar concerns apply to authoritative servers responding from an anycast IP address. As long as the pool of servers is in a heterogeneous state, any flapping route that 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 to cause problems for TLS, TCP, or QUIC connection state as well, so stable routes are important to ensure that the service remains available and responsive. The servers in a pool can share session information to increase the likelihood of successful resumptions.</t> </section> <sectionanchor="authentication"><name>Authentication</name>anchor="authentication"> <name>Authentication</name> <t>For unilateral deployment, an authoritative server does not need to offer any particular form of authentication.</t> <t>One simple deployment approach would just be to provide a self-issued,regularly-updatedregularly updated X.509 certificate. Whether the certificates used are short-lived or long-lived is up to the deployment. This mechanism is supported by many TLS and QUICclients,clients and will be acceptable for any opportunistic connection. The server could provide a normal PKI-based certificate, but there is no advantage to doing so at this time.</t> </section> <sectionanchor="authoritative-sni"><name>Serveranchor="authoritative-sni"> <name>Server Name Indication</name> <t>An authoritative DNS server that wants to handle unilateral queries <bcp14>MAY</bcp14> rely on Server Name Indication (SNI) to select alternate server credentials. However, such a server <bcp14>MUST NOT</bcp14> serve resource records that differ based on SNI (or on the lack of an SNI) provided by theclient,client because a probing recursive resolver that offers SNI might or might not have used the right server name to get the records it is looking for.</t> </section> <sectionanchor="authoritative-resource-exhaustion"><name>Resourceanchor="authoritative-resource-exhaustion"> <name>Resource Exhaustion</name> <t>A well-behaved recursive resolver may keep an encrypted connection open to an authoritativeserver,server to amortize the costs of connection setup for both parties.</t> <t>However, some authoritative servers may have insufficient resources available to keep many connections open concurrently.</t> <t>To keep resources under control, authoritative servers should proactively manage 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> <t>An authoritative server facing unforeseen resource exhaustion <bcp14>SHOULD</bcp14> cleanly close open connections from recursive resolvers based on theauthoritative'sauthoritative server's preferred prioritization.</t> <t>In the case of unanticipated resource exhaustion, close connections until resources are back in control. A reasonable prioritization scheme would be to close connections with no outstanding queries, ordered by idle time (longest idle time gets closed first), then close 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 also decline to accept new connections over encrypted transport.</t> </section> <sectionanchor="pad-responses-to-mitigate-traffic-analysis"><name>Padanchor="pad-responses-to-mitigate-traffic-analysis"> <name>Pad Responses to Mitigate Traffic Analysis</name> <t>To increase the anonymity set for each response, the authoritative server <bcp14>SHOULD</bcp14> use a sensible padding mechanism for all responses it sends when possible. The ability for the authoritative server to add padding might be limited, such as by not receiving anEDNS(0)EDNS0 option in the query. Specifically, a DoT server <bcp14>SHOULD</bcp14> useEDNS(0)EDNS0 padding <xref target="RFC7830"/> if possible, and a DoQ server <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 can be found in <xref target="RFC8467"/>.</t> </section> </section> <sectionanchor="recursive-guidance"><name>Guidanceanchor="recursive-guidance"> <name>Guidance for Recursive Resolvers</name> <t>The protocol described in this document is <bcp14>OPTIONAL</bcp14> for recursive resolvers. This section outlines a probing policy suitable for unilateral adoption by any recursive resolver. Following this policy should not result in failed resolutions or significant delays.</t> <sectionanchor="high-level-overview"><name>High-levelanchor="high-level-overview"> <name>High-Level Overview</name> <t>In addition to querying on Do53, the recursive resolver will tryeitherDoT, DoQ, or bothof DoT and DoQconcurrently. The recursive resolver remembers what opportunistic encrypted transport protocols 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 recursive resolver remembers a recent successful encrypted transport to that server, then it 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> <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 failure for a reasonable amount of time to avoid floodinga non-compatiblean 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> <t>See the subsections below for a more detailed description of this protocol.</t> </section> <sectionanchor="maintaining-authoritative-state-by-ip-address"><name>Maintaininganchor="maintaining-authoritative-state-by-ip-address"> <name>Maintaining Authoritative State by IP Address</name> <t>In designing a probing strategy, the recursive resolver could record its knowledge about any given authoritative server with different strategies, including at least:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>the authoritative server's IP address,</t> </li> <li> <t>the authoritative server's name (the NS record used), or</t> </li> <li> <t>the zone that contains the record being looked up.</t></list></t></li> </ul> <t>This document encourages the first strategy, to minimize timeouts or accidental delays, and does not describe the other two strategies.</t> <t>A timeout (accidental delay) is most likely to happen when the recursive client believes that the authoritative server offers encrypted transport, but the actual server reached declines encrypted transport (or worse, filters the incoming traffic and does not even respond with an ICMP destination port unreachable message, such as during rate limiting).</t> <t>By associating the state with the authoritative IP address, the client can minimize the number of accidental delays introduced (see also Sections <xreftarget="authoritative-pools"/>target="authoritative-pools" format="counter"/> and <xreftarget="conn-state"/>).</t>target="conn-state" format="counter"/>).</t> <t>For example, consider an authoritative server named<spanx style="verb">ns0.example.com</spanx><tt>ns0.example.com</tt> that is served by twoinstallations,installations: one at<spanx style="verb">2001:db8::7</spanx><tt>2001:db8::7</tt> that follows thisguidance,guidance and one at<spanx style="verb">2001:db8::8</spanx><tt>2001:db8::8</tt> that is a legacy (cleartext port 53-only) deployment. A recursive client who associates state with the<spanx style="verb">NS</spanx>NS name and reaches<spanx style="verb">2001:db8::7</spanx><tt>2001:db8::7</tt> first will "learn" that<spanx style="verb">ns0.example.com</spanx><tt>ns0.example.com</tt> supports encrypted transport. A subsequent query over encrypted transport dispatched to<spanx style="verb">2001:db8::8</spanx><tt>2001:db8::8</tt> would fail, potentially delaying the response.</t> </section> <sectionanchor="overall-recursive-resolver-settings"><name>Overallanchor="overall-recursive-resolver-settings"> <name>Overall Recursive Resolver 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 encrypted transports.</t><texttable title="Recursive resolver system parameters<table> <name>Recursive Resolver System Parameters perencrypted transport"> <ttcol align='left'>Name</ttcol> <ttcol align='left'>Description</ttcol> <ttcol align='left'>Suggested Default</ttcol> <c><spanx style="verb">persistence</spanx></c> <c>HowEncrypted Transport</name> <thead> <tr> <th align="left">Name</th> <th align="left">Description</th> <th align="left">Suggested Default</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>persistence</tt></td> <td align="left">How longshouldthe recursive resolverrememberremembers a successful encrypted transportconnections?</c> <c>3connection</td> <td align="left">3 days (259200seconds)</c> <c><spanx style="verb">damping</spanx></c> <c>Howseconds)</td> </tr> <tr> <td align="left"> <tt>damping</tt></td> <td align="left">How longshouldthe recursive resolverrememberremembers an unsuccessful encrypted transportconnections?</c> <c>1connection</td> <td align="left">1 day (86400seconds)</c> <c><spanx style="verb">timeout</spanx></c> <c>Howseconds)</td> </tr> <tr> <td align="left"> <tt>timeout</tt></td> <td align="left">How longshouldthe recursive resolverwaitwaits for an initiated encrypted connection tocomplete?</c> <c>4 seconds</c> </texttable>complete</td> <td align="left">4 seconds</td> </tr> </tbody> </table> <t>This document uses the notation<spanx style="verb"><transport>-foo</spanx><tt><transport>-foo</tt> to refer to the<spanx style="verb">foo</spanx><tt>foo</tt> parameter for the encrypted transport<spanx style="verb"><transport></spanx>.<tt><transport></tt>. For example,<spanx style="verb">DoT-persistence</spanx><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<spanx style="verb">DoT</spanx>.DoT. Additionally, when describing an arbitrary encrypted transport, we use<spanx style="verb">E</spanx><tt>E</tt> in place of<spanx style="verb"><transport></spanx><tt><transport></tt> to generically mean whatever encrypted transport is in use. For example, when handling a query sent over encrypted transport<spanx style="verb">E</spanx>,<tt>E</tt>, a reference to<spanx style="verb">E-timeout</spanx><tt>E-timeout</tt> should be understood to mean<spanx style="verb">DoT-timeout</spanx><tt>DoT-timeout</tt> if the query is sent over<spanx style="verb">DoT</spanx>,DoT, and to mean<spanx style="verb">DoQ-timeout</spanx><tt>DoQ-timeout</tt> if the query is sent over<spanx style="verb">DoQ</spanx>.</t>DoQ.</t> <t>This document also assumes that the recursive resolver maintains a list of outstanding cleartext queries destined for the authoritative server's IP address<spanx style="verb">X</spanx>.<tt>X</tt>. This list is referred to as<spanx style="verb">Do53-queries[X]</spanx>."<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. 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> <sectionanchor="recursive-requirements"><name>Recursiveanchor="recursive-requirements"> <name>Recursive Resolver Requirements</name> <t>To follow the strategies in thisguidance,document, a recursive resolver <bcp14>MUST</bcp14> implement at least one of either DoT or DoQ in its capacity as a client of authoritative nameservers. 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> <t>DoT queries from the recursive resolver <bcp14>MUST</bcp14> target TCP port853,853 using an ALPN of"<spanx style="verb">dot</spanx>"."<tt>dot</tt>". DoQ queries from the recursive resolver <bcp14>MUST</bcp14> target UDP port853,853 using an ALPN of"<spanx style="verb">doq</spanx>".</t>"<tt>doq</tt>".</t> <t>While this document focuses on the recursive-to-authoritative hop, a recursive resolver implementingthesethe strategies in this document <bcp14>SHOULD</bcp14> also accept queries from its clients over some encrypted transport unless it only accepts queries from the localhost.</t> </section> <sectionanchor="conn-state"><name>Authoritativeanchor="conn-state"> <name>Authoritative Server Encrypted Transport Connection State</name> <t>The recursive resolver <bcp14>SHOULD</bcp14> keep a record of the state for each authoritative server it contacts, indexed by the IP address of the authoritative 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><tt>2001:db8::100</tt> and<spanx style="verb">2001:db8::200</spanx>,<tt>2001:db8::200</tt>, it could keep two distinct sets of per-authoritative-IPstate,state: one for each source address it uses, if the recursive resolver knows the addresses in use. Keeping these state tables distinct for each source address makes it possible for a pooled authoritative server behind a load balancer to do a partial rollout while minimizing accidental timeouts (see <xref target="authoritative-pools"/>).</t> <t>In addition to tracking the state of connection attempts and outcomes, a recursive resolver <bcp14>SHOULD</bcp14> record the state of established sessions for encrypted protocols. The details of how sessions are identifiedisare dependent on the transport protocol implementation (such as a TLS session ticket or TLS session ID, a QUIC connection ID, and so on). The use of session resumption as recommended here is limited somewhat because the tickets are only stored within the context defined by the (clientIP, serverIP, protocols) tuples used to track client-server interaction by the recursive resolver in a table like the one below. However, session resumption still offers the ability to optimize the handshake in some circumstances.</t> <t>Each record should contain the following fields for each supported encrypted transport, each of which would initially be<spanx style="verb">null</spanx>:</t> <texttable title="Recursive resolver state per authoritative IP, per encrypted transport"> <ttcol align='left'>Name</ttcol> <ttcol align='left'>Description</ttcol> <ttcol align='left'>Retain<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 AcrossRestart</ttcol> <c><spanx style="verb">session</spanx></c> <c>TheRestart</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>session</tt></td> <td align="left">The associated state of anyexisting,existing established session (the structure of this value is dependent on the encrypted transport implementation). If<spanx style="verb">session</spanx><tt>session</tt> is not<spanx style="verb">null</spanx>,<tt>null</tt>, it may be in one of two states:<spanx style="verb">pending</spanx><tt>pending</tt> or<spanx style="verb">established</spanx></c> <c>no</c> <c><spanx style="verb">initiated</spanx></c> <c>Timestamp<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 connectionattempt</c> <c>yes</c> <c><spanx style="verb">completed</spanx></c> <c>Timestampattempt</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 isresumed)</c> <c>yes</c> <c><spanx style="verb">status</spanx></c> <c>Enumeratedresumed)</td> <td align="left">yes</td> </tr> <tr> <td align="left"> <tt>status</tt></td> <td align="left">Enumerated value of<spanx style="verb">success</spanx><tt>success</tt>, <tt>fail</tt>, or<spanx style="verb">fail</spanx> or <spanx style="verb">timeout</spanx>,<tt>timeout</tt> associated with the<spanx style="verb">completed</spanx> handshake</c> <c>yes</c> <c><spanx style="verb">last-response</spanx></c> <c>A<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 theconnection</c> <c>yes</c> <c><spanx style="verb">resumptions</spanx></c> <c>Aconnection</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 parameters) that could be used to resume a prior successfulsession</c> <c>yes</c> <c><spanx style="verb">queries</spanx></c> <c>Asession</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 authoritative server, each of which has additional status<spanx style="verb">early</spanx>, <spanx style="verb">unsent</spanx>, or <spanx style="verb">sent</spanx></c> <c>no</c> <c><spanx style="verb">last-activity</spanx></c> <c>Aof <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 theconnection</c> <c>no</c> </texttable>connection</td> <td align="left">no</td> </tr> </tbody> </table> <t>Note that the<spanx style="verb">session</spanx><tt>session</tt> fields in aggregate constitute 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>,<tt>session</tt>, <tt>queries</tt>, and<spanx style="verb">last-activity</spanx><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<spanx style="verb">E-foo[X]</spanx><tt>E-foo[X]</tt> to indicate the value of field<spanx style="verb">foo</spanx><tt>foo</tt> for encrypted transport<spanx style="verb">E</spanx><tt>E</tt> to IP address<spanx style="verb">X</spanx>.</t><tt>X</tt>.</t> <t>For example,<spanx style="verb">DoT-initiated[192.0.2.4]</spanx><tt>DoT-initiated[192.0.2.4]</tt> represents the timestamp when the most recent DoT connection packet was sent to IP address192.0.2.4.</t><tt>192.0.2.4</tt>.</t> <t>This document uses the notation<spanx style="verb">any-E-queries</spanx><tt>any-E-queries</tt> to indicate any query on an encrypted transport.</t> </section> <sectionanchor="probing-policy"><name>Probinganchor="probing-policy"> <name>Probing Policy</name> <t>When a recursive resolver discovers the need for an authoritative lookup to an authoritative DNS server using thatservers'sserver's IP address<spanx style="verb">X</spanx>,<tt>X</tt>, it retrieves the connection state records described in <xref target="conn-state"/> associated with<spanx style="verb">X</spanx><tt>X</tt> from its cache.</t><t>The<t>Some of the subsections that follow offer pseudocode that corresponds roughly to an asynchronous programming model for a recursive resolver's interactions with authoritative servers.The followingAll subsections also presume that the time of the discovery of the need for lookup is time<spanx style="verb">T0</spanx>.</t><tt>T0</tt>.</t> <t>If any of the records discussed here are absent, they are treated as<spanx style="verb">null</spanx>.</t><tt>null</tt>.</t> <t>The recursive resolver must decide whether to initially send a query over Do53, or overanyeither of the supported encrypted transports (DoT or DoQ).</t> <t>Note that a recursive resolver might initiate this query via any or all of the known transports. When multiple queries are sent, the initial packets for each connection can be sent concurrently, similar to the method used in the document known as "Happy Eyeballs" (<xref target="RFC8305"/>). However, unlike Happy Eyeballs, when one transport succeeds, the other connections do not need to beterminated, but canterminated; instead they can be continued to establish whether the IP address<spanx style="verb">X</spanx><tt>X</tt> is capable of communicating on the relevant transport.</t> <sectionanchor="sending-a-query-over-do53"><name>Sendinganchor="sending-a-query-over-do53"> <name>Sending a Query over Do53</name> <t>For any of the supported encrypted transports<spanx style="verb">E</spanx>, if either of the following holds true,<tt>E</tt>, the recursive resolver <bcp14>SHOULD NOT</bcp14> send a query to<spanx style="verb">X</spanx><tt>X</tt> overDo53:</t> <t><list style="symbols"> <t><spanx style="verb">E-session[X]</spanx>Do53 if either of the following holds true:</t> <ul spacing="normal"> <li> <t><tt>E-session[X]</tt> is in the<spanx style="verb">established</spanx><tt>established</tt> state, or</t><t><spanx style="verb">E-status[X]</spanx></li> <li> <t><tt>E-status[X]</tt> is<spanx style="verb">success</spanx>,<tt>success</tt> and<spanx style="verb">(T0<tt>(T0 - E-last-response[X]) <persistence</spanx></t> </list></t>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 transport, and the last successful encrypted transport connection was long ago, the recursive resolver sends a query to<spanx style="verb">X</spanx><tt>X</tt> over Do53. When it does so, it inserts a handle for the query in<spanx style="verb">Do53-queries[X]</spanx>.</t><tt>Do53-queries[X]</tt>.</t> </section> <sectionanchor="receiving-a-response-over-do53"><name>Receivinganchor="receiving-a-response-over-do53"> <name>Receiving a Response over Do53</name> <t>When any response<spanx style="verb">R</spanx><tt>R</tt> (a well-formed DNS response, asynchronous timeout, asynchronous destination port unreachable,etc)etc.) for query<spanx style="verb">Q</spanx><tt>Q</tt> arrives at the recursive resolver in cleartext sent over Do53 from an authoritative server with IP address<spanx style="verb">X</spanx>,<tt>X</tt>, the recursive resolvershould:</t>should perform the following.</t> <t>If<spanx style="verb">Q</spanx><tt>Q</tt> is not in<spanx style="verb">Do53-queries[X]</spanx>:</t> <t><list style="symbols"> <t>Process <spanx style="verb">R</spanx><tt>Do53-queries[X]</tt>:</t> <ul spacing="normal"> <li> <t>process <tt>R</tt> no further (do not respond to a cleartext response to a query that is notoutstanding)</t> </list></t>outstanding).</t> </li> </ul> <t>Otherwise, if<spanx style="verb">Q</spanx><tt>Q</tt> 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<ul spacing="normal"> <li> <t>remove <tt>Q</tt> from <tt>Do53-queries[X]</tt>,</t> </li> <li> <t>discard any content from theresponseresponse, and process<spanx style="verb">R</spanx><tt>R</tt> nofurther</t> </list></t>further.</t> </li> </ul> <t>If<spanx style="verb">R</spanx><tt>R</tt> 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 resolver</t> <t>For<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<spanx style="verb">E</spanx>: <list style="symbols"> <t>If <spanx style="verb">Q</spanx><tt>E</tt>: </t> <ul spacing="normal"> <li> <t>if <tt>Q</tt> is in<spanx style="verb">E-queries[X]</spanx>: <list style="symbols"> <t>Mark <spanx style="verb">Q</spanx><tt>E-queries[X]</tt>, then </t> <ul spacing="normal"> <li> <t>mark <tt>Q</tt> as alreadyprocessed</t> </list></t> </list></t> </list></t> <t>Butprocessed.</t> </li> </ul> </li> </ul> </li> </ul> <t>However, if<spanx style="verb">R</spanx><tt>R</tt> ismalformed,malformed or a failure (e.g., a timeout or destination portunreachable):</t> <t><list style="symbols">unreachable), and</t> <ul spacing="normal"> <li> <t>if<spanx style="verb">Q</spanx><tt>Q</tt> is not in any of<spanx style="verb">any-E-queries[X]</spanx>: <list style="symbols"> <t>Treat<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 policy for unresponsive or non-compliant authoritatives, such as falling back to another authoritative server, returning<spanx style="verb">SERVFAIL</spanx><tt>SERVFAIL</tt> to the requesting client, and soon)</t> </list></t> </list></t>on).</t> </li> </ul> </li> </ul> </section> <sectionanchor="initiating-a-connection-over-encrypted-transport"><name>Initiatinganchor="initiating-a-connection-over-encrypted-transport"> <name>Initiating a Connection over Encrypted Transport</name> <t>If any<spanx style="verb">E-session[X]</spanx><tt>E-session[X]</tt> is in the<spanx style="verb">established</spanx><tt>established</tt> state, the recursive resolver <bcp14>SHOULD NOT</bcp14> initiate a new connection or resume a previous connection to<spanx style="verb">X</spanx><tt>X</tt> over Do53 or<spanx style="verb">E</spanx>,<tt>E</tt>, but should instead send queries to<spanx style="verb">X</spanx><tt>X</tt> through the existing session (see <xref target="sending"/>).</t> <t>If the recursive resolver prefers one encrypted transport over another, but only the unpreferred encrypted transport is in the<spanx style="verb">established</spanx><tt>established</tt> state, it <bcp14>MAY</bcp14> also initiate a new connection to<spanx style="verb">X</spanx><tt>X</tt> over its preferred encrypted transport while concurrently sending the query over the<spanx style="verb">established</spanx><tt>established</tt> encrypted transport<spanx style="verb">E</spanx>.</t><tt>E</tt>.</t> <t>Before considering whether to initiate a new connection over an encrypted transport, the timer should be examined, and its state possibly refreshed, for encrypted transport<spanx style="verb">E</spanx><tt>E</tt> to authoritative IP address<spanx style="verb">X</spanx>:</t> <t><list style="symbols"> <t>if <spanx style="verb">E-session[X]</spanx><tt>X</tt>.</t> <ul spacing="normal"> <li> <t>If <tt>E-session[X]</tt> is in state<spanx style="verb">pending</spanx>,<tt>pending</tt>, and</t><t><spanx style="verb">T0</li> <li> <t><tt>T0 - E-initiated[X] >E-timeout</spanx>,E-timeout</tt>, then<list style="symbols"></t> <ul spacing="normal"> <li> <t>set<spanx style="verb">E-session[X]</spanx><tt>E-session[X]</tt> to<spanx style="verb">null</spanx><tt>null</tt>, and</t> </li> <li> <t>set<spanx style="verb">E-status[X]</spanx><tt>E-status[X]</tt> to<spanx style="verb">timeout</spanx></t> </list></t> </list></t><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<spanx style="verb">X</spanx><tt>X</tt> over<spanx style="verb">E</spanx><tt>E</tt> as long as one of the following holds true:</t><t><list style="symbols"> <t><spanx style="verb">E-status[X]</spanx><ul spacing="normal"> <li> <t><tt>E-status[X]</tt> is<spanx style="verb">success</spanx>,<tt>success</tt>, or</t><t><spanx style="verb">E-status[X]</spanx></li> <li> <t><tt>E-status[X]</tt> is either<spanx style="verb">fail</spanx><tt>fail</tt> or<spanx style="verb">timeout</spanx>,<tt>timeout</tt> and<spanx style="verb">(T0<tt>(T0 - E-completed[X]) >damping</spanx>,damping</tt>, or</t><t><spanx style="verb">E-status[X]</spanx></li> <li> <t><tt>E-status[X]</tt> is<spanx style="verb">null</spanx><tt>null</tt> and<spanx style="verb">E-initiated[X]</spanx><tt>E-initiated[X]</tt> is<spanx style="verb">null</spanx></t> </list></t><tt>null</tt>.</t> </li> </ul> <t>When initiating a session to<spanx style="verb">X</spanx><tt>X</tt> over encrypted transport<spanx style="verb">E</spanx>,<tt>E</tt>, if<spanx style="verb">E-resumptions[X]</spanx><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 initialClient HelloClientHello handshake should not try to resume any session.</t> <t>When initiating a connection, the recursive resolver should take the following steps:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>set<spanx style="verb">E-initiated[X]</spanx><tt>E-initiated[X]</tt> to<spanx style="verb">T0</spanx></t><tt>T0</tt>,</t> </li> <li> <t>store a handle for the new session (which should have<spanx style="verb">pending</spanx><tt>pending</tt> state) in<spanx style="verb">E-session[X]</spanx></t><tt>E-session[X]</tt>, and</t> </li> <li> <t>insert a handle for the query that prompted this connection in<spanx style="verb">E-queries[X]</spanx>,<tt>E-queries[X]</tt>, with status<spanx style="verb">unsent</spanx><tt>unsent</tt> or<spanx style="verb">early</spanx>,<tt>early</tt>, as appropriate (see below).</t></list></t></li> </ul> <sectionanchor="early-data"><name>Earlyanchor="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 initialClient HelloClientHello in some contexts. A recursive resolver that initiates a connection over an encrypted transport according 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, according to the sending guidance in <xref target="sending"/>.</t> <t>If it does so, the status of<spanx style="verb">Q</spanx><tt>Q</tt> in<spanx style="verb">E-queries[X]</spanx><tt>E-queries[X]</tt> should be set to<spanx style="verb">early</spanx><tt>early</tt> instead of<spanx style="verb">unsent</spanx>.</t><tt>unsent</tt>.</t> </section> <sectionanchor="resumption"><name>Resumptionanchor="resumption"> <name>Resumption Tickets</name> <t>When initiating a new connection (whether by resuming an old session or not), the recursive resolver <bcp14>SHOULD</bcp14> request a session resumption ticket 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><tt>E-resumptions[X]</tt>.</t> </section> <sectionanchor="recursive-sni"><name>Serveranchor="recursive-sni"> <name>Server Name Indication</name> <t>For modern encrypted transports like TLS 1.3, most client implementations expect to send a Server Name Indication (SNI) in theClient Hello.</t>ClientHello.</t> <t>There are two complications with selecting or sending an SNI in this unilateralprobing:</t> <t><list style="symbols">probing.</t> <ul spacing="normal"> <li> <t>Some authoritative servers are known by more than one name; selecting a single name to use for a given connection may be difficult or impossible.</t> </li> <li> <t>In most configurations, the contents of the SNI fieldisare exposed on the wire to a passive adversary. This potentially reveals additional information about which query is beingmade,made based on the NS of the query itself.</t></list></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 authoritative server when attempting encrypted transport.</t> <t>If the recursive resolver needs to send an SNI to the authoritative server for some reason not found in this document, using EncryptedClient HelloClientHello (<xref target="I-D.ietf-tls-esni"/>) would reduce leakage.</t> </section> <sectionanchor="authoritative-server-authentication"><name>Authoritativeanchor="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 presented by the server. If the client cannot verify the server's identity, it <bcp14>MAY</bcp14> use that information for reporting, logging, or other analysispurposes. Butpurposes; however, it <bcp14>MUST NOT</bcp14> reject the connection due to the authentication failure, as the result would be falling back to cleartext, which would leak the content of the session to a passive network monitor.</t> </section> </section> <sectionanchor="establish-encrypted"><name>Establishinganchor="establish-encrypted"> <name>Establishing an Encrypted Transport Connection</name> <t>When an encrypted transport connection actually completes (e.g., the TLS handshake completes) at time<spanx style="verb">T1</spanx>,<tt>T1</tt>, the recursive resolver sets<spanx style="verb">E-completed[X]</spanx><tt>E-completed[X]</tt> to<spanx style="verb">T1</spanx><tt>T1</tt> and does thefollowing:</t>following.</t> <t>If the handshake completedsuccessfully:</t> <t><list style="symbols"> <t>update <spanx style="verb">E-session[X]</spanx>successfully, the recursive resolver:</t> <ul spacing="normal"> <li> <t>updates <tt>E-session[X]</tt> so that it is in state<spanx 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">T1</spanx></t> <t>set <spanx style="verb">E-completed[X]</spanx><tt>established</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<spanx style="verb">T1</spanx></t><tt>T1</tt>, and</t> </li> <li> <t>for each query<spanx style="verb">Q</spanx><tt>Q</tt> in<spanx style="verb">E-queries[X]</spanx>: <list style="symbols"><tt>E-queries[X]</tt>: </t> <ul spacing="normal"> <li> <t>if early data was accepted and<spanx style="verb">Q</spanx><tt>Q</tt> is<spanx style="verb">early</spanx>, <list style="symbols"> <t>set<tt>early</tt>, then </t> <ul spacing="normal"> <li> <t>sets the status of<spanx style="verb">Q</spanx><tt>Q</tt> to<spanx style="verb">sent</spanx></t> </list></t> <t>otherwise: <list style="symbols"> <t>send <spanx style="verb">Q</spanx><tt>sent</tt>.</t> </li> </ul> </li> <li> <t>Otherwise: </t> <ul spacing="normal"> <li> <t>sends <tt>Q</tt> through the session (see <xreftarget="sending"/>),target="sending"/>) andsetsets the status of<spanx style="verb">Q</spanx><tt>Q</tt> to<spanx style="verb">sent</spanx></t> </list></t> </list></t> </list></t><tt>sent</tt>.</t> </li> </ul> </li> </ul> </li> </ul> </section> <sectionanchor="failing-to-establish-an-encrypted-transport-connection"><name>Failinganchor="failing-to-establish-an-encrypted-transport-connection"> <name>Failing to Establish an Encrypted Transport Connection</name> <t>If, at time<spanx style="verb">T2</spanx><tt>T2</tt>, an encrypted transport handshake completes with a failure (e.g., a TLSalert),</t> <t><list style="symbols">alert):</t> <ul spacing="normal"> <li> <t>set<spanx style="verb">E-session[X]</spanx><tt>E-session[X]</tt> to<spanx style="verb">null</spanx></t><tt>null</tt>,</t> </li> <li> <t>set<spanx style="verb">E-status[X]</spanx><tt>E-status[X]</tt> to<spanx style="verb">fail</spanx></t><tt>fail</tt>,</t> </li> <li> <t>set<spanx style="verb">E-completed[X]</spanx><tt>E-completed[X]</tt> to<spanx style="verb">T2</spanx></t><tt>T2</tt>, and</t> </li> <li> <t>for each query<spanx style="verb">Q</spanx><tt>Q</tt> in<spanx style="verb">E-queries[X]</spanx>: <list style="symbols"><tt>E-queries[X]</tt>: </t> <ul spacing="normal"> <li> <t>if<spanx style="verb">Q</spanx><tt>Q</tt> is not present in any other<spanx style="verb">any-E-queries[X]</spanx><tt>any-E-queries[X]</tt> or in<spanx style="verb">Do53-queries[X]</spanx>,<tt>Do53-queries[X]</tt>, add<spanx style="verb">Q</spanx><tt>Q</tt> to<spanx style="verb">Do53-queries[X]</spanx><tt>Do53-queries[X]</tt> and send query<spanx style="verb">Q</spanx><tt>Q</tt> to<spanx style="verb">X</spanx><tt>X</tt> over Do53.</t></list></t> </list></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<spanx style="verb">X</spanx>.<tt>X</tt>. It will retry encrypted transport to<spanx style="verb">X</spanx><tt>X</tt> once the<spanx style="verb">damping</spanx><tt>damping</tt> timer has elapsed.</t> </section> <sectionanchor="e-failure"><name>Encryptedanchor="e-failure"> <name>Encrypted Transport Failure</name> <t>Once established, an encrypted transport might fail for a number of reasons (e.g., decryptionfailure,failure or improper protocol sequence).</t> <t>If this happens:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>set<spanx style="verb">E-session[X]</spanx><tt>E-session[X]</tt> to<spanx style="verb">null</spanx></t><tt>null</tt>,</t> </li> <li> <t>set<spanx style="verb">E-status[X]</spanx><tt>E-status[X]</tt> to<spanx style="verb">fail</spanx></t><tt>fail</tt>, and</t> </li> <li> <t>for each query<spanx style="verb">Q</spanx><tt>Q</tt> in<spanx style="verb">E-queries[X]</spanx>: <list style="symbols"><tt>E-queries[X]</tt>: </t> <ul spacing="normal"> <li> <t>if<spanx style="verb">Q</spanx><tt>Q</tt> is not present in any other<spanx style="verb">any-E-queries[X]</spanx><tt>any-E-queries[X]</tt> or in<spanx style="verb">Do53-queries[X]</spanx>,<tt>Do53-queries[X]</tt>, add<spanx style="verb">Q</spanx><tt>Q</tt> to<spanx style="verb">Do53-queries[X]</spanx><tt>Do53-queries[X]</tt> and send query<spanx style="verb">Q</spanx><tt>Q</tt> to<spanx style="verb">X</spanx><tt>X</tt> over Do53.</t></list></t> </list></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<spanx style="verb">X</spanx>.<tt>X</tt>. It will retry encrypted transport to<spanx style="verb">X</spanx><tt>X</tt> once the<spanx style="verb">damping</spanx><tt>damping</tt> timer has elapsed.</t> </section> <sectionanchor="e-shutdown"><name>Handlinganchor="e-shutdown"> <name>Handling Clean Shutdown of an Encrypted Transport Connection</name> <t>At time<spanx style="verb">T3</spanx>,<tt>T3</tt>, the recursive resolver may find that authoritative server<spanx style="verb">X</spanx><tt>X</tt> cleanly closes an existing outstanding connection (most likely due to resource exhaustion, see <xref target="authoritative-resource-exhaustion"/>).</t> <t>When this happens:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>set<spanx style="verb">E-session[X]</spanx><tt>E-session[X]</tt> to<spanx style="verb">null</spanx></t><tt>null</tt>, and</t> </li> <li> <t>for each query<spanx style="verb">Q</spanx><tt>Q</tt> in<spanx style="verb">E-queries[X]</spanx>: <list style="symbols"><tt>E-queries[X]</tt>: </t> <ul spacing="normal"> <li> <t>if<spanx style="verb">Q</spanx><tt>Q</tt> is not present in any other<spanx style="verb">any-E-queries[X]</spanx><tt>any-E-queries[X]</tt> or in<spanx style="verb">Do53-queries[X]</spanx>,<tt>Do53-queries[X]</tt>, add<spanx style="verb">Q</spanx><tt>Q</tt> to<spanx style="verb">Do53-queries[X]</spanx><tt>Do53-queries[X]</tt> and send query<spanx style="verb">Q</spanx><tt>Q</tt> to<spanx style="verb">X</spanx><tt>X</tt> over Do53.</t></list></t> </list></t></li> </ul> </li> </ul> <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 style="verb">X</spanx>.<tt>X</tt>. Any subsequent query to<spanx style="verb">X</spanx><tt>X</tt> will retry the encrypted connection promptly.</t> </section> <sectionanchor="sending"><name>Sendinganchor="sending"> <name>Sending a Query over Encrypted Transport</name> <t>When sending a query to an authoritative server over encrypted transport at time<spanx style="verb">T4</spanx>,<tt>T4</tt>, the recursive resolver should take a few reasonable steps to ensure privacy andefficiency.</t> <t>Afterefficiency. After sending query<spanx style="verb">Q</spanx>,<tt>Q</tt>, the recursive resolvershould ensureshould:</t> <ul> <li>Ensure that<spanx style="verb">Q</spanx>'s<tt>Q</tt>'s state in<spanx style="verb">E-queries[X]</spanx><tt>E-queries[X]</tt> is set to<spanx style="verb">sent</spanx>.</t> <t>The recursive resolver also sets <spanx style="verb">E-last-activity[X]</spanx><tt>sent</tt>.</li> <li>Set <tt>E-last-activity[X]</tt> to<spanx style="verb">T4</spanx>.</t> <t>In addition, the<tt>T4</tt>.</li> </ul> <t>The recursive resolver should also consider the guidance in the followingsections.</t>subsections.</t> <sectionanchor="pad-queries-to-mitigate-traffic-analysis"><name>Padanchor="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>SHOULD</bcp14> use a sensible padding mechanism for all queries it sends. Specifically, a DoT client <bcp14>SHOULD</bcp14> useEDNS(0)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 can be found in <xref target="RFC8467"/>.</t> </section> <sectionanchor="send-queries-in-separate-channels"><name>Sendanchor="send-queries-in-separate-channels"> <name>Send Queries in Separate Channels</name> <t>When multiple queries are multiplexed on a single encrypted transport to a single authoritative server, the recursive resolver <bcp14>SHOULD</bcp14> pipeline 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 <xref section="6.2.1.1" sectionFormat="of" target="RFC7766"/> (for DoT) and <xref section="5.6" sectionFormat="of" target="RFC9250"/> (for DoQ).</t> </section> </section> <sectionanchor="receiving-encrypted"><name>Receivinganchor="receiving-encrypted"> <name>Receiving a Response over Encrypted Transport</name> <t>Even though session-level events on encrypted transports like clean shutdown (see <xref target="e-shutdown"/>) or encrypted transport failure (see <xref target="e-failure"/>) can happen, some events happen on encryptedtransporttransports that are specific to aquery,query and are not session-wide. This subsection describes how the recursive resolver deals with events related to a specific query.</t> <t>When a query-specific response<spanx style="verb">R</spanx><tt>R</tt> (a well-formed DNS response or an asynchronous timeout) associated with query<spanx style="verb">Q</spanx><tt>Q</tt> arrives at the recursive resolver over encrypted transport<spanx style="verb">E</spanx><tt>E</tt> from an authoritative server with IP address<spanx style="verb">X</spanx><tt>X</tt> at time<spanx style="verb">T5</spanx>,<tt>T5</tt>, the recursive resolvershould:</t>should perform the following.</t> <t>If<spanx style="verb">Q</spanx><tt>Q</tt> is not in<spanx style="verb">E-queries[X]</spanx>:</t> <t><list style="symbols"> <t>Discard<tt>E-queries[X]</tt>:</t> <ul spacing="normal"> <li> <t>discard the response and process<spanx style="verb">R</spanx><tt>R</tt> no further (do not respond to an encrypted response to a query that is notoutstanding)</t> </list></t>outstanding).</t> </li> </ul> <t>Otherwise:</t><t><list style="symbols"> <t>Remove <spanx style="verb">Q</spanx> from <spanx style="verb">E-queries[X]</spanx></t> <t>Set <spanx style="verb">E-last-activity[X]</spanx> to <spanx style="verb">T5</spanx></t> <t>Set <spanx style="verb">E-last-response[X]</spanx> to <spanx style="verb">T5</spanx></t> </list></t><ul spacing="normal"> <li> <t>remove <tt>Q</tt> from <tt>E-queries[X]</tt>,</t> </li> <li> <t>set <tt>E-last-activity[X]</tt> to <tt>T5</tt>, and</t> </li> <li> <t>set <tt>E-last-response[X]</tt> to <tt>T5</tt>.</t> </li> </ul> <t>If<spanx style="verb">Q</spanx><tt>Q</tt> was marked as already processed:</t><t><list style="symbols"> <t>Discard<ul spacing="normal"> <li> <t>discard the response and process the response nofurther</t> </list></t>further.</t> </li> </ul> <t>If<spanx style="verb">R</spanx><tt>R</tt> is a well-formed DNS response:</t><t><list style="symbols"> <t><spanx style="verb">R</spanx> is further processed by the recursive resolver</t> <t>For<ul spacing="normal"> <li> <t>process <tt>R</tt> further, and</t> </li> <li> <t>for each supported encrypted transport<spanx style="verb">N</spanx><tt>N</tt> other than<spanx style="verb">E</spanx>: <list style="symbols"> <t>If <spanx style="verb">Q</spanx><tt>E</tt>: </t> <ul spacing="normal"> <li> <t>if <tt>Q</tt> is in<spanx style="verb">N-queries[X]</spanx>: <list style="symbols"> <t>Mark <spanx style="verb">Q</spanx><tt>N-queries[X]</tt>, then </t> <ul spacing="normal"> <li> <t>mark <tt>Q</tt> as alreadyprocessed</t> </list></t> </list></t>processed.</t> </li> </ul> </li> </ul> </li> <li> <t>If<spanx style="verb">Q</spanx><tt>Q</tt> is in<spanx style="verb">Do53-queries[X]</spanx>: <list style="symbols"> <t>Mark <spanx style="verb">Q</spanx><tt>Do53-queries[X]</tt>: </t> <ul spacing="normal"> <li> <t>mark <tt>Q</tt> as alreadyprocessed</t> </list></t> </list></t> <t>Butprocessed.</t> </li> </ul> </li> </ul> <t>However, if<spanx style="verb">R</spanx><tt>R</tt> ismalformed,malformed or a failure (e.g.,timeout):</t> <t><list style="symbols"> <t>If <spanx style="verb">Q</spanx>timeout), and</t> <ul spacing="normal"> <li> <t>if <tt>Q</tt> is not in<spanx style="verb">Do53-queries[X]</spanx><tt>Do53-queries[X]</tt> or in any of<spanx style="verb">any-E-queries[X]</spanx>: <list style="symbols"> <t>Treat<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 policy for unresponsive or non-compliantauthoritatives,authoritative servers, such as falling back to another authoritative server, returning<spanx style="verb">SERVFAIL</spanx><tt>SERVFAIL</tt> to the requesting client, and soon)</t> </list></t> </list></t>on).</t> </li> </ul> </li> </ul> </section> <sectionanchor="recursive-resource-exhaustion"><name>Resourceanchor="recursive-resource-exhaustion"> <name>Resource Exhaustion</name> <t>To keep resources under control, a recursive resolver should proactively manage outstanding encrypted 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> <t>Even with sensible connection management, a recursive resolver doing unilateral probing may find resources unexpectedlyscarce,scarce and may need to close some outstanding connections.</t> <t>In such a situation, the recursive resolver <bcp14>SHOULD</bcp14> use a reasonable prioritization scheme to close outstanding connections.</t> <t>One reasonable prioritization scheme wouldbe:</t> <t><list style="symbols"> <t>closebe to close outstanding<spanx style="verb">established</spanx><tt>established</tt> sessions based on<spanx style="verb">E-last-activity[X]</spanx> (oldest<tt>E-last-activity[X]</tt> (i.e, the oldest timestamp gets closedfirst)</t> </list></t>first).</t> <t>Note that when resources are limited, a recursive resolver following this guidance may also choose not to initiate new connections for encrypted transport.</t> </section> <sectionanchor="maintaining-connections"><name>Maintaininganchor="maintaining-connections"> <name>Maintaining Connections</name> <t>Some recursive resolvers looking to amortize connection costs andtominimize latency <bcp14>MAY</bcp14> choose to synthesize queries to a particular authoritative server to keep an encrypted transport session active.</t> <t>A recursive resolver that adopts this approach should try to align the synthesized queries with other optimizations. For example, a recursive resolver that "pre-fetches" a particular resource record to keep its cache "hot" can send that query over an established encrypted transport session.</t> </section> <sectionanchor="additional-tuning"><name>Additionalanchor="additional-tuning"> <name>Additional Tuning</name> <t>A recursive resolver's state table for an authoritative server can contain additional information beyond what is described above. The recursive resolver might use that additional state to change the way it interacts with the authoritative server in the future. Some examples of additionalstate include:</t> <t><list style="symbols">states include the following.</t> <ul spacing="normal"> <li> <t>Whether the server accepts "early data" over a transport such asDoQ;</t>DoQ.</t> </li> <li> <t>Whether the server fails to respond to queries after the handshakesucceeds;</t>succeeds.</t> </li> <li> <t>Tracking theround tripround-trip time of queries to theserver;</t>server.</t> </li> <li> <t>Tracking the number of timeouts (compared to the number of successful queries).</t></list></t></li> </ul> </section> </section> </section> <sectionanchor="iana-considerations"><name>IANAanchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANAconsiderations.</t>actions.</t> </section> <sectionanchor="privacy-considerations"><name>Privacyanchor="privacy-considerations"> <name>Privacy Considerations</name> <sectionanchor="sni-considerations"><name>Serveranchor="sni-considerations"> <name>Server Name Indication</name> <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 handshake leaks information about the intended query to a passive network observer.</t> <t>In particular, if two different zones refer to the same nameserver IP addresses viadifferently-nameddifferently named NS records, a passive network observer can distinguish the queries to one zone from the queries to the other.</t> <t>Omitting SNI entirely, or using EncryptedClient HelloClientHello to hide the intended SNI, avoids this additional leakage. However, a series of queries that leak this information is still an improvement over cleartext.</t> </section> <sectionanchor="modelling-the-probability-of-encryption"><name>Modellinganchor="modeling-the-probability-of-encryption"> <name>Modeling the Probability of Encryption</name> <t>Given that there are many parameter choices that can be made by recursive resolvers and authoritative servers, it is reasonable to consider the probability that queries would be encrypted. Such a measurement would also certainly be affected by the types of queries being sent by the recursive resolver,whichwhich, inturnturn, is also related to the types of queries that are sent to the recursive resolver by the stub resolvers and forwarders 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 because it would help assess the overall DNS privacy value of implementing the protocol. Thus, it would be useful if recursive resolvers and authoritative servers reported percentages of queries sent and received over the different transports.</t> </section> </section> <sectionanchor="security-considerations"><name>Securityanchor="security-considerations"> <name>Security Considerations</name> <t>The guidance in this document provides defense against passive network monitors for most queries. It does not defend against active attackers. It can also leak some queries and their responses due to"happy eyeballs"Happy Eyeballs optimizations (<xref target="RFC8305"/>) when the recursive resolver's cache is cold.</t> <t>Implementation of the guidance in this document should increase deployment of opportunistic encrypted DNS transport between recursive resolvers and authoritative servers at little operational risk.</t> <t>However, implementers cannot rely on the guidance in this document for robust defense against activeattackers, butattackers: they should treat it as a stepping stone en route to stronger defense.</t> <t>In particular, a recursive resolver followingthisthe guidance in this document can easily be forced 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 the recursive resolver would not defend against or detect due to lack of server authentication. Defending against these attacks without risking additional unexpected protocol failures 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 ecosystem. A privacy-preserving recursive resolver should adopt other practices as well, such as QNAME minimization (<xref target="RFC9156"/>), local root zone (<xref target="RFC8806"/>),etc,etc., to reduce the overall leakage of query information that could infringe on the client's privacy.</t> </section> <sectionanchor="operational-considerations"><name>Operationalanchor="operational-considerations"> <name>Operational Considerations</name> <t>As recursive resolvers implement this protocol, authoritative servers will see more probing on port 853 of IP addresses that are associated with NS records. Such probing of an authoritative server should generally not cause any significantproblems: ifproblems. If the authoritative server is not supporting this protocol, it will not respond on port853, and853; if it is supporting this protocol, it will act accordingly.</t> <t>However, a system that is a public recursive resolver that supports DoT and/or 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) or intentional. In such a case, a recursive resolver following this protocol will look for authoritative answers to ports 53 and 853 on that IPaddress, andaddress. Additionally, the DNS server answering on port 853 would need to be able to differentiate queries for recursive answers from queries for authoritativeanswers, for exampleanswers (e.g., by having the authoritative server handle all queries that have the Recursion Desired (RD) flagunset.</t>unset).</t> <t>As discussed in <xref target="security-considerations"/>, the protocol described in this document provides no defense against active attackers. On a network where a captive portal is operating, some communications may be activelyintercepted, e.g.,intercepted (e.g., when the network tries to redirect a user to complete an interaction with a captive portalserver.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 check policy has been satisfied.</t> </section><section anchor="acknowledgements"><name>Acknowledgements</name> <t>Many people contributed to the development of this document beyond the authors, 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> <back> <displayreference target="I-D.ietf-dnsop-dns-error-reporting" to="DNS-ER"/> <displayreference target="I-D.ietf-tls-esni" to="TLS-ECH"/> <references> <name>References</name> <referencestitle='Normative References'anchor="sec-normative-references"><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 document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="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 confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS 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 and 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 provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t> <t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t> </abstract> </front> <seriesInfo name="RFC" value="7858"/> <seriesInfo name="DOI" value="10.17487/RFC7858"/> </reference> <reference anchor="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 in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t> </abstract> </front> <seriesInfo name="RFC" value="7301"/> <seriesInfo name="DOI" value="10.17487/RFC7301"/> </reference><name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> </references> <referencestitle='Informative References'anchor="sec-informative-references"><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 context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on 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 in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1035"/> <seriesInfo name="DOI" value="10.17487/RFC1035"/> </reference> <reference anchor="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 DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t> </abstract> </front> <seriesInfo name="RFC" value="8484"/> <seriesInfo name="DOI" value="10.17487/RFC8484"/> </reference> <reference anchor="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 DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.</t> </abstract> </front> <seriesInfo name="RFC" value="8467"/> <seriesInfo name="DOI" value="10.17487/RFC8467"/> </reference> <reference anchor="RFC8305"> <front> <title>Happy Eyeballs Version 2: Better Connectivity Using Concurrency</title> <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 hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms 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 (TLS) 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 transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.</t> </abstract> </front> <seriesInfo name="RFC" value="7766"/> <seriesInfo name="DOI" value="10.17487/RFC7766"/> </reference> <reference anchor="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 improve 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 RFC 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 responses 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 to 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 zone 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 mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server 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 Entities (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 security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted 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). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential 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 misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating recursive resolver to automatically signal an error to a monitoring agent specified by the authoritative server. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-dns-error-reporting-06"/> </reference> <reference anchor="RFC9102"> <front> <title>TLS DNSSEC Chain Extension</title> <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<name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7672.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7830.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8460.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8461.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8467.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9102.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9156.xml"/> <!-- [I-D.ietf-tls-esni] IESG state I-D Exists --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-esni.xml"/> <!-- [I-D.ietf-dnsop-dns-error-reporting] IESG state Waiting forthe in-band transport 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 TLS 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 denial-of-existence proof that can be validated.</t> <t>This experimental extension is developed outside the IETF and is published 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>AD Go-Ahead --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-dns-error-reporting.xml"/> </references> </references><?line 671?> <section anchor="early-implementations"><name>Early Implementations</name> <t>[ RFC Editor: please remove this section before publication ]</t> <t>This appendix lists some of the implementations of the protocol as it finished 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><sectionanchor="assessing-the-experiment"><name>Assessinganchor="assessing-the-experiment"> <name>Assessing the Experiment</name> <t>This document ispublished asanexperimentalExperimental RFC. In order to assess the success of the experiment, some key metrics could be collected by the technical community about the deployment of the protocol in this document. These metrics will be collected in recursive resolvers, authoritative servers, and the networks containing them. Some key metricsinclude:</t> <t><list style="symbols">include the following.</t> <ul spacing="normal"> <li> <t>Comparison of the CPU and memory use between Do53 and encryptedtransports</t>transports.</t> </li> <li> <t>Comparison of the query response rates between Do53 and encryptedtransports</t>transports.</t> </li> <li> <t>Measurement of server authentication successes andfailures</t>failures.</t> </li> <li> <t>Measurement and descriptions of observed attack traffic, ifany</t>any.</t> </li> <li> <t>Comparison of transactional bandwidth (ingress/egress, packets per second, bytes per second) between Do53 and encryptedtransports</t> </list></t>transports.</t> </li> </ul> </section> <sectionanchor="adding-auth"><name>Defense Againstanchor="adding-auth"> <name>Defense against Active Attackers</name> <t>The protocol described in this document provides no defense against active attackers. 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 recursive resolver that wants to prevent an active attack on communication between it and an authoritative server that has committed to offering encrypted DNS transport. An inherent part of this use case is that the recursive resolver would want to respond with a<spanx style="verb">SERVFAIL</spanx><tt>SERVFAIL</tt> response to its client if it cannot make an authenticated encrypted connection to any of the authoritative nameservers 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"/>) has 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>So<t>Therefore, such a future protocol would need at least three major distinctions from the protocol described in this document:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>A signaling mechanism that tells the recursive resolver that the authoritative server intends to offer authenticatedencryption</t>encryption.</t> </li> <li> <t>Authentication of the authoritativeserver</t>server.</t> </li> <li> <t>A way to combine defense against an active attacker with the defenses described in thisdocument</t> </list></t>document.</t> </li> </ul> <t>This can be thought of as a DNS analog to <xreftarget="MTA-STS"/>target="RFC8461"/> or <xreftarget="DANE-SMTP"/>.</t>target="RFC7672"/>.</t> <sectionanchor="signaling-mechanism-properties"><name>Signalinganchor="signaling-mechanism-properties"> <name>Signaling Mechanism Properties</name> <t>To defend against an active attacker, the signaling mechanism needs to be able to indicate that the recursive resolver should"fail closed"fail closed if it cannot authenticate the server for a particular query.</t> <t>The signaling mechanism itself would have to be resistant to downgrade attacks 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 on the IP addresses of the client and server, signaled intent to offer encrypted transport is more likely to be scoped by the queried zone in theDNS,DNS or by the nameserver name than by the IP address.</t> <t>A reasonable authoritative server operator or zone administrator probably doesn't want to risk breaking anything when they first enable the signal. Therefore, a signaling mechanism should probably also offer a means to report problems to the authoritative server operator without the client failing closed. Such a mechanism is likely to be similar to those described in <xreftarget="TLSRPT"/>target="RFC8460"/> or <xreftarget="DNS-Error-Reporting"/>.</t>target="I-D.ietf-dnsop-dns-error-reporting"/>.</t> </section> <sectionanchor="authentication-of-authoritative-server"><name>Authenticationanchor="authentication-of-authoritative-server"> <name>Authentication of AuthoritativeServer</name>Servers</name> <t>Forms of server authentication might include:</t><t><list style="symbols"> <t>an<ul spacing="normal"> <li> <t>An X.509Certificatecertificate issued by awidely-knownwidely known certification authority associated with the common NS names used for this authoritativeserver</t> <t>DANE authenticationserver.</t> </li> <li> <t>DNS-Based Authentication of Named Entities (DANE) (to avoid infinite recursion, the DNS records necessary to authenticate could be transmitted in the TLS handshake using the DNSSECChain Extensionchain extension (see <xreftarget="RFC9102"/>))</t> </list></t>target="RFC9102"/>)).</t> </li> </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> </section> <sectionanchor="combining-protocols"><name>Combininganchor="combining-protocols"> <name>Combining Protocols</name> <t>If this protocol gains reasonable adoption, and a newer protocol that can offer defense against an active attacker were available, deployment is likely to be staggered and incomplete. This means that an operator thatwantwants to maximize confidentiality for their users will want to use both protocols together.</t> <t>Any new stronger protocol should consider how it interacts with the opportunistic protocol defined here, so that operators are not faced with the choice between widespread opportunistic protection against passive attackers (this document) and morenarrowly-targetednarrowly targeted protection against active attackers.</t> </section> </section> <sectionanchor="document-considerations"><name>Document Considerations</name> <t>[ RFC Editor: please remove this section before publication ]</t> <section anchor="document-history"><name>Document History</name> <section anchor="substantive-changes-from-12-to-13"><name>Substantive Changes from -12 to -13</name> <t><list style="symbols"> <t>Changes based on IESG review</t> </list></t> </section> <section anchor="substantive-changes-from-11-to-12"><name>Substantive Changes from -11 to -12</name> <t><list style="symbols"> <t>Editorial changes received during IETF Last Call</t> </list></t> </section> <section anchor="substantive-changes-from-10-to-11"><name>Substantive Changes from -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 from -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 from -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 from -07 to -08</name> <t><list style="symbols"> <t>Changed status to Experimental</t> <t>Added operational considerations section</t>anchor="acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>Manymany editorial updates</t> </list></t> </section> <section anchor="substantive-changes-from-06-to-07"><name>Substantive Changes from -06 to -07</name> <t><list style="symbols"> <t>Updated how to handle responses from encrypted transports that are slower that Do53</t> </list></t> </section> <section anchor="substantive-changes-from-05-to-06"><name>Substantive Changes from -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 failed</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 from -03 to -04</name> <t><list style="symbols"> <t>Clarified that "completed handshake" in Table 2 also includes resumed sessions.</t> <t>In Section 4.6.1, specified not to use Do53 even when the last successful connection is far in the past.</t> <t>In Section 4.6.3, clarified that an established connection in the established state should not be resumed prematurely.</t> </list></t> </section> <section anchor="substantive-changes-from-02-to-03"><name>Substantive Changes from -02people contributed to-03</name> <t><list style="symbols"> <t>Added an Additional Tuning section on recursive resolvers recording other data 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 recursive 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 modellingtheprobabilitydevelopment ofencryption as a future task.</t> </list></t> </section> <section anchor="substantive-changes-from-01-to-02"><name>Substantive Changes from -01 to -02</name> <t><list style="symbols"> <t>Removed EDNS Client Subnet recommendations from the probing policy: recursive resolvers implementing the guidance provided inthisdraft intend to enhance privacy for their users' queries, and although ECS is a valuable feature, it represents a privacy risk. Therefore, a futuredocumentencompassing a "how to add privacy" approach could serve for better discussion on this discrepancy (thank you Puneet Sood!).</t> <t>Added text on padding queries and responses to mitigate traffic analysis (thank 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 from -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 comparison with persistence</t> </list></t> </section> <section anchor="substantive-changes-from-01-to-02-now-draft-ietf-dprive-unilateral-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 servebeyond thesame 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-from-00-to-01"><name>draft-dkgjsal-dprive-unilateral-probing Substantive Changes from -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 changing answers</t> <t>Document ALPNauthors, including <contact fullname="Alexander Mayrhofer"/>, <contact fullname="Brian Dickson"/>, <contact fullname="Christian Huitema"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Eric Nygren"/>, <contact fullname="Erik Kline"/>, <contact fullname="Florian Obser"/>, <contact fullname="Haoyu Song"/>, <contact fullname="Jim Reid"/>, <contact fullname="Kris Shrishak"/>, <contact fullname="Peter Thomassen"/>, <contact fullname="Peter van Dijk"/>, <contact fullname="Ralf Weber"/>, <contact fullname="Rich Salz"/>, <contact fullname="Robert Evans"/>, <contact fullname="Sara Dickinson"/>, <contact fullname="Scott Hollenbeck"/>, <contact fullname="Stephane Bortzmeyer"/>, <contact fullname="Yorgos Thessalonikefs"/>, andport numbers</t> <t>Justify sorting recursive resolver state by authoritative IP address</t> </list></t> </section> </section>the DPRIVE Working Group.</t> </section> </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>