RFC 8094 - DNS over Datagram Transport Layer Security (DTLS) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8094
タイトル : RFC 8094 - DNS over Datagram Transport Layer Security（DTLS）
翻訳編集 : 自動生成

[要約] RFC 8094は、DNSトラフィックのセキュリティを向上させるために、DTLSを使用する方法を提案しています。目的は、DNSクエリとレスポンスの暗号化と認証を提供し、中間者攻撃やデータの改ざんを防ぐことです。

Internet Engineering Task Force (IETF)                          T. Reddy
Request for Comments: 8094                                         Cisco
Category: Experimental                                           D. Wing
ISSN: 2070-1721
                                                                P. Patil
                                                                   Cisco
                                                           February 2017

DNS over Datagram Transport Layer Security (DTLS)

DNS over Datagram Transport Layer Security（DTLS）

Abstract

概要

DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.

DNSクエリと応答は、DNSクライアントとサーバー間のパス上のネットワーク要素に表示されます。これらのクエリと応答には、プライバシーに配慮した情報が含まれる可能性があり、保護するのに役立ちます。

This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.

このドキュメントでは、パッシブリスナーや特定のアクティブな攻撃から保護するために、DNSにデータグラムトランスポート層セキュリティ（DTLS）を使用することを提案しています。遅延はDNSにとって重要であるため、この提案では、DTLSラウンドトリップを削減し、DTLSハンドシェイクサイズを削減するメカニズムについても説明します。提案されたメカニズムはポート853で実行されます。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc8094.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8094で入手できます。

著作権表示

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
      1.1. Relationship to TCP Queries and to DNSSEC ..................3
      1.2. Document Status ............................................4
   2. Terminology .....................................................4
   3. Establishing and Managing DNS over DTLS Sessions ................5
      3.1. Session Initiation .........................................5
      3.2. DTLS Handshake and Authentication ..........................5
      3.3. Established Sessions .......................................6
   4. Performance Considerations ......................................7
   5. Path MTU (PMTU) Issues ..........................................7
   6. Anycast .........................................................8
   7. Usage ...........................................................9
   8. IANA Considerations .............................................9
   9. Security Considerations .........................................9
   10. References ....................................................10
      10.1. Normative References .....................................10
      10.2. Informative References ...................................11
   Acknowledgements ..................................................13
   Authors' Addresses ................................................13

1. Introduction

1. はじめに

The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS queries and responses are normally exchanged unencrypted; thus, they are vulnerable to eavesdropping. Such eavesdropping can result in an undesired entity learning domain that a host wishes to access, thus resulting in privacy leakage. The DNS privacy problem is further discussed in [RFC7626].

ドメインネームシステムは、[RFC1034]および[RFC1035]で指定されています。 DNSクエリと応答は通常、暗号化されずに交換されます。したがって、彼らは盗聴に対して脆弱です。このような盗聴は、ホストがアクセスすることを望む望ましくないエンティティ学習ドメインをもたらす可能性があり、その結果、プライバシー漏洩が生じる。 DNSプライバシー問題は、[RFC7626]でさらに議論されています。

