doc: Add RFC documents

1 files changed, 1355 insertions, 0 deletions

diff --git a/doc/rfc/rfc9539.txt b/doc/rfc/rfc9539.txt
new file mode 100644
index 0000000..2859bb1
--- /dev/null
+++ b/doc/rfc/rfc9539.txt
@@ -0,0 +1,1355 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                D. K. Gillmor, Ed.
+Request for Comments: 9539                                          ACLU
+Category: Experimental                                   J. Salazar, Ed.
+ISSN: 2070-1721                                                         
+                                                         P. Hoffman, Ed.
+                                                                   ICANN
+                                                           February 2024
+
+
+            Unilateral Opportunistic Deployment of Encrypted
+                     Recursive-to-Authoritative DNS
+
+Abstract
+
+   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.  The protections 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.
+
+   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 against
+   more-powerful attacks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are candidates for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9539.
+
+Copyright Notice
+
+   Copyright (c) 2024 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+     1.2.  Terminology
+   2.  Priorities
+     2.1.  Minimizing Negative Impacts
+     2.2.  Protocol Choices
+   3.  Guidance for Authoritative Servers
+     3.1.  Pooled Authoritative Servers behind a Load Balancer
+     3.2.  Authentication
+     3.3.  Server Name Indication
+     3.4.  Resource Exhaustion
+     3.5.  Pad Responses to Mitigate Traffic Analysis
+   4.  Guidance for Recursive Resolvers
+     4.1.  High-Level Overview
+     4.2.  Maintaining Authoritative State by IP Address
+     4.3.  Overall Recursive Resolver Settings
+     4.4.  Recursive Resolver Requirements
+     4.5.  Authoritative Server Encrypted Transport Connection State
+     4.6.  Probing Policy
+       4.6.1.  Sending a Query over Do53
+       4.6.2.  Receiving a Response over Do53
+       4.6.3.  Initiating a Connection over Encrypted Transport
+       4.6.4.  Establishing an Encrypted Transport Connection
+       4.6.5.  Failing to Establish an Encrypted Transport Connection
+       4.6.6.  Encrypted Transport Failure
+       4.6.7.  Handling Clean Shutdown of an Encrypted Transport
+               Connection
+       4.6.8.  Sending a Query over Encrypted Transport
+       4.6.9.  Receiving a Response over Encrypted Transport
+       4.6.10. Resource Exhaustion
+       4.6.11. Maintaining Connections
+       4.6.12. Additional Tuning
+   5.  IANA Considerations
+   6.  Privacy Considerations
+     6.1.  Server Name Indication
+     6.2.  Modeling the Probability of Encryption
+   7.  Security Considerations
+   8.  Operational Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Appendix A.  Assessing the Experiment
+   Appendix B.  Defense against Active Attackers
+     B.1.  Signaling Mechanism Properties
+     B.2.  Authentication of Authoritative Servers
+     B.3.  Combining Protocols
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This document aims to provide guidance to DNS implementers and
+   operators who want to simply enable protection against passive
+   network observers.
+
+   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 [RFC7435]), that is,
+   encrypting things that would otherwise be in the clear, without
+   interfering with or weakening stronger forms of security.
+
+   This document also briefly introduces (but does not try to specify)
+   how a future protocol might permit defense against an active attacker
+   in Appendix B.
+
+   The protocol described here offers three concrete advantages to the
+   DNS ecosystem:
+
+   *  Protection from passive attackers of DNS queries in transit
+      between recursive and authoritative servers.
+
+   *  A road map for gaining real-world experience at scale with
+      encrypted protections of this traffic.
+
+   *  A bridge to some possible future protection against a more
+      powerful attacker.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+1.2.  Terminology
+
+   Unilateral:  Capable of opportunistic probing without external
+      coordination with any of the other parties.
+
+   Do53:  DNS over port 53 ([RFC1035]) for traditional cleartext
+      transport.
+
+   DoQ:  DNS over QUIC ([RFC9250]).
+
+   DoT:  DNS over TLS ([RFC7858]).
+
+   Encrypted transports:  DoQ and DoT, collectively.
+
+2.  Priorities
+
+   The protocol described in this document was developed with two
+   priorities: minimizing negative impacts and retaining flexibility in
+   the underlying encrypted transport protocol.
+
+2.1.  Minimizing Negative Impacts
+
+   The protocol described in this document aims to minimize potentially
+   negative impacts caused by the probing of encrypted transports for
+   the systems that adopt the protocol, for the parties that those
+   systems communicate with, and for uninvolved third parties.  The
+   negative impacts that this protocol specifically tries to minimize
+   are:
+
+   *  excessive bandwidth use,
+
+   *  excessive use of computational resources (CPU and memory in
+      particular), and
+
+   *  the potential for amplification attacks (where DNS resolution
+      infrastructure is wielded as part of a DoS attack).
+
+2.2.  Protocol Choices
+
+   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 ([RFC7858]) says that it:
+
+   |  ...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.
+
+   It further says:
+
+   |  It might work equally between recursive clients and authoritative
+   |  servers...
+
+   The DoQ specification ([RFC9250]) says:
+
+   |  For the recursive to authoritative scenario, authentication
+   |  requirements are unspecified at the time of writing and are the
+   |  subject of ongoing work in the DPRIVE WG.
+
+   The protocol described in this document specifies the use of DoT and
+   DoQ without authentication of the server.
+
+   This document does not pursue the use of DNS over HTTPS, commonly
+   called "DoH" ([RFC8484]), in this context because a DoH client needs
+   to know the path part of a DoH endpoint URL.  Currently, there are no
+   mechanisms for a DNS recursive resolver to predict the path on its
+   own, in an 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.
+
+3.  Guidance for Authoritative Servers
+
+   The protocol described in this document is OPTIONAL for authoritative
+   servers.  An authoritative server choosing to implement the protocol
+   described in this document MUST implement at least one of either DoT
+   or DoQ on port 853.
+
+   An authoritative server choosing to implement the protocol described
+   in this document MAY require clients to use Application-Layer
+   Protocol Negotiation (ALPN) (see [RFC7301]).  The ALPN strings the
+   client will use are given in Section 4.4.
+
+   An authoritative server implementing DoT or DoQ MUST populate the
+   response from the same authoritative zone data as the unencrypted 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., Extension
+   Mechanisms for DNS (EDNS0)) and flags (e.g., the TrunCation (TC) bit)
+   might vary based on the transport.  In other words, the content of
+   the responses to a particular query MUST be the same regardless of
+   the type of transport.
+
+3.1.  Pooled Authoritative Servers behind a Load Balancer
+
+   Some authoritative DNS servers are structured as a pool of
+   authoritatives standing behind a load 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.
+
+   A recursive resolver following the guidance in Section 4 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.
+
+   To avoid incurring additional minor timeouts for such a recursive
+   resolver, the pool operator SHOULD:
+
+   *  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
+
+   *  ensure that the load balancer maps client requests to pool members
+      based on client IP addresses, or
+
+   *  use a load 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.
+
+   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.
+
+3.2.  Authentication
+
+   For unilateral deployment, an authoritative server does not need to
+   offer any particular form of authentication.
+
+   One simple deployment approach would just be to provide a self-
+   issued, regularly 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 QUIC 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.
+
+3.3.  Server Name Indication
+
+   An authoritative DNS server that wants to handle unilateral queries
+   MAY rely on Server Name Indication (SNI) to select alternate server
+   credentials.  However, such a server MUST NOT serve resource records
+   that differ based on SNI (or on the lack of an SNI) provided by the
+   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.
+
+3.4.  Resource Exhaustion
+
+   A well-behaved recursive resolver may keep an encrypted connection
+   open to an authoritative server to amortize the costs of connection
+   setup for both parties.
+
+   However, some authoritative servers may have insufficient resources
+   available to keep many connections open concurrently.
+
+   To keep resources under control, authoritative servers should
+   proactively manage their encrypted connections.  Section 5.5 of
+   [RFC9250] offers useful guidance for servers managing DoQ
+   connections.  Section 3.4 of [RFC7858] offers useful guidance for
+   servers managing DoT connections.
+
+   An authoritative server facing unforeseen resource exhaustion SHOULD
+   cleanly close open connections from recursive resolvers based on the
+   authoritative server's preferred prioritization.
+
+   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).
+
+   When resources are especially tight, the authoritative server may
+   also decline to accept new connections over encrypted transport.
+
+3.5.  Pad Responses to Mitigate Traffic Analysis
+
+   To increase the anonymity set for each response, the authoritative
+   server SHOULD 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 an EDNS0 option in
+   the query.  Specifically, a DoT server SHOULD use EDNS0 padding
+   [RFC7830] if possible, and a DoQ server SHOULD follow the guidance in
+   Section 5.4 of [RFC9250].  How much to pad is out of scope of this
+   document, but a reasonable suggestion can be found in [RFC8467].
+
+4.  Guidance for Recursive Resolvers
+
+   The protocol described in this document is OPTIONAL 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.
+
+4.1.  High-Level Overview
+
+   In addition to querying on Do53, the recursive resolver will try DoT,
+   DoQ, or both concurrently.  The recursive resolver remembers what
+   opportunistic encrypted transport protocols have worked recently
+   based on a (clientIP, serverIP, protocol) tuple.
+
+   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.
+
+   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 flooding an incompatible server with requests
+   that it cannot accept.  The description of how an encrypted transport
+   protocol fails is in Section 4.6.4 and the sections following that.
+
+   See the subsections below for a more detailed description of this
+   protocol.
+
+4.2.  Maintaining Authoritative State by IP Address
+
+   In designing a probing strategy, the recursive resolver could record
+   its knowledge about any given authoritative server with different
+   strategies, including at least:
+
+   *  the authoritative server's IP address,
+
+   *  the authoritative server's name (the NS record used), or
+
+   *  the zone that contains the record being looked up.
+
+   This document encourages the first strategy, to minimize timeouts or
+   accidental delays, and does not describe the other two strategies.
+
+   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).
+
+   By associating the state with the authoritative IP address, the
+   client can minimize the number of accidental delays introduced (see
+   also Sections 3.1 and 4.5).
+
+   For example, consider an authoritative server named ns0.example.com
+   that is served by two installations: one at 2001:db8::7 that follows
+   this guidance and one at 2001:db8::8 that is a legacy (cleartext port
+   53-only) deployment.  A recursive client who associates state with
+   the NS name and reaches 2001:db8::7 first will "learn" that
+   ns0.example.com supports encrypted transport.  A subsequent query
+   over encrypted transport dispatched to 2001:db8::8 would fail,
+   potentially delaying the response.
+
+4.3.  Overall Recursive Resolver Settings
+
+   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.
+
+      +=============+==================================+===========+
+      | Name        | Description                      | Suggested |
+      |             |                                  | Default   |
+      +=============+==================================+===========+
+      | persistence | How long the recursive resolver  | 3 days    |
+      |             | remembers a successful encrypted | (259200   |
+      |             | transport connection             | seconds)  |
+      +-------------+----------------------------------+-----------+
+      | damping     | How long the recursive resolver  | 1 day     |
+      |             | remembers an unsuccessful        | (86400    |
+      |             | encrypted transport connection   | seconds)  |
+      +-------------+----------------------------------+-----------+
+      | timeout     | How long the recursive resolver  | 4 seconds |
+      |             | waits for an initiated encrypted |           |
+      |             | connection to complete           |           |
+      +-------------+----------------------------------+-----------+
+
+            Table 1: Recursive Resolver System Parameters per
+                           Encrypted Transport
+
+   This document uses the notation <transport>-foo to refer to the foo
+   parameter for the encrypted transport <transport>.  For example, DoT-
+   persistence would indicate the length of time that the recursive
+   resolver will remember that an authoritative server had a successful
+   connection over DoT.  Additionally, when describing an arbitrary
+   encrypted transport, we use E in place of <transport> to generically
+   mean whatever encrypted transport is in use.  For example, when
+   handling a query sent over encrypted transport E, a reference to
+   E-timeout should be understood to mean DoT-timeout if the query is
+   sent over DoT, and to mean DoQ-timeout if the query is sent over DoQ.
+
+   This document also assumes that the recursive resolver maintains a
+   list of outstanding cleartext queries destined for the authoritative
+   server's IP address X.  This list is referred to as "Do53-queries[X]"
+   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.
+
+   Implementers or deployers of DNS recursive resolvers that follow the
+   strategies in this document are encouraged to publish their preferred
+   values of these parameters.
+
+4.4.  Recursive Resolver Requirements
+
+   To follow the strategies in this document, a recursive resolver MUST
+   implement at least one of either DoT or DoQ in its capacity as a
+   client of authoritative nameservers.  A recursive resolver SHOULD
+   implement the client side of DoT.  A recursive resolver SHOULD
+   implement the client side of DoQ.
+
+   DoT queries from the recursive resolver MUST target TCP port 853
+   using an ALPN of "dot".  DoQ queries from the recursive resolver MUST
+   target UDP port 853 using an ALPN of "doq".
+
+   While this document focuses on the recursive-to-authoritative hop, a
+   recursive resolver implementing the strategies in this document
+   SHOULD also accept queries from its clients over some encrypted
+   transport unless it only accepts queries from the localhost.
+
+4.5.  Authoritative Server Encrypted Transport Connection State
+
+   The recursive resolver SHOULD 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.
+
+   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 2001:db8::100 and
+   2001:db8::200, it could keep two distinct sets of per-authoritative-
+   IP 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 Section 3.1).
+
+   In addition to tracking the state of connection attempts and
+   outcomes, a recursive resolver SHOULD record the state of established
+   sessions for encrypted protocols.  The details of how sessions are
+   identified are 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.
+
+   Each record should contain the following fields for each supported
+   encrypted transport, each of which would initially be null:
+
+    +===============+======================================+=========+
+    | Name          | Description                          | Retain  |
+    |               |                                      | Across  |
+    |               |                                      | Restart |
+    +===============+======================================+=========+
+    | session       | The associated state of any existing | no      |
+    |               | established session (the structure   |         |
+    |               | of this value is dependent on the    |         |
+    |               | encrypted transport implementation). |         |
+    |               | If session is not null, it may be in |         |
+    |               | one of two states: pending or        |         |
+    |               | established.                         |         |
+    +---------------+--------------------------------------+---------+
+    | initiated     | Timestamp of the most recent         | yes     |
+    |               | connection attempt                   |         |
+    +---------------+--------------------------------------+---------+
+    | completed     | Timestamp of the most recent         | yes     |
+    |               | completed handshake (which can       |         |
+    |               | include one where an existing        |         |
+    |               | session is resumed)                  |         |
+    +---------------+--------------------------------------+---------+
+    | status        | Enumerated value of success, fail,   | yes     |
+    |               | or timeout associated with the       |         |
+    |               | completed handshake                  |         |
+    +---------------+--------------------------------------+---------+
+    | last-response | A timestamp of the most recent       | yes     |
+    |               | response received on the connection  |         |
+    +---------------+--------------------------------------+---------+
+    | resumptions   | A stack of resumption tickets (and   | yes     |
+    |               | associated parameters) that could be |         |
+    |               | used to resume a prior successful    |         |
+    |               | session                              |         |
+    +---------------+--------------------------------------+---------+
+    | queries       | A queue of queries intended for this | no      |
+    |               | authoritative server, each of which  |         |
+    |               | has additional status of early,      |         |
+    |               | unsent, or sent                      |         |
+    +---------------+--------------------------------------+---------+
+    | last-activity | A timestamp of the most recent       | no      |
+    |               | activity on the connection           |         |
+    +---------------+--------------------------------------+---------+
+
+        Table 2: Recursive Resolver State per-Authoritative-IP and
+                         per-Encrypted Transport
+
+   Note that the session fields in aggregate constitute a pool of open
+   connections to different servers.
+
+   With the exception of the session, queries, and last-activity fields,
+   this cache information should be kept across restart of the server
+   unless explicitly cleared by administrative action.
+
+   This document uses the notation E-foo[X] to indicate the value of
+   field foo for encrypted transport E to IP address X.
+
+   For example, DoT-initiated[192.0.2.4] represents the timestamp when
+   the most recent DoT connection packet was sent to IP address
+   192.0.2.4.
+
+   This document uses the notation any-E-queries to indicate any query
+   on an encrypted transport.
+
+4.6.  Probing Policy
+
+   When a recursive resolver discovers the need for an authoritative
+   lookup to an authoritative DNS server using that server's IP address
+   X, it retrieves the connection state records described in Section 4.5
+   associated with X from its cache.
+
+   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.  All subsections
+   also presume that the time of the discovery of the need for lookup is
+   time T0.
+
+   If any of the records discussed here are absent, they are treated as
+   null.
+
+   The recursive resolver must decide whether to initially send a query
+   over Do53, or over either of the supported encrypted transports (DoT
+   or DoQ).
+
+   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"
+   ([RFC8305]).  However, unlike Happy Eyeballs, when one transport
+   succeeds, the other connections do not need to be terminated; instead
+   they can be continued to establish whether the IP address X is
+   capable of communicating on the relevant transport.
+
+4.6.1.  Sending a Query over Do53
+
+   For any of the supported encrypted transports E, the recursive
+   resolver SHOULD NOT send a query to X over Do53 if either of the
+   following holds true:
+
+   *  E-session[X] is in the established state, or
+
+   *  E-status[X] is success and (T0 - E-last-response[X]) <
+      persistence.
+
+   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.
+
+   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 X over Do53.  When
+   it does so, it inserts a handle for the query in Do53-queries[X].
+
+4.6.2.  Receiving a Response over Do53
+
+   When any response R (a well-formed DNS response, asynchronous
+   timeout, asynchronous destination port unreachable, etc.) for query Q
+   arrives at the recursive resolver in cleartext sent over Do53 from an
+   authoritative server with IP address X, the recursive resolver should
+   perform the following.
+
+   If Q is not in Do53-queries[X]:
+
+   *  process R no further (do not respond to a cleartext response to a
+      query that is not outstanding).
+
+   Otherwise, if Q was marked as already processed:
+
+   *  remove Q from Do53-queries[X],
+
+   *  discard any content from the response, and process R no further.
+
+   If R is a well-formed DNS response:
+
+   *  remove Q from Do53-queries[X],
+
+   *  process R further, and
+
+   *  for each supported encrypted transport E:
+
+      -  if Q is in E-queries[X], then
+
+         o  mark Q as already processed.
+
+   However, if R is malformed or a failure (e.g., a timeout or
+   destination port unreachable), and
+
+   *  if Q is not in any of any-E-queries[X], then
+
+      -  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
+         SERVFAIL to the requesting client, and so on).
+
+4.6.3.  Initiating a Connection over Encrypted Transport
+
+   If any E-session[X] is in the established state, the recursive
+   resolver SHOULD NOT initiate a new connection or resume a previous
+   connection to X over Do53 or E, but should instead send queries to X
+   through the existing session (see Section 4.6.8).
+
+   If the recursive resolver prefers one encrypted transport over
+   another, but only the unpreferred encrypted transport is in the
+   established state, it MAY also initiate a new connection to X over
+   its preferred encrypted transport while concurrently sending the
+   query over the established encrypted transport E.
+
+   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 E to authoritative IP
+   address X.
+
+   *  If E-session[X] is in state pending, and
+
+   *  T0 - E-initiated[X] > E-timeout, then
+
+      -  set E-session[X] to null, and
+
+      -  set E-status[X] to timeout.
+
+   When resources are available to attempt a new encrypted transport,
+   the recursive resolver should only initiate a new connection to X
+   over E as long as one of the following holds true:
+
+   *  E-status[X] is success, or
+
+   *  E-status[X] is either fail or timeout and (T0 - E-completed[X]) >
+      damping, or
+
+   *  E-status[X] is null and E-initiated[X] is null.
+
+   When initiating a session to X over encrypted transport E, if
+   E-resumptions[X] is not empty, one ticket should be popped off the
+   stack and used to try to resume a previous session.  Otherwise, the
+   initial ClientHello handshake should not try to resume any session.
+
+   When initiating a connection, the recursive resolver should take the
+   following steps:
+
+   *  set E-initiated[X] to T0,
+
+   *  store a handle for the new session (which should have pending
+      state) in E-session[X], and
+
+   *  insert a handle for the query that prompted this connection in
+      E-queries[X], with status unsent or early, as appropriate (see
+      below).
+
+4.6.3.1.  Early Data
+
+   Modern encrypted transports like TLS 1.3 offer the chance to send
+   "early data" from the client in the initial ClientHello in some
+   contexts.  A recursive resolver that initiates a connection over an
+   encrypted transport according to this guidance in a context where
+   early data is possible SHOULD send the DNS query that prompted the
+   connection in the early data, according to the sending guidance in
+   Section 4.6.8.
+
+   If it does so, the status of Q in E-queries[X] should be set to early
+   instead of unsent.
+
+4.6.3.2.  Resumption Tickets
+
+   When initiating a new connection (whether by resuming an old session
+   or not), the recursive resolver SHOULD 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 E-resumptions[X].
+
+4.6.3.3.  Server Name Indication
+
+   For modern encrypted transports like TLS 1.3, most client
+   implementations expect to send a Server Name Indication (SNI) in the
+   ClientHello.
+
+   There are two complications with selecting or sending an SNI in this
+   unilateral probing.
+
+   *  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.
+
+   *  In most configurations, the contents of the SNI field are exposed
+      on the wire to a passive adversary.  This potentially reveals
+      additional information about which query is being made based on
+      the NS of the query itself.
+
+   To avoid additional leakage and complexity, a recursive resolver
+   following this guidance SHOULD NOT send an SNI to the authoritative
+   server when attempting encrypted transport.
+
+   If the recursive resolver needs to send an SNI to the authoritative
+   server for some reason not found in this document, using Encrypted
+   ClientHello ([TLS-ECH]) would reduce leakage.
+
+4.6.3.4.  Authoritative Server Authentication
+
+   Because this probing policy is unilateral and opportunistic, the
+   client connecting under this policy MUST accept any certificate
+   presented by the server.  If the client cannot verify the server's
+   identity, it MAY use that information for reporting, logging, or
+   other analysis purposes; however, it MUST NOT 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.
+
+4.6.4.  Establishing an Encrypted Transport Connection
+
+   When an encrypted transport connection actually completes (e.g., the
+   TLS handshake completes) at time T1, the recursive resolver sets
+   E-completed[X] to T1 and does the following.
+
+   If the handshake completed successfully, the recursive resolver:
+
+   *  updates E-session[X] so that it is in state established,
+
+   *  sets E-status[X] to success,
+
+   *  sets E-last-response[X] to T1,
+
+   *  sets E-completed[X] to T1, and
+
+   *  for each query Q in E-queries[X]:
+
+      -  if early data was accepted and Q is early, then
+
+         o  sets the status of Q to sent.
+
+      -  Otherwise:
+
+         o  sends Q through the session (see Section 4.6.8) and sets the
+            status of Q to sent.
+
+4.6.5.  Failing to Establish an Encrypted Transport Connection
+
+   If, at time T2, an encrypted transport handshake completes with a
+   failure (e.g., a TLS alert):
+
+   *  set E-session[X] to null,
+
+   *  set E-status[X] to fail,
+
+   *  set E-completed[X] to T2, and
+
+   *  for each query Q in E-queries[X]:
+
+      -  if Q is not present in any other any-E-queries[X] or in
+         Do53-queries[X], add Q to Do53-queries[X] and send query Q to X
+         over Do53.
+
+   Note that this failure will trigger the recursive resolver to fall
+   back to cleartext queries to the authoritative server at IP address
+   X.  It will retry encrypted transport to X once the damping timer has
+   elapsed.
+
+4.6.6.  Encrypted Transport Failure
+
+   Once established, an encrypted transport might fail for a number of
+   reasons (e.g., decryption failure or improper protocol sequence).
+
+   If this happens:
+
+   *  set E-session[X] to null,
+
+   *  set E-status[X] to fail, and
+
+   *  for each query Q in E-queries[X]:
+
+      -  if Q is not present in any other any-E-queries[X] or in
+         Do53-queries[X], add Q to Do53-queries[X] and send query Q to X
+         over Do53.
+
+   Note that this failure will trigger the recursive resolver to fall
+   back to cleartext queries to the authoritative server at IP address
+   X.  It will retry encrypted transport to X once the damping timer has
+   elapsed.
+
+4.6.7.  Handling Clean Shutdown of an Encrypted Transport Connection
+
+   At time T3, the recursive resolver may find that authoritative server
+   X cleanly closes an existing outstanding connection (most likely due
+   to resource exhaustion, see Section 3.4).
+
+   When this happens:
+
+   *  set E-session[X] to null, and
+
+   *  for each query Q in E-queries[X]:
+
+      -  if Q is not present in any other any-E-queries[X] or in
+         Do53-queries[X], add Q to Do53-queries[X] and send query Q to X
+         over Do53.
+
+   Note that this premature shutdown will trigger the recursive resolver
+   to fall back to cleartext queries to the authoritative server at IP
+   address X.  Any subsequent query to X will retry the encrypted
+   connection promptly.
+
+4.6.8.  Sending a Query over Encrypted Transport
+
+   When sending a query to an authoritative server over encrypted
+   transport at time T4, the recursive resolver should take a few
+   reasonable steps to ensure privacy and efficiency.  After sending
+   query Q, the recursive resolver should:
+
+   *  Ensure that Q's state in E-queries[X] is set to sent.
+
+   *  Set E-last-activity[X] to T4.
+
+   The recursive resolver should also consider the guidance in the
+   following subsections.
+
+4.6.8.1.  Pad Queries to Mitigate Traffic Analysis
+
+   To increase the anonymity set for each query, the recursive resolver
+   SHOULD use a sensible padding mechanism for all queries it sends.
+   Specifically, a DoT client SHOULD use EDNS0 padding [RFC7830], and a
+   DoQ client SHOULD follow the guidance in Section 5.4 of [RFC9250].
+   How much to pad is out of scope of this document, but a reasonable
+   suggestion can be found in [RFC8467].
+
+4.6.8.2.  Send Queries in Separate Channels
+
+   When multiple queries are multiplexed on a single encrypted transport
+   to a single authoritative server, the recursive resolver SHOULD
+   pipeline queries and MUST be capable of receiving responses out of
+   order.  For guidance on how to best achieve this on a given encrypted
+   transport, see Section 6.2.1.1 of [RFC7766] (for DoT) and Section 5.6
+   of [RFC9250] (for DoQ).
+
+4.6.9.  Receiving a Response over Encrypted Transport
+
+   Even though session-level events on encrypted transports like clean
+   shutdown (see Section 4.6.7) or encrypted transport failure (see
+   Section 4.6.6) can happen, some events happen on encrypted transports
+   that are specific to a query and are not session-wide.  This
+   subsection describes how the recursive resolver deals with events
+   related to a specific query.
+
+   When a query-specific response R (a well-formed DNS response or an
+   asynchronous timeout) associated with query Q arrives at the
+   recursive resolver over encrypted transport E from an authoritative
+   server with IP address X at time T5, the recursive resolver should
+   perform the following.
+
+   If Q is not in E-queries[X]:
+
+   *  discard the response and process R no further (do not respond to
+      an encrypted response to a query that is not outstanding).
+
+   Otherwise:
+
+   *  remove Q from E-queries[X],
+
+   *  set E-last-activity[X] to T5, and
+
+   *  set E-last-response[X] to T5.
+
+   If Q was marked as already processed:
+
+   *  discard the response and process the response no further.
+
+   If R is a well-formed DNS response:
+
+   *  process R further, and
+
+   *  for each supported encrypted transport N other than E:
+
+      -  if Q is in N-queries[X], then
+
+         o  mark Q as already processed.
+
+   *  If Q is in Do53-queries[X]:
+
+      -  mark Q as already processed.
+
+   However, if R is malformed or a failure (e.g., timeout), and
+
+   *  if Q is not in Do53-queries[X] or in any of any-E-queries[X], then
+
+      -  treat this as a failed query (i.e., follow the resolver's
+         policy for unresponsive or non-compliant authoritative servers,
+         such as falling back to another authoritative server, returning
+         SERVFAIL to the requesting client, and so on).
+
+4.6.10.  Resource Exhaustion
+
+   To keep resources under control, a recursive resolver should
+   proactively manage outstanding encrypted connections.  Section 5.5 of
+   [RFC9250] offers useful guidance for clients managing DoQ
+   connections.  Section 3.4 of [RFC7858] offers useful guidance for
+   clients managing DoT connections.
+
+   Even with sensible connection management, a recursive resolver doing
+   unilateral probing may find resources unexpectedly scarce and may
+   need to close some outstanding connections.
+
+   In such a situation, the recursive resolver SHOULD use a reasonable
+   prioritization scheme to close outstanding connections.
+
+   One reasonable prioritization scheme would be to close outstanding
+   established sessions based on E-last-activity[X] (i.e, the oldest
+   timestamp gets closed first).
+
+   Note that when resources are limited, a recursive resolver following
+   this guidance may also choose not to initiate new connections for
+   encrypted transport.
+
+4.6.11.  Maintaining Connections
+
+   Some recursive resolvers looking to amortize connection costs and
+   minimize latency MAY choose to synthesize queries to a particular
+   authoritative server to keep an encrypted transport session active.
+
+   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.
+
+4.6.12.  Additional Tuning
+
+   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 additional states include the following.
+
+   *  Whether the server accepts "early data" over a transport such as
+      DoQ.
+
+   *  Whether the server fails to respond to queries after the handshake
+      succeeds.
+
+   *  Tracking the round-trip time of queries to the server.
+
+   *  Tracking the number of timeouts (compared to the number of
+      successful queries).
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  Privacy Considerations
+
+6.1.  Server Name Indication
+
+   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.
+
+   In particular, if two different zones refer to the same nameserver IP
+   addresses via differently named NS records, a passive network
+   observer can distinguish the queries to one zone from the queries to
+   the other.
+
+   Omitting SNI entirely, or using Encrypted ClientHello to hide the
+   intended SNI, avoids this additional leakage.  However, a series of
+   queries that leak this information is still an improvement over
+   cleartext.
+
+6.2.  Modeling the Probability of Encryption
+
+   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, which, in turn, 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.
+
+7.  Security Considerations
+
+   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 optimizations ([RFC8305]) when the recursive
+   resolver's cache is cold.
+
+   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.
+
+   However, implementers cannot rely on the guidance in this document
+   for robust defense against active attackers: they should treat it as
+   a stepping stone en route to stronger defense.
+
+   In particular, a recursive resolver following the 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.
+
+   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 ([RFC9156]),
+   local root zone ([RFC8806]), etc., to reduce the overall leakage of
+   query information that could infringe on the client's privacy.
+
+8.  Operational Considerations
+
+   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 significant problems.  If the authoritative
+   server is not supporting this protocol, it will not respond on port
+   853; if it is supporting this protocol, it will act accordingly.
+
+   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 IP address.  Additionally, the DNS server
+   answering on port 853 would need to be able to differentiate queries
+   for recursive answers from queries for authoritative answers (e.g.,
+   by having the authoritative server handle all queries that have the
+   Recursion Desired (RD) flag unset).
+
+   As discussed in Section 7, 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 actively
+   intercepted (e.g., when the network tries to redirect a user to
+   complete an interaction with a captive portal server).  A recursive
+   resolver operating on a node that performs captive portal detection
+   and Internet connectivity checks SHOULD delay encrypted transport
+   probes to authoritative servers until after the node's Internet
+   connectivity check policy has been satisfied.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
+              "Transport Layer Security (TLS) Application-Layer Protocol
+              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
+              July 2014, <https://www.rfc-editor.org/info/rfc7301>.
+
+   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
+              and P. Hoffman, "Specification for DNS over Transport
+              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
+              2016, <https://www.rfc-editor.org/info/rfc7858>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
+              Dedicated QUIC Connections", RFC 9250,
+              DOI 10.17487/RFC9250, May 2022,
+              <https://www.rfc-editor.org/info/rfc9250>.
+
+9.2.  Informative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
+              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
+              December 2014, <https://www.rfc-editor.org/info/rfc7435>.
+
+   [RFC7672]  Dukhovni, V. and W. Hardaker, "SMTP Security via
+              Opportunistic DNS-Based Authentication of Named Entities
+              (DANE) Transport Layer Security (TLS)", RFC 7672,
+              DOI 10.17487/RFC7672, October 2015,
+              <https://www.rfc-editor.org/info/rfc7672>.
+
+   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
+              D. Wessels, "DNS Transport over TCP - Implementation
+              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
+              <https://www.rfc-editor.org/info/rfc7766>.
+
+   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
+              DOI 10.17487/RFC7830, May 2016,
+              <https://www.rfc-editor.org/info/rfc7830>.
+
+   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
+              Better Connectivity Using Concurrency", RFC 8305,
+              DOI 10.17487/RFC8305, December 2017,
+              <https://www.rfc-editor.org/info/rfc8305>.
+
+   [RFC8460]  Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,
+              and M. Risher, "SMTP TLS Reporting", RFC 8460,
+              DOI 10.17487/RFC8460, September 2018,
+              <https://www.rfc-editor.org/info/rfc8460>.
+
+   [RFC8461]  Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
+              and J. Jones, "SMTP MTA Strict Transport Security (MTA-
+              STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
+              <https://www.rfc-editor.org/info/rfc8461>.
+
+   [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms
+              for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
+              October 2018, <https://www.rfc-editor.org/info/rfc8467>.
+
+   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
+              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
+              <https://www.rfc-editor.org/info/rfc8484>.
+
+   [RFC8806]  Kumari, W. and P. Hoffman, "Running a Root Server Local to
+              a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
+              <https://www.rfc-editor.org/info/rfc8806>.
+
+   [RFC9102]  Dukhovni, V., Huque, S., Toorop, W., Wouters, P., and M.
+              Shore, "TLS DNSSEC Chain Extension", RFC 9102,
+              DOI 10.17487/RFC9102, August 2021,
+              <https://www.rfc-editor.org/info/rfc9102>.
+
+   [RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
+              Name Minimisation to Improve Privacy", RFC 9156,
+              DOI 10.17487/RFC9156, November 2021,
+              <https://www.rfc-editor.org/info/rfc9156>.
+
+   [TLS-ECH]  Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
+              Encrypted Client Hello", Work in Progress, Internet-Draft,
+              draft-ietf-tls-esni-17, 9 October 2023,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
+              esni-17>.
+
+   [DNS-ER]   Arends, R. and M. Larson, "DNS Error Reporting", Work in
+              Progress, Internet-Draft, draft-ietf-dnsop-dns-error-
+              reporting-07, 17 November 2023,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
+              dns-error-reporting-07>.
+
+Appendix A.  Assessing the Experiment
+
+   This document is an Experimental 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
+   metrics include the following.
+
+   *  Comparison of the CPU and memory use between Do53 and encrypted
+      transports.
+
+   *  Comparison of the query response rates between Do53 and encrypted
+      transports.
+
+   *  Measurement of server authentication successes and failures.
+
+   *  Measurement and descriptions of observed attack traffic, if any.
+
+   *  Comparison of transactional bandwidth (ingress/egress, packets per
+      second, bytes per second) between Do53 and encrypted transports.
+
+Appendix B.  Defense against Active Attackers
+
+   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.
+
+   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 SERVFAIL response to its client if it cannot make an
+   authenticated encrypted connection to any of the authoritative
+   nameservers for a name.
+
+   However, an authoritative server that merely offers encrypted
+   transport (for example, by following the guidance in Section 3) has
+   made no such commitment, and no recursive resolver that prioritizes
+   delivery of DNS records to its clients would want to "fail closed"
+   unilaterally.
+
+   Therefore, such a future protocol would need at least three major
+   distinctions from the protocol described in this document:
+
+   *  A signaling mechanism that tells the recursive resolver that the
+      authoritative server intends to offer authenticated encryption.
+
+   *  Authentication of the authoritative server.
+
+   *  A way to combine defense against an active attacker with the
+      defenses described in this document.
+
+   This can be thought of as a DNS analog to [RFC8461] or [RFC7672].
+
+B.1.  Signaling Mechanism Properties
+
+   To defend against an active attacker, the signaling mechanism needs
+   to be able to indicate that the recursive resolver should fail closed
+   if it cannot authenticate the server for a particular query.
+
+   The signaling mechanism itself would have to be resistant to
+   downgrade attacks from active attackers.
+
+   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 the DNS or by the nameserver name than by the IP address.
+
+   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 [RFC8460] or [DNS-ER].
+
+B.2.  Authentication of Authoritative Servers
+
+   Forms of server authentication might include:
+
+   *  An X.509 certificate issued by a widely known certification
+      authority associated with the common NS names used for this
+      authoritative server.
+
+   *  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 DNSSEC chain
+      extension (see [RFC9102])).
+
+   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.
+
+B.3.  Combining Protocols
+
+   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 that wants to maximize confidentiality for their users
+   will want to use both protocols together.
+
+   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 more narrowly targeted
+   protection against active attackers.
+
+Acknowledgements
+
+   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.
+
+Authors' Addresses
+
+   Daniel Kahn Gillmor (editor)
+   American Civil Liberties Union
+   125 Broad St.
+   New York, NY 10004
+   United States of America
+   Email: dkg@fifthhorseman.net
+
+
+   Joey Salazar (editor)
+   Alajuela
+   20201
+   Costa Rica
+   Email: joeygsal@gmail.com
+
+
+   Paul Hoffman (editor)
+   ICANN
+   United States of America
+   Email: paul.hoffman@icann.org