[要約] RFC 7858は、DNS over TLSの仕様を定めたものであり、DNSトラフィックのセキュリティとプライバシーを向上させることを目的としています。
Internet Engineering Task Force (IETF) Z. Hu
Request for Comments: 7858 L. Zhu
Category: Standards Track J. Heidemann
ISSN: 2070-1721 USC/ISI
A. Mankin
Independent
D. Wessels
Verisign Labs
P. Hoffman
ICANN
May 2016
Specification for DNS over Transport Layer Security (TLS)
DNS over Transport Layer Security（TLS）の仕様
Abstract
概要
This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.
このドキュメントでは、DNSにプライバシーを提供するためのトランスポート層セキュリティ（TLS）の使用について説明します。 TLSによって提供される暗号化は、RFC 7626で説明されているように、ネットワーク内のDNSクエリによる盗聴やパス上での改ざんの機会を排除します。さらに、このドキュメントでは、TLSを介したDNSの2つの使用プロファイルを指定し、パフォーマンスの考慮事項に関するアドバイスを提供して、 DNSでTCPおよびTLSを使用します。
This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.
このドキュメントでは、DPRIVEワーキンググループの憲章に従って、スタブから再帰へのトラフィックの保護に焦点を当てています。再帰的から権限のあるトラフィックへのプロトコルの将来のアプリケーションを妨げません。
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/rfc7858.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7858で入手できます。
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. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. TLS Handshake and Authentication . . . . . . . . . . . . 5
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5
3.4. Connection Reuse, Close, and Reestablishment . . . . . . 6
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
4.2. Out-of-Band Key-Pinned Privacy Profile . . . . . . . . . 7
5. Performance Considerations . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Out-of-Band Key-Pinned Privacy Profile Example . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Today, nearly all DNS queries [RFC1034] [RFC1035] are sent unencrypted, which makes them vulnerable to eavesdropping by an attacker that has access to the network channel, reducing the privacy of the querier. Recent news reports have elevated these concerns, and recent IETF work has specified privacy considerations for DNS [RFC7626].
今日、ほとんどすべてのDNSクエリ[RFC1034] [RFC1035]は暗号化されずに送信されるため、ネットワークチャネルにアクセスできる攻撃者による盗聴に対して脆弱になり、クエリアのプライバシーが低下します。最近のニュースレポートではこれらの懸念が高まり、最近のIETFの作業ではDNSのプライバシーに関する考慮事項が規定されています[RFC7626]。
Prior work has addressed some aspects of DNS security, but until recently, there has been little work on privacy between a DNS client and server. DNS Security Extensions (DNSSEC) [RFC4033] provide _response integrity_ by defining mechanisms to cryptographically sign zones, allowing end users (or their first-hop resolver) to verify replies are correct. By intention, DNSSEC does not protect request and response privacy. Traditionally, either privacy was not considered a requirement for DNS traffic or it was assumed that network traffic was sufficiently private; however, these perceptions are evolving due to recent events [RFC7258].
以前の作業はDNSセキュリティのいくつかの側面に対処していましたが、最近まで、DNSクライアントとサーバー間のプライバシーに関する作業はほとんどありませんでした。 DNS Security Extensions（DNSSEC）[RFC4033]は、ゾーンに暗号で署名するメカニズムを定義することにより、_応答整合性_を提供し、エンドユーザー（またはその最初のホップのリゾルバー）が応答が正しいことを確認できるようにします。意図的に、DNSSECは要求と応答のプライバシーを保護しません。従来、プライバシーはDNSトラフィックの要件とは見なされていなかったか、ネットワークトラフィックは十分にプライベートであると想定されていました。しかしながら、これらの認識は最近の出来事のために進化しています[RFC7258]。
Other work that has offered the potential to encrypt between DNS clients and servers includes DNSCurve [DNSCurve], DNSCrypt [DNSCRYPT-WEBSITE], Confidential DNS [CONFIDENTIAL-DNS], and IPSECA [IPSECA]. In addition to the present specification, the DPRIVE Working Group has also adopted a proposal for DNS over Datagram Transport Layer Security (DTLS) [DNSoD].
DNSクライアントとサーバー間の暗号化の可能性を提供してきた他の作業には、DNSCurve [DNSCurve]、DNSCrypt [DNSCRYPT-WEBSITE]、機密DNS [CONFIDENTIAL-DNS]、およびIPSECA [IPSECA]が含まれます。現在の仕様に加えて、DPRIVEワーキンググループは、DNS over Datagram Transport Layer Security（DTLS）[DNSoD]の提案も採用しています。
This document describes using DNS over TLS on a well-known port and also offers advice on performance considerations to minimize overheads from using TCP and TLS with DNS.
このドキュメントでは、well-knownポートでのDNS over TLSの使用について説明し、DNSでTCPおよびTLSを使用することによるオーバーヘッドを最小限に抑えるためのパフォーマンスの考慮事項についてのアドバイスも提供します。
Initiation of DNS over TLS is very straightforward. By establishing a connection over a well-known port, clients and servers expect and agree to negotiate a TLS session to secure the channel. Deployment will be gradual. Not all servers will support DNS over TLS and the well-known port might be blocked by some firewalls. Clients will be expected to keep track of servers that support TLS and those that don't. Clients and servers will adhere to the TLS implementation recommendations and security considerations of [BCP195].
DNS over TLSの開始は非常に簡単です。ウェルノウンポートを介して接続を確立することにより、クライアントとサーバーはTLSセッションをネゴシエートしてチャネルを保護することを期待して同意します。展開は段階的に行われます。すべてのサーバーがDNS over TLSをサポートするわけではなく、既知のポートが一部のファイアウォールによってブロックされる可能性があります。クライアントは、TLSをサポートするサーバーとサポートしないサーバーを追跡することが期待されます。クライアントとサーバーは、[BCP195]のTLS実装の推奨事項とセキュリティの考慮事項に準拠します。
The protocol described here works for queries and responses between stub clients and recursive servers. It 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.
ここで説明するプロトコルは、スタブクライアントと再帰サーバー間のクエリと応答で機能します。再帰的なクライアントと権限のあるサーバー間で同等に機能する可能性がありますが、このプロトコルのアプリケーションは、現在の憲章ではDNS PRIVate Exchange（DPRIVE）ワーキンググループの対象外です。
This document describes two profiles in Section 4 that provide different levels of assurance of privacy: an opportunistic privacy profile and an out-of-band key-pinned privacy profile. It is expected that a future document based on [TLS-DTLS-PROFILES] will further describe additional privacy profiles for DNS over both TLS and DTLS.
このドキュメントでは、異なるレベルのプライバシー保証を提供するセクション4の2つのプロファイルについて説明します。日和見プライバシープロファイルと、帯域外キー固定プライバシープロファイルです。 [TLS-DTLS-PROFILES]に基づく将来の文書では、TLSとDTLSの両方を介したDNSの追加のプライバシープロファイルについてさらに説明することが期待されています。
An earlier draft version of this document described a technique for upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, essentially, "STARTTLS for DNS". To simplify the protocol, this document now only uses a well-known port to specify TLS use, omitting the upgrade approach. The upgrade approach no longer appears in this document, which now focuses exclusively on the use of a well-known port for DNS over TLS.
このドキュメントの以前のドラフトバージョンでは、本質的に「DNSのSTARTTLS」を使用して、DNS-over-TCP接続をDNS-over-TLSセッションにアップグレードする方法について説明しました。プロトコルを簡略化するために、このドキュメントでは、既知のポートのみを使用してTLSの使用を指定し、アップグレードアプローチを省略しています。アップグレードアプローチはこのドキュメントには記載されておらず、DNS over TLSの既知のポートの使用にのみ焦点を当てています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
By default, a DNS server that supports DNS over TLS MUST listen for and accept TCP connections on port 853, unless it has mutual agreement with its clients to use a port other than 853 for DNS over TLS. In order to use a port other than 853, both clients and servers would need a configuration option in their software.
デフォルトでは、DNS over TLSをサポートするDNSサーバーは、クライアントと相互に合意して、DNS over TLSに853以外のポートを使用する場合を除き、ポート853でTCP接続をリッスンして受け入れる必要があります。 853以外のポートを使用するには、クライアントとサーバーの両方でソフトウェアの構成オプションが必要になります。
By default, a DNS client desiring privacy from DNS over TLS from a particular server MUST establish a TCP connection 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 TLS. Such another port MUST NOT be port 53 but MAY be from the "first-come, first-served" port range. This recommendation against use of port 53 for DNS over TLS is to avoid complication in selecting use or non-use of TLS and to reduce risk of downgrade attacks. The first data exchange on this TCP connection MUST be the client and server initiating a TLS handshake using the procedure described in [RFC5246].
デフォルトでは、特定のサーバーからのDNS over TLSからのプライバシーを要求するDNSクライアントは、サーバーと相互に合意して、DNS over TLSにポート853以外のポートを使用する場合を除き、サーバーのポート853へのTCP接続を確立する必要があります。そのような別のポートはポート53であってはなりませんが、「先着順」のポート範囲からのものである場合があります。 TLS over DNSにポート53を使用しないことに対するこの推奨事項は、TLSの使用または非使用を選択する際の複雑さを回避し、ダウングレード攻撃のリスクを軽減するためです。このTCP接続での最初のデータ交換は、[RFC5246]で説明されている手順を使用してTLSハンドシェイクを開始するクライアントとサーバーでなければなりません（MUST）。
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 TLS (including, for example, after a failed TLS handshake). There are significant security issues in mixing protected and unprotected data, and for this reason, TCP connections on a port designated by a given server for DNS over TLS are reserved purely for encrypted communications.
DNSクライアントとサーバーは、クリアテキストDNSメッセージの転送にポート853を使用してはなりません（MUST NOT）。 DNSクライアントは送信してはならず（MUST NOT）、DNSサーバーはDNS over TLSに使用されるポートのクリアテキストDNSメッセージに応答してはなりません（たとえば、失敗したTLSハンドシェイク後を含む）。保護されたデータと保護されていないデータの混在には重大なセキュリティ上の問題があるため、DNS over TLSの特定のサーバーによって指定されたポート上のTCP接続は、暗号化された通信のためにのみ予約されています。
DNS clients SHOULD remember server IP addresses that don't support DNS over TLS, including timeouts, connection refusals, and TLS handshake failures, and not request DNS over TLS from them for a reasonable period (such as one hour per server). DNS clients following an out-of-band key-pinned privacy profile (Section 4.2) MAY be more aggressive about retrying DNS-over-TLS connection failures.
DNSクライアントは、タイムアウト、接続拒否、TLSハンドシェイクの失敗など、DNS over TLSをサポートしていないサーバーIPアドレスを記憶し、妥当な期間（サーバーごとに1時間など）DNS over TLSを要求しないようにする必要があります。アウトオブバンドキー固定プライバシープロファイル（セクション4.2）に従うDNSクライアントは、DNS-over-TLS接続失敗の再試行についてより積極的になる場合があります。
Once the DNS client succeeds in connecting via TCP on the well-known port for DNS over TLS, it proceeds with the TLS handshake [RFC5246], following the best practices specified in [BCP195].
DNSクライアントは、DNS over TLSの既知のポートでTCPを介した接続に成功すると、[BCP195]で指定されたベストプラクティスに従って、TLSハンドシェイク[RFC5246]に進みます。
The client will then authenticate the server, if required. This document does not propose new ideas for authentication. Depending on the privacy profile in use (Section 4), the DNS client may choose not to require authentication of the server, or it may make use of a trusted Subject Public Key Info (SPKI) Fingerprint pin set.
その後、クライアントは必要に応じてサーバーを認証します。このドキュメントは、認証に関する新しいアイデアを提案していません。使用中のプライバシープロファイル（セクション4）に応じて、DNSクライアントはサーバーの認証を要求しないことを選択したり、信頼されたサブジェクトの公開キー情報（SPKI）フィンガープリントピンセットを利用したりできます。
After TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping.
TLSネゴシエーションが完了すると、接続は暗号化され、盗聴から保護されます。
All messages (requests and responses) in the established TLS session MUST use the two-octet length field described in Section 4.2.2 of [RFC1035]. For reasons of efficiency, 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 ([RFC7766], Section 8).
確立されたTLSセッションのすべてのメッセージ（要求と応答）は、[RFC1035]のセクション4.2.2で説明されている2オクテットの長さフィールドを使用する必要があります。効率上の理由から、DNSクライアントとサーバーは、2オクテットの長さフィールドと、その長さフィールドによって記述されたメッセージを同時に（たとえば、単一の「書き込み」システムコールで）TCPレイヤーに渡してそれを作成する必要があります（SHOULD）。すべてのデータが単一のTCPセグメントで送信される可能性が高くなります（[RFC7766]、セクション8）。
In order to minimize latency, clients SHOULD pipeline multiple queries over a TLS session. When a DNS client sends multiple queries to a server, it should not wait for an outstanding reply before sending the next query ([RFC7766], Section 6.2.1.1).
レイテンシを最小限に抑えるために、クライアントはTLSセッションを介して複数のクエリをパイプライン処理する必要があります（SHOULD）。 DNSクライアントがサーバーに複数のクエリを送信する場合、次のクエリを送信する前に未解決の応答を待つべきではありません（[RFC7766]、セクション6.2.1.1）。
Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TLS 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 ([RFC7766], Section 7).
パイプライン化された応答は順不同で到着する可能性があるため、クライアントは、メッセージIDを使用して、同じTLS接続で未解決のクエリへの応答を照合する必要があります。応答に質問セクションが含まれている場合、クライアントはQNAME、QCLASS、およびQTYPEフィールドと一致する必要があります。クライアントが未解決のクエリへの応答を適切に照合できないと、相互運用性に深刻な影響を与える可能性があります（[RFC7766]、セクション7）。
For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()", current implementations are known to open and close TCP connections for each DNS query. To avoid excess TCP connections, each with a single query, clients SHOULD reuse a single TCP connection to the recursive resolver. Alternatively, they may prefer to use UDP to a DNS-over-TLS-enabled caching resolver on the same machine that then uses a system-wide TCP connection to the recursive resolver.
「getaddrinfo()」や「gethostbyname()」などのライブラリ関数を使用するDNSクライアントの場合、現在の実装では、各DNSクエリのTCP接続を開いたり閉じたりすることが知られています。それぞれが単一のクエリを持つ過剰なTCP接続を回避するために、クライアントは再帰リゾルバへの単一のTCP接続を再利用する必要があります（SHOULD）。あるいは、同じマシンでDNS-over-TLSが有効なキャッシングリゾルバーにUDPを使用してから、再帰リゾルバーへのシステム全体のTCP接続を使用することを好む場合もあります。
In order to amortize TCP and TLS connection setup costs, clients and servers SHOULD NOT immediately close a connection after each response. Instead, clients and servers SHOULD reuse existing connections for subsequent queries as long as they have sufficient resources. In some cases, this means that clients and servers may need to keep idle connections open for some amount of time.
TCPとTLSの接続設定コストを償却するために、クライアントとサーバーは、各応答の後に接続をすぐに閉じないでください。代わりに、クライアントとサーバーは、十分なリソースがある限り、後続のクエリで既存の接続を再利用する必要があります。場合によっては、これはクライアントとサーバーがアイドル接続を開いたままにしておく必要があることを意味します。
Proper management of established and idle connections is important to the healthy operation of a DNS server. An implementor of DNS over TLS SHOULD follow best practices for DNS over TCP, as described in [RFC7766]. Failure to do so may lead to resource exhaustion and denial of service.
確立された接続とアイドル接続の適切な管理は、DNSサーバーの正常な動作にとって重要です。 [RFC7766]で説明されているように、DNS over TLSの実装者は、DNS over TCPのベストプラクティスに従う必要があります（SHOULD）。そうしないと、リソースが使い果たされ、サービスが拒否される可能性があります。
Whereas client and server implementations from the era of [RFC1035] are known to have poor TCP connection management, this document stipulates that successful negotiation of TLS indicates the willingness of both parties to keep idle DNS connections open, independent of timeouts or other recommendations for DNS over TCP without TLS. In other words, software implementing this protocol is assumed to support idle, persistent connections and be prepared to manage multiple, potentially long-lived TCP connections.
[RFC1035]時代のクライアントとサーバーの実装ではTCP接続管理が不十分であることが知られていますが、このドキュメントでは、TLSのネゴシエーションが成功すると、タイムアウトやDNSのその他の推奨事項とは無関係に、両方の当事者がアイドルDNS接続を開いたままにする意欲があることが示されますTLSなしのTCP経由。つまり、このプロトコルを実装するソフトウェアは、アイドル状態の永続的な接続をサポートし、複数の潜在的に長命のTCP接続を管理する準備ができていると想定されます。
This document does not make specific recommendations for timeout values on idle connections. Clients and servers should reuse and/or close connections depending on the level of available resources. Timeouts may be longer during periods of low activity and shorter during periods of high activity. Current work in this area may also assist DNS-over-TLS clients and servers in selecting useful timeout values [RFC7828] [TDNS].
このドキュメントでは、アイドル接続のタイムアウト値について特定の推奨事項は行いません。クライアントとサーバーは、使用可能なリソースのレベルに応じて、接続を再利用またはクローズする必要があります。タイムアウトは、アクティビティの少ない期間では長く、アクティビティの多い期間では短くなる場合があります。この領域での現在の作業は、DNS-over-TLSクライアントおよびサーバーが有用なタイムアウト値を選択する際にも役立ちます[RFC7828] [TDNS]。
Clients and servers that keep idle connections open MUST be robust to termination of idle connection by either party. As with current DNS over TCP, DNS servers MAY close the connection at any time (perhaps due to resource constraints). As with current DNS over TCP, clients MUST handle abrupt closes and be prepared to reestablish connections and/or retry queries.
アイドル接続を開いたままにするクライアントとサーバーは、いずれかの当事者によるアイドル接続の終了に対して堅牢でなければなりません。現在のDNS over TCPと同様に、DNSサーバーは（おそらくリソースの制約のため）いつでも接続を閉じることができます（MAY）。現在のDNS over TCPと同様に、クライアントは突然のクローズを処理し、接続の再確立やクエリの再試行に備える必要があります。
When reestablishing a DNS-over-TCP connection that was terminated, as discussed in [RFC7766], TCP Fast Open [RFC7413] is of benefit. Underlining the requirement for sending only encrypted DNS data on a DNS-over-TLS port (Section 3.2), when using TCP Fast Open, the client and server MUST immediately initiate or resume a TLS handshake (cleartext DNS MUST NOT be exchanged). DNS servers SHOULD enable fast TLS session resumption [RFC5077], and this SHOULD be used when reestablishing connections.
[RFC7766]で説明されているように、終了したDNS-over-TCP接続を再確立する場合、TCP Fast Open [RFC7413]が役立ちます。暗号化されたDNSデータのみをDNS-over-TLSポートで送信する要件（セクション3.2）を強調し、TCP Fast Openを使用する場合、クライアントとサーバーはTLSハンドシェイクを直ちに開始または再開する必要があります（クリアテキストDNSは交換してはなりません）。 DNSサーバーは高速TLSセッション再開を有効にする必要があります[RFC5077]。これは接続を再確立するときに使用する必要があります。
When closing a connection, DNS servers SHOULD use the TLS close-notify request to shift TCP TIME-WAIT state to the clients. Additional requirements and guidance for optimizing DNS over TCP are provided by [RFC7766].
接続を閉じるとき、DNSサーバーはTLSのclose-notifyリクエストを使用して、TCP TIME-WAIT状態をクライアントにシフトする必要があります（SHOULD）。 DNS over TCPを最適化するための追加の要件とガイダンスは、[RFC7766]によって提供されています。
This protocol provides flexibility to accommodate several different use cases. This document defines two usage profiles: (1) opportunistic privacy and (2) out-of-band key-pinned authentication that can be used to obtain stronger privacy guarantees if the client has a trusted relationship with a DNS server supporting TLS. Additional methods of authentication will be defined in a forthcoming document [TLS-DTLS-PROFILES].
このプロトコルは、いくつかの異なる使用例に対応する柔軟性を提供します。このドキュメントでは、（1）日和見プライバシーと（2）クライアントがTLSをサポートするDNSサーバーとの信頼関係を確立している場合に、より強力なプライバシーを保証するために使用できる帯域外キーピン認証の2つの使用プロファイルを定義します。追加の認証方法は、今後のドキュメント[TLS-DTLS-PROFILES]で定義されます。
For opportunistic privacy, analogous to SMTP opportunistic security [RFC7435], one does not require privacy, but one desires privacy when possible.
SMTP日和見セキュリティ[RFC7435]に類似した日和見プライバシーの場合、プライバシーは必要ありませんが、可能であればプライバシーを求めます。
With opportunistic privacy, a client might learn of a TLS-enabled recursive DNS resolver from an untrusted source. One possible example flow would be if the client used the DHCP DNS server option [RFC3646] to discover the IP address of a TLS-enabled recursive and then attempted DNS over TLS on port 853. With such a discovered DNS server, the client might or might not validate the resolver. These choices maximize availability and performance, but they leave the client vulnerable to on-path attacks that remove privacy.
日和見プライバシーにより、クライアントは信頼できないソースからTLS対応の再帰DNSリゾルバーを知る可能性があります。考えられるフローの例の1つは、クライアントがDHCP DNSサーバーオプション[RFC3646]を使用してTLS対応の再帰的なIPアドレスを検出し、ポート853でTLS over DNSを試行した場合です。このような検出されたDNSサーバーでは、クライアントはリゾルバーを検証しない可能性があります。これらの選択により、可用性とパフォーマンスが最大化されますが、クライアントは、プライバシーを削除するパス上攻撃に対して脆弱になります。
Opportunistic privacy can be used by any current client, but it only provides privacy when there are no on-path active attackers.
日和見プライバシーは、現在のどのクライアントでも使用できますが、パス上のアクティブな攻撃者がいない場合にのみプライバシーを提供します。
The out-of-band key-pinned privacy profile can be used in environments where an established trust relationship already exists between DNS clients and servers (e.g., stub-to-recursive in enterprise networks, actively maintained contractual service relationships, or a client using a public DNS resolver). The result of this profile is that the client has strong guarantees about the privacy of its DNS data by connecting only to servers it can authenticate. Operators of a DNS-over-TLS service in this profile are expected to provide pins that are specific to the service being pinned (i.e., public keys belonging directly to the end entity or to a service-specific private certificate authority (CA)) and not to a public key(s) of a generic public CA.
アウトオブバンドキー固定プライバシープロファイルは、DNSクライアントとサーバー間に確立された信頼関係が既に存在する環境で使用できます（たとえば、エンタープライズネットワークでのスタブと再帰、アクティブに維持された契約サービス関係、またはクライアントを使用するパブリックDNSリゾルバー）。このプロファイルの結果、クライアントは、認証できるサーバーにのみ接続することにより、DNSデータのプライバシーについて強力な保証を持ちます。このプロファイルのDNS-over-TLSサービスのオペレーターは、ピン留めされるサービスに固有のピン（つまり、エンドエンティティまたはサービス固有のプライベート認証局（CA）に直接属する公開鍵）を提供することが期待されています。一般的な公開CAの公開鍵には使用できません。
In this profile, clients authenticate servers by matching a set of SPKI Fingerprints in an analogous manner to that described in [RFC7469]. With this out-of-band key-pinned privacy profile, client administrators SHOULD deploy a backup pin along with the primary pin, for the reasons explained in [RFC7469]. A backup pin is especially helpful in the event of a key rollover, so that a server operator does not have to coordinate key transitions with all its clients simultaneously. After a change of keys on the server, an updated pin set SHOULD be distributed to all clients in some secure way in preparation for future key rollover. The mechanism for an out-of-band pin set update is out of scope for this document.
このプロファイルでは、クライアントは、[RFC7469]で説明されているのと同様の方法でSPKIフィンガープリントのセットを照合することにより、サーバーを認証します。 [RFC7469]で説明されている理由により、この帯域外のキー固定されたプライバシープロファイルを使用して、クライアント管理者はプライマリピンと共にバックアップピンを展開する必要があります（SHOULD）。バックアップピンは、キーのロールオーバーが発生した場合に特に役立ちます。これにより、サーバーオペレーターは、キーの遷移をすべてのクライアントと同時に調整する必要がなくなります。サーバーでキーを変更した後、更新されたピンセットを、将来のキーのロールオーバーに備えて安全な方法ですべてのクライアントに配布する必要があります（SHOULD）。アウトオブバンドピンセット更新のメカニズムは、このドキュメントの範囲外です。
Such a client will only use DNS servers for which an SPKI Fingerprint pin set has been provided. The possession of a trusted pre-deployed pin set allows the client to detect and prevent person-in-the-middle and downgrade attacks.
このようなクライアントは、SPKIフィンガープリントピンセットが提供されているDNSサーバーのみを使用します。信頼できる展開済みのピンセットを所有しているため、クライアントは中間者攻撃やダウングレード攻撃を検出して防止できます。
However, a configured DNS server may be temporarily unavailable when configuring a network. For example, for clients on networks that require authentication through web-based login, such authentication may rely on DNS interception and spoofing. Techniques such as those used by DNSSEC-trigger [DNSSEC-TRIGGER] MAY be used during network configuration, with the intent to transition to the designated DNS provider after authentication. The user MUST be alerted whenever possible that the DNS is not private during such bootstrap.
ただし、ネットワークを構成するときに、構成済みのDNSサーバーが一時的に使用できない場合があります。たとえば、Webベースのログインによる認証を必要とするネットワーク上のクライアントの場合、そのような認証はDNSインターセプトとスプーフィングに依存する場合があります。 DNSSEC-trigger [DNSSEC-TRIGGER]で使用されるようなテクニックは、認証後に指定されたDNSプロバイダーに移行することを目的として、ネットワーク構成中に使用される場合があります。このようなブートストラップ中は、DNSがプライベートではないことを可能な限りユーザーに通知する必要があります。
Upon successful TLS connection and handshake, the client computes the SPKI Fingerprints for the public keys found in the validated server's certificate chain (or in the raw public key, if the server provides that instead). If a computed fingerprint exactly matches one of the configured pins, the client continues with the connection as normal. Otherwise, the client MUST treat the SPKI validation failure as a non-recoverable error. Appendix A provides a detailed example of how this authentication could be performed in practice.
TLS接続とハンドシェイクが成功すると、クライアントは、検証済みサーバーの証明書チェーン（またはサーバーが代わりに提供する場合は生の公開鍵）にある公開鍵のSPKIフィンガープリントを計算します。計算されたフィンガープリントが構成済みのピンの1つと完全に一致する場合、クライアントは通常どおり接続を続行します。それ以外の場合、クライアントはSPKI検証の失敗を回復不可能なエラーとして処理する必要があります。付録Aは、この認証を実際に実行する方法の詳細な例を示しています。
Implementations of this privacy profile MUST support the calculation of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded ASN.1 representation of the SPKI of an X.509 certificate.
このプライバシープロファイルの実装は、X.509証明書のSPKIのDERエンコードされたASN.1表現のSHA-256 [RFC6234]ハッシュとしてのフィンガープリントの計算をサポートする必要があります。
Implementations MUST support the representation of a SHA-256 fingerprint as a base64-encoded character string [RFC4648]. Additional fingerprint types MAY also be supported.
実装は、base64でエンコードされた文字列[RFC4648]としてのSHA-256フィンガープリントの表現をサポートする必要があります。追加の指紋タイプもサポートされる場合があります。
DNS over TLS incurs additional latency at session startup. It also requires additional state (memory) and increased processing (CPU).
DNS over TLSでは、セッションの起動時に追加の遅延が発生します。また、追加の状態（メモリ）と増加した処理（CPU）も必要です。
Latency: Compared to UDP, DNS over TCP requires an additional round-trip time (RTT) of latency to establish a TCP connection. TCP Fast Open [RFC7413] can eliminate that RTT when information exists from prior connections. The TLS handshake adds another two RTTs of latency. Clients and servers should support connection keepalive (reuse) and out-of-order processing to amortize connection setup costs. Fast TLS connection resumption [RFC5077] further reduces the setup delay and avoids the DNS server keeping per-client session state.
待機時間：UDPと比較して、DNS over TCPでは、TCP接続を確立するために、追加の待機時間（RTT）の待機時間が必要です。 TCP Fast Open [RFC7413]は、以前の接続からの情報が存在する場合、そのRTTを排除できます。 TLSハンドシェイクにより、さらに2つのRTTの遅延が追加されます。クライアントとサーバーは、接続の設定コストを償却するために、接続のキープアライブ（再利用）と順序外の処理をサポートする必要があります。高速なTLS接続の再開[RFC5077]により、セットアップの遅延がさらに削減され、DNSサーバーがクライアントごとのセッション状態を維持することが回避されます。
TLS False Start [TLS-FALSESTART] can also lead to a latency reduction in certain situations. Implementations supporting TLS False Start need to be aware that it imposes additional constraints on how one uses TLS, over and above those stated in [BCP195]. It is unsafe to use False Start if your implementation and deployment does not adhere to these specific requirements. See [TLS-FALSESTART] for the details of these additional constraints.
TLS False Start [TLS-FALSESTART]は、特定の状況での待ち時間の短縮にもつながります。 TLS False Startをサポートする実装は、[BCP195]で述べられているものに加えて、TLSの使用方法に追加の制約を課すことに注意する必要があります。実装と展開がこれらの特定の要件に準拠していない場合、False Startを使用するのは危険です。これらの追加の制約の詳細については、[TLS-FALSESTART]を参照してください。
State: The use of connection-oriented TCP requires keeping additional state at the server in both the kernel and application. The state requirements are of particular concern on servers with many clients, although memory-optimized TLS can add only modest state over TCP. Smaller timeout values will reduce the number of concurrent connections, and servers can preemptively close connections when resource limits are exceeded.
状態：接続指向のTCPを使用するには、カーネルとアプリケーションの両方でサーバーの追加の状態を維持する必要があります。状態の要件は、多くのクライアントを持つサーバーで特に懸念されますが、メモリ最適化TLSはTCPを介して適度な状態しか追加できません。タイムアウト値を小さくすると、同時接続の数が減り、サーバーはリソース制限を超えたときに接続を事前に閉じることができます。
Processing: The use of TLS encryption algorithms results in slightly higher CPU usage. Servers can choose to refuse new DNS-over-TLS clients if processing limits are exceeded.
処理：TLS暗号化アルゴリズムを使用すると、CPU使用率がわずかに高くなります。サーバーは、処理制限を超えた場合に、新しいDNS-over-TLSクライアントを拒否することを選択できます。
Number of connections: To minimize state on DNS servers and connection startup time, clients SHOULD minimize the creation of new TCP connections. Use of a local DNS request aggregator (a particular type of forwarder) allows a single active DNS-over-TLS connection from any given client computer to its server. Additional guidance can be found in [RFC7766].
接続数：DNSサーバーの状態と接続の起動時間を最小限に抑えるために、クライアントは新しいTCP接続の作成を最小限に抑える必要があります（SHOULD）。ローカルDNS要求アグリゲーター（特定のタイプのフォワーダー）を使用すると、特定のクライアントコンピューターからサーバーへの単一のアクティブなDNS-over-TLS接続が可能になります。追加のガイダンスは[RFC7766]にあります。
A full performance evaluation is outside the scope of this specification. A more detailed analysis of the performance implications of DNS over TLS (and DNS over TCP) is discussed in [TDNS] and [RFC7766].
完全なパフォーマンス評価は、この仕様の範囲外です。 DNS over TLS（およびDNS over TCP）のパフォーマンスへの影響のより詳細な分析は、[TDNS]および[RFC7766]で説明されています。
IANA has added the following value to the "Service Name and Transport Protocol Port Number Registry" in the System Range. The registry for that range requires IETF Review or IESG Approval [RFC6335], and such a review was requested using the early allocation process [RFC7120] for the well-known TCP port in this document.
IANAは、システム範囲の「サービス名とトランスポートプロトコルのポート番号レジストリ」に次の値を追加しました。その範囲のレジストリには、IETFレビューまたはIESG承認[RFC6335]が必要です。このようなレビューは、このドキュメントの既知のTCPポートの初期割り当てプロセス[RFC7120]を使用して要求されました。
IANA has reserved the same port number over UDP for the proposed DNS-over-DTLS protocol [DNSoD].
IANAは、提案されているDNS-over-DTLSプロトコル[DNSoD]のために、UDPを介して同じポート番号を予約しています。
Service Name domain-s Port Number 853 Transport Protocol(s) TCP/UDP Assignee IESG Contact IETF Chair Description DNS query-response protocol run over TLS/DTLS Reference This document
サービス名domain-sポート番号853トランスポートプロトコルTCP / UDP譲受人IESG連絡先IETF議長説明TLS / DTLSリファレンス上で実行されるDNSクエリ応答プロトコルこのドキュメント
Earlier draft versions of this document proposed an upgrade-based approach to establish a TLS session. The client would signal its interest in TLS by setting a "TLS OK" bit in the Extensions Mechanisms for DNS (EDNS(0)) flags field. A server would signal its acceptance by responding with the TLS OK bit set.
このドキュメントの以前のドラフトバージョンでは、TLSセッションを確立するためのアップグレードベースのアプローチが提案されていました。クライアントは、DNSの拡張メカニズム（EDNS（0））フラグフィールドに「TLS OK」ビットを設定することで、TLSへの関心を示します。サーバーは、TLS OKビットを設定して応答することにより、その受け入れを通知します。
Since we assume the client doesn't want to reveal (leak) any information prior to securing the channel, we proposed the use of a "dummy query" that clients could send for this purpose. The proposed query name was STARTTLS, query type TXT, and query class CH.
クライアントがチャネルを保護する前に情報を公開（漏洩）したくないと想定しているため、この目的のためにクライアントが送信できる「ダミークエリ」の使用を提案しました。提案されたクエリ名は、STARTTLS、クエリタイプTXT、クエリクラスCHでした。
The TLS OK signaling approach has both advantages and disadvantages. One important advantage is that clients and servers could negotiate TLS. If the server is too busy, or doesn't want to provide TLS service to a particular client, it can respond negatively to the TLS probe. An ancillary benefit is that servers could collect information on adoption of DNS over TLS (via the TLS OK bit in queries) before implementation and deployment. Another anticipated advantage is the expectation that DNS over TLS would work over port 53. That is, no need to "waste" another port and deploy new firewall rules on middleboxes.
TLS OKシグナリングアプローチには、利点と欠点の両方があります。重要な利点の1つは、クライアントとサーバーがTLSをネゴシエートできることです。サーバーがビジー状態であるか、特定のクライアントにTLSサービスを提供したくない場合、サーバーはTLSプローブに否定的に応答できます。付随的な利点は、実装と展開の前に、サーバーがDNS over TLSの採用に関する情報を（クエリのTLS OKビットを介して）収集できることです。予想されるもう1つの利点は、DNS over TLSがポート53で機能することです。つまり、別のポートを「無駄」にして、ミドルボックスに新しいファイアウォールルールを展開する必要がありません。
However, at the same time, there was uncertainty whether or not middleboxes would pass the TLS OK bit, given that the EDNS0 flags field has been unchanged for many years. Another disadvantage is that the TLS OK bit may make downgrade attacks easy and indistinguishable from broken middleboxes. From a performance standpoint, the upgrade-based approach had the disadvantage of requiring 1xRTT additional latency for the dummy query.
ただし、同時に、EDNS0フラグフィールドが何年も変更されていないことを考えると、ミドルボックスがTLS OKビットを渡すかどうかは不確実でした。もう1つの欠点は、TLS OKビットによってダウングレード攻撃が容易になり、壊れたミドルボックスと区別がつかなくなる可能性があることです。パフォーマンスの観点から、アップグレードベースのアプローチには、ダミークエリに1xRTTの追加レイテンシが必要になるという欠点がありました。
Following this proposal, DNS over DTLS was proposed separately. DNS over DTLS claimed it could work over port 53, but only because a non-DTLS server interprets a DNS-over-DTLS query as a response. That is, the non-DTLS server observes the QR flag set to 1. While this technically works, it seems unfortunate and perhaps even undesirable.
この提案に続いて、DNS over DTLSが個別に提案されました。 DNS over DTLSは、ポート53で機能する可能性があると主張しましたが、これは非DTLSサーバーがDNS-over-DTLSクエリを応答として解釈するためです。つまり、DTLS以外のサーバーは、QRフラグが1に設定されていることを確認します。これは技術的には機能しますが、残念ながらおそらく望ましくないようです。
DNS over both TLS and DTLS can benefit from a single well-known port and avoid extra latency and misinterpreted queries as responses.
TLSとDTLSの両方でDNSを使用すると、1つの既知のポートからメリットを得て、余分なレイテンシや応答としてのクエリの誤解を回避できます。
Use of DNS over TLS is designed to address the privacy risks that arise out of the ability to eavesdrop on DNS messages. It does not address other security issues in DNS, and there are a number of residual risks that may affect its success at protecting privacy:
DNS over TLSの使用は、DNSメッセージを盗聴する機能から生じるプライバシーリスクに対処するように設計されています。 DNSの他のセキュリティ問題には対応しておらず、プライバシー保護の成功に影響を与える可能性のあるリスクがいくつか残っています。
1. There are known attacks on TLS, such as person-in-the-middle and protocol downgrade. These are general attacks on TLS and not specific to DNS over TLS; please refer to the TLS RFCs for discussion of these security issues. Clients and servers MUST adhere to the TLS implementation recommendations and security considerations of [BCP195]. DNS clients keeping track of servers known to support TLS enables clients to detect downgrade attacks. For servers with no connection history and no apparent support for TLS, depending on their privacy profile and privacy requirements, clients may choose to (a) try another server when available, (b) continue without TLS, or (c) refuse to forward the query.
1. TLSに対する既知の攻撃には、中間者やプロトコルのダウングレードなどがあります。これらはTLSに対する一般的な攻撃であり、DNS over TLSに固有のものではありません。これらのセキュリティ問題については、TLS RFCを参照してください。クライアントとサーバーは、[BCP195]のTLS実装の推奨事項とセキュリティの考慮事項に準拠する必要があります。 TLSをサポートすることがわかっているサーバーを追跡しているDNSクライアントは、クライアントがダウングレード攻撃を検出できるようにします。接続履歴がなく、TLSの明らかなサポートがないサーバーの場合、プライバシープロファイルとプライバシー要件に応じて、クライアントは（a）可能な場合は別のサーバーを試す、（b）TLSなしで続行する、または（c）転送を拒否することを選択できますクエリ。
2. Middleboxes [RFC3234] are present in some networks and have been known to interfere with normal DNS resolution. Use of a designated port for DNS over TLS should avoid such interference. In general, clients that attempt TLS and fail can either fall back on unencrypted DNS or wait and retry later, depending on their privacy profile and privacy requirements.
2. Middleboxes [RFC3234]は一部のネットワークに存在し、通常のDNS解決を妨害することが知られています。 DNS over TLSの指定ポートを使用すると、このような干渉を回避できます。一般に、TLSを試行して失敗したクライアントは、クライアントのプライバシープロファイルとプライバシー要件に応じて、暗号化されていないDNSにフォールバックするか、しばらく待ってから再試行します。
3. Any DNS protocol interactions performed in the clear can be modified by a person-in-the-middle attacker. For example, unencrypted queries and responses might take place over port 53 between a client and server. For this reason, clients MAY discard cached information about server capabilities advertised in cleartext.
3.平文で実行されるDNSプロトコルの相互作用は、中間者攻撃者によって変更される可能性があります。たとえば、暗号化されていないクエリと応答は、クライアントとサーバーの間のポート53で発生する可能性があります。このため、クライアントは、クリアテキストでアドバタイズされたサーバー機能に関するキャッシュされた情報を破棄してもよい（MAY）。
4. This document does not, itself, specify ideas to resist known traffic analysis or side-channel leaks. Even with encrypted messages, a well-positioned party may be able to glean certain details from an analysis of message timings and sizes. Clients and servers may consider the use of a padding method to address privacy leakage due to message sizes [RFC7830]. Since traffic analysis can be based on many kinds of patterns and many kinds of classifiers, simple padding schemes alone might not be sufficient to mitigate such an attack. Padding will, however, form a part of more complex mitigations for traffic-analysis attacks that are likely to be developed over time. Implementors who can offer flexibility in terms of how padding can be used may be in a better position to enable such mitigations to be deployed in the future.
4. このドキュメント自体は、既知のトラフィック分析やサイドチャネルリークに対抗するためのアイデアを指定するものではありません。メッセージが暗号化されていても、適切に配置されたパーティは、メッセージのタイミングとサイズの分析から特定の詳細を収集できる場合があります。クライアントとサーバーは、メッセージサイズによるプライバシー漏洩に対処するための埋め込み方法の使用を検討する場合があります[RFC7830]。トラフィック分析は多くの種類のパターンと多くの種類の分類子に基づくことができるため、単純なパディングスキームだけでは、このような攻撃を緩和するには不十分な場合があります。ただし、パディングは、時間の経過とともに開発される可能性が高いトラフィック分析攻撃に対するより複雑な緩和策の一部を形成します。パディングをどのように使用できるかという点で柔軟性を提供できる実装者は、そのような緩和策を将来展開できるようにするためにより良い立場にあるかもしれません。
As noted earlier, DNSSEC and DNS over TLS are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other.
前述のように、DNSSECとDNS over TLSは独立した完全に互換性のあるプロトコルであり、それぞれが異なる問題を解決します。一方を使用しても、もう一方の必要性や有用性が低下することはありません。
[BCP195] 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, May 2015, <https://www.rfc-editor.org/info/bcp195>.
[BCP195] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、2015年5月、<https://www.rfc-editor.org/info/bcp195>。
[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>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[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>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<http：//www.rfc- editor.org/info/rfc6234>。
[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>。
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7120] Cotton、M。、「Early IANA Allocation of Standards Track Code Points」、BCP 100、RFC 7120、DOI 10.17487 / RFC7120、2014年1月、<http://www.rfc-editor.org/info/rfc7120> 。
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7469] Evans、C.、Palmer、C。、およびR. Sleevi、「HTTPの公開キー固定拡張機能」、RFC 7469、DOI 10.17487 / RFC7469、2015年4月、<http://www.rfc-editor.org / info / rfc7469>。
[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>。
[CONFIDENTIAL-DNS] Wijngaards, W. and G. Wiley, "Confidential DNS", Work in Progress, draft-wijngaards-dnsop-confidentialdns-03, March 2015.
[CONFIDENTIAL-DNS] Wijngaards、W。およびG. Wiley、「Confidential DNS」、Work in Progress、draft-wijngaards-dnsop-confidentialdns-03、2015年3月。
[DNSCRYPT-WEBSITE] Denis, F., "DNSCrypt", December 2015, <https://www.dnscrypt.org/>.
[DNSCRYPT-WEBSITE] Denis、F。、「DNSCrypt」、2015年12月、<https://www.dnscrypt.org/>。
[DNSCurve] Dempsky, M., "DNSCurve: Link-Level Security for the Domain Name System", Work in Progress, draft-dempsky-dnscurve-01, February 2010.
[DNSCurve] Dempsky、M。、「DNSCurve：Link-Level Security for the Domain Name System」、Work in Progress、draft-dempsky-dnscurve-01、2010年2月。
[DNSoD] Reddy, T., Wing, D., and P. Patil, "DNS over DTLS (DNSoD)", Work in Progress, draft-ietf-dprive-dnsodtls-06, April 2016.
[DNSoD] Reddy、T.、Wing、D。、およびP. Patil、「DNS over DTLS（DNSoD）」、Work in Progress、draft-ietf-dprive-dnsodtls-06、2016年4月。
[DNSSEC-TRIGGER] NLnet Labs, "Dnssec-Trigger", May 2014, <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[DNSSEC-TRIGGER] NLnet Labs、「Dnssec-Trigger」、2014年5月、<https://www.nlnetlabs.nl/projects/dnssec-trigger/>。
[IPSECA] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. Mohaisen, "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA", Work in Progress, draft-osterweil-dane-ipsec-03, July 2015.
[IPSECA] Osterweil、E.、Wiley、G.、Okubo、T.、Lavu、R。、およびA. Mohaisen、「DANEセマンティクスとIPsecによるOpportunistic Encryption：IPSECA」、Work in Progress、draft-osterweil-dane- ipsec-03、2015年7月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, <http://www.rfc-editor.org/info/rfc3234>.
[RFC3234]カーペンター、B。およびS.ブリム、「ミドルボックス：分類と問題」、RFC 3234、DOI 10.17487 / RFC3234、2002年2月、<http://www.rfc-editor.org/info/rfc3234>。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <http://www.rfc-editor.org/info/rfc3646>.
[RFC3646] Droms、R。、編、「IPv6の動的ホスト構成プロトコルのDNS構成オプション（DHCPv6）」、RFC 3646、DOI 10.17487 / RFC3646、2003年12月、<http://www.rfc-editor.org / info / rfc3646>。
[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>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[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>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[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>。
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <http://www.rfc-editor.org/info/rfc7828>.
[RFC7828] Wouters、P.、Abley、J.、Dickinson、S。、およびR. Bellis、「The edns-tcp-keepalive EDNS0 Option」、RFC 7828、DOI 10.17487 / RFC7828、2016年4月、<http：// www.rfc-editor.org/info/rfc7828>。
[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>。
[TDNS] 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://dx.doi.org/10.1109/SP.2015.18>.
[TDNS] Zhu、L.、Hu、Z.、Heidemann、J.、Wessels、D.、Mankin、A。、およびN. Somaiya、「プライバシーとセキュリティを向上させる接続指向DNS」、2015年セキュリティに関するIEEEシンポジウムおよびプライバシー（SP）、DOI 10.1109 / SP.2015.18、<http://dx.doi.org/10.1109/SP.2015.18>。
[TLS-DTLS-PROFILES] Dickinson, S., Gillmor, D., and T. Reddy, "Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS", Work in Progress, draft-ietf-dprive-dtls-and-tls-profiles-01, March 2016.
[TLS-DTLS-PROFILES] Dickinson、S.、Gillmor、D。、およびT. Reddy、「DNS-over-TLSおよびDNS-over-DTLSの認証および（D）TLSプロファイル」、作業中、ドラフト- ietf-dprive-dtls-and-tls-profiles-01、2016年3月。
[TLS-FALSESTART] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", Work in Progress, draft-ietf-tls-falsestart-02, May 2016.
[TLS-FALSESTART] Langley、A.、Modadugu、N。、およびB. Moeller、「Transport Layer Security（TLS）False Start」、Work in Progress、draft-ietf-tls-falsestart-02、May 2016。
This section presents an example of how the out-of-band key-pinned privacy profile could work in practice based on a minimal pin set (two pins).
このセクションでは、最小限のピンセット（2つのピン）に基づいて、帯域外キーピンプライバシープロファイルが実際にどのように機能するかの例を示します。
A DNS client system is configured with an out-of-band key-pinned privacy profile from a network service, using a pin set containing two pins. Represented in HTTP Public Key Pinning (HPKP) [RFC7469] style, the pins are:
DNSクライアントシステムは、2つのピンを含むピンセットを使用して、ネットワークサービスからのアウトオブバンドキー固定プライバシープロファイルで構成されます。 HTTP公開鍵ピン留め（HPKP）[RFC7469]スタイルで表されるピンは次のとおりです。
o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
o pin-sha256 = "FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI ="
o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="
o pin-sha256 = "dFSY3wdPU8L0u / 8qECuz5wtlSgnorYV2f66L6GNQg6w ="
The client also configures the IP addresses of its expected DNS server: perhaps 192.0.2.3 and 2001:db8::2:4.
クライアントは、予想されるDNSサーバーのIPアドレス（おそらく192.0.2.3および2001：db8 :: 2：4）も構成します。
The client connects to one of these addresses on TCP port 853 and begins the TLS handshake: negotiation of TLS 1.2 with a Diffie-Hellman key exchange. The server sends a certificate message with a list of three certificates (A, B, and C) and signs the ServerKeyExchange message correctly with the public key found in certificate A.
クライアントは、TCPポート853でこれらのアドレスのいずれかに接続し、TLSハンドシェイクを開始します。Diffie-Hellman鍵交換を使用したTLS 1.2のネゴシエーション。サーバーは、3つの証明書（A、B、C）のリストを含む証明書メッセージを送信し、証明書Aにある公開鍵を使用してServerKeyExchangeメッセージに正しく署名します。
The client now takes the SHA-256 digest of the SPKI in cert A and compares it against both pins in the pin set. If either pin matches, the verification is successful; the client continues with the TLS connection and can make its first DNS query.
クライアントは、証明書AのSPKIのSHA-256ダイジェストを取得し、ピンセットの両方のピンと比較します。いずれかのピンが一致する場合、検証は成功です。クライアントはTLS接続を続行し、最初のDNSクエリを実行できます。
If neither pin matches the SPKI of cert A, the client verifies that cert A is actually issued by cert B. If it is, it takes the SHA-256 digest of the SPKI in cert B and compares it against both pins in the pin set. If either pin matches, the verification is successful. Otherwise, it verifies that B was issued by C and then compares the pins against the digest of C's SPKI.
どちらのピンも証明書AのSPKIと一致しない場合、クライアントは、証明書Aが実際に証明書Bによって発行されていることを確認します。一致する場合、証明書BのSPKIのSHA-256ダイジェストを取得し、ピンセットの両方のピンと比較します。 。どちらかのピンが一致すれば、検証は成功です。それ以外の場合は、BがCによって発行されたことを確認してから、ピンをCのSPKIのダイジェストと比較します。
If none of the SPKIs in the cryptographically valid chain of certs match any pin in the pin set, the client closes the connection with an error and marks the IP address as failed.
暗号的に有効な証明書チェーンのSPKIがピンセットのピンと一致しない場合、クライアントはエラーで接続を閉じ、IPアドレスに失敗のマークを付けます。
Acknowledgments
謝辞
The authors would like to thank Stephane Bortzmeyer, John Dickinson, Brian Haberman, Christian Huitema, Shumon Huque, Simon Joseffson, Kim-Minh Kaplan, Simon Kelley, Warren Kumari, John Levine, Ilari Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei Tatuya, Tim Wicinski, and Glen Wiley for reviewing this specification. They also thank Nikita Somaiya for early work on this idea.
著者は、ステファン・ボルツマイヤー、ジョン・ディキンソン、ブライアン・ハーバーマン、クリスチャン・ウイテマ、シュモン・ハケ、サイモン・ジョセフソン、キム・ミン・カプラン、サイモン・ケリー、ウォーレン・クマリ、ジョン・レバイン、イラリ・リスヴァーラ、ビル・マニング、ジョージ・マイケルソン、エリック・オスターワイル、この仕様をレビューしてくださったJinmei Tatuya、Tim Wicinski、およびGlen Wiley。彼らはまた、この考えの初期の作業について、Nikita Somaiyaに感謝します。
Work by Zi Hu, Liang Zhu, and John Heidemann on this document is partially sponsored by the U.S. Dept. of Homeland Security (DHS) Science and Technology Directorate, Homeland Security Advanced Research Projects Agency (HSARPA), Cyber Security Division, BAA 11-01-RIKA and Air Force Research Laboratory, Information Directorate under agreement number FA8750-12-2-0344, and contract number D08PC75599.
この文書に関するZi Hu、Liang Zhu、およびJohn Heidemannによる作業は、米国国土安全保障省（DHS）の科学技術局、国土安全保障省高等研究計画局（HSARPA）、サイバーセキュリティ部門、BAA 11- 01-RIKAおよび空軍研究所、契約番号FA8750-12-2-0344、契約番号D08PC75599に基づく情報局。
Contributors
貢献者
The below individuals contributed significantly to the document:
以下の個人が文書に大きく貢献しました：
Sara Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
さら ぢｃきんそん しのづん いんてｒねｔ てｃｈのぉぎえｓ まｇだぇん せんｔれ おｘふぉｒｄ Ｓしえんせ ぱｒｋ おｘふぉｒｄ おＸ４ ４が うにてｄ きんｇどｍ
Email: sara@sinodun.com
URI: http://sinodun.com
Daniel Kahn Gillmor ACLU 125 Broad Street, 18th Floor New York, NY 10004 United States
Daniel Kahn Gillmor ACLU 125 Broad Street、18th Floor New York、NY 10004アメリカ
Authors' Addresses
著者のアドレス
Zi Hu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States
Zi Hu USC / Information Sciences Institute 4676 Admiralty Way、Suite 1133 Marina del Rey、CA 90292 United States
Phone: +1-213-587-1057
Email: zihu@outlook.com
Liang Zhu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States
Liang Zhu USC /情報科学研究所4676 Admiralty Way、Suite 1133 Marina del Rey、CA 90292アメリカ合衆国
Phone: +1-310-448-8323
Email: liangzhu@usc.edu
John Heidemann USC/Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 United States
John Heidemann USC / Information Sciences Institute 4676 Admiralty Way、Suite 1001 Marina del Rey、CA 90292アメリカ合衆国
Phone: +1-310-822-1511
Email: johnh@isi.edu
Allison Mankin Independent
あっぃそん まんきん いんでぺんでんｔ
Phone: +1-301-728-7198
Email: Allison.mankin@gmail.com
Duane Wessels Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
Duane Wessels Verisign Labs 12061 Bluemont Way Reston、VA 20190アメリカ
Phone: +1-703-948-3200 Email: dwessels@verisign.com Paul Hoffman ICANN
電話：+ 1-703-948-3200メール：dwessels@verisign.com Paul Hoffman ICANN
Email: paul.hoffman@icann.org