This document defines DNS over DTLS, which provides confidential DNS communication between stub resolvers and recursive resolvers, stub resolvers and forwarders, and forwarders and recursive resolvers. DNS over DTLS puts an additional computational load on servers. The largest gain for privacy is to protect the communication between the DNS client (the end user's machine) and its caching resolver. DNS over DTLS might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) working group per its current charter. This document does not change the format of DNS messages.

このドキュメントでは、DNS over DTLSを定義します。これにより、スタブリゾルバと再帰リゾルバ、スタブリゾルバとフォワーダ、およびフォワーダと再帰リゾルバ間の機密DNS通信が提供されます。 DNS over DTLSは、サーバーに追加の計算負荷をかけます。プライバシーの最大の利点は、DNSクライアント（エンドユーザーのマシン）とそのキャッシュリゾルバー間の通信を保護することです。 DNS over DTLSは、再帰的なクライアントと権限のあるサーバー間で同等に機能する可能性がありますが、このプロトコルのアプリケーションは、現在の憲章ではDNS PRIVate Exchange（DPRIVE）ワーキンググループの範囲外です。このドキュメントでは、DNSメッセージの形式は変更されません。

The motivations for proposing DNS over DTLS are that:

DNS over DTLSを提案する動機は次のとおりです。

o TCP suffers from network head-of-line blocking, where the loss of a packet causes all other TCP segments not to be delivered to the application until the lost packet is retransmitted. DNS over DTLS, because it uses UDP, does not suffer from network head-of-line blocking.

o TCPはネットワークヘッドオブラインブロッキングの影響を受けます。この場合、パケットの損失により、失われたパケットが再送信されるまで、他のすべてのTCPセグメントがアプリケーションに配信されません。 DNS over DTLSはUDPを使用しているため、ネットワークのヘッドオブラインブロッキングの影響を受けません。

o DTLS session resumption consumes one round trip, whereas TLS session resumption can start only after the TCP handshake is complete. However, with TCP Fast Open [RFC7413], the implementation can achieve the same RTT efficiency as DTLS.

o DTLSセッションの再開は1回のラウンドトリップを消費しますが、TLSセッションの再開は、TCPハンドシェイクが完了した後にのみ開始できます。ただし、TCP Fast Open [RFC7413]を使用すると、実装はDTLSと同じRTT効率を達成できます。

Note: DNS over DTLS is an experimental update to DNS, and the experiment will be concluded when the specification is evaluated through implementations and interoperability testing.

注：DNS over DTLSはDNSの実験的なアップデートであり、実装と相互運用性テストを通じて仕様が評価された時点で実験は終了します。

1.1. Relationship to TCP Queries and to DNSSEC

1.1. TCPクエリおよびDNSSECとの関係

DNS queries can be sent over UDP or TCP. The scope of this document, however, is only UDP. DNS over TCP can be protected with TLS, as described in [RFC7858]. DNS over DTLS alone cannot provide privacy for DNS messages in all circumstances, specifically when the DTLS record size is larger than the path MTU. In such situations, the DNS server will respond with a truncated response (see Section 5).

DNSクエリは、UDPまたはTCPを介して送信できます。ただし、このドキュメントの範囲はUDPのみです。 [RFC7858]で説明されているように、DNS over TCPはTLSで保護できます。 DNS over DTLSだけでは、特にDTLSレコードサイズがパスMTUより大きい場合、すべての状況でDNSメッセージにプライバシーを提供できません。このような状況では、DNSサーバーは切り捨てられた応答で応答します（セクション5を参照）。

Therefore, DNS clients and servers that implement DNS over DTLS MUST also implement DNS over TLS in order to provide privacy for clients that desire Strict Privacy as described in [DTLS].

したがって、DNS over DTLSを実装するDNSクライアントとサーバーは、[DTLS]で説明されている厳格なプライバシーを望むクライアントにプライバシーを提供するために、TLS over DNSも実装する必要があります。

DNS Security Extensions (DNSSEC) [RFC4033] provide object integrity of DNS resource records, allowing end users (or their resolver) to verify the legitimacy of responses. However, DNSSEC does not provide privacy for DNS requests or responses. DNS over DTLS works in conjunction with DNSSEC, but DNS over DTLS does not replace the need or value of DNSSEC.

DNSセキュリティ拡張機能（DNSSEC）[RFC4033]は、DNSリソースレコードのオブジェクトの整合性を提供し、エンドユーザー（またはそのリゾルバー）が応答の正当性を検証できるようにします。ただし、DNSSECはDNS要求または応答にプライバシーを提供しません。 DNS over DTLSはDNSSECと連携して機能しますが、DNS over DTLSはDNSSECの必要性や価値を置き換えるものではありません。

1.2. Document Status

1.2. ドキュメントのステータス

This document is an Experimental RFC. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large-scale, real-life deployments.

このドキュメントは試験的なRFCです。アプローチが大規模で使用可能かどうかを判断するための重要な側面の1つは、大規模な実際の展開におけるプロトコルの取り込み、使いやすさ、および動作の動作を観察することです。

This DTLS solution was considered by the DPRIVE working group as an option to use in case the TLS-based approach specified in [RFC7858] turns out to have some issues when deployed. At the time of writing, it is expected that [RFC7858] is what will be deployed, and so this specification is mainly intended as a backup.

このDTLSソリューションは、[RFC7858]で指定されているTLSベースのアプローチが展開時に問題があることが判明した場合に使用するオプションとして、DPRIVEワーキンググループによって検討されました。執筆時点では、[RFC7858]が展開されることが予想されているため、この仕様は主にバックアップを目的としています。

The following guidelines should be considered when performance benchmarking DNS over DTLS:

DNS over DTLSのパフォーマンスベンチマークを行う場合は、次のガイドラインを考慮する必要があります。

1. DNS over DTLS can recover from packet loss and reordering, and does not suffer from network head-of-line blocking. DNS over DTLS performance, in comparison with DNS over TLS, may be better in lossy networks.

1. DNS over DTLSは、パケット損失と再配列から回復でき、ネットワークのヘッドオブラインブロッキングの影響を受けません。 DNS over DTLSのパフォーマンスは、DNS over TLSと比較して、損失の多いネットワークで優れている場合があります。

2. The number of round trips to send the first DNS query over DNS over DTLS is less than the number of round trips to send the first DNS query over TLS. Even if TCP Fast Open is used, it only works for subsequent TCP connections between the DNS client and server (Section 3 in [RFC7413]).

2. DNS over DTLSを介して最初のDNSクエリを送信するラウンドトリップの数は、TLSを介して最初のDNSクエリを送信するラウンドトリップの数よりも少ないです。 TCP Fast Openを使用しても、DNSクライアントとサーバー間の後続のTCP接続でのみ機能します（[RFC7413]のセクション3）。

3. If the DTLS 1.3 protocol [DTLS13] is used for DNS over DTLS, it provides critical latency improvements for connection establishment over DTLS 1.2.

3. DTLS 1.3プロトコル[DTLS13]がDNS over DTLSに使用されている場合、DTLS 1.2を介した接続の確立で重要な遅延が改善されます。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「[RFC2119]」で説明されているように解釈されます。

3. Establishing and Managing DNS over DTLS Sessions

3. DNS over DTLSセッションの確立と管理

3.1. Session Initiation

3.1. セッションの開始

By default, DNS over DTLS MUST run over standard UDP port 853 as defined in Section 8, unless the DNS server has mutual agreement with its clients to use a port other than 853 for DNS over DTLS. In order to use a port other than 853, both clients and servers would need a configuration option in their software.

デフォルトでは、DNS over DTLSは、セクション8で定義されている標準のUDPポート853で実行する必要があります（ただし、DNSサーバーがクライアントと相互に合意して、DNS over DTLSに853以外のポートを使用する場合を除く）。 853以外のポートを使用するには、クライアントとサーバーの両方でソフトウェアの構成オプションが必要になります。

The DNS client should determine if the DNS server supports DNS over DTLS by sending a DTLS ClientHello message to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS over DTLS. Such another port MUST NOT be port 53 but MAY be from the "first-come, first-served" port range (User Ports [RFC6335], range 1024-49151). This recommendation against the use of port 53 for DNS over DTLS is to avoid complications in selecting use or non-use of DTLS and to reduce risk of downgrade attacks.

DNSクライアントは、サーバーがポート853以外のポートをDNS over DTLSに使用することについて相互の合意がない限り、サーバーのポート853にDTLS ClientHelloメッセージを送信することにより、DNSサーバーがDNS over DTLSをサポートするかどうかを判断する必要があります。そのような別のポートはポート53であってはなりません（MUST NOT）が、「先着順」のポート範囲（ユーザーポート[RFC6335]、範囲1024〜49151）からである場合があります。 DNS over DTLSにポート53を使用しないことに対するこの推奨事項は、DTLSの使用または非使用を選択する際の複雑さを回避し、ダウングレード攻撃のリスクを軽減することです。

A DNS server that does not support DNS over DTLS will not respond to ClientHello messages sent by the client. If no response is received from that server, and the client has no better round-trip estimate, the client SHOULD retransmit the DTLS ClientHello according to Section 4.2.4.1 of [RFC6347]. After 15 seconds, it SHOULD cease attempts to retransmit its ClientHello. The client MAY repeat that procedure to discover if DNS over DTLS service becomes available from the DNS server, but such probing SHOULD NOT be done more frequently than every 24 hours and MUST NOT be done more frequently than every 15 minutes. This mechanism requires no additional signaling between the client and server.

DNS over DTLSをサポートしていないDNSサーバーは、クライアントから送信されたClientHelloメッセージに応答しません。そのサーバーから応答が受信されず、クライアントに適切な往復推定値がない場合、クライアントは[RFC6347]のセクション4.2.4.1に従ってDTLS ClientHelloを再送信する必要があります（SHOULD）。 15秒後、ClientHelloの再送信の試行を中止する必要があります（SHOULD）。クライアントは、DNSサーバーからDNS over DTLSサービスが利用可能になるかどうかを検出するためにその手順を繰り返すことができますが、そのような調査は24時間よりも頻繁に行うべきではなく、15分よりも頻繁に行ってはなりません。このメカニズムでは、クライアントとサーバー間の追加のシグナリングは必要ありません。

DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT respond to cleartext DNS messages on any port used for DNS over DTLS (including, for example, after a failed DTLS handshake). There are significant security issues in mixing protected and unprotected data; therefore, UDP connections on a port designated by a given server for DNS over DTLS are reserved purely for encrypted communications.

DNSクライアントとサーバーは、クリアテキストDNSメッセージの転送にポート853を使用してはなりません（MUST NOT）。 DNSクライアントは送信してはならず（MUST NOT）、DNSサーバーはDNS over DTLSに使用されるポート上のクリアテキストDNSメッセージに応答してはなりません（たとえば、失敗したDTLSハンドシェイク後など）。保護されたデータと保護されていないデータの混在には、重大なセキュリティ問題があります。そのため、DNS over DTLS用に特定のサーバーによって指定されたポート上のUDP接続は、暗号化された通信のためだけに予約されています。

3.2. DTLS Handshake and Authentication

3.2. DTLSハンドシェイクと認証

The DNS client initiates the DTLS handshake as described in [RFC6347], following the best practices specified in [RFC7525]. After DTLS negotiation completes, if the DTLS handshake succeeds according to [RFC6347], the connection will be encrypted and would then be protected from eavesdropping.

DNSクライアントは、[RFC7525]で指定されたベストプラクティスに従って、[RFC6347]で説明されているようにDTLSハンドシェイクを開始します。 DTLSネゴシエーションが完了した後、[RFC6347]に従ってDTLSハンドシェイクが成功した場合、接続は暗号化され、盗聴から保護されます。

DNS privacy requires encrypting the query (and response) from passive attacks. Such encryption typically provides integrity protection as a side effect, which means on-path attackers cannot simply inject bogus DNS responses. However, to provide stronger protection from active attackers pretending to be the server, the server itself needs to be authenticated. To authenticate the server providing DNS privacy, DNS client MUST use the authentication mechanisms discussed in [DTLS]. This document does not propose new ideas for authentication.

DNSプライバシーでは、パッシブ攻撃からのクエリ（および応答）を暗号化する必要があります。このような暗号化は、通常、副作用として整合性保護を提供します。つまり、パス上の攻撃者は、偽のDNS応答を単に注入することはできません。ただし、サーバーを装ったアクティブな攻撃者からの保護を強化するには、サーバー自体を認証する必要があります。 DNSプライバシーを提供するサーバーを認証するには、DNSクライアントは[DTLS]で説明されている認証メカニズムを使用する必要があります。このドキュメントは、認証に関する新しいアイデアを提案していません。

3.3. Established Sessions

3.3. 確立されたセッション

In DTLS, all data is protected using the same record encoding and mechanisms. When the mechanism described in this document is in effect, DNS messages are encrypted using the standard DTLS record encoding. When a DTLS user wishes to send a DNS message, the data is delivered to the DTLS implementation as an ordinary application data write (e.g., SSL_write()). A single DTLS session can be used to send multiple DNS requests and receive multiple DNS responses.

DTLSでは、すべてのデータが同じレコードエンコーディングとメカニズムを使用して保護されます。このドキュメントで説明されているメカニズムが有効な場合、DNSメッセージは標準のDTLSレコードエンコーディングを使用して暗号化されます。 DTLSユーザーがDNSメッセージを送信したい場合、データは通常のアプリケーションデータ書き込み（SSL_write()など）としてDTLS実装に配信されます。単一のDTLSセッションを使用して、複数のDNS要求を送信し、複数のDNS応答を受信できます。

To mitigate the risk of unintentional server overload, DNS over DTLS clients MUST take care to minimize the number of concurrent DTLS sessions made to any individual server. For any given client/server interaction, it is RECOMMENDED that there be no more than one DTLS session. Similarly, servers MAY impose limits on the number of concurrent DTLS sessions 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 representing multiple resolvers on a single machine, or is representing multiple clients behind a device performing Network Address Translation (NAT).

意図しないサーバーの過負荷のリスクを軽減するために、DNS over DTLSクライアントは、個々のサーバーに対して同時に行われるDTLSセッションの数を最小限に抑えるように注意する必要があります。特定のクライアント/サーバー対話では、DTLSセッションは1つだけにすることをお勧めします。同様に、サーバーは、特定のクライアントIPアドレスまたはサブネットに対して処理される同時DTLSセッションの数に制限を課してもよい（MAY）。たとえば、クライアントのIPアドレスが単一のクライアントに属しているか、単一のマシン上の複数のリゾルバーを表しているか、または実行中のデバイスの背後にある複数のクライアントを表しているかをサーバーが認識していないためネットワークアドレス変換（NAT）。

In between normal DNS traffic, while the communication to the DNS server is quiescent, the DNS client MAY want to probe the server using DTLS heartbeat [RFC6520] to ensure it has maintained cryptographic state. Such probes can also keep alive firewall or NAT bindings. This probing reduces the frequency of needing a new handshake when a DNS query needs to be resolved, improving the user experience at the cost of bandwidth and processing time.

通常のDNSトラフィックの合間に、DNSサーバーへの通信が休止している間、DNSクライアントは、DTLSハートビート[RFC6520]を使用してサーバーをプローブし、暗号化状態を維持していることを確認できます。このようなプローブは、ファイアウォールまたはNATバインディングを存続させることもできます。このプローブにより、DNSクエリを解決する必要があるときに新しいハンドシェイクが必要になる頻度が減り、帯域幅と処理時間を犠牲にしてユーザーエクスペリエンスが向上します。

A DTLS session is terminated by the receipt of an authenticated message that closes the connection (e.g., a DTLS fatal alert). If the server has lost state, a DTLS handshake needs to be initiated with the server. For the server, to mitigate the risk of unintentional server overload, it is RECOMMENDED that the default DNS over DTLS server application-level idle time be set to several seconds and not set to less than a second, but no particular value is specified. When no DNS queries have been received from the client after idle timeout, the server MUST send a DTLS fatal alert and then destroy its DTLS state. The DTLS fatal alert packet indicates the server has destroyed its state, signaling to the client that if it wants to send a new DTLS message, it will need to re-establish cryptographic context with the server (via full DTLS handshake or DTLS session resumption). In practice, the idle period can vary dynamically, and servers MAY allow idle connections to remain open for longer periods as resources permit.

DTLSセッションは、接続を閉じる認証済みメッセージ（DTLSの致命的なアラートなど）を受信すると終了します。サーバーの状態が失われた場合、サーバーとのDTLSハンドシェイクを開始する必要があります。サーバーでは、意図しないサーバーの過負荷のリスクを軽減するために、デフォルトのDNS over DTLSサーバーのアプリケーションレベルのアイドル時間を数秒に設定し、1秒未満に設定しないことをお勧めしますが、特定の値は指定しません。アイドルタイムアウト後にクライアントからDNSクエリを受信していない場合、サーバーはDTLSの致命的なアラートを送信してから、DTLS状態を破棄する必要があります。 DTLSの致命的なアラートパケットは、サーバーがその状態を破棄したことを示し、新しいDTLSメッセージを送信する場合は、サーバーとの暗号化コンテキストを再確立する必要があることをクライアントに通知します（完全なDTLSハンドシェイクまたはDTLSセッションの再開により）。。実際には、アイドル期間は動的に変化する可能性があり、サーバーは、リソースが許す限り、アイドル接続をより長い期間開いたままにすることを許可する場合があります。

4. Performance Considerations

4. パフォーマンスに関する考慮事項

The DTLS protocol profile for DNS over DTLS is discussed in Section 11 of [DTLS]. To reduce the number of octets of the DTLS handshake, especially the size of the certificate in the ServerHello (which can be several kilobytes), DNS clients and servers can use raw public keys [RFC7250] or Cached Information Extension [RFC7924]. Cached Information Extension avoids transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake. TLS False Start [RFC7918] can reduce round trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) DNS query.

