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 authoritative server.¶
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 192.0.2.100
and 192.0.2.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 is dependent on the transport protocol implementation (such as TLS session ticket or TLS session ID, 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
:¶
Table 2:
Recursive resolver state per authoritative IP, per encrypted transport
Name |
Description |
Retain Across Restart |
session
|
The associated state of any existing, 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
|
no |
initiated
|
Timestamp of most recent connection attempt |
yes |
completed
|
Timestamp of most recent completed handshake (which can include one where an existing session is resumed) |
yes |
status
|
Enumerated value of success or fail or timeout , associated with the completed handshake |
yes |
last-response
|
A timestamp of the most recent response received on the connection |
yes |
resumptions
|
A stack of resumption tickets (and associated parameters) that could be used to resume a prior successful session |
yes |
queries
|
A queue of queries intended for this authoritative server, each of which has additional status early , unsent , or sent
|
no |
last-activity
|
A timestamp of the most recent activity on the connection |
no |
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.¶