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
        
1. Introduction
1. 介绍

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指示该操作的成功或失败。

2. Requirements Language
2. 需求语言

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]所述进行解释。

3. Terminology
3. 术语

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.

清除计时器:将计时器值设置为零,但不重新启动计时器。

4. Applicability
4. 适用性

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会话的传输。

4.1. Use Cases
4.1. 用例

Several use cases for DNS Stateful Operations are described below.

DNS有状态操作的几个用例如下所述。

4.1.1. Session Management
4.1.1. 会话管理

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足以大大增强此用例的连接管理。

4.1.2. Long-Lived Subscriptions
4.1.2. 长期订阅

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意义上的“活动”,但它用于维护中间盒中的状态,并确保客户端和服务器彼此仍然具有连接。

4.2. Applicable Transports
4.2. 适用运输

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有状态操作。如果其他运输工具满足本节第一段中规定的要求,则可在将来添加这些运输工具。

5. Protocol Details
5. 协议详情

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节)。

5.1. DSO Session Establishment
5.1. DSO会话建立

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)。

5.1.1. DSO Session Establishment Failure
5.1.1. DSO会话建立失败

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节)。

5.1.2. DSO Session Establishment Success
5.1.2. DSO会话建立成功

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消息,因此客户机或服务器都可以是消息的发起方。

5.2. Operations after DSO Session Establishment
5.2. 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会话的有效方式这一事实。

5.3. DSO Session Termination
5.3. 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选项设置为零来实现的。

5.3.1. Handling Protocol Errors
5.3.1. 处理协议错误

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".

将后一种形式的错误条件描述为“致命错误”,并指定遇到致命错误条件的实现“必须立即强制中止连接”。

5.4. Message Format
5.4. 消息格式

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                            /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
        
5.4.1. DNS Header Fields in DSO Messages
5.4.1. DSO消息中的DNS头字段

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数据。

5.4.2. DSO Data
5.4.2. 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的实例超过指定数量,则这是一个致命错误,缺陷响应消息的收件人必须立即强制中止连接。

5.4.3. DSO Unidirectional Messages
5.4.3. DSO单向消息

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数据包。

5.4.4. TLV Syntax
5.4.4. TLV语法

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类型的软件的责任。

5.4.5. Unrecognized TLVs
5.4.5. 未识别的TLV

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响应消息,则必须无声地忽略未识别