DNS over DTLSのDTLSプロトコルプロファイルは、[DTLS]のセクション11で説明されています。 DTLSハンドシェイクのオクテットの数、特にServerHelloの証明書のサイズ（数キロバイトになる場合があります）を減らすために、DNSクライアントとサーバーは生の公開鍵[RFC7250]またはCached Information Extension [RFC7924]を使用できます。 Cached Information Extensionは、クライアントが以前のTLSハンドシェイクからの情報をキャッシュした場合、サーバーの証明書と証明書チェーンの送信を回避します。 TLS False Start [RFC7918]は、TLSの2番目のメッセージフライト（ChangeCipherSpec）に（暗号化された）DNSクエリを含めることを許可することで、ラウンドトリップを削減できます。

It is highly advantageous to avoid server-side DTLS state and reduce the number of new DTLS sessions on the server that can be done with TLS Session Resumption without server state [RFC5077]. This also eliminates a round trip for subsequent DNS over DTLS queries, because with [RFC5077] the DTLS session does not need to be re-established.

サーバー側のDTLS状態を回避し、サーバー状態のないTLSセッション再開で実行できるサーバー上の新しいDTLSセッションの数を減らすことは非常に有利です[RFC5077]。また、[RFC5077]ではDTLSセッションを再確立する必要がないため、後続のDNS over DTLSクエリのラウンドトリップも不要になります。

