Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 8490 ISC
Updates: 1035, 7766 S. Cheshire
Category: Standards Track Apple Inc.
ISSN: 2070-1721 J. Dickinson
S. Dickinson
Sinodun
T. Lemon
Nibbhaya Consulting
T. Pusateri
Unaffiliated
March 2019
Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 8490 ISC
Updates: 1035, 7766 S. Cheshire
Category: Standards Track Apple Inc.
ISSN: 2070-1721 J. Dickinson
S. Dickinson
Sinodun
T. Lemon
Nibbhaya Consulting
T. Pusateri
Unaffiliated
March 2019
DNS Stateful Operations
DNS有状态操作
Abstract
摘要
This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.
本文档为DNS有状态操作（DSO）定义了一个新的DNS操作码。DSO消息使用类型长度值（TLV）语法在持久有状态会话中通信操作。定义了三个TLV来管理会话超时、终止和加密填充，并为扩展定义了一个框架来支持新的有状态操作。本文档通过添加新的DNS头操作码来更新RFC1035，该操作码具有不同的消息语义和新的结果代码。本文档通过重新定义会话、提供关于连接重用的新指导以及提供处理会话空闲超时的新机制来更新RFC 7766。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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/rfc8490.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8490.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Session Management . . . . . . . . . . . . . . . . . 9
4.1.2. Long-Lived Subscriptions . . . . . . . . . . . . . . 9
4.2. Applicable Transports . . . . . . . . . . . . . . . . . . 10
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11
5.1. DSO Session Establishment . . . . . . . . . . . . . . . . 12
5.1.1. DSO Session Establishment Failure . . . . . . . . . . 13
5.1.2. DSO Session Establishment Success . . . . . . . . . . 14
5.2. Operations after DSO Session Establishment . . . . . . . 14
5.3. DSO Session Termination . . . . . . . . . . . . . . . . . 15
5.3.1. Handling Protocol Errors . . . . . . . . . . . . . . 15
5.4. Message Format . . . . . . . . . . . . . . . . . . . . . 16
5.4.1. DNS Header Fields in DSO Messages . . . . . . . . . . 17
5.4.2. DSO Data . . . . . . . . . . . . . . . . . . . . . . 18
5.4.3. DSO Unidirectional Messages . . . . . . . . . . . . . 20
5.4.4. TLV Syntax . . . . . . . . . . . . . . . . . . . . . 21
5.4.5. Unrecognized TLVs . . . . . . . . . . . . . . . . . . 22
5.4.6. EDNS(0) and TSIG . . . . . . . . . . . . . . . . . . 23
5.5. Message Handling . . . . . . . . . . . . . . . . . . . . 24
5.5.1. Delayed Acknowledgement Management . . . . . . . . . 25
5.5.2. MESSAGE ID Namespaces . . . . . . . . . . . . . . . . 26
5.5.3. Error Responses . . . . . . . . . . . . . . . . . . . 27
5.6. Responder-Initiated Operation Cancellation . . . . . . . 28
6. DSO Session Lifecycle and Timers . . . . . . . . . . . . . . 29
6.1. DSO Session Initiation . . . . . . . . . . . . . . . . . 29
6.2. DSO Session Timeouts . . . . . . . . . . . . . . . . . . 30
6.3. Inactive DSO Sessions . . . . . . . . . . . . . . . . . . 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Session Management . . . . . . . . . . . . . . . . . 9
4.1.2. Long-Lived Subscriptions . . . . . . . . . . . . . . 9
4.2. Applicable Transports . . . . . . . . . . . . . . . . . . 10
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 11
5.1. DSO Session Establishment . . . . . . . . . . . . . . . . 12
5.1.1. DSO Session Establishment Failure . . . . . . . . . . 13
5.1.2. DSO Session Establishment Success . . . . . . . . . . 14
5.2. Operations after DSO Session Establishment . . . . . . . 14
5.3. DSO Session Termination . . . . . . . . . . . . . . . . . 15
5.3.1. Handling Protocol Errors . . . . . . . . . . . . . . 15
5.4. Message Format . . . . . . . . . . . . . . . . . . . . . 16
5.4.1. DNS Header Fields in DSO Messages . . . . . . . . . . 17
5.4.2. DSO Data . . . . . . . . . . . . . . . . . . . . . . 18
5.4.3. DSO Unidirectional Messages . . . . . . . . . . . . . 20
5.4.4. TLV Syntax . . . . . . . . . . . . . . . . . . . . . 21
5.4.5. Unrecognized TLVs . . . . . . . . . . . . . . . . . . 22
5.4.6. EDNS(0) and TSIG . . . . . . . . . . . . . . . . . . 23
5.5. Message Handling . . . . . . . . . . . . . . . . . . . . 24
5.5.1. Delayed Acknowledgement Management . . . . . . . . . 25
5.5.2. MESSAGE ID Namespaces . . . . . . . . . . . . . . . . 26
5.5.3. Error Responses . . . . . . . . . . . . . . . . . . . 27
5.6. Responder-Initiated Operation Cancellation . . . . . . . 28
6. DSO Session Lifecycle and Timers . . . . . . . . . . . . . . 29
6.1. DSO Session Initiation . . . . . . . . . . . . . . . . . 29
6.2. DSO Session Timeouts . . . . . . . . . . . . . . . . . . 30
6.3. Inactive DSO Sessions . . . . . . . . . . . . . . . . . . 31
6.4. The Inactivity Timeout . . . . . . . . . . . . . . . . . 32
6.4.1. Closing Inactive DSO Sessions . . . . . . . . . . . . 32
6.4.2. Values for the Inactivity Timeout . . . . . . . . . . 33
6.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 34
6.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 34
6.5.2. Values for the Keepalive Interval . . . . . . . . . . 34
6.6. Server-Initiated DSO Session Termination . . . . . . . . 36
6.6.1. Server-Initiated Retry Delay Message . . . . . . . . 37
6.6.2. Misbehaving Clients . . . . . . . . . . . . . . . . . 38
6.6.3. Client Reconnection . . . . . . . . . . . . . . . . . 38
7. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 40
7.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 40
7.1.1. Client Handling of Received Session Timeout Values . 42
7.1.2. Relationship to edns-tcp-keepalive EDNS(0) Option . . 43
7.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 44
7.2.1. Retry Delay TLV Used as a Primary TLV . . . . . . . . 44
7.2.2. Retry Delay TLV Used as a Response Additional TLV . . 46
7.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 46
8. Summary Highlights . . . . . . . . . . . . . . . . . . . . . 47
8.1. QR Bit and MESSAGE ID . . . . . . . . . . . . . . . . . . 47
8.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Additional Considerations . . . . . . . . . . . . . . . . . . 50
9.1. Service Instances . . . . . . . . . . . . . . . . . . . . 50
9.2. Anycast Considerations . . . . . . . . . . . . . . . . . 51
9.3. Connection Sharing . . . . . . . . . . . . . . . . . . . 52
9.4. Operational Considerations for Middleboxes . . . . . . . 53
9.5. TCP Delayed Acknowledgement Considerations . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
10.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . 57
10.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 57
10.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 57
11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
11.1. TLS Zero Round-Trip Considerations . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
6.4. The Inactivity Timeout . . . . . . . . . . . . . . . . . 32
6.4.1. Closing Inactive DSO Sessions . . . . . . . . . . . . 32
6.4.2. Values for the Inactivity Timeout . . . . . . . . . . 33
6.5. The Keepalive Interval . . . . . . . . . . . . . . . . . 34
6.5.1. Keepalive Interval Expiry . . . . . . . . . . . . . . 34
6.5.2. Values for the Keepalive Interval . . . . . . . . . . 34
6.6. Server-Initiated DSO Session Termination . . . . . . . . 36
6.6.1. Server-Initiated Retry Delay Message . . . . . . . . 37
6.6.2. Misbehaving Clients . . . . . . . . . . . . . . . . . 38
6.6.3. Client Reconnection . . . . . . . . . . . . . . . . . 38
7. Base TLVs for DNS Stateful Operations . . . . . . . . . . . . 40
7.1. Keepalive TLV . . . . . . . . . . . . . . . . . . . . . . 40
7.1.1. Client Handling of Received Session Timeout Values . 42
7.1.2. Relationship to edns-tcp-keepalive EDNS(0) Option . . 43
7.2. Retry Delay TLV . . . . . . . . . . . . . . . . . . . . . 44
7.2.1. Retry Delay TLV Used as a Primary TLV . . . . . . . . 44
7.2.2. Retry Delay TLV Used as a Response Additional TLV . . 46
7.3. Encryption Padding TLV . . . . . . . . . . . . . . . . . 46
8. Summary Highlights . . . . . . . . . . . . . . . . . . . . . 47
8.1. QR Bit and MESSAGE ID . . . . . . . . . . . . . . . . . . 47
8.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Additional Considerations . . . . . . . . . . . . . . . . . . 50
9.1. Service Instances . . . . . . . . . . . . . . . . . . . . 50
9.2. Anycast Considerations . . . . . . . . . . . . . . . . . 51
9.3. Connection Sharing . . . . . . . . . . . . . . . . . . . 52
9.4. Operational Considerations for Middleboxes . . . . . . . 53
9.5. TCP Delayed Acknowledgement Considerations . . . . . . . 54
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
10.1. DSO OPCODE Registration . . . . . . . . . . . . . . . . 57
10.2. DSO RCODE Registration . . . . . . . . . . . . . . . . . 57
10.3. DSO Type Code Registry . . . . . . . . . . . . . . . . . 57
11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
11.1. TLS Zero Round-Trip Considerations . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
This document specifies a mechanism for managing stateful DNS connections. DNS most commonly operates over a UDP transport, but it can also operate over streaming transports; the original DNS RFC specifies DNS-over-TCP [RFC1035], and a profile for DNS-over-TLS [RFC7858] has been specified. These transports can offer persistent long-lived sessions and therefore, when using them for transporting DNS messages, it is of benefit to have a mechanism that can establish parameters associated with those sessions, such as timeouts. In such situations, it is also advantageous to support server-initiated messages (such as DNS Push Notifications [Push]).
本文档指定了管理有状态DNS连接的机制。DNS通常通过UDP传输进行操作，但也可以通过流传输进行操作；原始DNS RFC指定通过TCP的DNS[RFC1035]，并且已指定通过TLS的DNS[RFC7858]的配置文件。这些传输可以提供持久的长寿命会话，因此，当使用它们传输DNS消息时，有一种机制可以建立与这些会话相关的参数（例如超时）是有益的。在这种情况下，支持服务器启动的消息（例如DNS推送通知[Push]）也是有利的。
The existing Extension Mechanism for DNS (EDNS(0)) [RFC6891] is explicitly defined to only have "per-message" semantics. While EDNS(0) has been used to signal at least one session-related parameter (edns-tcp-keepalive EDNS(0) Option [RFC7828]), the result is less than optimal due to the restrictions imposed by the EDNS(0) semantics and the lack of server-initiated signaling. For example, a server cannot arbitrarily instruct a client to close a connection because the server can only send EDNS(0) options in responses to queries that contained EDNS(0) options.
DNS（EDNS（0））[RFC6891]的现有扩展机制被明确定义为仅具有“每条消息”语义。虽然EDNS（0）已被用于向至少一个会话相关参数（EDNS tcp keepalive EDNS（0）选项[RFC7828]）发送信号，但由于EDNS（0）语义施加的限制以及缺少服务器启动的信令，结果并非最佳。例如，服务器不能任意指示客户端关闭连接，因为服务器只能在响应包含EDNS（0）选项的查询时发送EDNS（0）选项。
This document defines a new DNS OPCODE for DNS Stateful Operations (DSO) with a value of 6. DSO messages are used to communicate operations within persistent stateful sessions, expressed using Type Length Value (TLV) syntax. This document defines an initial set of three TLVs used to manage session timeouts, termination, and encryption padding.
本文档为DNS有状态操作（DSO）定义了一个新的DNS操作码，其值为6。DSO消息用于在使用类型长度值（TLV）语法表示的持久有状态会话中通信操作。本文档定义了三个TLV的初始集合，用于管理会话超时、终止和加密填充。
All three TLVs defined here are mandatory for all implementations of DSO. Further TLVs may be defined in additional specifications.
这里定义的所有三个TLV对于DSO的所有实现都是必需的。其他TLV可在附加规范中定义。
DSO messages may or may not be acknowledged. Whether a DSO message is to be acknowledged (a DSO request message) or is not to be acknowledged (a DSO unidirectional message) is specified in the definition of that particular DSO message type. The MESSAGE ID is nonzero for DSO request messages, and zero for DSO unidirectional messages. Messages are pipelined and responses may appear out of order when multiple requests are being processed concurrently.
DSO消息可能会被确认，也可能不会被确认。在该特定DSO消息类型的定义中指定是确认DSO消息（DSO请求消息）还是不确认DSO消息（DSO单向消息）。对于DSO请求消息，消息ID为非零，对于DSO单向消息，消息ID为零。当同时处理多个请求时，消息是管道化的，响应可能会出现无序。
The format for DSO messages (Section 5.4) differs somewhat from the traditional DNS message format used for standard queries and responses. The standard twelve-byte header is used, but the four count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) are set to zero, and accordingly their corresponding sections are not present.
DSO消息的格式（第5.4节）与用于标准查询和响应的传统DNS消息格式有所不同。使用标准的十二字节报头，但四个计数字段（QDCOUNT、ANCOUNT、NSCOUNT、ARCOUNT）被设置为零，因此它们相应的部分不存在。
The actual data pertaining to DNS Stateful Operations (expressed in TLV syntax) is appended to the end of the DNS message header. Just as in traditional DNS-over-TCP [RFC1035] [RFC7766], the stream protocol carrying DSO messages (which are just another kind of DNS message) frames them by putting a 16-bit message length at the start. The length of the DSO message is therefore determined from that length rather than from any of the DNS header counts.
与DNS有状态操作相关的实际数据（以TLV语法表示）附加到DNS消息头的末尾。正如传统的TCP上的DNS[RFC1035][RFC7766]一样，承载DSO消息（这只是另一种DNS消息）的流协议通过在开始处放置16位消息长度来对其进行帧化。因此，DSO消息的长度是根据该长度而不是任何DNS报头计数来确定的。
When displayed using packet analyzer tools that have not been updated to recognize the DSO format, this will result in the DSO data being displayed as unknown extra data after the end of the DNS message.
当使用尚未更新以识别DSO格式的数据包分析器工具显示时，这将导致DSO数据在DNS消息结束后显示为未知额外数据。
This new format has distinct advantages over an RR-based format because it is more explicit and more compact. Each TLV definition is specific to its use case and, as a result, contains no redundant or overloaded fields. Importantly, it completely avoids conflating DNS Stateful Operations in any way with normal DNS operations or with existing EDNS(0)-based functionality. A goal of this approach is to avoid the operational issues that have befallen EDNS(0), particularly relating to middlebox behavior (see sections discussing EDNS(0), and problems caused by firewalls and load balancers, in the recent work describing causes of DNS failures [Fail]).
与基于RR的格式相比，这种新格式具有明显的优势，因为它更明确、更紧凑。每个TLV定义都特定于其用例，因此不包含冗余或重载字段。重要的是，它完全避免了以任何方式将DNS有状态操作与正常DNS操作或现有基于EDN（0）的功能混为一谈。此方法的目标是避免EDN（0）遇到的操作问题，特别是与中间盒行为有关的问题（请参阅在最近描述DNS故障原因的工作中讨论EDN（0）以及防火墙和负载平衡器引起的问题[Fail]）。
With EDNS(0), multiple options may be packed into a single OPT pseudo-RR, and there is no generalized mechanism for a client to be able to tell whether a server has processed or otherwise acted upon each individual option within the combined OPT pseudo-RR. The specifications for each individual option need to define how each different option is to be acknowledged, if necessary.
使用EDN（0），可以将多个选项打包到单个OPT伪RR中，并且客户端没有通用的机制来判断服务器是否已处理或以其他方式对组合的OPT伪RR中的每个单独选项进行了操作。如有必要，每个单独选项的规范需要定义如何确认每个不同选项。
In contrast to EDNS(0), with DSO there is no compelling motivation to pack multiple operations into a single message for efficiency reasons, because DSO always operates using a connection-oriented transport protocol. Each DSO operation is communicated in its own separate DNS message, and the transport protocol can take care of packing several DNS messages into a single IP packet if appropriate. For example, TCP can pack multiple small DNS messages into a single TCP segment. This simplification allows for clearer semantics. Each DSO request message communicates just one primary operation, and the RCODE in the corresponding response message indicates the success or failure of that operation.
与EDN（0）相比，使用DSO时，出于效率原因，没有令人信服的动机将多个操作打包到单个消息中，因为DSO始终使用面向连接的传输协议进行操作。每个DSO操作都在其单独的DNS消息中进行通信，如果合适，传输协议可以负责将多个DNS消息打包到单个IP数据包中。例如，TCP可以将多个小型DNS消息打包到单个TCP段中。这种简化允许更清晰的语义。每个DSO请求消息只传递一个主要操作，相应响应消息中的RCODE指示该操作的成功或失败。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
DSO: DNS Stateful Operations.
DSO:DNS有状态操作。
connection: a bidirectional byte (or message) stream, where the bytes (or messages) are delivered reliably and in order, such as provided by using DNS-over-TCP [RFC1035] [RFC7766] or DNS-over-TLS [RFC7858].
连接：一种双向字节（或消息）流，其中字节（或消息）按顺序可靠地传递，例如通过TCP[RFC1035][RFC7766]上的DNS或TLS[RFC7858]上的DNS提供。
session: the unqualified term "session" in the context of this document refers to a persistent network connection between two endpoints that allows for the exchange of DNS messages over a connection where either end of the connection can send messages to the other end. (The term has no relationship to the "session layer" of the OSI "seven-layer model".)
会话：本文档上下文中的非限定术语“会话”是指两个端点之间的持久网络连接，允许通过连接交换DNS消息，其中连接的任何一端都可以向另一端发送消息。（该术语与OSI“七层模型”的“会话层”无关。）
DSO Session: a session established between two endpoints that acknowledge persistent DNS state via the exchange of DSO messages over the connection. This is distinct from a DNS-over-TCP session as described in the previous specification for DNS-over-TCP [RFC7766].
DSO会话：在两个端点之间建立的会话，通过连接上的DSO消息交换确认持久DNS状态。这不同于先前的TCP上的DNS规范[RFC7766]中描述的TCP上的DNS会话。
close gracefully: a normal session shutdown where the client closes the TCP connection to the server using a graceful close such that no data is lost (e.g., using TCP FIN; see Section 5.3).
优雅地关闭：一种正常的会话关闭，客户端使用优雅的关闭方式关闭与服务器的TCP连接，从而不会丢失任何数据（例如，使用TCP FIN；参见第5.3节）。
forcibly abort: a session shutdown as a result of a fatal error where the TCP connection is unilaterally aborted without regard for data loss (e.g., using TCP RST; see Section 5.3).
强制中止：由于致命错误导致的会话关闭，其中TCP连接在不考虑数据丢失的情况下单方面中止（例如，使用TCP RST；参见第5.3节）。
server: the software with a listening socket, awaiting incoming connection requests, in the usual DNS sense.
服务器：在通常的DNS意义上，带有监听套接字的软件，等待传入的连接请求。
client: the software that initiates a connection to the server's listening socket, in the usual DNS sense.
客户端：在通常的DNS意义上，启动到服务器侦听套接字的连接的软件。
initiator: the software that sends a DSO request message or a DSO unidirectional message during a DSO Session. Either a client or server can be an initiator.
启动器：在DSO会话期间发送DSO请求消息或DSO单向消息的软件。客户机或服务器都可以是启动器。
responder: the software that receives a DSO request message or a DSO unidirectional message during a DSO Session. Either a client or a server can be a responder.
应答器：在DSO会话期间接收DSO请求消息或DSO单向消息的软件。客户机或服务器都可以是响应者。
sender: the software that is sending a DNS message, a DSO message, a DNS response, or a DSO response.
发送方：发送DNS消息、DSO消息、DNS响应或DSO响应的软件。
receiver: the software that is receiving a DNS message, a DSO message, a DNS response, or a DSO response.
接收器：接收DNS消息、DSO消息、DNS响应或DSO响应的软件。
service instance: a specific instance of server software running on a specific host (Section 9.1).
服务实例：在特定主机上运行的服务器软件的特定实例（第9.1节）。
long-lived operation: an outstanding operation on a DSO Session where either the client or server, acting as initiator, has requested that the responder send new information regarding the request, as it becomes available.
长寿命操作：DSO会话上的一种未完成操作，其中作为启动器的客户端或服务器请求响应者在请求可用时发送有关该请求的新信息。
early data: a TLS 1.3 handshake containing data on the first flight that begins a DSO Session (Section 2.3 of the TLS 1.3 specification [RFC8446]). TCP Fast Open [RFC7413] is only permitted when using TLS.
早期数据：TLS 1.3握手，包含开始DSO会话的第一次航班上的数据（TLS 1.3规范[RFC8446]第2.3节）。只有在使用TLS时才允许TCP快速打开[RFC7413]。
DNS message: any DNS message, including DNS queries, responses, updates, DSO messages, etc.
DNS消息：任何DNS消息，包括DNS查询、响应、更新、DSO消息等。
DNS request message: any DNS message where the QR bit is 0.
DNS请求消息：QR位为0的任何DNS消息。
DNS response message: any DNS message where the QR bit is 1.
DNS响应消息：QR位为1的任何DNS消息。
DSO message: a DSO request message, DSO unidirectional message, or DSO response to a DSO request message. If the QR bit is 1 in a DSO message, it is a DSO response message. If the QR bit is 0 in a DSO message, it is a DSO request message or DSO unidirectional message, as determined by the specification of its Primary TLV.
DSO消息：DSO请求消息、DSO单向消息或DSO对DSO请求消息的响应。如果DSO消息中QR位为1，则为DSO响应消息。如果DSO消息中的QR位为0，则它是DSO请求消息或DSO单向消息，由其主要TLV的规格确定。
DSO response message: a response to a DSO request message.
DSO响应消息：对DSO请求消息的响应。
DSO request message: a DSO message that requires a response.
DSO请求消息：需要响应的DSO消息。
DSO unidirectional message: a DSO message that does not require and cannot induce a response.
DSO单向消息：不需要且不能引发响应的DSO消息。
Primary TLV: the first TLV in a DSO request message or DSO unidirectional message; this determines the nature of the operation being performed.
主TLV：DSO请求消息或DSO单向消息中的第一个TLV；这决定了正在执行的操作的性质。
Additional TLV: any TLVs that follow the Primary TLV in a DSO request message or DSO unidirectional message.
附加TLV：在DSO请求消息或DSO单向消息中跟随主TLV的任何TLV。
Response Primary TLV: in a DSO response, any TLVs with the same DSO-TYPE as the Primary TLV from the corresponding DSO request message. If present, any Response Primary TLV(s) MUST appear first in the DSO response message, before any Response Additional TLVs.
响应主TLV：在DSO响应中，与来自相应DSO请求消息的主TLV具有相同DSO类型的任何TLV。如果存在，任何响应主TLV必须首先出现在DSO响应消息中，然后再出现任何响应附加TLV。
Response Additional TLV: any TLVs in a DSO response that follow the (optional) Response Primary TLV(s).
响应附加TLV：DSO响应中（可选）响应主TLV之后的任何TLV。
inactivity timer: the time since the most recent non-keepalive DNS message was sent or received (see Section 6.4).
非活动计时器：自发送或接收最近的非保留DNS消息以来的时间（见第6.4节）。
keepalive timer: the time since the most recent DNS message was sent or received (see Section 6.5).
keepalive timer：自发送或接收最新DNS消息以来的时间（参见第6.5节）。
session timeouts: the inactivity timer and the keepalive timer.
会话超时：不活动计时器和保持活动计时器。
inactivity timeout: the maximum value that the inactivity timer can have before the connection is gracefully closed.
非活动超时：在正常关闭连接之前，非活动计时器可以具有的最大值。
keepalive interval: the maximum value that the keepalive timer can have before the client is required to send a keepalive (see Section 7.1).
keepalive interval：在要求客户端发送keepalive之前，keepalive计时器可以具有的最大值（参见第7.1节）。
resetting a timer: setting the timer value to zero and restarting the timer.
重置计时器：将计时器值设置为零并重新启动计时器。
clearing a timer: setting the timer value to zero but not restarting the timer.
清除计时器：将计时器值设置为零，但不重新启动计时器。
DNS Stateful Operations are applicable to several known use cases and are only applicable on transports that are capable of supporting a DSO Session.
DNS有状态操作适用于几种已知的用例，并且仅适用于能够支持DSO会话的传输。
Several use cases for DNS Stateful Operations are described below.
DNS有状态操作的几个用例如下所述。
In one use case, establishing session parameters such as server-defined timeouts is of great use in the general management of persistent connections. For example, using DSO Sessions for stub-to-recursive DNS-over-TLS [RFC7858] is more flexible for both the client and the server than attempting to manage sessions using just the edns-tcp-keepalive EDNS(0) Option [RFC7828]. The simple set of TLVs defined in this document is sufficient to greatly enhance connection management for this use case.
在一个用例中，建立会话参数（如服务器定义的超时）在持久连接的一般管理中非常有用。例如，与仅使用edns tcp keepalive edns（0）选项[RFC7828]管理会话相比，对客户端和服务器而言，将DSO会话用于TLS[RFC7858]上的存根到递归DNS更为灵活。本文档中定义的一组简单的TLV足以大大增强此用例的连接管理。
In another use case, DNS-based Service Discovery (DNS-SD) [RFC6763] has evolved into a naturally session-based mechanism where, for example, long-lived subscriptions lend themselves to 'push' mechanisms as opposed to polling. Long-lived stateful connections and server-initiated messages align with this use case [Push].
在另一个使用案例中，基于DNS的服务发现（DNS-SD）[RFC6763]已演变为一种自然的基于会话的机制，例如，长寿命的订阅将自己借给“推送”机制，而不是轮询。长寿命的有状态连接和服务器启动的消息与此用例[推送]一致。
A general use case is that DNS traffic is often bursty, but session establishment can be expensive. One challenge with long-lived connections is sustaining sufficient traffic to maintain NAT and firewall state. To mitigate this issue, this document introduces a new concept for the DNS -- DSO "keepalive traffic". This traffic carries no DNS data and is not considered 'activity' in the classic DNS sense, but it serves to maintain state in middleboxes and to assure the client and server that they still have connectivity to each other.
一般情况下，DNS流量通常是突发的，但建立会话可能会很昂贵。长寿命连接的一个挑战是维持足够的流量以维持NAT和防火墙状态。为了缓解这个问题，本文引入了DNS的一个新概念——DSO“keepalive流量”。此流量不携带DNS数据，也不被视为经典DNS意义上的“活动”，但它用于维护中间盒中的状态，并确保客户端和服务器彼此仍然具有连接。
DNS Stateful Operations are applicable in cases where it is useful to maintain an open session between a DNS client and server, where the transport allows such a session to be maintained, and where the transport guarantees in-order delivery of messages on which DSO depends. Two specific transports that meet the requirements to support DNS Stateful Operations are DNS-over-TCP [RFC1035] [RFC7766] and DNS-over-TLS [RFC7858].
DNS有状态操作适用于以下情况：维护DNS客户端和服务器之间的开放会话很有用；传输允许维护此类会话；传输保证DSO所依赖的消息按顺序传递。满足支持DNS有状态操作要求的两种特定传输是TCP上的DNS[RFC1035][RFC7766]和TLS上的DNS[RFC7858]。
Note that in the case of DNS-over-TLS, there is no mechanism for upgrading from DNS-over-TCP to DNS-over-TLS mid-connection (see Section 7 of the DNS-over-TLS specification [RFC7858]). A connection is either DNS-over-TCP from the start, or DNS-over-TLS from the start.
注意，对于TLS上的DNS，没有从TCP上的DNS升级到TLS上的DNS mid连接的机制（请参阅DNS over TLS规范[RFC7858]第7节）。连接从一开始就是通过TCP的DNS，或者从一开始就是通过TLS的DNS。
DNS Stateful Operations are not applicable for transports that cannot support clean session semantics or that do not guarantee in-order delivery. While in principle such a transport could be constructed over UDP, the current specification of DNS-over-UDP [RFC1035] does not provide in-order delivery or session semantics and hence cannot be used. Similarly, DNS-over-HTTP [RFC8484] cannot be used because HTTP has its own mechanism for managing sessions, which is incompatible with the mechanism specified here.
DNS有状态操作不适用于不支持干净会话语义或不保证按顺序传递的传输。虽然原则上这种传输可以通过UDP构建，但当前的DNS over UDP规范[RFC1035]没有提供顺序传递或会话语义，因此无法使用。类似地，无法使用HTTP上的DNS[RFC8484]，因为HTTP有自己的会话管理机制，这与此处指定的机制不兼容。
Only DNS-over-TCP and DNS-over-TLS are currently defined for use with DNS Stateful Operations. Other transports may be added in the future if they meet the requirements set out in the first paragraph of this section.
当前仅定义了TCP上的DNS和TLS上的DNS用于DNS有状态操作。如果其他运输工具满足本节第一段中规定的要求，则可在将来添加这些运输工具。
The overall flow of DNS Stateful Operations goes through a series of phases:
DNS有状态操作的整体流程经历一系列阶段：
Connection Establishment: A client establishes a connection to a server (Section 4.2).
连接建立：客户端建立到服务器的连接（第4.2节）。
Connected but Sessionless: A connection exists, but a DSO Session has not been established. DNS messages can be sent from the client to server, and DNS responses can be sent from the server to the client. In this state, a client that wishes to use DSO can attempt to establish a DSO Session (Section 5.1). Standard DNS-over-TCP inactivity timeout handling is in effect [RFC7766] (see Section 7.1.2 of this document).
已连接但无会话：存在连接，但尚未建立DSO会话。DNS消息可以从客户端发送到服务器，DNS响应可以从服务器发送到客户端。在此状态下，希望使用DSO的客户端可以尝试建立DSO会话（第5.1节）。标准DNS over TCP非活动超时处理生效[RFC7766]（请参阅本文档第7.1.2节）。
DSO Session Establishment in Progress: A client has sent a DSO request within the last 30 seconds, but has not yet received a DSO response for that request. In this phase, the client may send more DSO requests and more DNS requests, but MUST NOT send DSO unidirectional messages (Section 5.1).
正在建立DSO会话：客户端已在过去30秒内发送DSO请求，但尚未收到该请求的DSO响应。在此阶段，客户端可以发送更多DSO请求和更多DNS请求，但不得发送DSO单向消息（第5.1节）。
DSO Session Establishment Timeout: A client has sent a DSO request, and after 30 seconds has still received no DSO response for that request. This means that the server is now in an indeterminate state. The client forcibly aborts the connection. The client MAY reconnect without using DSO, if appropriate.
DSO会话建立超时：客户端已发送DSO请求，30秒后仍未收到该请求的DSO响应。这意味着服务器现在处于不确定状态。客户端强制中止连接。如果合适，客户端可以在不使用DSO的情况下重新连接。
DSO Session Establishment Failed: A client has sent a DSO request, and received a corresponding DSO response with a nonzero RCODE. This means that the attempt to establish the DSO Session did not succeed. At this point, the client is permitted to continue operating without a DSO Session (Connected but Sessionless) but does not send further DSO messages (Section 5.1).
DSO会话建立失败：客户端已发送DSO请求，并收到带有非零RCODE的相应DSO响应。这意味着建立DSO会话的尝试没有成功。此时，允许客户端在没有DSO会话（已连接但无会话）的情况下继续运行，但不发送进一步的DSO消息（第5.1节）。
DSO Session Established: A client has sent a DSO request, and received a corresponding DSO response with RCODE set to NOERROR (0). A DSO Session has now been successfully established. Both client and server may send DSO messages and DNS messages; both may send replies in response to messages they receive (Section 5.2). The inactivity timer (Section 6.4) is active; the keepalive timer (Section 6.5) is active. Standard DNS-over-TCP inactivity timeout handling is no longer in effect [RFC7766] (see Section 7.1.2 of this document).
DSO会话已建立：客户端已发送DSO请求，并收到相应的DSO响应，RCODE设置为NOERROR（0）。DSO会话现已成功建立。客户端和服务器都可以发送DSO消息和DNS消息；双方均可发送回复，以响应其收到的消息（第5.2节）。非活动计时器（第6.4节）处于活动状态；keepalive计时器（第6.5节）处于活动状态。标准DNS over TCP非活动超时处理不再有效[RFC7766]（请参阅本文档第7.1.2节）。
Server Shutdown: The server has decided to gracefully terminate the session and has sent the client a Retry Delay message (Section 6.6.1). There may still be unprocessed messages from the client; the server will ignore these. The server will not send any further messages to the client (Section 6.6.1.1).
服务器关闭：服务器已决定正常终止会话，并已向客户端发送重试延迟消息（第6.6.1节）。可能仍有来自客户端的未处理消息；服务器将忽略这些。服务器不会向客户端发送任何进一步的消息（第6.6.1.1节）。
Client Shutdown: The client has decided to disconnect, either because it no longer needs service, the connection is inactive (Section 6.4.1), or because the server sent it a Retry Delay message (Section 6.6.1). The client closes the connection gracefully (Section 5.3).
客户端关闭：客户端已决定断开连接，可能是因为它不再需要服务，连接处于非活动状态（第6.4.1节），或者是因为服务器向其发送了重试延迟消息（第6.6.1节）。客户端优雅地关闭连接（第5.3节）。
Reconnect: The client disconnected as a result of a server shutdown. The client either waits for the server-specified Retry Delay to expire (Section 6.6.3) or else contacts a different server instance. If the client no longer needs service, it does not reconnect.
重新连接：由于服务器关闭，客户端已断开连接。客户端要么等待服务器指定的重试延迟过期（第6.6.3节），要么联系其他服务器实例。如果客户端不再需要服务，则不会重新连接。
Forcibly Abort: The client or server detected a protocol error, and further communication would have undefined behavior. The client or server forcibly aborts the connection (Section 5.3).
强制中止：客户端或服务器检测到协议错误，进一步的通信将具有未定义的行为。客户端或服务器强制中止连接（第5.3节）。
Abort Reconnect Wait: The client has forcibly aborted the connection but still needs service. Or, the server forcibly aborted the connection, but the client still needs service. The client either connects to a different service instance (Section 9.1) or waits to reconnect (Section 6.6.3.1).
中止重新连接等待：客户端已强制中止连接，但仍需要服务。或者，服务器强制中止连接，但客户端仍需要服务。客户端连接到不同的服务实例（第9.1节）或等待重新连接（第6.6.3.1节）。
In order for a session to be established between a client and a server, the client must first establish a connection to the server using an applicable transport (see Section 4.2).
为了在客户端和服务器之间建立会话，客户端必须首先使用适用的传输建立与服务器的连接（参见第4.2节）。
In some environments, it may be known in advance by external means that both client and server support DSO, and in these cases either client or server may initiate DSO messages at any time. In this case, the session is established as soon as the connection is established; this is referred to as implicit DSO Session establishment.
在某些环境中，可以通过外部手段预先知道客户机和服务器都支持DSO，在这些情况下，客户机或服务器可以随时启动DSO消息。在这种情况下，一旦建立连接，就建立会话；这称为隐式DSO会话建立。
However, in the typical case a server will not know in advance whether a client supports DSO, so in general, unless it is known in advance by other means that a client does support DSO, a server MUST NOT initiate DSO request messages or DSO unidirectional messages until a DSO Session has been mutually established by at least one successful DSO request/response exchange initiated by the client, as
但是，在典型情况下，服务器不会预先知道客户机是否支持DSO，因此一般来说，除非通过其他方式预先知道客户机确实支持DSO，在客户机启动的至少一个成功的DSO请求/响应交换相互建立DSO会话之前，服务器不得启动DSO请求消息或DSO单向消息，如图所示
described below. This is referred to as explicit DSO Session establishment.
如下所述。这称为显式DSO会话建立。
Until a DSO Session has been implicitly or explicitly established, a client MUST NOT initiate DSO unidirectional messages.
在隐式或显式建立DSO会话之前，客户端不得启动DSO单向消息。
A DSO Session is established over a connection by the client sending a DSO request message, such as a DSO Keepalive request message (Section 7.1), and receiving a response with a matching MESSAGE ID, and RCODE set to NOERROR (0), indicating that the DSO request was successful.
通过客户端发送DSO请求消息（如DSO Keepalive请求消息（第7.1节））并接收具有匹配消息ID的响应，并且RCODE设置为NOERROR（0），指示DSO请求成功，通过连接建立DSO会话。
Some DSO messages are permitted as early data (Section 11.1). Others are not. Unidirectional messages are never permitted as early data, unless an implicit DSO Session exists.
某些DSO消息允许作为早期数据（第11.1节）。其他人则不然。除非存在隐式DSO会话，否则绝不允许将单向消息作为早期数据。
If a server receives a DSO message in early data whose Primary TLV is not permitted to appear in early data, the server MUST forcibly abort the connection. If a client receives a DSO message in early data, and there is no implicit DSO Session, the client MUST forcibly abort the connection. This can only be enforced on TLS connections; therefore, servers MUST NOT enable TCP Fast Open (TFO) when listening for a connection that does not require TLS.
如果服务器接收到早期数据中的DSO消息，其主TLV不允许出现在早期数据中，则服务器必须强制中止连接。如果客户端在早期数据中接收到DSO消息，并且没有隐含的DSO会话，则客户端必须强制中止连接。这只能在TLS连接上实施；因此，在侦听不需要TLS的连接时，服务器不得启用TCP Fast Open（TFO）。
If the response RCODE is set to NOTIMP (4), or in practice any value other than NOERROR (0) or DSOTYPENI (defined below), then the client MUST assume that the server does not implement DSO at all. In this case, the client is permitted to continue sending DNS messages on that connection but MUST NOT issue further DSO messages on that connection.
如果响应RCODE设置为NOTIMP（4），或者实际上设置为NOERROR（0）或DSOTYPENI（定义如下）以外的任何值，则客户端必须假定服务器根本没有实现DSO。在这种情况下，允许客户端在该连接上继续发送DNS消息，但不得在该连接上发出更多的DSO消息。
If the RCODE in the response is set to DSOTYPENI ("DSO-TYPE Not Implemented"; RCODE 11), this indicates that the server does support DSO but does not implement the DSO-TYPE of the Primary TLV in this DSO request message. A server implementing DSO MUST NOT return DSOTYPENI for a DSO Keepalive request message because the Keepalive TLV is mandatory to implement. But in the future, if a client attempts to establish a DSO Session using a response-requiring DSO request message using some newly-defined DSO-TYPE that the server does not understand, that would result in a DSOTYPENI response. If the server returns DSOTYPENI, then a DSO Session is not considered established. The client is, however, permitted to continue sending DNS messages on the connection, including other DSO messages such as the DSO Keepalive, which may result in a successful NOERROR response, yielding the establishment of a DSO Session.
如果响应中的RCODE设置为DSOTYPENI（“未实现DSO-TYPE”；RCODE 11），则表示服务器确实支持DSO，但未实现此DSO请求消息中主TLV的DSO-TYPE。实现DSO的服务器不能为DSO Keepalive请求消息返回DSOTYPENI，因为Keepalive TLV是强制实现的。但在将来，如果客户机尝试使用服务器不理解的某个新定义的DSO类型，使用需要DSO请求消息的响应来建立DSO会话，则会导致DSOTYPENI响应。如果服务器返回DSOTYPENI，则认为未建立DSO会话。但是，允许客户端继续在连接上发送DNS消息，包括其他DSO消息，如DSO Keepalive，这可能导致成功的无错误响应，从而建立DSO会话。
When a DSO message is received by an existing DNS server that doesn't recognize the DSO OPCODE, two other possible outcomes exist: the server might send no response to the DSO message, or the server might drop the connection.
当现有DNS服务器接收到无法识别DSO操作码的DSO消息时，可能存在两种其他结果：服务器可能不发送对DSO消息的响应，或者服务器可能断开连接。
If the server sends no response to the DSO message, the client SHOULD wait 30 seconds, after which time the server will be assumed not to support DSO. If the server doesn't respond within 30 seconds, it can be assumed that it is not going to respond; this leaves it in an unspecified state: there is no specification requiring that a response be sent to an unknown message, but there is also no specification stating what state the server is in if no response is sent. Therefore the client MUST forcibly abort the connection to the server. The client MAY reconnect, but not use DSO, if appropriate (Section 6.6.3.1). By disconnecting and reconnecting, the client ensures that the server is in a known state before sending any subsequent requests.
如果服务器未发送对DSO消息的响应，则客户端应等待30秒，之后将假定服务器不支持DSO。如果服务器在30秒内没有响应，则可以假定它不会响应；这使它处于未指定的状态：没有要求向未知消息发送响应的规范，但也没有说明如果未发送响应服务器处于何种状态的规范。因此，客户端必须强制中止与服务器的连接。如果合适，客户端可以重新连接，但不使用DSO（第6.6.3.1节）。通过断开和重新连接，客户端确保服务器在发送任何后续请求之前处于已知状态。
If the server drops the connection the client SHOULD mark that service instance as not supporting DSO, and not attempt a DSO connection for some period of time (at least an hour) after the failed attempt. The client MAY reconnect but not use DSO, if appropriate (Section 6.6.3.2).
如果服务器断开连接，客户端应将该服务实例标记为不支持DSO，并且在尝试失败后的一段时间内（至少一小时）不尝试DSO连接。如果合适，客户可以重新连接，但不使用DSO（第6.6.3.2节）。
When the server receives a DSO request message from a client, and transmits a successful NOERROR response to that request, the server considers the DSO Session established.
当服务器从客户端接收到DSO请求消息，并对该请求发送成功的无错误响应时，服务器将认为DSO会话已建立。
When the client receives the server's NOERROR response to its DSO request message, the client considers the DSO Session established.
当客户机收到服务器对其DSO请求消息的NOERROR响应时，客户机认为DSO会话已建立。
Once a DSO Session has been established, either end may unilaterally send appropriate DSO messages at any time, and therefore either client or server may be the initiator of a message.
一旦建立了DSO会话，任何一端都可以在任何时候单方面发送适当的DSO消息，因此客户机或服务器都可以是消息的发起方。
Once a DSO Session has been established, clients and servers should behave as described in this specification with regard to inactivity timeouts and session termination, not as previously prescribed in the earlier specification for DNS-over-TCP [RFC7766].
一旦建立了DSO会话，客户机和服务器在非活动超时和会话终止方面的行为应符合本规范中的描述，而不是先前针对TCP上DNS的规范[RFC7766]中的规定。
Because a server that supports DNS Stateful Operations MUST return an RCODE of "NOERROR" when it receives a Keepalive TLV DSO request message, the Keepalive TLV is an ideal candidate for use in establishing a DSO Session. Any other option that can only succeed
由于支持DNS有状态操作的服务器在收到Keepalive TLV DSO请求消息时必须返回“NOERROR”的RCODE，因此Keepalive TLV是建立DSO会话的理想候选。任何其他只能成功的选择
when sent to a server of the desired kind is also a good candidate for use in establishing a DSO Session. For clients that implement only the DSO-TYPEs defined in this base specification, sending a Keepalive TLV is the only DSO request message they have available to initiate a DSO Session. Even for clients that do implement other future DSO-TYPEs, for simplicity they MAY elect to always send an initial DSO Keepalive request message as their way of initiating a DSO Session. A future definition of a new response-requiring DSO-TYPE gives implementers the option of using that new DSO-TYPE if they wish, but does not change the fact that sending a Keepalive TLV remains a valid way of initiating a DSO Session.
当发送到所需类型的服务器时，也是用于建立DSO会话的良好候选。对于仅实现本基本规范中定义的DSO类型的客户机，发送Keepalive TLV是唯一可用于启动DSO会话的DSO请求消息。即使对于实现其他未来DSO类型的客户机，为简单起见，他们也可以选择始终发送初始DSO Keepalive请求消息作为启动DSO会话的方式。未来对需要DSO-TYPE的新响应的定义为实现者提供了使用该新DSO-TYPE的选项（如果他们愿意），但不会改变发送Keepalive TLV仍然是启动DSO会话的有效方式这一事实。
A DSO Session is terminated when the underlying connection is closed. DSO Sessions are "closed gracefully" as a result of the server closing a DSO Session because it is overloaded, because of the client closing the DSO Session because it is done, or because of the client closing the DSO Session because it is inactive. DSO Sessions are "forcibly aborted" when either the client or server closes the connection because of a protocol error.
当基础连接关闭时，DSO会话终止。由于服务器因DSO会话过载而关闭，由于客户端因DSO会话完成而关闭，或者由于客户端因DSO会话不活动而关闭，因此DSO会话“正常关闭”。当客户端或服务器由于协议错误而关闭连接时，DSO会话将“强制中止”。
o Where this specification says "close gracefully", it means sending a TLS close_notify (if TLS is in use) followed by a TCP FIN, or the equivalent for other protocols. Where this specification requires a connection to be closed gracefully, the requirement to initiate that graceful close is placed on the client in order to place the burden of TCP's TIME-WAIT state on the client rather than the server.
o 如果本规范规定“优雅关闭”，则表示发送TLS close_notify（如果TLS正在使用），后跟TCP FIN，或其他协议的等效协议。当本规范要求正常关闭连接时，启动正常关闭的要求放在客户端上，以便将TCP的等待时间状态的负担放在客户端而不是服务器上。
o Where this specification says "forcibly abort", it means sending a TCP RST or the equivalent for other protocols. In the BSD Sockets API, this is achieved by setting the SO_LINGER option to zero before closing the socket.
o 如果本规范规定“强制中止”，则表示发送TCP RST或其他协议的等效协议。在BSD套接字API中，这是通过在关闭套接字之前将SO_LINGER选项设置为零来实现的。
In protocol implementation, there are generally two kinds of errors that software writers have to deal with. The first is situations that arise due to factors in the environment, such as temporary loss of connectivity. While undesirable, these situations do not indicate a flaw in the software and are situations that software should generally be able to recover from.
在协议实现中，软件编写人员通常要处理两种错误。第一种情况是由于环境因素引起的情况，例如暂时失去连接。虽然不希望出现这种情况，但这些情况并不表示软件中存在缺陷，并且通常是软件能够从中恢复的情况。
The second is situations that should never happen when communicating with a compliant DSO implementation. If they do happen, they indicate a serious flaw in the protocol implementation beyond what is reasonable to expect software to recover from. This document
第二种情况是在与兼容的DSO实现通信时不应发生的情况。如果确实发生这种情况，则表明协议实现中存在严重缺陷，超出了软件可以恢复的合理范围。本文件
describes this latter form of error condition as a "fatal error" and specifies that an implementation encountering a fatal error condition "MUST forcibly abort the connection immediately".
将后一种形式的错误条件描述为“致命错误”，并指定遇到致命错误条件的实现“必须立即强制中止连接”。
A DSO message begins with the standard twelve-byte DNS message header [RFC1035] with the OPCODE field set to the DSO OPCODE (6). However, unlike standard DNS messages, the question section, answer section, authority records section, and additional records sections are not present. The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MUST be set to zero on transmission.
DSO消息以标准十二字节DNS消息头[RFC1035]开始，操作码字段设置为DSO操作码（6）。但是，与标准DNS消息不同，问题部分、答案部分、权限记录部分和附加记录部分不存在。传输时，必须将相应的计数字段（QDCOUNT、ANCOUNT、NSCOUNT、ARCOUNT）设置为零。
If a DSO message is received where any of the count fields are not zero, then a FORMERR MUST be returned.
如果接收到任何计数字段不为零的DSO消息，则必须返回FORMERR。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MESSAGE ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|QR | OPCODE (6) | Z | RCODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| QDCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ANCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| NSCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ARCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO Data /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MESSAGE ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|QR | OPCODE (6) | Z | RCODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| QDCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ANCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| NSCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ARCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO Data /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
In a DSO unidirectional message, the MESSAGE ID field MUST be set to zero. In a DSO request message, the MESSAGE ID field MUST be set to a unique nonzero value that the initiator is not currently using for any other active operation on this connection. For the purposes here, a MESSAGE ID is in use in this DSO Session if the initiator has used it in a DSO request message for which it is still awaiting a response, or if the client has used it to set up a long-lived operation that has not yet been canceled. For example, a long-lived operation could be a Push Notification subscription [Push] or a Discovery Relay interface subscription [Relay].
在DSO单向消息中，消息ID字段必须设置为零。在DSO请求消息中，消息ID字段必须设置为唯一的非零值，启动器当前未将该值用于此连接上的任何其他活动操作。出于此处的目的，如果发起者在DSO请求消息中使用了消息ID，而该发起者仍在等待响应，或者如果客户端已使用该ID设置了尚未取消的长期操作，则该DSO会话中正在使用该消息ID。例如，长期操作可以是推送通知订阅[Push]或发现中继接口订阅[Relay]。
Whether a message is a DSO request message or a DSO unidirectional message is determined only by the specification for the Primary TLV. An acknowledgment cannot be requested by including a nonzero MESSAGE ID in a message that is required according to its Primary TLV to be unidirectional. Nor can an acknowledgment be prevented by sending a MESSAGE ID of zero in a message that is required to be a DSO request message according to its Primary TLV. A responder that receives either such malformed message MUST treat it as a fatal error and forcibly abort the connection immediately.
消息是DSO请求消息还是DSO单向消息仅由主TLV的规范确定。无法通过在消息中包含非零消息ID来请求确认，根据其主要TLV，该消息需要是单向的。也不能通过在根据其主要TLV要求为DSO请求消息的消息中发送消息ID为零来阻止确认。接收此类格式错误消息的响应程序必须将其视为致命错误，并立即强制中止连接。
In a DSO request message or DSO unidirectional message, the DNS Header Query/Response (QR) bit MUST be zero (QR=0). If the QR bit is not zero, the message is not a DSO request or DSO unidirectional message.
在DSO请求消息或DSO单向消息中，DNS标头查询/响应（QR）位必须为零（QR=0）。如果QR位不为零，则该消息不是DSO请求或DSO单向消息。
In a DSO response message, the DNS Header QR bit MUST be one (QR=1). If the QR bit is not one, the message is not a DSO response message.
在DSO响应消息中，DNS头QR位必须为1（QR=1）。如果QR位不是1，则该消息不是DSO响应消息。
In a DSO response message (QR=1), the MESSAGE ID field MUST NOT be zero, and MUST contain a copy of the value of the (nonzero) MESSAGE ID field in the DSO request message being responded to. If a DSO response message (QR=1) is received where the MESSAGE ID is zero, this is a fatal error and the recipient MUST forcibly abort the connection immediately.
在DSO响应消息（QR=1）中，消息ID字段不得为零，并且必须包含所响应DSO请求消息中（非零）消息ID字段值的副本。如果在消息ID为零的情况下收到DSO响应消息（QR=1），则这是一个致命错误，收件人必须立即强制中止连接。
The DNS Header OPCODE field holds the DSO OPCODE value (6).
DNS标头操作码字段保存DSO操作码值（6）。
The Z bits are currently unused in DSO messages; in both DSO request messages and DSO responses, the Z bits MUST be set to zero (0) on transmission and MUST be ignored on reception.
Z位当前未在DSO消息中使用；在DSO请求消息和DSO响应中，Z位在传输时必须设置为零（0），在接收时必须忽略。
In a DSO request message (QR=0), the RCODE is set according to the definition of the request. For example, in a Retry Delay message (Section 6.6.1), the RCODE indicates the reason for termination. However, in most DSO request messages (QR=0), except where clearly
在DSO请求消息（QR=0）中，根据请求的定义设置RCODE。例如，在重试延迟消息（第6.6.1节）中，RCODE指示终止的原因。但是，在大多数DSO请求消息（QR=0）中，除非
specified otherwise, the RCODE is set to zero on transmission, and silently ignored on reception.
否则，RCODE在传输时设置为零，在接收时自动忽略。
The RCODE value in a response message (QR=1) may be one of the following values:
响应消息（QR=1）中的RCODE值可以是以下值之一：
+------+-----------+------------------------------------------------+
| Code | Mnemonic | Description |
+------+-----------+------------------------------------------------+
| 0 | NOERROR | Operation processed successfully |
| | | |
| 1 | FORMERR | Format error |
| | | |
| 2 | SERVFAIL | Server failed to process DSO request message |
| | | due to a problem with the server |
| | | |
| 4 | NOTIMP | DSO not supported |
| | | |
| 5 | REFUSED | Operation declined for policy reasons |
| | | |
| 11 | DSOTYPENI | Primary TLV's DSO-Type is not implemented |
+------+-----------+------------------------------------------------+
+------+-----------+------------------------------------------------+
| Code | Mnemonic | Description |
+------+-----------+------------------------------------------------+
| 0 | NOERROR | Operation processed successfully |
| | | |
| 1 | FORMERR | Format error |
| | | |
| 2 | SERVFAIL | Server failed to process DSO request message |
| | | due to a problem with the server |
| | | |
| 4 | NOTIMP | DSO not supported |
| | | |
| 5 | REFUSED | Operation declined for policy reasons |
| | | |
| 11 | DSOTYPENI | Primary TLV's DSO-Type is not implemented |
+------+-----------+------------------------------------------------+
Use of the above RCODEs is likely to be common in DSO but does not preclude the definition and use of other codes in future documents that make use of DSO.
上述代码的使用可能在DSO中很常见，但并不排除在将来使用DSO的文档中定义和使用其他代码。
If a document defining a new DSO-TYPE makes use of response codes not defined here, then that document MUST specify the specific interpretation of those RCODE values in the context of that new DSO TLV.
如果定义新DSO类型的文档使用了此处未定义的响应代码，则该文档必须在该新DSO TLV的上下文中指定这些RCODE值的具体解释。
The RCODE field is followed by the four zero-valued count fields, followed by the DSO Data.
RCODE字段后面是四个零值计数字段，后面是DSO数据。
The standard twelve-byte DNS message header with its zero-valued count fields is followed by the DSO Data, expressed using TLV syntax, as described in Section 5.4.4.
标准的十二字节DNS消息头及其零值计数字段后面是DSO数据，使用TLV语法表示，如第5.4.4节所述。
A DSO request message or DSO unidirectional message MUST contain at least one TLV. The first TLV in a DSO request message or DSO unidirectional message is referred to as the "Primary TLV" and determines the nature of the operation being performed, including whether it is a DSO request or a DSO unidirectional operation. In some cases, it may be appropriate to include other TLVs in a DSO request message or DSO unidirectional message, such as the DSO
DSO请求消息或DSO单向消息必须至少包含一个TLV。DSO请求消息或DSO单向消息中的第一个TLV称为“主TLV”，并确定正在执行的操作的性质，包括它是DSO请求还是DSO单向操作。在某些情况下，可能适合在DSO请求消息或DSO单向消息（例如DSO）中包括其他TLV
Encryption Padding TLV (Section 7.3). Additional TLVs follow the Primary TLV. Additional TLVs are not limited to what is defined in this document. New Additional TLVs may be defined in the future. Their definitions will describe when their use is appropriate.
加密填充TLV（第7.3节）。其他TLV跟随主TLV。其他TLV不限于本文件中的定义。将来可能会定义新的附加TLV。它们的定义将描述何时使用合适。
An unrecognized Primary TLV results in a DSOTYPENI error response. Unrecognized Additional TLVs are silently ignored, as described in Sections 5.4.5 and 8.2.
无法识别的主TLV将导致DSOTYPENI错误响应。如第5.4.5节和第8.2节所述，未识别的附加TLV将被默默忽略。
A DSO response message may contain no TLVs, or may contain one or more TLVs, appropriate to the information being communicated.
DSO响应消息可以不包含TLV，或者可以包含一个或多个TLV，这些TLV适合于正在通信的信息。
Any TLVs with the same DSO-TYPE as the Primary TLV from the corresponding DSO request message are Response Primary TLV(s) and MUST appear first in a DSO response message. A DSO response message may contain multiple Response Primary TLVs, or a single Response Primary TLV, or in some cases, no Response Primary TLV. A Response Primary TLV is not required; for most DSO operations the MESSAGE ID field in the DNS message header is sufficient to identify the DSO request message to which a particular response message relates.
与相应DSO请求消息中的主TLV具有相同DSO类型的任何TLV都是响应主TLV，必须首先出现在DSO响应消息中。DSO响应消息可能包含多个响应主TLV，或单个响应主TLV，或在某些情况下不包含响应主TLV。不需要响应主TLV；对于大多数DSO操作，DNS消息头中的消息ID字段足以识别与特定响应消息相关的DSO请求消息。
Any other TLVs in a DSO response message are Response Additional TLVs, such as the DSO Encryption Padding TLV (Section 7.3). Response Additional TLVs follow the Response Primary TLV(s), if present. Response Additional TLVs are not limited to what is defined in this document. New Response Additional TLVs may be defined in the future. Their definitions will describe when their use is appropriate. Unrecognized Response Additional TLVs are silently ignored, as described in Sections 5.4.5 and 8.2.
DSO响应消息中的任何其他TLV都是响应附加TLV，例如DSO加密填充TLV（第7.3节）。响应附加TLV跟随响应主TLV（如果存在）。响应附加TLV不限于本文件中定义的内容。未来可能会定义新的响应附加TLV。它们的定义将描述何时使用合适。如第5.4.5节和第8.2节所述，未识别的响应附加TLV将被静默忽略。
The specification for each DSO TLV determines what TLVs are required in a response to a DSO request message using that TLV. If a DSO response is received for an operation where the specification requires that the response carry a particular TLV or TLVs, and the required TLV(s) are not present, then this is a fatal error and the recipient of the defective response message MUST forcibly abort the connection immediately. Similarly, if more than the specified number of instances of a given TLV are present, this is a fatal error and the recipient of the defective response message MUST forcibly abort the connection immediately.
每个DSO TLV的规范确定在使用该TLV响应DSO请求消息时需要哪些TLV。如果针对规范要求响应携带特定TLV或TLV的操作收到DSO响应，且所需TLV不存在，则这是一个致命错误，缺陷响应消息的接收者必须立即强制中止连接。类似地，如果给定TLV的实例超过指定数量，则这是一个致命错误，缺陷响应消息的收件人必须立即强制中止连接。
It is anticipated that most DSO operations will be specified to use DSO request messages, which generate corresponding DSO responses. In some specialized high-traffic use cases, it may be appropriate to specify DSO unidirectional messages. DSO unidirectional messages can be more efficient on the network because they don't generate a stream of corresponding reply messages. Using DSO unidirectional messages can also simplify software in some cases by removing the need for an initiator to maintain state while it waits to receive replies it doesn't care about. When the specification for a particular TLV used as a Primary TLV (i.e., first) in an outgoing DSO request message (i.e., QR=0) states that a message is to be unidirectional, the MESSAGE ID field MUST be set to zero and the receiver MUST NOT generate any response message corresponding to that DSO unidirectional message.
预计大多数DSO操作将指定为使用DSO请求消息，该消息将生成相应的DSO响应。在一些特殊的高流量用例中，指定DSO单向消息可能是合适的。DSO单向消息在网络上效率更高，因为它们不会生成相应的回复消息流。在某些情况下，使用DSO单向消息还可以简化软件，因为它不需要启动器在等待它不关心的回复时维护状态。当在传出DSO请求消息（即QR=0）中用作主TLV（即第一个）的特定TLV的规范规定消息是单向的时，消息ID字段必须设置为零，并且接收器不得生成与该DSO单向消息对应的任何响应消息。
The previous point, that the receiver MUST NOT generate responses to DSO unidirectional messages, applies even in the case of errors.
前一点，即接收机不得生成对DSO单向消息的响应，即使在出现错误的情况下也适用。
When a DSO message is received where both the QR bit and the MESSAGE ID field are zero, the receiver MUST NOT generate any response. For example, if the DSO-TYPE in the Primary TLV is unrecognized, then a DSOTYPENI error MUST NOT be returned; instead, the receiver MUST forcibly abort the connection immediately.
当接收到QR位和消息ID字段均为零的DSO消息时，接收器不得生成任何响应。例如，如果无法识别主TLV中的DSO-TYPE，则不得返回DSOTYPENI错误；相反，接收器必须立即强制中止连接。
DSO unidirectional messages MUST NOT be used "speculatively" in cases where the sender doesn't know if the receiver supports the Primary TLV in the message because there is no way to receive any response to indicate success or failure. DSO unidirectional messages are only appropriate in cases where the sender already knows that the receiver supports and wishes to receive these messages.
如果发送方不知道接收方是否支持消息中的主TLV，则不得“推测”使用DSO单向消息，因为无法接收任何指示成功或失败的响应。DSO单向消息仅适用于发送方已经知道接收方支持并希望接收这些消息的情况。
For example, after a client has subscribed for Push Notifications [Push], the subsequent event notifications are then sent as DSO unidirectional messages. This is appropriate because the client initiated the message stream by virtue of its Push Notification subscription, thereby indicating its support of Push Notifications and its desire to receive those notifications.
例如，客户端订阅推送通知[Push]后，随后的事件通知将作为DSO单向消息发送。这是合适的，因为客户机通过其推送通知订阅启动了消息流，从而表明其对推送通知的支持以及接收这些通知的愿望。
Similarly, after a Discovery Relay client has subscribed to receive inbound multicast DNS (mDNS) [RFC6762] traffic from a Discovery Relay, the subsequent stream of received packets is then sent using DSO unidirectional messages. This is appropriate because the client initiated the message stream by virtue of its Discovery Relay link subscription, thereby indicating its support of Discovery Relay and its desire to receive inbound mDNS packets over that DSO Session [Relay].
类似地，在发现中继客户端订阅从发现中继接收入站多播DNS（mDNS）[RFC6762]通信量之后，随后使用DSO单向消息发送接收到的分组流。这是适当的，因为客户机凭借其发现中继链路订阅启动了消息流，从而表明其支持发现中继，并希望通过该DSO会话[中继]接收入站mDNS数据包。
All TLVs, whether used as "Primary", "Additional", "Response Primary", or "Response Additional", use the same encoding syntax.
所有TLV，无论用作“主”、“附加”、“响应主”还是“响应附加”，都使用相同的编码语法。
A specification that defines a new TLV must specify whether the DSO-TYPE can be used as a Primary TLV, and whether the DSO-TYPE can be used as an Additional TLV. Some DSO-TYPEs are dual-purpose and can be used as Primary TLVs in some messages, and in other messages as Additional TLVs. The specification for a DSO-TYPE must also state whether, when used as the Primary (i.e., first) TLV in a DSO message (i.e., QR=0), that DSO message is unidirectional, or is a DSO request message that requires a response.
定义新TLV的规范必须指定DSO-TYPE是否可以用作主TLV，以及DSO-TYPE是否可以用作附加TLV。某些DSO类型具有双重用途，可在某些消息中用作主TLV，在其他消息中用作附加TLV。DSO类型的规范还必须说明，当用作DSO消息（即QR=0）中的主要（即第一个）TLV时，DSO消息是单向的，还是需要响应的DSO请求消息。
If a DSO request message requires a response, the specification must also state which TLVs, if any, are to be included in the response and how many instances of each of the TLVs are allowed. The Primary TLV may or may not be contained in the response depending on what is specified for that TLV. If multiple instances of the Primary TLV are allowed the specification should clearly describe how they should be processed.
如果DSO请求消息需要响应，则规范还必须说明响应中包括哪些TLV（如果有），以及允许每个TLV的实例数。主要TLV可能包含在响应中，也可能不包含在响应中，具体取决于为该TLV指定的内容。如果允许主TLV的多个实例，则规范应明确说明应如何处理这些实例。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
DSO-TYPE: A 16-bit unsigned integer, in network (big endian) byte order, giving the DSO-TYPE of the current DSO TLV per the IANA "DSO Type Codes" registry.
DSO-TYPE：一个16位无符号整数，以网络（big-endian）字节顺序表示，根据IANA“DSO-TYPE Codes”注册表给出当前DSO TLV的DSO-TYPE。
DSO-LENGTH: A 16-bit unsigned integer, in network (big endian) byte order, giving the size in bytes of the DSO-DATA.
DSO-LENGTH：一个16位无符号整数，以网络（大端）字节顺序表示，给出DSO-DATA的字节大小。
DSO-DATA: Type-code specific format. The generic DSO machinery treats the DSO-DATA as an opaque "blob" without attempting to interpret it. Interpretation of the meaning of the DSO-DATA for a particular DSO-TYPE is the responsibility of the software that implements that DSO-TYPE.
DSO-DATA：特定于类型代码的格式。通用的DSO机制将DSO-DATA视为不透明的“blob”，而不尝试对其进行解释。解释特定DSO类型的DSO数据含义是实现该DSO类型的软件的责任。
If a DSO request message is received containing an unrecognized Primary TLV, with a nonzero MESSAGE ID (indicating that a response is expected), then the receiver MUST send an error response with a matching MESSAGE ID, and RCODE DSOTYPENI. The error response MUST NOT contain a copy of the unrecognized Primary TLV.
如果接收到的DSO请求消息包含无法识别的主TLV，且消息ID为非零（表示预期会有响应），则接收器必须发送一个错误响应，该错误响应带有匹配的消息ID，并且RCODE DSOTYPENI。错误响应不得包含无法识别的主TLV的副本。
If a DSO unidirectional message is received containing both an unrecognized Primary TLV and a zero MESSAGE ID (indicating that no response is expected), then this is a fatal error and the recipient MUST forcibly abort the connection immediately.
如果收到的DSO单向消息包含无法识别的主TLV和零消息ID（表示预期不会有响应），则这是一个致命错误，收件人必须立即强制中止连接。
If a DSO request message or DSO unidirectional message is received where the Primary TLV is recognized, containing one or more unrecognized Additional TLVs, the unrecognized Additional TLVs MUST be silently ignored, and the remainder of the message is interpreted and handled as if the unrecognized parts were not present.
如果接收到的DSO请求消息或DSO单向消息中，主TLV被识别，包含一个或多个未识别的附加TLV，则必须静默忽略未识别的附加TLV，并且消息的其余部分将被解释和处理，就像未识别的部分不存在一样。
Similarly, if a DSO response message is received containing one or more unrecognized TLVs, the unrecognized TLVs MUST be silently ignored and the remainder of the message is interpreted and handled as if the unrecognized parts are not present.
类似地，如果接收到包含一个或多个未识别TLV的DSO响应消息，则必须无声地忽略未识别TLV，并且消息的其余部分将被解释和处理，就像未识别部分不存在一样。
Since the ARCOUNT field MUST be zero, a DSO message cannot contain a valid EDNS(0) option in the additional records section. If functionality provided by current or future EDNS(0) options is desired for DSO messages, one or more new DSO TLVs need to be defined to carry the necessary information.
由于ARCOUNT字段必须为零，因此DSO消息在附加记录部分中不能包含有效的EDNS（0）选项。如果DSO消息需要当前或未来EDN（0）选项提供的功能，则需要定义一个或多个新的DSO TLV以承载必要的信息。
For example, the EDNS(0) Padding Option [RFC7830] used for security purposes is not permitted in a DSO message, so if message padding is desired for DSO messages, then the DSO Encryption Padding TLV described in Section 7.3 MUST be used.
例如，DSO消息中不允许出于安全目的使用EDNS（0）填充选项[RFC7830]，因此，如果DSO消息需要填充消息，则必须使用第7.3节中描述的DSO加密填充TLV。
A DSO message can't contain a TSIG record because a TSIG record is included in the additional section of the message, which would mean that ARCOUNT would be greater than zero. DSO messages are required to have an ARCOUNT of zero. Therefore, if use of signatures with DSO messages becomes necessary in the future, a new DSO TLV would have to be defined to perform this function.
DSO消息不能包含TSIG记录，因为TSIG记录包含在消息的附加部分中，这意味着ARCOUNT将大于零。DSO消息要求ARCOUNT为零。因此，如果将来有必要对DSO消息使用签名，则必须定义一个新的DSO TLV来执行此功能。
Note, however, that while DSO *messages* cannot include EDNS(0) or TSIG records, a DSO *session* is typically used to carry a whole series of DNS messages of different kinds, including DSO messages and other DNS message types like Query [RFC1034] [RFC1035] and Update [RFC2136]. These messages can carry EDNS(0) and TSIG records.
然而，请注意，虽然DSO*消息*不能包括EDN（0）或TSIG记录，但DSO*会话*通常用于承载一系列不同类型的DNS消息，包括DSO消息和其他DNS消息类型，如查询[RFC1034][RFC1035]和更新[RFC2136]。这些信息可以携带EDN（0）和TSIG记录。
Although messages may contain other EDNS(0) options as appropriate, this specification explicitly prohibits use of the edns-tcp-keepalive EDNS(0) Option [RFC7828] in *any* messages sent on a DSO Session (because it is obsoleted by the functionality provided by the DSO Keepalive operation). If any message sent on a DSO Session contains an edns-tcp-keepalive EDNS(0) Option, this is a fatal error and the recipient of the defective message MUST forcibly abort the connection immediately.
尽管消息可能包含其他EDN（0）选项（视情况而定），但本规范明确禁止在DSO会话上发送的*任何*消息中使用EDN tcp keepalive EDN（0）选项[RFC7828]（因为DSO keepalive操作提供的功能已将其淘汰）。如果在DSO会话上发送的任何消息包含edns tcp keepalive edns（0）选项，则这是一个致命错误，有缺陷消息的收件人必须立即强制中止连接。
As described in Section 5.4.1, whether an outgoing DSO message with the QR bit in the DNS header set to zero is a DSO request or a DSO unidirectional message is determined by the specification for the Primary TLV, which in turn determines whether the MESSAGE ID field in that outgoing message will be zero or nonzero.
如第5.4.1节所述，DNS报头中QR位设置为零的传出DSO消息是DSO请求还是DSO单向消息由主TLV规范确定，这反过来决定传出消息中的消息ID字段是零还是非零。
Every DSO message with the QR bit in the DNS header set to zero and a nonzero MESSAGE ID field is a DSO request message, and MUST elicit a corresponding response, with the QR bit in the DNS header set to one and the MESSAGE ID field set to the value given in the corresponding DSO request message.
DNS报头中QR位设置为零且消息ID字段非零的每条DSO消息都是DSO请求消息，必须引发相应的响应，DNS报头中的QR位设置为一，消息ID字段设置为相应DSO请求消息中给定的值。
Valid DSO request messages sent by the client with a nonzero MESSAGE ID field elicit a response from the server, and valid DSO request messages sent by the server with a nonzero MESSAGE ID field elicit a response from the client.
具有非零消息ID字段的客户端发送的有效DSO请求消息将从服务器获取响应，而具有非零消息ID字段的服务器发送的有效DSO请求消息将从客户端获取响应。
Every DSO message with both the QR bit in the DNS header and the MESSAGE ID field set to zero is a DSO unidirectional message and MUST NOT elicit a response.
DNS头中QR位和消息ID字段均设置为零的每个DSO消息都是DSO单向消息，不得引发响应。
Generally, most good TCP implementations employ a delayed acknowledgement timer to provide more efficient use of the network and better performance.
通常，大多数好的TCP实现都使用延迟确认计时器，以提供更有效的网络使用和更好的性能。
With a bidirectional exchange over TCP, such as with a DSO request message, the operating system TCP implementation waits for the application-layer client software to generate the corresponding DSO response message. The TCP implementation can then send a single combined packet containing the TCP acknowledgement, the TCP window update, and the application-generated DSO response message. This is more efficient than sending three separate packets, as would occur if the TCP packet containing the DSO request were acknowledged immediately.
对于TCP上的双向交换，例如DSO请求消息，操作系统TCP实现将等待应用层客户端软件生成相应的DSO响应消息。然后，TCP实现可以发送包含TCP确认、TCP窗口更新和应用程序生成的DSO响应消息的单个组合数据包。这比发送三个单独的数据包更有效，如果包含DSO请求的TCP数据包被立即确认，则会发生这种情况。
With a DSO unidirectional message or DSO response message, there is no corresponding application-generated DSO response message, and consequently, no hint to the transport protocol about when it should send its acknowledgement and window update.
对于DSO单向消息或DSO响应消息，没有相应的应用程序生成的DSO响应消息，因此，没有向传输协议提示何时应发送其确认和窗口更新。
Some networking APIs provide a mechanism that allows the application-layer client software to signal to the transport protocol that no response will be forthcoming (in effect it can be thought of as a zero-length "empty" write). Where available in the networking API being used, the recipient of a DSO unidirectional message or DSO response message, having parsed and interpreted the message, SHOULD then use this mechanism provided by the networking API to signal that no response for this message will be forthcoming. The TCP implementation can then go ahead and send its acknowledgement and window update without further delay. See Section 9.5 for further discussion of why this is important.
一些网络API提供了一种机制，允许应用层客户端软件向传输协议发出信号，表示不会有响应（实际上，可以将其视为零长度的“空”写入）。在所使用的网络API中可用的情况下，DSO单向消息或DSO响应消息的接收者在解析和解释该消息后，应使用网络API提供的该机制来发出该消息将不会有响应的信号。然后，TCP实现可以继续并发送其确认和窗口更新，而不再延迟。关于为什么这一点很重要的进一步讨论，请参见第9.5节。
The namespaces of 16-bit MESSAGE IDs are independent in each direction. This means it is *not* an error for both client and server to send DSO request messages at the same time as each other, using the same MESSAGE ID, in different directions. This simplification is necessary in order for the protocol to be implementable. It would be infeasible to require the client and server to coordinate with each other regarding allocation of new unique MESSAGE IDs. It is also not necessary to require the client and server to coordinate with each other regarding allocation of new unique MESSAGE IDs. The value of the 16-bit MESSAGE ID combined with the identity of the initiator (client or server) is sufficient to unambiguously identify the operation in question. This can be thought of as a 17-bit message identifier space using message identifiers 0x00001-0x0FFFF for client-to-server DSO request messages, and 0x10001-0x1FFFF for server-to-client DSO request messages. The least-significant 16 bits are stored explicitly in the MESSAGE ID field of the DSO message, and the most-significant bit is implicit from the direction of the message.
16位消息ID的名称空间在每个方向上都是独立的。这意味着客户机和服务器使用相同的消息ID在不同的方向上同时发送DSO请求消息，这不是一个错误。为了使协议能够实现，这种简化是必要的。要求客户机和服务器在分配新的唯一消息ID方面相互协调是不可行的。也不需要要求客户机和服务器在分配新的唯一消息ID方面相互协调。16位消息ID的值与启动器（客户机或服务器）的标识相结合，足以明确标识所涉及的操作。这可以看作是一个17位的消息标识符空间，对于客户端到服务器的DSO请求消息，使用消息标识符0x00001-0x0FFFF；对于服务器到客户端的DSO请求消息，使用消息标识符0x10001-0x1FFF。最低有效16位显式存储在DSO消息的消息ID字段中，最高有效位从消息方向隐式存储。
As described in Section 5.4.1, an initiator MUST NOT reuse a MESSAGE ID that it already has in use for an outstanding DSO request message (unless specified otherwise by the relevant specification for the DSO-TYPE in question). At the very least, this means that a MESSAGE ID can't be reused in a particular direction on a particular DSO Session while the initiator is waiting for a response to a previous DSO request message using that MESSAGE ID on that DSO Session (unless specified otherwise by the relevant specification for the DSO-TYPE in question), and for a long-lived operation, the MESSAGE ID for the operation can't be reused while that operation remains active.
如第5.4.1节所述，发起者不得重复使用其已用于未完成DSO请求消息的消息ID（除非相关DSO类型规范另有规定）。至少，这意味着，当启动器在该DSO会话上使用消息ID等待对先前DSO请求消息的响应时，消息ID不能在特定DSO会话的特定方向上重用（除非相关DSO类型规范另有规定），对于长期运行的操作，在该操作保持活动状态时，无法重用该操作的消息ID。
If a client or server receives a response (QR=1) where the MESSAGE ID is zero, or is any other value that does not match the MESSAGE ID of any of its outstanding operations, this is a fatal error and the recipient MUST forcibly abort the connection immediately.
如果客户端或服务器接收到消息ID为零的响应（QR=1），或者是与任何未完成操作的消息ID不匹配的任何其他值，则这是一个致命错误，收件人必须立即强制中止连接。
If a responder receives a DSO request message (QR=0) where the MESSAGE ID is not zero, the responder tracks request MESSAGE IDs, and the MESSAGE ID matches the MESSAGE ID of a DSO request message it received for which a response has not yet been sent, it MUST forcibly abort the connection immediately. This behavior is required to prevent a hypothetical attack that takes advantage of undefined behavior in this case. However, if the responder does not track MESSAGE IDs in this way, no such risk exists. Therefore, tracking MESSAGE IDs just to implement this sanity check is not required.
如果响应者接收到消息ID不为零的DSO请求消息（QR=0），响应者跟踪请求消息ID，并且消息ID与它接收到的尚未发送响应的DSO请求消息的消息ID匹配，则必须立即强制中止连接。在这种情况下，需要此行为来防止利用未定义行为的假设攻击。但是，如果响应者不以这种方式跟踪消息ID，则不存在此类风险。因此，不需要仅为了实现此健全性检查而跟踪消息ID。
When a DSO request message is unsuccessful for some reason, the responder returns an error code to the initiator.
当DSO请求消息因某种原因失败时，响应程序将向启动器返回错误代码。
In the case of a server returning an error code to a client in response to an unsuccessful DSO request message, the server MAY choose to end the DSO Session or MAY choose to allow the DSO Session to remain open. For error conditions that only affect the single operation in question, the server SHOULD return an error response to the client and leave the DSO Session open for further operations.
如果服务器响应不成功的DSO请求消息向客户端返回错误代码，则服务器可以选择结束DSO会话，也可以选择允许DSO会话保持打开状态。对于仅影响所讨论的单个操作的错误情况，服务器应向客户端返回错误响应，并使DSO会话保持打开状态以进行进一步操作。
For error conditions that are likely to make all operations unsuccessful in the immediate future, the server SHOULD return an error response to the client and then end the DSO Session by sending a Retry Delay message as described in Section 6.6.1.
对于可能导致近期所有操作不成功的错误情况，服务器应向客户端返回错误响应，然后通过发送重试延迟消息（如第6.6.1节所述）结束DSO会话。
Upon receiving an error response from the server, a client SHOULD NOT automatically close the DSO Session. An error relating to one particular operation on a DSO Session does not necessarily imply that all other operations on that DSO Session have also failed or that future operations will fail. The client should assume that the server will make its own decision about whether or not to end the DSO Session based on the server's determination of whether the error condition pertains to this particular operation or to any subsequent operations. If the server does not end the DSO Session by sending the client a Retry Delay message (Section 6.6.1), then the client SHOULD continue to use that DSO Session for subsequent operations.
从服务器收到错误响应后，客户端不应自动关闭DSO会话。与DSO会话上的一个特定操作相关的错误并不一定意味着该DSO会话上的所有其他操作也已失败，或者将来的操作将失败。客户机应假设服务器将根据服务器确定的错误条件是否与此特定操作或任何后续操作相关，自行决定是否结束DSO会话。如果服务器未通过向客户端发送重试延迟消息（第6.6.1节）来结束DSO会话，则客户端应继续使用该DSO会话进行后续操作。
When a DSO unidirectional message type is received (MESSAGE ID field is zero), the receiver should already be expecting this DSO message type. Section 5.4.5 describes the handling of unknown DSO message types. When a DSO unidirectional message of an unexpected type is received, the receiver SHOULD forcibly abort the connection. Whether the connection should be forcibly aborted for other internal errors processing the DSO unidirectional message is implementation dependent according to the severity of the error.
当接收到DSO单向消息类型（消息ID字段为零）时，接收器应该已经期望该DSO消息类型。第5.4.5节描述了未知DSO消息类型的处理。当接收到意外类型的DSO单向消息时，接收器应强制中止连接。处理DSO单向消息的其他内部错误是否应强制中止连接取决于错误的严重程度。
This document, the base specification for DNS Stateful Operations, does not itself define any long-lived operations, but it defines a framework for supporting long-lived operations such as Push Notification subscriptions [Push] and Discovery Relay interface subscriptions [Relay].
本文档（DNS有状态操作的基本规范）本身并不定义任何长寿命操作，但它定义了一个框架，用于支持长寿命操作，如推送通知订阅[Push]和发现中继接口订阅[Relay]。
Long-lived operations, if successful, will remain active until the initiator terminates the operation.
长寿命操作如果成功，将保持活动状态，直到启动器终止操作。
However, it is possible that a long-lived operation may be valid at the time it was initiated, but then a later change of circumstances may render that operation invalid. For example, a long-lived client operation may pertain to a name that the server is authoritative for, but then the server configuration is changed such that it is no longer authoritative for that name.
但是，长期运行的操作在启动时可能是有效的，但随后环境的变化可能会导致该操作无效。例如，长期客户端操作可能与服务器具有权威性的名称有关，但随后服务器配置发生更改，使其不再具有该名称的权威性。
In such cases, instead of terminating the entire session, it may be desirable for the responder to be able to cancel selectively only those operations that have become invalid.
在这种情况下，响应者可能希望能够仅选择性地取消那些已变得无效的操作，而不是终止整个会话。
The responder performs this selective cancellation by sending a new DSO response message with the MESSAGE ID field containing the MESSAGE ID of the long-lived operation that is to be terminated (that it had previously acknowledged with a NOERROR RCODE) and the RCODE field of the new DSO response message giving the reason for cancellation.
响应者通过发送新的DSO响应消息来执行此选择性取消，消息ID字段包含要终止的长寿命操作的消息ID（之前已使用NOERROR RCODE确认），以及新DSO响应消息的RCODE字段，给出取消原因。
After a DSO response message with nonzero RCODE has been sent, that operation has been terminated from the responder's point of view, and the responder sends no more messages relating to that operation.
发送带有非零RCODE的DSO响应消息后，从响应者的角度来看，该操作已终止，响应者不再发送与该操作相关的消息。
After a DSO response message with nonzero RCODE has been received by the initiator, that operation has been terminated from the initiator's point of view, and the canceled operation's MESSAGE ID is now free for reuse.
发起者接收到带有非零RCODE的DSO响应消息后，从发起者的角度来看，该操作已终止，取消的操作的消息ID现在可以自由重用。
A DSO Session begins as described in Section 5.1.
DSO会话按照第5.1节所述开始。
Once a DSO Session has been created, client or server may initiate as many DNS operations as they wish using the DSO Session.
创建DSO会话后，客户机或服务器可以使用DSO会话启动任意数量的DNS操作。
When an initiator has multiple messages to send, it SHOULD NOT wait for each response before sending the next message.
当启动器有多条消息要发送时，它不应该在发送下一条消息之前等待每个响应。
A responder MUST act on messages in the order they are received, and SHOULD return responses to request messages as they become available. A responder SHOULD NOT delay sending responses for the purpose of delivering responses in the same order that the corresponding requests were received.
响应者必须按照收到消息的顺序对消息进行处理，并在消息可用时返回对请求消息的响应。响应者不应延迟发送响应，以便按照接收相应请求的相同顺序发送响应。
Section 6.2.1.1 of the DNS-over-TCP specification [RFC7766] specifies this in more detail.
DNS over TCP规范[RFC7766]第6.2.1.1节对此作了更详细的规定。
Two timeout values are associated with a DSO Session: the inactivity timeout and the keepalive interval. Both values are communicated in the same TLV, the Keepalive TLV (Section 7.1).
两个超时值与DSO会话相关：非活动超时和保持活动间隔。这两个值在相同的TLV（保持TLV）中进行通信（第7.1节）。
The first timeout value, the inactivity timeout, is the maximum time for which a client may speculatively keep an inactive DSO Session open in the expectation that it may have future requests to send to that server.
第一个超时值，即非活动超时，是客户机可以推测地保持非活动DSO会话处于打开状态的最长时间，以期望将来有请求发送到该服务器。
The second timeout value, the keepalive interval, is the maximum permitted interval between messages if the client wishes to keep the DSO Session alive.
第二个超时值keepalive interval是如果客户端希望使DSO会话保持活动状态，则消息之间允许的最大间隔。
The two timeout values are independent. The inactivity timeout may be shorter, the same, or longer than the keepalive interval, though in most cases the inactivity timeout is expected to be shorter than the keepalive interval.
这两个超时值是独立的。不活动超时可能比keepalive间隔短、相同或更长，但在大多数情况下，不活动超时预计比keepalive间隔短。
A shorter inactivity timeout with a longer keepalive interval signals to the client that it should not speculatively keep an inactive DSO Session open for very long without reason, but when it does have an active reason to keep a DSO Session open, it doesn't need to be sending an aggressive level of DSO keepalive traffic to maintain that session. An example of this would be a client that has subscribed to DNS Push notifications. In this case, the client is not sending any traffic to the server, but the session is not inactive because there is an active request to the server to receive push notifications.
较短的非活动超时和较长的keepalive间隔向客户端发出信号，表明它不应无缘无故地推测性地将非活动DSO会话保持打开很长时间，但当它确实有保持DSO会话打开的活动原因时，它不需要发送高级别的DSO keepalive流量来维持该会话。例如，已订阅DNS推送通知的客户端。在这种情况下，客户端不会向服务器发送任何通信量，但会话不会处于非活动状态，因为存在向服务器发送的接收推送通知的活动请求。
A longer inactivity timeout with a shorter keepalive interval signals to the client that it may speculatively keep an inactive DSO Session open for a long time, but to maintain that inactive DSO Session it should be sending a lot of DSO keepalive traffic. This configuration is expected to be less common.
较长的非活动超时和较短的保留时间间隔向客户端发出信号，表明它可能会推测性地将非活动DSO会话保持长时间打开，但为了保持该非活动DSO会话，它应该发送大量的DSO保留流量。这种配置预计不太常见。
In the usual case where the inactivity timeout is shorter than the keepalive interval, it is only when a client has a long-lived, low-traffic operation that the keepalive interval comes into play in order to ensure that a sufficient residual amount of traffic is generated to maintain NAT and firewall state, and to assure the client and server that they still have connectivity to each other.
在通常情况下，如果非活动超时时间短于keepalive interval，则只有当客户端具有长寿命的低流量操作时，keepalive interval才会发挥作用，以确保生成足够的剩余流量来维持NAT和防火墙状态，并确保客户机和服务器之间仍然保持连接。
On a new DSO Session, if no explicit DSO Keepalive message exchange has taken place, the default value for both timeouts is 15 seconds.
在新的DSO会话上，如果没有发生明确的DSO Keepalive消息交换，则两个超时的默认值都是15秒。
For both timeouts, lower values of the timeout result in higher network traffic and a higher CPU load on the server.
对于这两种超时，较低的超时值会导致较高的网络流量和服务器上较高的CPU负载。
At both servers and clients, the generation or reception of any complete DNS message (including DNS requests, responses, updates, DSO messages, etc.) resets both timers for that DSO Session, with the one exception being that a DSO Keepalive message resets only the keepalive timer, not the inactivity timeout timer.
在服务器和客户机上，生成或接收任何完整的DNS消息（包括DNS请求、响应、更新、DSO消息等）都会重置该DSO会话的两个计时器，唯一的例外是DSO Keepalive消息仅重置Keepalive计时器，而不是不活动超时计时器。
In addition, for as long as the client has an outstanding operation in progress, the inactivity timer remains cleared and an inactivity timeout cannot occur.
此外，只要客户端有一个未完成的操作正在进行，不活动计时器就会保持清除状态，并且不会发生不活动超时。
For short-lived DNS operations like traditional queries and updates, an operation is considered "in progress" for the time between request and response, typically a period of a few hundred milliseconds at most. At the client, the inactivity timer is cleared upon transmission of a request and remains cleared until reception of the corresponding response. At the server, the inactivity timer is cleared upon reception of a request and remains cleared until transmission of the corresponding response.
对于像传统查询和更新这样的短期DNS操作，在请求和响应之间的一段时间内，操作被视为“正在进行”，通常最长为几百毫秒。在客户端，在发送请求时清除非活动计时器，并保持清除状态，直到接收到相应的响应。在服务器上，在接收到请求时清除非活动计时器，并保持清除状态，直到发送相应的响应。
For long-lived DNS Stateful Operations (such as a Push Notification subscription [Push] or a Discovery Relay interface subscription [Relay]), an operation is considered "in progress" for as long as the operation is active, i.e., until it is canceled. This means that a DSO Session can exist with active operations, with no messages flowing in either direction, for far longer than the inactivity timeout. This is not an error. This is why there are two separate timers: the inactivity timeout and the keepalive interval. Just because a DSO Session has no traffic for an extended period of time, it does not automatically make that DSO Session "inactive", if it has an active operation that is awaiting events.
对于长期存在的DNS有状态操作（例如推送通知订阅[Push]或发现中继接口订阅[Relay]），只要操作处于活动状态，即直到取消为止，操作都被视为“正在进行”。这意味着DSO会话可以在活动操作的情况下存在，没有消息向任何方向流动，持续时间远远超过非活动超时。这不是一个错误。这就是为什么有两个独立的计时器：非活动超时和保持活动间隔。仅仅因为DSO会话在很长一段时间内没有通信量，如果它有一个正在等待事件的活动操作，它不会自动使该DSO会话处于“非活动”状态。
The purpose of the inactivity timeout is for the server to balance the trade-off between the costs of setting up new DSO Sessions and the costs of maintaining inactive DSO Sessions. A server with abundant DSO Session capacity can offer a high inactivity timeout to permit clients to keep a speculative DSO Session open for a long time and to save the cost of establishing a new DSO Session for future communications with that server. A server with scarce memory resources can offer a low inactivity timeout to cause clients to promptly close DSO Sessions whenever they have no outstanding operations with that server and then create a new DSO Session later when needed.
非活动超时的目的是让服务器在设置新DSO会话的成本和维护非活动DSO会话的成本之间取得平衡。具有丰富DSO会话容量的服务器可以提供高非活动超时，以允许客户端将推测DSO会话保持长时间打开，并节省为将来与该服务器通信而建立新DSO会话的成本。内存资源稀缺的服务器可以提供较低的非活动超时，以使客户端在与该服务器没有未完成的操作时立即关闭DSO会话，然后在需要时创建新的DSO会话。
When a connection's inactivity timeout is reached, the client MUST begin closing the idle connection, but a client is not required to keep an idle connection open until the inactivity timeout is reached. A client MAY close a DSO Session at any time, at the client's discretion. If a client determines that it has no current or reasonably anticipated future need for a currently inactive DSO Session, then the client SHOULD gracefully close that connection.
当达到连接的非活动超时时，客户端必须开始关闭空闲连接，但在达到非活动超时之前，客户端无需保持空闲连接打开。客户可自行决定随时关闭DSO会话。如果客户端确定其当前或合理预期的未来不需要当前不活动的DSO会话，则客户端应正常关闭该连接。
If, at any time during the life of the DSO Session, the inactivity timeout value (i.e., 15 seconds by default) elapses without there being any operation active on the DSO Session, the client MUST close the connection gracefully.
如果在DSO会话生命周期内的任何时候，不活动超时值（即默认情况下15秒）已过，而DSO会话上没有任何活动操作，则客户端必须正常关闭连接。
If, at any time during the life of the DSO Session, too much time elapses without there being any operation active on the DSO Session, then the server MUST consider the client delinquent and MUST forcibly abort the DSO Session. What is considered "too much time" in this context is five seconds or twice the current inactivity timeout value, whichever is greater. If the inactivity timeout has its default value of 15 seconds, this means that a client will be considered delinquent and disconnected if it has not closed its connection after 30 seconds of inactivity.
如果在DSO会话的生命周期中的任何时间，经过太多的时间而没有在DSO会话上有任何活动，那么服务器必须考虑客户端违法，并且必须强制中止DSO会话。在此上下文中，被视为“时间过长”的是5秒或当前非活动超时值的两倍，以较大者为准。如果不活动超时的默认值为15秒，这意味着如果客户端在30秒不活动后未关闭其连接，则该客户端将被视为拖欠并断开连接。
In this context, an operation being active on a DSO Session includes a query waiting for a response, an update waiting for a response, or an active long-lived operation, but not a DSO Keepalive message exchange itself. A DSO Keepalive message exchange resets only the keepalive interval timer, not the inactivity timeout timer.
在此上下文中，DSO会话上处于活动状态的操作包括等待响应的查询、等待响应的更新或活动的长期操作，但不包括DSO Keepalive消息交换本身。DSO Keepalive消息交换仅重置Keepalive间隔计时器，而不重置非活动超时计时器。
If the client wishes to keep an inactive DSO Session open for longer than the default duration, then it uses the DSO Keepalive message to request longer timeout values as described in Section 7.1.
如果客户端希望将非活动DSO会话保持打开状态的时间超过默认持续时间，则它将使用DSO Keepalive消息请求更长的超时值，如第7.1节所述。
For the inactivity timeout value, lower values result in more frequent DSO Session teardowns and re-establishments. Higher values result in lower traffic and a lower CPU load on the server, but a higher memory burden to maintain state for inactive DSO Sessions.
对于非活动超时值，值越低，DSO会话断开和重新建立的频率越高。值越高，服务器上的通信量越低，CPU负载越低，但维护非活动DSO会话状态的内存负担越大。
A server may dictate any value it chooses for the inactivity timeout (either in a response to a client-initiated request or in a server-initiated message) including values under one second, or even zero.
服务器可以指定它为非活动超时选择的任何值（在响应客户端启动的请求或服务器启动的消息中），包括1秒以下的值，甚至零。
An inactivity timeout of zero informs the client that it should not speculatively maintain idle connections at all, and as soon as the client has completed the operation or operations relating to this server, the client should immediately begin closing this session.
非活动超时为零将通知客户端，它根本不应推测性地维护空闲连接，并且一旦客户端完成与此服务器相关的一个或多个操作，客户端应立即开始关闭此会话。
A server will forcibly abort an idle client session after five seconds or twice the inactivity timeout value, whichever is greater. In the case of a zero inactivity timeout value, this means that if a client fails to close an idle client session, then the server will forcibly abort the idle session after five seconds.
服务器将在5秒或非活动超时值的两倍（以较大者为准）后强制中止空闲客户端会话。在非活动超时值为零的情况下，这意味着如果客户端无法关闭空闲客户端会话，则服务器将在五秒钟后强制中止空闲会话。
An inactivity timeout of 0xFFFFFFFF represents "infinity" and informs the client that it may keep an idle connection open as long as it wishes. Note that after granting an unlimited inactivity timeout in this way, at any point the server may revise that inactivity timeout by sending a new DSO Keepalive message dictating new Session Timeout values to the client.
0xFFFFFF的非活动超时表示“无限”，并通知客户端，只要它愿意，它可以保持空闲连接打开。请注意，在以这种方式授予无限非活动超时后，服务器可以随时通过向客户端发送新的DSO Keepalive消息来修改该非活动超时，该消息指示新的会话超时值。
The largest *finite* inactivity timeout supported by the current Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 days).
当前Keepalive TLV支持的最大*有限*非活动超时为0xFFFFFE（2^32-2毫秒，约49.7天）。
The purpose of the keepalive interval is to manage the generation of sufficient messages to maintain state in middleboxes (such at NAT gateways or firewalls) and for the client and server to periodically verify that they still have connectivity to each other. This allows them to clean up state when connectivity is lost and to establish a new session if appropriate.
keepalive间隔的目的是管理生成足够的消息，以维护中间盒（如NAT网关或防火墙）中的状态，并让客户端和服务器定期验证它们是否仍然彼此连接。这允许他们在连接丢失时清除状态，并在适当时建立新会话。
If, at any time during the life of the DSO Session, the keepalive interval value (i.e., 15 seconds by default) elapses without any DNS messages being sent or received on a DSO Session, the client MUST take action to keep the DSO Session alive by sending a DSO Keepalive message (Section 7.1). A DSO Keepalive message exchange resets only the keepalive timer, not the inactivity timer.
如果在DSO会话生命周期内的任何时候，keepalive interval值（即，默认情况下15秒）在DSO会话上未发送或接收任何DNS消息的情况下消失，则客户端必须通过发送DSO keepalive消息来采取措施，使DSO会话保持活动状态（第7.1节）。DSO Keepalive消息交换仅重置Keepalive计时器，而不重置非活动计时器。
If a client disconnects from the network abruptly, without cleanly closing its DSO Session, perhaps leaving a long-lived operation uncanceled, the server learns of this after failing to receive the required DSO keepalive traffic from that client. If, at any time during the life of the DSO Session, twice the keepalive interval value (i.e., 30 seconds by default) elapses without any DNS messages being sent or received on a DSO Session, the server SHOULD consider the client delinquent and SHOULD forcibly abort the DSO Session.
如果客户机突然断开与网络的连接，而没有完全关闭其DSO会话，可能使长期运行的操作未取消，则服务器在未能从该客户机接收到所需的DSO keepalive通信量后会了解到这一点。如果在DSO会话的生命周期中的任何时间，经过两次保持活动间隔值（即默认为30秒），而没有在DSO会话上发送或接收任何DNS消息，则服务器应考虑客户端拖欠，并应强制中止DSO会话。
For the keepalive interval value, lower values result in a higher volume of DSO keepalive traffic. Higher values of the keepalive interval reduce traffic and the CPU load, but have minimal effect on the memory burden at the server because clients keep a DSO Session open for the same length of time (determined by the inactivity timeout) regardless of the level of DSO keepalive traffic required.
对于keepalive interval值，值越低，DSO keepalive通信量越大。较高的keepalive interval值可以减少通信量和CPU负载，但对服务器上的内存负担影响最小，因为无论所需的DSO keepalive通信量是多少，客户端都会将DSO会话保持在相同的打开时间长度（由非活动超时确定）。
It may be appropriate for clients and servers to select different keepalive intervals depending on the type of network they are on.
客户机和服务器可以根据所处的网络类型选择不同的保持间隔。
A corporate DNS server that knows it is serving only clients on the internal network, with no intervening NAT gateways or firewalls, can impose a longer keepalive interval because frequent DSO keepalive traffic is not required.
如果公司DNS服务器知道它只为内部网络上的客户机提供服务，而不干预NAT网关或防火墙，则可以施加更长的保持间隔，因为不需要频繁的DSO保持通信。
A public DNS server that is serving primarily residential consumer clients, where it is likely there will be a NAT gateway on the path, may impose a shorter keepalive interval to generate more frequent DSO keepalive traffic.
主要为住宅用户客户端服务的公共DNS服务器（路径上可能有NAT网关）可能会施加较短的保持间隔以生成更频繁的DSO保持通信。
A smart client may be adaptive to its environment. A client using a private IPv4 address [RFC1918] to communicate with a DNS server at an address outside that IPv4 private address block may conclude that there is likely to be a NAT gateway on the path, and accordingly request a shorter keepalive interval.
智能客户端可以适应其环境。使用专用IPv4地址[RFC1918]与位于该IPv4专用地址块之外的地址处的DNS服务器通信的客户端可能认为路径上可能存在NAT网关，并相应地请求更短的保持间隔。
By default, it is RECOMMENDED that clients request, and servers grant, a keepalive interval of 60 minutes. This keepalive interval provides for reasonably timely detection if a client abruptly disconnects without cleanly closing the session. Also, it is sufficient to maintain state in firewalls and NAT gateways that follow the IETF recommended Best Current Practice that the "established connection idle-timeout" used by middleboxes be at least 2 hours and 4 minutes [RFC5382] [RFC7857].
默认情况下，建议客户端请求，服务器授予60分钟的保持间隔。如果客户端在没有完全关闭会话的情况下突然断开连接，此keepalive间隔提供了合理的及时检测。此外，在遵循IETF建议的最佳当前实践的防火墙和NAT网关中保持状态就足够了，即中间盒使用的“已建立连接空闲超时”至少为2小时4分钟[RFC5382][RFC7857]。
Note that the shorter the keepalive interval value, the higher the load on client and server. Moreover, for a keepalive value that is shorter than the time needed for the transport to retransmit, the loss of a single packet would cause a server to overzealously abort the connection. For example, a (hypothetical and unrealistic) keepalive interval value of 100 ms would result in a continuous stream of ten messages per second or more (if allowed by the current congestion control window) in both directions to keep the DSO Session alive. And, in this extreme example, a single retransmission over a path with, as an example, 100 ms RTT would introduce a momentary pause in the stream of messages long enough to cause the server to abort the connection.
请注意，keepalive interval值越短，客户端和服务器上的负载就越高。此外，对于短于传输重新传输所需时间的keepalive值，丢失单个数据包将导致服务器过度中断连接。例如，100 ms的（假设的和不现实的）keepalive interval值将在两个方向上产生每秒10条或更多的连续消息流（如果当前拥塞控制窗口允许），以保持DSO会话处于活动状态。并且，在这个极端的例子中，在一条路径上的一次重传（例如100 ms RTT）会在消息流中引入一个短暂的暂停，其时间足以导致服务器中止连接。
Because of this concern, the server MUST NOT send a DSO Keepalive message (either a DSO response to a client-initiated DSO request or a server-initiated DSO message) with a keepalive interval value less than ten seconds. If a client receives a DSO Keepalive message specifying a keepalive interval value less than ten seconds, this is a fatal error and the client MUST forcibly abort the connection immediately.
由于此问题，服务器不得发送Keepalive interval值小于10秒的DSO Keepalive消息（DSO对客户端启动的DSO请求的响应或服务器启动的DSO消息）。如果客户端收到指定Keepalive interval值小于10秒的DSO Keepalive消息，则这是一个致命错误，客户端必须立即强制中止连接。
A keepalive interval value of 0xFFFFFFFF represents "infinity" and informs the client that it should generate no DSO keepalive traffic. Note that after signaling that the client should generate no DSO keepalive traffic in this way, the server may at any point revise that DSO keepalive traffic requirement by sending a new DSO Keepalive message dictating new Session Timeout values to the client.
keepalive interval值0xFFFFFF表示“无限”，并通知客户端它不应生成DSO keepalive通信量。注意，在以这种方式发出客户机不应生成DSO keepalive通信量的信号之后，服务器可以在任何时候通过向客户机发送新的DSO keepalive消息来修改该DSO keepalive通信量要求，该消息指示新的会话超时值。
The largest *finite* keepalive interval supported by the current Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 days).
当前keepalive TLV支持的最大*有限*keepalive间隔为0xFFFFFE（2^32-2毫秒，约49.7天）。
In addition to canceling individual long-lived operations selectively (Section 5.6), there are also occasions where a server may need to terminate one or more entire DSO sessions. An entire DSO session may need to be terminated if the client is defective in some way or departs from the network without closing its DSO session. DSO Sessions may also need to be terminated if the server becomes overloaded or is reconfigured and lacks the ability to be selective about which operations need to be canceled.
除了有选择地取消单个长期操作（第5.6节）外，有时服务器可能需要终止一个或多个完整的DSO会话。如果客户端在某种程度上存在缺陷，或者在未关闭其DSO会话的情况下离开网络，则可能需要终止整个DSO会话。如果服务器过载或重新配置，并且无法选择需要取消哪些操作，则可能需要终止DSO会话。
This section discusses various reasons a DSO session may be terminated and the mechanisms for doing so.
本节讨论DSO会话可能终止的各种原因以及终止的机制。
In normal operation, closing a DSO Session is the client's responsibility. The client makes the determination of when to close a DSO Session based on an evaluation of both its own needs and the inactivity timeout value dictated by the server. A server only causes a DSO Session to be ended in the exceptional circumstances outlined below. Some of the exceptional situations in which a server may terminate a DSO Session include:
在正常操作中，关闭DSO会话是客户端的责任。客户机根据对其自身需求和服务器指定的非活动超时值的评估来确定何时关闭DSO会话。服务器仅在下列异常情况下导致DSO会话结束。服务器可能终止DSO会话的一些例外情况包括：
o The server application software or underlying operating system is shutting down or restarting.
o 服务器应用程序软件或基础操作系统正在关闭或重新启动。
o The server application software terminates unexpectedly (perhaps due to a bug that makes it crash, causing the underlying operating system to send a TCP RST).
o 服务器应用程序软件意外终止（可能是由于导致其崩溃的错误，导致底层操作系统发送TCP RST）。
o The server is undergoing a reconfiguration or maintenance procedure that, due to the way the server software is implemented, requires clients to be disconnected. For example, some software is implemented such that it reads a configuration file at startup, and changing the server's configuration entails modifying the configuration file and then killing and restarting the server software, which generally entails a loss of network connections.
o 服务器正在经历重新配置或维护过程，由于服务器软件的实现方式，需要断开客户端的连接。例如，某些软件在启动时读取配置文件，而更改服务器的配置需要修改配置文件，然后关闭并重新启动服务器软件，这通常会导致网络连接丢失。
o The client fails to meet its obligation to generate the required DSO keepalive traffic or to close an inactive session by the prescribed time (five seconds or twice the time interval dictated by the server, whichever is greater, as described in Section 6.2).
o 客户端未能在规定的时间内（5秒或服务器规定的时间间隔的两倍，以较大者为准，如第6.2节所述）履行生成所需DSO keepalive流量或关闭非活动会话的义务。
o The client sends a grossly invalid or malformed request that is indicative of a seriously defective client implementation.
o 客户端发送的请求严重无效或格式错误，表明客户端实现存在严重缺陷。
o The server is over capacity and needs to shed some load.
o 服务器容量过大，需要卸载一些负载。
In the cases described above where a server elects to terminate a DSO Session, it could do so simply by forcibly aborting the connection. However, if it did this, the likely behavior of the client might be simply to treat this as a network failure and reconnect immediately, putting more burden on the server.
在上述情况下，服务器选择终止DSO会话，只需强制中止连接即可。但是，如果它这样做了，客户端的可能行为可能只是将其视为网络故障并立即重新连接，从而给服务器带来更多负担。
Therefore, to avoid this reconnection implosion, a server SHOULD instead choose to shed client load by sending a Retry Delay message with an appropriate RCODE value informing the client of the reason the DSO Session needs to be terminated. The format of the DSO Retry Delay TLV and the interpretations of the various RCODE values are described in Section 7.2. After sending a DSO Retry Delay message, the server MUST NOT send any further messages on that DSO Session.
因此，为了避免这种重新连接内爆，服务器应该选择通过发送带有适当RCODE值的重试延迟消息来释放客户端负载，通知客户端需要终止DSO会话的原因。第7.2节描述了DSO重试延迟TLV的格式和各种RCODE值的解释。发送DSO重试延迟消息后，服务器不得在该DSO会话上再发送任何消息。
The server MAY randomize retry delays in situations where many retry delays are sent in quick succession so as to avoid all the clients attempting to reconnect at once. In general, implementations should avoid using the DSO Retry Delay message in a way that would result in many clients reconnecting at the same time if every client attempts to reconnect at the exact time specified.
在快速连续发送多个重试延迟的情况下，服务器可能会随机化重试延迟，以避免所有客户端同时尝试重新连接。一般来说，如果每个客户机都试图在指定的确切时间重新连接，则实现应避免使用DSO重试延迟消息，从而导致许多客户机同时重新连接。
Upon receipt of a DSO Retry Delay message from the server, the client MUST make note of the reconnect delay for this server and then immediately close the connection gracefully.
从服务器收到DSO重试延迟消息后，客户端必须记录此服务器的重新连接延迟，然后立即正常关闭连接。
After sending a DSO Retry Delay message, the server SHOULD allow the client five seconds to close the connection, and if the client has not closed the connection after five seconds, then the server SHOULD forcibly abort the connection.
发送DSO重试延迟消息后，服务器应允许客户端5秒钟关闭连接，如果客户端在5秒钟后仍未关闭连接，则服务器应强制中止连接。
A DSO Retry Delay message MUST NOT be initiated by a client. If a server receives a DSO Retry Delay message, this is a fatal error and the server MUST forcibly abort the connection immediately.
DSO重试延迟消息不能由客户端启动。如果服务器收到DSO重试延迟消息，这是一个致命错误，服务器必须立即强制中止连接。
At the instant a server chooses to initiate a DSO Retry Delay message, there may be DNS requests already in flight from client to server on this DSO Session, which will arrive at the server after its DSO Retry Delay message has been sent. The server MUST silently ignore such incoming requests and MUST NOT generate any response messages for them. When the DSO Retry Delay message from the server arrives at the client, the client will determine that any DNS requests it previously sent on this DSO Session that have not yet received a response will now certainly not be receiving any response.
当服务器选择启动DSO重试延迟消息时，此DSO会话上可能已经有DNS请求正在从客户端传输到服务器，这些请求将在发送其DSO重试延迟消息后到达服务器。服务器必须以静默方式忽略此类传入请求，并且不得为其生成任何响应消息。当来自服务器的DSO重试延迟消息到达客户端时，客户端将确定它以前在此DSO会话上发送的尚未收到响应的任何DNS请求现在肯定不会收到任何响应。
Such requests should be considered failed and should be retried at a later time, as appropriate.
此类请求应被视为失败，并应在以后酌情重试。
In the case where some, but not all, of the existing operations on a DSO Session have become invalid (perhaps because the server has been reconfigured and is no longer authoritative for some of the names), but the server is terminating all affected DSO Sessions en masse by sending them all a DSO Retry Delay message, the reconnect delay MAY be zero, indicating that the clients SHOULD immediately attempt to re-establish operations.
如果DSO会话上的某些（但不是全部）现有操作已无效（可能是因为服务器已重新配置，不再对某些名称具有权威性），但服务器通过向所有受影响的DSO会话发送DSO重试延迟消息来终止所有受影响的DSO会话，则重新连接延迟可能为零，指示客户端应立即尝试重新建立操作。
It is likely that some of the attempts will be successful and some will not, depending on the nature of the reconfiguration.
根据重新配置的性质，可能有些尝试会成功，有些则不会成功。
In the case where a server is terminating a large number of DSO Sessions at once (e.g., if the system is restarting) and the server doesn't want to be inundated with a flood of simultaneous retries, it SHOULD send different reconnect delay values to each client. These adjustments MAY be selected randomly, pseudorandomly, or deterministically (e.g., incrementing the time value by one tenth of a second for each successive client, yielding a post-restart reconnection rate of ten clients per second).
如果服务器一次终止大量DSO会话（例如，如果系统正在重新启动），并且服务器不希望被大量同时重试淹没，则应向每个客户端发送不同的重新连接延迟值。可以随机、伪随机或确定地选择这些调整（例如，将每个连续客户端的时间值增加十分之一秒，产生每秒十个客户端的重启后重新连接速率）。
A server may determine that a client is not following the protocol correctly. There may be no way for the server to recover the DSO session, in which case the server forcibly terminates the connection. Since the client doesn't know why the connection dropped, it may reconnect immediately. If the server has determined that a client is not following the protocol correctly, it MAY terminate the DSO Session as soon as it is established, specifying a long retry-delay to prevent the client from immediately reconnecting.
服务器可能会确定客户端未正确遵循协议。服务器可能无法恢复DSO会话，在这种情况下，服务器会强制终止连接。由于客户端不知道连接断开的原因，因此可能会立即重新连接。如果服务器已确定客户端未正确遵循协议，则可能会在建立DSO会话后立即终止该会话，并指定较长的重试延迟以防止客户端立即重新连接。
After a DSO Session is ended by the server (either by sending the client a DSO Retry Delay message or by forcibly aborting the underlying transport connection), the client SHOULD try to reconnect to that service instance or to another suitable service instance if more than one is available. If reconnecting to the same service instance, the client MUST respect the indicated delay, if available, before attempting to reconnect. Clients SHOULD NOT attempt to randomize the delay; the server will randomly jitter the retry delay values it sends to each client if this behavior is desired.
服务器结束DSO会话（通过向客户端发送DSO重试延迟消息或通过强制中止基础传输连接）后，客户端应尝试重新连接到该服务实例或其他合适的服务实例（如果有多个可用）。如果重新连接到同一服务实例，则客户端必须遵守指示的延迟（如果可用），然后再尝试重新连接。客户不应尝试将延迟随机化；如果需要这种行为，服务器将随机抖动发送给每个客户端的重试延迟值。
If a particular service instance will only be out of service for a short maintenance period, it should indicate a retry delay value that is a little longer than the expected maintenance window. It should not default to a very large delay value, or clients may not attempt to reconnect promptly after it resumes service.
如果某个特定服务实例仅在短维护期内停止服务，则它应指示一个重试延迟值，该值略长于预期的维护窗口。它不应默认为非常大的延迟值，否则客户端可能不会在恢复服务后立即尝试重新连接。
If a service instance does not want a client to reconnect ever (perhaps the service instance is being decommissioned), it SHOULD set the retry delay to the maximum value 0xFFFFFFFF (2^32-1 milliseconds, approximately 49.7 days). It is not possible to instruct a client to stay away for longer than 49.7 days. If, after 49.7 days, the DNS or other configuration information still indicates that this is the valid service instance for a particular service, then clients MAY attempt to reconnect. In reality, if a client is rebooted or otherwise loses state, it may well attempt to reconnect before 49.7 days elapse, for as long as the DNS or other configuration information continues to indicate that this is the service instance the client should use.
如果服务实例不希望客户端重新连接（可能服务实例正在停用），则应将重试延迟设置为最大值0xFFFFFF（2^32-1毫秒，约49.7天）。不可能指示客户离开超过49.7天。如果在49.7天后，DNS或其他配置信息仍然指示这是特定服务的有效服务实例，则客户端可能会尝试重新连接。实际上，如果客户端重新启动或以其他方式失去状态，它很可能会在49.7天之前尝试重新连接，只要DNS或其他配置信息继续指示这是客户端应该使用的服务实例。
If a connection was forcibly aborted by the client due to noncompliant behavior by the server, the client SHOULD mark that service instance as not supporting DSO. The client MAY reconnect but not attempt to use DSO, or it may connect to a different service instance if applicable.
如果由于服务器的不符合行为而导致客户端强制中止连接，则客户端应将该服务实例标记为不支持DSO。客户端可以重新连接，但不尝试使用DSO，也可以连接到不同的服务实例（如果适用）。
It is also possible for a server to forcibly terminate the connection; in this case, the client doesn't know whether the termination was the result of a protocol error or a network outage. When the client notices that the connection has been dropped, it can attempt to reconnect immediately. However, if the connection is dropped again without the client being able to successfully do whatever it is trying to do, it should mark the server as not supporting DSO.
服务器也可以强制终止连接；在这种情况下，客户端不知道终止是协议错误还是网络中断的结果。当客户端注意到连接已断开时，它可以尝试立即重新连接。但是，如果再次断开连接而客户端无法成功执行其尝试执行的任何操作，则应将服务器标记为不支持DSO。
Once a server has been marked by the client as not supporting DSO, the client SHOULD NOT attempt DSO operations on that server until some time has elapsed. A reasonable minimum would be an hour. Since forcibly aborted connections are the result of a software failure, it's not likely that the problem will be solved in the first hour after it's first encountered. However, by restricting the retry interval to an hour, the client will be able to notice when the problem has been fixed without placing an undue burden on the server.
一旦客户机将服务器标记为不支持DSO，客户机就不应在该服务器上尝试DSO操作，直到过了一段时间。合理的最低要求是一小时。由于强制中断连接是软件故障的结果，因此问题不太可能在第一次遇到后的第一个小时内得到解决。但是，通过将重试间隔限制为一小时，客户机将能够注意到问题何时得到解决，而不会给服务器带来不必要的负担。
This section describes the three base TLVs for DNS Stateful Operations: Keepalive, Retry Delay, and Encryption Padding.
本节介绍DNS有状态操作的三个基本TLV：Keepalive、重试延迟和加密填充。
The Keepalive TLV (DSO-TYPE=1) performs two functions. Primarily, it establishes the values for the Session Timeouts. Incidentally, it also resets the keepalive timer for the DSO Session, meaning that it can be used as a kind of "no-op" message for the purpose of keeping a session alive. The client will request the desired Session Timeout values and the server will acknowledge with the response values that it requires the client to use.
Keepalive TLV（DSO-TYPE=1）执行两个功能。它主要为会话超时设置值。顺便说一句，它还重置DSO会话的keepalive计时器，这意味着它可以用作一种“无操作”消息，以保持会话处于活动状态。客户端将请求所需的会话超时值，服务器将使用它要求客户端使用的响应值进行确认。
DSO messages with the Keepalive TLV as the Primary TLV may appear in early data.
以Keepalive TLV为主TLV的DSO消息可能会出现在早期数据中。
The DSO-DATA for the Keepalive TLV is as follows:
Keepalive TLV的DSO-DATA如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INACTIVITY TIMEOUT (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEEPALIVE INTERVAL (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INACTIVITY TIMEOUT (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEEPALIVE INTERVAL (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INACTIVITY TIMEOUT: The inactivity timeout for the current DSO Session, specified as a 32-bit unsigned integer, in network (big endian) byte order in units of milliseconds. This is the timeout at which the client MUST begin closing an inactive DSO Session. The inactivity timeout can be any value of the server's choosing. If the client does not gracefully close an inactive DSO Session, then after five seconds or twice this interval, whichever is greater, the server will forcibly abort the connection.
非活动超时：当前DSO会话的非活动超时，指定为32位无符号整数，以网络（big-endian）字节顺序为单位，以毫秒为单位。这是客户端必须开始关闭非活动DSO会话的超时时间。不活动超时可以是服务器选择的任何值。如果客户端未正常关闭非活动DSO会话，则在5秒或两次该间隔后（以较大者为准），服务器将强制中止连接。
KEEPALIVE INTERVAL: The keepalive interval for the current DSO Session, specified as a 32-bit unsigned integer, in network (big endian) byte order in units of milliseconds. This is the interval at which a client MUST generate DSO keepalive traffic to maintain connection state. The keepalive interval MUST NOT be less than ten seconds. If the client does not generate the mandated DSO keepalive traffic, then after twice this interval the server will forcibly abort the connection. Since the minimum allowed keepalive interval is ten seconds, the minimum time at which a server will forcibly disconnect a client for failing to generate the mandated DSO keepalive traffic is twenty seconds.
KEEPALIVE INTERVAL：当前DSO会话的KEEPALIVE INTERVAL，指定为32位无符号整数，以网络（big-endian）字节顺序为单位，以毫秒为单位。这是客户端必须生成DSO keepalive流量以保持连接状态的时间间隔。保持间隔不得小于10秒。如果客户端未生成强制的DSO keepalive通信量，则在此间隔两次后，服务器将强制中止连接。由于允许的最小keepalive间隔为10秒，因此服务器因无法生成强制DSO keepalive通信而强制断开客户端连接的最短时间为20秒。
The transmission or reception of DSO Keepalive messages (i.e., messages where the Keepalive TLV is the first TLV) reset only the keepalive timer, not the inactivity timer. The reason for this is that periodic DSO Keepalive messages are sent for the sole purpose of keeping a DSO Session alive when that DSO Session has current or recent non-maintenance activity that warrants keeping that DSO Session alive. Sending DSO keepalive traffic itself is not considered a client activity; it is considered a maintenance activity that is performed in service of other client activities. If DSO keepalive traffic itself were to reset the inactivity timer, then that would create a circular livelock where keepalive traffic would be sent indefinitely to keep a DSO Session alive. In this scenario, the only activity on that DSO Session would be the keepalive traffic keeping the DSO Session alive so that further keepalive traffic can be sent. For a DSO Session to be considered active, it must be carrying something more than just keepalive traffic. This is why merely sending or receiving a DSO Keepalive message does not reset the inactivity timer.
DSO Keepalive消息（即Keepalive TLV是第一个TLV的消息）的传输或接收仅重置Keepalive计时器，而不是非活动计时器。原因是，发送定期DSO Keepalive消息的唯一目的是在DSO会话具有当前或最近的非维护活动时保持该DSO会话的活动状态。发送DSO keepalive流量本身不被视为客户端活动；它被认为是为其他客户活动服务而执行的维护活动。如果DSO keepalive流量本身要重置非活动计时器，那么这将创建一个循环活锁，在该活锁中，keepalive流量将无限期发送，以保持DSO会话的活动状态。在这种情况下，该DSO会话上的唯一活动将是保持DSO会话活动的keepalive流量，以便可以发送更多keepalive流量。要将DSO会话视为活动会话，它必须承载的内容不仅仅是保持通信量。这就是为什么仅仅发送或接收DSO Keepalive消息不会重置非活动计时器的原因。
When sent by a client, the DSO Keepalive request message MUST be sent as a DSO request message with a nonzero MESSAGE ID. If a server receives a DSO Keepalive message with a zero MESSAGE ID, then this is a fatal error and the server MUST forcibly abort the connection immediately. The DSO Keepalive request message resets a DSO Session's keepalive timer and, at the same time, communicates to the server the client's requested Session Timeout values. In a server response to a client-initiated DSO Keepalive request message, the Session Timeouts contain the server's chosen values from this point forward in the DSO Session, which the client MUST respect. This is modeled after the DHCP protocol, where the client requests a certain lease lifetime using DHCP option 51 [RFC2132], but the server is the ultimate authority for deciding what lease lifetime is actually granted.
由客户端发送时，DSO Keepalive请求消息必须作为消息ID非零的DSO请求消息发送。如果服务器收到消息ID为零的DSO Keepalive消息，则这是一个致命错误，服务器必须立即强制中止连接。DSO Keepalive请求消息重置DSO会话的Keepalive计时器，同时向服务器发送客户端请求的会话超时值。在服务器对客户机启动的DSO Keepalive请求消息的响应中，会话超时包含从DSO会话的这一点开始服务器选择的值，客户机必须遵守这些值。这是按照DHCP协议建模的，在DHCP协议中，客户端使用DHCP选项51[RFC2132]请求特定的租约期限，但服务器是决定实际授予的租约期限的最终权威。
When a client is sending its second and subsequent DSO Keepalive request messages to the server, the client SHOULD continue to request its preferred values each time. This allows flexibility so that if conditions change during the lifetime of a DSO Session, the server can adapt its responses to better fit the client's needs.
当客户机向服务器发送其第二个和后续DSO Keepalive请求消息时，客户机每次都应继续请求其首选值。这允许灵活性，因此如果条件在DSO会话的生命周期内发生变化，服务器可以调整其响应以更好地满足客户机的需要。
Once a DSO Session is in progress (Section 5.1), a DSO Keepalive message MAY be initiated by a server. When sent by a server, the DSO Keepalive message MUST be sent as a DSO unidirectional message with the MESSAGE ID set to zero. The client MUST NOT generate a response to a server-initiated DSO Keepalive message. If a client receives a DSO Keepalive request message with a nonzero MESSAGE ID, then this is a fatal error and the client MUST forcibly abort the connection immediately. The DSO Keepalive unidirectional message from the
一旦DSO会话正在进行（第5.1节），服务器可能会启动DSO Keepalive消息。由服务器发送时，DSO Keepalive消息必须作为消息ID设置为零的DSO单向消息发送。客户端不得对服务器启动的DSO Keepalive消息生成响应。如果客户端接收到消息ID为非零的DSO Keepalive请求消息，则这是一个致命错误，客户端必须立即强制中止连接。DSO保留来自的单向消息
server resets a DSO Session's keepalive timer and, at the same time, unilaterally informs the client of the new Session Timeout values to use from this point forward in this DSO Session. No client DSO response to this unilateral declaration is required or allowed.
服务器重置DSO会话的keepalive计时器，同时，单方面通知客户端新的会话超时值，以便从此点开始在此DSO会话中使用。不需要或不允许客户DSO响应此单方面声明。
In DSO Keepalive response messages, exactly one instance of the Keepalive TLV MUST be present and is used only as a Response Primary TLV sent as a reply to a DSO Keepalive request message from the client. A Keepalive TLV MUST NOT be added to other responses as a Response Additional TLV. If the server wishes to update a client's Session Timeout values other than in response to a DSO Keepalive request message from the client, then it does so by sending a DSO Keepalive unidirectional message of its own, as described above.
在DSO Keepalive响应消息中，必须仅存在Keepalive TLV的一个实例，并且仅用作响应主TLV，作为对来自客户端的DSO Keepalive请求消息的答复发送。不能将Keepalive TLV作为响应附加TLV添加到其他响应中。如果服务器希望更新客户端的会话超时值，而不是响应来自客户端的DSO Keepalive请求消息，则它通过发送自己的DSO Keepalive单向消息来实现，如上所述。
It is not required that the Keepalive TLV be used in every DSO Session. While many DSO operations will be used in conjunction with a long-lived session state, not all DSO operations require a long-lived session state, and in some cases the default 15-second value for both the inactivity timeout and keepalive interval may be perfectly appropriate. However, note that for clients that implement only the DSO-TYPEs defined in this document, a DSO Keepalive request message is the only way for a client to initiate a DSO Session.
不要求在每个DSO会话中使用Keepalive TLV。虽然许多DSO操作将与长寿命会话状态结合使用，但并非所有DSO操作都需要长寿命会话状态，在某些情况下，不活动超时和保持活动间隔的默认15秒值可能非常合适。但是，请注意，对于仅实现本文档中定义的DSO类型的客户端，DSO Keepalive请求消息是客户端启动DSO会话的唯一方式。
When a client receives a response to its client-initiated DSO Keepalive request message, or receives a server-initiated DSO Keepalive unidirectional message, the client has then received Session Timeout values dictated by the server. The two timeout values contained in the Keepalive TLV from the server may each be higher, lower, or the same as the respective Session Timeout values the client previously had for this DSO Session.
当客户机接收到对其客户机启动的DSO Keepalive请求消息的响应，或接收到服务器启动的DSO Keepalive单向消息时，客户机随后接收到服务器指定的会话超时值。来自服务器的Keepalive TLV中包含的两个超时值可以分别高于、低于或等于客户端先前为此DSO会话拥有的相应会话超时值。
In the case of the keepalive timer, the handling of the received value is straightforward. The act of receiving the message containing the DSO Keepalive TLV itself resets the keepalive timer and updates the keepalive interval for the DSO Session. The new keepalive interval indicates the maximum time that may elapse before another message must be sent or received on this DSO Session, if the DSO Session is to remain alive.
在keepalive计时器的情况下，对接收值的处理非常简单。接收包含DSO Keepalive TLV本身的消息的行为会重置Keepalive计时器并更新DSO会话的Keepalive间隔。新的keepalive interval表示如果DSO会话要保持活动状态，则在此DSO会话上必须发送或接收另一条消息之前可能经过的最长时间。
In the case of the inactivity timeout, the handling of the received value is a little more subtle, though the meaning of the inactivity timeout remains as specified; it still indicates the maximum permissible time allowed without useful activity on a DSO Session. The act of receiving the message containing the Keepalive TLV does not itself reset the inactivity timer. The time elapsed since the last useful activity on this DSO Session is unaffected by exchange of
在非活动超时的情况下，接收值的处理稍微微妙一些，尽管非活动超时的含义仍然是指定的；它仍然指示在DSO会话上没有有用活动时允许的最大允许时间。接收包含Keepalive TLV的消息的行为本身不会重置非活动计时器。此DSO会话上自上次有用活动以来经过的时间不受数据交换的影响
DSO Keepalive messages. The new inactivity timeout value in the Keepalive TLV in the received message does update the timeout associated with the running inactivity timer; that becomes the new maximum permissible time without activity on a DSO Session.
DSO保留消息。接收到的消息中Keepalive TLV中的新非活动超时值会更新与正在运行的非活动计时器关联的超时；这将成为DSO会话上无活动的新的最大允许时间。
o If the current inactivity timer value is less than the new inactivity timeout, then the DSO Session may remain open for now. When the inactivity timer value reaches the new inactivity timeout, the client MUST then begin closing the DSO Session as described above.
o 如果当前非活动计时器值小于新的非活动超时，则DSO会话可能暂时保持打开状态。当非活动计时器值达到新的非活动超时时，客户端必须开始关闭DSO会话，如上所述。
o If the current inactivity timer value is equal to the new inactivity timeout, then this DSO Session has been inactive for exactly as long as the server will permit, and now the client MUST immediately begin closing this DSO Session.
o 如果当前非活动计时器值等于新的非活动超时，则此DSO会话在服务器允许的时间内一直处于非活动状态，现在客户端必须立即开始关闭此DSO会话。
o If the current inactivity timer value is already greater than the new inactivity timeout, then this DSO Session has already been inactive for longer than the server permits, and the client MUST immediately begin closing this DSO Session.
o 如果当前非活动计时器值已大于新的非活动超时，则此DSO会话的非活动时间已超过服务器允许的时间，并且客户端必须立即开始关闭此DSO会话。
o If the current inactivity timer value is already more than twice the new inactivity timeout, then the client is immediately considered delinquent (this DSO Session is immediately eligible to be forcibly terminated by the server) and the client MUST immediately begin closing this DSO Session. However, if a server abruptly reduces the inactivity timeout in this way, then, to give the client time to close the connection gracefully before the server resorts to forcibly aborting it, the server SHOULD give the client an additional grace period of either five seconds or one quarter of the new inactivity timeout, whichever is greater.
o 如果当前的非活动计时器值已超过新的非活动超时的两倍，则客户端立即被视为逾期（此DSO会话可立即被服务器强制终止），并且客户端必须立即开始关闭此DSO会话。但是，如果服务器以这种方式突然减少了非活动超时，那么，为了在服务器强制中止连接之前给客户端时间正常关闭连接，服务器应该给客户端额外的宽限期，即5秒或新的非活动超时的四分之一，以较大者为准。
The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has similar intent to the edns-tcp-keepalive EDNS(0) Option [RFC7828]. A client/server pair that supports DSO MUST NOT use the edns-tcp-keepalive EDNS(0) Option within any message after a DSO Session has been established. A client that has sent a DSO message to establish a session MUST NOT send an edns-tcp-keepalive EDNS(0) Option from this point on. Once a DSO Session has been established, if either client or server receives a DNS message over the DSO Session that contains an edns-tcp-keepalive EDNS(0) Option, this is a fatal error and the receiver of the edns-tcp-keepalive EDNS(0) Option MUST forcibly abort the connection immediately.
Keepalive TLV（DSO-TYPE=1）中的非活动超时值与edns tcp Keepalive edns（0）选项[RFC7828]具有类似的意图。在建立DSO会话后，支持DSO的客户端/服务器对不得在任何消息中使用edns tcp keepalive edns（0）选项。从现在起，已发送DSO消息以建立会话的客户端不得发送edns tcp keepalive edns（0）选项。一旦建立DSO会话，如果客户端或服务器通过包含edns tcp keepalive edns（0）选项的DSO会话接收到DNS消息，则这是一个致命错误，edns tcp keepalive edns（0）选项的接收方必须立即强制中止连接。
The Retry Delay TLV (DSO-TYPE=2) can be used as a Primary TLV (unidirectional) in a server-to-client message, or as a Response Additional TLV in either direction. DSO messages with a Relay Delay TLV as their Primary TLV are not permitted in early data.
重试延迟TLV（DSO-TYPE=2）可以用作服务器到客户端消息中的主TLV（单向），也可以用作任一方向上的响应附加TLV。早期数据中不允许使用中继延迟TLV作为主要TLV的DSO消息。
The DSO-DATA for the Retry Delay TLV is as follows:
重试延迟TLV的DSO-DATA如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETRY DELAY (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETRY DELAY (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RETRY DELAY: A time value, specified as a 32-bit unsigned integer in network (big endian) byte order, in units of milliseconds, within which the initiator MUST NOT retry this operation or retry connecting to this server. Recommendations for the RETRY DELAY value are given in Section 6.6.1.
重试延迟：一个时间值，以网络（big-endian）字节顺序指定为32位无符号整数，以毫秒为单位，在此时间内，启动器不得重试此操作或重试连接到此服务器。第6.6.1节给出了重试延迟值的建议。
When used as the Primary TLV in a DSO unidirectional message, the Retry Delay TLV is sent from server to client. It is used by a server to instruct a client to close the DSO Session and underlying connection, and not to reconnect for the indicated time interval.
当用作DSO单向消息中的主TLV时，重试延迟TLV从服务器发送到客户端。服务器使用它来指示客户端关闭DSO会话和底层连接，并且在指定的时间间隔内不重新连接。
In this case, it applies to the DSO Session as a whole, and the client MUST begin closing the DSO Session as described in Section 6.6.1. The RCODE in the message header SHOULD indicate the principal reason for the termination:
在这种情况下，它适用于整个DSO会话，客户端必须按照第6.6.1节所述开始关闭DSO会话。消息头中的RCODE应指明终止的主要原因：
o NOERROR indicates a routine shutdown or restart.
o 无错误表示例行关闭或重新启动。
o FORMERR indicates that a client DSO request was too badly malformed for the session to continue.
o FORMERR表示客户端DSO请求的格式严重错误，会话无法继续。
o SERVFAIL indicates that the server is overloaded due to resource exhaustion and needs to shed load.
o SERVFAIL表示服务器由于资源耗尽而过载，需要卸载。
o REFUSED indicates that the server has been reconfigured, and at this time it is now unable to perform one or more of the long-lived client operations that were previously being performed on this DSO Session.
o 拒绝表示服务器已重新配置，此时无法执行以前在此DSO会话上执行的一个或多个长期客户端操作。
o NOTAUTH indicates that the server has been reconfigured and at this time it is now unable to perform one or more of the long-lived client operations that were previously being performed on this DSO Session because it does not have authority over the names in question (for example, a DNS Push Notification server could be reconfigured such that it is no longer accepting DNS Push Notification requests for one or more of the currently subscribed names).
o NOTAUTH表示服务器已重新配置，目前无法执行以前在此DSO会话上执行的一个或多个长期客户端操作，因为它没有对相关名称的权限（例如，可以重新配置DNS推送通知服务器，使其不再接受一个或多个当前订阅名称的DNS推送通知请求）。
This document specifies only these RCODE values for the DSO Retry Delay message. Servers sending DSO Retry Delay messages SHOULD use one of these values. However, future circumstances may create situations where other RCODE values are appropriate in DSO Retry Delay messages, so clients MUST be prepared to accept DSO Retry Delay messages with any RCODE value.
本文档仅为DSO重试延迟消息指定这些RCODE值。发送DSO重试延迟消息的服务器应使用以下值之一。但是，未来的情况可能会造成其他RCODE值在DSO重试延迟消息中适用的情况，因此客户端必须准备好接受具有任何RCODE值的DSO重试延迟消息。
In some cases, when a server sends a DSO Retry Delay unidirectional message to a client, there may be more than one reason for the server wanting to end the session. Possibly, the configuration could have been changed such that some long-lived client operations can no longer be continued due to policy (REFUSED), and other long-lived client operations can no longer be performed due to the server no longer being authoritative for those names (NOTAUTH). In such cases, the server MAY use any of the applicable RCODE values, or RCODE=NOERROR (routine shutdown or restart).
在某些情况下，当服务器向客户端发送DSO重试延迟单向消息时，可能有多个原因导致服务器希望结束会话。可能已经更改了配置，使得某些长期客户端操作由于策略（拒绝）而无法继续，而其他长期客户端操作由于服务器不再具有这些名称的权限（NOTAUTH）而无法执行。在这种情况下，服务器可以使用任何适用的RCODE值，或RCODE=NOERROR（例行关闭或重新启动）。
Note that the selection of RCODE value in a DSO Retry Delay message is not critical since the RCODE value is generally used only for information purposes such as writing to a log file for future human analysis regarding the nature of the disconnection. Generally, clients do not modify their behavior depending on the RCODE value. The RETRY DELAY in the message tells the client how long it should wait before attempting a new connection to this service instance.
请注意，DSO重试延迟消息中RCODE值的选择并不重要，因为RCODE值通常仅用于信息目的，例如写入日志文件，以便将来对断开连接的性质进行人工分析。通常，客户端不会根据RCODE值修改其行为。消息中的重试延迟告诉客户端在尝试与此服务实例建立新连接之前应该等待多长时间。
For clients that do in some way modify their behavior depending on the RCODE value, they should treat unknown RCODE values the same as RCODE=NOERROR (routine shutdown or restart).
对于以某种方式根据RCODE值修改其行为的客户端，它们应将未知RCODE值视为与RCODE=NOERROR（例程关闭或重新启动）相同。
A DSO Retry Delay message (DSO message where the Primary TLV is Retry Delay) from server to client is a DSO unidirectional message; the MESSAGE ID MUST be set to zero in the outgoing message and the client MUST NOT send a response.
从服务器到客户端的DSO重试延迟消息（主TLV为重试延迟的DSO消息）是DSO单向消息；传出消息中的消息ID必须设置为零，并且客户端不得发送响应。
A client MUST NOT send a DSO Retry Delay message to a server. If a server receives a DSO message where the Primary TLV is the Retry Delay TLV, this is a fatal error and the server MUST forcibly abort the connection immediately.
客户端不得向服务器发送DSO重试延迟消息。如果服务器收到DSO消息，其中主TLV是重试延迟TLV，则这是一个致命错误，服务器必须立即强制中止连接。
In the case of a DSO request message that results in a nonzero RCODE value, the responder MAY append a Retry Delay TLV to the response, indicating the time interval during which the initiator SHOULD NOT attempt this operation again.
在导致非零RCODE值的DSO请求消息的情况下，响应者可以向响应附加重试延迟TLV，指示启动器不应再次尝试此操作的时间间隔。
The indicated time interval during which the initiator SHOULD NOT retry applies only to the failed operation, not to the DSO Session as a whole.
指示的启动器不应重试的时间间隔仅适用于失败的操作，而不适用于整个DSO会话。
Either a client or a server, whichever is acting in the role of the responder for a particular DSO request message, MAY append a Retry Delay TLV to an error response that it sends.
对于特定DSO请求消息，客户机或服务器（以响应者的角色为准）可以将重试延迟TLV附加到其发送的错误响应中。
The Encryption Padding TLV (DSO-TYPE=3) can only be used as an Additional or Response Additional TLV. It is only applicable when the DSO Transport layer uses encryption such as TLS.
加密填充TLV（DSO-TYPE=3）只能用作附加或响应附加TLV。它仅在DSO传输层使用加密（如TLS）时适用。
The DSO-DATA for the Padding TLV is optional and is a variable length field containing non-specified values. A DSO-LENGTH of 0 essentially provides for 4 bytes of padding (the minimum amount).
填充TLV的DSO-DATA是可选的，是包含非指定值的可变长度字段。DSO长度0基本上提供4字节的填充（最小数量）。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ /
/ PADDING -- VARIABLE NUMBER OF BYTES /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ /
/ PADDING -- VARIABLE NUMBER OF BYTES /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
As specified for the EDNS(0) Padding Option [RFC7830], the PADDING bytes SHOULD be set to 0x00. Other values MAY be used, for example, in cases where there is a concern that the padded message could be subject to compression before encryption. PADDING bytes of any value MUST be accepted in the messages received.
如为EDNS（0）填充选项[RFC7830]指定的，填充字节应设置为0x00。例如，在担心填充消息可能在加密之前受到压缩的情况下，可以使用其他值。接收的消息中必须接受任何值的填充字节。
The Encryption Padding TLV may be included in either a DSO request message, response, or both. As specified for the EDNS(0) Padding Option [RFC7830], if a DSO request message is received with an Encryption Padding TLV, then the DSO response MUST also include an Encryption Padding TLV.
加密填充TLV可以包含在DSO请求消息、响应或两者中。按照EDNS（0）填充选项[RFC7830]的规定，如果接收到带有加密填充TLV的DSO请求消息，则DSO响应还必须包括加密填充TLV。
The length of padding is intentionally not specified in this document and is a function of current best practices with respect to the type and length of data in the preceding TLVs [RFC8467].
本文件中有意未指定填充长度，它是关于前面TLV[RFC8467]中数据类型和长度的当前最佳实践的函数。
This section summarizes some noteworthy highlights about various aspects of the DSO protocol.
本节总结了有关DSO协议各个方面的一些值得注意的要点。
In DSO request messages, the QR bit is 0 and the MESSAGE ID is nonzero.
在DSO请求消息中，QR位为0，消息ID为非零。
In DSO response messages, the QR bit is 1 and the MESSAGE ID is nonzero.
在DSO响应消息中，QR位为1，消息ID为非零。
In DSO unidirectional messages, the QR bit is 0 and the MESSAGE ID is zero.
在DSO单向消息中，QR位为0，消息ID为零。
The table below illustrates which combinations are legal and how they are interpreted:
下表说明了哪些组合是合法的以及如何解释：
+------------------------------+------------------------+
| MESSAGE ID zero | MESSAGE ID nonzero |
+--------+------------------------------+------------------------+
| QR=0 | DSO unidirectional message | DSO request message |
+--------+------------------------------+------------------------+
| QR=1 | Invalid - Fatal Error | DSO response message |
+--------+------------------------------+------------------------+
+------------------------------+------------------------+
| MESSAGE ID zero | MESSAGE ID nonzero |
+--------+------------------------------+------------------------+
| QR=0 | DSO unidirectional message | DSO request message |
+--------+------------------------------+------------------------+
| QR=1 | Invalid - Fatal Error | DSO response message |
+--------+------------------------------+------------------------+
The table below indicates, for each of the three TLVs defined in this document, whether they are valid in each of ten different contexts.
下表表明，对于本文件中定义的三个TLV中的每一个，它们是否在十种不同的上下文中都有效。
The first five contexts are DSO requests or DSO unidirectional messages from client to server, and the corresponding responses from server back to client:
前五个上下文是从客户端到服务器的DSO请求或DSO单向消息，以及从服务器返回到客户端的相应响应：
o C-P - Primary TLV, sent in DSO request message, from client to server, with nonzero MESSAGE ID indicating that this request MUST generate response message.
o C-P—主TLV，在DSO请求消息中从客户端发送到服务器，消息ID为非零，表示此请求必须生成响应消息。
o C-U - Primary TLV, sent in DSO unidirectional message, from client to server, with zero MESSAGE ID indicating that this request MUST NOT generate response message.
o C-U-主TLV，在DSO单向消息中从客户端发送到服务器，消息ID为零，表示此请求不得生成响应消息。
o C-A - Additional TLV, optionally added to a DSO request message or DSO unidirectional message from client to server.
o C-A-附加TLV，可选地添加到DSO请求消息或从客户端到服务器的DSO单向消息中。
o CRP - Response Primary TLV, included in response message sent back to the client (in response to a client "C-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV in the request.
o CRP-响应主TLV，包含在发送回客户端的响应消息中（响应具有非零消息ID的客户端“C-P”请求，指示需要响应），其中响应TLV的DSO类型与请求中主TLV的DSO类型匹配。
o CRA - Response Additional TLV, included in response message sent back to the client (in response to a client "C-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV does not match the DSO-TYPE of the Primary TLV in the request.
o CRA-响应附加TLV，包含在发送回客户端的响应消息中（响应具有非零消息ID的客户端“C-P”请求，指示需要响应），其中响应TLV的DSO类型与请求中主TLV的DSO类型不匹配。
The second five contexts are their counterparts in the opposite direction: DSO requests or DSO unidirectional messages from server to client, and the corresponding responses from client back to server.
第二个五个上下文是相反方向的对应上下文：从服务器到客户端的DSO请求或DSO单向消息，以及从客户端到服务器的相应响应。
o S-P - Primary TLV, sent in DSO request message, from server to client, with nonzero MESSAGE ID indicating that this request MUST generate response message.
o S-P—主TLV，在DSO请求消息中从服务器发送到客户端，消息ID为非零，表示此请求必须生成响应消息。
o S-U - Primary TLV, sent in DSO unidirectional message, from server to client, with zero MESSAGE ID indicating that this request MUST NOT generate response message.
o S-U—主TLV，以DSO单向消息形式从服务器发送到客户端，消息ID为零，表示此请求不得生成响应消息。
o S-A - Additional TLV, optionally added to a DSO request message or DSO unidirectional message from server to client.
o S-A—附加TLV，可选地添加到从服务器到客户端的DSO请求消息或DSO单向消息中。
o SRP - Response Primary TLV, included in response message sent back to the server (in response to a server "S-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV in the request.
o SRP—响应主TLV，包含在发送回服务器的响应消息中（响应具有非零消息ID的服务器“S-P”请求，指示需要响应），其中响应TLV的DSO类型与请求中主TLV的DSO类型匹配。
o SRA - Response Additional TLV, included in response message sent back to the server (in response to a server "S-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV does not match the DSO-TYPE of the Primary TLV in the request.
o SRA—响应附加TLV，包含在发送回服务器的响应消息中（响应具有非零消息ID的服务器“S-P”请求，指示需要响应），其中响应TLV的DSO类型与请求中主TLV的DSO类型不匹配。
+-------------------------+-------------------------+
| C-P C-U C-A CRP CRA | S-P S-U S-A SRP SRA |
+------------+-------------------------+-------------------------+
| KeepAlive | X X | X |
+------------+-------------------------+-------------------------+
| RetryDelay | X | X X |
+------------+-------------------------+-------------------------+
| Padding | X X | X X |
+------------+-------------------------+-------------------------+
+-------------------------+-------------------------+
| C-P C-U C-A CRP CRA | S-P S-U S-A SRP SRA |
+------------+-------------------------+-------------------------+
| KeepAlive | X X | X |
+------------+-------------------------+-------------------------+
| RetryDelay | X | X X |
+------------+-------------------------+-------------------------+
| Padding | X X | X X |
+------------+-------------------------+-------------------------+
Note that some of the columns in this table are currently empty. The table provides a template for future TLV definitions to follow. It is recommended that definitions of future TLVs include a similar table summarizing the contexts where the new TLV is valid.
请注意，此表中的某些列当前为空。该表为将来的TLV定义提供了一个模板。建议未来TLV的定义包括一个类似的表，总结新TLV有效的上下文。
We use the term "service instance" to refer to software running on a host that can receive connections on some set of { IP address, port } tuples. What makes the software an instance is that regardless of which of these tuples the client uses to connect to it, the client is connected to the same software, running on the same logical node (see Section 9.2), and will receive the same answers and the same keying information.
我们使用术语“服务实例”来指运行在主机上的软件，该软件可以在某组{IP地址，端口}元组上接收连接。使软件成为一个实例的原因是，无论客户机使用哪一个元组连接到它，客户机都连接到运行在同一逻辑节点上的同一软件（参见第9.2节），并将收到相同的答案和相同的键控信息。
Service instances are identified from the perspective of the client. If the client is configured with { IP address, port } tuples, it has no way to tell if the service offered at one tuple is the same server that is listening on a different tuple. So in this case, the client treats each different tuple as if it references a different service instance.
从客户机的角度识别服务实例。如果客户机配置了{IP地址，端口}元组，则无法判断在一个元组上提供的服务是否是在另一个元组上侦听的同一服务器。因此，在本例中，客户机将每个不同的元组视为引用不同的服务实例。
In some cases, a client is configured with a hostname and a port number. The port number may be given explicitly, along with the hostname. The port number may be omitted, and assumed to have some default value. The hostname and a port number may be learned from the network, as in the case of DNS SRV records. In these cases, the { hostname, port } tuple uniquely identifies the service instance, subject to the usual case-insensitive DNS comparison of names [RFC1034].
在某些情况下，客户端配置有主机名和端口号。端口号可以与主机名一起显式给出。端口号可以省略，并假定有一些默认值。主机名和端口号可以从网络中学习，就像DNS SRV记录一样。在这些情况下，{hostname，port}元组唯一地标识服务实例，遵循通常不区分大小写的DNS名称比较[RFC1034]。
It is possible that two hostnames might point to some common IP addresses; this is a configuration anomaly that the client is not obliged to detect. The effect of this could be that after being told to disconnect, the client might reconnect to the same server because it is represented as a different service instance.
两个主机名可能指向一些公共IP地址；这是一种配置异常，客户端没有义务检测到。这样做的效果可能是，在被告知断开连接后，客户端可能会重新连接到同一服务器，因为它被表示为不同的服务实例。
Implementations SHOULD NOT resolve hostnames and then perform the process of matching IP address(es) in order to evaluate whether two entities should be determined to be the "same service instance".
实现不应解析主机名，然后执行匹配IP地址的过程，以评估是否应将两个实体确定为“同一服务实例”。
When an anycast service is configured on a particular IP address and port, it must be the case that although there is more than one physical server responding on that IP address, each such server can be treated as equivalent. What we mean by "equivalent" here is that both servers can provide the same service and, where appropriate, the same authentication information, such as PKI certificates, when establishing connections.
当在特定IP地址和端口上配置选播服务时，必须是这样的情况：尽管有多个物理服务器在该IP地址上响应，但每个这样的服务器都可以被视为等效的。这里我们所说的“等效”是指，在建立连接时，两台服务器可以提供相同的服务，并在适当的情况下提供相同的身份验证信息，如PKI证书。
If a change in network topology causes packets in a particular TCP connection to be sent to an anycast server instance that does not know about the connection, the new server will automatically terminate the connection with a TCP reset, since it will have no record of the connection, and then the client can reconnect or stop using the connection as appropriate.
如果网络拓扑的更改导致特定TCP连接中的数据包被发送到不知道该连接的选播服务器实例，则新服务器将通过TCP重置自动终止该连接，因为它将没有该连接的记录，然后，客户端可以根据需要重新连接或停止使用连接。
If, after the connection is re-established, the client's assumption that it is connected to the same instance is violated in some way, that would be considered an incorrect behavior in this context. It is, however, out of the possible scope for this specification to make specific recommendations in this regard; that would be up to follow-on documents that describe specific uses of DNS Stateful Operations.
如果在重新建立连接后，客户端认为它连接到同一实例的假设在某种程度上被违反，那么在这种情况下，这将被视为不正确的行为。然而，在这方面提出具体建议超出了本规范的可能范围；这将取决于描述DNS有状态操作的特定用途的后续文档。
As previously specified for DNS-over-TCP [RFC7766]:
正如前面为TCP上的DNS指定的[RFC7766]：
To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one connection for regular queries, one for zone transfers, and one for each protocol that is being used on top of TCP (for example, if the resolver was using TLS). However, it is noted that certain primary/secondary configurations with many busy zones might need to use more than one TCP connection for zone transfers for operational reasons (for example, to support concurrent transfers of multiple zones).
为了降低服务器意外过载的风险，DNS客户端必须注意尽量减少与任何单个服务器的并发TCP连接数。建议对于任何给定的客户机/服务器交互，常规查询的连接不应超过一个，区域传输的连接不应超过一个，TCP上使用的每个协议的连接不应超过一个（例如，如果解析器使用TLS）。但是，需要注意的是，由于操作原因（例如，为了支持多个区域的并发传输），具有许多繁忙区域的某些主/辅助配置可能需要使用多个TCP连接进行区域传输。
A single server may support multiple services, including DNS Updates [RFC2136], DNS Push Notifications [Push], and other services, for one or more DNS zones. When a client discovers that the target server for several different operations is the same service instance (see Section 9.1), the client SHOULD use a single shared DSO Session for all those operations.
单个服务器可以支持多个服务，包括一个或多个DNS区域的DNS更新[RFC2136]、DNS推送通知[Push]和其他服务。当客户端发现多个不同操作的目标服务器是同一服务实例时（参见第9.1节），客户端应为所有这些操作使用单个共享DSO会话。
This requirement has two benefits. First, it reduces unnecessary connection load on the DNS server. Second, it avoids the connection startup time that would be spent establishing each new additional connection to the same DNS server.
这一要求有两个好处。首先，它减少了DNS服务器上不必要的连接负载。第二，它避免了建立到同一DNS服务器的每个新附加连接所需的连接启动时间。
However, server implementers and operators should be aware that connection sharing may not be possible in all cases. A single host device may be home to multiple independent client software instances that don't coordinate with each other. Similarly, multiple independent client devices behind the same NAT gateway will also typically appear to the DNS server as different source ports on the same client IP address. Because of these constraints, a DNS server MUST be prepared to accept multiple connections from different source ports on the same client IP address.
但是，服务器实现者和操作员应该意识到，并非所有情况下都可以进行连接共享。单个主机设备可能是多个相互不协调的独立客户端软件实例的所在地。类似地，同一NAT网关后面的多个独立客户端设备通常也会在DNS服务器上显示为同一客户端IP地址上的不同源端口。由于这些限制，DNS服务器必须准备好接受来自同一客户端IP地址上不同源端口的多个连接。
Where an application-layer middlebox (e.g., a DNS proxy, forwarder, or session multiplexer) is in the path, care must be taken to avoid a configuration in which DSO traffic is mishandled. The simplest way to avoid such problems is to avoid using middleboxes. When this is not possible, middleboxes should be evaluated to make sure that they behave correctly.
当应用层中间盒（例如DNS代理、转发器或会话多路复用器）位于路径中时，必须小心避免DSO通信错误处理的配置。避免此类问题的最简单方法是避免使用中间盒。当这不可能时，应评估中间盒，以确保其行为正确。
Correct behavior for middleboxes consists of one of the following:
中间盒的正确行为包括以下一项：
o The middlebox does not forward DSO messages and responds to DSO messages with a response code other than NOERROR or DSOTYPENI.
o 中间盒不转发DSO消息，而是使用NOERROR或DSOTYPENI以外的响应代码响应DSO消息。
o The middlebox acts as a DSO server and follows this specification in establishing connections.
o 中间盒充当DSO服务器，在建立连接时遵循此规范。
o There is a 1:1 correspondence between incoming and outgoing connections such that when a connection is established to the middlebox, it is guaranteed that exactly one corresponding connection will be established from the middlebox to some DNS resolver, and all incoming messages will be forwarded without modification or reordering. An example of this would be a NAT forwarder or TCP connection optimizer (e.g., for a high-latency connection such as a geosynchronous satellite link).
o 传入和传出连接之间存在1:1的对应关系，因此，当建立到中间盒的连接时，可以保证从中间盒到某个DNS解析程序将建立恰好一个对应的连接，并且所有传入消息将在不进行修改或重新排序的情况下转发。例如，NAT转发器或TCP连接优化器（例如，对于高延迟连接，如地球同步卫星链路）。
Middleboxes that do not meet one of the above criteria are very likely to fail in unexpected and difficult-to-diagnose ways. For example, a DNS load balancer might unbundle DNS messages from the incoming TCP stream and forward each message from the stream to a different DNS server. If such a load balancer is in use, and the DNS servers it points to implement DSO and are configured to enable DSO, DSO Session establishment will succeed, but no coherent session will exist between the client and the server. If such a load balancer is pointed at a DNS server that does not implement DSO or is configured not to allow DSO, no such problem will exist, but such a configuration risks unexpected failure if new server software is installed that does implement DSO.
不符合上述标准之一的中间盒很可能以意外和难以诊断的方式失败。例如，DNS负载平衡器可能将DNS消息从传入的TCP流中分离，并将每个消息从该流转发到不同的DNS服务器。如果使用这样的负载平衡器，并且它指向的DNS服务器实现DSO并配置为启用DSO，则DSO会话建立将成功，但客户端和服务器之间将不存在一致的会话。如果这样的负载平衡器指向未实现DSO或配置为不允许DSO的DNS服务器，则不存在此类问题，但如果安装了实现DSO的新服务器软件，则此类配置可能会出现意外故障。
It is of course possible to implement a middlebox that properly supports DSO. It is even possible to implement one that implements DSO with long-lived operations. This can be done either by maintaining a 1:1 correspondence between incoming and outgoing connections, as mentioned above, or by terminating incoming sessions at the middlebox but maintaining state in the middlebox about any long-lived operations that are requested. Specifying this in detail is beyond the scope of this document.
当然，可以实现一个适当支持DSO的中间盒。甚至可以实现一个使用长寿命操作实现DSO的系统。如上所述，这可以通过在传入和传出连接之间保持1:1的对应关系来实现，也可以通过在中间盒终止传入会话，但在中间盒中保持有关所请求的任何长期操作的状态来实现。详细说明这一点超出了本文件的范围。
Most modern implementations of the Transmission Control Protocol (TCP) include a feature called "Delayed Acknowledgement" [RFC1122].
传输控制协议（TCP）的大多数现代实现包括一个称为“延迟确认”的功能[RFC1122]。
Without this feature, TCP can be very wasteful on the network. For illustration, consider a simple example like remote login using a very simple TCP implementation that lacks delayed acks. When the user types a keystroke, a data packet is sent. When the data packet arrives at the server, the simple TCP implementation sends an immediate acknowledgement. Mere milliseconds later, the server process reads the one byte of keystroke data, and consequently the simple TCP implementation sends an immediate window update. Mere milliseconds later, the server process generates the character echo and sends this data back in reply. The simple TCP implementation then sends this data packet immediately too. In this case, this simple TCP implementation sends a burst of three packets almost instantaneously (ack, window update, data).
如果没有此功能，TCP在网络上可能非常浪费。为了说明，请考虑一个简单的示例，比如使用缺少延迟ACK的非常简单的TCP实现的远程登录。当用户键入击键时，将发送一个数据包。当数据包到达服务器时，简单TCP实现立即发送确认。仅仅几毫秒之后，服务器进程就会读取一个字节的击键数据，因此简单的TCP实现会立即发送一个窗口更新。仅仅几毫秒之后，服务器进程就生成了字符echo并将该数据发送回应答。然后，简单的TCP实现也会立即发送此数据包。在这种情况下，这个简单的TCP实现几乎同时发送三个数据包的突发（ack、窗口更新、数据）。
Clearly it would be more efficient if the TCP implementation were to combine the three separate packets into one, and this is what the delayed ack feature enables.
显然，如果TCP实现将三个单独的数据包合并为一个，那么效率会更高，这就是延迟ack特性所能实现的。
With delayed ack, the TCP implementation waits after receiving a data packet, typically for 200 ms, and then sends its ack if (a) more data packet(s) arrive, (b) the receiving process generates some reply data, or (c) 200 ms elapse without either of the above occurring.
对于延迟的ack，TCP实现在接收到数据分组之后等待，通常为200ms，然后如果（a）更多数据分组到达，（b）接收过程生成一些应答数据，或者（c）200ms后没有发生上述任一情况，则发送其ack。
With delayed ack, remote login becomes much more efficient, generating just one packet instead of three for each character echo.
通过延迟确认，远程登录变得更加高效，每个字符回显只生成一个数据包，而不是三个。
The logic of delayed ack is that the 200 ms delay cannot do any significant harm. If something at the other end were waiting for something, then the receiving process should generate the reply that the thing at the other end is waiting for, and TCP will then immediately send that reply (combined with the ack and window update). And if the receiving process does not in fact generate any reply for this particular message, then by definition the thing at the other end cannot be waiting for anything. Therefore, the 200 ms delay is harmless.
延迟确认的逻辑是200毫秒延迟不会造成任何重大损害。如果另一端的某个东西正在等待某个东西，那么接收过程应该生成另一端的东西正在等待的应答，然后TCP将立即发送该应答（与ack和窗口更新结合）。如果接收过程实际上没有为这个特定的消息生成任何回复，那么根据定义，另一端的东西不能等待任何东西。因此，200毫秒的延迟是无害的。
This assumption may be true unless the sender is using Nagle's algorithm, a similar efficiency feature, created to protect the network from poorly written client software that performs many rapid small writes in succession. Nagle's algorithm allows these small writes to be coalesced into larger, less wasteful packets.
这种假设可能是正确的，除非发送方使用Nagle算法，这是一种类似的效率特性，用于保护网络不受连续执行许多快速小写操作的写得不好的客户端软件的影响。Nagle的算法允许将这些小的写入合并成更大、更少浪费的数据包。
Unfortunately, Nagle's algorithm and delayed ack, two valuable efficiency features, can interact badly with each other when used together [NagleDA].
不幸的是，Nagle算法和延迟ack这两个有价值的效率特性在一起使用时可能会相互影响不良[NagleDA]。
DSO request messages elicit responses; DSO unidirectional messages and DSO response messages do not.
DSO请求消息引发响应；DSO单向消息和DSO响应消息不存在。
For DSO request messages, which do elicit responses, Nagle's algorithm and delayed ack work as intended.
对于确实会引发响应的DSO请求消息，Nagle算法和延迟ack按预期工作。
For DSO messages that do not elicit responses, the delayed ack mechanism causes the ack to be delayed by 200 ms. The 200 ms delay on the ack can in turn cause Nagle's algorithm to prevent the sender from sending any more data for 200 ms until the awaited ack arrives. On an enterprise Gigabit Ethernet (GigE) backbone with sub-millisecond round-trip times, a 200 ms delay is enormous in comparison.
对于不引发响应的DSO消息，延迟的ack机制会导致ack延迟200 ms。ack上的200 ms延迟会反过来导致Nagle算法阻止发送方在等待的ack到达之前发送更多数据200 ms。在往返时间为亚毫秒的企业千兆以太网（GigE）主干上，相比之下，200毫秒的延迟是巨大的。
When this issues is raised, there are two solutions that are often offered, neither of them ideal:
当提出这一问题时，通常会提供两种解决方案，但都不理想：
1. Disable delayed ack. For DSO messages that elicit no response, removing delayed ack avoids the needless 200 ms delay and sends back an immediate ack that tells Nagle's algorithm that it should immediately grant the sender permission to send its next packet. Unfortunately, for DSO messages that *do* elicit a response, removing delayed ack removes the efficiency gains of combining acks with data, and the responder will now send two or three packets instead of one.
1. 禁用延迟确认。对于不引起响应的DSO消息，删除延迟ack可避免不必要的200毫秒延迟，并立即发送回ack，告知Nagle算法它应立即授予发送方发送其下一个数据包的权限。不幸的是，对于*确实*引发响应的DSO消息，删除延迟的ack会降低将ack与数据组合的效率，响应者现在将发送两个或三个数据包，而不是一个。
2. Disable Nagle's algorithm. When acks are delayed by the delayed ack algorithm, removing Nagle's algorithm prevents the sender from being blocked from sending its next small packet immediately. Unfortunately, on a network with a higher round-trip time, removing Nagle's algorithm removes the efficiency gains of combining multiple small packets into fewer larger ones, with the goal of limiting the number of small packets in flight at any one time.
2. 禁用Nagle算法。当延迟ack算法延迟ack时，删除Nagle算法可防止发送方被阻止立即发送下一个小数据包。不幸的是，在往返时间较长的网络上，删除Nagle算法会降低将多个小数据包组合成更小的大数据包的效率，目的是限制在任何时间飞行的小数据包的数量。
The problem here is that with DSO messages that elicit no response, the TCP implementation is stuck waiting, unsure if a response is about to be generated or whether the TCP implementation should go ahead and send an ack and window update.
这里的问题是，对于没有响应的DSO消息，TCP实现被困在等待中，不确定是否将生成响应，或者TCP实现是否应该继续并发送ack和窗口更新。
The solution is networking APIs that allow the receiver to inform the TCP implementation that a received message has been read, processed, and no response for this message will be generated. TCP can then
解决方案是网络API，它允许接收方通知TCP实现接收到的消息已被读取、处理，并且不会生成对此消息的响应。然后，TCP可以
stop waiting for a response that will never come, and immediately go ahead and send an ack and window update.
停止等待永远不会出现的响应，立即发送确认和窗口更新。
For implementations of DSO, disabling delayed ack is NOT RECOMMENDED because of the harm this can do to the network.
对于DSO的实现，不建议禁用延迟ack，因为这会对网络造成危害。
For implementations of DSO, disabling Nagle's algorithm is NOT RECOMMENDED because of the harm this can do to the network.
对于DSO的实现，不建议禁用Nagle算法，因为这会对网络造成危害。
At the time that this document is being prepared for publication, it is known that at least one TCP implementation provides the ability for the recipient of a TCP message to signal that it is not going to send a response, and hence the delayed ack mechanism can stop waiting. Implementations on operating systems where this feature is available SHOULD make use of it.
在准备发布此文档时，已知至少有一个TCP实现为TCP消息的接收者提供了发送不发送响应的信号的能力，因此延迟ack机制可以停止等待。在具有此功能的操作系统上的实现应该使用它。
The IANA has assigned the value 6 for DNS Stateful Operations (DSO) in the "DNS OpCodes" registry.
IANA已为“DNS操作码”注册表中的DNS有状态操作（DSO）分配了值6。
IANA has assigned the value 11 for the DSOTYPENI error code in the "DNS RCODEs" registry. The DSOTYPENI error code ("DSO-TYPE Not Implemented") indicates that the receiver does implement DNS Stateful Operations, but does not implement the specific DSO-TYPE of the Primary TLV in the DSO request message.
IANA已为“DNS RCODEs”注册表中的DSOTYPENI错误代码分配了值11。DSOTYPENI错误代码（“未实现DSO-TYPE”）表示接收器确实实现了DNS有状态操作，但没有实现DSO请求消息中主TLV的特定DSO-TYPE。
The IANA has created the 16-bit "DSO Type Codes" registry, with initial (hexadecimal) values as shown below:
IANA已创建16位“DSO类型代码”注册表，初始值（十六进制）如下所示：
+-----------+-----------------------+-------+-----------+-----------+
| Type | Name | Early | Status | Reference |
| | | Data | | |
+-----------+-----------------------+-------+-----------+-----------+
| 0000 | Reserved | NO | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0001 | KeepAlive | OK | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0002 | RetryDelay | NO | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0003 | EncryptionPadding | NA | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0004-003F | Unassigned, reserved | NO | | |
| | for DSO session- | | | |
| | management TLVs | | | |
| | | | | |
| 0040-F7FF | Unassigned | NO | | |
| | | | | |
| F800-FBFF | Experimental/local | NO | | |
| | use | | | |
| | | | | |
| FC00-FFFF | Reserved for future | NO | | |
| | expansion | | | |
+-----------+-----------------------+-------+-----------+-----------+
+-----------+-----------------------+-------+-----------+-----------+
| Type | Name | Early | Status | Reference |
| | | Data | | |
+-----------+-----------------------+-------+-----------+-----------+
| 0000 | Reserved | NO | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0001 | KeepAlive | OK | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0002 | RetryDelay | NO | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0003 | EncryptionPadding | NA | Standards | RFC 8490 |
| | | | Track | |
| | | | | |
| 0004-003F | Unassigned, reserved | NO | | |
| | for DSO session- | | | |
| | management TLVs | | | |
| | | | | |
| 0040-F7FF | Unassigned | NO | | |
| | | | | |
| F800-FBFF | Experimental/local | NO | | |
| | use | | | |
| | | | | |
| FC00-FFFF | Reserved for future | NO | | |
| | expansion | | | |
+-----------+-----------------------+-------+-----------+-----------+
The meanings of the fields are as follows:
这些字段的含义如下：
Type: The 16-bit DSO type code.
类型：16位DSO类型代码。
Name: The human-readable name of the TLV.
名称：TLV的人类可读名称。
Early Data: If OK, this TLV may be sent as early data in a TLS zero round-trip (Section 2.3 of the TLS 1.3 specification [RFC8446]) initial handshake. If NA, the TLV may appear as an Additional TLV in a DSO message that is sent as early data.
早期数据：如果正常，该TLV可作为TLS零往返（TLS 1.3规范[RFC8446]第2.3节）初始握手中的早期数据发送。如果不适用，TLV可能在作为早期数据发送的DSO消息中显示为附加TLV。
Status: RFC status (e.g., "Standards Track") or "External" if not documented in an RFC.
状态：RFC状态（例如，“标准跟踪”）或“外部”，如果RFC中没有记录。
Reference: A stable reference to the document in which this TLV is defined.
参考：对定义此TLV的文档的稳定参考。
Note: DSO Type Code zero is reserved and is not currently intended for allocation.
注：DSO类型代码0是保留的，当前不用于分配。
Registrations of new DSO Type Codes in the "Reserved for DSO session-management" range 0004-003F and the "Reserved for future expansion" range FC00-FFFF require publication of an IETF Standards Action document [RFC8126].
在“保留用于DSO会话管理”范围0004-003F和“保留用于未来扩展”范围FC00-FFFF中注册新的DSO类型代码需要发布IETF标准行动文件[RFC8126]。
Requests to register additional new DSO Type Codes in the "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert Review [RFC8126]. The expert review should validate that the requested type code is specified in a way that conforms to this specification, and that the intended use for the code would not be addressed with an experimental/local assignment.
在“未分配”范围0040-F7FF中注册其他新DSO类型代码的请求将在专家审查后由IANA记录[RFC8126]。专家评审应验证所要求的类型代码是以符合本规范的方式指定的，并且代码的预期用途不会通过实验/本地分配解决。
DSO Type Codes in the "experimental/local" range F800-FBFF may be used as Experimental Use or Private Use values [RFC8126] and may be used freely for development purposes or for other purposes within a single site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments (since IANA does not record them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of "experimental/local" values to ensure that no conflicts occur within the intended scope of use.
“实验/本地”F800-FBFF范围内的DSO类型代码可作为实验使用或私人使用值[RFC8126]，并可自由用于开发目的或单个站点内的其他目的。未尝试阻止多个站点以不同（且不兼容）的方式使用相同的值。IANA无需审查此类分配（因为IANA不记录它们），而且分配通常对广泛的互操作性没有帮助。现场有责任使用“实验/本地”值，以确保在预期使用范围内不会发生冲突。
Any document defining a new TLV that lists a value of "OK" in the Early Data column must include a threat analysis for the use of the TLV in the case of TLS zero round-trip. See Section 11.1 for details.
在早期数据列中列出“OK”值的任何定义新TLV的文件必须包括TLS零往返情况下使用TLV的威胁分析。详见第11.1节。
If this mechanism is to be used with DNS-over-TLS, then these messages are subject to the same constraints as any other DNS-over-TLS messages and MUST NOT be sent in the clear before the TLS session is established.
如果此机制将与通过TLS的DNS一起使用，则这些消息将受到与任何其他通过TLS的DNS消息相同的约束，并且在建立TLS会话之前不得以明文形式发送。
The data field of the "Encryption Padding" TLV could be used as a covert channel.
“加密填充”TLV的数据字段可用作隐蔽通道。
When designing new DSO TLVs, the potential for data in the TLV to be used as a tracking identifier should be taken into consideration and should be avoided when not required.
在设计新的DSO TLV时，应考虑TLV中的数据用作跟踪标识符的可能性，并且在不需要时应避免。
When used without TLS or similar cryptographic protection, a malicious entity may be able to inject a malicious unidirectional DSO Retry Delay message into the data stream, specifying an unreasonably large RETRY DELAY, causing a denial-of-service attack against the client.
在没有TLS或类似加密保护的情况下使用时，恶意实体可能会将恶意单向DSO重试延迟消息注入数据流，指定不合理的大重试延迟，从而导致针对客户端的拒绝服务攻击。
The establishment of DSO Sessions has an impact on the number of open TCP connections on a DNS server. Additional resources may be used on the server as a result. However, because the server can limit the number of DSO Sessions established and can also close existing DSO Sessions as needed, denial of service or resource exhaustion should not be a concern.
DSO会话的建立会影响DNS服务器上打开的TCP连接数。因此，可能会在服务器上使用其他资源。但是，由于服务器可以限制已建立的DSO会话的数量，也可以根据需要关闭现有的DSO会话，因此拒绝服务或资源耗尽不应引起关注。
DSO permits zero round-trip operation using TCP Fast Open with TLS 1.3 [RFC8446] early data to reduce or eliminate round trips in session establishment. TCP Fast Open is only permitted in combination with TLS 1.3 early data. In the rest of this section, we refer to TLS 1.3 early data in a TLS zero round-trip initial handshake message, regardless of whether or not it is included in a TCP SYN packet with early data using the TCP Fast Open option, as "early data."
DSO允许使用TCP Fast Open和TLS 1.3[RFC8446]早期数据进行零往返操作，以减少或消除会话建立中的往返。TCP Fast Open仅允许与TLS 1.3早期数据结合使用。在本节的其余部分中，我们将TLS零往返初始握手消息中的TLS 1.3早期数据称为“早期数据”，无论它是否包含在使用TCP Fast Open选项的具有早期数据的TCP SYN数据包中
A DSO message may or may not be permitted to be sent as early data. The definition for each TLV that can be used as a Primary TLV is required to state whether or not that TLV is permitted as early data. Only response-requiring messages are ever permitted as early data, and only clients are permitted to send a DSO message as early data unless there is an implicit DSO session (see Section 5.1).
DSO消息可以作为早期数据发送，也可以不作为早期数据发送。需要为每个可用作主要TLV的TLV定义，以说明是否允许该TLV作为早期数据。只有需要消息的响应才允许作为早期数据，并且只有客户端才允许作为早期数据发送DSO消息，除非存在隐式DSO会话（见第5.1节）。
For DSO messages that are permitted as early data, a client MAY include one or more such messages as early data without having to wait for a DSO response to the first DSO request message to confirm successful establishment of a DSO Session.
对于被允许作为早期数据的DSO消息，客户端可以包括一个或多个这样的消息作为早期数据，而不必等待DSO对第一DSO请求消息的响应来确认DSO会话的成功建立。
However, unless there is an implicit DSO session, a client MUST NOT send DSO unidirectional messages until after a DSO Session has been mutually established.
但是，除非存在隐式DSO会话，否则在相互建立DSO会话之前，客户端不得发送DSO单向消息。
Similarly, unless there is an implicit DSO session, a server MUST NOT send DSO request messages until it has received a response-requiring DSO request message from a client and transmitted a successful NOERROR response for that request.
类似地，除非存在隐式DSO会话，否则服务器在从客户端接收到需要DSO请求消息的响应并成功传输该请求的无错误响应之前，不得发送DSO请求消息。
Caution must be taken to ensure that DSO messages sent as early data are idempotent or are otherwise immune to any problems that could result from the inadvertent replay that can occur with zero round-trip operation.
必须谨慎，以确保作为早期数据发送的DSO消息是幂等的，或者不受任何问题的影响，这些问题可能是由于在零往返操作中可能发生的意外重放而导致的。
It would be possible to add a TLV that requires the server to do some significant work and send that to the server as initial data in a TCP SYN packet. A flood of such packets could be used as a DoS attack on the server. None of the TLVs defined here have this property.
可以添加一个TLV，要求服务器执行一些重要的工作，并将其作为TCP SYN数据包中的初始数据发送给服务器。大量此类数据包可能被用作服务器上的DoS攻击。此处定义的TLV均不具有此属性。
If a new TLV is specified that does have this property, that TLV must be specified as not permitted in zero round-trip messages. This prevents work from being done until a round-trip has occurred from the server to the client to verify that the source address of the packet is reachable.
如果指定的新TLV不具有此属性，则必须在零往返消息中将该TLV指定为不允许。这将阻止在从服务器到客户机的往返过程中完成工作，以验证数据包的源地址是否可访问。
Documents that define new TLVs must state whether each new TLV may be sent as early data. Such documents must include a threat analysis in the security considerations section for each TLV defined in the document that may be sent as early data. This threat analysis should be done based on the advice given in Sections 2.3, 8, and Appendix E.5 of the TLS 1.3 specification [RFC8446].
定义新TLV的文档必须说明是否可以将每个新TLV作为早期数据发送。此类文件必须在“安全注意事项”一节中包含对文件中定义的每个TLV（可能作为早期数据发送）的威胁分析。应根据TLS 1.3规范[RFC8446]第2.3节、第8节和附录E.5中给出的建议进行威胁分析。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<https://www.rfc-editor.org/info/rfc1034>.
[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>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<https://www.rfc-editor.org/info/rfc1918>.
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，DOI 10.17487/RFC2136，1997年4月<https://www.rfc-editor.org/info/rfc2136>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS的扩展机制（EDNS（0）），STD 75，RFC 6891，DOI 10.17487/RFC68911913年4月<https://www.rfc-editor.org/info/rfc6891>.
[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>.
[RFC7766]Dickinson，J.，Dickinson，S.，Bellis，R.，Mankin，A.，和D.Wessels，“TCP上的DNS传输-实施要求”，RFC 7766，DOI 10.17487/RFC7766，2016年3月<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>.
[RFC7830]Mayrhofer，A.，“EDNS（0）填充选项”，RFC 7830，DOI 10.17487/RFC7830，2016年5月<https://www.rfc-editor.org/info/rfc7830>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[Fail] Andrews, M. and R. Bellis, "A Common Operational Problem in DNS Servers - Failure To Communicate", Work in Progress, draft-ietf-dnsop-no-response-issue-13, February 2019.
[Fail]Andrews，M.和R.Bellis，“DNS服务器中的一个常见操作问题-通信失败”，正在进行的工作，草稿-ietf-dnsop-no-response-issue-132019年2月。
[NagleDA] Cheshire, S., "TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK", May 2005, <http://www.stuartcheshire.org/papers/nagledelayedack/>.
[NagleDA]Cheshire，S.，“Nagle算法和延迟ACK之间的交互导致的TCP性能问题”，2005年5月<http://www.stuartcheshire.org/papers/nagledelayedack/>.
[Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", Work in Progress, draft-ietf-dnssd-push-18, March 2019.
[Push]Pusateri，T.和S.Cheshire，“DNS推送通知”，正在进行中，草案-ietf-dnssd-Push-1822019年3月。
[Relay] Lemon, T. and S. Cheshire, "Multicast DNS Discovery Relay", Work in Progress, draft-ietf-dnssd-mdns-relay-02, March 2019.
[中继]Lemon，T.和S.Cheshire，“多播DNS发现中继”，正在进行的工作，草稿-ietf-dnssd-mdns-Relay-022019年3月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<https://www.rfc-editor.org/info/rfc1122>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 2132，DOI 10.17487/RFC2132，1997年3月<https://www.rfc-editor.org/info/rfc2132>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.
[RFC5382]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，DOI 10.17487/RFC5382，2008年10月<https://www.rfc-editor.org/info/rfc5382>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<https://www.rfc-editor.org/info/rfc6763>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<https://www.rfc-editor.org/info/rfc7413>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-editor.org/info/rfc7828>.
[RFC7828]Wouters，P.，Abley，J.，Dickinson，S.，和R.Bellis，“edns tcp keepalive EDNS0选项”，RFC 7828，DOI 10.17487/RFC78282016年4月<https://www.rfc-editor.org/info/rfc7828>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[RFC7857]Penno，R.，Perreault，S.，Boucadair，M.，Ed.，Sivakumar，S.，和K.Naito，“网络地址转换（NAT）行为要求的更新”，BCP 127，RFC 7857，DOI 10.17487/RFC7857，2016年4月<https://www.rfc-editor.org/info/rfc7857>.
[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>.
[RFC7858]Hu，Z.，Zhu，L.，Heidemann，J.，Mankin，A.，Wessels，D.，和P.Hoffman，“DNS传输层安全规范（TLS）”，RFC 7858，DOI 10.17487/RFC7858，2016年5月<https://www.rfc-editor.org/info/rfc7858>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[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>.
[RFC8467]Mayrhofer，A.“DNS（EDNS（0））扩展机制的填充策略”，RFC 8467，DOI 10.17487/RFC8467，2018年10月<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>.
[RFC8484]Hoffman，P.和P.McManus，“HTTPS（DoH）上的DNS查询”，RFC 8484，DOI 10.17487/RFC8484，2018年10月<https://www.rfc-editor.org/info/rfc8484>.
Acknowledgements
致谢
Thanks to Stephane Bortzmeyer, Tim Chown, Ralph Droms, Paul Hoffman, Jan Komissar, Edward Lewis, Allison Mankin, Rui Paulo, David Schinazi, Manju Shankar Rao, Bernie Volz, and Bob Harold for their helpful contributions to this document.
感谢Stephane Bortzmeyer、Tim Chown、Ralph Droms、Paul Hoffman、Jan Komissar、Edward Lewis、Allison Mankin、Rui Paulo、David Schinazi、Manju Shankar Rao、Bernie Volz和Bob Harold对本文件的贡献。
Authors' Addresses
作者地址
Ray Bellis Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 United States of America
Ray Bellis Internet Systems Consortium，Inc.美国加利福尼亚州红木市查特街950号，邮编94063
Phone: +1 (650) 423-1200
Email: ray@isc.org
Phone: +1 (650) 423-1200
Email: ray@isc.org
Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, CA 95014 United States of America
斯图尔特柴郡苹果公司，美国加利福尼亚州库珀蒂诺市苹果公园大道一号，邮编95014
Phone: +1 (408) 996-1010
Email: cheshire@apple.com
Phone: +1 (408) 996-1010
Email: cheshire@apple.com
John Dickinson Sinodun Internet Technologies Magadalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
John Dickinson Sinodun Internet Technologies Magadalen中心牛津科技园牛津OX4 4GA英国
Email: jad@sinodun.com
Email: jad@sinodun.com
Sara Dickinson Sinodun Internet Technologies Magadalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
Sara Dickinson Sinodun Internet Technologies Magadalen中心牛津科技园牛津OX4 4GA英国
Email: sara@sinodun.com
Email: sara@sinodun.com
Ted Lemon Nibbhaya Consulting P.O. Box 958 Brattleboro, VT 05302-0958 United States of America
Ted Lemon Nibbhaya Consulting美国VT 05302-0958布拉特波罗958号邮政信箱
Email: mellon@fugue.com
Email: mellon@fugue.com
Tom Pusateri Unaffiliated Raleigh, NC 27608 United States of America
美国北卡罗来纳州罗利市Tom Pusateri非附属公司27608
Phone: +1 (919) 867-1330
Email: pusateri@bangj.com
Phone: +1 (919) 867-1330
Email: pusateri@bangj.com