[要約] RFC 7828は、EDNS0オプションであるedns-tcp-keepaliveについての要約と目的を提供しています。このオプションは、TCP接続の維持を目的としており、ネットワークの信頼性とパフォーマンスを向上させることを目指しています。
Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 7828 Red Hat
Category: Standards Track J. Abley
ISSN: 2070-1721 Dyn, Inc.
S. Dickinson
Sinodun
R. Bellis
ISC
April 2016
The edns-tcp-keepalive EDNS0 Option
edns-tcp-keepalive EDNS0オプション
Abstract
概要
DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.
クライアントとサーバー間のDNSメッセージは、UDPまたはTCPを介して受信されます。 UDPトランスポートでは、ビジー状態のサーバーでの状態の保持が少なくなりますが、TCPでの切り捨てと再試行が発生する可能性があります。さらに、UDPはリフレクション攻撃に悪用される可能性があります。 TCPを使用すると、再送信と増幅が減少します。ただし、クライアントは通常、再試行にのみTCPを使用し、サーバーは通常、秒単位のアイドルタイムアウトを使用します。
This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.
このドキュメントでは、DNSサーバーが可変アイドルタイムアウトを通知できるようにするEDNS0オプション（ "edns-tcp-keepalive"）を定義しています。このシグナリングは、DNSトランザクション時間への影響を最小限に抑えて、TCPトランスポートに関連付けられた状態を効果的に管理できるようにすることで、長寿命のTCP接続の使用を促進します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7828.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7828で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5
3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5
3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6
3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6
3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6
3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6
3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7
3.5. Non-clean Paths . . . . . . . . . . . . . . . . . . . . . 8
3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8
4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
DNS messages between clients and servers may be received over either UDP or TCP [RFC1035]. Historically, DNS clients used APIs that only facilitated sending and receiving a single query over either UDP or TCP. New APIs and deployment of DNSSEC validating resolvers on hosts that in the past were using stub resolving only is increasing the DNS client base that prefer using long-lived TCP connections. Long-lived TCP connections can result in lower request latency than the case where UDP transport is used and truncated responses are received. This is because clients that retry over TCP following a truncated UDP response typically only use the TCP session for a single (request, response) pair, continuing with UDP transport for subsequent queries.
クライアントとサーバー間のDNSメッセージは、UDPまたはTCP [RFC1035]のいずれかで受信される場合があります。歴史的に、DNSクライアントは、UDPまたはTCPを介した単一のクエリの送受信のみを容易にするAPIを使用していました。新しいAPIと、以前はスタブ解決のみを使用していたホストでのDNSSEC検証リゾルバーの展開により、存続期間の長いTCP接続の使用を好むDNSクライアントベースが増加しています。存続期間の長いTCP接続では、UDPトランスポートが使用され、切り捨てられた応答が受信される場合よりも、要求の待ち時間が短くなる可能性があります。これは、切り捨てられたUDP応答に続いてTCPで再試行するクライアントは、通常、単一の（要求、応答）ペアに対してのみTCPセッションを使用し、後続のクエリではUDPトランスポートを続行するためです。
The use of TCP transport requires state to be retained on DNS servers. If a server is to perform adequately with a significant query load received over TCP, it must manage its available resources to ensure that all established TCP sessions are well-used, and idle connections are closed after an appropriate amount of time.
TCPトランスポートを使用するには、DNSサーバーで状態を保持する必要があります。サーバーがTCP経由で受信した大量のクエリ負荷で適切に実行する場合、確立されたすべてのTCPセッションが適切に使用され、適切な時間が経過するとアイドル接続が閉じられるように、利用可能なリソースを管理する必要があります。
UDP transport is stateless, and hence presents a much lower resource burden on a busy DNS server than TCP. An exchange of DNS messages over UDP can also be completed in a single round trip between communicating hosts, resulting in optimally short transaction times. UDP transport is not without its risks, however.
UDPトランスポートはステートレスであるため、TCPよりもビジーなDNSサーバーのリソース負荷がはるかに低くなります。 UDPを介したDNSメッセージの交換は、通信ホスト間の1回の往復で完了することもできるため、トランザクション時間が最適化されます。ただし、UDPトランスポートにはリスクがないわけではありません。
A single-datagram exchange over UDP between two hosts can be exploited to enable a reflection attack on a third party. Response Rate Limiting [RRL] is designed to help mitigate such attacks against authoritative-only servers. One feature of RRL is to let some amount of responses "slip" through the rate limiter. These are returned with the TC (truncation) bit set, which causes legitimate clients to resend the same query using TCP transport.
2つのホスト間でUDPを介した単一のデータグラム交換を悪用して、サードパーティへのリフレクション攻撃を可能にすることができます。応答速度制限[RRL]は、権限のあるサーバーのみに対するこのような攻撃を軽減するように設計されています。 RRLの1つの機能は、一定の量の応答をレートリミッターを介して「スリップ」させることです。これらはTC（切り捨て）ビットセットで返されます。これにより、正当なクライアントがTCPトランスポートを使用して同じクエリを再送信します。
[RFC1035] specified a maximum DNS message size over UDP transport of 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols subsequently increased the observed frequency at which responses exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than 512 bytes to be exchanged over UDP, with a corresponding increased incidence of fragmentation. Fragmentation is known to be problematic in general, and has also been implicated in increasing the risk of cache poisoning attacks [fragmentation-considered-poisonous].
[RFC1035]は、UDPトランスポート上の512バイトの最大DNSメッセージサイズを指定しました。 DNSSEC [RFC4033]およびその他のプロトコルの導入により、応答がこの制限を超える頻度が増加しました。 EDNS0 [RFC6891]を使用すると、512バイトを超えるDNSメッセージをUDP経由で交換でき、それに対応して断片化の発生率が高くなります。フラグメンテーションは一般に問題があることが知られており、キャッシュポイズニング攻撃のリスクの増加にも関与しています[fragmentation-considered-poisonous]。
TCP transport is less susceptible to the risks of fragmentation and reflection attacks. However, TCP transport for DNS as currently deployed has expensive setup overhead, compared to using UDP (when no retry is required).
TCPトランスポートは、フラグメンテーション攻撃やリフレクション攻撃のリスクをあまり受けません。ただし、現在展開されているDNSのTCPトランスポートは、UDPを使用する場合（再試行が不要な場合）に比べて、設定にオーバーヘッドがかかります。
The overhead of the three-way TCP handshake for a single DNS transaction is substantial, increasing the transaction time for a single (request, response) pair of DNS messages from 1x RTT to 2x RTT. There is no such overhead for a session that is already established; therefore, the overhead of the initial TCP handshake is minimised when the resulting session is used to exchange multiple DNS message pairs over a single session. The extra RTT time for session setup can be represented as the equation (1 + N)/N, where N represents the number of DNS message pairs that utilize the session and the result approaches unity as N increases.
単一のDNSトランザクションに対する3方向のTCPハンドシェイクのオーバーヘッドは非常に大きく、DNSメッセージの単一の（要求、応答）ペアのトランザクション時間が1x RTTから2x RTTに増加します。すでに確立されているセッションには、そのようなオーバーヘッドはありません。したがって、最初のTCPハンドシェイクのオーバーヘッドは、結果のセッションを使用して単一のセッションで複数のDNSメッセージのペアを交換するときに最小限に抑えられます。セッションセットアップの追加のRTT時間は、式（1 + N）/ Nで表すことができます。ここで、Nはセッションを利用するDNSメッセージペアの数を表し、Nが増加するにつれて結果は1に近づきます。
With increased deployment of DNSSEC and new RR types containing application-specific cryptographic material, there is an increase in the prevalence of truncated responses received over UDP with retries over TCP. The overhead for a DNS transaction over UDP truncated due to RRL is 3x RTT higher than the overhead imposed on the same transaction initiated over TCP.
DNSSECとアプリケーション固有の暗号素材を含む新しいRRタイプの導入が増えると、UDPを介して受信される切り捨てられた応答がTCPを介して再試行される頻度が増加します。 RRLにより切り捨てられたUDPを介したDNSトランザクションのオーバーヘッドは、TCPを介して開始された同じトランザクションに課されるオーバーヘッドよりも3倍のRTT高くなります。
This document proposes a signalling mechanism between DNS clients and servers that encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.
このドキュメントでは、DNSトランザクション時間への影響を最小限に抑えてTCPトランスポートに関連付けられた状態を効果的に管理できるようにすることで、長寿命のTCP接続の使用を促進するDNSクライアントとサーバー間のシグナリングメカニズムを提案します。
This mechanism will be of benefit for both stub-resolver and resolver-authoritative TCP connections. In the latter case, the persistent nature of the TCP connection can provide improved defence against attacks including DDoS.
このメカニズムは、スタブリゾルバーとリゾルバー権限のあるTCP接続の両方に役立ちます。後者の場合、TCP接続の永続的な性質により、DDoSを含む攻撃に対する防御が向上します。
The reduced overhead of this extension adds up significantly when combined with other EDNS0 extensions, such as [CHAIN-QUERY] and [DNS-over-TLS]. For example, the combination of these EDNS0 extensions make it possible for hosts on high-latency mobile networks to natively and efficiently perform DNSSEC validation and encrypt queries.
この拡張のオーバーヘッドの削減は、[CHAIN-QUERY]や[DNS-over-TLS]などの他のEDNS0拡張と組み合わせると大幅に増加します。たとえば、これらのEDNS0拡張の組み合わせにより、高遅延モバイルネットワーク上のホストがDNSSEC検証をネイティブかつ効率的に実行し、クエリを暗号化することが可能になります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document specifies a new EDNS0 [RFC6891] option, edns-tcp-keepalive, which can be used by DNS clients and servers to signal a willingness to keep an idle TCP session open to conduct future DNS transactions, with the idle timeout being specified by the server. This specification does not distinguish between different types of DNS client and server in the use of this option.
このドキュメントは、新しいEDNS0 [RFC6891]オプション、edns-tcp-keepaliveを指定します。これは、DNSクライアントとサーバーが使用して、アイドルTCPセッションを開いたままにして将来のDNSトランザクションを実行する意欲を示すことができ、アイドルタイムアウトはサーバー。この仕様では、このオプションを使用する際のDNSクライアントとサーバーのタイプを区別しません。
[RFC7766] defines an 'idle DNS-over-TCP session' from both the client and server perspective. The idle timeout described here begins when the idle condition is met per that definition and should be reset when that condition is lifted, i.e., when a client sends a message or when a server receives a message on an idle connection.
[RFC7766]は、クライアントとサーバーの両方の観点から「アイドルDNS-over-TCPセッション」を定義します。ここで説明するアイドルタイムアウトは、その定義に従ってアイドル条件が満たされたときに始まり、その条件が解除されたとき、つまりクライアントがメッセージを送信したとき、またはサーバーがアイドル接続でメッセージを受信したときにリセットする必要があります。
The edns-tcp-keepalive option is encoded as follows:
edns-tcp-keepaliveオプションは次のようにエンコードされます。
1 2 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
+-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+
| TIMEOUT !
+-------------------------------+
where:
ただし：
OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, 11
OPTION-CODE：edns-tcp-keepaliveに割り当てられたEDNS0オプションコード、11
OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2 if it is present;
OPTION-LENGTH：TIMEOUTが省略されている場合は値0、存在する場合は値2。
TIMEOUT: an idle timeout value for the TCP connection, specified in units of 100 milliseconds, encoded in network byte order.
TIMEOUT：TCP接続のアイドルタイムアウト値。100ミリ秒単位で指定され、ネットワークバイトオーダーでエンコードされます。
DNS clients MUST NOT include the edns-tcp-keepalive option in queries sent using UDP transport.
DNSクライアントは、UDPトランスポートを使用して送信されるクエリにedns-tcp-keepaliveオプションを含めてはなりません（MUST NOT）。
DNS clients MAY include the edns-tcp-keepalive option in the first query sent to a server using TCP transport to signal their desire to keep the connection open when idle.
DNSクライアントは、TCPトランスポートを使用してサーバーに送信される最初のクエリにedns-tcp-keepaliveオプションを含めて、アイドル時に接続を開いたままにしておくことを示すことができます（MAY）。
DNS clients MAY include the edns-tcp-keepalive option in subsequent queries sent to a server using TCP transport to signal their continued desire to keep the connection open when idle.
DNSクライアントは、TCPトランスポートを使用してサーバーに送信される後続のクエリにedns-tcp-keepaliveオプションを含めて、アイドル時に接続を開いたままにしておくことを継続的に要求する場合があります。
Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT value.
クライアントはOPTION-LENGTHに0を指定し、TIMEOUT値を省略しなければなりません。
A DNS client that receives a response using UDP transport that includes the edns-tcp-keepalive option MUST ignore the option.
edns-tcp-keepaliveオプションを含むUDPトランスポートを使用して応答を受信するDNSクライアントは、オプションを無視する必要があります。
A DNS client that receives a response using TCP transport that includes the edns-tcp-keepalive option MAY keep the existing TCP session open when it is idle. It SHOULD honour the timeout received in that response (overriding any previous timeout) and initiate close of the connection before the timeout expires.
edns-tcp-keepaliveオプションを含むTCPトランスポートを使用して応答を受信するDNSクライアントは、アイドル状態のときに既存のTCPセッションを開いたままにすることができます（MAY）。その応答で受信したタイムアウトを尊重し（以前のタイムアウトを上書きし）、タイムアウトになる前に接続のクローズを開始する必要があります（SHOULD）。
A DNS client that receives a response that includes the edns-tcp-keepalive option with a TIMEOUT value of 0 SHOULD send no more queries on that connection and initiate closing the connection as soon as it has received all outstanding responses.
edns-tcp-keepaliveオプションを含み、TIMEOUT値が0の応答を受信するDNSクライアントは、その接続に対してこれ以上クエリを送信せず、未処理の応答をすべて受信するとすぐに接続のクローズを開始する必要があります（SHOULD）。
A DNS client that sent a query containing the edns-keepalive-option but receives a response that does not contain the edns-keepalive-option SHOULD assume the server does not support keepalive and behave following the guidance in [RFC7766]. This holds true even if a previous edns-keepalive-option exchange occurred on the existing TCP connection.
edns-keepalive-optionを含むクエリを送信したが、edns-keepalive-optionを含まない応答を受信したDNSクライアントは、サーバーがキープアライブをサポートしておらず、[RFC7766]のガイダンスに従って動作すると想定する必要があります。これは、以前のedns-keepalive-option交換が既存のTCP接続で発生した場合でも当てはまります。
A DNS server that receives a query using UDP transport that includes the edns-tcp-keepalive option MUST ignore the option.
edns-tcp-keepaliveオプションを含むUDPトランスポートを使用してクエリを受信するDNSサーバーは、オプションを無視する必要があります。
A DNS server that receives a query using TCP transport that includes the edns-tcp-keepalive option MAY modify the local idle timeout associated with that TCP session if resources permit.
edns-tcp-keepaliveオプションを含むTCPトランスポートを使用してクエリを受信するDNSサーバーは、リソースが許可する場合、そのTCPセッションに関連付けられているローカルアイドルタイムアウトを変更できます（MAY）。
A DNS server that receives a query sent using TCP transport that includes an OPT RR (with or without the edns-tcp-keepalive option) MAY include the edns-tcp-keepalive option in the response to signal the expected idle timeout on a connection. Servers MUST specify the TIMEOUT value that is currently associated with the TCP session. It is reasonable for this value to change according to local resource constraints. The DNS server SHOULD send an edns-tcp-keepalive option with a timeout of 0 if it deems its local resources are too low to service more TCP keepalive sessions or if it wants clients to close currently open connections.
OPT RR（edns-tcp-keepaliveオプションの有無にかかわらず）を含むTCPトランスポートを使用して送信されたクエリを受信するDNSサーバーは、接続で予期されるアイドルタイムアウトを通知する応答にedns-tcp-keepaliveオプションを含めることができます（MAY）。サーバーは、現在TCPセッションに関連付けられているTIMEOUT値を指定する必要があります。この値は、ローカルリソースの制約に従って変更するのが妥当です。 DNSサーバーは、ローカルリソースが低すぎてより多くのTCPキープアライブセッションを処理できないと見なした場合、またはクライアントが現在開いている接続を閉じたい場合に、タイムアウトが0のedns-tcp-keepaliveオプションを送信する必要があります（SHOULD）。
Both DNS clients and servers are subject to resource constraints that will limit the extent to which TCP sessions can persist. Effective limits for the number of active sessions that can be maintained on individual clients and servers should be established, either as configuration options or by interrogation of process limits imposed by the operating system. Servers that implement edns-tcp-keepalive should also engage in TCP connection management by recycling existing connections when appropriate, closing connections gracefully, and managing request queues to enable fair use.
DNSクライアントとサーバーはどちらも、TCPセッションが持続できる範囲を制限するリソースの制約を受けます。個々のクライアントおよびサーバーで維持できるアクティブなセッション数の有効な制限は、構成オプションとして、またはオペレーティングシステムによって課されるプロセス制限の問い合わせによって確立する必要があります。 edns-tcp-keepaliveを実装するサーバーは、適切な場合に既存の接続をリサイクルし、接続を適切に閉じ、要求キューを管理してフェアユースを可能にすることにより、TCP接続管理にも関与する必要があります。
In the event that there is greater demand for TCP sessions than can be accommodated, servers may reduce the TIMEOUT value signalled in successive DNS messages to minimise idle time on existing sessions. This also allows, for example, clients with other candidate servers to query to establish new TCP sessions with different servers in expectation that an existing session is likely to be closed or to fall back to UDP.
対処できるよりも多くのTCPセッションの需要がある場合、サーバーは、連続するDNSメッセージで通知されるTIMEOUT値を減らして、既存のセッションのアイドル時間を最小限に抑えることがあります。これにより、たとえば、他の候補サーバーを持つクライアントは、既存のセッションが閉じられるかUDPにフォールバックする可能性があることを想定して、異なるサーバーとの新しいTCPセッションを確立するためにクエリを実行できます。
Based on TCP session resources, servers may signal a TIMEOUT value of 0 to request clients to close connections as soon as possible. This is useful when server resources become very low or a denial-of-service attack is detected and further maximises the shifting of TIME_WAIT state to well-behaved clients.
TCPセッションリソースに基づいて、サーバーはTIMEOUT値0を通知して、クライアントにできるだけ早く接続を閉じるように要求できます。これは、サーバーリソースが非常に少なくなった場合、またはサービス拒否攻撃が検出され、正常に動作するクライアントへのTIME_WAIT状態の移行をさらに最大化する場合に役立ちます。
However, it should be noted that RFC 6891 states:
ただし、RFC 6891には次のように記載されていることに注意してください。
Lack of presence of an OPT record in a request MUST be taken as an indication that the requestor does not implement any part of this specification and that the responder MUST NOT include an OPT record in its response.
リクエストにOPTレコードが存在しないことは、リクエスタがこの仕様のどの部分も実装していないこと、およびレスポンダがその応答にOPTレコードを含めてはならないことを示していると見なす必要があります。
Since servers must be faithful to this specification even on a persistent TCP connection, it means that (following the initial exchange of timeouts) a server may not be presented with the opportunity to signal a change in the idle timeout associated with a connection if the client does not send any further requests containing EDNS0 OPT RRs. This limitation makes persistent connection handling via an initial idle timeout signal more attractive than a mechanism that establishes default persistence and then uses a connection close signal (in a similar manner to HTTP 1.1 [RFC7230]).
サーバーは永続的なTCP接続でもこの仕様に忠実でなければならないため、（タイムアウトの最初の交換に続いて）クライアントが接続に関連付けられたアイドルタイムアウトの変更を通知する機会がサーバーに提供されない可能性がありますEDNS0 OPT RRを含むそれ以上の要求を送信しません。この制限により、初期アイドルタイムアウト信号による永続的な接続処理が、デフォルトの永続性を確立し、接続クローズ信号を使用するメカニズム（HTTP 1.1 [RFC7230]と同様の方法）よりも魅力的になります。
If a client includes the edns-tcp-keepalive option in the first query, it SHOULD include an EDNS0 OPT RR periodically in any further messages it sends during the TCP session. This will increase the chance of the client being notified should the server modify the timeout associated with a session. The algorithm for choosing when to do this is out of scope of this document and is left up to the implementor and/or operator.
クライアントが最初のクエリにedns-tcp-keepaliveオプションを含める場合、TCPセッション中に送信する追加のメッセージにEDNS0 OPT RRを定期的に含める必要があります（SHOULD）。これにより、サーバーがセッションに関連付けられたタイムアウトを変更した場合に、クライアントに通知される可能性が高くなります。これをいつ行うかを選択するためのアルゴリズムは、このドキュメントの範囲外であり、実装者やオペレーターに任されています。
DNS clients and servers MAY close a TCP session at any time in order to manage local resource constraints. The algorithm by which clients and servers rank active TCP sessions in order to determine which to close is not specified in this document.
DNSクライアントとサーバーは、ローカルリソースの制約を管理するために、いつでもTCPセッションを閉じることができます。このドキュメントでは、どちらを閉じるかを決定するためにクライアントとサーバーがアクティブなTCPセッションをランク付けするアルゴリズムは指定されていません。
Many paths between DNS clients and servers suffer from poor hygiene, limiting the free flow of DNS messages that include particular EDNS0 options or messages that exceed a particular size. A fallback strategy similar to that described in [RFC6891], Section 6.2.2 SHOULD be employed to avoid persistent interference due to non-clean paths.
DNSクライアントとサーバー間の多くのパスは、特定のEDNS0オプションまたは特定のサイズを超えるメッセージを含むDNSメッセージの自由な流れを制限する、衛生状態の悪さに悩まされています。 [RFC6891]のセクション6.2.2で説明されているものと同様のフォールバック戦略を採用して、クリーンでないパスによる永続的な干渉を回避する必要があります。
DNS servers of various types are commonly deployed using anycast [RFC4786].
さまざまなタイプのDNSサーバーは、一般的にエニーキャスト[RFC4786]を使用して配備されます。
Changes in network topology between clients and anycast servers may cause disruption to TCP sessions making use of edns-tcp-keepalive more often than with TCP sessions that omit it, since the TCP sessions are expected to be longer lived. It might be possible for anycast servers to avoid disruption due to topology changes by making use of TCP multipath [RFC6824] to anchor the server side of the TCP connection to an unambiguously unicast address.
クライアントとエニーキャストサーバー間のネットワークトポロジが変化すると、TCPセッションの寿命が長くなることが予想されるため、edns-tcp-keepaliveを使用しないTCPセッションよりも、TCPセッションが中断する可能性があります。エニーキャストサーバーは、TCPマルチパス[RFC6824]を使用してTCP接続のサーバー側を明確にユニキャストアドレスに固定することにより、トポロジの変更による中断を回避できる場合があります。
It is RECOMMENDED that DNS intermediaries that terminate TCP connections implement edns-tcp-keepalive. An intermediary that does not implement edns-tcp-keepalive but sits between a client and server that both support edns-tcp-keepalive might close idle connections unnecessarily.
TCP接続を終了するDNS仲介者がedns-tcp-keepaliveを実装することをお勧めします。 edns-tcp-keepaliveを実装していないが、両方がedns-tcp-keepaliveをサポートするクライアントとサーバーの間にある仲介者は、アイドル接続を不必要に閉じる可能性があります。
The edns-tcp-keepalive option can potentially be abused to request large numbers of long-lived sessions in a quick burst. When a DNS server detects abusive behaviour, it SHOULD immediately close the TCP connection and free the resources used.
edns-tcp-keepaliveオプションは、悪用されて、短時間のバーストで多数の長期間セッションを要求する可能性があります。 DNSサーバーが不正な動作を検出すると、すぐにTCP接続を閉じて、使用していたリソースを解放する必要があります（SHOULD）。
Servers could choose to monitor client behaviour with respect to the edns-tcp-keepalive option to build up profiles of clients that do not honour the specified timeout.
サーバーは、指定されたタイムアウトを守らないクライアントのプロファイルを構築するために、edns-tcp-keepaliveオプションに関してクライアントの動作を監視することを選択できます。
Readers are advised to familiarise themselves with the security considerations outlined in [RFC7766]
読者は、[RFC7766]で概説されているセキュリティの考慮事項に精通することをお勧めします
IANA has assigned an EDNS0 option code for the edns-tcp-keepalive option from the "DNS EDNS0 Option Codes (OPT)" registry as follows:
IANAは、次のように「DNS EDNS0オプションコード（OPT）」レジストリからedns-tcp-keepaliveオプションのEDNS0オプションコードを割り当てました。
+-------+--------------------+----------+-----------+
| Value | Name | Status | Reference |
+-------+--------------------+----------+-----------+
| 11 | edns-tcp-keepalive | Standard | RFC 7828 |
+-------+--------------------+----------+-----------+
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、DOI 10.17487 / RFC4786、2006年12月、<http://www.rfc-editor.org/info/rfc4786> 。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://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月、<http：// www.rfc-editor.org/info/rfc6891>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[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, <http://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月、< http://www.rfc-editor.org/info/rfc7766>。
[CHAIN-QUERY] Wouters, P., "Chain Query requests in DNS", Work in Progress, draft-ietf-dnsop-edns-chain-query-07, February 2016.
[CHAIN-QUERY] Wouters、P。、「DNSのチェーンクエリリクエスト」、Work in Progress、draft-ietf-dnsop-edns-chain-query-07、2016年2月。
[DNS-over-TLS] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over TLS", Work in Progress, draft-ietf-dprive-dns-over-tls-09, March 2016.
[DNS-over-TLS] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「TLS over DNSの仕様」、作業中、ドラフト-ietf-dprive-dns-over-tls-09、2016年3月。
[fragmentation-considered-poisonous] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", arXiv: 1205.4011, May 2012, <http://arxiv.org/abs/1205.4011>.
[fragmentation-considered-poisonous] Herzberg、A。およびH. Shulman、「フラグメンテーションは有毒と見なされた」、arXiv：1205.4011、2012年5月、<http://arxiv.org/abs/1205.4011>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<http：// www.rfc-editor.org/info/rfc6824>。
[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012, <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
[RRL] Vixie、P。およびV. Schryver、「DNS Response Rate Limiting（DNS RRL）」、ISC-TN 2012-1-Draft1、2012年4月、<https://ftp.isc.org/isc/pubs/ tn / isc-tn-2012-1.txt>。
Acknowledgements
謝辞
The authors acknowledge the contributions of Jinmei TATUYA and Mark Andrews. Thanks to Duane Wessels for detailed review and the many others who contributed to the mailing list discussion.
著者は、JINMEI TATUYAとMark Andrewsの貢献に感謝します。詳細なレビューをしてくれたDuane Wesselsと、メーリングリストのディスカッションに貢献してくれた他の多くの人に感謝します。
Authors' Addresses
著者のアドレス
Paul Wouters Red Hat
ポール・ウーターズレッドハット
Email: pwouters@redhat.com
Joe Abley Dyn, Inc. 103-186 Albert Street London, ON N6A 1M1 Canada
Joe Abley Dyn、Inc.103-186 Albert Street London、ON N6A 1M1 Canada
Phone: +1 519 670 9327
Email: jabley@dyn.com
Sara Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
さら ぢｃきんそん しのづん いんてｒねｔ てｃｈのぉぎえｓ まｇだぇん せんｔれ おｘふぉｒｄ Ｓしえんせ ぱｒｋ おｘふぉｒｄ おＸ４ ４が うにてｄ きんｇどｍ
Email: sara@sinodun.com
URI: http://sinodun.com
Ray Bellis Internet Systems Consortium, Inc 950 Charter Street Redwood City, CA 94063 United States
Ray Bellis Internet Systems Consortium、Inc 950 Charter Street Redwood City、CA 94063アメリカ合衆国
Phone: +1 650 423 1200
Email: ray@isc.org
URI: http://www.isc.org