Since responses within a DTLS session can arrive out of order, clients MUST match responses to outstanding queries on the same DTLS connection using the DNS 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 (Section 7 of [RFC7766]).

DTLSセッション内の応答は順不同で到着する可能性があるため、クライアントは、DNSメッセージIDを使用して、同じDTLS接続上の未解決のクエリへの応答を照合する必要があります。応答に質問セクションが含まれている場合、クライアントはQNAME、QCLASS、およびQTYPEフィールドと一致する必要があります。クライアントが未解決のクエリへの応答を適切に照合できないと、相互運用性に深刻な影響を与える可能性があります（[RFC7766]のセクション7）。

5. Path MTU (PMTU) Issues

5. パスMTU（PMTU）の問題

Compared to normal DNS, DTLS adds at least 13 octets of header, plus cipher and authentication overhead to every query and every response. This reduces the size of the DNS payload that can be carried. The DNS client and server MUST support the Extension Mechanisms for DNS (EDNS0) option defined in [RFC6891] so that the DNS client can indicate to the DNS server the maximum DNS response size it can reassemble and deliver in the DNS client's network stack. If the DNS client does set the EDNS0 option defined in [RFC6891], then the maximum DNS response size of 512 bytes plus DTLS overhead will be well within the Path MTU. If the Path MTU is not known, an IP MTU of 1280 bytes SHOULD be assumed. The client sets its EDNS0 value as if DTLS is not being used. The DNS server MUST ensure that the DNS response size does not exceed the Path MTU, i.e., each DTLS record MUST fit within a single datagram, as required by [RFC6347]. The DNS server must consider the amount of record expansion expected by the DTLS processing when calculating the size of DNS response that fits within the path MTU. The Path MTU MUST be greater than or equal to the DNS response size + DTLS overhead of 13 octets + padding size ([RFC7830]) + authentication overhead of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 of [RFC6347]). If the DNS server's response were to exceed that calculated value, the server MUST send a response that does fit within that value and sets the TC (truncated) bit. Upon receiving a response with the TC bit set and wanting to receive the entire response, the client behavior is governed by the current Usage Profile [DTLS]. For Strict Privacy, the client MUST only send a new DNS request for the same resource record over an encrypted transport (e.g., DNS over TLS [RFC7858]). Clients using Opportunistic Privacy SHOULD try for the best case (an encrypted and authenticated transport) but MAY fall back to intermediate cases and eventually the worst case scenario (clear text) in order to obtain a response.

