[要約] RFC 8490は、DNSの状態操作に関する仕様であり、DNSプロトコルの拡張を提案しています。目的は、DNSの状態操作をサポートし、効率的なリソース管理とパフォーマンスの向上を実現することです。
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 OPCODEを定義します。 DSOメッセージは、Type Length Value（TLV）構文を使用して永続的なステートフルセッション内の操作を伝達します。セッションタイムアウト、終了、および暗号化パディングを管理する3つのTLVが定義され、新しいステートフル操作を可能にする拡張機能のフレームワークが定義されています。このドキュメントは、異なるメッセージセマンティクスと新しい結果コードの両方を持つ新しいDNSヘッダーOPCODEを追加することにより、RFC 1035を更新します。このドキュメントは、セッションを再定義し、接続の再利用に関する新しいガイダンスを提供し、セッションのアイドルタイムアウトを処理するための新しいメカニズムを提供することにより、RFC 7766を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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はDNS-over-TCP [RFC1035]を指定しており、DNS-over-TLS [RFC7858]のプロファイルが指定されています。これらのトランスポートは永続的な長期セッションを提供できるため、DNSメッセージのトランスポートにそれらを使用する場合、タイムアウトなど、それらのセッションに関連するパラメーターを確立できるメカニズムがあると便利です。そのような状況では、サーバーが開始したメッセージ（DNSプッシュ通知[プッシュ]など）をサポートすることも有利です。
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）は、少なくとも1つのセッション関連パラメーター（edns-tcp-keepalive EDNS（0）Option [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.
このドキュメントでは、値が6のDNSステートフル操作（DSO）の新しいDNS OPCODEを定義します。DSOメッセージは、タイプ長値（TLV）構文を使用して表される永続的なステートフルセッション内の操作を通信するために使用されます。このドキュメントでは、セッションタイムアウト、終了、および暗号化パディングの管理に使用される3つのTLVの初期セットを定義します。
All three TLVs defined here are mandatory for all implementations of DSO. Further TLVs may be defined in additional specifications.
ここで定義されている3つの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メッセージタイプの定義で指定されます。 MESSAGE IDは、DSO要求メッセージの場合はゼロ以外、DSO単方向メッセージの場合はゼロです。メッセージはパイプライン処理され、複数の要求が同時に処理されている場合、応答が順序正しく表示されない場合があります。
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メッセージ形式とは多少異なります。標準の12バイトのヘッダーが使用されますが、4つのカウントフィールド（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メッセージヘッダーの最後に追加されます。従来のDNS-over-TCP [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形式を認識するように更新されていないパケットアナライザツールを使用して表示すると、DNSメッセージの終了後に、DSOデータが不明な追加データとして表示されます。
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オペレーションや既存のEDNS（0）ベースの機能とのDNSステートフルオペレーションの混乱を完全に回避することです。このアプローチの目標は、特にミドルボックスの動作に関連するEDNS（0）に該当する運用上の問題（EDNS（0）について説明しているセクション、およびファイアウォールとロードバランサーによって引き起こされる問題を参照）を回避することです。失敗[失敗]）。
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.
EDNS（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.
ESO（0）とは対照的に、DSOは常に接続指向のトランスポートプロトコルを使用して動作するため、DSOでは効率上の理由から複数の操作を単一のメッセージにパックする強い動機はありません。各DSO操作は独自のDNSメッセージで通信され、トランスポートプロトコルは、必要に応じて、複数のDNSメッセージを単一のIPパケットにパッキングすることができます。たとえば、TCPは複数の小さなDNSメッセージを単一のTCPセグメントにパックできます。この簡素化により、セマンティクスがより明確になります。各DSO要求メッセージは1つの主要な操作のみを伝達し、対応する応答メッセージの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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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].
接続：双方向バイト（またはメッセージ）ストリーム。バイト（またはメッセージ）は、DNS-over-TCP [RFC1035] [RFC7766]またはDNS-over-TLS [RFC7858]を使用して提供されるなど、確実かつ順序どおりに配信されます。 。
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".)
セッション：このドキュメントの文脈における「セッション」という非限定的な用語は、2つのエンドポイント間の永続的なネットワーク接続を指し、接続の一方の端が他方の端にメッセージを送信できる接続を介してDNSメッセージを交換できるようにします。 （この用語は、OSIの「7層モデル」の「セッション層」とは関係ありません。）
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状態を確認する2つのエンドポイント間で確立されたセッション。これは、DNS-over-TCPの以前の仕様[RFC7766]で説明されているDNS-over-TCPセッションとは異なります。
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.
初期データ：DSOセッションを開始する最初のフライトに関するデータを含むTLS 1.3ハンドシェイク（TLS 1.3仕様のセクション2.3 [RFC8446]）。 TCP Fast Open [RFC7413]は、TLSを使用する場合にのみ許可されます。
DNS message: any DNS message, including DNS queries, responses, updates, DSO messages, etc.
DNSメッセージ：DNSクエリ、応答、更新、DSOメッセージなどのDNSメッセージ
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の場合、プライマリTLVの仕様によって決定されるように、DSO要求メッセージまたはDSO単方向メッセージです。
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-TYPEを持つすべてのTLV。存在する場合、応答プライマリTLVは、応答追加TLVの前に、DSO応答メッセージで最初に出現する必要があります。
Response Additional TLV: any TLVs in a DSO response that follow the (optional) Response Primary TLV(s).
応答追加TLV：（オプションの）応答プライマリTLVに続くDSO応答内のすべての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).
キープアライブタイマー：最新の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).
キープアライブ間隔：クライアントがキープアライブを送信する必要がある前に、キープアライブタイマーが保持できる最大値（セクション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.
1つの使用例では、サーバー定義のタイムアウトなどのセッションパラメータの確立は、永続的な接続の一般的な管理に非常に役立ちます。たとえば、スタブから再帰へのDNS-over-TLS [RFC7858]にDSOセッションを使用すると、edns-tcp-keepalive EDNS（0）オプション[RFC7828]だけを使用してセッションを管理するよりも、クライアントとサーバーの両方で柔軟性が高くなります。 ]。このドキュメントで定義されている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トラフィックがバースト的であることが多いですが、セッションの確立にはコストがかかる可能性があります。長期接続の課題の1つは、NATとファイアウォールの状態を維持するのに十分なトラフィックを維持することです。この問題を軽減するために、このドキュメントでは、DNSの新しい概念であるDSO「キープアライブトラフィック」を紹介します。このトラフィックは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ステートフル操作をサポートするための要件を満たす2つの特定のトランスポートは、DNS-over-TCP [RFC1035] [RFC7766]とDNS-over-TLS [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.
DNS-over-TLSの場合、DNS-over-TCPからDNS-over-TLS中間接続にアップグレードするメカニズムがないことに注意してください（DNS-over-TLS仕様[RFC7858]のセクション7を参照）。接続は、最初からDNS-over-TCP、または最初からDNS-over-TLSのいずれかです。
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-over-HTTP [RFC8484]は使用できません。これは、ここで指定されたメカニズムと互換性がありません。
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.
現在、DNS-over-TCPおよびDNS-over-TLSのみが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を使用せずに再接続してもよい（MAY）。
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要求を送信し、RCODEがNOERROR（0）に設定された対応するDSO応答を受信しました。 DSOセッションが正常に確立されました。クライアントとサーバーの両方がDSOメッセージとDNSメッセージを送信できます。どちらも、受信したメッセージに応答して返信を送信できます（セクション5.2）。非アクティブタイマー（セクション6.4）がアクティブです。キープアライブタイマー（セクション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 described below. This is referred to as explicit DSO Session establishment.
ただし、通常の場合、サーバーはクライアントがDSOをサポートしているかどうかを事前に認識しないため、一般的に、クライアントがDSOをサポートしていることが他の方法で事前に認識されていない限り、サーバーはDSO要求メッセージまたはDSO単方向を開始してはなりません（MUST NOT）以下で説明するように、クライアントが開始した少なくとも1つの成功したDSO要求/応答交換によって、DSOセッションが相互に確立されるまでメッセージ。これは、明示的なDSOセッションの確立と呼ばれます。
Until a DSO Session has been implicitly or explicitly established, a client MUST NOT initiate DSO unidirectional messages.
DSOセッションが暗黙的または明示的に確立されるまで、クライアントはDSO単方向メッセージを開始してはなりません（MUST NOT）。
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キープアライブ要求メッセージ（7.1節）などのDSO要求メッセージを送信し、一致するメッセージIDとRERRORがNOERROR（0）に設定された応答を受信するクライアントによって、接続を介して確立されます。 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.
サーバーが、プライマリTLVが初期データに現れることが許可されていない初期データでDSOメッセージを受信した場合、サーバーは接続を強制的に中止する必要があります。クライアントが初期データでDSOメッセージを受信し、暗黙のDSOセッションがない場合、クライアントは接続を強制的に中止する必要があります。これはTLS接続でのみ適用できます。したがって、TLSを必要としない接続をリッスンする場合、サーバーはTCP Fast Open（TFO）を有効にしてはなりません（MUST NOT）。
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メッセージを発行してはなりません（MUST NOT）。
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 Not Implemented"; RCODE 11）に設定されている場合、これはサーバーがDSOをサポートしているが、このDSO要求メッセージのプライマリTLVのDSO-TYPEを実装していないことを示します。キープアライブTLVの実装は必須であるため、DSOを実装するサーバーは、DSOキープアライブ要求メッセージに対してDSOTYPENIを返してはなりません（MUST NOT）。ただし、将来的に、クライアントが、サーバーが理解できない新しく定義されたDSO-TYPEを使用して、応答が必要なDSO要求メッセージを使用してDSOセッションを確立しようとすると、DSOTYPENI応答が発生します。サーバーがDSOTYPENIを返す場合、DSOセッションは確立されているとは見なされません。ただし、クライアントは、DSOキープアライブなどの他のDSOメッセージを含め、接続でDNSメッセージを送信し続けることが許可されています。これにより、NOERROR応答が成功し、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.
DSO OPCODEを認識しない既存のDNSサーバーがDSOメッセージを受信すると、他に2つの結果が考えられます。サーバーが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秒待機する必要があります（SHOULD）。その後、サーバーは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をサポートしていないものとしてマークし、試行が失敗した後しばらく（少なくとも1時間）DSO接続を試行しないようにする必要があります。クライアントは再接続してもよいが、適切な場合はDSOを使用しない（MAY 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要求メッセージを受信し、その要求に対して正常なNOERROR応答を送信すると、サーバーは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セッションが確立されると、クライアントとサーバーは、DNS-over-TCP [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 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.
DNSステートフル操作をサポートするサーバーは、Keepalive TLV DSO要求メッセージを受信するとRCODE "NOERROR"を返さなければならないため、Keepalive TLVはDSOセッションの確立に使用する理想的な候補です。目的の種類のサーバーに送信したときにのみ成功する他のオプションも、DSOセッションの確立に使用するのに適しています。この基本仕様で定義されたDSO-TYPEのみを実装するクライアントの場合、キープアライブTLVの送信は、DSOセッションを開始するために使用できる唯一のDSO要求メッセージです。他の将来のDSO-TYPEを実装するクライアントであっても、簡単にするために、DSOセッションを開始する方法として常に初期DSOキープアライブ要求メッセージを送信することを選択できます。新しい応答を必要とするDSO-TYPEの将来の定義により、実装者は必要に応じてその新しいDSO-TYPEを使用できるようになりますが、キープアライブ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セッションは「正常に閉じられます」。プロトコルエラーのためにクライアントまたはサーバーが接続を閉じると、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のTIME-WAIT状態の負担をかけるために、その正常なクローズを開始する必要があります。
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.
プロトコルの実装では、ソフトウェア作成者が処理しなければならないエラーには一般に2種類あります。 1つ目は、一時的な接続の切断など、環境の要因によって発生する状況です。これらの状況は望ましくありませんが、ソフトウェアの欠陥を示すものではなく、ソフトウェアが通常回復できるはずの状況です。
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 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".
2つ目は、準拠するDSO実装と通信するときに発生してはならない状況です。それらが発生する場合、それらは、ソフトウェアが回復することを期待することが合理的である以上に、プロトコル実装に重大な欠陥があることを示しています。このドキュメントでは、この後者の形式のエラー状態を「致命的なエラー」として説明し、致命的なエラー状態が発生した実装が「接続をただちに強制的に中止する必要がある」ことを明記しています。
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メッセージは、OPCODEフィールドがDSO OPCODE（6）に設定された標準の12バイトDNSメッセージヘッダー[RFC1035]で始まります。ただし、標準の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 /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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単方向メッセージでは、MESSAGE IDフィールドをゼロに設定する必要があります。 DSO要求メッセージでは、MESSAGE IDフィールドを、イニシエーターが現在この接続で他のアクティブな操作に使用していない一意のゼロ以外の値に設定する必要があります。ここでの目的のために、MESSAGE IDは、イニシエーターがそれをまだ応答を待っているDSO要求メッセージで使用した場合、またはクライアントがそれを使用して長期間の操作をセットアップした場合、このDSOセッションで使用されます。それはまだキャンセルされていません。たとえば、長期間有効な操作は、プッシュ通知サブスクリプション[プッシュ]またはディスカバリリレーインターフェイスサブスクリプション[リレー]です。
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の仕様によってのみ決定されます。プライマリTLVが単方向であることを要求するメッセージにゼロ以外のメッセージIDを含めることで、確認を要求することはできません。また、プライマリTLVに応じてDSO要求メッセージである必要があるメッセージでゼロのメッセージIDを送信することで、確認応答を防ぐこともできません。このような不正なメッセージを受信したレスポンダは、それを致命的なエラーとして扱い、接続をただちに強制的に中止しなければなりません（MUST）。
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フィールドはゼロであってはならず（MUSTAGE ID）、応答されるDSO要求メッセージの（非ゼロ）メッセージIDフィールドの値のコピーを含んでいる必要があります。 MESSAGE IDが0のDSO応答メッセージ（QR = 1）を受信した場合、これは致命的なエラーであり、受信者は接続をただちに強制的に中止する必要があります。
The DNS Header OPCODE field holds the DSO OPCODE value (6).
DNSヘッダーOPCODEフィールドは、DSO OPCODE値（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 specified otherwise, the RCODE is set to zero on transmission, and silently ignored on reception.
DSO要求メッセージ（QR = 0）では、要求の定義に従ってRCODEが設定されます。たとえば、再試行遅延メッセージ（セクション6.6.1）では、RCODEが終了の理由を示します。ただし、ほとんどのDSO要求メッセージ（QR = 0）では、特に明記されていない限り、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 |
+------+-----------+------------------------------------------------+
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.
上記のRCODEの使用は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-TYPEを定義するドキュメントがここで定義されていない応答コードを使用する場合、そのドキュメントは、その新しいDSO TLVのコンテキストでそれらのRCODE値の特定の解釈を指定する必要があります。
The RCODE field is followed by the four zero-valued count fields, followed by the DSO Data.
RCODEフィールドの後に4つのゼロ値カウントフィールドが続き、その後に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.
セクション5.4.4で説明されているように、ゼロ値のカウントフィールドを持つ標準の12バイトDNSメッセージヘッダーの後に、TLV構文を使用して表現されたDSOデータが続きます。
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 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.
DSO要求メッセージまたはDSO単方向メッセージには、少なくとも1つのTLVが含まれている必要があります。 DSO要求メッセージまたはDSO単方向メッセージの最初のTLVは「プライマリTLV」と呼ばれ、DSO要求であるか、DSO単方向操作であるかなど、実行される操作の性質を決定します。場合によっては、DSO暗号化パディングTLV（セクション7.3）など、DSO要求メッセージまたはDSO単方向メッセージに他のTLVを含めることが適切な場合があります。追加の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が含まれていない場合や、通信される情報に適した1つ以上の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-TYPEを持つすべてのTLVは、応答プライマリTLVであり、DSO応答メッセージの最初に出現する必要があります。 DSO応答メッセージには、複数の応答プライマリTLV、または単一の応答プライマリTLVが含まれるか、場合によっては、応答プライマリTLVが含まれないことがあります。応答プライマリTLVは必要ありません。ほとんどのDSO操作では、DNSメッセージヘッダーのMESSAGE 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は、DSO暗号化パディングTLV（セクション7.3）などのResponse Additional TLVです。 Response追加のTLVが存在する場合、Response Primary 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を運ぶことが仕様で要求されている操作に対して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の仕様で、メッセージが単方向であることを示している場合、MESSAGE IDフィールドをゼロに設定し、受信者は、そのDSO単方向メッセージに対応する応答メッセージを生成してはならない（MUST NOT）。
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ビットとMESSAGE IDフィールドの両方がゼロであるDSOメッセージを受信した場合、受信者は応答を生成してはならない（MUST NOT）。たとえば、プライマリTLVのDSO-TYPEが認識されない場合、DSOTYPENIエラーを返してはなりません（MUST NOT）。代わりに、受信者は接続をただちに強制的に中止する必要があります。
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.
たとえば、クライアントがプッシュ通知[プッシュ]をサブスクライブした後、後続のイベント通知は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.
「Primary」、「Additional」、「Response Primary」、または「Response Additional」として使用されているかどうかにかかわらず、すべての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-TYPEは二重目的であり、一部のメッセージではプライマリTLVとして使用でき、その他のメッセージでは追加のTLVとして使用できます。 DSO-TYPEの仕様では、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 /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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ビットの符号なし整数。ネットワーク（ビッグエンディアン）バイトオーダーで、IANAの「DSOタイプコード」レジストリごとに現在の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を解釈せずに不透明な「ブロブ」として扱います。特定のDSO-TYPEに対するDSO-DATAの意味の解釈は、そのDSO-TYPEを実装するソフトウェアの責任です。
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.
認識されないプライマリTLVを含み、非ゼロのメッセージID（応答が予期されることを示す）を含むDSO要求メッセージが受信された場合、受信者は一致するメッセージIDとRCODE DSOTYPENIを含むエラー応答を送信する必要があります。エラー応答には、認識されないプライマリTLVのコピーを含めてはなりません（MUST NOT）。
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.
認識されないプライマリTLVとゼロのMESSAGE ID（応答が予想されないことを示す）の両方を含むDSO単方向メッセージを受信した場合、これは致命的なエラーであり、受信者は接続をただちに強制的に中止する必要があります。
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.
プライマリTLVが認識され、1つ以上の認識されない追加TLVが含まれているDSO要求メッセージまたはDSO単方向メッセージが受信された場合、認識されない追加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.
同様に、1つ以上の認識されない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）オプションを含めることはできません。現在または将来のEDNS（0）オプションによって提供される機能がDSOメッセージに必要な場合、1つ以上の新しい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.
たとえば、セキュリティ目的で使用されるEDNS（0）パディングオプション[RFC7830]はDSOメッセージでは許可されないため、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.
TSIGレコードがメッセージの追加セクションに含まれているため、DSOメッセージに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 *メッセージ*にはEDNS（0）またはTSIGレコードを含めることはできませんが、DSO *セッション*は通常、DSOメッセージやクエリなどの他のDNSメッセージタイプを含む、さまざまな種類のDNSメッセージのシリーズ全体を運ぶために使用されます。 [RFC1034] [RFC1035]およびアップデート[RFC2136]。これらのメッセージは、EDNS（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.
メッセージには必要に応じて他のEDNS（0）オプションが含まれる場合がありますが、この仕様では、DSOセッションで送信される*すべての*メッセージでedns-tcp-keepalive EDNS（0）オプション[RFC7828]を使用することを明示的に禁止しています（ DSOキープアライブ操作によって提供される機能）。 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ビットがゼロに設定され、ゼロ以外のMESSAGE IDフィールドが設定されたすべてのDSOメッセージは、DSO要求メッセージであり、対応する応答を引き出し、DNSヘッダーのQRビットを1に設定し、MESSAGE 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.
MESSAGE IDフィールドがゼロ以外のクライアントから送信された有効なDSO要求メッセージは、サーバーからの応答を引き出します。0以外のメッセージ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ビットとMESSAGE IDフィールドの両方がゼロに設定されているすべてのDSOメッセージは、DSO単方向メッセージであり、応答を引き出してはなりません（MUST NOT）。
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.
DSO要求メッセージなどのTCPを介した双方向交換では、オペレーティングシステムのTCP実装は、アプリケーション層クライアントソフトウェアが対応するDSO応答メッセージを生成するのを待ちます。次に、TCP実装は、TCP確認応答、TCPウィンドウ更新、およびアプリケーション生成のDSO応答メッセージを含む単一の結合パケットを送信できます。これは、DSO要求を含むTCPパケットがすぐに確認応答される場合に発生するように、3つの個別のパケットを送信するよりも効率的です。
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が提供するこのメカニズムを使用して、このメッセージに対する応答がないことを通知する必要があります（SHOULD）。その後、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の名前空間は、各方向で独立しています。これは、クライアントとサーバーの両方が、同じMESSAGE IDを使用して、異なる方向に同時にDSO要求メッセージを送信することはエラーではないことを意味します。この単純化は、プロトコルを実装可能にするために必要です。新しい一意のMESSAGE IDの割り当てに関して、クライアントとサーバーが互いに調整することを要求することは不可能です。また、新しい一意のMESSAGE IDの割り当てに関して、クライアントとサーバーが互いに調整することを要求する必要もありません。イニシエーター（クライアントまたはサーバー）のIDと組み合わせた16ビットのメッセージIDの値は、問題の操作を明確に識別するのに十分です。これは、クライアントからサーバーへのDSO要求メッセージにはメッセージID 0x00001-0x0FFFF、サーバーからクライアントへのDSO要求メッセージには0x10001-0x1FFFFを使用する17ビットのメッセージIDスペースと考えることができます。最下位16ビットはDSOメッセージのMESSAGE 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-TYPEの関連仕様で特に指定されていない限り）。少なくとも、これは、イニシエーターがそのDSOセッションでそのMESSAGE IDを使用して前のDSO要求メッセージへの応答を待っている間、特定のDSOセッションで特定の方向にMESSAGE IDを再利用できないことを意味します（指定されていない限り）。それ以外の場合は、問題のDSO-TYPEの関連する仕様による）、および長期間有効な操作の場合、その操作がアクティブな間は、その操作のメッセージ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.
クライアントまたはサーバーがMESSAGE IDがゼロの応答（QR = 1）を受け取った場合、または未処理の操作のMESSAGE 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.
レスポンダーがMESSAGE IDがゼロではないDSO要求メッセージ（QR = 0）を受信した場合、レスポンダーは要求MESSAGE IDを追跡し、MESSAGE IDは、応答がまだ受信していないDSO要求メッセージのMESSAGE 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セッションを開いたままにすることを選択することができます（MAY）。問題の単一の操作のみに影響するエラー条件の場合、サーバーはクライアントにエラー応答を返し、DSOセッションを開いたままにして、さらに操作を行う必要があります（SHOULD）。
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セッションを終了する必要があります（SHOULD）。
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セッションを自動的に閉じるべきではありません（SHOULD NOT）。 DSOセッションでの1つの特定の操作に関するエラーは、そのDSOセッションでの他のすべての操作も失敗したこと、または将来の操作が失敗することを必ずしも意味しません。クライアントは、サーバーがDSOセッションを終了するかどうかについて、エラー条件がこの特定の操作に関連するのか、それとも後続の操作に関連するのかを決定することに基づいて独自に決定するものと想定します。サーバーがクライアントに再試行遅延メッセージを送信することによってDSOセッションを終了しない場合（セクション6.6.1）、クライアントは後続の操作でそのDSOセッションを引き続き使用する必要があります（SHOULD）。
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単方向メッセージを受信すると、受信者は接続を強制的に中止する必要があります（SHOULD）。 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ステートフルオペレーションの基本仕様であり、それ自体は長期間のオペレーションを定義していませんが、プッシュ通知サブスクリプション[プッシュ]やディスカバリーリレーインターフェイスサブスクリプション[リレー]などの長期間のオペレーションをサポートするためのフレームワークを定義しています。
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.
レスポンダは、このDESC応答メッセージを送信することにより、この選択的なキャンセルを実行します。MESSAGEIDフィールドには、終了する長命の操作（以前にNOERROR RCODEで確認応答していた）のMESSAGE IDと、キャンセルの理由を示す新しいDSO応答メッセージ。
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.
セクション5.1で説明されているように、DSOセッションが開始します。
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.
レスポンダは、メッセージが受信された順序でメッセージを処理する必要があり、メッセージが利用可能になったら、要求メッセージへの応答を返す必要があります。レスポンダは、対応する要求が受信されたのと同じ順序で応答を配信する目的で、応答の送信を遅らせるべきではありません（SHOULD NOT）。
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セッションには、非アクティブタイムアウトとキープアライブ間隔という2つのタイムアウト値が関連付けられています。両方の値は同じ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.
2番目のタイムアウト値であるキープアライブ間隔は、クライアントが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.
2つのタイムアウト値は独立しています。非アクティブタイムアウトは、キープアライブインターバルよりも短い、同じ、または長い場合がありますが、ほとんどの場合、非アクティブタイムアウトはキープアライブインターバルよりも短いと予想されます。
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.
キープアライブ間隔が長い非アクティブタイムアウトが短いと、クライアントに非アクティブなDSOセッションを理由なしに非常に長い間投機的に開いたままにしてはならないことを通知しますが、DSOセッションを開いたままにするアクティブな理由がある場合は必要ありません。そのセッションを維持するために、積極的なレベルのDSOキープアライブトラフィックを送信します。この例は、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.
非アクティブタイムアウトがキープアライブインターバルよりも短い通常のケースでは、十分なトラフィックの残りの量を確保するために、キープアライブインターバルが機能するのは、クライアントが長命で低トラフィックの操作を行った場合のみです。 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キープアライブメッセージ交換が行われていない場合、両方のタイムアウトのデフォルト値は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キープアライブメッセージがリセットされることだけが例外です非アクティブタイムアウトタイマーではなく、キープアライブタイマー。
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ステートフル操作（プッシュ通知サブスクリプション[プッシュ]やディスカバリーリレーインターフェイスサブスクリプション[リレー]など）の場合、操作がアクティブである限り、つまり操作が完了するまで、操作は「進行中」と見なされます。キャンセル。これは、DSOセッションがアクティブな操作で存在し、非アクティブタイムアウトよりもはるかに長い間、どちらの方向にもメッセージが流れないことを意味します。これはエラーではありません。これが、非アクティブタイムアウトとキープアライブインターバルという2つの別個のタイマーがある理由です。 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セッションに対する現在または合理的に予想される将来の必要がないと判断した場合、クライアントはその接続を適切に閉じる必要があります（SHOULD）。
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セッションの存続期間中いつでも、DSOセッションでアクティブな操作が行われずに非アクティブタイムアウト値（デフォルトでは15秒）が経過した場合、クライアントは接続を適切に閉じる必要があります。
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秒か、現在の非アクティブタイムアウト値の2倍のどちらか大きい方です。非アクティブタイムアウトのデフォルト値が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キープアライブメッセージ交換自体は含まれません。 DSOキープアライブメッセージ交換は、キープアライブインターバルタイマーのみをリセットし、非アクティブタイムアウトタイマーはリセットしません。
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セッションをデフォルトの期間より長く開いたままにしたい場合は、7.1で説明したように、DSOキープアライブメッセージを使用してより長いタイムアウト値を要求します。
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秒または2倍のいずれか大きい方になると強制的に中止します。非アクティブタイムアウト値がゼロの場合、これは、クライアントがアイドル状態のクライアントセッションを閉じることに失敗した場合、サーバーは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.
非アクティブタイムアウト0xFFFFFFFFは「無限大」を表し、アイドル接続を開いたままにすることができることをクライアントに通知します。このように無制限のタイムアウトを許可した後、サーバーはいつでも、クライアントに新しいセッションタイムアウト値を指示する新しいDSOキープアライブメッセージを送信することにより、その非アクティブタイムアウトを修正する場合があります。
The largest *finite* inactivity timeout supported by the current Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 days).
現在のキープアライブTLVでサポートされる最大の*有限*非アクティブタイムアウトは0xFFFFFFFE（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.
キープアライブ間隔の目的は、ミドルボックス（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セッションの存続期間中いつでも、DSOセッションでDNSメッセージが送受信されずにキープアライブインターバル値（デフォルトでは15秒）が経過した場合、クライアントはDSOセッションを存続させるためのアクションを実行する必要があります。 DSOキープアライブメッセージを送信する（セクション7.1）。 DSOキープアライブメッセージ交換では、キープアライブタイマーのみがリセットされ、非アクティブタイマーはリセットされません。
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キープアライブトラフィックの受信に失敗した後にこれを認識します。 DSOセッションの存続期間中いつでも、DSOセッションでDNSメッセージが送受信されずにキープアライブ間隔値の2倍（つまり、デフォルトでは30秒）が経過した場合、サーバーはクライアントを延滞と見なし、強制的にSHOULD 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.
キープアライブインターバル値の場合、値が小さいほど、DSOキープアライブトラフィックの量が多くなります。キープアライブ間隔の値を大きくすると、トラフィックとCPUの負荷は軽減されますが、クライアントはDSOのレベルに関係なく、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.
頻繁なDSOキープアライブトラフィックが必要ないため、NATゲートウェイやファイアウォールが介在せず、内部ネットワーク上のクライアントのみにサービスを提供していることがわかっている企業DNSサーバーは、より長いキープアライブインターバルを課すことができます。
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.
パス上にNATゲートウェイが存在する可能性が高い、主に住宅用コンシューマークライアントにサービスを提供しているパブリックDNSサーバーは、より頻繁な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分のキープアライブ間隔を要求し、サーバーが許可することが推奨されています。このキープアライブ間隔は、クライアントがセッションを完全に閉じずに突然切断した場合に、適時にタイムリーに検出できるようにします。また、ミドルボックスが使用する「確立された接続のアイドルタイムアウト」が少なくとも2時間4分であるというIETF推奨のベストカレントプラクティスに従うファイアウォールとNATゲートウェイの状態を維持するのに十分です[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.
キープアライブ間隔の値が短いほど、クライアントとサーバーの負荷が高くなることに注意してください。さらに、トランスポートが再送信するのに必要な時間よりも短いキープアライブ値の場合、単一のパケットが失われると、サーバーは接続を熱心に中止します。たとえば、（仮説的で非現実的な）キープアライブ間隔の値が100ミリ秒の場合、DSOセッションを維持するために、双方向で現在の輻輳制御ウィンドウで許可されている場合、毎秒10メッセージ以上の連続ストリームが発生します。また、この極端な例では、例として100 ms RTTのパスで1回再送信すると、サーバーが接続を中止するのに十分な時間、メッセージストリームに一時的な一時停止が発生します。
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.
この問題のため、サーバーは、キープアライブ間隔の値が10秒未満のDSOキープアライブメッセージ（クライアントが開始したDSO要求に対するDSO応答またはサーバーが開始したDSOメッセージ）を送信してはなりません（MUST NOT）。クライアントが10秒未満のキープアライブインターバル値を指定するDSOキープアライブメッセージを受信した場合、これは致命的なエラーであり、クライアントは直ちに接続を強制的に中止する必要があります。
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.
キープアライブインターバル値0xFFFFFFFFは「無限大」を表し、DSOキープアライブトラフィックを生成しないようにクライアントに通知します。クライアントがこの方法でDSOキープアライブトラフィックを生成しないことを通知した後、サーバーはいつでも、クライアントに新しいセッションタイムアウト値を指示する新しいDSOキープアライブメッセージを送信することにより、DSOキープアライブトラフィック要件を修正できます。
The largest *finite* keepalive interval supported by the current Keepalive TLV is 0xFFFFFFFE (2^32-2 milliseconds, approximately 49.7 days).
現在のキープアライブTLVでサポートされる最大の*有限*キープアライブ間隔は0xFFFFFFFE（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）、サーバーが1つ以上の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 クライアントは、必要なDSOキープアライブトラフィックを生成する、または非アクティブセッションを所定の時間（5秒またはサーバーで指定された時間間隔の2倍のいずれか長い方、6.2項で説明する）までに閉じる義務を果たしません。
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.
したがって、この再接続の急増を回避するために、サーバーは代わりに、DSOセッションを終了する必要がある理由をクライアントに通知する適切なRCODE値を含む再試行遅延メッセージを送信して、クライアントの負荷を減らすことを選択する必要があります。 DSO Retry Delay TLVのフォーマットとさまざまなRCODE値の解釈については、セクション7.2で説明しています。 DSO再試行遅延メッセージを送信した後、サーバーはそのDSOセッションでそれ以上メッセージを送信してはなりません（MUST NOT）。
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秒後に接続を閉じていない場合、サーバーは接続を強制的に中止する必要があります（SHOULD）。
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再試行遅延メッセージは、クライアントによって開始されてはなりません（MUST NOT）。サーバーが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再試行遅延メッセージが送信された後にサーバーに到着します。サーバーはそのような着信要求を黙って無視しなければならず（MUST NOT）、それらに対する応答メッセージを生成してはなりません（MUST NOT）。サーバーからの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再試行遅延メッセージをまとめて送信することにより、再接続遅延はゼロになる場合があり、クライアントが直ちに操作を再確立する必要があることを示します。
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セッションを終了していて（システムが再起動している場合など）、サーバーが同時再試行のフラッドで溢れることを望まない場合は、サーバーに異なる再接続遅延値を送信する必要があります（SHOULD）各クライアント。これらの調整は、ランダム、疑似ランダム、または確定的に選択できます（たとえば、連続するクライアントごとに時間値を1/10秒ずつインクリメントし、再起動後の再接続率を1秒あたり10クライアントにする）。
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セッションを終了できます（MAY）。
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再試行遅延メッセージを送信するか、基になるトランスポート接続を強制的に中止することにより）、クライアントは、そのサービスインスタンスまたは複数の場合は別の適切なサービスインスタンスに再接続する必要があります（SHOULD）。利用可能です。同じサービスインスタンスに再接続する場合、クライアントは、再接続を試みる前に、指定された遅延があればそれを尊重しなければなりません（MUST）。クライアントは遅延をランダム化しようとしてはいけません。この動作が必要な場合、サーバーは各クライアントに送信する再試行遅延値をランダムにジッタします。
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.
サービスインスタンスがクライアントの再接続を望まない場合（おそらくサービスインスタンスが廃止される可能性があります）、再試行遅延を最大値0xFFFFFFFF（2 ^ 32-1ミリ秒、約49.7日）に設定する必要があります（SHOULD）。 49.7日以上離れるようにクライアントに指示することはできません。 49.7日が経過しても、DNSまたはその他の構成情報が、これが特定のサービスの有効なサービスインスタンスであることを依然として示している場合、クライアントは再接続を試みることができます（MAY）。実際には、クライアントが再起動されるか、状態が失われると、DNSまたは他の構成情報がクライアントが使用する必要のあるサービスインスタンスであることを引き続き示している限り、49.7日が経過する前に再接続を試みる可能性があります。
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をサポートしていないものとしてマークする必要があります（SHOULD）。クライアントは再接続してもかまいませんが、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操作を試行してはなりません（SHOULD NOT）。妥当な最小値は1時間です。強制的に中止された接続はソフトウェア障害の結果であるため、問題が最初に発生してから最初の1時間で問題が解決される可能性はほとんどありません。ただし、再試行間隔を1時間に制限することにより、クライアントはサーバーに過度の負担をかけることなく、問題が修正されたときに通知できます。
This section describes the three base TLVs for DNS Stateful Operations: Keepalive, Retry Delay, and Encryption Padding.
このセクションでは、DNSステートフル操作の3つの基本TLVであるキープアライブ、再試行遅延、および暗号化パディングについて説明します。
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.
キープアライブTLV（DSO-TYPE = 1）は2つの機能を実行します。主に、セッションタイムアウトの値を設定します。ちなみに、DSOセッションのキープアライブタイマーもリセットします。つまり、セッションを維持するための「no-op」メッセージの一種として使用できます。クライアントは必要なセッションタイムアウト値を要求し、サーバーはクライアントが使用する必要があることを応答値で確認します。
DSO messages with the Keepalive TLV as the Primary TLV may appear in early data.
プライマリTLVとしてキープアライブTLVを持つDSOメッセージは、初期のデータに表示される場合があります。
The DSO-DATA for the Keepalive 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
INACTIVITY TIMEOUT：現在のDSOセッションの非アクティブタイムアウト。ミリ秒単位のネットワーク（ビッグエンディアン）バイトオーダーで、32ビットの符号なし整数として指定します。これは、クライアントが非アクティブなDSOセッションを閉じ始める必要があるタイムアウトです。非活動タイムアウトは、サーバーが選択した任意の値にすることができます。クライアントが非アクティブなDSOセッションを正常に閉じなかった場合、5秒またはこの間隔の2倍のいずれか長い方が経過すると、サーバーは接続を強制的に中止します。
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.
キープアライブ間隔：現在のDSOセッションのキープアライブ間隔。ミリ秒単位のネットワーク（ビッグエンディアン）バイトオーダーで、32ビットの符号なし整数として指定します。これは、接続状態を維持するためにクライアントがDSOキープアライブトラフィックを生成する必要がある間隔です。キープアライブ間隔は10秒未満であってはなりません。クライアントが必須のDSOキープアライブトラフィックを生成しない場合、この間隔の2倍後にサーバーは接続を強制的に中止します。許可される最小キープアライブ間隔は10秒であるため、必須のDSOキープアライブトラフィックの生成に失敗したためにサーバーがクライアントを強制的に切断する最小時間は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キープアライブメッセージ（つまり、キープアライブTLVが最初のTLVであるメッセージ）の送信または受信は、非アクティブタイマーではなく、キープアライブタイマーのみをリセットします。これは、そのDSOセッションに、そのDSOセッションの存続を保証する現在または最近の非メンテナンスアクティビティがある場合、DSOセッションの存続を唯一の目的として定期的なDSOキープアライブメッセージが送信されるためです。 DSOキープアライブトラフィック自体の送信は、クライアントアクティビティとは見なされません。他のクライアントアクティビティのサービスで実行されるメンテナンスアクティビティと見なされます。 DSOキープアライブトラフィック自体が非アクティブタイマーをリセットする場合、それにより循環ライブロックが作成され、キープアライブトラフィックが無期限に送信されてDSOセッションを存続させます。このシナリオでは、そのDSOセッションでの唯一のアクティビティは、DSOセッションを存続させるキープアライブトラフィックであるため、さらにキープアライブトラフィックを送信できます。 DSOセッションがアクティブであると見なされるには、キープアライブトラフィック以上のものを運ぶ必要があります。これが、DSOキープアライブメッセージの送受信だけでは非アクティブタイマーがリセットされない理由です。
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キープアライブ要求メッセージは、ゼロ以外のメッセージIDを持つDSO要求メッセージとして送信する必要があります。サーバーがMESSAGE IDがゼロのDSOキープアライブメッセージを受信した場合、これは致命的なエラーであり、サーバーは接続を直ちに強制的に中止する必要があります。 DSOキープアライブ要求メッセージは、DSOセッションのキープアライブタイマーをリセットし、同時にクライアントが要求したセッションタイムアウト値をサーバーに通知します。クライアントが開始したDSOキープアライブ要求メッセージに対するサーバーの応答では、セッションタイムアウトには、サーバーがこの時点からDSOセッションで転送するサーバーの選択した値が含まれます。これは、クライアントがDHCPオプション51 [RFC2132]を使用して特定のリースライフタイムを要求するDHCPプロトコルをモデルにしていますが、実際に付与されるリースライフタイムを決定する最終的な権限はサーバーです。
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.
クライアントが2番目以降のDSOキープアライブ要求メッセージをサーバーに送信するとき、クライアントは毎回その優先値を要求し続ける必要があります（SHOULD）。これにより柔軟性が得られ、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 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セッションが進行中の場合（セクション5.1）、DSOキープアライブメッセージがサーバーによって開始される場合があります。サーバーから送信される場合、DSOキープアライブメッセージは、MESSAGE IDがゼロに設定されたDSO単方向メッセージとして送信される必要があります。クライアントは、サーバーが開始したDSOキープアライブメッセージへの応答を生成してはなりません（MUST NOT）。クライアントがゼロ以外のメッセージIDを持つDSOキープアライブ要求メッセージを受信した場合、これは致命的なエラーであり、クライアントは接続をただちに強制的に中止する必要があります。サーバーからのDSOキープアライブ単方向メッセージは、DSOセッションのキープアライブタイマーをリセットすると同時に、この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キープアライブ応答メッセージでは、キープアライブTLVのインスタンスが1つだけ存在しなければならず、クライアントからのDSOキープアライブ要求メッセージへの応答として送信される応答プライマリTLVとしてのみ使用されます。キープアライブTLVは、応答追加TLVとして他の応答に追加してはなりません（MUST NOT）。サーバーがクライアントからのDSOキープアライブ要求メッセージへの応答以外の方法でクライアントのセッションタイムアウト値を更新する場合は、上記のように、サーバーが独自のDSOキープアライブ単一方向メッセージを送信することによって更新します。
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セッションでキープアライブTLVを使用する必要はありません。多くのDSO操作が長期間のセッション状態と組み合わせて使用されますが、すべてのDSO操作が長期間のセッション状態を必要とするわけではなく、場合によっては、非アクティブタイムアウトとキープアライブ間隔の両方のデフォルトの15秒値が完全である可能性があります適切な。ただし、このドキュメントで定義されているDSO-TYPEのみを実装するクライアントの場合、DSOキープアライブ要求メッセージがクライアントが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キープアライブ要求メッセージへの応答を受信したとき、またはサーバーが開始したDSOキープアライブ単方向メッセージを受信したとき、クライアントはサーバーによって指示されたセッションタイムアウト値を受信しています。サーバーからのキープアライブTLVに含まれる2つのタイムアウト値はそれぞれ、クライアントが以前にこの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.
キープアライブタイマーの場合、受信した値の処理は簡単です。 DSOキープアライブTLV自体を含むメッセージを受信すると、キープアライブタイマーがリセットされ、DSOセッションのキープアライブ間隔が更新されます。新しいキープアライブ間隔は、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 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セッションでの有効なアクティビティなしで許容される最大許容時間を示しています。キープアライブTLVを含むメッセージを受信すること自体は、非アクティブタイマーをリセットしません。このDSOセッションでの最後の有効なアクティビティからの経過時間は、DSOキープアライブメッセージの交換による影響を受けません。受信メッセージのキープアライブ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 現在の非アクティブタイマーの値がすでに新しい非アクティブタイムアウトの2倍を超えている場合、クライアントはすぐに滞納と見なされ（このDSOセッションはサーバーによって強制的に強制終了される資格があります）、クライアントはすぐにこのDSOセッションを閉じ始める必要があります。ただし、サーバーがこのようにして非アクティブタイムアウトを急激に減らした場合、サーバーが強制的に接続を中止する前にクライアントに接続を適切に閉じる時間を与えるために、サーバーは5秒または新しい非アクティブタイムアウトの4分の1のいずれか大きい方。
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.
キープアライブTLV（DSO-TYPE = 1）の非アクティブタイムアウト値は、edns-tcp-keepalive EDNS（0）オプション[RFC7828]と同様の意図を持っています。 DSOセッションが確立された後、DSOをサポートするクライアント/サーバーのペアは、メッセージ内でedns-tcp-keepalive EDNS（0）オプションを使用してはなりません（MUST NOT）。セッションを確立するためにDSOメッセージを送信したクライアントは、この時点からedns-tcp-keepalive EDNS（0）オプションを送信してはなりません（MUST NOT）。 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
RETRY DELAY：ネットワーク（ビッグエンディアン）バイトオーダーで32ビットの符号なし整数としてミリ秒単位で指定された時間値。この範囲内では、イニシエーターはこの操作を再試行してはならないか、このサーバーへの接続を再試行してはなりません。 RETRY DELAY値の推奨事項は、セクション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は、終了の主な理由を示す必要があります（SHOULD）。
o NOERROR indicates a routine shutdown or restart.
o NOERRORは、通常のシャットダウンまたは再起動を示します。
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 REFUSEDは、サーバーが再構成されていることを示します。現時点では、このDSOセッションで以前に実行されていた長期間のクライアント操作を1つ以上実行できなくなりました。
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セッションで以前に実行されていた長期間のクライアント操作を1つ以上実行できないことを示します。たとえば、DNSプッシュ通知サーバーを再構成して、現在サブスクライブしている名前の1つ以上に対する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 Retry DelayメッセージのこれらのRCODE値のみを指定しています。 DSO Retry Delayメッセージを送信するサーバーは、これらの値のいずれかを使用する必要があります（SHOULD）。ただし、将来の状況により、DSO再試行遅延メッセージで他のRCODE値が適切である状況が発生する可能性があるため、クライアントは、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 Retry Delay単一方向メッセージをクライアントに送信するときに、サーバーがセッションを終了しようとする理由が複数ある場合があります。おそらく、構成が変更された可能性があり、ポリシー（REFUSED）が原因で長期間のクライアント操作を続行できなくなり、サーバーが権限を失ったため、他の長期間のクライアント操作を実行できなくなった可能性があります。名前（NOTAUTH）。そのような場合、サーバーは適切なRCODE値、またはRCODE = NOERROR（ルーチンのシャットダウンまたは再起動）のいずれかを使用できます（MAY）。
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.
RSO値は通常、切断の性質に関する将来の人間による分析のためのログファイルへの書き込みなどの情報目的にのみ使用されるため、DSO再試行遅延メッセージのRCODE値の選択は重要ではありません。通常、クライアントはRCODE値に応じて動作を変更しません。メッセージ内のRETRY DELAYは、このサービスインスタンスへの新しい接続を試行する前に待機する必要がある時間をクライアントに通知します。
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 Retry Delayメッセージをサーバーに送信してはなりません（MUST NOT）。サーバーがプライマリTLVが再試行遅延TLVであるDSOメッセージを受信した場合、これは致命的なエラーであり、サーバーは直ちに接続を強制的に中止する必要があります。
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を応答に追加して、イニシエータがこの操作を再試行してはならない時間間隔を示してもよい（MAY）。
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を追加してもよい（MAY）。
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-LENGTHが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 /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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]で指定されているように、PADDINGバイトは0x00に設定する必要があります（SHOULD）。たとえば、パディングされたメッセージが暗号化の前に圧縮される可能性がある場合は、他の値を使用できます。受信したメッセージでは、任意の値のPADDINGバイトを受け入れる必要があります。
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.
Encryption Padding TLVは、DSO要求メッセージ、応答、またはその両方に含めることができます。 EDNS（0）パディングオプション[RFC7830]で指定されているように、DSO要求メッセージが暗号化パディングTLVで受信された場合、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であり、MESSAGE 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で、MESSAGE 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 |
+--------+------------------------------+------------------------+
The table below indicates, for each of the three TLVs defined in this document, whether they are valid in each of ten different contexts.
次の表は、このドキュメントで定義されている3つのTLVのそれぞれについて、それらが10の異なるコンテキストのそれぞれで有効かどうかを示しています。
The first five contexts are DSO requests or DSO unidirectional messages from client to server, and the corresponding responses from server back to client:
最初の5つのコンテキストは、クライアントからサーバーへの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-クライアントからサーバーにDSO要求メッセージで送信されるプライマリTLV。この要求が応答メッセージを生成する必要があることを示すゼロ以外のメッセージ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-クライアントからサーバーへのDSO単方向メッセージで送信されるプライマリTLV。メッセージIDが0であり、このリクエストが応答メッセージを生成してはならないことを示します。
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を持つクライアント「CP」要求への応答）。応答TLVのDSO-TYPEはDSO-TYPEと一致します。要求内のプライマリTLVの。
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を持つクライアント「CP」要求への応答）、応答TLVのDSO-TYPEがDSOと一致しない-リクエストのプライマリTLVの-TYPE。
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.
2番目の5つのコンテキストは、反対方向の対応するものです。サーバーからクライアントへの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-DSO要求メッセージでサーバーからクライアントに送信されるプライマリTLV。この要求が応答メッセージを生成する必要があることを示すゼロ以外のメッセージ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が0であり、このリクエストが応答メッセージを生成してはならないことを示します。
o S-A - Additional TLV, optionally added to a DSO request message or DSO unidirectional message from server to client.
o S-A-サーバーからクライアントへのDSO要求メッセージまたはDSO単方向メッセージにオプションで追加される追加のTLV。
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を持つサーバー「SP」要求への応答）。応答TLVのDSO-TYPEはDSO-TYPEと一致します。要求内のプライマリTLVの。
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-Response TLVのDSO-TYPEがDSOと一致しない場合、サーバーに送り返される応答メッセージに含まれる（応答が必要であることを示すゼロ以外のMESSAGE IDを持つサーバー「SP」要求への応答） -リクエストのプライマリTLVの-TYPE。
+-------------------------+-------------------------+
| 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.
2つのホスト名がいくつかの一般的な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".
実装では、2つのエンティティが「同じサービスインスタンス」であると判断する必要があるかどうかを評価するために、ホスト名を解決してからIPアドレスのマッチングプロセスを実行するべきではありません（SHOULD NOT）。
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]:
以前DNS-over-TCP [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の上で使用されている各プロトコルごとに1つずつの接続が存在する必要がある（SHOULD）ことが推奨されます（たとえば、リゾルバーが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.
単一のサーバーは、1つ以上のDNSゾーンに対して、DNSアップデート[RFC2136]、DNSプッシュ通知[プッシュ]、およびその他のサービスを含む複数のサービスをサポートする場合があります。クライアントが複数の異なる操作のターゲットサーバーが同じサービスインスタンスであることを発見した場合（セクション9.1を参照）、クライアントはそれらすべての操作に対して単一の共有DSOセッションを使用する必要があります（SHOULD）。
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.
この要件には2つの利点があります。まず、DNSサーバーの不要な接続負荷を軽減します。第2に、同じ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ゲートウェイの背後にある複数の独立したクライアントデバイスも、通常、同じクライアントIPアドレスの異なるソースポートとしてDNSサーバーに表示されます。これらの制約のため、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 ミドルボックスへの接続が確立されると、ミドルボックスから一部のDNSリゾルバーへの対応する接続が1つだけ確立されることが保証され、すべての受信メッセージが転送されることなく、着信接続と送信接続が1：1で対応します。変更または並べ替え。これの例は、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ロードバランサーは、着信TCPストリームからのDNSメッセージをアンバンドルし、各メッセージをストリームから別の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].
Transmission Control Protocol（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実装が即座に確認応答を送信します。ほんの数ミリ秒後、サーバープロセスは1バイトのキーストロークデータを読み取り、その結果、単純なTCP実装がウィンドウの更新を即座に送信します。数ミリ秒後、サーバープロセスは文字エコーを生成し、このデータを返信します。単純なTCP実装は、このデータパケットもすぐに送信します。この場合、この単純なTCP実装は、3つのパケットのバーストをほぼ瞬時に送信します（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実装が3つの別々のパケットを1つに結合する場合はより効率的であり、これが遅延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実装はデータパケットの受信後、通常200ミリ秒待機し、（a）より多くのデータパケットが到着した場合、（b）受信プロセスが応答データを生成した場合、または（c ）上記のいずれも発生せずに200ミリ秒が経過した。
With delayed ack, remote login becomes much more efficient, generating just one packet instead of three for each character echo.
遅延ackにより、リモートログインははるかに効率的になり、各文字エコーに対して3つのパケットではなく1つのパケットのみを生成します。
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.
遅延ackのロジックは、200ミリ秒の遅延が重大な害を及ぼすことはないということです。相手側の何かが何かを待っていた場合、受信プロセスは相手側のものが待っているという応答を生成し、TCPはすぐにその応答を送信します（ackとウィンドウの更新と組み合わせて）。そして、受信プロセスが実際にこの特定のメッセージに対する応答を生成しない場合、定義により、反対側にあるものは何も待つことができません。したがって、200 msの遅延は無害です。
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].
残念ながら、2つの貴重な効率機能である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ミリ秒遅れます。 ACKの200ミリ秒の遅延により、Nagleのアルゴリズムは、待機中のACKが到着するまで、送信者が200ミリ秒以上データを送信できないようにする可能性があります。ミリ秒未満のラウンドトリップ時間を備えたエンタープライズギガビットイーサネット（GigE）バックボーンでは、200ミリ秒の遅延が比較すると非常に大きくなります。
When this issues is raised, there are two solutions that are often offered, neither of them ideal:
この問題が発生した場合、しばしば提供される2つのソリューションがあり、どちらも理想的ではありません。
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ミリ秒の遅延が回避され、送信者に次のパケットの送信をすぐに許可するようNagleのアルゴリズムに通知する即時ackが返されます。残念ながら、応答を引き出す* SO * DSOメッセージの場合、遅延ackを削除すると、ackとデータを組み合わせる効率が向上し、レスポンダは1つではなく2つまたは3つのパケットを送信します。
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 stop waiting for a response that will never come, and immediately go ahead and send an ack and window update.
解決策は、受信したメッセージが読み取られて処理され、このメッセージに対する応答が生成されないことを受信者がTCP実装に通知できるようにするネットワークAPIです。その後、TCPは、決して来ない応答の待機を停止し、すぐに先に進み、確認応答とウィンドウの更新を送信します。
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.
このドキュメントの公開準備中、少なくとも1つのTCP実装により、TCPメッセージの受信者が応答を送信しないことを通知する機能が提供されることがわかっているため、遅延ackメカニズムにより、待ってはいけません。この機能を利用できるオペレーティングシステムでの実装は、それを利用する必要があります。
The IANA has assigned the value 6 for DNS Stateful Operations (DSO) in the "DNS OpCodes" registry.
IANAは、「DNS OpCodes」レジストリの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 Not Implemented」）は、レシーバーが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進数）値を使用して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 | | | |
+-----------+-----------------------+-------+-----------+-----------+
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.
初期データ：OKの場合、このTLVはTLSゼロラウンドトリップ（TLS 1.3仕様[RFC8446]のセクション2.3）の初期ハンドシェイクで初期データとして送信される場合があります。 NAの場合、TLVは、初期データとして送信されるDSOメッセージで追加のTLVとして表示される場合があります。
Status: RFC status (e.g., "Standards Track") or "External" if not documented in an RFC.
ステータス：RFCステータス（例： "Standards Track"）またはRFCに記載されていない場合は "External"。
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タイプコードを登録する要求は、エキスパートレビュー[RFC8126]の後にIANAによって記録されます。専門家によるレビューでは、要求されたタイプコードがこの仕様に準拠した方法で指定されていること、およびコードの使用目的が実験的/ローカルな割り当てでは扱われないことを検証する必要があります。
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.
Early Data列に「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.
このメカニズムがDNS-over-TLSで使用される場合、これらのメッセージは他のDNS-over-TLSメッセージと同じ制約の対象となり、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 Retry Delayメッセージをデータストリームに挿入し、不当に大きなRETRY DELAYを指定して、クライアントに対してサービス拒否攻撃を引き起こす可能性があります。
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は、TLS 1.3 [RFC8446]初期データを使用したTCP Fast Openを使用したゼロラウンドトリップ操作を許可し、セッション確立におけるラウンドトリップを削減または排除します。 TCP Fast Openは、TLS 1.3初期データとの組み合わせでのみ許可されます。このセクションの残りの部分では、TCP Fast Openオプションを使用して初期データを含むTCP SYNパケットに含まれているかどうかに関係なく、TLSゼロラウンドトリップ初期ハンドシェイクメッセージのTLS 1.3初期データを「初期データ。」
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セッションがない限り（セクション5.1を参照）、クライアントのみが初期データとしてDSOメッセージを送信できます。
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応答を待つ必要なしに、早期データとして1つ以上のそのようなメッセージを含めることができます。
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単方向メッセージを送信してはなりません（MUST NOT）。
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要求メッセージを受信し、その要求に対して正常なNOERROR応答を送信するまで、DSO要求メッセージを送信してはなりません（MUST NOT）。
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 UPDATE）」、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 / RFC6891、2013年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、「DNS Transport over TCP-実装要件」、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。、「The EDNS（0）Padding Option」、RFC 7830、DOI 10.17487 / RFC7830、May 2016、<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]コットン、M。、レイバ、B。、およびT.ナルテン、「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.
[失敗] Andrews、M。、およびR. Bellis、「DNSサーバーの一般的な運用上の問題-通信の失敗」、作業中、draft-ietf-dnsop-no-response-issue-13、2019年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.
[プッシュ]プサテリ、T.、S。チェシャー、「DNSプッシュ通知」、作業中、draft-ietf-dnssd-push-18、2019年3月。
[Relay] Lemon, T. and S. Cheshire, "Multicast DNS Discovery Relay", Work in Progress, draft-ietf-dnssd-mdns-relay-02, March 2019.
[リレー]レモン、T.、S。チェシャー、「マルチキャストDNSディスカバリリレー」、作業中、draft-ietf-dnssd-mdns-relay-02、2019年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。、編、「インターネットホストの要件-通信層」、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。、編、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. Krochmal、「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 Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年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、「The edns-tcp-keepalive EDNS0 Option」、RFC 7828、DOI 10.17487 / RFC7828、2016年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.、and K. Naito、 "Updates to Network Address Translation（NAT）Behavioral Requirements"、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 over Transport Layer Security（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。、「The Transport Layer Security（TLS）Protocol Version 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 Charter Street Redwood City、CA 94063アメリカ合衆国
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 John Dickinson Sinodun Internet Technologies Magadalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
電話：+1（408）996-1010メール：cheshire@apple.com John Dickinson Sinodun Internet Technologies Magadalen Center Oxford Science Park Oxford OX4 4GA United Kingdom
Email: jad@sinodun.com
Sara Dickinson Sinodun Internet Technologies Magadalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
さら ぢｃきんそん しのづん いんてｒねｔ てｃｈのぉぎえｓ まがだぇん せんｔれ おｘふぉｒｄ Ｓしえんせ ぱｒｋ おｘふぉｒｄ おＸ４ ４が うにてｄ きんｇどｍ
Email: sara@sinodun.com
Ted Lemon Nibbhaya Consulting P.O. Box 958 Brattleboro, VT 05302-0958 United States of America
テッドレモンニッバヤコンサルティングP.O. Box 958 Brattleboro、VT 05302-0958アメリカ合衆国
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