When a recursive resolver discovers the need for an authoritative lookup to an authoritative DNS server using IP address
X, it retrieves the records associated with
X from its cache.¶
The following sections presume that the time of the discovery of the need for lookup is time
The recursive resolver must decide whether to initially send a query over Do53, or over any of the supported encrypted transports (DoT or DoQ).¶
Note that a 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 "Happy Eyeballs" ([RFC8305]).
However, unlike Happy Eyeballs, when one transport succeeds, the other connections do not need to be terminated, but can instead be continued to establish whether the IP address
X is capable of communicating on the relevant transport.¶
For any of the supported encrypted transports
E, if either of the following holds true, the resolver SHOULD NOT send a query to
X over Do53:¶
E-session[X] is in the
established state, or¶
(T0 - E-last-response[X]) < persistence¶
Otherwise, if there is no outstanding session for any encrypted transport, and the last successful encrypted transport connection was long ago, the resolver sends a query to
X over Do53.
When it does so, it inserts a handle for the query in
E-session[X] is in the
established state, the recursive resolver SHOULD NOT initiate a new 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 has a preferred encrypted transport, but only a different transport is in the
established state, it MAY also initiate a new connection to
X over its preferred transport while concurrently sending the query over the
Before considering whether to initiate a new connection over an encrypted transport, the timer should examine and possibly refresh its state for encrypted transport
E to authoritative IP address
When resources are available to attempt a new encrypted transport, the resolver should only initiate a new connection to
E as long as one of the following holds true:¶
(T0 - E-completed[X]) > damping, or¶
When initiating a session to
X over encrypted transport
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 Client Hello handshake should not try to resume any session.¶
When initiating a connection, the resolver should take the following steps:¶
- store a handle for the new session (which should have
pending state) in
- insert a handle for the query that prompted this connection in
E-queries[X], with status
early, as appropriate (see below).¶
Modern encrypted transports like TLS 1.3 offer the chance to store "early data" from the client into the initial Client Hello in some contexts.
A resolver that initiates a connection over a 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
E-queries[X] should be set to
early instead of
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
For modern encrypted transports like TLS 1.3, most client implementations expect to send a Server Name Indication (SNI) in the Client Hello.¶
There are two complications with selecting or sending 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 is 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 SNI to the authoritative when attempting encrypted transport.¶
If the recursive resolver needs to send SNI to the authoritative for some reason not found in this document, it is RECOMMENDED that it implements Encrypted Client Hello ([I-D.ietf-tls-esni]) to reduce leakage.¶
Once established, an encrypted transport might fail for a number of reasons (e.g., decryption failure, or improper protocol sequence).¶
If this happens:¶
Note that this failure will trigger the recursive resolver to fall back to cleartext queries to the authoritative server at IP address
It will retry encrypted transport to
X once the
damping timer has elapsed.¶
For example, What if a TCP timeout closes an idle DoT connection?
What if a QUIC stream ends up timing out but other streams on the same QUIC connection are going through?
Do the described scenarios cover the case when an encrypted transport's port is made unavailable/closed?¶
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
The recursive resolver also sets
In addition, the recursive resolver should consider the guidance in the following sections.¶
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 EDNS(0) 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].¶
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 [RFC7766] (for DoT) and [RFC9250] (for DoQ).¶
To keep resources under control, a recursive resolver should proactively manage outstanding encrypted connections.
Section 6.5 of [RFC9250] ("Connection Handling") 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:¶
- close outstanding
established sessions based on
E-last-activity[X] (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.¶
Some recursive resolvers looking to amortize connection costs, and to minimize latency MAY choose to synthesize queries to a particular resolver to keep a 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.¶