通常のDNSと比較して、DTLSは少なくとも13オクテットのヘッダーに加えて、すべてのクエリとすべての応答に暗号と認証のオーバーヘッドを追加します。これにより、運ぶことができるDNSペイロードのサイズが小さくなります。 DNSクライアントとサーバーは、[RFC6891]で定義されているDNSの拡張メカニズム（EDNS0）オプションをサポートする必要があるため、DNSクライアントは、再構築してDNSクライアントのネットワークスタックで配信できる最大DNS応答サイズをDNSサーバーに示すことができます。 DNSクライアントが[RFC6891]で定義されているEDNS0オプションを設定する場合、512バイトの最大DNS応答サイズとDTLSオーバーヘッドは、パスMTU内に十分収まります。パスMTUが不明な場合は、1280バイトのIP MTUを想定する必要があります（SHOULD）。クライアントは、DTLSが使用されていないかのようにEDNS0値を設定します。 DNSサーバーは、DNS応答サイズがパスMTUを超えないようにする必要があります。つまり、[RFC6347]で要求されているように、各DTLSレコードは単一のデータグラム内に収まる必要があります。 DNSサーバーは、パスMTUに適合するDNS応答のサイズを計算するときに、DTLS処理によって予期されるレコード拡張の量を考慮する必要があります。パスMTUは、DNS応答サイズ+ 13オクテットのDTLSオーバーヘッド+パディングサイズ（[RFC7830]）+ネゴシエートされたDTLS暗号スイートの認証オーバーヘッド+ブロックパディング（[RFC6347]のセクション4.1.1.1）以上である必要があります。。 DNSサーバーの応答がその計算された値を超える場合、サーバーはその値に収まる応答を送信し、TC（切り捨て）ビットを設定する必要があります。 TCビットが設定された応答を受信し、応答全体を受信したい場合、クライアントの動作は、現在の使用プロファイル[DTLS]によって制御されます。厳格なプライバシーの場合、クライアントは、暗号化されたトランスポート（たとえば、DNS over TLS [RFC7858]）を介して同じリソースレコードに対する新しいDNSリクエストのみを送信する必要があります。 Opportunistic Privacyを使用するクライアントは、最良のケース（暗号化および認証されたトランスポート）を試行する必要がありますが、応答を取得するために、中間ケースにフォールバックし、最終的には最悪のケースのシナリオ（クリアテキスト）にフォールバックできます（MAY）。

