[要約] RFC 7766は、DNSトランスポートをTCP上で実装するための要件を定義している。目的は、DNSの信頼性とパフォーマンスを向上させるために、TCPを使用したDNSトランスポートの実装を促進することである。
Internet Engineering Task Force (IETF) J. Dickinson
Request for Comments: 7766 S. Dickinson
Obsoletes: 5966 Sinodun
Updates: 1035, 1123 R. Bellis
Category: Standards Track ISC
ISSN: 2070-1721 A. Mankin
D. Wessels
Verisign Labs
March 2016
DNS Transport over TCP - Implementation Requirements
DNSトランスポートover TCP-実装要件
Abstract
概要
This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.
このドキュメントでは、DNS実装のトランスポートプロトコルとしてTCPをサポートするための要件を指定し、DNS-over-UDPと同等のDNS-over-TCPパフォーマンスに関するガイドラインを提供します。このドキュメントはRFC 5966を廃止したため、RFC 1035およびRFC 1123を更新します。
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/rfc7766.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7766で入手できます。
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 Terminology . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Transport Protocol Selection . . . . . . . . . . . . . . . . 5
6. Connection Handling . . . . . . . . . . . . . . . . . . . . . 6
6.1. Current Practices . . . . . . . . . . . . . . . . . . . . 6
6.1.1. Clients . . . . . . . . . . . . . . . . . . . . . . . 7
6.1.2. Servers . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. Connection Reuse . . . . . . . . . . . . . . . . . . 8
6.2.1.1. Query Pipelining . . . . . . . . . . . . . . . . 8
6.2.2. Concurrent Connections . . . . . . . . . . . . . . . 9
6.2.3. Idle Timeouts . . . . . . . . . . . . . . . . . . . . 9
6.2.4. Teardown . . . . . . . . . . . . . . . . . . . . . . 10
7. Response Reordering . . . . . . . . . . . . . . . . . . . . . 10
8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 11
9. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Summary of Advantages and Disadvantages to Using TCP
for DNS . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Changes to RFC 5966 . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Most DNS [RFC1034] transactions take place over UDP [RFC768]. TCP [RFC793] is always used for full zone transfers (using AXFR) and is often used for messages whose sizes exceed the DNS protocol's original 512-byte limit. The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP. The need for increased TCP use has also been driven by the protection it provides against address spoofing and therefore exploitation of DNS in reflection/amplification attacks. It is now widely used in Response Rate Limiting [RRL1] [RRL2]. Additionally, recent work on DNS privacy solutions such as [DNS-over-TLS] is another motivation to revisit DNS-over-TCP requirements.
ほとんどのDNS [RFC1034]トランザクションはUDP [RFC768]を介して行われます。 TCP [RFC793]は常にフルゾーン転送（AXFRを使用）に使用され、サイズがDNSプロトコルの元の512バイト制限を超えるメッセージによく使用されます。 DNSセキュリティ（DNSSEC）とIPv6の展開の増加により、応答サイズが増加し、そのためTCPの使用が増加しています。 TCPの使用を増やす必要性は、アドレスのなりすましに対する保護、したがってリフレクション/増幅攻撃でのDNSの悪用によるものです。現在では、Response Rate Limiting [RRL1] [RRL2]で広く使用されています。さらに、[DNS-over-TLS]などのDNSプライバシーソリューションに関する最近の取り組みは、DNS-over-TCP要件を再検討するもう1つの動機です。
Section 6.1.3.2 of [RFC1123] states:
[RFC1123]のセクション6.1.3.2には、次のように記載されています。
DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries.
DNSリゾルバと再帰サーバーは、（ゾーン転送ではない）クエリを送信するために、UDPをサポートする必要があり、TCPをサポートする必要があります（SHOULD）。
However, some implementors have taken the text quoted above to mean that TCP support is an optional feature of the DNS protocol.
ただし、一部の実装者は、上記のテキストを使用して、TCPサポートがDNSプロトコルのオプション機能であることを意味しています。
The majority of DNS server operators already support TCP, and the default configuration for most software implementations is to support TCP. The primary audience for this document is those implementors whose limited support for TCP restricts interoperability and hinders deployment of new DNS features.
ほとんどのDNSサーバーオペレーターは既にTCPをサポートしており、ほとんどのソフトウェア実装のデフォルト構成はTCPをサポートすることです。このドキュメントの主な対象読者は、TCPの限定的なサポートが相互運用性を制限し、新しいDNS機能の展開を妨げる実装者です。
This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation.
したがって、このドキュメントでは、コアDNSプロトコルの仕様を更新して、TCPのサポートが完全なDNSプロトコル実装の必須部分となるようにします。
There are several advantages and disadvantages to the increased use of TCP (see Appendix A) as well as implementation details that need to be considered. This document addresses these issues and presents TCP as a valid transport alternative for DNS. It extends the content of [RFC5966], with additional considerations and lessons learned from research, developments, and implementation of TCP in DNS and in other Internet protocols.
考慮が必要な実装の詳細だけでなく、TCPの使用の増加（付録Aを参照）にはいくつかの長所と短所があります。このドキュメントでは、これらの問題に対処し、TCPをDNSの有効な代替トランスポートとして提示します。 [RFC5966]の内容を拡張し、DNSや他のインターネットプロトコルでのTCPの研究、開発、実装から学んだ追加の考慮事項と教訓を備えています。
Whilst this document makes no specific requirements for operators of DNS servers to meet, it does offer some suggestions to operators to help ensure that support for TCP on their servers and network is optimal. It should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) will probably result in resolution failure and/or application-level timeouts.
このドキュメントでは、DNSサーバーのオペレーターが満たす必要のある特定の要件はありませんが、サーバーとネットワークでのTCPのサポートが最適であることを確認するのに役立ついくつかの提案をオペレーターに提供しています。 TCP（またはネットワーク層でのDNS over TCPのブロック）のサポートに失敗すると、解決の失敗やアプリケーションレベルのタイムアウトが発生する可能性があることに注意してください。
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]で説明されているように解釈されます。
o Persistent connection: a TCP connection that is not closed either by the server after sending the first response nor by the client after receiving the first response.
o 持続的接続：最初の応答を送信した後にサーバーによっても、最初の応答を受信した後にクライアントによっても閉じられないTCP接続。
o Connection Reuse: the sending of multiple queries and responses over a single TCP connection.
o 接続の再利用：単一のTCP接続を介した複数のクエリと応答の送信。
o Idle DNS-over-TCP session: Clients and servers view application-level idleness differently. A DNS client considers an established DNS-over-TCP session to be idle when it has no pending queries to send and there are no outstanding responses. A DNS server considers an established DNS-over-TCP session to be idle when it has sent responses to all the queries it has received on that connection.
o アイドルDNS-over-TCPセッション：クライアントとサーバーは、アプリケーションレベルのアイドル状態を異なる方法で表示します。 DNSクライアントは、送信する保留中のクエリがなく、未処理の応答がない場合、確立されたDNS-over-TCPセッションがアイドルであると見なします。 DNSサーバーは、その接続で受信したすべてのクエリに応答を送信すると、確立されたDNS-over-TCPセッションがアイドルであると見なします。
o Pipelining: the sending of multiple queries and responses over a single TCP connection but not waiting for any outstanding replies before sending another query.
o パイプライン処理：単一のTCP接続を介して複数のクエリと応答を送信しますが、別のクエリを送信する前に未解決の応答を待機しません。
o Out-of-Order Processing: The processing of queries concurrently and the returning of individual responses as soon as they are available, possibly out of order. This will most likely occur in recursive servers; however, it is possible in authoritative servers that, for example, have different backend data stores.
o 順不同処理：クエリを同時に処理し、可能であれば順番が狂ってすぐに個々の応答を返します。これはおそらく再帰サーバーで発生します。ただし、たとえば、異なるバックエンドデータストアを持つ信頼できるサーバーでは可能です。
In the absence of EDNS0 (Extension Mechanisms for DNS 0 [RFC6891]; see below), the normal behaviour of any DNS server that needs to send a UDP response that would exceed the 512-byte limit is for the server to truncate the response so that it fits within that limit and then set the TC flag in the response header. When the client receives such a response, it takes the TC flag as an indication that it should retry over TCP instead.
EDNS0（DNS 0 [RFC6891]の拡張メカニズム;以下を参照）がない場合、512バイトの制限を超えるUDP応答を送信する必要があるDNSサーバーの通常の動作は、サーバーが応答を切り捨てるためです。その制限内に収まることを確認してから、応答ヘッダーにTCフラグを設定します。クライアントがこのような応答を受信すると、代わりにTCPを介して再試行する必要があることを示すTCフラグを受け取ります。
RFC 1123 also says:
RFC 1123はまた言います：
... it is also clear that some new DNS record types defined in the future will contain information exceeding the 512 byte limit that applies to UDP, and hence will require TCP. Thus, resolvers and name servers should implement TCP services as a backup to UDP today, with the knowledge that they will require the TCP service in the future.
...また、将来定義されるいくつかの新しいDNSレコードタイプには、UDPに適用される512バイトの制限を超える情報が含まれるため、TCPが必要になることも明らかです。したがって、リゾルバとネームサーバーは、将来的にTCPサービスが必要になることを認識しながら、TCPサービスをUDPへのバックアップとして実装する必要があります。
Existing deployments of DNSSEC [RFC4033] have shown that truncation at the 512-byte boundary is now commonplace. For example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger than 512 bytes.
DNSSEC [RFC4033]の既存の展開では、512バイト境界での切り捨てが一般的になっていることが示されています。たとえば、NextSECure 3（NSEC3）[RFC5155]を使用したDNSSEC署名ゾーンからの存在しないドメイン（NXDOMAIN）（RCODE == 3）の応答は、ほぼ常に512バイトより大きくなります。
Since the original core specifications for DNS were written, the extension mechanisms for DNS have been introduced. These extensions can be used to indicate that the client is prepared to receive UDP responses larger than 512 bytes. An EDNS0-compatible server receiving a request from an EDNS0-compatible client may send UDP packets up to that client's announced buffer size without truncation.
DNSの元のコア仕様が記述されたため、DNSの拡張メカニズムが導入されました。これらの拡張は、クライアントが512バイトを超えるUDP応答を受信する準備ができていることを示すために使用できます。 EDNS0互換クライアントから要求を受信するEDNS0互換サーバーは、そのクライアントのアナウンスされたバッファサイズまでUDPパケットを切り捨てずに送信できます。
However, transport of UDP packets that exceed the size of the path MTU causes IP packet fragmentation, which has been found to be unreliable in many circumstances. Many firewalls routinely block fragmented IP packets, and some do not implement the algorithms necessary to reassemble fragmented packets. Worse still, some network devices deliberately refuse to handle DNS packets containing EDNS0 options. Other issues relating to UDP transport and packet size are discussed in [RFC5625].
ただし、パスMTUのサイズを超えるUDPパケットを転送すると、IPパケットの断片化が発生します。これは、多くの状況で信頼できないことが判明しています。多くのファイアウォールは定期的に断片化されたIPパケットをブロックし、一部のファイアウォールは断片化されたパケットを再構成するために必要なアルゴリズムを実装していません。さらに悪いことに、一部のネットワークデバイスは、意図的にEDNS0オプションを含むDNSパケットの処理を拒否します。 UDPトランスポートとパケットサイズに関連する他の問題は、[RFC5625]で説明されています。
The MTU most commonly found in the core of the Internet is around 1500 bytes, and even that limit is routinely exceeded by DNSSEC-signed responses.
インターネットのコアで最も一般的に見られるMTUは約1500バイトであり、DNSSEC署名付き応答によってその制限を日常的に超えています。
The future that was anticipated in RFC 1123 has arrived, and the only standardised UDP-based mechanism that may have resolved the packet size issue has been found inadequate.
RFC 1123で予期されていた未来が到来し、パケットサイズの問題を解決した可能性のある唯一の標準化されたUDPベースのメカニズムが不十分であることが判明しました。
Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS implementations MUST support both UDP and TCP transport.
[RFC1123]のセクション6.1.3.2が更新されました。すべての汎用DNS実装は、UDPトランスポートとTCPトランスポートの両方をサポートする必要があります。
o Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet.
o 信頼できるサーバーの実装はTCPをサポートする必要があるため、応答のサイズが単一のUDPパケットに収まるサイズに制限されません。
o Recursive server (or forwarder) implementations MUST support TCP so that they do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients.
o 再帰的なサーバー（またはフォワーダー）の実装は、TCP対応サーバーからの大きな応答がTCP対応クライアントに到達するのを妨げないように、TCPをサポートする必要があります。
o Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.
o スタブリゾルバの実装（オペレーティングシステムのDNS解決ライブラリなど）は、TCPをサポートする必要があります。そうしないと、独自のクライアントとアップストリームサーバー間の相互運用性が制限されます。
Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of RFC 1123 also says:
UDPまたはTCPをいつ使用するかの選択については、RFC 1123のセクション6.1.3.2にも次のように記載されています。
... a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.
...非ゾーン転送クエリを送信しているDNSリゾルバまたはサーバーは、最初にUDPクエリを送信する必要があります。
This requirement is hereby relaxed. Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons. TCP MAY be used before sending any UDP queries. If the resolver already has an open TCP connection to the server, it SHOULD reuse this connection. In essence, TCP ought to be considered a valid alternative transport to UDP, not purely a retry option.
これにより、この要件は緩和されます。スタブリゾルバと再帰リゾルバは、ローカルの運用上の理由に応じて、TCPまたはUDPクエリを送信することを選択できます。 UDPクエリを送信する前にTCPを使用できます。リゾルバがすでにサーバーへのオープンTCP接続を持っている場合、この接続を再利用する必要があります。本質的に、TCPは純粋に再試行オプションではなく、UDPへの有効な代替トランスポートと見なされるべきです。
In addition, it is noted that all recursive and authoritative servers MUST send responses using the same transport as the query arrived on. In the case of TCP, this MUST also be the same connection.
さらに、すべての再帰的で信頼できるサーバーは、クエリが到着したときと同じトランスポートを使用して応答を送信する必要があることに注意してください。 TCPの場合、これも同じ接続でなければなりません。
Section 4.2.2 of [RFC1035] says:
[RFC1035]のセクション4.2.2は次のように述べています。
- The server should assume that the client will initiate connection closing, and should delay closing its end of the connection until all outstanding client requests have been satisfied.
- サーバーは、クライアントが接続のクローズを開始すると想定し、すべての未解決のクライアント要求が満たされるまで、接続の終了を遅らせる必要があります。
- If the server needs to close a dormant connection to reclaim resources, it should wait until the connection has been idle for a period on the order of two minutes. In particular, the server should allow the SOA and AXFR request sequence (which begins a refresh operation) to be made on a single connection. Since the server would be unable to answer queries anyway, a unilateral close or reset may be used instead of graceful close.
- サーバーがリソースを再利用するために休止状態の接続を閉じる必要がある場合は、接続が約2分間アイドル状態になるまで待機する必要があります。特に、サーバーは、SOAおよびAXFR要求シーケンス（リフレッシュ操作を開始する）が単一の接続で行われることを許可する必要があります。いずれにしてもサーバーはクエリに応答できないので、正常なクローズの代わりに、一方的なクローズまたはリセットを使用できます。
Other more modern protocols (e.g., HTTP/1.1 [RFC7230], HTTP/2 [RFC7540]) have support by default for persistent TCP connections for all requests. Connections are then normally closed via a 'connection close' signal from one party.
他の最新のプロトコル（HTTP / 1.1 [RFC7230]、HTTP / 2 [RFC7540]など）は、デフォルトで、すべてのリクエストの永続的なTCP接続をサポートしています。その後、接続は通常、一方のパーティからの「接続クローズ」信号を介してクローズされます。
The description in [RFC1035] is clear that servers should view connections as persistent (particularly after receiving an SOA), but unfortunately does not provide enough detail for an unambiguous interpretation of client behaviour for queries other than a SOA. Additionally, DNS does not yet have a signalling mechanism for connection timeout or close, although some have been proposed.
[RFC1035]の説明では、サーバーは接続を永続的に（特にSOAを受信した後）と見なす必要があることは明らかですが、残念ながらSOA以外のクエリに対するクライアントの動作を明確に解釈するための十分な詳細はありません。さらに、DNSにはまだ接続タイムアウトまたはクローズのシグナリングメカニズムがありませんが、いくつか提案されています。
There is no clear guidance today in any RFC as to when a DNS client should close a TCP connection, and there are no specific recommendations with regard to DNS client idle timeouts. However, at the time of writing, it is common practice for clients to close the TCP connection after sending a single request (apart from the SOA/ AXFR case).
今日のRFCには、DNSクライアントがTCP接続を閉じる必要がある時期に関する明確なガイダンスはなく、DNSクライアントのアイドルタイムアウトに関する特定の推奨事項はありません。ただし、これを書いている時点では、クライアントが（SOA / AXFRの場合を除いて）単一の要求を送信した後にTCP接続を閉じるのが一般的です。
Many DNS server implementations use a long fixed idle timeout and default to a small number of TCP connections. They also offer little in the way of TCP connection management options. The disadvantages of this include:
多くのDNSサーバー実装は、長い固定アイドルタイムアウトを使用し、デフォルトで少数のTCP接続に設定されています。また、TCP接続管理オプションをほとんど提供しません。これには次のような短所があります。
o Operational experience has shown that long server timeouts can easily cause resource exhaustion and poor response under heavy load.
o 運用経験から、サーバーのタイムアウトが長いと、高負荷時にリソースが使い果たされ、応答が悪くなる可能性があることがわかっています。
o Intentionally opening many connections and leaving them idle can trivially create a TCP denial of service (DoS) attack as many DNS servers are poorly equipped to defend against this by modifying their idle timeouts or other connection management policies.
o 多くのDNSサーバーはアイドルタイムアウトや他の接続管理ポリシーを変更してこれを防御する機能が不十分であるため、意図的に多くの接続を開いてアイドル状態のままにすると、TCPサービス拒否（DoS）攻撃が発生する可能性があります。
o A modest number of clients that all concurrently attempt to use persistent connections with non-zero idle timeouts to such a server could unintentionally cause the same DoS problem.
o そのようなサーバーへのゼロ以外のアイドルタイムアウトで永続的な接続を同時に使用しようとする適度な数のクライアントは、意図せずに同じDoS問題を引き起こす可能性があります。
Note that this DoS is only on the TCP service. However, in these cases, it affects not only clients that wish to use TCP for their queries for operational reasons, but all clients that choose to fall back to TCP from UDP after receiving a TC=1 flag.
このDoSはTCPサービスのみに存在することに注意してください。ただし、これらの場合、操作上の理由でクエリにTCPを使用したいクライアントだけでなく、TC = 1フラグを受け取った後にUDPからTCPにフォールバックすることを選択したすべてのクライアントに影響します。
The following sections include recommendations that are intended to result in more consistent and scalable implementations of DNS-over-TCP.
次のセクションには、DNS-over-TCPのより一貫したスケーラブルな実装をもたらすことを目的とした推奨事項が含まれています。
One perceived disadvantage to DNS over TCP is the added connection setup latency, generally equal to one RTT. To amortise connection setup costs, both clients and servers SHOULD support connection reuse by sending multiple queries and responses over a single persistent TCP connection.
DNS over TCPの欠点の1つに、接続セットアップのレイテンシが追加されていることが挙げられます。これは、一般に1つのRTTに相当します。接続設定コストを償却するために、クライアントとサーバーの両方が、単一の永続的なTCP接続を介して複数のクエリと応答を送信することにより、接続の再利用をサポートする必要があります（SHOULD）。
When sending multiple queries over a TCP connection, clients MUST NOT reuse the DNS Message ID of an in-flight query on that connection in order to avoid Message ID collisions. This is especially important if the server could be performing out-of-order processing (see Section 7).
TCP接続を介して複数のクエリを送信する場合、メッセージIDの衝突を回避するために、クライアントはその接続でインフライトクエリのDNSメッセージIDを再利用してはなりません（MUST NOT）。これは、サーバーが順不同の処理を実行している場合に特に重要です（セクション7を参照）。
Due to the historical use of TCP primarily for zone transfer and truncated responses, no existing RFC discusses the idea of pipelining DNS queries over a TCP connection.
主にゾーン転送と切り捨てられた応答のためのTCPの歴史的な使用のため、既存のRFCは、TCP接続を介したDNSクエリのパイプライン化のアイデアについて議論していません。
In order to achieve performance on par with UDP, DNS clients SHOULD pipeline their queries. When a DNS client sends multiple queries to a server, it SHOULD NOT wait for an outstanding reply before sending the next query. Clients SHOULD treat TCP and UDP equivalently when considering the time at which to send a particular query.
UDPと同等のパフォーマンスを実現するために、DNSクライアントはクエリをパイプライン処理する必要があります（SHOULD）。 DNSクライアントがサーバーに複数のクエリを送信する場合、次のクエリを送信する前に未解決の応答を待つべきではありません（SHOULD NOT）。クライアントは、特定のクエリを送信する時間を考慮する場合、TCPとUDPを同等に扱う必要があります（SHOULD）。
It is likely that DNS servers need to process pipelined queries concurrently and also send out-of-order responses over TCP in order to provide the level of performance possible with UDP transport. If TCP performance is of importance, clients might find it useful to use server processing times as input to server and transport selection algorithms.
UDPトランスポートで可能なレベルのパフォーマンスを提供するために、DNSサーバーはパイプライン化されたクエリを同時に処理し、TCPを介して異常な応答を送信する必要がある可能性があります。 TCPのパフォーマンスが重要である場合、クライアントは、サーバーの処理時間をサーバーおよびトランスポート選択アルゴリズムへの入力として使用すると便利な場合があります。
DNS servers (especially recursive) MUST expect to receive pipelined queries. The server SHOULD process TCP queries concurrently, just as it would for UDP. The server SHOULD answer all pipelined queries, even if they are received in quick succession. The handling of responses to pipelined queries is covered in Section 7.
DNSサーバー（特に再帰的）は、パイプライン化されたクエリを受信する必要があります。サーバーは、UDPの場合と同様に、TCPクエリを同時に処理する必要があります（SHOULD）。サーバーは、パイプライン化されたすべてのクエリに応答する必要があります。パイプラインクエリに対する応答の処理については、セクション7で説明します。
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つの接続のみが必要です（たとえば、リゾルバーが使用している場合） TLS）。ただし、運用上の理由から（たとえば、複数のゾーンの同時転送をサポートするため）、ビジーゾーンが多い特定のプライマリ/セカンダリ構成では、ゾーン転送に複数のTCP接続を使用する必要がある場合があります。
Similarly, servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client IP address or subnet. These limits SHOULD be much looser than the client guidelines above, because the server does not know, for example, if a client IP address belongs to a single client, is multiple resolvers on a single machine, or is multiple clients behind a device performing Network Address Translation (NAT).
同様に、サーバーは、特定のクライアントIPアドレスまたはサブネットで処理される同時TCP接続の数に制限を課してもよい（MAY）。たとえば、クライアントのIPアドレスが単一のクライアントに属しているのか、単一のマシン上の複数のリゾルバーであるのか、ネットワークを実行するデバイスの背後にある複数のクライアントであるのか、サーバーは知らないため、これらの制限は上記のクライアントガイドラインよりもはるかに緩いはずです（SHOULD）。アドレス変換（NAT）。
To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimise the idle time of established DNS-over-TCP sessions made to any individual server. DNS clients SHOULD close the TCP connection of an idle session, unless an idle timeout has been established using some other signalling mechanism, for example, [edns-tcp-keepalive].
意図しないサーバーの過負荷のリスクを軽減するために、DNSクライアントは、個々のサーバーに対して確立されたDNS-over-TCPセッションのアイドル時間を最小限に抑えるよう注意する必要があります。 [edns-tcp-keepalive]などの他のシグナリングメカニズムを使用してアイドルタイムアウトが確立されていない限り、DNSクライアントはアイドルセッションのTCP接続を閉じる必要があります（SHOULD）。
To mitigate the risk of unintentional server overload, it is RECOMMENDED that the default server application-level idle period be on the order of seconds, but no particular value is specified. In practice, the idle period can vary dynamically, and servers MAY allow idle connections to remain open for longer periods as resources permit. A timeout of at least a few seconds is advisable for normal operations to support those clients that expect the SOA and AXFR request sequence to be made on a single connection as originally specified in [RFC1035]. Servers MAY use zero timeouts when they are experiencing heavy load or are under attack.
意図しないサーバーの過負荷のリスクを軽減するために、デフォルトのサーバーアプリケーションレベルのアイドル期間を数秒程度にすることをお勧めしますが、特定の値は指定されていません。実際には、アイドル期間は動的に変化する可能性があり、サーバーは、リソースが許す限り、アイドル接続をより長い期間開いたままにすることを許可する場合があります。 [RFC1035]で最初に指定されたように、SOAおよびAXFR要求シーケンスが単一の接続で行われることを期待するクライアントをサポートするには、通常の操作で少なくとも数秒のタイムアウトが推奨されます。サーバーは、負荷が大きい場合や攻撃を受けている場合に、タイムアウトを使用しない場合があります。
DNS messages delivered over TCP might arrive in multiple segments. A DNS server that resets its idle timeout after receiving a single segment might be vulnerable to a "slow-read attack". For this reason, servers SHOULD reset the idle timeout on the receipt of a full DNS message, rather than on receipt of any part of a DNS message.
TCPを介して配信されるDNSメッセージは、複数のセグメントで到着する場合があります。単一のセグメントを受信した後にアイドルタイムアウトをリセットするDNSサーバーは、「低速読み取り攻撃」に対して脆弱である可能性があります。このため、サーバーは、DNSメッセージの一部を受信するのではなく、完全なDNSメッセージを受信したときにアイドルタイムアウトをリセットする必要があります（SHOULD）。
Under normal operation DNS clients typically initiate connection closing on idle connections; however, DNS servers can close the connection if the idle timeout set by local policy is exceeded. Also, connections can be closed by either end under unusual conditions such as defending against an attack or system failure/ reboot.
通常の操作では、DNSクライアントは通常、アイドル接続で接続クローズを開始します。ただし、ローカルポリシーで設定されたアイドルタイムアウトを超えた場合、DNSサーバーは接続を閉じることができます。また、攻撃に対する防御やシステム障害/再起動などの異常な状況下では、どちらかの側で接続を閉じることができます。
DNS clients SHOULD retry unanswered queries if the connection closes before receiving all outstanding responses. No specific retry algorithm is specified in this document.
DNSクライアントは、すべての未処理の応答を受信する前に接続が閉じた場合、応答のないクエリを再試行する必要があります（SHOULD）。このドキュメントでは、特定の再試行アルゴリズムは指定されていません。
If a DNS server finds that a DNS client has closed a TCP session (or if the session has been otherwise interrupted) before all pending responses have been sent, then the server MUST NOT attempt to send those responses. Of course, the DNS server MAY cache those responses.
保留中のすべての応答が送信される前に、DNSサーバーがDNSクライアントがTCPセッションを閉じた（またはセッションが中断された）ことを検出した場合、サーバーはそれらの応答の送信を試みてはなりません（MUST NOT）。もちろん、DNSサーバーはそれらの応答をキャッシュしてもよい（MAY）。
RFC 1035 is ambiguous on the question of whether TCP responses may be reordered -- the only relevant text is in Section 4.2.1, which relates to UDP:
RFC 1035は、TCP応答を並べ替えるかどうかの問題について曖昧です。関連する唯一のテキストは、UDPに関連するセクション4.2.1にあります。
Queries or their responses may be reordered by the network, or by processing in name servers, so resolvers should not depend on them being returned in order.
クエリまたはその応答は、ネットワークまたはネームサーバーでの処理によって並べ替えられる可能性があるため、リゾルバはそれらが順番に返されることに依存すべきではありません。
For the avoidance of future doubt, this requirement is clarified. Authoritative servers and recursive resolvers are RECOMMENDED to support the preparing of responses in parallel and sending them out of order, regardless of the transport protocol in use. Stub and recursive resolvers MUST be able to process responses that arrive in a different order than that in which the requests were sent, regardless of the transport protocol in use.
将来の疑いを避けるために、この要件は明確にされています。使用中のトランスポートプロトコルに関係なく、権限のあるサーバーと再帰リゾルバーを使用して、応答の準備と順不同での送信をサポートすることをお勧めします。スタブおよび再帰リゾルバは、使用中のトランスポートプロトコルに関係なく、要求が送信された順序とは異なる順序で到着する応答を処理できる必要があります。
In order to achieve performance on par with UDP, recursive resolvers SHOULD process TCP queries in parallel and return individual responses as soon as they are available, possibly out of order.
UDPと同等のパフォーマンスを実現するために、再帰リゾルバは、TCPクエリを並行して処理し、可能であれば順番が狂ってすぐに個々の応答を返す必要があります（SHOULD）。
Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TCP connection using the Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability.
パイプライン化された応答は順不同で到着する可能性があるため、クライアントは、メッセージIDを使用して、応答を同じTCP接続上の未解決のクエリに一致させる必要があります。応答に質問セクションが含まれている場合、クライアントはQNAME、QCLASS、およびQTYPEフィールドと一致する必要があります。クライアントが未処理のクエリへの応答を適切に照合できないと、相互運用性に深刻な影響を与える可能性があります。
DNS clients and servers SHOULD pass the two-octet length field, and the message described by that length field, to the TCP layer at the same time (e.g., in a single "write" system call) to make it more likely that all the data will be transmitted in a single TCP segment. This is for reasons of both efficiency and to avoid problems due to some DNS server implementations behaving undesirably when reading data from the TCP layer (due to a lack of clarity in previous documents). For example, some DNS server implementations might abort a TCP session if the first "read" from the TCP layer does not contain both the length field and the entire message.
DNSクライアントとサーバーは、2オクテットの長さフィールドと、その長さフィールドによって記述されたメッセージを同時に（たとえば、単一の「書き込み」システムコールで）TCP層に渡して、すべてのデータは単一のTCPセグメントで送信されます。これは、効率性の理由と、TCPサーバーからデータを読み取るときに一部のDNSサーバー実装が望ましくない動作をすることによる問題を回避するためです（以前のドキュメントでは明確さが欠けていたため）。たとえば、一部のDNSサーバーの実装では、TCP層からの最初の「読み取り」に長さフィールドとメッセージ全体の両方が含まれていない場合、TCPセッションを中止することがあります。
To clarify, DNS servers MUST NOT close a connection simply because the first "read" from the TCP layer does not contain the entire DNS message, and servers SHOULD apply the connection timeouts as specified in Section 6.2.3.
明確にするために、TCP層からの最初の「読み取り」にDNSメッセージ全体が含まれておらず、サーバーがセクション6.2.3で指定された接続タイムアウトを適用する必要があるため、DNSサーバーは接続を閉じてはなりません。
This section is non-normative.
このセクションは非規範的です。
TCP Fast Open (TFO) [RFC7413] allows data to be carried in the SYN packet, reducing the cost of reopening TCP connections. It also saves up to one RTT compared to standard TCP.
TCP Fast Open（TFO）[RFC7413]では、SYNパケットでデータを伝送できるため、TCP接続を再オープンするコストが削減されます。また、標準TCPと比較して最大1つのRTTを節約します。
TFO mitigates the security vulnerabilities inherent in sending data in the SYN, especially on a system like DNS where amplification attacks are possible, by use of a server-supplied cookie. TFO clients request a server cookie in the initial SYN packet at the start of a new connection. The server returns a cookie in its SYN-ACK. The client caches the cookie and reuses it when opening subsequent connections to the same server.
TFOは、サーバーが提供するCookieを使用することで、特に増幅攻撃が可能なDNSのようなシステムで、SYNでデータを送信することによるセキュリティの脆弱性を軽減します。 TFOクライアントは、新しい接続の開始時に最初のSYNパケットでサーバーCookieを要求します。サーバーはSYN-ACKでCookieを返します。クライアントはCookieをキャッシュし、同じサーバーへの後続の接続を開くときにそれを再利用します。
The cookie is stored by the client's TCP stack (kernel) and persists if either the client or server processes are restarted. TFO also falls back to a regular TCP handshake gracefully.
CookieはクライアントのTCPスタック（カーネル）によって格納され、クライアントまたはサーバープロセスが再起動されても保持されます。 TFOは、通常のTCPハンドシェイクにも適切にフォールバックします。
DNS services taking advantage of IP anycast [RFC4786] might need to take additional steps when enabling TFO. From [RFC7413]:
IPエニーキャスト[RFC4786]を利用するDNSサービスでは、TFOを有効にするときに追加の手順が必要になる場合があります。 [RFC7413]から：
Servers behind load balancers that accept connection requests to the same server IP address should use the same key such that they generate identical Fast Open cookies for a particular client IP address. Otherwise, a client may get different cookies across connections; its Fast Open attempts would fall back to the regular 3WHS.
同じサーバーIPアドレスへの接続要求を受け入れるロードバランサーの背後にあるサーバーは、同じキーを使用して、特定のクライアントIPアドレスに対して同一のFast Open Cookieを生成する必要があります。そうしないと、クライアントは接続全体で異なるCookieを取得する可能性があります。その高速オープンの試みは、通常の3WHSにフォールバックします。
When DNS-over-TCP is a transport for DNS private exchange, as in [DNS-over-TLS], the implementor needs to be aware of TFO and to ensure that data requiring protection (e.g. data for a DNS query) is not accidentally transported in the clear. See [DNS-over-TLS] for discussion.
[DNS-over-TLS]のように、DNS-over-TCPがDNSプライベート交換のトランスポートである場合、実装者はTFOを認識し、保護が必要なデータ（DNSクエリのデータなど）が誤って発生しないことを確認する必要があります平文で輸送されました。議論については[DNS-over-TLS]を参照してください。
Some DNS server operators have expressed concern that wider promotion and use of DNS over TCP will expose them to a higher risk of DoS attacks on TCP (both accidental and deliberate).
一部のDNSサーバーオペレーターは、TCP over DNSのより広いプロモーションと使用により、TCPへのDoS攻撃のリスクが高まる（偶発的および意図的な）ことに懸念を表明しています。
Although there is a higher risk of some specific attacks against TCP-enabled servers, techniques for the mitigation of DoS attacks at the network level have improved substantially since DNS was first designed.
TCP対応サーバーに対する特定の攻撃のリスクは高くなりますが、DNSが最初に設計されて以来、ネットワークレベルでのDoS攻撃を軽減するための手法は大幅に改善されています。
Readers are advised to familiarise themselves with [CPNI-TCP], a security assessment of TCP that details known TCP attacks and countermeasures and that references most of the relevant RFCs on this topic.
読者は[CPNI-TCP]に慣れることをお勧めします。これは、既知のTCP攻撃と対策を詳述し、このトピックに関連するRFCのほとんどを参照するTCPのセキュリティ評価です。
To mitigate the risk of DoS attacks, DNS servers are advised to engage in TCP connection management. This could include maintaining state on existing connections, reusing existing connections, and controlling request queues to enable fair use. It is likely to be advantageous to provide configurable connection management options, for example:
DoS攻撃のリスクを軽減するために、DNSサーバーはTCP接続管理に従事することをお勧めします。これには、既存の接続の状態の維持、既存の接続の再利用、フェアユースを有効にするための要求キューの制御が含まれます。たとえば、構成可能な接続管理オプションを提供することは有利です。
o total number of TCP connections
o TCP接続の総数
o maximum TCP connections per source IP address or subnet
o ソースIPアドレスまたはサブネットごとの最大TCP接続
o TCP connection idle timeout
o TCP接続アイドルタイムアウト
o maximum DNS transactions per TCP connection
o TCP接続ごとの最大DNSトランザクション
o maximum TCP connection duration
o 最大TCP接続期間
No specific values are recommended for these parameters.
これらのパラメータに特定の値は推奨されません。
Operators are advised to familiarise themselves with the configuration and tuning parameters available in the TCP stack of the operating system. However, detailed advice on this is outside the scope of this document.
オペレーターは、オペレーティングシステムのTCPスタックで使用可能な構成およびチューニングパラメーターについて理解することをお勧めします。ただし、これに関する詳細なアドバイスは、このドキュメントの範囲外です。
Operators of recursive servers are advised to ensure that they only accept connections from expected clients (for example, by the use of an Access Control List (ACL)) and do not accept them from unknown sources. In the case of UDP traffic, this will help protect against reflection attacks [RFC5358]; and in the case of TCP traffic, it will prevent an unknown client from exhausting the server's limits on the number of concurrent connections.
再帰サーバーのオペレーターは、予期されるクライアントからの接続のみを受け入れるようにし（たとえば、アクセス制御リスト（ACL）を使用して）、不明なソースからの接続を受け入れないようにすることをお勧めします。 UDPトラフィックの場合、これはリフレクション攻撃からの保護に役立ちます[RFC5358]。 TCPトラフィックの場合は、不明なクライアントがサーバーの同時接続数の制限を使い果たすことを防ぎます。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[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>。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<http://www.rfc-editor.org/info / rfc1123>。
[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> 。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <http://www.rfc-editor.org/info/rfc5155>.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<http： //www.rfc-editor.org/info/rfc5155>。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <http://www.rfc-editor.org/info/rfc5358>.
[RFC5358] Damas、J。およびF. Neves、「Preventing Use of Recursive Nameservers in Reflector Attacks」、BCP 140、RFC 5358、DOI 10.17487 / RFC5358、2008年10月、<http://www.rfc-editor.org/ info / rfc5358>。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <http://www.rfc-editor.org/info/rfc5625>.
[RFC5625] Bellis、R。、「DNSプロキシ実装ガイドライン」、BCP 152、RFC 5625、DOI 10.17487 / RFC5625、2009年8月、<http://www.rfc-editor.org/info/rfc5625>。
[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation Requirements", RFC 5966, DOI 10.17487/RFC5966, August 2010, <http://www.rfc-editor.org/info/rfc5966>.
[RFC5966] Bellis、R。、「TCP Transport over TCP-実装要件」、RFC 5966、DOI 10.17487 / RFC5966、2010年8月、<http://www.rfc-editor.org/info/rfc5966>。
[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>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<http：// www.rfc-editor.org/info/rfc7540>。
[Connection-Oriented-DNS] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "Connection-Oriented DNS to Improve Privacy and Security", 2015 IEEE Symposium on Security and Privacy (SP), DOI 10.1109/SP.2015.18, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=7163025>.
[Connection-Oriented-DNS] Zhu、L.、Hu、Z.、Heidemann、J.、Wessels、D.、Mankin、A.、and N. Somaiya、 "Connection-Oriented DNS to Improve Privacy and Security"、2015 IEEE Symposium on Security and Privacy（SP）、DOI 10.1109 / SP.2015.18、<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7163025>。
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>.
[CPNI-TCP] CPNI、「TCP（Transmission Control Protocol）のセキュリティ評価」、2009、<http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf >。
[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-06, February 2016.
[DNS-over-TLS] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「TLS over DNSの仕様」、作業中、ドラフト-ietf-dprive-dns-over-tls-06、2016年2月。
[edns-tcp-keepalive] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", Work in Progress, draft-ietf-dnsop-edns-tcp-keepalive-03, September 2015.
[edns-tcp-keepalive] Wouters、P.、Abley、J.、Dickinson、S。、およびR. Bellis、「The edns-tcp-keepalive EDNS0 Option」、Work in Progress、draft-ietf-dnsop-edns- tcp-keepalive-03、2015年9月。
[fragmentation-considered-poisonous] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>.
[fragmentation-considered-poisonous] Herzberg、A。およびH. Shulman、「フラグメンテーションは有毒と見なされる」、2012年5月、<http://arxiv.org/abs/1205.4011>。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、DOI 10.17487 / RFC5405、2008年11月、<http://www.rfc-editor.org/info / rfc5405>。
[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>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://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月、<http：//www.rfc-editor .org / info / rfc7413>。
[RRL1] 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>.
[RRL1] 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>。
[RRL2] ISC Support, "Using the Response Rate Limiting Feature in BIND 9.10", ISC Knowledge Base AA-00994, June 2013, <https://kb.isc.org/article/AA-00994/>.
[RRL2] ISCサポート、「BIND 9.10での応答速度制限機能の使用」、ISCナレッジベースAA-00994、2013年6月、<https://kb.isc.org/article/AA-00994/>。
Appendix A. Summary of Advantages and Disadvantages to Using TCP for DNS
付録A. DNSにTCPを使用する利点と欠点の要約
The TCP handshake generally prevents address spoofing and, therefore, the reflection/amplification attacks that plague UDP.
TCPハンドシェイクは、一般にアドレスのなりすましを防ぎ、UDPを悩ます反射/増幅攻撃を防ぎます。
IP fragmentation is less of a problem for TCP than it is for UDP. TCP stacks generally implement Path MTU Discovery so they can avoid IP fragmentation of TCP segments. UDP, on the other hand, does not provide reassembly; this means datagrams that exceed the path MTU size must experience fragmentation [RFC5405]. Middleboxes are known to block IP fragments, leading to timeouts and forcing client implementations to "hunt" for EDNS0 reply size values supported by the network path. Additionally, fragmentation may lead to cache poisoning [fragmentation-considered-poisonous].
IPフラグメンテーションは、UDPの場合よりもTCPの場合の問題が少ないです。 TCPスタックは通常、パスMTU検出を実装しているため、TCPセグメントのIP断片化を回避できます。一方、UDPは再構成を提供しません。これは、パスMTUサイズを超えるデータグラムは断片化を経験する必要があることを意味します[RFC5405]。ミドルボックスはIPフラグメントをブロックすることが知られており、タイムアウトを引き起こし、クライアントの実装に、ネットワークパスでサポートされているEDNS0応答サイズの値を「ハント」するよう強制します。さらに、断片化はキャッシュポイズニング[fragmentation-considered-poisonous]につながる可能性があります。
TCP setup costs an additional RTT compared to UDP queries. Setup costs can be amortised by reusing connections, pipelining queries, and enabling TCP Fast Open.
TCPセットアップには、UDPクエリと比較して追加のRTTがかかります。接続の再利用、クエリのパイプライン化、TCP Fast Openの有効化により、セットアップコストを償却できます。
TCP imposes additional state-keeping requirements on clients and servers. The use of TCP Fast Open reduces the cost of closing and reopening TCP connections.
TCPは、クライアントとサーバーに追加の状態保持要件を課します。 TCP Fast Openを使用すると、TCP接続を閉じて再度開くコストが削減されます。
Long-lived TCP connections to anycast servers might be disrupted due to routing changes. Clients utilizing TCP for DNS need to always be prepared to re-establish connections or otherwise retry outstanding queries. It might also be possible for Multipath TCP [RFC6824] to allow a server to hand a connection over from the anycast address to a unicast address.
エニーキャストサーバーへの長期間のTCP接続は、ルーティングの変更が原因で中断される可能性があります。 DNSにTCPを使用するクライアントは、接続を再確立するか、未処理のクエリを再試行する準備を常に行う必要があります。マルチパスTCP [RFC6824]がサーバーにエニーキャストアドレスからユニキャストアドレスへの接続の引き渡しを許可することも可能かもしれません。
There are many "middleboxes" in use today that interfere with TCP over port 53 [RFC5625]. This document does not propose any solutions, other than to make it absolutely clear that TCP is a valid transport for DNS and support for it is a requirement for all implementations.
今日使用されている多くの「ミドルボックス」が、ポート53を介したTCP [RFC5625]に干渉しています。このドキュメントは、TCPがDNSの有効なトランスポートであり、そのサポートがすべての実装の要件であることを完全に明確にすることを除いて、ソリューションを提案していません。
A more in-depth discussion of connection-oriented DNS can be found elsewhere [Connection-Oriented-DNS].
コネクション型DNSの詳細については、[コネクション型DNS]を参照してください。
This document obsoletes [RFC5966] and differs from it in several respects. An overview of the most substantial changes/updates that implementors should take note of is given below.
このドキュメントは[RFC5966]を廃止し、いくつかの点でそれとは異なります。実装者が注意すべき最も重要な変更/更新の概要を以下に示します。
1. A Terminology section (Section 3) is added defining several new concepts.
1. 用語セクション（セクション3）が追加され、いくつかの新しい概念が定義されています。
2. Paragraph 3 of Section 5 puts TCP on a more equal footing with UDP than RFC 5966 does. For example, it states:
2. セクション5のパラグラフ3は、TCPをRFC 5966よりもUDPと同等の立場に置いています。たとえば、次のように述べています。
1. TCP MAY be used before sending any UDP queries.
1. UDPクエリを送信する前にTCPを使用できます。
2. TCP ought to be considered a valid alternative transport to UDP, not purely a fallback option.
2. TCPは、純粋にフォールバックオプションではなく、UDPへの有効な代替トランスポートと見なされるべきです。
3. Section 6.2.1 adds a new recommendation that TCP connection reuse SHOULD be supported.
3. セクション6.2.1では、TCP接続の再利用をサポートする必要があるという新しい推奨事項が追加されています。
4. Section 6.2.1.1 adds a new recommendation that DNS clients SHOULD pipeline their queries and DNS servers SHOULD process pipelined queries concurrently.
4. セクション6.2.1.1は、DNSクライアントがクエリをパイプライン化し、DNSサーバーがパイプライン化されたクエリを同時に処理する必要があるという新しい推奨事項を追加しています。
5. Section 6.2.2 adds new recommendations on the number and usage of TCP connections for client/server interactions.
5. セクション6.2.2では、クライアント/サーバーの相互作用のためのTCP接続の数と使用に関する新しい推奨事項が追加されています。
6. Section 6.2.3 adds a new recommendation that DNS clients SHOULD close idle sessions unless using a signalling mechanism.
6. セクション6.2.3では、シグナリングメカニズムを使用しない限り、DNSクライアントがアイドルセッションを閉じる必要があるという新しい推奨事項を追加しています。
7. Section 7 clarifies that servers are RECOMMENDED to prepare TCP responses in parallel and send answers out of order. It also clarifies how TCP queries and responses should be matched by clients.
7. セクション7は、サーバーがTCP応答を並行して準備し、順不同で応答を送信することが推奨されることを明確にします。また、クライアントがTCPクエリと応答をどのように照合するかを明確にします。
8. Section 8 adds a new recommendation about how DNS clients and servers should handle the 2-byte message length field for TCP messages.
8. セクション8では、DNSクライアントとサーバーがTCPメッセージの2バイトのメッセージ長フィールドを処理する方法に関する新しい推奨事項を追加しています。
9. Section 9 adds a non-normative discussion of the use of TCP Fast Open.
9. セクション9では、TCP Fast Openの使用に関する非規範的な説明を追加しています。
10. Section 10 adds new advice regarding DoS mitigation techniques.
10. セクション10では、DoS軽減技術に関する新しいアドバイスを追加します。
Acknowledgements
謝辞
The authors would like to thank Francis Dupont and Paul Vixie for their detailed reviews, as well as Andrew Sullivan, Tony Finch, Stephane Bortzmeyer, Joe Abley, Tatuya Jinmei, and the many others who contributed to the mailing list discussion. Also, the authors thank Liang Zhu, Zi Hu, and John Heidemann for extensive DNS-over-TCP discussions and code, and Lucie Guiraud and Danny McPherson for reviewing early draft versions of this document. We would also like to thank all those who contributed to RFC 5966.
著者は、詳細なレビューを提供してくれたFrancis DupontとPaul Vixie、およびメーリングリストのディスカッションに貢献してくれたAndrew Sullivan、Tony Finch、Stephane Bortzmeyer、Joe Abley、Tatuya Jinmei、および多くの他に感謝します。また、著者は、広範囲にわたるDNS-over-TCPの議論とコードについてLiang Zhu、Zi Hu、およびJohn Heidemannに感謝し、このドキュメントの初期ドラフトバージョンをレビューしてくれたLucie GuiraudとDanny McPhersonに感謝します。また、RFC 5966に貢献したすべての人に感謝します。
Authors' Addresses
著者のアドレス
John Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
John Dickinson Sinodun Internet TechnologiesマグダレンセンターオックスフォードサイエンスパークオックスフォードOX4 4GAイギリス
Email: jad@sinodun.com
URI: http://sinodun.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
Allison Mankin Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
Allison Mankin Verisign Labs 12061 Bluemont Way Reston、VA 20190アメリカ
Phone: +1 301 728 7198 Email: allison.mankin@gmail.com Duane Wessels Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
電話：+1 301 728 7198メール：allison.mankin@gmail.com Duane Wessels Verisign Labs 12061 Bluemont Way Reston、VA 20190米国
Phone: +1 703 948 3200
Email: dwessels@verisign.com