[要約] RFC 9464は、IKEv2構成ペイロード属性タイプを定義し、DoH、DoT、DoQなどの暗号化DNSプロトコルをサポートするDNSリゾルバを割り当てることを目的としています。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 9464 Orange
Category: Standards Track T. Reddy.K
ISSN: 2070-1721 Nokia
D. Wing
Cloud Software Group
V. Smyslov
ELVIS-PLUS
November 2023
This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ).
このドキュメントは、新しいインターネットキーエクスチェンジプロトコルバージョン2（IKEV2）構成ペイロード属性タイプを指定して、HTTPS（DOH）を超えるDNS、TLS（DOT）を超えるDNSなどの暗号化されたDNSプロトコルをサポートするDNSリゾルバーを割り当て、QUIC（DOQ）を超えるDNSなど。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9464.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9464で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. IKEv2 Configuration Payload Attribute Types for Encrypted DNS
3.1. ENCDNS_IP* Configuration Payload Attributes
3.2. ENCDNS_DIGEST_INFO Configuration Payload Attribute
4. IKEv2 Protocol Exchange
5. Subject Public Key Info (SPKI) Hash
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Configuration Payload Examples
A.1. Configuration of Encrypted IPv6 DNS Resolvers without
Suggested Values
A.2. Configuration of Encrypted IPv6 DNS Resolvers with
Suggested Values
A.3. Split DNS
Acknowledgments
Authors' Addresses
This document specifies a mechanism for assigning encrypted DNS configurations to an Internet Key Exchange Protocol Version 2 (IKEv2) initiator [RFC7296]. Specifically, it assigns one or more Authentication Domain Names (ADNs) of DNS resolvers that support encrypted DNS protocols. The specific protocols supported are described using the Service Parameters format defined in [RFC9460]; supported protocols include DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], and DNS over QUIC (DoQ) [RFC9250].
このドキュメントは、暗号化されたDNS構成をインターネットキーエクスチェンジプロトコルバージョン2（IKEV2）イニシエーター[RFC7296]に割り当てるメカニズムを指定します。具体的には、暗号化されたDNSプロトコルをサポートするDNSリゾルバーの1つ以上の認証ドメイン名（ADNS）を割り当てます。サポートされている特定のプロトコルは、[RFC9460]で定義されたサービスパラメーター形式を使用して説明されています。サポートされているプロトコルには、HTTPS（DOH）[RFC8484]、TLS（DOT）上のDNS（RFC7858]、およびDNSがQUIC（DOQ）[RFC9250]を超えるDNSが含まれます。
This document introduces three new IKEv2 Configuration Payload Attribute Types (Section 3) to add support for encrypted DNS resolvers. The ENCDNS_IP4 and ENCDNS_IP6 attribute types (Section 3.1) are used to provision ADNs, a list of IP addresses, and a set of service parameters. The ENCDNS_DIGEST_INFO attribute (Section 3.2) additionally allows a specific resolver certificate to be indicated by the IKEv2 responder.
このドキュメントでは、3つの新しいIKEV2構成ペイロード属性タイプ（セクション3）を導入して、暗号化されたDNSリゾルバーのサポートを追加します。ENCDNS_IP4およびENCDNS_IP6属性タイプ（セクション3.1）は、ADN、IPアドレスのリスト、および一連のサービスパラメーターのプロビジョニングに使用されます。ENCDNS_DIGEST_INFO属性（セクション3.2）により、IKEV2レスポンダーが特定のリゾルバー証明書を示すことができます。
The encrypted DNS resolver hosted by a Virtual Private Network (VPN) provider can get a domain-validated certificate from a public Certificate Authority (CA). The VPN client does not need to be provisioned with the root certificate of a private CA to authenticate the certificate of the encrypted DNS resolvers. The encrypted DNS resolver can run on private IP addresses, and its access can be restricted to clients connected to the VPN.
仮想プライベートネットワーク（VPN）プロバイダーがホストする暗号化されたDNSリゾルバーは、公的証明書当局（CA）からドメイン検証証明書を取得できます。VPNクライアントは、暗号化されたDNSリゾルバーの証明書を認証するために、プライベートCAのルート証明書を提供する必要はありません。暗号化されたDNSリゾルバーはプライベートIPアドレスで実行でき、そのアクセスはVPNに接続されたクライアントに制限できます。
For many years, typical designs have often assumed that the DNS resolver was usually located inside the protected domain, but they don't consider implementations where the DNS resolver could be located outside of it. With encrypted DNS, implementing the latter scenario becomes plausible. Note that existing VPN client implementations might not expect the discovered DNS resolver IP addresses to be outside of the covered IP address ranges of the VPN tunnel.
長年にわたり、典型的なデザインは、DNSリゾルバーが通常保護されたドメインの内側にあるとしばしば想定してきましたが、DNSリゾルバーがその外側にある可能性のある実装を考慮していません。暗号化されたDNSを使用すると、後者のシナリオを実装することが妥当になります。既存のVPNクライアントの実装は、発見されたDNS Resolver IPアドレスがVPNトンネルの対象IPアドレス範囲の外側にあるとは思わない場合があることに注意してください。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the terms defined in [RFC8499].
このドキュメントでは、[RFC8499]で定義されている用語を使用します。
Also, this document uses the terms defined in [RFC7296]. In particular, readers should be familiar with the terms "initiator" and "responder" as used in that document.
また、このドキュメントでは、[RFC7296]で定義されている用語を使用しています。特に、読者は、そのドキュメントで使用されている「イニシエーター」と「レスポンダー」という用語に精通している必要があります。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
Do53:
do53：
Refers to unencrypted DNS.
暗号化されていないDNSを指します。
Encrypted DNS:
暗号化されたDNS：
Refers to a scheme where DNS messages are sent over an encrypted channel. Examples of encrypted DNS are DoT, DoH, and DoQ.
暗号化されたチャネルを介してDNSメッセージが送信されるスキームを指します。暗号化されたDNSの例は、DOT、DOH、およびDOQです。
ENCDNS_IP*:
encdns_ip*：
Refers to any of the IKEv2 Configuration Payload Attribute Types defined in Section 3.1.
セクション3.1で定義されているIKEV2構成ペイロード属性タイプのいずれかを指します。
The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types, ENCDNS_IP4 and ENCDNS_IP6, are used to configure an initiator with encrypted DNS resolvers. Both attribute types share the format shown in Figure 1. The information included in these attributes adheres to the recommendation in Section 3.1.9 of [RFC9463].
ENCDNS_IP* IKEV2構成ペイロード属性タイプ、ENCDNS_IP4およびENCDNS_IP6は、暗号化されたDNSリゾルバーを使用してイニシエーターを構成するために使用されます。両方の属性タイプは、図1に示す形式を共有しています。これらの属性に含まれる情報は、[RFC9463]のセクション3.1.9の推奨に準拠しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+
|R| Attribute Type | Length |
+-+-----------------------------+---------------+---------------+
| Service Priority | Num Addresses | ADN Length |
+-------------------------------+---------------+---------------+
~ IP Address(es) ~
+---------------------------------------------------------------+
~ Authentication Domain Name ~
+---------------------------------------------------------------+
~ Service Parameters (SvcParams) ~
+---------------------------------------------------------------+
Figure 1: Format of ENCDNS_IP4 and ENCDNS_IP6 Configuration Attributes
図1：ENCDNS_IP4およびENCDNS_IP6構成属性の形式
The description of the fields shown in Figure 1 is as follows:
図1に示すフィールドの説明は次のとおりです。
R (Reserved, 1 bit):
R（予約済み、1ビット）：
This bit MUST be set to zero and MUST be ignored on receipt (see Section 3.15.1 of [RFC7296] for details).
このビットはゼロに設定する必要があり、領収書で無視する必要があります（詳細については、[RFC7296]のセクション3.15.1を参照）。
Attribute Type (15 bits):
属性タイプ（15ビット）：
Identifier for the Configuration Attribute Type. This is set to 27 for ENCDNS_IP4 or 28 for ENCDNS_IP6, as registered in Section 8.
構成属性タイプの識別子。これは、セクション8に登録されているように、ENCDNS_IP4の場合は27、ENCDNS_IP6で28に設定されています。
Length (2 octets, unsigned integer):
長さ（2オクテット、符号なし整数）：
Length of the enclosed data in octets. In particular, this field is set to: * 0, if the Configuration payload has type (1) CFG_REQUEST and no specific DNS resolver is requested or (2) CFG_ACK. If the "Length" field is set to 0, then the subsequent fields shown in Figure 1 are not present. * (4 + 'Length of the ADN' + N * 4 + 'Length of SvcParams') for ENCDNS_IP4 attributes if the Configuration payload has type CFG_REQUEST, CFG_REPLY, or CFG_SET, with N being the number of included IPv4 addresses ("Num Addresses"). * (4 + 'Length of the ADN' + N * 16 + 'Length of SvcParams') for ENCDNS_IP6 attributes if the Configuration payload has type CFG_REQUEST, CFG_REPLY, or CFG_SET, with N being the number of included IPv6 addresses ("Num Addresses").
オクテットの囲まれたデータの長さ。特に、このフィールドは次のように設定されています。 * 0、構成ペイロードにタイプ（1）CFG_REQUESTがあり、特定のDNSリゾルバーが要求されないか、（2）CFG_ACKに設定されています。「長さ」フィールドが0に設定されている場合、図1に示す後続のフィールドは存在しません。*（adn 'n * 4' svcparamsの長さ4 '）encdns_ip4属性の場合、構成ペイロードにタイプCFG_REQUEST、CFG_REPLY、またはCFG_SETが含まれている場合、nは含まれているIPv4アドレスの数（「numアドレス」）です。*（adn 'n * 16' svcparamsの長さ4 '）encdns_ip6属性の場合、構成ペイロードにタイプCFG_REQUEST、CFG_REPLY、またはCFG_SETが含まれている場合、nはIPv6アドレスの数（「numアドレス」）です。
Service Priority (2 octets):
サービスの優先順位（2オクテット）：
The priority of this attribute compared to other ENCDNS_IP* instances. This 16-bit unsigned integer is interpreted following the rules specified in Section 2.4.1 of [RFC9460]. As AliasMode (Section 2.4.2 of [RFC9460]) is not supported, this field MUST NOT be set to 0. Note that AliasMode is not supported because such a mode will trigger additional Do53 queries while the data can be supplied directly in the IKE response.
他のencdns_ip*インスタンスと比較したこの属性の優先度。この16ビットの署名されていない整数は、[RFC9460]のセクション2.4.1で指定されたルールに従って解釈されます。AliAsMode（[RFC9460]のセクション2.4.2）がサポートされていないため、このフィールドは0に設定してはなりません。このようなモードは追加のdo53クエリをトリガーし、データをikeで直接提供できるため、アリスマデはサポートされていないことに注意してください。応答。
Num Addresses (1 octet):
numアドレス（1オクテット）：
Indicates the number of enclosed IPv4 (for ENCDNS_IP4) or IPv6 (for ENCDNS_IP6) addresses. This value MUST NOT be set to 0 if the Configuration payload has type CFG_REPLY or CFG_SET. This may be set to 0 in CFG_REQUEST to indicate that no IP address is encoded in the attribute.
囲まれたIPv4（encdns_ip4の場合）またはIPv6（encdns_ip6用）のアドレスの数を示します。構成ペイロードにタイプCFG_REPLYまたはCFG_SETがある場合、この値を0に設定しないでください。これは、CFG_REQUESTで0に設定され、属性にIPアドレスがエンコードされていないことを示します。
ADN Length (1 octet):
ADN長（1オクテット）：
Indicates the length of the "Authentication Domain Name" field in octets. When set to 0, this means that no ADN is enclosed in the attribute.
オクテットの「認証ドメイン名」フィールドの長さを示します。0に設定すると、これはADNが属性に囲まれていないことを意味します。
IP Address(es) (variable):
IPアドレス（es）（変数）：
Includes one or more IP addresses that can be used to reach the encrypted DNS resolver identified by the ADN. For ENCDNS_IP4, this field contains one or more 4-octet IPv4 addresses, and for ENCDNS_IP6, this field contains one or more 16-octet IPv6 addresses.
ADNによって識別された暗号化されたDNSリゾルバーに到達するために使用できる1つ以上のIPアドレスが含まれています。ENCDNS_IP4の場合、このフィールドには1つまたは複数の4-OCTET IPv4アドレスが含まれており、Encdns_IP6の場合、このフィールドには1つ以上の16オクテットのIPv6アドレスが含まれています。
Authentication Domain Name (variable):
認証ドメイン名（変数）：
A fully qualified domain name of the encrypted DNS resolver, in DNS presentation format and using an Internationalized Domain Names for Applications (IDNA) A-label [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, CR). An example of a valid ADN for a DoH server is "doh1.example.com".
DNSプレゼンテーション形式で、暗号化されたDNS Resolverの完全に適格なドメイン名、およびアプリケーション（IDNA）A-Label [RFC5890]の国際化ドメイン名を使用しています。名前には、ターミネーター（null、crなど）を含めてはなりません。DOHサーバーの有効なADNの例は、「doh1.example.com」です。
Service Parameters (SvcParams) (variable):
サービスパラメーター（SVCPARAMS）（変数）：
Specifies a set of service parameters that are encoded following the same rules for encoding SvcParams using the wire format specified in Section 2.2 of [RFC9460]. Section 3.1.5 of [RFC9463] lists a set of service parameters that are recommended to be supported by implementations. The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams, as they are superseded by the included IP addresses. If no "port" service parameter is included, this indicates that default port numbers should be used. As a reminder, the default port number is 853 for DoT (Section 6 of [RFC7858]), 443 for DoH (Section 8.1 of [RFC8484]), and 853 for DoQ (Section 8 of [RFC9250]). The service parameters apply to all IP addresses in the ENCDNS_IP* Configuration Payload Attribute.
[RFC9460]のセクション2.2で指定されたワイヤ形式を使用して、SVCparamsをエンコードするための同じルールに従ってエンコードされる一連のサービスパラメーターを指定します。[RFC9463]のセクション3.1.5には、実装によってサポートされることが推奨される一連のサービスパラメーターを示します。サービスパラメーターには、含まれているIPアドレスに取って代わられているため、「IPv4hint」または「IPv6Hint」SVCPARAMSを含めるべきではありません。「ポート」サービスパラメーターが含まれていない場合、これはデフォルトのポート番号を使用する必要があることを示します。リマインダーとして、デフォルトのポート番号は、DOTで853（[RFC7858]のセクション6）、DOHの場合は443（[RFC8484]のセクション8.1）、DOQで853（[RFC9250]のセクション8）です。サービスパラメーターは、ENCDNS_IP*構成ペイロード属性のすべてのIPアドレスに適用されます。
The ENCDNS_DIGEST_INFO Configuration Payload Attribute (Figure 2) allows IKEv2 responders to specify a certificate digest that initiators can use when validating TLS connections to encrypted resolvers. This attribute can also be sent by the initiator to request specific hash algorithms for such digests.
ENCDNS_DIGEST_INFO構成ペイロード属性（図2）により、IKEV2レスポンダーは、TLS接続を暗号化されたリゾルバーに検証するときにイニシエーターが使用できる証明書ダイジェストを指定できます。この属性は、そのようなダイジェストの特定のハッシュアルゴリズムを要求するために、イニシエーターによって送信することもできます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+
|R| Attribute Type | Length |
+-+-------------+---------------+-------------------------------+
| Num Hash Algs | ADN Length | |
+---------------+---------------+ +
~ Authentication Domain Name ~
+---------------------------------------------------------------+
~ List of Hash Algorithm Identifiers ~
+---------------------------------------------------------------+
~ Certificate Digest ~
+---------------------------------------------------------------+
Figure 2: ENCDNS_DIGEST_INFO Attribute Format
図2：encdns_digest_info属性形式
Some of the fields shown in Figure 2 can be omitted, as further detailed below.
以下にさらに詳しく説明するように、図2に示すフィールドの一部は省略できます。
The format of the ENCDNS_DIGEST_INFO attribute if the Configuration payload has type CFG_REQUEST is shown in Figure 3.
構成ペイロードがタイプCFG_REQUESTを持っている場合、ENCDNS_DIGEST_INFO属性の形式を図3に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+
|R| Attribute Type | Length |
+-+-------------+---------------+-------------------------------+
| Num Hash Algs | ADN Length | |
+---------------+---------------+ +
~ List of Hash Algorithm Identifiers ~
+---------------------------------------------------------------+
Figure 3: ENCDNS_DIGEST_INFO Attribute Format in CFG_REQUEST
図3：CFG_REQUESTのENCDNS_DIGEST_INFO属性形式
The description of the fields shown in Figure 3 is as follows:
図3に示すフィールドの説明は次のとおりです。
R (Reserved, 1 bit):
R（予約済み、1ビット）：
This bit MUST be set to zero and MUST be ignored on receipt (see Section 3.15.1 of [RFC7296] for details).
このビットはゼロに設定する必要があり、領収書で無視する必要があります（詳細については、[RFC7296]のセクション3.15.1を参照）。
Attribute Type (15 bits):
属性タイプ（15ビット）：
Identifier for the Configuration Attribute Type. This is set to 29; see Section 8.
構成属性タイプの識別子。これは29に設定されています。セクション8を参照してください。
Length (2 octets, unsigned integer):
長さ（2オクテット、符号なし整数）：
Length of the enclosed data in octets. This field MUST be set to "2 + (2 * 'number of included hash algorithm identifiers')".
オクテットの囲まれたデータの長さ。このフィールドは、「2 * '含まれるハッシュアルゴリズム識別子の数）」に設定する必要があります。
Num Hash Algs (1 octet):
num hash algs（1オクテット）：
Indicates the number of identifiers included in the "List of Hash Algorithm Identifiers" field. This field MUST be set to "(Length - 2)/2".
「ハッシュアルゴリズム識別子のリスト」フィールドに含まれる識別子の数を示します。このフィールドは、「（長さ-2）/2」に設定する必要があります。
ADN Length (1 octet):
ADN長（1オクテット）：
MUST be set to 0.
0に設定する必要があります。
List of Hash Algorithm Identifiers (variable):
ハッシュアルゴリズム識別子のリスト（変数）：
Specifies a list of 16-bit hash algorithm identifiers that are supported by the encrypted DNS client. This list may be controlled by a local policy. The values of this field are identifiers taken from "IKEv2 Hash Algorithms" on IANA's "Internet Key Exchange Version 2 (IKEv2) Parameters" registry [IANA-IKE-HASH]. There is no padding between the hash algorithm identifiers. Note that SHA2-256 is mandatory to implement (see Section 5).
暗号化されたDNSクライアントによってサポートされている16ビットハッシュアルゴリズム識別子のリストを指定します。このリストは、ローカルポリシーによって制御される場合があります。このフィールドの値は、IANAの「Internet Key Exchangeバージョン2（IKEV2）パラメーター」の「IKEV2ハッシュアルゴリズム」から取得した識別子です。ハッシュアルゴリズム識別子の間にパディングはありません。SHA2-256は実装に必須であることに注意してください（セクション5を参照）。
The format of the ENCDNS_DIGEST_INFO attribute if the Configuration payload has type CFG_REPLY or CFG_SET is shown in Figure 4.
構成ペイロードがタイプCFG_REPLYまたはCFG_SETを持っている場合、ENCDNS_DIGEST_INFO属性の形式を図4に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+
|R| Attribute Type | Length |
+-+-------------+---------------+-------------------------------+
| Num Hash Algs | ADN Length | |
+---------------+---------------+ +
~ Authentication Domain Name ~
+-------------------------------+-------------------------------+
| Hash Algorithm Identifier | ~
+-------------------------------+ +
~ Certificate Digest ~
+---------------------------------------------------------------+
Figure 4: ENCDNS_DIGEST_INFO Attribute Format in CFG_REPLY or CFG_SET
図4：cfg_replyまたはcfg_setのencdns_digest_info属性形式
The description of the fields shown in Figure 4 is as follows:
図4に示すフィールドの説明は次のとおりです。
R (Reserved, 1 bit):
R（予約済み、1ビット）：
This bit MUST be set to zero and MUST be ignored on receipt (see Section 3.15.1 of [RFC7296] for details).
このビットはゼロに設定する必要があり、領収書で無視する必要があります（詳細については、[RFC7296]のセクション3.15.1を参照）。
Attribute Type (15 bits):
属性タイプ（15ビット）：
Identifier for the Configuration Attribute Type. This is set to 29; see Section 8.
構成属性タイプの識別子。これは29に設定されています。セクション8を参照してください。
Length (2 octets, unsigned integer):
長さ（2オクテット、符号なし整数）：
Length of the data in octets.
オクテットのデータの長さ。
Num Hash Algs (1 octet):
num hash algs（1オクテット）：
MUST be set to 1.
1に設定する必要があります。
ADN Length (1 octet):
ADN長（1オクテット）：
Indicates the length of the "Authentication Domain Name" field in octets. When set to 0, this means that the digest applies on the ADN conveyed in the ENCDNS_IP* Configuration Payload Attribute.
オクテットの「認証ドメイン名」フィールドの長さを示します。0に設定すると、これは、encdns_ip*構成ペイロード属性で伝達されるADNにダイジェストが適用されることを意味します。
Authentication Domain Name (variable):
認証ドメイン名（変数）：
A fully qualified domain name of the encrypted DNS resolver following the syntax defined in [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, CR). A name is included only when multiple ADNs are included in the ENCDNS_IP* Configuration Payload Attribute.
[RFC5890]で定義された構文に続く、暗号化されたDNSリゾルバーの完全に適格なドメイン名。名前には、ターミネーター（null、crなど）を含めてはなりません。名前は、ENCDNS_IP*構成ペイロード属性に複数のADNが含まれている場合にのみ含まれています。
Hash Algorithm Identifier (2 octets):
ハッシュアルゴリズム識別子（2オクテット）：
Specifies the 16-bit hash algorithm identifier selected by the DNS resolver to generate the digest of its certificate.
DNSリゾルバーによって選択された16ビットハッシュアルゴリズム識別子を指定して、証明書のダイジェストを生成します。
Certificate Digest (variable):
証明書ダイジェスト（変数）：
Includes the Subject Public Key Info (SPKI) hash (Section 5) of the encrypted DNS resolver certificate using the algorithm identified in the "Hash Algorithm Identifier" field. The length of this field is "Length - 4 - 'ADN Length'".
「ハッシュアルゴリズム識別子」フィールドで識別されたアルゴリズムを使用して、暗号化されたDNSリゾルバー証明書の主題公開鍵情報（SPKI）ハッシュ（セクション5）が含まれます。このフィールドの長さは「長さ-4- 'adn length」です。
The ENCDNS_DIGEST_INFO attribute may be present in the Configuration payload of CFG_ACK. In such a case, the ENCDNS_DIGEST_INFO MUST be returned with zero-length data.
ENCDNS_DIGEST_INFO属性は、CFG_ACKの構成ペイロードに存在する場合があります。そのような場合、encdns_digest_infoはゼロ長データで返される必要があります。
As discussed in Section 3.15.1 of [RFC7296], there are no defined uses for the CFG_SET/CFG_ACK exchange. The use of the ENCDNS_DIGEST_INFO attribute for these messages is provided for completeness.
[RFC7296]のセクション3.15.1で説明したように、CFG_SET/CFG_ACK Exchangeの定義された使用はありません。これらのメッセージのencdns_digest_info属性の使用は、完全性のために提供されます。
This section describes how the attributes defined in Section 3 are used to configure an IKEv2 initiator with one or more encrypted DNS resolvers. As a reminder, badly formatted attributes or unacceptable fields are handled as per Section 2.21 of [RFC7296].
このセクションでは、セクション3で定義されている属性を使用して、1つ以上の暗号化されたDNSリゾルバーを使用してIKEV2イニシエーターを構成する方法について説明します。リマインダーとして、[RFC7296]のセクション2.21に従って、ひどくフォーマットされた属性または容認できないフィールドが処理されます。
Initiators first indicate support for encrypted DNS by including ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders supply encrypted DNS configuration by including ENCDNS_IP* attributes in their CFG_REPLY payloads. Concretely:
イニシエーターは、CFG_REQUESTペイロードにENCDNS_IP*属性を含めることにより、暗号化されたDNSのサポートを最初に示します。レスポンダーは、CFG_REPLYペイロードにENCDNS_IP*属性を含めることにより、暗号化されたDNS構成を提供します。具体的に：
* If the initiator supports encrypted DNS, it includes either or both of the ENCDNS_IP4 and ENCDNS_IP6 attributes in its CFG_REQUEST. If the initiator does not want to request specific DNS resolvers, it sets the "Length" field to 0 for the attribute. For a given attribute type, the initiator MAY send either an empty attribute or a list of distinct suggested resolvers. The initiator MAY also include the ENCDNS_DIGEST_INFO attribute with a list of hash algorithms that are supported by the encrypted DNS client.
* イニシエーターが暗号化されたDNSをサポートする場合、CFG_REQUESTにENCDNS_IP4およびENCDNS_IP6属性のいずれかまたは両方が含まれます。イニシエーターが特定のDNSリゾルバーを要求したくない場合、属性の「長さ」フィールドを0に設定します。特定の属性タイプの場合、イニシエーターは空の属性または異なる推奨リゾルバーのリストのいずれかを送信する場合があります。イニシエーターには、暗号化されたDNSクライアントによってサポートされているハッシュアルゴリズムのリストを含むENCDNS_DIGEST_INFO属性を含めることもできます。
* If the request includes multiple bitwise identical attributes, only the first occurrence is processed, and the rest SHOULD be ignored by the responder. The responder MAY discard the full request if the count of repeated attributes exceeds an (implementation-specific) threshold.
* リクエストに複数のビットごとの同一属性が含まれている場合、最初の発生のみが処理され、残りはレスポンダーによって無視される必要があります。繰り返される属性のカウントが（実装固有の）しきい値を超える場合、レスポンダーは完全な要求を破棄することができます。
* For each ENCDNS_IP* attribute from the CFG_REQUEST, if the responder supports the corresponding address family, and absent any policy restrictions, the responder sends back one or more ENCDNS_IP* attributes in the CFG_REPLY with an appropriate list of IP addresses, service parameters, and an ADN. The list of IP addresses MUST include at least one IP address. The service parameters SHOULD include at least the "alpn" service parameter. The "alpn" service parameter may not be required in contexts such as a variant of DNS over the Constrained Application Protocol (CoAP) where the messages are encrypted using Object Security for Constrained RESTful Environments (OSCORE) [RFC8613].
* CFG_REQUESTからの各ENCDNS_IP*属性について、レスポンダーが対応するアドレスファミリをサポートし、ポリシーの制限がない場合、ResponderはCFG_REPの1つまたは複数のENCDNS_IP*属性を、IPアドレス、サービスパラメーター、およびサービスパラメーターの適切なリストとともに送り返します。adn。IPアドレスのリストには、少なくとも1つのIPアドレスを含める必要があります。サービスパラメーターには、少なくとも「ALPN」サービスパラメーターを含める必要があります。「ALPN」サービスパラメーターは、Constared Restful環境（OSCORE）[RFC8613]のオブジェクトセキュリティを使用してメッセージが暗号化されている制約付きアプリケーションプロトコル（COAP）を介したDNSのバリアントなどのコンテキストでは必要ない場合があります。
* The responder MAY ignore suggested values from the initiator (if any). Multiple instances of the same ENCDNS_IP* attribute MAY be returned if distinct ADNs or service parameters need to be assigned to the initiator. In such instances, the different attributes can have matching or distinct IP addresses. These instances MUST be presented to a local DNS client following their service priority (i.e., a smaller service priority value indicates a higher preference).
* レスポンダーは、イニシエーターから推奨される値を無視する場合があります（ある場合）。異なるADNまたはサービスパラメーターをイニシエーターに割り当てる必要がある場合、同じENCDNS_IP*属性の複数のインスタンスを返すことができます。そのような場合、異なる属性には一致または異なるIPアドレスを持つことができます。これらのインスタンスは、サービスの優先順位に従ってローカルDNSクライアントに提示する必要があります（つまり、サービスの優先順位値が小さい場合は、より高い好みを示します）。
* In addition, the responder MAY return the ENCDNS_DIGEST_INFO attribute to convey a digest of the certificate of the encrypted DNS and the identifier of the hash algorithm that is used to generate the digest.
* さらに、Responderは、ENCDNS_DIGEST_INFO属性を返して、暗号化されたDNSの証明書と、ダイジェストを生成するために使用されるハッシュアルゴリズムの識別子のダイジェストを伝えることができます。
* If the CFG_REQUEST includes an ENCDNS_IP* attribute but the CFG_REPLY does not include an ENCDNS_IP* attribute matching the requested address family, this is an indication that the requested address family is not supported by the responder or the responder is not configured to provide corresponding resolver addresses.
* CFG_REQUESTにENCDNS_IP*属性が含まれているが、CFG_REPLYに要求された住所ファミリに一致するENCDNS_IP*属性が含まれていない場合、これは要求されたアドレスファミリが応答者またはレスポンダーによってサポートされていないことを示しています。。
* If the initiator receives both ENCDNS_IP* and INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, it is RECOMMENDED that the initiator use the encrypted DNS resolvers.
* イニシエーターがENCDNS_IP*と内部_IP6_DNS（またはinternal_ip4_dns）属性の両方を受信する場合、イニシエーターは暗号化されたDNSリゾルバーを使用することをお勧めします。
The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, or DoQ) with the address or addresses conveyed in ENCDNS_IP* and uses the mechanisms discussed in Section 8 of [RFC8310] to authenticate the DNS resolver certificate using the ADN conveyed in ENCDNS_IP*.
DNSクライアントは、ENCDNS_IP*で伝えられたアドレスまたはアドレスを使用して、暗号化されたDNSセッション（DOT、DOH、またはDOQなど）を確立し、[RFC8310]のセクション8で説明したメカニズムを使用して、伝えられたADNを使用してDNS Resolver証明書を認証するDNS Resolver証明書を使用します。encdns_ip*。
If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the client has to create an SPKI hash (Section 5) of the DNS resolver certificate received in the TLS handshake using the negotiated hash algorithm in the ENCDNS_DIGEST_INFO attribute. If the computed digest for an ADN matches the digest sent in the ENCDNS_DIGEST_INFO attribute, the encrypted DNS resolver certificate is successfully validated. If so, the client continues with the TLS connection as normal. Otherwise, the client MUST treat the resolver certificate validation failure as a non-recoverable error. This approach is similar to certificate usage PKIX-EE(1) with selector SPKI(1) as defined in [RFC7671], but without PKIX validation.
CFG_REPLYにENCDNS_DIGEST_INFO属性が含まれている場合、クライアントは、ENCDNS_DIGEST_INFO属性のネゴシエートハッシュアルゴリズムを使用して、TLSハンドシェイクで受信したDNSリゾルバー証明書のSPKIハッシュ（セクション5）を作成する必要があります。ADNの計算されたダイジェストがENCDNS_DIGEST_INFO属性で送信されたダイジェストと一致する場合、暗号化されたDNSリゾルバー証明書が正常に検証されます。その場合、クライアントは通常どおりTLS接続を続行します。それ以外の場合、クライアントは、Resolver証明書の検証障害を回復不可能なエラーとして扱う必要があります。このアプローチは、[RFC7671]で定義されているように、Selector SPKI（1）を使用した証明書の使用PKIX-EE（1）に似ていますが、PKIX検証はありません。
If the IPsec connection is a split-tunnel configuration and the initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS client resolves the internal names using ENCDNS_IP* DNS resolvers.
IPSEC接続がスプリットトンネル構成であり、イニシエーターが[RFC8598]に従ってinternal_dns_domainをネゴシエートした場合、DNSクライアントはENCDNS_IP* DNSリゾルバーを使用して内部名を解決します。
Note: [RFC8598] requires that the INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attribute be present when INTERNAL_DNS_DOMAIN is included. This specification relaxes that constraint in the presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* attributes are supplied, responders are allowed to include INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes.
注：[RFC8598]では、内部_IP6_DNS（またはinternal_ip4_dns）属性がinternal_dns_domainが含まれている場合に存在する必要があります。この仕様は、encdns_ip*属性の存在下でその制約を緩和します。つまり、internal_ip6_dns（またはinternal_ip4_dns）属性がない場合でも、encdns_ip*属性が提供される場合、レスポンダーはinternal_dns_domainを含めることができます。
The SPKI hash of the encrypted DNS resolver certificate is the output of a cryptographic hash algorithm whose input is the DER-encoded ASN.1 representation of the SPKI.
暗号化されたDNSリゾルバー証明書のSPKIハッシュは、入力がDer-Encoded ASN.1 SPKIの表現である暗号化ハッシュアルゴリズムの出力です。
Implementations MUST support SHA2-256 [RFC6234].
実装はSHA2-256 [RFC6234]をサポートする必要があります。
This document adheres to the security considerations defined in [RFC7296]. In particular, this document does not alter the trust that the initiator has placed on the DNS configuration provided by a responder.
この文書は、[RFC7296]で定義されているセキュリティ上の考慮事項に準拠しています。特に、このドキュメントは、イニシエーターがレスポンダーが提供するDNS構成に配置した信頼を変更するものではありません。
Networks are susceptible to internal attacks as discussed in Section 3.2 of [INT-THREAT-MOD]. Hosting encrypted DNS resolvers even in the case of split-VPN configuration can minimize the attack vector (e.g., a compromised network device cannot monitor/modify DNS traffic). This specification describes a mechanism for restricting access to the DNS messages to only the parties that need to know.
ネットワークは、[Int-Threat-Mod]のセクション3.2で説明したように、内部攻撃の影響を受けやすい。Split-VPN構成の場合でも暗号化されたDNSリゾルバーをホストすると、攻撃ベクトルを最小限に抑えることができます（たとえば、侵害されたネットワークデバイスはDNSトラフィックを監視/変更できません）。この仕様には、DNSメッセージへのアクセスを知る必要がある当事者のみに制限するメカニズムが説明されています。
If the IKEv2 responder has used the NULL Authentication method [RFC7619] to authenticate itself, the initiator MUST NOT use returned ENCDNS_IP* resolvers configuration unless the initiator is preconfigured, e.g., in the operating system or the application.
IKEV2 ResponderがNull認証方法[RFC7619]を使用して認証した場合、イニシエーターがオペレーティングシステムまたはアプリケーションで事前に設定されていない限り、イニシエーターは返されたENCDNS_IP* Resolvers構成を使用してはなりません。
This specification does not extend the scope of accepting DNSSEC trust anchors beyond the usage guidelines defined in Section 6 of [RFC8598].
この仕様は、[RFC8598]のセクション6で定義されている使用ガイドラインを超えて、DNSSECトラストアンカーを受け入れる範囲を拡張しません。
As discussed in [RFC9076], the use of encrypted DNS does not reduce the data available in the DNS resolver. For example, the reader may refer to Section 8 of [RFC8484] or Section 7 of [RFC9250] for a discussion on specific privacy considerations for encrypted DNS.
[RFC9076]で説明したように、暗号化されたDNSの使用は、DNSリゾルバーで利用可能なデータを削減しません。たとえば、読者は、暗号化されたDNSの特定のプライバシーに関する考慮事項に関する議論のために、[RFC8484]のセクション8または[RFC9250]のセクション7を参照することができます。
IANA has assigned the following new IKEv2 Configuration Payload Attribute Types in the "IKEv2 Configuration Payload Attribute Types" namespace available at [IANA-IKE-CFG].
IANAは、[IANA-kfg]で利用可能な「ikev2構成ペイロード属性タイプ」という名前の「ikev2構成ペイロード属性タイプ」に、次の新しいikev2構成ペイロード属性タイプを割り当てました。
+=======+====================+=============+===========+===========+
| Value | Attribute Type | Multivalued | Length | Reference |
+=======+====================+=============+===========+===========+
| 27 | ENCDNS_IP4 | YES | 0 or more | RFC 9464 |
+-------+--------------------+-------------+-----------+-----------+
| 28 | ENCDNS_IP6 | YES | 0 or more | RFC 9464 |
+-------+--------------------+-------------+-----------+-----------+
| 29 | ENCDNS_DIGEST_INFO | YES | 0 or more | RFC 9464 |
+-------+--------------------+-------------+-----------+-----------+
Table 1
[IANA-IKE-HASH]
IANA, "IKEv2 Hash Algorithms",
<https://www.iana.org/assignments/ikev2-parameters/>.
[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>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[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,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[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>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8598, DOI 10.17487/RFC8598, May 2019,
<https://www.rfc-editor.org/info/rfc8598>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[IANA-IKE-CFG]
IANA, "IKEv2 Configuration Payload Attribute Types",
<https://www.iana.org/assignments/ikev2-parameters/>.
[INT-THREAT-MOD]
Arkko, J. and S. Farrell, "Challenges and Changes in the
Internet Threat Model", Work in Progress, Internet-Draft,
draft-arkko-farrell-arch-model-t-04, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-arkko-
farrell-arch-model-t-04>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<https://www.rfc-editor.org/info/rfc7619>.
[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>.
[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>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
DOI 10.17487/RFC9076, July 2021,
<https://www.rfc-editor.org/info/rfc9076>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>.
Figure 5 depicts an example of a CFG_REQUEST to request the configuration of IPv6 DNS resolvers without providing any suggested values. In this example, the initiator uses the ENCDNS_DIGEST_INFO attribute to indicate that the encrypted DNS client supports SHA2-256 (2), SHA2-384 (3), and SHA2-512 (4) hash algorithms for certificate digests. The label of these algorithms is taken from [IANA-IKE-HASH]. The use of INTERNAL_IP6_ADDRESS is explained in [RFC7296] and thus is not reiterated here.
図5は、推奨される値を提供せずにIPv6 DNSリゾルバーの構成を要求するCFG_REQUESTの例を示しています。この例では、イニシエーターはENCDNS_DIGEST_INFO属性を使用して、暗号化されたDNSクライアントがSHA2-256（2）、SHA2-384（3）、およびSHA2-512（4）ハッシュアルゴリズムをサポートしていることを示します。これらのアルゴリズムのラベルは、[iana-yik-hash]から取得されます。internal_ip6_addressの使用は[RFC7296]で説明されているため、ここでは繰り返されません。
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6()
ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
Figure 5: Example of a CFG_REQUEST
図5：CFG_REQUESTの例
Figure 6 depicts an example of a CFG_REPLY that can be sent by a responder as a response to the above CFG_REQUEST. This response indicates the following information to identify the encrypted DNS resolver:
図6は、上記のCFG_REQUESTへの応答としてレスポンダーが送信できるCFG_REPLYの例を示しています。この応答は、暗号化されたDNSリゾルバーを特定するための次の情報を示しています。
* Its service priority, which is 1.
* そのサービスの優先順位は1です。
* Its single (1) IPv6 address (2001:db8:99:88:77:66:55:44).
* その単一（1）IPv6アドレス（2001：DB8：99：88：77：66：55：44）。
* Its ADN (doh.example.com). This ADN has a length of 15.
* そのadn（doh.example.com）。このADNの長さは15です。
* Its supported HTTP version (h2).
* サポートされているHTTPバージョン（H2）。
* The relative form of the URI Template (/dns-query{?dns}).
* URIテンプレートの相対形式（/dns-query {？dns}）。
* The SPKI hash of the resolver's certificate using SHA2-256 (8b6e7a5971cc6bb0b4db5a71...).
* SHA2-256（8B6E7A5971CC6BB0B4DB5A71 ...）を使用したResolverの証明書のSPKIハッシュ。
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64)
ENCDNS_IP6(1, 1, 15,
(2001:db8:99:88:77:66:55:44),
"doh.example.com",
(alpn=h2 dohpath=/dns-query{?dns}))
ENCDNS_DIGEST_INFO(0, SHA2-256,
8b6e7a5971cc6bb0b4db5a71...)
Figure 6: Example of a CFG_REPLY
図6：CFG_REPLYの例
In the example depicted in Figure 6, no ADN is included in the ENCDNS_DIGEST_INFO attribute because only one ADN is provided in the ENCDNS_IP6 attribute. Identifying the encrypted resolver associated with the supplied digest is therefore unambiguous.
図6に示す例では、ENCDNS_IP6属性に1つのADNのみが提供されているため、ADNはENCDNS_DIGEST_INFO属性に含まれていません。したがって、提供されたダイジェストに関連付けられた暗号化されたリゾルバーを特定することは明確です。
An initiator may provide suggested values in the CFG_REQUEST when requesting an encrypted DNS resolver. For example, the initiator may:
イニシエーターは、暗号化されたDNSリゾルバーを要求するときに、CFG_Requestで推奨される値を提供する場合があります。たとえば、イニシエーターは次のとおりです。
* Indicate a preferred resolver that is identified by an IPv6 address (see Figure 7).
* IPv6アドレスによって識別される優先リゾルバーを示します（図7を参照）。
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 1, 0,
(2001:db8:99:88:77:66:55:44))
Figure 7: Example of a CFG_REQUEST with a Preferred Resolver Identified by Its IP Address
図7：IPアドレスで識別された優先リゾルバーを備えたCFG_REQUESTの例
* Indicate a preferred resolver that is identified by an ADN (see Figure 8).
* ADNによって識別される優先リゾルバーを示します（図8を参照）。
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 0, 15, "doh.example.com")
Figure 8: Example of a CFG_REQUEST with a Preferred Resolver Identified by Its ADN
図8：ADNによって識別された優先リゾルバーを備えたCFG_REQUESTの例
* Indicate a preferred transport protocol (DoT, in the example depicted in Figure 9).
* 好ましい輸送プロトコルを示します（図9に示す例では、DOT）。
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 0, 0, (alpn=dot))
Figure 9: Example of a CFG_REQUEST with a Preferred Transport Protocol
図9：優先輸送プロトコルを備えたCFG_REQUESTの例
* or any combination thereof.
* またはその組み合わせ。
An initiator may also indicate that it supports Split DNS by including the INTERNAL_DNS_DOMAIN attribute in a CFG_REQUEST as shown in Figure 10. In this example, the initiator does not indicate any preference for the requested encrypted DNS server, nor does it indicate which DNS queries will be forwarded through the IPsec tunnel.
イニシエーターは、図10に示すように、CFG_REQUESTに内部_DNS_DOMAIN属性を含めることにより、分割DNSをサポートすることも示す場合があります。この例では、イニシエーターは要求された暗号化されたDNSサーバーの優先度を示していません。IPSECトンネルを通して転送されます。
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6()
INTERNAL_DNS_DOMAIN()
Figure 10: Example of a CFG_REQUEST with Support for Split DNS
図10：分割DNSのサポートを備えたCFG_REQUESTの例
Figure 11 shows an example of the responder's reply. Absent any prohibited local policy, the initiator uses the encrypted DNS server (doh.example.com) for any subsequent DNS queries for "example.com" and its subdomains.
図11は、レスポンダーの返信の例を示しています。禁止されているローカルポリシーがなければ、イニシエーターは、「Examp.com」とそのサブドメインの後続のDNSクエリに暗号化されたDNSサーバー（doh.example.com）を使用します。
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64)
ENCDNS_IP6(1, 1, 15,
(2001:db8:99:88:77:66:55:44),
"doh.example.com",
(alpn=h2 dohpath=/dns-query{?dns}))
INTERNAL_DNS_DOMAIN(example.com)
Figure 11: Example of a CFG_REPLY with INTERNAL_DNS_DOMAIN
図11：internal_dns_domainを使用したCFG_REPLYの例
Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy Pauly for their reviews and comments.
Yoav Nir、Christian Jacquenet、Paul Wouters、Tommy Paulyのレビューとコメントに感謝します。
Yoav and Paul suggested the use of one single attribute carrying both the name and an IP address instead of depending on the existing INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes.
YoavとPaulは、既存のinternal_ip6_dnsとinternal_ip4_dns属性に依存するのではなく、名前とIPアドレスの両方を運ぶ1つの単一の属性の使用を提案しました。
Thanks to Tero Kivinen for the Shepherd review and Roman Danyliw for the AD review.
Shepherd ReviewのTero Kivinenと、広告レビューのRoman Danyliwに感謝します。
Thanks to Stewart Bryant for the gen-art review, Dhruv Dhody for the ops-dir review, and Patrick Mevzek for the dns-dir review.
Gen-ArtレビューのStewart Bryant、OPS-DIRレビューのDhruv Dhody、およびDNS-DIRレビューのPatrick Mezzekに感謝します。
Thanks to Paul Wouters, Zaheduzzaman Sarker, Éric Vyncke, and Robert Wilton for their comments during the IESG review.
IESGレビュー中にコメントをしてくれたPaul Wouters、Zaheduzzaman Sarker、éricvyncke、およびRobert Wiltonに感謝します。
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K
Nokia
India
Email: kondtir@gmail.com
Dan Wing
Cloud Software Group Holdings, Inc.
United States of America
Email: dwing-ietf@fuggles.com
Valery Smyslov
ELVIS-PLUS
Russian Federation
Email: svan@elvis.ru