6. Anycast

6. エニーキャスト

DNS servers are often configured with anycast addresses. While the network is stable, packets transmitted from a particular source to an anycast address will reach the same server that has the cryptographic context from the DNS over DTLS handshake. But, when the network configuration or routing changes, a DNS over DTLS packet can be received by a server that does not have the necessary cryptographic context. Clients using DNS over DTLS need to always be prepared to re-initiate the DTLS handshake, and in the worst case this could even happen immediately after re-initiating a new handshake. To encourage the client to initiate a new DTLS handshake, DNS servers SHOULD generate a DTLS fatal alert message in response to receiving a DTLS packet for which the server does not have any cryptographic context. Upon receipt of an unauthenticated DTLS fatal alert, the DTLS client validates the fatal alert is within the replay window (Section 4.1.2.6 of [RFC6347]). It is difficult for the DTLS client to validate that the DTLS fatal alert was generated by the DTLS server in response to a request or was generated by an on- or off-path attacker. Thus, upon receipt of an in-window DTLS fatal alert, the client SHOULD continue retransmitting the DTLS packet (in the event the fatal alert was spoofed), and at the same time it SHOULD initiate DTLS session resumption. When the DTLS client receives an authenticated DNS response from one of those DTLS sessions, the other DTLS session should be terminated.

DNSサーバーは多くの場合、エニーキャストアドレスで構成されます。ネットワークが安定している間、特定のソースからエニーキャストアドレスに送信されたパケットは、DNS over DTLSハンドシェイクからの暗号化コンテキストを持つ同じサーバーに到達します。ただし、ネットワーク構成またはルーティングが変更されると、必要な暗号化コンテキストを持たないサーバーがDNS over DTLSパケットを受信する可能性があります。 DNS over DTLSを使用するクライアントは、DTLSハンドシェイクを再開できるように常に準備する必要があり、最悪の場合、これは新しいハンドシェイクを再開した直後に発生することさえあります。クライアントが新しいDTLSハンドシェイクを開始することを奨励するために、DNSサーバーは、サーバーに暗号化コンテキストがないDTLSパケットの受信に応答して、DTLS致命的な警告メッセージを生成する必要があります（SHOULD）。 DTLSクライアントは、認証されていないDTLSの致命的なアラートを受信すると、致命的なアラートが再生ウィンドウ内にあることを検証します（[RFC6347]のセクション4.1.2.6）。 DTLSクライアントが要求に応じてDTLSサーバーによって生成された、またはパス上またはパス外の攻撃者によって生成されたDTLS致命的なアラートを検証することは困難です。したがって、ウィンドウ内のDTLSの致命的なアラートを受信すると、クライアントはDTLSパケットの再送信を継続し（致命的なアラートがスプーフィングされた場合）、同時にDTLSセッションの再開を開始する必要があります（SHOULD）。 DTLSクライアントがこれらのDTLSセッションの1つから認証済みのDNS応答を受信すると、他のDTLSセッションを終了する必要があります。

