[要約] RFC 8310は、DNS over TLSおよびDNS over DTLSの使用プロファイルに関する情報を提供します。このRFCの目的は、セキュアなDNS通信のための標準化と実装のガイドラインを提供することです。
Internet Engineering Task Force (IETF) S. Dickinson
Request for Comments: 8310 Sinodun
Updates: 7858 D. Gillmor
Category: Standards Track ACLU
ISSN: 2070-1721 T. Reddy
McAfee
March 2018
Usage Profiles for DNS over TLS and DNS over DTLS
DNS over TLSおよびDNS over DTLSの使用プロファイル
Abstract
概要
This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858.
このドキュメントでは、DNS over Transport Layer Security（TLS）またはデータグラムTLS（DTLS）に使用できる1つ以上の認証メカニズムに基づく使用プロファイルについて説明します。これらのプロファイルは、クリアテキストDNSのみを使用する場合と比較して、DNSトランザクションのプライバシーを向上させることができます。このドキュメントでは、新しい認証メカニズムについても説明しています。DNSクライアントが認証ドメイン名を使用して、DNSサーバーへの（D）TLS接続を認証するいくつかの方法について説明しています。さらに、DNS over（D）TLSを実装するDNSクライアントおよびサーバーの（D）TLSプロトコルプロファイルを定義します。このドキュメントはRFC 7858を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8310.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8310で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Scope ...........................................................7
4. Discussion ......................................................8
5. Usage Profiles ..................................................8
5.1. DNS Resolution ............................................11
6. Authentication in DNS over (D)TLS ..............................11
6.1. DNS-over-(D)TLS Startup Configuration Problems ............11
6.2. Credential Verification ...................................12
6.3. Summary of Authentication Mechanisms ......................12
6.4. Combining Authentication Mechanisms .......................15
6.5. Authentication in Opportunistic Privacy ...................15
6.6. Authentication in Strict Privacy ..........................16
6.7. Implementation Guidance ...................................16
7. Sources of Authentication Domain Names .........................17
7.1. Full Direct Configuration .................................17
7.2. Direct Configuration of ADN Only ..........................17
7.3. Dynamic Discovery of ADN ..................................17
7.3.1. DHCP ...............................................18
8. Credential Verification Based on Authentication Domain Name ....18
8.1. Authentication Based on PKIX Certificate ..................18
8.2. DANE ......................................................19
8.2.1. Direct DNS Meta-Queries ............................20
8.2.2. TLS DNSSEC Chain Extension .........................20
9. (D)TLS Protocol Profile ........................................20
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
11.1. Countermeasures to DNS Traffic Analysis ..................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................24
Appendix A. Server Capability Probing and Caching by DNS Clients ..26
Acknowledgments ...................................................27
Authors' Addresses ................................................27
DNS privacy issues are discussed in [RFC7626]. The specific issues described in [RFC7626] that are most relevant to this document are
DNSのプライバシー問題は[RFC7626]で議論されています。 [RFC7626]で説明されている、このドキュメントに最も関連する特定の問題は、
o Passive attacks that eavesdrop on cleartext DNS transactions on the wire (Section 2.4 of [RFC7626]) and
o クリアテキストDNSトランザクションをネットワーク上で盗聴するパッシブ攻撃（[RFC7626]のセクション2.4）および
o Active attacks that redirect clients to rogue servers to monitor DNS traffic (Section 2.5.3 of [RFC7626]).
o クライアントを不正なサーバーにリダイレクトしてDNSトラフィックを監視するアクティブな攻撃（[RFC7626]のセクション2.5.3）。
Mitigating these attacks increases the privacy of DNS transactions; however, many of the other issues raised in [RFC7626] still apply.
これらの攻撃を軽減すると、DNSトランザクションのプライバシーが向上します。ただし、[RFC7626]で提起された他の問題の多くはまだ適用されます。
Two documents that provide ways to increase DNS privacy between DNS clients and DNS servers are
DNSクライアントとDNSサーバー間のDNSプライバシーを強化する方法を提供する2つのドキュメントは、
o "Specification for DNS over Transport Layer Security (TLS)" [RFC7858], referred to here as simply "DNS over TLS".
o 「DNS over Transport Layer Security（TLS）の仕様」[RFC7858]。ここでは単に「DNS over TLS」と呼びます。
o "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094], referred to here as simply "DNS over DTLS". Note that [RFC8094] is an Experimental specification.
o 「DNS over Datagram Transport Layer Security（DTLS）」[RFC8094]、ここでは単に「DNS over DTLS」と呼びます。 [RFC8094]は実験的な仕様であることに注意してください。
Both documents are limited in scope to communications between stub clients and recursive resolvers, and the same scope is applied to this document (see Sections 2 and 3). The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application was out of scope for the DNS PRIVate Exchange (dprive) Working Group charter at the time this document was published.
どちらのドキュメントも、スタブクライアントと再帰リゾルバ間の通信にスコープが限定されており、同じスコープがこのドキュメントに適用されます（セクション2および3を参照）。ここでの提案は、将来的には再帰的なクライアントや権限のあるサーバーで使用されるように調整または拡張される可能性がありますが、このアプリケーションは、このドキュメントが公開された時点ではDNS PRIVate Exchange（dprive）ワーキンググループチャーターの範囲外でした。
This document specifies two usage profiles (Strict Privacy and Opportunistic Privacy) for DTLS [RFC6347] and TLS [RFC5246] that provide improved levels of mitigation for the attacks described above compared to using only cleartext DNS.
このドキュメントでは、DTLS [RFC6347]とTLS [RFC5246]の2つの使用プロファイル（Strict PrivacyとOpportunistic Privacy）を指定し、クリアテキストDNSのみを使用する場合と比較して、上記の攻撃に対する軽減レベルを向上させます。
Section 5 presents a generalized discussion of usage profiles by separating the usage profile, which is based purely on the security properties it offers the user, from the specific mechanism or mechanisms that are used for DNS server authentication. The profiles described are
セクション5では、純粋にユーザーに提供するセキュリティプロパティに基づく使用プロファイルを、DNSサーバー認証に使用される特定のメカニズムから分離することにより、使用プロファイルの一般的な説明を示します。説明されているプロファイルは
o A Strict Privacy profile, which requires an encrypted connection and successful authentication of the DNS server; this mitigates both passive eavesdropping and client redirection (at the expense of providing no DNS service if an encrypted, authenticated connection is not available).
o 厳格なプライバシープロファイル。暗号化された接続とDNSサーバーの正常な認証が必要です。これにより、パッシブ盗聴とクライアントリダイレクトの両方が軽減されます（暗号化された認証済みの接続が利用できない場合にDNSサービスを提供しないという犠牲を払って）。
o An Opportunistic Privacy profile, which will attempt, but does not require, encryption and successful authentication; it therefore provides limited or no mitigation for such attacks but maximizes the chance of DNS service.
o 暗号化と認証の成功を試みるが必要としない、日和見プライバシープロファイル。したがって、このような攻撃に対する制限はほとんどないか軽減されますが、DNSサービスの可能性が最大化されます。
The above usage profiles attempt authentication of the server using at least one authentication mechanism. Section 6.4 discusses how to combine authentication mechanisms to determine the overall authentication result. Depending on that overall authentication result (and whether encryption is available), the usage profile will determine if the connection should proceed, fall back, or fail.
上記の使用プロファイルは、少なくとも1つの認証メカニズムを使用してサーバーの認証を試みます。セクション6.4では、認証メカニズムを組み合わせて認証結果全体を決定する方法について説明します。その全体的な認証結果（および暗号化が使用可能かどうか）に応じて、使用プロファイルは、接続を続行するか、フォールバックするか、失敗するかを決定します。
One authentication mechanism is already described in [RFC7858]. [RFC7858] specifies an authentication mechanism for DNS over TLS that is based on Subject Public Key Info (SPKI) in the context of a specific case of a Strict Privacy profile using that single authentication mechanism. Therefore, the "out-of-band key-pinned privacy profile" described in [RFC7858] would qualify as a "Strict Privacy profile" that used SPKI pinning for authentication.
1つの認証メカニズムは[RFC7858]ですでに説明されています。 [RFC7858]は、件名公開鍵情報（SPKI）に基づくDNS over TLSの認証メカニズムを、その単一の認証メカニズムを使用する厳格なプライバシープロファイルの特定のケースのコンテキストで指定します。したがって、[RFC7858]で説明されている「帯域外キーピンプライバシープロファイル」は、認証にSPKIピン留めを使用した「厳格プライバシープロファイル」と見なされます。
This document extends the use of authentication based on SPKI pin sets, so that it is considered a general authentication mechanism that can be used with either DNS-over-(D)TLS usage profile. That is, the mechanism for SPKI pin sets as described in [RFC7858] MAY be used with DNS over (D)TLS.
このドキュメントは、SPKIピンセットに基づく認証の使用を拡張するため、DNS-over-（D）TLS使用プロファイルのいずれかで使用できる一般的な認証メカニズムと見なされます。つまり、[RFC7858]で説明されているSPKIピンセットのメカニズムは、DNS over（D）TLSで使用できます。
This document also describes a number of additional authentication mechanisms, all of which specify how a DNS client should authenticate a DNS server based on an "authentication domain name". In particular, the following topics are described:
このドキュメントでは、いくつかの追加の認証メカニズムについても説明します。これらのメカニズムはすべて、「認証ドメイン名」に基づいてDNSクライアントがDNSサーバーを認証する方法を指定します。特に、次のトピックについて説明します。
o How a DNS client can obtain the combination of an authentication domain name and IP address for a DNS server. See Section 7.
o DNSクライアントがDNSサーバーの認証ドメイン名とIPアドレスの組み合わせを取得する方法。セクション7を参照してください。
o What acceptable credentials a DNS server can present to prove its identity for (D)TLS authentication based on a given authentication domain name. See Section 8.
o 特定の認証ドメイン名に基づく（D）TLS認証のIDを証明するためにDNSサーバーが提示できる許容資格情報。セクション8を参照してください。
o How a DNS client can verify that any given credential matches the authentication domain name obtained for a DNS server. See Section 8.
o DNSクライアントが特定の資格情報がDNSサーバー用に取得した認証ドメイン名と一致することを確認する方法。セクション8を参照してください。
This document defines a (D)TLS protocol profile for use with DNS; see Section 9. This profile defines the configuration options and protocol extensions required of both parties to (1) optimize connection establishment and session resumption for transporting DNS and (2) support all currently specified authentication mechanisms.
このドキュメントでは、DNSで使用する（D）TLSプロトコルプロファイルを定義しています。セクション9を参照してください。このプロファイルは、（1）接続の確立とDNSを転送するためのセッション再開を最適化し、（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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Several terms are used specifically in the context of this document:
このドキュメントでは、いくつかの用語が具体的に使用されています。
o DNS client: A DNS stub resolver or forwarder. In the case of a forwarder, the term "DNS client" is used to discuss the side that sends queries.
o DNSクライアント：DNSスタブリゾルバーまたはフォワーダー。フォワーダーの場合、「DNSクライアント」という用語は、クエリを送信する側を説明するために使用されます。
o DNS server: A DNS recursive resolver or forwarder. In the case of a forwarder, the term "DNS server" is used to discuss the side that responds to queries. Note that, as used in this document, this term does not apply to authoritative servers.
o DNSサーバー：DNS再帰リゾルバーまたはフォワーダー。フォワーダーの場合、「DNSサーバー」という用語は、クエリに応答する側を説明するために使用されます。このドキュメントで使用されているように、この用語は権限のあるサーバーには適用されないことに注意してください。
o Privacy-enabling DNS server: A DNS server that implements DNS over TLS [RFC7858] and may optionally implement DNS over DTLS [RFC8094]. The server should also offer at least one of the credentials described in Section 8 and implement the (D)TLS profile described in Section 9.
o プライバシーを有効にするDNSサーバー：DNS over TLS [RFC7858]を実装し、オプションでDNS over DTLS [RFC8094]を実装できるDNSサーバー。サーバーは、セクション8で説明されている資格情報の少なくとも1つを提供し、セクション9で説明されている（D）TLSプロファイルを実装する必要があります。
o (D)TLS: Used for brevity; refers to both Transport Layer Security [RFC5246] and Datagram Transport Layer Security [RFC6347]. Specific terms will be used for any text that applies to either protocol alone.
o （D）TLS：簡潔にするために使用。トランスポート層セキュリティ[RFC5246]とデータグラムトランスポート層セキュリティ[RFC6347]の両方を指します。特定の用語は、いずれかのプロトコルのみに適用されるテキストに使用されます。
o DNS over (D)TLS: Used for brevity; refers to both DNS over TLS [RFC7858] and DNS over DTLS [RFC8094]. Specific terms will be used for any text that applies to either protocol alone.
o DNS over（D）TLS：簡潔にするために使用。 DNS over TLS [RFC7858]とDNS over DTLS [RFC8094]の両方を指します。特定の用語は、いずれかのプロトコルのみに適用されるテキストに使用されます。
o Authentication domain name: A domain name that can be used to authenticate a privacy-enabling DNS server. Sources of authentication domain names are discussed in Section 7.
o 認証ドメイン名：プライバシーを有効にするDNSサーバーの認証に使用できるドメイン名。認証ドメイン名のソースについては、セクション7で説明します。
o SPKI pin sets: [RFC7858] describes the use of cryptographic digests to "pin" public key information in a manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. An SPKI pin set is a collection of these pins that constrains a DNS server.
o SPKIピンセット：[RFC7858]は、HTTP公開鍵ピンニング（HPKP）[RFC7469]と同様の方法で公開鍵情報を「ピン留め」するための暗号化ダイジェストの使用について説明しています。 SPKIピンセットは、DNSサーバーを制約するこれらのピンのコレクションです。
o Authentication information: Information a DNS client may use as the basis of an authentication mechanism. In this context, this information can be either
o 認証情報：DNSクライアントが認証メカニズムの基礎として使用できる情報。このコンテキストでは、この情報は次のいずれかです。
* an SPKI pin set or
* SPKIピンセットまたは
* an authentication domain name
* 認証ドメイン名
o Reference identifier: A reference identifier as described in [RFC6125], constructed by the DNS client when performing TLS authentication of a DNS server.
o 参照識別子：[RFC6125]で説明されている参照識別子。DNSサーバーのTLS認証を実行するときにDNSクライアントによって作成されます。
o Credential: Information available for a DNS server that proves its identity for authentication purposes. Credentials discussed here include
o 資格情報：認証目的でIDを証明するDNSサーバーで利用可能な情報。ここで説明する資格には、
* a PKIX certificate
* PKIX証明書
* a DNSSEC-validated chain to a TLSA record
* TLSAレコードへのDNSSEC検証チェーン
but may also include SPKI pin sets.
SPKIピンセットが含まれる場合もあります。
This document is limited to describing
このドキュメントは説明に限定されています
o Usage profiles based on general authentication mechanisms.
o 一般的な認証メカニズムに基づく使用プロファイル。
o The details of domain-name-based authentication of DNS servers by DNS clients (as defined in Section 2).
o DNSクライアントによるDNSサーバーのドメイン名ベースの認証の詳細（セクション2で定義）。
o The (D)TLS profiles needed to support authentication in DNS over (D)TLS.
o （D）TLSを介したDNSでの認証をサポートするために必要な（D）TLSプロファイル。
As such, the following topics are out of scope for this document:
そのため、次のトピックはこのドキュメントの範囲外です。
o Authentication of authoritative servers by recursive resolvers.
o 再帰リゾルバによる権限のあるサーバーの認証。
o Authentication of DNS clients by DNS servers.
o DNSサーバーによるDNSクライアントの認証。
o The details of how to perform authentication based on SPKI pin sets. This is defined in [RFC7858].
o SPKIピンセットに基づいて認証を実行する方法の詳細。これは[RFC7858]で定義されています。
o Any server identifier other than domain names, including IP addresses, organizational names, country of origin, etc.
o IPアドレス、組織名、出身国など、ドメイン名以外のサーバー識別子
One way to mitigate eavesdropping on cleartext DNS transactions by passive attackers is to encrypt the query (and response). Such encryption typically provides integrity protection as a side effect; this means that on-path attackers cannot simply inject bogus DNS responses. To also mitigate active attackers pretending to be the server, the client must authenticate the (D)TLS connection to the server.
パッシブ攻撃者によるクリアテキストDNSトランザクションの盗聴を軽減する1つの方法は、クエリ（および応答）を暗号化することです。このような暗号化は、通常、副作用として整合性保護を提供します。これは、パス上の攻撃者が偽のDNS応答を単に注入することはできないことを意味します。サーバーを装ったアクティブな攻撃者も緩和するには、クライアントはサーバーへの（D）TLS接続を認証する必要があります。
This document discusses usage profiles, which provide differing levels of attack mitigation to DNS clients, based on the requirements for authentication and encryption, regardless of the context (for example, which network the client is connected to). A usage profile is a concept distinct from a usage policy or usage model; a usage policy or usage model might dictate which profile should be used in a particular context (enterprise vs. coffee shop), with a particular set of DNS servers or with reference to other external factors. A description of the variety of usage policies is out of scope for this document but may be the subject of future work.
このドキュメントでは、コンテキスト（クライアントが接続されているネットワークなど）に関係なく、認証と暗号化の要件に基づいて、DNSクライアントにさまざまなレベルの攻撃軽減を提供する使用プロファイルについて説明します。使用プロファイルは、使用ポリシーや使用モデルとは異なる概念です。使用ポリシーまたは使用モデルによって、特定のDNSサーバーのセットまたは他の外部要因を参照して、特定のコンテキスト（エンタープライズ対コーヒーショップ）で使用するプロファイルを指定できます。さまざまな使用ポリシーの説明はこのドキュメントの範囲外ですが、将来の作業の対象となる可能性があります。
The term "privacy-enabling DNS server" is used throughout this document. This is a DNS server that
このドキュメントでは、「プライバシーを有効にするDNSサーバー」という用語を使用しています。これはDNSサーバーです
o MUST implement DNS over TLS [RFC7858].
o DNS over TLS [RFC7858]を実装する必要があります。
o MAY implement DNS over DTLS [RFC8094].
o DNS over DTLS [RFC8094]を実装してもよい[MAY]。
o SHOULD offer at least one of the credentials described in Section 8.
o セクション8で説明されている資格情報の少なくとも1つを提供する必要があります。
o Implements the (D)TLS profile described in Section 9.
o セクション9で説明されている（D）TLSプロファイルを実装します。
A DNS client has a choice of usage profiles available to increase the privacy of DNS transactions. This choice is briefly discussed in both [RFC7858] and [RFC8094]. These usage profiles are
DNSクライアントには、DNSトランザクションのプライバシーを高めるために使用可能な使用プロファイルの選択肢があります。この選択は、[RFC7858]と[RFC8094]の両方で簡単に説明されています。これらの使用プロファイルは
o Strict Privacy profile: The DNS client requires both an encrypted and authenticated connection to a privacy-enabling DNS server. A hard failure occurs if this is not available. This requires the client to securely obtain authentication information it can use to authenticate the server. This profile mitigates both passive and active attacks, thereby providing the client with the best available privacy for DNS. This profile is discussed in detail in Section 6.6.
o 厳格なプライバシープロファイル：DNSクライアントには、プライバシーを有効にするDNSサーバーへの暗号化された接続と認証された接続の両方が必要です。これが利用できない場合、ハード障害が発生します。これには、クライアントがサーバーの認証に使用できる認証情報を安全に取得する必要があります。このプロファイルは、パッシブ攻撃とアクティブ攻撃の両方を軽減し、クライアントにDNSで利用可能な最高のプライバシーを提供します。このプロファイルについては、セクション6.6で詳しく説明します。
o Opportunistic Privacy profile: The DNS client uses Opportunistic Security as described in [RFC7435].
o 日和見プライバシープロファイル：[RFC7435]で説明されているように、DNSクライアントは日和見セキュリティを使用します。
* "... the use of cleartext as the baseline communication security policy, with encryption and authentication negotiated and applied to the communication when available."
* 「...ベースラインの通信セキュリティポリシーとしてのクリアテキストの使用。暗号化と認証がネゴシエートされ、可能な場合は通信に適用されます。」
As described in [RFC7435], it might result in
[RFC7435]で説明されているように、
* an encrypted and authenticated connection
* 暗号化および認証された接続
* an encrypted connection
* 暗号化された接続
* a cleartext connection
* クリアテキスト接続
depending on the fallback logic of the client, the available authentication information, and the capabilities of the DNS server. In all these cases, the DNS client is willing to continue with a connection to the DNS server and perform resolution of queries. The use of Opportunistic Privacy is intended to support incremental deployment of increased privacy with a view to widespread adoption of the Strict Privacy profile. It should be employed when the DNS client might otherwise settle for cleartext; it provides the maximum protection available, depending on the combination of factors described above. If all the configured DNS servers are DNS privacy servers, then it can provide protection against passive attacks and might protect against active ones.
クライアントのフォールバックロジック、利用可能な認証情報、およびDNSサーバーの機能によって異なります。これらすべてのケースで、DNSクライアントはDNSサーバーへの接続を続行し、クエリの解決を実行する用意があります。 Opportunistic Privacyの使用は、Strict Privacyプロファイルの広範な採用を視野に入れて、増加したプライバシーの段階的な展開をサポートすることを目的としています。 DNSクライアントが平文で解決する可能性がある場合に使用する必要があります。上記の要因の組み合わせに応じて、利用可能な最大の保護を提供します。構成されたすべてのDNSサーバーがDNSプライバシーサーバーである場合、パッシブ攻撃に対する保護を提供でき、アクティブな攻撃から保護する可能性があります。
Both profiles can include an initial meta-query (performed using Opportunistic Privacy) to obtain the IP address for the privacy-enabling DNS server to which the DNS client will subsequently connect. The rationale for permitting this for the Strict Privacy profile is that requiring such meta-queries to also be performed using the Strict Privacy profile would introduce significant deployment obstacles. However, it should be noted that in this scenario an active attack on the meta-query is possible. Such an attack could result in a Strict Privacy profile client connecting to a server it cannot authenticate (and therefore not obtaining DNS service) or an Opportunistic Privacy client connecting to a server controlled by the attacker. DNSSEC validation can detect the attack on the meta-query, which may result in the client not obtaining DNS service (for both usage profiles), depending on its DNSSEC validation policy. See Section 7.2 for more discussion.
両方のプロファイルには、（日和見プライバシーを使用して実行される）初期メタクエリを含めて、DNSクライアントがその後接続するプライバシー対応DNSサーバーのIPアドレスを取得できます。 Strict Privacyプロファイルでこれを許可する根拠は、Strict Privacyプロファイルを使用してこのようなメタクエリも実行する必要があると、展開に重大な障害が発生することです。ただし、このシナリオでは、メタクエリに対するアクティブな攻撃が可能であることに注意してください。このような攻撃は、認証できないサーバーに接続する（したがってDNSサービスを取得しない）厳格なプライバシープロファイルクライアント、または攻撃者が制御するサーバーに接続する日和見プライバシークライアントになる可能性があります。 DNSSEC検証では、メタクエリに対する攻撃を検出できます。これにより、クライアントのDNSSEC検証ポリシーによっては、クライアントが（両方の使用プロファイルの）DNSサービスを取得できなくなる場合があります。詳細については、セクション7.2を参照してください。
To compare the two usage profiles, Table 1 below shows a successful Strict Privacy profile alongside the three possible outcomes of an Opportunistic Privacy profile. In the best-case scenario for the Opportunistic Privacy profile (an authenticated and encrypted connection), it is equivalent to the Strict Privacy profile. In the worst-case scenario, it is equivalent to cleartext. Clients using the Opportunistic Privacy profile SHOULD try for the best case but MAY fall back to the intermediate case and, eventually, the worst-case scenario, in order to obtain a response. One reason to fall back without trying every available privacy-enabling DNS server is if latency is more important than attack mitigation; see Appendix A. The Opportunistic Privacy profile therefore provides varying protection, depending on what kind of connection is actually used, including no attack mitigation at all.
2つの使用プロファイルを比較するために、以下の表1は、成功した厳格なプライバシープロファイルと、機会主義的プライバシープロファイルの3つの可能な結果を示しています。 Opportunistic Privacyプロファイル（認証および暗号化された接続）の最良のシナリオでは、Strict Privacyプロファイルと同等です。最悪のシナリオでは、クリアテキストと同等です。 Opportunistic Privacyプロファイルを使用するクライアントは、最良のケースを試行する必要がありますが、応答を取得するために、中間ケース、そして最終的には最悪のシナリオにフォールバックする場合があります（MAY）。プライバシーを有効にするすべてのDNSサーバーを試さずにフォールバックする1つの理由は、攻撃の軽減よりも待機時間が重要な場合です。付録Aを参照してください。したがって、攻撃的軽減策をまったく含まないなど、実際に使用される接続の種類に応じて、日和見プライバシープロファイルはさまざまな保護を提供します。
Note that there is no requirement in Opportunistic Security to notify the user regarding what type of connection is actually used; the "detection" described below is only possible if such connection information is available. However, if it is available and the user is informed that an unencrypted connection was used to connect to a server, then the user should assume (detect) that the connection is subject to both active and passive attacks, since the DNS queries are sent in cleartext. This might be particularly useful if a new connection to a certain server is unencrypted when all previous connections were encrypted. Similarly, if the user is informed that an encrypted but unauthenticated connection was used, then the user can detect that the connection may be subject to active attacks. In other words, for the cases where no protection is provided against an attacker (N), it is possible to detect that an attack might be happening (D). This is discussed in Section 6.5.
Opportunistic Securityでは、実際に使用されている接続の種類についてユーザーに通知する必要がないことに注意してください。以下に説明する「検出」は、そのような接続情報が利用可能な場合にのみ可能です。ただし、それが利用可能であり、暗号化されていない接続がサーバーへの接続に使用されたことがユーザーに通知された場合、DNSクエリが送信されるため、ユーザーは接続がアクティブとパッシブの両方の攻撃を受けると想定（検出）する必要がありますクリアテキスト。これは、以前の接続がすべて暗号化されているときに、特定のサーバーへの新しい接続が暗号化されていない場合に特に役立ちます。同様に、暗号化されているが認証されていない接続が使用されたことがユーザーに通知された場合、ユーザーはその接続がアクティブな攻撃を受けている可能性があることを検出できます。つまり、攻撃者に対する保護が提供されていない場合（N）、攻撃が行われている可能性があることを検出できます（D）。これについては、セクション6.5で説明します。
+---------------+------------+------------------+-----------------+
| Usage Profile | Connection | Passive Attacker | Active Attacker |
+---------------+------------+------------------+-----------------+
| Strict | A, E | P | P |
| Opportunistic | A, E | P | P |
| Opportunistic | E | P | N, D |
| Opportunistic | | N, D | N, D |
+---------------+------------+------------------+-----------------+
P == Protection; N == No protection; D == Detection is possible;
A == Authenticated connection; E == Encrypted connection
Table 1: Attack Protection by Usage Profile and Type of Attacker
表1：使用プロファイルと攻撃者の種類による攻撃防御
The Strict Privacy profile provides the best attack mitigation and therefore SHOULD always be implemented in DNS clients that implement the Opportunistic Privacy profile.
Strict Privacyプロファイルは最善の攻撃緩和を提供するため、Opportunistic Privacyプロファイルを実装するDNSクライアントに常に実装する必要があります。
A DNS client that implements DNS over (D)TLS SHOULD NOT be configured by default to use only cleartext.
DNS over（D）TLSを実装するDNSクライアントは、デフォルトでクリアテキストのみを使用するように構成すべきではありません（SHOULD NOT）。
The choice between the two profiles depends on a number of factors, including which is more important to the particular client:
2つのプロファイルのどちらを選択するかは、特定のクライアントにとってより重要な要素を含む、いくつかの要因によって異なります。
o DNS service, at the cost of no attack mitigation (Opportunistic Privacy) or
o DNSサービス、ただし、攻撃を軽減しない（Opportunistic Privacy）または
o Best available attack mitigation, at the potential cost of no DNS service (Strict Privacy).
o DNSサービスがない場合の潜在的なコスト（厳格なプライバシー）で、利用可能な最善の攻撃の軽減。
Additionally, the two profiles require varying levels of configuration (or a trusted relationship with a provider) and DNS server capabilities; therefore, DNS clients will need to carefully select which profile to use based on their communication needs.
さらに、2つのプロファイルには、さまざまなレベルの構成（またはプロバイダーとの信頼関係）およびDNSサーバー機能が必要です。したがって、DNSクライアントは、通信のニーズに基づいて、使用するプロファイルを慎重に選択する必要があります。
A DNS server that implements DNS over (D)TLS SHOULD provide at least one credential (Section 2) so that those DNS clients that wish to use the Strict Privacy profile are able to do so.
DNS over（D）TLSを実装するDNSサーバーは、少なくとも1つの資格情報（セクション2）を提供する必要があります（セクション2）。これにより、厳格なプライバシープロファイルを使用したいDNSクライアントが提供できるようになります。
A DNS client SHOULD select a particular usage profile when resolving a query. A DNS client MUST NOT fall back from Strict Privacy to Opportunistic Privacy during the resolution of a given query, as this could invalidate the protection offered against attackers. It is anticipated that DNS clients will use a particular usage profile for all queries to all configured servers until an operational issue or policy update dictates a change in the profile used.
DNSクライアントは、クエリを解決するときに特定の使用プロファイルを選択する必要があります（SHOULD）。 DNSクライアントは、攻撃者に対して提供された保護を無効にする可能性があるため、特定のクエリの解決中に厳格なプライバシーから日和見プライバシーにフォールバックしてはなりません。 DNSクライアントは、運用上の問題またはポリシーの更新によって使用されるプロファイルの変更が指示されるまで、構成されたすべてのサーバーに対するすべてのクエリに対して特定の使用プロファイルを使用することが予想されます。
This section describes authentication mechanisms and how they can be used in either Strict or Opportunistic Privacy for DNS over (D)TLS.
このセクションでは、認証メカニズムと、それらをDNS over（D）TLSの厳密または日和見プライバシーで使用する方法について説明します。
Many (D)TLS clients use PKIX authentication [RFC6125] based on an authentication domain name for the server they are contacting. These clients typically first look up the server's network address in the DNS before making this connection. Such a DNS client therefore has a bootstrap problem, as it will typically only know the IP address of its DNS server.
多くの（D）TLSクライアントは、接続しているサーバーの認証ドメイン名に基づいてPKIX認証[RFC6125]を使用します。これらのクライアントは通常、この接続を行う前に、まずDNSでサーバーのネットワークアドレスを検索します。したがって、このようなDNSクライアントは通常、DNSサーバーのIPアドレスしか認識しないため、ブートストラップの問題があります。
In this case, before connecting to a DNS server, a DNS client needs to learn the authentication domain name it should associate with the IP address of a DNS server for authentication purposes. Sources of authentication domain names are discussed in Section 7.
この場合、DNSサーバーに接続する前に、DNSクライアントは、認証目的でDNSサーバーのIPアドレスに関連付ける認証ドメイン名を知る必要があります。認証ドメイン名のソースについては、セクション7で説明します。
One advantage of this domain-name-based approach is that it encourages the association of stable, human-recognizable identifiers with secure DNS service providers.
このドメイン名ベースのアプローチの利点の1つは、人間が認識できる安定した識別子と安全なDNSサービスプロバイダーとの関連付けを促進することです。
Verification of SPKI pin sets is discussed in [RFC7858].
SPKIピンセットの検証については、[RFC7858]で説明されています。
In terms of domain-name-based verification, once an authentication domain name is known for a DNS server, a choice of authentication mechanisms can be used for credential verification. Section 8 discusses these mechanisms -- namely, PKIX certificate-based authentication and DNS-Based Authentication of Named Entities (DANE) -- in detail.
ドメイン名ベースの検証に関しては、DNSサーバーの認証ドメイン名が判明すると、認証メカニズムの選択を使用して資格情報を検証できます。セクション8では、これらのメカニズム、つまりPKIX証明書ベースの認証とDNSベースの名前付きエンティティの認証（DANE）について詳しく説明します。
Note that the use of DANE adds requirements on the ability of the client to get validated DNSSEC results. This is discussed in more detail in Section 8.2.
DANEを使用すると、検証済みのDNSSEC結果を取得するクライアントの機能に関する要件が追加されることに注意してください。これについては、セクション8.2で詳しく説明します。
This section provides an overview of the various authentication mechanisms. Table 2 below indicates how the DNS client obtains information to use for authentication for each option: either statically via direct configuration or dynamically. Of course, the Opportunistic Privacy profile does not require authentication, and so a client using that profile may choose to connect to a privacy-enabling DNS server on the basis of just an IP address.
このセクションでは、さまざまな認証メカニズムの概要について説明します。以下の表2は、DNSクライアントが各オプションの認証に使用する情報を取得する方法を示しています：直接構成によって静的に、または動的に。もちろん、Opportunistic Privacyプロファイルは認証を必要としないので、そのプロファイルを使用するクライアントは、IPアドレスのみに基づいてプライバシー対応DNSサーバーに接続することを選択できます。
+---+------------+-------------+------------------------------------+
| # | Static | Dynamically | Short name: Description |
| | Config | Obtained | |
+---+------------+-------------+------------------------------------+
| 1 | SPKI + IP | | SPKI: SPKI pin set(s) and IP |
| | | | address obtained out of band |
| | | | [RFC7858] |
| | | | |
| 2 | ADN + IP | | ADN: ADN and IP address obtained |
| | | | out of band (see Section 7.1) |
| | | | |
| 3 | ADN | IP | ADN only: Opportunistic Privacy |
| | | | meta-queries to a NP DNS server |
| | | | for A/AAAA (see Section 7.2) |
| | | | |
| 4 | | ADN + IP | DHCP: DHCP configuration only (see |
| | | | Section 7.3.1) |
| | | | |
| 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via |
| | | TLSA record | Opportunistic Privacy meta-queries |
| | | | to NP DNS server (see Section |
| | | | 8.2.1) |
| | | | |
| 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain |
| | | TLSA record | provided by PE DNS server in TLS |
| | | | DNSSEC chain extension (see |
| | | | Section 8.2.2) |
+---+------------+-------------+------------------------------------+
SPKI == SPKI pin set(s); IP == IP Address;
ADN == Authentication Domain Name; NP == Network-Provided;
PE == Privacy-Enabling; [ ] == Data may be obtained either
statically or dynamically
Table 2: Overview of Authentication Mechanisms
表2：認証メカニズムの概要
The following summary attempts to present some key attributes of each of the mechanisms (using the "Short name" from Table 2), indicating attractive attributes with a "+" and undesirable attributes with a "-".
次の要約では、各メカニズムのいくつかの主要な属性（表2の「短縮名」を使用）を提示し、魅力的な属性に「+」、望ましくない属性に「-」を示しています。
1. SPKI
1. 話す
+ Minimal leakage (note that the ADN is always leaked in the Server Name Indication (SNI) field in the ClientHello in TLS when communicating with a privacy-enabling DNS server)
+ 最小限のリーク（プライバシーを有効にするDNSサーバーと通信するときに、TLSのClientHelloのサーバー名表示（SNI）フィールドでADNが常にリークされることに注意してください）
- Overhead of ongoing key management required
- 継続的なキー管理のオーバーヘッドが必要
2. ADN
2. ADN
+ Minimal leakage
+ 最小限の漏れ
+ One-off direct configuration only
+ 1回限りの直接構成のみ
3. ADN only
3. ADNのみ
+ Minimal one-off direct configuration; only a human-recognizable domain name needed
+ 最小限の1回限りの直接構成。人間が認識できるドメイン名のみが必要
- A/AAAA meta-queries leaked to network-provided DNS server that may be subject to active attack (attack can be mitigated by DNSSEC validation)
- アクティブな攻撃を受ける可能性のあるネットワーク提供のDNSサーバーにリークされたA / AAAAメタクエリ（DNSSEC検証により攻撃を軽減できます）
4. DHCP
4. DHCP
+ No static config
+ 静的構成なし
- Requires a non-standard or future DHCP option in order to provide the ADN
- ADNを提供するには、非標準または将来のDHCPオプションが必要です
- Requires secure and trustworthy connection to DHCP server if used with a Strict Privacy profile
- 厳格なプライバシープロファイルで使用する場合、DHCPサーバーへの安全で信頼できる接続が必要
5. DANE
5. データ
The ADN and/or IP may be obtained statically or dynamically, and the relevant attributes of that method apply.
ADNやIPは静的または動的に取得でき、そのメソッドの関連属性が適用されます。
+ DANE options (e.g., matching on entire certificate)
+ DANEオプション（証明書全体での一致など）
- Requires a DNSSEC-validating stub implementation (the deployment of which is limited at the time of this writing)
- DNSSEC検証スタブ実装が必要です（この記事の執筆時点では、展開は制限されています）
- DNSSEC chain meta-queries leaked to network-provided DNS server that may be subject to active attack
- DNSSECチェーンのメタクエリがネットワーク提供のDNSサーバーにリークし、アクティブな攻撃を受ける可能性がある
6. TLS extension
6. TLS拡張
The ADN and/or IP may be obtained statically or dynamically, and the relevant attributes of that method apply.
ADNやIPは静的または動的に取得でき、そのメソッドの関連属性が適用されます。
+ Reduced latency compared with DANE
+ DANEと比較してレイテンシを短縮
+ No network-provided DNS server required if ADN and IP statically configured
+ ADNおよびIPが静的に構成されている場合、ネットワーク提供のDNSサーバーは不要
+ DANE options (e.g., matching on entire certificate)
+ DANEオプション（証明書全体での一致など）
- Requires a DNSSEC-validating stub implementation
- DNSSEC検証スタブ実装が必要
This document does not make explicit recommendations about how an authentication mechanism based on SPKI pin sets should be combined with a domain-based mechanism from an operator perspective. However, it can be envisaged that a DNS server operator may wish to make both an SPKI pin set and an authentication domain name available to allow clients to choose which mechanism to use. Therefore, the following text provides guidance on how clients ought to behave if they choose to configure both, as is possible in HPKP [RFC7469].
このドキュメントでは、オペレーターの観点から、SPKIピンセットに基づく認証メカニズムをドメインベースのメカニズムとどのように組み合わせるかについて、明確な推奨はしていません。ただし、DNSサーバーのオペレーターがSPKIピンセットと認証ドメイン名の両方を使用可能にして、クライアントが使用するメカニズムを選択できるようにすることも考えられます。したがって、次のテキストは、HPKP [RFC7469]で可能なように、クライアントが両方を構成することを選択した場合のクライアントの動作に関するガイダンスを提供します。
A DNS client that is configured with both an authentication domain name and an SPKI pin set for a DNS server SHOULD match on both a valid credential for the authentication domain name and a valid SPKI pin set (if both are available) when connecting to that DNS server. In this case, the client SHOULD treat individual SPKI pins as specified in Section 2.6 of [RFC7469] with regard to user-defined trust anchors. The overall authentication result SHOULD only be considered successful if both authentication mechanisms are successful.
認証ドメイン名とDNSサーバーのSPKIピンセットの両方で構成されたDNSクライアントは、そのDNSに接続するときに、認証ドメイン名の有効な資格情報と有効なSPKIピンセット（両方が使用可能な場合）の両方で一致する必要があります（SHOULD）。サーバ。この場合、クライアントは、ユーザー定義のトラストアンカーに関して、[RFC7469]のセクション2.6で指定されているように、個々のSPKIピンを処理する必要があります（SHOULD）。両方の認証メカニズムが成功した場合にのみ、認証結果全体が成功したと見なされるべきです。
An Opportunistic Privacy Profile (based on Opportunistic Security [RFC7435]) that MAY be used for DNS over (D)TLS is described in [RFC7858] and is further specified in this document.
DNS over（D）TLSに使用される可能性のある日和見プライバシープロファイル（日和見セキュリティ[RFC7435]に基づく）は[RFC7858]で説明されており、このドキュメントでさらに詳しく説明されています。
DNS clients that issue queries under an Opportunistic Privacy profile and that know authentication information for a given privacy-enabling DNS server SHOULD try to authenticate the server using the mechanisms described here. This is useful for detecting (but not preventing) active attacks, since the fact that authentication information is available indicates that the server in question is a privacy-enabling DNS server to which it should be possible to establish an authenticated and encrypted connection. In this case, whilst a client cannot know the reason for an authentication failure, from a security standpoint the client should consider an active attack in progress and proceed under that assumption. For example, a client that implements a nameserver selection algorithm that preferentially uses nameservers that successfully authenticated (see Section 5) might not continue to use the failing server if there were alternative servers available.
Opportunistic Privacyプロファイルの下でクエリを発行し、特定のプライバシー対応DNSサーバーの認証情報を知っているDNSクライアントは、ここで説明するメカニズムを使用してサーバーを認証する必要があります。認証情報が利用可能であるという事実は、問題のサーバーがプライバシー対応のDNSサーバーであり、認証および暗号化された接続を確立できる必要があることを示しているため、これはアクティブな攻撃の検出に役立ちます（ただし、防止はできません）。この場合、クライアントは認証失敗の理由を知ることができませんが、セキュリティの観点から、クライアントは進行中のアクティブな攻撃を検討し、その仮定の下で続行する必要があります。たとえば、正常に認証されたネームサーバー（セクション5を参照）を優先的に使用するネームサーバー選択アルゴリズムを実装するクライアントは、代替サーバーが利用可能である場合、失敗したサーバーを引き続き使用しない可能性があります。
Attempting authentication is also useful for debugging or diagnostic purposes if there are means to report the result. This information can provide a basis for a DNS client to switch to (preferred) Strict Privacy where it is viable, e.g., where all the configured servers support DNS over (D)TLS and successfully authenticate.
認証の試行は、結果を報告する手段がある場合、デバッグまたは診断の目的にも役立ちます。この情報は、DNSクライアントが実行可能な（推奨）厳格プライバシーに切り替えるための基礎を提供します。たとえば、構成されたすべてのサーバーがDNS over（D）TLSをサポートし、認証に成功します。
To authenticate a privacy-enabling DNS server, a DNS client needs to know authentication information for each server it is willing to contact. This is necessary to protect against active attacks that attempt to redirect clients to rogue DNS servers.
プライバシーを有効にするDNSサーバーを認証するには、DNSクライアントは、接続する各サーバーの認証情報を知っている必要があります。これは、クライアントを不正なDNSサーバーにリダイレクトしようとするアクティブな攻撃から保護するために必要です。
A DNS client requiring Strict Privacy MUST use either (1) one of the sources listed in Section 7, to obtain an authentication domain name for the server it contacts or (2) an SPKI pin set as described in [RFC7858].
厳格なプライバシーを要求するDNSクライアントは、（1）セクション7にリストされているソースの1つを使用して、接続するサーバーの認証ドメイン名を取得するか、（2）[RFC7858]で説明されているSPKIピンセットを使用する必要があります。
A DNS client requiring Strict Privacy MUST only attempt to connect to DNS servers for which at least one piece of authentication information is known. The client MUST use the available verification mechanisms described in Section 8 to authenticate the server and MUST abort connections to a server when no verification mechanism succeeds.
厳格なプライバシーを要求するDNSクライアントは、少なくとも1つの認証情報がわかっているDNSサーバーへの接続のみを試行する必要があります。クライアントは、セクション8で説明されている利用可能な検証メカニズムを使用してサーバーを認証し、検証メカニズムが成功しなかった場合はサーバーへの接続を中止する必要があります。
With Strict Privacy, the DNS client MUST NOT commence sending DNS queries until at least one of the privacy-enabling DNS servers becomes available.
厳格なプライバシーでは、プライバシーを有効にするDNSサーバーの少なくとも1つが利用可能になるまで、DNSクライアントはDNSクエリの送信を開始してはなりません（MUST NOT）。
A privacy-enabling DNS server may be temporarily unavailable when configuring a network. For example, for clients on networks that require registration through web-based login (a.k.a. "captive portals"), such registration 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 privacy-enabling DNS servers after captive-portal registration. If using a Strict Privacy profile, the system MUST alert by some means that the DNS is not private during such a bootstrap operation.
プライバシーを有効にするDNSサーバーは、ネットワークを構成するときに一時的に利用できない場合があります。たとえば、Webベースのログイン（別名「キャプティブポータル」）を介した登録が必要なネットワーク上のクライアントの場合、そのような登録はDNSインターセプトとスプーフィングに依存する場合があります。 dnssec-trigger [dnssec-trigger]で使用されるような手法は、キャプティブポータル登録後に指定されたプライバシー対応DNSサーバーに移行することを目的として、ネットワーク構成中に使用できます。 Strict Privacyプロファイルを使用している場合、システムは何らかの方法で、そのようなブートストラップ操作中にDNSがプライベートではないことを警告する必要があります。
Section 9 describes the (D)TLS profile for DNS over (D)TLS. Additional considerations relating to general implementation guidelines are discussed in both Section 11 and Appendix A.
セクション9では、DNS over（D）TLSの（D）TLSプロファイルについて説明します。一般的な実装ガイドラインに関する追加の考慮事項は、セクション11と付録Aの両方で説明されています。
DNS clients may be directly and securely provisioned with the authentication domain name of each privacy-enabling DNS server -- for example, using a client-specific configuration file or API.
DNSクライアントは、たとえば、クライアント固有の構成ファイルまたはAPIを使用して、プライバシーを有効にする各DNSサーバーの認証ドメイン名で直接かつ安全にプロビジョニングできます。
In this case, direct configuration for a DNS client would consist of both an IP address and an authentication domain name for each DNS server that were obtained via an out-of-band mechanism.
この場合、DNSクライアントの直接構成は、帯域外メカニズムを介して取得された各DNSサーバーのIPアドレスと認証ドメイン名の両方で構成されます。
A DNS client may be configured directly and securely with only the authentication domain name of each of its privacy-enabling DNS servers -- for example, using a client-specific configuration file or API.
DNSクライアントは、プライバシー固有の各DNSサーバーの認証ドメイン名のみを使用して、たとえばクライアント固有の構成ファイルまたはAPIを使用して、直接かつ安全に構成できます。
A DNS client might learn of a default recursive DNS resolver from an untrusted source (such as DHCP's DNS Recursive Name Server option [RFC3646]). It can then use meta-queries performed using an Opportunistic Privacy profile to an untrusted recursive DNS resolver to establish the IP address of the intended privacy-enabling DNS resolver by doing a lookup of A/AAAA records. A DNSSEC-validating client SHOULD apply the same validation policy to the A/AAAA meta-queries as it does to other queries. A client that does not validate DNSSEC SHOULD apply the same policy (if any) to the A/AAAA meta-queries as it does to other queries. Private DNS resolution can now be done by the DNS client against the pre-configured privacy-enabling DNS resolver, using the IP address obtained from the untrusted DNS resolver.
DNSクライアントは、信頼できないソース（DHCPのDNS再帰的ネームサーバーオプション[RFC3646]など）からデフォルトの再帰的DNSリゾルバーを学習する場合があります。次に、信頼できない再帰DNSリゾルバーに対してOpportunistic Privacyプロファイルを使用して実行されたメタクエリを使用して、A / AAAAレコードのルックアップを行うことにより、目的のプライバシー対応DNSリゾルバーのIPアドレスを確立できます。 DNSSEC検証クライアントは、他のクエリと同じ検証ポリシーをA / AAAAメタクエリに適用する必要があります（SHOULD）。 DNSSECを検証しないクライアントは、他のクエリと同じポリシー（存在する場合）をA / AAAAメタクエリに適用する必要があります（SHOULD）。プライベートDNS解決は、信頼されていないDNSリゾルバーから取得したIPアドレスを使用して、構成済みのプライバシー対応DNSリゾルバーに対してDNSクライアントで実行できるようになりました。
A DNS client so configured that successfully connects to a privacy-enabling DNS server MAY choose to locally cache the server host IP addresses in order to not have to repeat the meta-query.
プライバシーを有効にするDNSサーバーに正常に接続するように構成されたDNSクライアントは、メタクエリを繰り返す必要がないようにサーバーホストのIPアドレスをローカルにキャッシュすることを選択できます。
This section discusses the general case of a DNS client discovering both the authentication domain name and IP address dynamically. At the time of this writing, this is not possible by any standard means. However, since, for example, a future DHCP extension could (in principle) provide this mechanism, the required security properties of such mechanisms are outlined here.
このセクションでは、認証ドメイン名とIPアドレスの両方を動的に検出するDNSクライアントの一般的なケースについて説明します。これを書いている時点では、これは標準的な手段では不可能です。ただし、たとえば、将来のDHCP拡張機能が（原則として）このメカニズムを提供する可能性があるため、このようなメカニズムに必要なセキュリティプロパティの概要をここで説明します。
When using a Strict Privacy profile, the dynamic discovery technique used as a source of authentication domain names MUST be considered secure and trustworthy. This requirement does not apply when using an Opportunistic Privacy profile, given the security expectation of that profile.
Strict Privacyプロファイルを使用する場合、認証ドメイン名のソースとして使用される動的検出技術は、安全で信頼できるものと見なされなければなりません（MUST）。 Opportunistic Privacyプロファイルを使用する場合、そのプロファイルのセキュリティ要件を考慮すると、この要件は適用されません。
In the typical case today, a DHCP server [RFC2131] [RFC3315] provides a list of IP addresses for DNS resolvers (see Section 3.8 of [RFC2132]) but does not provide an authentication domain name for the DNS resolver, thus preventing the use of most of the authentication methods described here (all of those that are based on a mechanism with ADN; see Table 2).
今日の一般的なケースでは、DHCPサーバー[RFC2131] [RFC3315]はDNSリゾルバーのIPアドレスのリストを提供しますが（[RFC2132]のセクション3.8を参照）、DNSリゾルバーの認証ドメイン名を提供しないため、使用できませんここで説明するほとんどの認証方法（ADNのメカニズムに基づくすべての認証方法。表2を参照）。
This document does not specify or request any DHCP extension to provide authentication domain names. However, if one is developed in future work, the issues outlined in Section 8 of [RFC7227] should be taken into account, as should the security considerations discussed in Section 23 of [RFC3315].
このドキュメントでは、認証ドメイン名を提供するDHCP拡張機能を指定または要求していません。ただし、将来の作業で開発される場合、[RFC3315]のセクション23で説明されているセキュリティの考慮事項と同様に、[RFC7227]のセクション8で概説されている問題を考慮する必要があります。
This document does not attempt to describe secured and trusted relationships to DHCP servers, as this is purely a DHCP issue (and still open, at the time of this writing). Whilst some implementation work is in progress to secure IPv6 connections for DHCP, IPv4 connections have received little or no implementation attention in this area.
これは純粋にDHCPの問題であるため（この記事の執筆時点ではまだ公開されているため）、このドキュメントではDHCPサーバーとのセキュリティで保護された信頼関係については説明しません。 DHCPのIPv6接続を保護するための実装作業が進行中ですが、IPv4接続はこの領域で実装の注意をほとんどまたはまったく受けていません。
When a DNS client configured with an authentication domain name connects to its configured DNS server over (D)TLS, the server may present it with a PKIX certificate. In order to ensure proper authentication, DNS clients MUST verify the entire certification path per [RFC5280]. The DNS client additionally uses validation techniques as described in [RFC6125] to compare the domain name to the certificate provided.
認証ドメイン名で構成されたDNSクライアントが（D）TLS経由で構成されたDNSサーバーに接続すると、サーバーはPKIX証明書を提示する場合があります。適切な認証を保証するために、DNSクライアントは[RFC5280]に従って認証パス全体を検証する必要があります。 DNSクライアントは、[RFC6125]で説明されている検証手法をさらに使用して、ドメイン名を提供された証明書と比較します。
A DNS client constructs one reference identifier for the server based on the authentication domain name: a DNS-ID, which is simply the authentication domain name itself.
DNSクライアントは、認証ドメイン名に基づいてサーバーの1つの参照識別子を作成します。DNS-IDは、認証ドメイン名そのものです。
If the reference identifier is found (as described in Section 6 of [RFC6125]) in the PKIX certificate's subjectAltName extension, the DNS client should accept the certificate for the server.
（[RFC6125]のセクション6で説明されているように）参照識別子がPKIX証明書のsubjectAltName拡張で見つかった場合、DNSクライアントはサーバーの証明書を受け入れる必要があります。
A compliant DNS client MUST only inspect the certificate's subjectAltName extension for the reference identifier. In particular, it MUST NOT inspect the Subject field itself.
準拠しているDNSクライアントは、参照識別子の証明書のsubjectAltName拡張のみを検査する必要があります。特に、Subjectフィールド自体を検査してはなりません。
DANE [RFC6698] provides various mechanisms using DNSSEC to anchor trust for certificates and raw public keys. However, this requires the DNS client to have an authentication domain name (which must be obtained via a trusted source) for the DNS privacy server.
DANE [RFC6698]は、DNSSECを使用して証明書と生の公開鍵の信頼を固定するさまざまなメカニズムを提供します。ただし、これには、DNSクライアントがDNSプライバシーサーバー用の認証ドメイン名（信頼できるソースから取得する必要がある）が必要です。
This section assumes a solid understanding of both DANE [RFC6698] and DANE operations [RFC7671]. A few pertinent issues covered in these documents are outlined here as useful pointers, but familiarity with both of these documents in their entirety is expected.
このセクションは、DANE [RFC6698]とDANE操作[RFC7671]の両方を確実に理解していることを前提としています。これらのドキュメントでカバーされているいくつかの関連する問題は、役に立つポインタとしてここで概説されていますが、これらのドキュメントの両方に完全に精通していることが期待されます。
Note that [RFC6698] says
[RFC6698]は言うことに注意してください
Clients that validate the DNSSEC signatures themselves MUST use standard DNSSEC validation procedures. Clients that rely on another entity to perform the DNSSEC signature validation MUST use a secure mechanism between themselves and the validator.
DNSSEC署名自体を検証するクライアントは、標準のDNSSEC検証手順を使用する必要があります。 DNSSEC署名の検証を実行するために別のエンティティに依存しているクライアントは、クライアントとバリデータの間で安全なメカニズムを使用する必要があります。
Note that [RFC7671] covers the following topics:
[RFC7671]は以下のトピックをカバーしていることに注意してください：
o Sections 4.1 ("Opportunistic Security and PKIX Usages") and 14 ("Security Considerations") of [RFC7671], which both discuss the use of schemes based on trust anchors and end entities (PKIX-TA(0) and PKIX-EE(1), respectively) for Opportunistic Security.
o [RFC7671]のセクション4.1（「オポチュニスティックセキュリティとPKIXの使用法」）および14（「セキュリティの考慮事項」）。どちらも、トラストアンカーとエンドエンティティ（PKIX-TA（0）およびPKIX-EE（ 1）それぞれ、日和見セキュリティ用。
o Section 5 ("Certificate-Usage-Specific DANE Updates and Guidelines") of [RFC7671] -- specifically, Section 5.1 of [RFC7671], which outlines the combination of certificate usage DANE-EE(3) and selector SPKI(1) with raw public keys [RFC7250]. Section 5.1 of [RFC7671] also discusses the security implications of this mode; for example, it discusses key lifetimes and specifies that validity period enforcement is based solely on the TLSA RRset properties for this case.
o [RFC7671]のセクション5（「証明書の使用方法に固有のDANEの更新とガイドライン」）-具体的には、証明書の使用法DANE-EE（3）とセレクターSPKI（1）の組み合わせの概要を示す[RFC7671]のセクション5.1生の公開鍵[RFC7250]。 [RFC7671]のセクション5.1でも、このモードのセキュリティへの影響について説明しています。たとえば、キーの有効期間について説明し、有効期間の強制はこの場合のTLSA RRsetプロパティのみに基づくことを指定します。
o Section 13 ("Operational Considerations") of [RFC7671], which discusses TLSA TTLs and signature validity periods.
o [RFC7671]のセクション13（「運用上の考慮事項」）。TLSATTLと署名の有効期間について説明しています。
The specific DANE record for a DNS privacy server would take the form
DNSプライバシーサーバーの特定のDANEレコードは、次の形式になります。
_853._tcp.[authentication-domain-name] for TLS
TLSの_853._tcp。[authentication-domain-name]
_853._udp.[authentication-domain-name] for DTLS
_853._udp。[authentication-domain-name] for DTLS
The DNS client MAY choose to perform the DNS meta-queries to retrieve the required DANE records itself. The DNS meta-queries for such DANE records MAY use the Opportunistic Privacy profile or be in the clear to avoid trust recursion. The records MUST be validated using DNSSEC as described in [RFC6698].
DNSクライアントは、必要なDANEレコード自体を取得するためにDNSメタクエリを実行することを選択できます（MAY）。そのようなDANEレコードのDNSメタクエリは、Opportunistic Privacyプロファイルを使用するか、信頼できる再帰を回避するために明確にする必要があります。 [RFC6698]で説明されているように、レコードはDNSSECを使用して検証する必要があります。
The DNS client MAY offer the TLS extension described in [TLS-DNSSEC-Chain-Ext]. If the DNS server supports this extension, it can provide the full chain to the client in the handshake.
DNSクライアントは、[TLS-DNSSEC-Chain-Ext]で説明されているTLS拡張を提供してもよい（MAY）。 DNSサーバーがこの拡張機能をサポートしている場合、ハンドシェイクでクライアントに完全なチェーンを提供できます。
If the DNS client offers the TLS DNSSEC chain extension, it MUST be capable of validating the full DNSSEC authentication chain down to the leaf. If the supplied DNSSEC chain does not validate, the client MUST ignore the DNSSEC chain and validate only via other supplied credentials.
DNSクライアントがTLS DNSSECチェーン拡張を提供する場合、リーフまでの完全なDNSSEC認証チェーンを検証できる必要があります。提供されたDNSSECチェーンが検証しない場合、クライアントはDNSSECチェーンを無視し、他の提供された資格情報を介してのみ検証する必要があります。
This section defines the (D)TLS protocol profile of DNS over (D)TLS.
このセクションでは、DNS over（D）TLSの（D）TLSプロトコルプロファイルを定義します。
Clients and servers MUST adhere to the (D)TLS implementation recommendations and security considerations of [RFC7525], except with respect to the (D)TLS version.
クライアントとサーバーは、（D）TLSのバージョンを除き、[RFC7525]の（D）TLS実装の推奨事項とセキュリティの考慮事項に準拠する必要があります。
Since encryption of DNS using (D)TLS is a greenfield deployment, DNS clients and servers MUST implement only (D)TLS 1.2 or later. For example, implementing (D)TLS 1.3 [TLS-1.3] [DTLS-1.3] is also an option.
（D）TLSを使用したDNSの暗号化はグリーンフィールドの配備であるため、DNSクライアントとサーバーは（D）TLS 1.2以降のみを実装する必要があります。たとえば、（D）TLS 1.3 [TLS-1.3] [DTLS-1.3]の実装もオプションです。
Implementations MUST NOT offer or provide TLS compression, since compression can leak significant amounts of information, especially to a network observer capable of forcing the user to do an arbitrary DNS lookup in the style of the Compression Ratio Info-leak Made Easy (CRIME) attacks [CRIME].
実装はTLS圧縮を提供または提供してはなりません。圧縮は、特にユーザーに任意のDNSルックアップを圧縮率Info-leak Made Easy（CRIME）攻撃のスタイルで強制的に実行できるネットワークオブザーバーに大量の情報をリークする可能性があるためです。 [犯罪]。
Implementations compliant with this profile MUST implement the following items:
このプロファイルに準拠する実装は、次の項目を実装する必要があります。
o TLS session resumption without server-side state [RFC5077], which eliminates the need for the server to retain cryptographic state for longer than necessary. (This statement updates [RFC7858].)
o サーバー側の状態なしのTLSセッション再開[RFC5077]。これにより、サーバーが暗号化状態を必要以上に長く保持する必要がなくなります。 （このステートメントは[RFC7858]を更新します。）
o Raw public keys [RFC7250], which reduce the size of the ServerHello and can be used by servers that cannot obtain certificates (e.g., DNS servers on private networks). A client MUST only indicate support for raw public keys if it has an SPKI pin set pre-configured (for interoperability reasons).
o 生の公開鍵[RFC7250]。ServerHelloのサイズを縮小し、証明書を取得できないサーバー（プライベートネットワーク上のDNSサーバーなど）で使用できます。クライアントは、（相互運用性の理由で）SPKIピンセットが事前に構成されている場合にのみ、未加工の公開キーのサポートを示す必要があります。
Implementations compliant with this profile SHOULD implement the following items:
このプロファイルに準拠する実装は、次の項目を実装する必要があります。
o TLS False Start [RFC7918], which reduces round trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) DNS query.
o TLS False Start [RFC7918]。メッセージのTLSの2番目のフライト（ChangeCipherSpec）に（暗号化された）DNSクエリも含めることができるようにすることで、ラウンドトリップを削減します。
o The Cached Information Extension [RFC7924], which avoids transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake.
o Cached Information Extension [RFC7924]。クライアントが以前のTLSハンドシェイクからの情報をキャッシュした場合、サーバーの証明書と証明書チェーンの送信を回避します。
Guidance specific to TLS is provided in [RFC7858], and guidance specific to DTLS is provided in [RFC8094].
TLS固有のガイダンスは[RFC7858]で提供され、DTLS固有のガイダンスは[RFC8094]で提供されます。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
Security considerations discussed in [RFC7525], [RFC8094], and [RFC7858] apply to this document.
[RFC7525]、[RFC8094]、および[RFC7858]で説明されているセキュリティの考慮事項がこのドキュメントに適用されます。
DNS clients SHOULD implement (1) support for the mechanisms described in Section 8.2 and (2) offering a configuration option that limits authentication to using only those mechanisms (i.e., with no fallback to pure PKIX-based authentication) such that authenticating solely via the PKIX infrastructure can be avoided.
DNSクライアントは、（1）セクション8.2で説明されているメカニズムのサポートと（2）認証をそれらのメカニズムのみを使用するように制限する構成オプションを提供する必要があります（つまり、純粋なPKIXベースの認証にフォールバックせず）。 PKIXインフラストラクチャを回避できます。
This section makes suggestions for measures that can reduce the ability of attackers to infer information pertaining to encrypted client queries by other means (e.g., via an analysis of encrypted traffic size or via monitoring of the unencrypted traffic from a DNS recursive resolver to an authoritative server).
このセクションでは、攻撃者が暗号化されたクライアントクエリに関連する情報を他の手段（たとえば、暗号化されたトラフィックサイズの分析またはDNS再帰リゾルバーから権限のあるサーバーへの暗号化されていないトラフィックの監視を介して）で推測する能力を減らすことができる対策を提案します。 ）。
DNS-over-(D)TLS clients and servers SHOULD implement the following relevant DNS extensions:
DNS-over-（D）TLSクライアントとサーバーは、次の関連DNS拡張を実装する必要があります（SHOULD）。
o Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which allows encrypted queries and responses to hide their size, making analysis of encrypted traffic harder.
o DNSの拡張メカニズム（EDNS（0））パディング[RFC7830]。これにより、暗号化されたクエリと応答がそれらのサイズを隠し、暗号化されたトラフィックの分析が困難になります。
Guidance on padding policies for EDNS(0) is provided in [EDNS0-Pad-Policies].
EDNS（0）のパディングポリシーに関するガイダンスは、[EDNS0-Pad-Policies]で提供されています。
DNS-over-(D)TLS clients SHOULD implement the following relevant DNS extensions:
DNS-over-（D）TLSクライアントは、以下の関連するDNS拡張を実装する必要があります（SHOULD）。
o Privacy election per [RFC7871] ("Client Subnet in DNS Queries"). If a DNS client does not include an edns-client-subnet EDNS0 option with SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may potentially leak client address information to the upstream authoritative DNS servers. A DNS client ought to be able to inform the DNS resolver that it does not want any address information leaked, and the DNS resolver should honor that request.
o [RFC7871]（「DNSクエリのクライアントサブネット」）に基づくプライバシー選択。 DNSクライアントにクエリでSOURCE PREFIX-LENGTHが0に設定されたedns-client-subnet EDNS0オプションが含まれていない場合、DNSサーバーは上流の信頼できるDNSサーバーにクライアントアドレス情報をリークする可能性があります。 DNSクライアントは、アドレス情報の漏洩を望まないことをDNSリゾルバーに通知できる必要があり、DNSリゾルバーはその要求を受け入れる必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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, <https://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、 <https://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, <https://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月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://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月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<https：/ /www.rfc-editor.org/info/rfc6698>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc7250>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7671] Dukhovni、V。およびW. Hardaker、「DNSベースの名前付きエンティティの認証（DANE）プロトコル：更新および運用ガイダンス」、RFC 7671、DOI 10.17487 / RFC7671、2015年10月、<https：// www。 rfc-editor.org/info/rfc7671>。
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <https://www.rfc-editor.org/info/rfc7830>.
[RFC7830] Mayrhofer、A。、「The EDNS（0）Padding Option」、RFC 7830、DOI 10.17487 / RFC7830、May 2016、<https://www.rfc-editor.org/info/rfc7830>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <https://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月、<https：//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, <https://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月、<https://www.rfc-editor.org/info/ rfc7924>。
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.
[RFC8094] Reddy、T.、Wing、D。、およびP. Patil、「DNS over Datagram Transport Layer Security（DTLS）」、RFC 8094、DOI 10.17487 / RFC8094、2017年2月、<https：//www.rfc- editor.org/info/rfc8094>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty Security Conference, 2012, <https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf>.
[CRIME] Rizzo、J。およびT. Duong、「The CRIME Attack」、Ekoparty Security Conference、2012、<https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf>。
[dnssec-trigger] NLnetLabs, "Dnssec-Trigger", December 2017, <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[dnssec-trigger] NLnetLabs、「Dnssec-Trigger」、2017年12月、<https://www.nlnetlabs.nl/projects/dnssec-trigger/>。
[DTLS-1.3] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-dtls13-26, March 2018.
[DTLS-1.3] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「Datagram Transport Layer Security（DTLS）Protocol Version 1.3」、Work in Progress、draft-ietf-tls-dtls13-26、2018年3月。
[EDNS0-Pad-Policies] Mayrhofer, A., "Padding Policy for EDNS(0)", Work in Progress, draft-ietf-dprive-padding-policy-04, February 2018.
[EDNS0-Pad-Policies]マイヤーホーファー、A。、「EDNS（0）のパディングポリシー」、作業中、draft-ietf-dprive-padding-policy-04、2018年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https://www.rfc-editor.org/info/rfc2131>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<https://www.rfc-editor.org/info/rfc2132>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<https://www.rfc-editor.org/info/rfc3315>。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.
[RFC3646] Droms、R。、編、「IPv6の動的ホスト構成プロトコルのDNS構成オプション（DHCPv6）」、RFC 3646、DOI 10.17487 / RFC3646、2003年12月、<https://www.rfc-editor.org / info / rfc3646>。
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.
[RFC7227] Hankins、D.、Mrugalski、T.、Siodelski、M.、Jiang、S。、およびS. Krishnan、「新しいDHCPv6オプションを作成するためのガイドライン」、BCP 187、RFC 7227、DOI 10.17487 / RFC7227、2014年5月、<https://www.rfc-editor.org/info/rfc7227>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<https://www.rfc-editor.org/info/rfc7435>。
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7469] Evans、C.、Palmer、C。、およびR. Sleevi、「HTTPの公開キー固定拡張機能」、RFC 7469、DOI 10.17487 / RFC7469、2015年4月、<https://www.rfc-editor.org / info / rfc7469>。
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <https://www.rfc-editor.org/info/rfc7626>.
[RFC7626] Bortzmeyer、S。、「DNSプライバシーに関する考慮事項」、RFC 7626、DOI 10.17487 / RFC7626、2015年8月、<https://www.rfc-editor.org/info/rfc7626>。
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <https://www.rfc-editor.org/info/rfc7871>.
[RFC7871] Contavalli、C.、van der Gaast、W.、Lawrence、D。、およびW. Kumari、「DNSクエリのクライアントサブネット」、RFC 7871、DOI 10.17487 / RFC7871、2016年5月、<https：// www .rfc-editor.org / info / rfc7871>。
[TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-27, March 2018.
[TLS-1.3] Rescorla、E。、「Transport Layer Security（TLS）Protocol Version 1.3」、Work in Progress、draft-ietf-tls-tls13-27、2018年3月。
[TLS-DNSSEC-Chain-Ext] Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE Record and DNSSEC Authentication Chain Extension for TLS", Work in Progress, draft-ietf-tls-dnssec-chain-extension-06, January 2018.
[TLS-DNSSEC-Chain-Ext] Shore、M.、Barnes、R.、Huque、S。、およびW. Toorop、「TLSのためのDANEレコードおよびDNSSEC認証チェーン拡張」、作業中、draft-ietf- tls-dnssec-chain-extension-06、2018年1月。
This section presents a non-normative discussion of how DNS clients might probe for, and cache capabilities of, privacy-enabling DNS servers.
このセクションでは、DNSクライアントがプライバシーを有効にするDNSサーバーをプローブし、その機能をキャッシュする方法の非規範的な説明を示します。
Deployment of both DNS over TLS and DNS over DTLS will be gradual. Not all servers will support one or both of these protocols, and the well-known port might be blocked by some middleboxes. Clients will be expected to keep track of servers that support DNS over TLS and/or DNS over DTLS, as well as those that have been previously authenticated.
DNS over TLSとDNS over DTLSの両方の導入は段階的に行われます。すべてのサーバーがこれらのプロトコルの1つまたは両方をサポートするわけではなく、既知のポートが一部のミドルボックスによってブロックされる場合があります。クライアントは、DNS over TLSやDNS over DTLSをサポートするサーバーや、以前に認証されたサーバーを追跡することが求められます。
If no server capability information is available, then (unless otherwise specified by the configuration of the DNS client) DNS clients that implement both TLS and DTLS should try to authenticate using both protocols before failing or falling back to an unauthenticated or cleartext connection. DNS clients using an Opportunistic Privacy profile should try all available servers (possibly in parallel) in order to obtain an authenticated and encrypted connection before falling back. (RATIONALE: This approach can increase latency while discovering server capabilities but maximizes the chance of sending the query over an authenticated and encrypted connection.)
サーバー機能情報が利用できない場合、（DNSクライアントの構成で特に指定されていない限り）TLSとDTLSの両方を実装するDNSクライアントは、認証されていない接続またはクリアテキスト接続に失敗またはフォールバックする前に、両方のプロトコルを使用して認証を試行する必要があります。 Opportunistic Privacyプロファイルを使用するDNSクライアントは、フォールバックする前に認証および暗号化された接続を取得するために、使用可能なすべてのサーバーを（おそらく並行して）試行する必要があります。 （理論的根拠：このアプローチでは、サーバー機能の検出中にレイテンシを増やすことができますが、認証および暗号化された接続を介してクエリを送信する可能性を最大化します。）
Acknowledgments
謝辞
Thanks to the authors of both [RFC8094] and [RFC7858] for laying the groundwork for this document and for reviewing the contents. The authors would also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman, Christian Huitema, and John Levine for review and discussion of the ideas presented here.
[RFC8094]と[RFC7858]の両方の作成者に、このドキュメントの基礎を築き、内容をレビューしてくれたことに感謝します。著者はまた、ここに提示されたアイデアのレビューとディスカッションについて、John Dickinson、Shumon Huque、Melinda Shore、Gowri Visweswaran、Ray Bellis、Stephane Bortzmeyer、Jinmei Tatuya、Paul Hoffman、Christian Huitema、およびJohn Levineに感謝します。
Authors' Addresses
著者のアドレス
Sara Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
さら ぢｃきんそん しのづん いんてｒねｔ てｃｈのぉぎえｓ まｇだぇん せんｔれ おｘふぉｒｄ Ｓしえんせ ぱｒｋ おｘふぉｒｄ おＸ４ ４が うにてｄ きんｇどｍ
Email: sara@sinodun.com
URI: https://www.sinodun.com/
Daniel Kahn Gillmor ACLU 125 Broad Street, 18th Floor New York, NY 10004 United States of America
Daniel Kahn Gillmor ACLU 125 Broad Street、18th Floor New York、NY 10004アメリカ合衆国
Email: dkg@fifthhorseman.net
Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India
Tirumaleswar Reddy McAfee、Inc. Embassy Golf Link Business Park Bangalore、Karnataka、Indiaインド
Email: TirumaleswarReddy_Konda@McAfee.com