RFC 9539

Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS

📅 published February 2024, from ietf

RFC 9539: Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS 🎀

okay bestie, here's the deal with this one 💅. it's RFC 9539, published February 2024, and it's Experimental (not a Standards Track spec, so it's a "try it out and see" kind of doc 🧪). The ISSN is 2070-1721 ✨.

The editors are D. K. Gillmor, Ed. (ACLU), J. Salazar, Ed., and P. Hoffman, Ed. (ICANN). The title block doesn't list anything it obsoletes or updates, so this doc stands on its own 🦋.

Abstract 🌸

okay so this doc is all about the steps DNS servers can take by themselves (no begging other servers to coordinate, no cap) to protect DNS query privacy from a passive network monitor 👀. that's recursive resolvers AND authoritative servers. the catch: an active attacker can still get around these protections, but the whole point is that they're way simpler and less risky to roll out than the heavier defenses 💖.

the bigger goal is to make it quicker and easier to get opportunistic encrypted transport running on the recursive-to-authoritative hop of DNS. like, if it's easy to deploy this widely, it could set the stage for stronger crypto protections against more powerful attacks later 🔥.

Status of This Memo 📜

this one is not an Internet Standards Track spec. it's published for examination, experimental implementation, and evaluation 🧪.

it defines an Experimental Protocol for the Internet community. it's a product of the Internet Engineering Task Force (IETF), it represents the IETF community's consensus, it got public review, and the IESG approved it for publication. not every IESG-approved doc is up for any level of Internet Standard though, so check Section 2 of RFC 7841 if you want the details 🤓.

info about the current status, errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9539 ✨.

the IETF Trust and the document authors own the copyright (2024), all rights reserved 🔒.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read those, bestie, because they spell out your rights and restrictions 🫶. and if you extract any Code Components from this doc, they have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per 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 doc is here to help DNS implementers and operators who want to turn on protection against passive network observers without a headache 💖.

it zeroes in on mechanisms that recursive resolvers and authoritative servers can adopt unilaterally, with no explicit coordination with the other parties 🦋. this is opportunistic security (see [RFC7435]), which means encrypting stuff that would otherwise be in the clear, without interfering with or weakening stronger forms of security 🔐.

there's also a brief look in Appendix B at how a future protocol might allow defense against an active attacker. it's just an intro though, not a full spec for that 👀.

the protocol here gives the DNS ecosystem three concrete advantages 👑:

  • protection from passive attackers of DNS queries in transit between recursive and authoritative servers 🛡️
  • a road map for getting real-world experience at scale with encrypted protection of this traffic 🗺️
  • a bridge to 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: able to do 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 in this doc was built around two priorities: minimizing negative impacts and keeping flexibility in the underlying encrypted transport protocol 💅.

2.1. Minimizing Negative Impacts 🌿

the protocol is designed to cut down on potentially negative impacts that come from probing encrypted transports. that goes for the systems that adopt it, the parties they talk to, and uninvolved third parties too 🫶. the specific negatives it tries to minimize are:

  • excessive bandwidth use 📶
  • excessive use of computational resources (CPU and memory in particular) 🧮
  • the potential for amplification attacks (where DNS resolution infrastructure gets wielded as part of a DoS attack) 🚨

2.2. Protocol Choices 🧩