7. Usage

7. 使用法

Two Usage Profiles, Strict and Opportunistic, are explained in [DTLS]. The order of preference for DNS usage is as follows:

[DTLS]では、厳格と日和見の2つの使用プロファイルが説明されています。 DNS使用の優先順位は次のとおりです。

1. Encrypted DNS messages with an authenticated server

1. 認証されたサーバーによる暗号化されたDNSメッセージ

2. Encrypted DNS messages with an unauthenticated server

2. 認証されていないサーバーでの暗号化されたDNSメッセージ

3. Plaintext DNS messages

3. プレーンテキストDNSメッセージ

8. IANA Considerations

8. IANAに関する考慮事項

This specification uses port 853 already allocated in the IANA port number registry as defined in Section 6 of [RFC7858].

この仕様では、[RFC7858]のセクション6で定義されているIANAポート番号レジストリにすでに割り当てられているポート853を使用します。

9. Security Considerations

9. セキュリティに関する考慮事項

The interaction between a DNS client and a DNS server requires Datagram Transport Layer Security (DTLS) with a ciphersuite offering confidentiality protection. The guidance given in [RFC7525] MUST be followed to avoid attacks on DTLS. The DNS client SHOULD use the TLS Certificate Status Request extension (Section 8 of [RFC6066]), commonly called "OCSP stapling" to check the revocation status of the public key certificate of the DNS server. OCSP stapling, unlike OCSP [RFC6960], does not suffer from scale and privacy issues. DNS clients keeping track of servers known to support DTLS enables clients to detect downgrade attacks. To interfere with DNS over DTLS, an on- or off-path attacker might send an ICMP message towards the DTLS client or DTLS server. As these ICMP messages cannot be authenticated, all ICMP errors should be treated as soft errors [RFC1122]. If the DNS query was sent over DTLS, then the corresponding DNS response MUST only be accepted if it is received over the same DTLS connection. This behavior mitigates all possible attacks described in Measures for Making DNS More Resilient against Forged Answers [RFC5452]. The security considerations in [RFC6347] and [DTLS] are to be taken into account.

DNSクライアントとDNSサーバー間の対話には、機密保護を提供する暗号スイートを備えたデータグラムトランスポート層セキュリティ（DTLS）が必要です。 [RFC7525]で提供されたガイダンスは、DTLSへの攻撃を回避するために従わなければなりません。 DNSクライアントは、一般に「OCSPステープリング」と呼ばれるTLS証明書ステータス要求拡張（[RFC6066]のセクション8）を使用して、DNSサーバーの公開鍵証明書の失効ステータスを確認する必要があります（SHOULD）。 OCSP [RFC6960]とは異なり、OCSPステープリングは、スケールやプライバシーの問題に悩まされることはありません。 DTLSをサポートすることがわかっているサーバーを追跡しているDNSクライアントは、クライアントがダウングレード攻撃を検出できるようにします。 DNS over DTLSを妨害するために、パス上またはパス外の攻撃者がICMPメッセージをDTLSクライアントまたはDTLSサーバーに送信する可能性があります。これらのICMPメッセージは認証できないため、すべてのICMPエラーはソフトエラーとして処理する必要があります[RFC1122]。 DNSクエリがDTLS経由で送信された場合、対応するDNS応答は、同じDTLS接続経由で受信された場合にのみ受け入れられる必要があります。この動作は、偽造された回答に対するDNSの回復力を高めるための対策[RFC5452]で説明されているすべての可能な攻撃を軽減します。 [RFC6347]と[DTLS]のセキュリティに関する考慮事項が考慮されます。

A malicious client might attempt to perform a high number of DTLS handshakes with a server. As the clients are not uniquely identified by the protocol and can be obfuscated with IPv4 address sharing and with IPv6 temporary addresses, a server needs to mitigate the impact of such an attack. Such mitigation might involve rate limiting handshakes from a certain subnet or more advanced DoS/DDoS techniques beyond the scope of this document.

悪意のあるクライアントが、サーバーで多数のDTLSハンドシェイクを実行しようとする可能性があります。クライアントはプロトコルによって一意に識別されず、IPv4アドレス共有とIPv6一時アドレスで難読化される可能性があるため、サーバーはこのような攻撃の影響を軽減する必要があります。このような緩和策には、特定のサブネットからのレート制限ハンドシェイクや、このドキュメントの範囲を超える、より高度なDoS / DDoSテクニックが含まれる場合があります。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

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