this doc focuses on strategies used by DNS servers, but it doesn't go deep on the specific protocols. that's because those protocols, DoT and DoQ especially, are described in other docs 📚. the DoT spec ([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 adds:

"It might work equally between recursive clients and authoritative servers..."

the DoQ spec ([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 in this doc uses DoT and DoQ without authentication of the server 🔓.

this doc doesn't go after DNS over HTTPS, usually called "DoH" ([RFC8484]), in this context. why? a DoH client needs to know the path part of a DoH endpoint URL, and right now there's no way for a DNS recursive resolver to predict that path on its own, opportunistically or unilaterally, without burning excessive resources 😭. if mechanisms for that get defined later, this protocol can be updated to accommodate them ✨.

3. Guidance for Authoritative Servers 🏛️

the protocol here is OPTIONAL for authoritative servers 🙌. an authoritative server that chooses to implement it MUST implement at least one of DoT or DoQ on port 853 💜.

an authoritative server that chooses to implement this protocol MAY require clients to use Application-Layer Protocol Negotiation (ALPN) (see [RFC7301]). the ALPN strings the client will use are 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, which can be different from the unencrypted transports. so response sizes, related options (like Extension Mechanisms for DNS (EDNS0)), and flags (like 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 💖.

That's the end of Part 1! ✨

3.1. Pooled Authoritative Servers behind a Load Balancer 🎀

Okay so some authoritative DNS servers are basically a whole pool of authoritatives hanging out behind a load balancer, all sharing one IP address. The load balancer forwards each query to a pool member, and the members usually get updated independently of each other 🧚

A recursive resolver following Section 4 and talking to a pool like this probably has no idea it's a pool 🙈 If some members speak the protocol in this document and others don't, the recursive client might think it's one server that sometimes offers encrypted transport and sometimes refuses it. Chaotic, bestie 💀

To avoid picking up extra minor timeouts for that 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.

Anycast IP addresses have the same drama 🌈 While the pool is in a heterogeneous state, any flapping route that switches a given client IP address to a different responder risks an extra timeout. Frequent routing changes for anycast listening IP addresses can also mess with TLS, TCP, or QUIC connection state, so stable routes matter if you want the service to stay available and responsive ✨ Also, the servers in a pool can share session information to make successful resumptions more likely 💜

3.2. Authentication 🦋

For unilateral deployment, an authoritative server does not need to offer any particular form of authentication. No pressure 💅

One simple approach is a self-issued, regularly updated X.509 certificate 🎀 Whether those certificates are short-lived or long-lived is up to the deployment. Lots of TLS and QUIC clients support this, and it's good enough for any opportunistic connection. You could use a normal PKI-based certificate, but there's no advantage to that 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. BUT (and this is a big but 😭) such a server MUST NOT serve resource records that differ based on SNI (or on the lack of an SNI) provided by the client. Why? A probing recursive resolver that offers SNI might or might not have used the right server name to get the records it's looking for, so it could get the wrong answers. Not iconic.

3.4. Resource Exhaustion 🔥

A well-behaved recursive resolver may keep an encrypted connection open to an authoritative server, which saves both parties the cost of setting up a new connection every time 🫶

However, some authoritative servers may not have enough resources to keep lots of connections open at once 😩

So to keep resources under control, authoritative servers should proactively manage their encrypted connections. Section 5.5 of [RFC9250] has useful guidance for servers managing DoQ connections, and Section 3.4 of [RFC7858] has 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.

If resources get squeezed unexpectedly, close connections until resources are back under control. A reasonable prioritization scheme would be to close connections with no outstanding queries first, ordered by idle time (the longest idle time gets closed first). After that, close connections with outstanding queries, ordered by the age of their outstanding query (the oldest outstanding query gets closed first) 🍓

When resources are especially tight, the authoritative server may also decline to accept new connections over encrypted transport. Boundaries are self-care, periodt 💅

3.5. Pad Responses to Mitigate Traffic Analysis 🌈

To make the anonymity set bigger for each response, the authoritative server SHOULD use a sensible padding mechanism for all responses it sends, when possible 🧁 The server's ability to add padding might be limited, such as when it doesn't receive 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 for 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 that any recursive resolver can adopt unilaterally 🦋 Following this policy should not result in failed resolutions or significant delays, which is the whole vibe ✨

4.1. High-Level Overview 🧚

Okay, the big picture: in addition to querying on Do53, the recursive resolver will try DoT, DoQ, or both concurrently 🌸 It remembers which opportunistic encrypted transport protocols have worked recently, keyed 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 🙅‍♀️ 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, so it doesn't flood an incompatible server with requests it can't accept 😭 How an encrypted transport fails is described in Section 4.6.4 and the sections following it.

Check the subsections below for the more detailed version 💅

4.2. Maintaining Authoritative State by IP Address 🎀

When designing a probing strategy, the recursive resolver could record what it knows about any given authoritative server in different ways, 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. It does not describe the other two strategies 🦋

A timeout (accidental delay) is most likely to happen when the recursive client believes the authoritative server offers encrypted transport, but the server it actually reaches declines encrypted transport. It's even worse if the server filters the incoming traffic and doesn't even send back an ICMP destination port unreachable message, like during rate limiting 💀

By tying the state to the authoritative IP address, the client can minimize the number of accidental delays it introduces (see also Sections 3.1 and 4.5) 🫶

Here's an example. Imagine an authoritative server named ns0.example.com served by two installations: one at 2001:db8::7 that follows this guidance, and one at 2001:db8::8 that's a legacy (cleartext port 53-only) deployment. A recursive client that associates state with the NS name and reaches 2001:db8::7 first will "learn" that ns0.example.com supports encrypted transport. A later query over encrypted transport sent to 2001:db8::8 would fail, and could delay the response. Plot twist 😱

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 means how long the recursive resolver will remember that an authoritative server had a successful connection over DoT 🧠 Also, when describing an arbitrary encrypted transport, we use E in place of <transport> to generically mean whichever encrypted transport is in use. So when handling a query sent over encrypted transport E, a reference to E-timeout means DoT-timeout if the query is sent over DoT, and DoQ-timeout if it's 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. That list is called Do53-queries[X]. This document doesn't try to describe how sending and receiving cleartext DNS queries (Do53) actually works for a recursive resolver. Instead, it describes a "bolt-on" mechanism that extends the recursive resolver's operation through a few simple hooks into its existing Do53 handling 🔌

Implementers or deployers of DNS recursive resolvers that follow the strategies in this document are encouraged to publish their preferred values for 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. Locking the door to localhost is fine, but otherwise let the clients in, bestie 🌸

4.5. Authoritative Server Encrypted Transport Connection State ✨

okay so bestie, the recursive resolver SHOULD keep a record of the state for each authoritative server it contacts 💖 indexed by the IP address of that authoritative server and the encrypted transports the recursive resolver supports. it's giving organized little notebook energy 📓🎀

ngl the recursive resolver might record this per-authoritative-IP state for each source IP address it uses when it sends queries 🦋 like, if a recursive resolver can send packets to authoritative servers from 2001:db8::100 and 2001:db8::200, it could keep two separate sets of per-authoritative-IP state, one for each source address it uses, as long as it knows which addresses are in use 🌸 keeping these state tables separate for each source address is what lets a pooled authoritative server behind a load balancer do a partial rollout without causing accidental timeouts 😭 (see Section 3.1) iconic.

highkey, a recursive resolver SHOULD also record the state of established sessions for encrypted protocols 🔥 on top of tracking connection attempts and outcomes. how sessions get identified depends on the transport implementation (like a TLS session ticket or TLS session ID, a QUIC connection ID, and so on) 🧚 session resumption as recommended here is kinda limited, because the tickets only live inside the context defined by the (clientIP, serverIP, protocols) tuples the recursive resolver uses to track client-server interaction in a table like the one below 💅 but honestly? resumption can still make the handshake faster in some situations ✨

each record should contain the following fields for each supported encrypted transport, and every one of them starts out 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 all the session fields together make up a pool of open connections to different servers 🫶

except for session, queries, and last-activity, this cache info should stick around across a server restart 💜 unless an administrator explicitly clears it 🙈

this document uses the notation E-foo[X] to mean the value of field foo for encrypted transport E at IP address X 🍓 so for example, DoT-initiated[192.0.2.4] is the timestamp of the most recent DoT connection packet sent to IP address 192.0.2.4 ✨

this document also uses any-E-queries to mean any query on an encrypted transport 🌸

4.6. Probing Policy 🔥

okay bestie, when a recursive resolver finds it needs an authoritative lookup to an authoritative DNS server at IP address X, it pulls the connection state records from Section 4.5 for X out of its cache 💅

some of the subsections below have pseudocode that roughly matches an asynchronous programming model for how a recursive resolver talks to authoritative servers 🧚 all of them also assume the time it discovered the need for the lookup is T0 ⏰

if any of these records are missing, they're treated as null 🫶

the recursive resolver MUST decide whether to send its first query over Do53, or over either of the supported encrypted transports (DoT or DoQ) 💖

and ngl, a recursive resolver might start this query on any or all of the known transports 🦋 when it sends multiple queries, the initial packets for each connection can go out concurrently, kinda like the "Happy Eyeballs" method ([RFC8305]) 🌈 but unlike Happy Eyeballs, when one transport succeeds, the other connections don't have to be killed off 💀 instead they can keep going to figure out whether IP address X can communicate over the relevant transport too ✨

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 these is true:

  • E-session[X] is in the established state, or
  • E-status[X] is success and (T0 - E-last-response[X]) < persistence.

this basically means that one successful connection to a server that the client then closed cleanly results in the client not sending the next query over Do53 😤✨

otherwise, if there's no outstanding session for any encrypted transport, and the last successful encrypted transport connection was a long time ago, the recursive resolver sends a query to X over Do53 🌸 when it does, it inserts a handle for the query into Do53-queries[X] 💜

4.6.2. Receiving a Response over Do53 🦋

when any response R (a well-formed DNS response, an asynchronous timeout, an asynchronous destination port unreachable, etc.) for query Q shows up at the recursive resolver in cleartext sent over Do53 from an authoritative server with IP address X, the recursive resolver SHOULD do 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 isn't outstanding) 🙅‍♀️

otherwise, if Q was already marked as 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
      • mark Q as already processed. ✅

but 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 start a new connection or resume a previous one to X over Do53 or E 🙅‍♀️ it 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 one is in the established state, it MAY also start a new connection to X over its preferred encrypted transport 🌈 while it concurrently sends the query over the established encrypted transport E 💖

before thinking about starting a new connection over an encrypted transport, the timer should be checked, 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 try a new encrypted transport, the recursive resolver SHOULD only start a new connection to X over E as long as one of these is 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 starting a session to X over encrypted transport E, if E-resumptions[X] isn't 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 starting a connection, the recursive resolver SHOULD take these 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 into 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 can send "early data" from the client in the initial ClientHello in some contexts 🔥 a recursive resolver that starts a connection over an encrypted transport following this guidance, in a context where early data is possible, SHOULD send the DNS query that prompted the connection as early data, following the sending guidance in Section 4.6.8 💅

if it does, the status of Q in E-queries[X] should be set to early instead of unsent ✨

4.6.3.2. Resumption Tickets 💜

when starting a new connection (whether it resumes 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 onto the stack at E-resumptions[X] 🦋

4.6.3.3. Server Name Indication 🎀

Okay bestie, 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 picking or sending an SNI during this unilateral probing 💅

  • Some authoritative servers are known by more than one name, so choosing a single name 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. That can reveal extra info about which query is being made, based on the NS of the query itself 👀

To avoid extra 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 can't 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, because 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
      • sets the status of Q to sent.
    • Otherwise:
      • 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
      • 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 🔒✨

okay so the guidance in this doc gives you defense against passive network monitors for most queries 👀 but it does NOT stop active attackers 🙅‍♀️. It can also leak some queries and their responses because of Happy Eyeballs optimizations ([RFC8305]) when the recursive resolver's cache is cold 💀.

Implementing this guidance should increase deployment of opportunistic encrypted DNS transport between recursive resolvers and authoritative servers, with little operational risk 🫶🌈 that's the slay part!!

BUT, bestie, implementers cannot rely on this guidance for robust defense against active attackers. Treat it as a stepping stone en route to stronger defense 🪜💖

Like, a recursive resolver following this guidance can be easily 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, because there's no server authentication 💔. Defending against these attacks without risking extra unexpected protocol failures would need signaling and coordination, and that's out of scope for this document 🙈

This guidance is only one part of running a privacy-preserving DNS ecosystem. A privacy-preserving recursive resolver should adopt other practices too, like QNAME minimization ([RFC9156]), the 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 at IP addresses associated with NS records 👀. Honestly, this kind of probing of an authoritative server should generally not cause any significant problems 🤷‍♀️. If the authoritative server isn't supporting this protocol, it won't respond on port 853. If it IS supporting this protocol, it'll act accordingly 💅

Now here's the plot twist 🎭 a system that's a public recursive resolver supporting DoT and/or DoQ might also have an IP address associated with NS records. This could be accidental (like a glue record with the wrong target address) or intentional 😬. In that case, a recursive resolver following this protocol will look for authoritative answers on ports 53 and 853 at that IP address. Also, the DNS server answering on port 853 would need to be able to tell apart queries for recursive answers from queries for authoritative answers, for example by having the authoritative server handle all queries that have the Recursion Desired (RD) flag unset 🧐

As discussed in Section 7, the protocol in this document provides no defense against active attackers. On a network where a captive portal is operating, some communications may be actively intercepted, like when the network tries to redirect a user to finish an interaction with a captive portal server 🚧. So a recursive resolver operating on a node that does 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 doc is an Experimental RFC 🔬 so to figure out if the experiment is working, the technical community could collect some key metrics about how this protocol gets deployed. These metrics would 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 in this doc provides NO defense against active attackers 😤 (okay yes I'm yelling, but it's important). A future protocol for recursive-to-authoritative DNS might want to provide that protection 🔮

This appendix assumes the use case for that future protocol is a recursive resolver that wants to stop an active attack on communication between itself 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 can't 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) hasn't made that commitment 🙅‍♀️. And no recursive resolver that prioritizes delivering DNS records to its clients would want to "fail closed" unilaterally 💀

Therefore, a future protocol like that would need at least three major distinctions from the protocol 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 can't 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 😰. So a signaling mechanism probably should also offer a way 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.3. Combining Protocols 🤝

If this protocol gets reasonable adoption, and a newer protocol that can defend against an active attacker shows up, deployment is likely to be staggered and incomplete. So an operator who 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. That way operators aren't stuck choosing between widespread opportunistic protection against passive attackers (this document) and more narrowly targeted protection against active attackers. 🦋

B.2. Authentication of Authoritative Servers 🔐

Okay bestie, here are some forms of server authentication that might be on the table: ✨

  • 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 it does, the identity would presumably be based on the NS name used for a given query or the IP address of the server. 🫶

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
📦 where this page comes from