[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 Securityの紹介と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.

[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without server-Side State」、RFC 5077、DOI 10.17487 / RFC5077、January 2008、 <http://www.rfc-editor.org/info/rfc5077>。

[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, <http://www.rfc-editor.org/info/rfc5452>.

[RFC5452] Hubert、A.およびR. van Mook、「DNSを偽造された回答に対してより弾力的にするための対策」、RFC 5452、DOI 10.17487 / RFC5452、2009年1月、<http://www.rfc-editor.org/info / rfc5452>。

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.

[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。

[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <http://www.rfc-editor.org/info/rfc6520>.

[RFC6520] Seggelmann、R.、Tuexen、M。、およびM. Williams、「Transport Layer Security（TLS）and Datagram Transport Layer Security（DTLS）Heartbeat Extension」、RFC 6520、DOI 10.17487 / RFC6520、2012年2月、<http ：//www.rfc-editor.org/info/rfc6520>。

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

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.

[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。

[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <http://www.rfc-editor.org/info/rfc7830>.

[RFC7830] Mayrhofer、A。、「The EDNS（0）Padding Option」、RFC 7830、DOI 10.17487 / RFC7830、May 2016、<http://www.rfc-editor.org/info/rfc7830>。

10.2. Informative References

10.2. 参考引用

[DTLS] Dickinson, S., Gillmor, D., and T. Reddy, "Authentication and (D)TLS Profile for DNS-over-(D)TLS", Work in Progress, draft-ietf-dprive-dtls-and-tls-profiles-08, January 2017.

[DTLS] Dickinson、S.、Gillmor、D。、およびT. Reddy、「Authentication and（D）TLS Profile for DNS-over-（D）TLS」、Work in Progress、draft-ietf-dprive-dtls-and -tls-profiles-08、2017年1月。

[DTLS13] Rescorla, E. and H. Tschofenig, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, draft-rescorla-tls-dtls13-00, October 2016.

[DTLS13] Rescorla、E。およびH. Tschofenig、「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」、作業中、draft-rescorla-tls-dtls13-00、2016年10月。

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.

[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.

[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<http://www.rfc-editor.org/info/rfc6066> 。

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.

[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。

[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <http://www.rfc-editor.org/info/rfc6960>.

[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、and C. Adams、 "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP"、RFC 6960、DOI 10.17487 / RFC6960、2013年6月、<http://www.rfc-editor.org/info/rfc6960>。

[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <http://www.rfc-editor.org/info/rfc7250>.

[RFC7250] Wouters、P.、Ed。、Tschofenig、H.、Ed。、Gilmore、J.、Weiler、S.、and T. Kivinen、 "Using Raw Public Keys in Transport Layer Security（TLS）and Datagram Transport Layerセキュリティ（DTLS）」、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<http://www.rfc-editor.org/info/rfc7250>。

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

[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <http://www.rfc-editor.org/info/rfc7626>.

[RFC7626] Bortzmeyer、S。、「DNSプライバシーに関する考慮事項」、RFC 7626、DOI 10.17487 / RFC7626、2015年8月、<http://www.rfc-editor.org/info/rfc7626>。

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

[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, <http://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月、<http://www.rfc-editor.org/info/rfc7858>。

[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <http://www.rfc-editor.org/info/rfc7918>.

[RFC7918] Langley、A.、Modadugu、N。、およびB. Moeller、「Transport Layer Security（TLS）False Start」、RFC 7918、DOI 10.17487 / RFC7918、2016年8月、<http：//www.rfc-editor .org / info / rfc7918>。

[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <http://www.rfc-editor.org/info/rfc7924>.

[RFC7924] Santesson、S。およびH. Tschofenig、「Transport Layer Security（TLS）Cached Information Extension」、RFC 7924、DOI 10.17487 / RFC7924、2016年7月、<http://www.rfc-editor.org/info/ rfc7924>。

Acknowledgements

謝辞

Thanks to Phil Hedrick for his review comments on TCP and to Josh Littlefield for pointing out DNS over DTLS load on busy servers (most notably root servers). The authors would like to thank Simon Josefsson, Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara Dickinson, Christian Huitema, Stephane Bortzmeyer, Alexander Mayrhofer, Allison Mankin, Jouni Korhonen, Stephen Farrell, Mirja Kuehlewind, Benoit Claise, and Geoff Huston for discussions and comments on the design of DNS over DTLS. The authors would like to give special thanks to Sara Dickinson for her help.

TCPに関するレビューコメントを提供してくれたPhil Hedrickと、忙しいサーバー（特にルートサーバー）でのDNS over DTLSの負荷を指摘してくれたJosh Littlefieldに感謝します。著者は、Simon Josefsson、Daniel Kahn Gillmor、Bob Harold、Ilari Liusvaara、Sara Dickinson、Christian Huitema、Stephane Bortzmeyer、Alexander Mayrhofer、Allison Mankin、Jouni Korhonen、Stephen Farrell、Mirja Kuehlewind、Benoit Claise、Geoff Hustonに感謝します。 DNS over DTLSの設計に関する議論とコメント。著者は彼女の助けのためにサラ・ディキンソンに特に感謝したいと思います。

Authors' Addresses

著者のアドレス

Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India

Tirumaleswar Reddy Cisco Systems、Inc. Cessna Business Park、Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka 560103 India

   Email: tireddy@cisco.com

Dan Wing

ダンウイング|

   Email: dwing-ietf@fuggles.com

Prashanth Patil Cisco Systems, Inc.

Prashanth Patil Cisco Systems、Inc.

   Email: praspati@cisco.com