[要約] RFC 9462 は、DNSクライアントが暗号化DNS構成を発見するためのメカニズムであるDDRを定義しています。DDRは、IPアドレスのみが知られている場合に、暗号化DNSへ移行するために使用されます。この仕組みは、同じエンティティまたは協力エンティティによって運営される場合に限定されており、暗号化DNSプロトコルのサポートを発見するためにも使用できます。
Internet Engineering Task Force (IETF) T. Pauly
Request for Comments: 9462 E. Kinnear
Category: Standards Track Apple Inc.
ISSN: 2070-1721 C. A. Wood
Cloudflare
P. McManus
Fastly
T. Jensen
Microsoft
November 2023
This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known.
このドキュメントでは、DNSクライアントがDNSレコードを使用してリゾルバーの暗号化されたDNS構成を発見するための一連のメカニズムである指定されたリゾルバー（DDR）の発見を定義します。この方法で発見された暗号化されたDNSリゾルバーは、「指定されたリゾルバー」と呼ばれます。これらのメカニズムは、リゾルバのIPアドレスのみがわかっている場合、暗号化されていないDNSから暗号化されたDNSに移動するために使用できます。これらのメカニズムは、暗号化されていないDNSリゾルバーとその指定されたリゾルバーが同じエンティティまたは協力エンティティによって動作される場合に限定されるように設計されています。また、暗号化されたDNSリゾルバーの名前がわかっている場合、暗号化された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/rfc9462.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9462で取得できます。
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
1.1. Specification of Requirements
2. Terminology
3. DNS Service Binding Records
4. Discovery Using Resolver IP Addresses
4.1. Use of Designated Resolvers
4.1.1. Use of Designated Resolvers across Network Changes
4.2. Verified Discovery
4.3. Opportunistic Discovery
5. Discovery Using Resolver Names
6. Deployment Considerations
6.1. Caching Forwarders
6.2. Certificate Management
6.3. Server Name Handling
6.4. Handling Non-DDR Queries for resolver.arpa
6.5. Interaction with Network-Designated Resolvers
7. Security Considerations
8. IANA Considerations
8.1. Special-Use Domain Name "resolver.arpa"
8.2. Domain Name Reservation Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Rationale for Using a Special-Use Domain Name
Appendix B. Rationale for Using SVCB Records
Authors' Addresses
When DNS clients wish to use encrypted DNS protocols such as DNS over TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250], or DNS over HTTPS (DoH) [RFC8484], they can require additional information beyond the IP address of the DNS server, such as the resolver's hostname, alternate IP addresses, non-standard ports, or URI Templates. However, common configuration mechanisms only provide the resolver's IP address during configuration. Such mechanisms include network provisioning protocols like DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement (RA) options [RFC8106], as well as manual configuration.
DNSクライアントがTLS（DOT）[RFC7858]を介したDNSなどの暗号化されたDNSプロトコル、DNSオーバーQuic（DOQ）[RFC9250]、またはHTTPS（DOH）[RFC8484]を介したDNSなどの暗号化されたDNSプロトコルを使用したい場合、IPを超えてIPを超えて追加情報を必要とすることができます。Resolverのホスト名、代替IPアドレス、非標準ポート、URIテンプレートなど、DNSサーバーのアドレス。ただし、一般的な構成メカニズムは、構成中にResolverのIPアドレスのみを提供します。このようなメカニズムには、DHCP [RFC2132] [RFC8415]やIPv6ルーター広告（RA）オプション[RFC8106]などのネットワークプロビジョニングプロトコル、および手動構成が含まれます。
This document defines two mechanisms for clients to discover Designated Resolvers that support these encrypted protocols using DNS server Service Binding (SVCB) records [RFC9460]:
このドキュメントでは、クライアントがDNSサーバーサービスバインディング（SVCB）レコード[RFC9460]を使用してこれらの暗号化されたプロトコルをサポートする指定されたリゾルバーを発見する2つのメカニズムを定義します。
1. When only an IP address of an Unencrypted DNS Resolver is known, the client queries a Special-Use Domain Name (SUDN) [RFC6761] to discover DNS SVCB records associated with one or more Encrypted DNS Resolvers the Unencrypted DNS Resolver has designated for use when support for DNS encryption is requested (Section 4).
1. 暗号化されていないDNSリゾルバーのIPアドレスのみがわかっている場合、クライアントは特別使用ドメイン名（SUDN）[RFC6761]を照会して、1つ以上の暗号化されたDNSリゾルバーに関連付けられたDNS SVCBレコードを発見します。DNS暗号化のサポートが要求されます（セクション4）。
2. When the hostname of an Encrypted DNS Resolver is known, the client requests details by sending a query for a DNS SVCB record. This can be used to discover alternate encrypted DNS protocols supported by a known server, or to provide details if a resolver name is provisioned by a network (Section 5).
2. 暗号化されたDNSリゾルバーのホスト名がわかっている場合、クライアントはDNS SVCBレコードのクエリを送信することにより詳細を要求します。これを使用して、既知のサーバーでサポートされている代替暗号化されたDNSプロトコルを発見したり、リゾルバー名がネットワークによってプロビジョニングされている場合は詳細を提供したりできます（セクション5）。
Both of these approaches allow clients to confirm that a discovered Encrypted DNS Resolver is designated by the originally provisioned resolver. "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a certificate that contains the IP address for the original designating resolver.
これらのアプローチの両方により、クライアントは、発見された暗号化されたDNSリゾルバーが元々プロビジョニングされたリゾルバーによって指定されていることをクライアントが確認できます。この文脈で「指定」とは、リゾルバーが同じエンティティまたは協力エンティティによって動作することを意味します。たとえば、リゾルバーは同じIPアドレスでアクセス可能であるか、元の指定リゾルバーの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 defines the following terms:
このドキュメントでは、次の用語を定義します。
DDR:
DDR：
Discovery of Designated Resolvers. "DDR" refers to the mechanisms defined in this document.
指定されたリゾルバーの発見。「DDR」とは、このドキュメントで定義されているメカニズムを指します。
Designated Resolver:
指定リゾルバー：
A resolver, presumably an Encrypted DNS Resolver, designated by another resolver for use in its own place. This designation can be verified with TLS certificates.
独自の場所で使用するために別のリゾルバーによって指定された、おそらく暗号化されたDNSリゾルバーであるリゾルバー。この指定は、TLS証明書で検証できます。
Encrypted DNS Resolver:
暗号化されたDNSリゾルバー：
A DNS resolver using any encrypted DNS transport. This includes current mechanisms such as DoH, DoT, and DoQ, as well as future mechanisms.
暗号化されたDNS輸送を使用したDNSリゾルバー。これには、DOH、DOT、DOQなどの現在のメカニズム、および将来のメカニズムが含まれます。
Unencrypted DNS Resolver:
暗号化されていないDNSリゾルバー：
A DNS resolver using a transport without encryption, historically TCP or UDP port 53.
暗号化なしのトランスポート、歴史的にTCPまたはUDPポート53を使用したDNSリゾルバー。
DNS resolvers can advertise one or more Designated Resolvers that may offer support over encrypted channels and are controlled by the same entity.
DNSリゾルバーは、暗号化されたチャネルよりもサポートを提供し、同じエンティティによって制御される1つ以上の指定されたリゾルバーを宣伝できます。
When a client discovers Designated Resolvers, it learns information such as the supported protocols and ports. This information is provided in ServiceMode SVCB records for DNS servers, although AliasMode SVCB records can be used to direct clients to the needed ServiceMode SVCB record per [RFC9460]. The formatting of these records, including the DNS-unique parameters such as "dohpath", are defined by [RFC9461].
クライアントが指定されたリゾルバーを発見すると、サポートされているプロトコルやポートなどの情報が学習されます。この情報は、DNSサーバーのServiceMode SVCBレコードで提供されていますが、Alismode SVCBレコードを使用して、[RFC9460]ごとに必要なServiceMode SVCBレコードにクライアントを誘導できます。「Dohpath」などのDNSユニークパラメーターを含むこれらのレコードのフォーマットは、[RFC9461]で定義されます。
The following is an example of a SVCB record describing a DoH server discovered by querying for _dns.example.net:
以下は、_dns.example.netのクエリによって発見されたDOHサーバーを説明するSVCBレコードの例です。
_dns.example.net. 7200 IN SVCB 1 example.net. (
alpn=h2 dohpath=/dns-query{?dns} )
The following is an example of a SVCB record describing a DoT server discovered by querying for _dns.example.net:
以下は、_dns.example.netのクエリによって発見されたドットサーバーを説明するSVCBレコードの例です。
_dns.example.net. 7200 IN SVCB 1 dot.example.net (
alpn=dot port=8530 )
The following is an example of a SVCB record describing a DoQ server discovered by querying for _dns.example.net:
以下は、_dns.example.netのクエリによって発見されたDOQサーバーを説明するSVCBレコードの例です。
_dns.example.net. 7200 IN SVCB 1 doq.example.net (
alpn=doq port=8530 )
If multiple Designated Resolvers are available, using one or more encrypted DNS protocols, the resolver deployment can indicate a preference using the priority fields in each SVCB record [RFC9460].
1つ以上の暗号化されたDNSプロトコルを使用して、複数の指定されたリゾルバーが利用可能である場合、リゾルバーの展開は、各SVCBレコード[RFC9460]の優先フィールドを使用して好みを示すことができます。
If the client encounters a mandatory parameter in a SVCB record it does not understand, it MUST NOT use that record to discover a Designated Resolver, in accordance with Section 8 of [RFC9460]. The client can still use other records in the same response if the client can understand all of their mandatory parameters. This allows future encrypted deployments to simultaneously support protocols even if a given client is not aware of all those protocols. For example, if the Unencrypted DNS Resolver returns three SVCB records -- one for DoH, one for DoT, and one for a yet-to-exist protocol -- a client that only supports DoH and DoT should be able to use those records while safely ignoring the third record.
クライアントが理解できないSVCBレコードで必須パラメーターに遭遇した場合、[RFC9460]のセクション8に従って、指定されたリゾルバーを発見するためにそのレコードを使用してはなりません。クライアントがすべての必須パラメーターを理解できる場合、クライアントは引き続き同じ応答で他のレコードを使用できます。これにより、特定のクライアントがこれらすべてのプロトコルを認識していなくても、将来の暗号化された展開を同時にサポートすることができます。たとえば、暗号化されていないDNSリゾルバーが3つのSVCBレコード（DOH用、1つはDOT用、もう1つはまだ存在していないプロトコル用）を返している場合、DOHとDOTのみをサポートするクライアントは、それらのレコードを使用できるはずです。3番目のレコードを安全に無視します。
To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted DNS Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of [RFC8484]. Designated Resolvers need to ensure that this deadlock is avoidable, as also described in Section 10 of [RFC8484].
名前のルックアップデッドロックを避けるために、指定されたリゾルバーを使用するクライアントは、特定の暗号化されたDNSリゾルバーが、リゾルバー自体の名前を解決するために必要なクエリに使用したり、リゾルバの証明書の取り消しチェックを実行するために必要なクエリに使用していないことを確認する必要があります。[RFC8484]のセクション10。指定されたリゾルバーは、[RFC8484]のセクション10で説明されているように、このデッドロックが回避可能であることを確認する必要があります。
This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers. Other protocols can also use the format defined by [RFC9461]. However, if any such protocol does not involve some form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in Section 4.2.
このドキュメントは、DOH、DOT、およびDOQ指定のリゾルバーの発見に焦点を当てています。他のプロトコルは、[RFC9461]で定義された形式も使用できます。ただし、そのようなプロトコルが何らかの形の証明書の検証を伴わない場合、セクション4.2で定義されているように指定の検証をサポートするために、新しい検証メカニズムを定義する必要があります。
When a DNS client is configured with an Unencrypted DNS Resolver IP address, it SHOULD query the resolver for SVCB records of a service with a scheme of "dns" and an authority of "resolver.arpa" before making other queries. This allows the client to switch to using encrypted DNS for all other queries, if possible. Specifically, the client issues a query for _dns.resolver.arpa. with the SVCB resource record type (64) [RFC9460].
DNSクライアントが暗号化されていないDNS Resolver IPアドレスで構成されている場合、他のクエリを作成する前に、「DNS」のスキームと「sloltver.arpa」の権限を持つサービスのSVCBレコードのリゾルバーを照会する必要があります。これにより、クライアントは、可能であれば、他のすべてのクエリに対して暗号化されたDNSの使用に切り替えることができます。具体的には、クライアントは_dns.resolver.arpaのクエリを発行します。SVCBリソースレコードタイプ（64）[RFC9460]。
Responses to the SVCB query for the "resolver.arpa" SUDN describe Designated Resolvers. To ensure that different Designated Resolver configurations can be correctly distinguished and associated with A and AAAA records for the resolver, ServiceMode SVCB responses to these queries MUST NOT use the "." or "resolver.arpa" value for the TargetName. Similarly, clients MUST NOT perform A or AAAA queries for "resolver.arpa".
「Resolver.Arpa」SudnのSVCBクエリへの応答は、指定されたリゾルバーを説明しています。異なる指定されたリゾルバー構成を正しく区別し、ResolverのAおよびAAAAレコードに関連付けることができるようにするために、これらのクエリに対するServiceMode SVCB応答は「。」を使用してはなりません。またはターゲット名の「sloltver.arpa」値。同様に、クライアントは「resolver.arpa」のaまたはaaaaクエリを実行してはなりません。
The following is an example of a SVCB record describing a DoH server discovered by querying for _dns.resolver.arpa.:
以下は、_dns.resolver.arpaのクエリによって発見されたDOHサーバーを説明するSVCBレコードの例です。
_dns.resolver.arpa. 7200 IN SVCB 1 doh.example.net (
alpn=h2 dohpath=/dns-query{?dns} )
The following is an example of a SVCB record describing a DoT server discovered by querying for _dns.resolver.arpa.:
以下は、_dns.resolver.arpaのクエリによって発見されたドットサーバーを説明するSVCBレコードの例です。
_dns.resolver.arpa. 7200 IN SVCB 1 dot.example.net (
alpn=dot port=8530 )
The following is an example of a SVCB record describing a DoQ server discovered by querying for _dns.resolver.arpa.:
以下は、_dns.resolver.arpaのクエリによって発見されたDOQサーバーを説明するSVCBレコードの例です。
_dns.resolver.arpa. 7200 IN SVCB 1 doq.example.net (
alpn=doq port=8530 )
If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. When responding to these special queries for "resolver.arpa", the recursive resolver SHOULD include the A and AAAA records for the name of the Designated Resolver in the Additional Answers section. This will save the DNS client an additional round trip to retrieve the address of the Designated Resolver; see Section 5 of [RFC9460].
このクエリを受信する再帰リゾルバーに1つ以上の指定リゾルバーがある場合、対応するSVCBレコードが返されます。「Resolver.Arpa」のこれらの特別なクエリに応答する場合、再帰的なリゾルバーには、追加の回答セクションに指定されたリゾルバーの名前のAとAAAのレコードを含める必要があります。これにより、DNSクライアントが指定されたリゾルバーのアドレスを取得するための追加の往復を節約します。[RFC9460]のセクション5を参照してください。
Designated Resolvers SHOULD be accessible using the IP address families that are supported by their associated Unencrypted DNS Resolvers. If an Unencrypted DNS Resolver is accessible using an IPv4 address, it ought to provide an A record for an IPv4 address of the Designated Resolver; similarly, if it is accessible using an IPv6 address, it ought to provide a AAAA record for an IPv6 address of the Designated Resolver. The Designated Resolver MAY support more address families than the Unencrypted DNS Resolver, but it SHOULD NOT support fewer. If this is not done, clients that only have connectivity over one address family might not be able to access the Designated Resolver.
指定されたリゾルバーは、関連する非暗号化されたDNSリゾルバーによってサポートされているIPアドレスファミリを使用してアクセス可能である必要があります。暗号化されていないDNSリゾルバーがIPv4アドレスを使用してアクセスできる場合、指定されたリゾルバーのIPv4アドレスのAレコードを提供する必要があります。同様に、IPv6アドレスを使用してアクセス可能である場合、指定されたリゾルバーのIPv6アドレスにAAAAレコードを提供する必要があります。指定されたリゾルバーは、暗号化されていないDNSリゾルバーよりも多くのアドレスファミリーをサポートする場合がありますが、より少ないサポートはサポートしてはなりません。これが完了していない場合、1つのアドレスファミリを超える接続性を持つクライアントは、指定されたリゾルバーにアクセスできない場合があります。
If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" zone, to provide a consistent and accurate signal to clients that it does not have a Designated Resolver.
このクエリを受信する再帰リゾルバーに指定されたリゾルバーがない場合、「Resolver.Arpa」ゾーンにクエリのNodataを返す必要があります。
When a client discovers Designated Resolvers from an Unencrypted DNS Resolver IP address, it can choose to use these Designated Resolvers either (1) automatically or (2) based on some other policy, heuristic, or user choice.
クライアントが暗号化されていないDNSリゾルバーIPアドレスから指定されたリゾルバーを発見すると、これらの指定されたリゾルバーを自動的に使用するか、（2）他のポリシー、ヒューリスティック、またはユーザーの選択に基づいて（2）使用することを選択できます。
This document defines two preferred methods for automatically using Designated Resolvers:
このドキュメントでは、指定されたリゾルバーを自動的に使用して2つの優先メソッドを定義します。
* Verified Discovery (Section 4.2), for when a TLS certificate can be used to validate the resolver's identity.
* 検証済みの発見（セクション4.2）、TLS証明書を使用してリゾルバーのIDを検証できる場合。
* Opportunistic Discovery (Section 4.3), for when a resolver's IP address is a private or local address.
* ResolverのIPアドレスがプライベートまたはローカルアドレスである場合の日和見的発見（セクション4.3）。
A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input. Details of such policy are out of scope for this document. Clients MUST NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. Use without validation can allow an attacker to direct traffic to an Encrypted DNS Resolver that is unrelated to the original Unencrypted DNS Resolver, as described in Section 7.
クライアントは、実装固有のポリシーまたはユーザー入力に基づいて、これらのメソッドのいずれかなしで発見された指定されたリゾルバーをさらに使用できます。このようなポリシーの詳細は、このドキュメントの範囲外です。クライアントは、このドキュメントで定義されている2つの方法や将来のメカニズムなど、何らかの検証なしに、指定されたリゾルバーを自動的に使用してはなりません。検証なしで使用すると、攻撃者は、セクション7で説明されているように、元の暗号化されていないDNSリゾルバーとは無関係の暗号化されたDNSリゾルバーにトラフィックを向けることができます。
A client MUST NOT reuse a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other Unencrypted DNS Resolver. Instead, the client needs to repeat the discovery process to discover the Designated Resolver of the other Unencrypted DNS Resolver. In other words, designations are per-resolver and MUST NOT be used to configure the client's universal DNS behavior. This ensures in all cases that queries are being sent to a party designated by the resolver originally being used.
クライアントは、他の暗号化されていないDNSリゾルバーの代わりに、暗号化されていない1つのDNSリゾルバーのIPアドレスを使用して発見された指定を再利用してはなりません。代わりに、クライアントは発見プロセスを繰り返して、他の暗号化されていないDNSリゾルバーの指定されたリゾルバーを発見する必要があります。言い換えれば、指定は分解者ごとであり、クライアントの普遍的なDNS動作を構成するために使用してはなりません。これにより、すべての場合において、クエリが元々使用されていたリゾルバーによって指定された当事者に送信されていることが保証されます。
If a client is configured with the same Unencrypted DNS Resolver IP address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each network, since the same IP address may be used for different servers on the different networks.
クライアントが複数の異なるネットワークで同じ暗号化されていないDNSリゾルバーIPアドレスで構成されている場合、同じものが同じため、1つのネットワークで発見された指定されたリゾルバーを他のネットワークで再利用しないでください。IPアドレスは、さまざまなネットワーク上のさまざまなサーバーに使用できます。
Verified Discovery is a mechanism that allows the automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake.
検証済みの発見は、TLSハンドシェイクを実行するDNS暗号化をサポートする指定されたリゾルバーの自動使用を可能にするメカニズムです。
In order to be considered a verified Designated Resolver, the TLS certificate presented by the Designated Resolver needs to pass the following checks made by the client:
検証された指定されたリゾルバーと見なされるために、指定されたリゾルバーによって提示されたTLS証明書は、クライアントが作成した以下のチェックに合格する必要があります。
1. The client MUST verify the chain of certificates up to a trust anchor as described in Section 6 of [RFC5280]. The client SHOULD use the default system or application trust anchors, unless otherwise configured.
1. クライアントは、[RFC5280]のセクション6で説明されているように、信託アンカーまでの証明書のチェーンを確認する必要があります。クライアントは、特に構成されていない限り、デフォルトのシステムまたはアプリケーショントラストアンカーを使用する必要があります。
2. The client MUST verify that the certificate contains the IP address of the designating Unencrypted DNS Resolver in an iPAddress entry of the subjectAltName extension as described in Section 4.2.1.6 of [RFC5280].
2. クライアントは、[RFC5280]のセクション4.2.1.6で説明されているように、SecumentAltName拡張子のiPaddressエントリに、暗号化されていないDNSリゾルバーの指定されているIPアドレスが含まれていることを確認する必要があります。
If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted DNS Resolver, so as to prefer encrypted DNS whenever possible.
これらのチェックが合格した場合、クライアントは、可能な限り暗号化されたDNSを好むように、それ以外の場合は暗号化されていないDNSリゾルバーを使用した場合に発見された指定されたリゾルバーを使用する必要があります。
If these checks fail, the client MUST NOT automatically use the discovered Designated Resolver if this designation was only discovered via a _dns.resolver.arpa. query (if the designation was advertised directly by the network as described in Section 6.5, the server can still be used). Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB record's Time to Live (TTL) in order to avoid excessive queries that will lead to further failed validations. The client MAY issue new queries if the SVCB record's TTL is excessively long (as determined by client policy) to minimize the length of time an intermittent attacker can prevent the use of encrypted DNS.
これらのチェックが失敗した場合、この指定が_dns.resolver.arpaを介してのみ発見された場合、クライアントは発見された指定されたリゾルバーを自動的に使用してはなりません。クエリ（セクション6.5で説明されているように、指定がネットワークによって直接宣伝された場合、サーバーは引き続き使用できます）。さらに、クライアントは、SVCBレコードのライブ（TTL）が示す時間の長さを使用して、この暗号化されていないDNSリゾルバーを使用して、さらに失敗した検証につながる過度のクエリを避けるために、指定されたリゾルバーのさらなるクエリを抑制する必要があります。SVCBレコードのTTLが過度に長い場合（クライアントポリシーで決定されている）、断続的な攻撃者が暗号化されたDNSの使用を防ぐことができる時間を最小限に抑えるために、クライアントは新しいクエリを発行する場合があります。
If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check (Section 4.3). If the IP address is not shared, opportunistic use allows for attackers to redirect queries to an unrelated Encrypted DNS Resolver, as described in Section 7.
指定されたリゾルバーと暗号化されていないDNSリゾルバーがIPアドレスを共有する場合、クライアントはこの証明書チェックがなくても、指定されたリゾルバーを日和見的に使用することを選択できます（セクション4.3）。IPアドレスが共有されていない場合、日和見的な使用により、攻撃者はセクション7で説明されているように、関連性のない暗号化されたDNSリゾルバーにクエリをリダイレクトできます。
Connections to a Designated Resolver can use a different IP address than the IP address of the Unencrypted DNS Resolver -- for example, if the process of resolving the SVCB service yields additional addresses. Even when a different IP address is used for the connection, the TLS certificate checks described in this section still apply for the original IP address of the Unencrypted DNS Resolver.
指定されたリゾルバーへの接続は、暗号化されていないDNSリゾルバーのIPアドレスとは異なるIPアドレスを使用できます。たとえば、SVCBサービスを解決するプロセスが追加のアドレスを生成する場合。接続に別のIPアドレスが使用されている場合でも、このセクションで説明するTLS証明書チェックは、暗号化されていないDNSリゾルバーの元のIPアドレスにまだ適用されます。
There are situations where Verified Discovery of encrypted DNS configuration over unencrypted DNS is not possible. For example, the identities of Unencrypted DNS Resolvers on private IP addresses [RFC1918], Unique Local Addresses (ULAs) [RFC4193], and Link-Local addresses [RFC3927] [RFC4291] cannot be safely confirmed using TLS certificates under most conditions.
暗号化されていないDNSよりも暗号化されたDNS構成の検証された発見が不可能な状況があります。たとえば、プライベートIPアドレス[RFC1918]、ユニークなローカルアドレス（ULAS）[RFC4193]、およびLink-Localアドレス[RFC3927] [RFC4291]の暗号化されていないDNSリゾルバーのアイデンティティは、ほとんどの条件下でTLS証明書を使用して安全に確認できません。
An opportunistic privacy profile is defined for DoT in Section 4.1 of [RFC7858] as a mode in which clients do not validate the name of the resolver presented in the certificate. This opportunistic privacy profile similarly applies to DoQ [RFC9250]. For this profile, Section 4.1 of [RFC7858] explains that clients might or might not validate the resolver; however, even if clients choose to perform some certificate validation checks, they will not be able to validate the names presented in the SubjectAltName (SAN) field of the certificate for private and local IP addresses.
[RFC7858]のセクション4.1のDOTに対して日和見プライバシープロファイルは、クライアントが証明書に表示されているリゾルバーの名前を検証しないモードとして定義されます。この日和見的なプライバシープロファイルも同様にDOQ [RFC9250]に適用されます。このプロファイルでは、[RFC7858]のセクション4.1は、クライアントがリゾルバーを検証する場合と検証できない場合があると説明しています。ただし、クライアントが証明書の検証チェックを実行することを選択したとしても、プライベートおよびローカルIPアドレスの証明書のsumberaltaltname（san）フィールドに表示される名前を検証することはできません。
A client MAY use information from the SVCB record for _dns.resolver.arpa. with this opportunistic privacy profile as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver. Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses.
クライアントは、_dns.resolver.arpaのSVCBレコードからの情報を使用できます。暗号化されたDNSリゾルバーのIPアドレスが、暗号化されていないDNSリゾルバーのIPアドレスと違いはない限り、この日和見プライバシープロファイルを使用します。クライアントは、他のアドレスを使用するリゾルバーがアドレスのTLS証明書をプロビジョニングできるため、プライベートまたはローカルIPアドレスを使用してリゾルバーにのみこのモードを使用する必要があります。
A DNS client that already knows the name of an Encrypted DNS Resolver can use DDR to discover details about all supported encrypted DNS protocols. This situation can arise if a client has been configured to use a given Encrypted DNS Resolver, or if a network provisioning protocol (such as DHCP or IPv6 RAs) provides a name for an Encrypted DNS Resolver alongside the resolver IP address, such as by using Discovery of Network-designated Resolvers (DNR) [RFC9463].
暗号化されたDNSリゾルバーの名前を既に知っているDNSクライアントは、DDRを使用して、サポートされているすべての暗号化されたDNSプロトコルの詳細を発見できます。この状況は、特定の暗号化されたDNSリゾルバーを使用するようにクライアントが構成されている場合、またはネットワークプロビジョニングプロトコル（DHCPやIPv6 RASなど）が、リゾルバーIPアドレスとともに暗号化されたDNSリゾルバーの名前を提供する場合に発生する可能性があります。ネットワーク指定リゾルバー（DNR）の発見[RFC9463]。
For these cases, the client simply sends a DNS SVCB query using the known name of the resolver. This query can be issued to the named Encrypted DNS Resolver itself or to any other resolver. Unlike the case of bootstrapping from an Unencrypted DNS Resolver (Section 4), these records SHOULD be available in the public DNS if the same domain name's A or AAAA records are available in the public DNS to allow using any resolver to discover another resolver's Designated Resolvers. When the name can only be resolved in private namespaces, these records SHOULD be available to the same audience as the A and AAAA records.
これらの場合、クライアントは、既知のリゾルバーの名前を使用してDNS SVCBクエリを送信するだけです。このクエリは、名前付き暗号化されたDNSリゾルバー自体または他のリゾルバーに発行できます。暗号化されていないDNSリゾルバー（セクション4）からのブートストラップの場合とは異なり、同じドメイン名がAまたはAAAAレコードが公開DNSで利用可能である場合、これらのレコードは公開DNSで利用可能である必要があります。。名前をプライベートネームスペースでのみ解決できる場合、これらのレコードはAおよびAAAAレコードと同じオーディエンスが利用できるようにする必要があります。
For example, if the client already knows about a DoT server resolver.example.com, it can issue a SVCB query for _dns.resolver.example.com to discover if there are other encrypted DNS protocols available. In the following example, the SVCB answers indicate that resolver.example.com supports both DoH and DoT and that the DoH server indicates a higher priority than the DoT server.
たとえば、クライアントがDot Server Resolver.example.comについてすでに知っている場合、_dns.resolver.example.comのSVCBクエリを発行して、他の暗号化されたDNSプロトコルが利用できるかどうかを発見できます。次の例では、SVCBの回答は、Resolver.example.comがDOHとDOTの両方をサポートしており、DOHサーバーがDOTサーバーよりも優先度が高いことを示していることを示しています。
_dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. (
alpn=h2 dohpath=/dns-query{?dns} )
_dns.resolver.example.com. 7200 IN SVCB 2 resolver.example.com. (
alpn=dot )
Clients MUST validate that for any Encrypted DNS Resolver discovered using a known resolver name, the TLS certificate of the resolver contains the known name in a subjectAltName extension. In the example above, this means that both servers need to have certificates that cover the name resolver.example.com. Often, the various supported encrypted DNS protocols will be specified such that the SVCB TargetName matches the known name, as is true in the example above. However, even when the TargetName is different (for example, if the DoH server had a TargetName of doh.example.com), the clients still check for the original known resolver name in the certificate.
クライアントは、既知のリゾルバー名を使用して発見された暗号化されたDNSリゾルバーについて、それを検証する必要があります。リゾルバーのTLS証明書には、subjectaltname拡張子に既知の名前が含まれています。上記の例では、これは両方のサーバーが名前Resolver.example.comという名前をカバーする証明書を持つ必要があることを意味します。多くの場合、サポートされているさまざまな暗号化されたDNSプロトコルが指定され、SVCB TargetNameが既知の名前と一致するように指定されます。ただし、TargetNameが異なる場合でも（たとえば、DOHサーバーにdoh.example.comのターゲット名がある場合）、クライアントは証明書の元の既知のリゾルバー名をまだ確認します。
Note that this resolver validation is not related to the DNS resolver that provided the SVCB answer.
このリゾルバーの検証は、SVCBの回答を提供するDNSリゾルバーとは関係がないことに注意してください。
As another example, being able to discover a Designated Resolver for a known Encrypted DNS Resolver is useful when a client has a DoT configuration for foo.resolver.example.com but is on a network that blocks DoT traffic. The client can still send a query to any other accessible resolver (either the local network resolver or an accessible DoH server) to discover if there is a designated DoH server for foo.resolver.example.com.
別の例として、クライアントがfoo.resolver.example.comのドット構成を持っているが、ドットトラフィックをブロックするネットワーク上にある場合、既知の暗号化されたDNSリゾルバーの指定されたリゾルバーを発見できることは役立ちます。クライアントは、他のアクセス可能なリゾルバー（ローカルネットワークリゾルバーまたはアクセス可能なDOHサーバーのいずれか）にクエリを送信して、foo.resolver.example.comに指定されたDOHサーバーがあるかどうかを発見できます。
Resolver deployments that support DDR are advised to consider the following points.
DDRをサポートするリゾルバーの展開は、次のポイントを考慮することをお勧めします。
A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" (or any subdomains) upstream. This prevents a client from receiving a SVCB record that will fail to authenticate because the forwarder's IP address is not in the SubjectAltName (SAN) field of the upstream resolver's Designated Resolver's TLS certificate. A DNS forwarder that already acts as a completely transparent forwarder MAY choose to forward these queries when the operator expects that this does not apply, because the operator either knows that the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or expects clients to validate the connection via some future mechanism.
DNSフォワーダーは、上流の「sloltver.arpa」（または任意のサブドメイン）のクエリを転送してはなりません。これにより、フロワーのIPアドレスが上流のResolverの指定されたResolverのTLS証明書のsumberaltaltname（san）フィールドにないため、クライアントが認証に失敗するSVCBレコードを受信することを防ぎます。すでに完全に透明な転送業者として機能しているDNSフォワーダーは、オペレーターがこれが適用されないことを期待している場合、これらのクエリを転送することを選択できます。オペレーターは、上流のリゾルバーがTLS証明書のSANフィールドに転送業者のIPアドレスを持っているか、または期待することを知っているからです。将来のメカニズムを介して接続を検証するクライアント。
Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and that the use of DDR by a resolver does not communicate a requirement for clients to use the SVCB record when it cannot be verified.
上流の「sloltver.arpa」のクエリを転送することを選択したオペレーターは、クライアントの動作が保証されないこと、およびリゾルバーによるDDRの使用は、クライアントが検証できないときにSVCBレコードを使用する要件を伝えないことに注意する必要があります。
Resolver owners that support Verified Discovery will need to list valid referring IP addresses in their TLS certificates. This may pose challenges for resolvers with a large number of referring IP addresses.
検証済みの発見をサポートするリゾルバーの所有者は、TLS証明書に有効な参照IPアドレスをリストする必要があります。これは、多数の参照IPアドレスを使用して、リゾルバーに課題をもたらす可能性があります。
Clients MUST NOT use "resolver.arpa" as the server name in either (1) the TLS Server Name Indication (SNI) [RFC8446] for DoT, DoQ, or DoH connections or (2) the URI host for DoH requests.
クライアントは、（1）DOT、DOQ、またはDOH接続のTLSサーバー名表示（SNI）[RFC8446]または（2）DOHリクエストのURIホストのいずれかのサーバー名として「resolver.arpa」を使用してはなりません。
When performing discovery using resolver IP addresses, clients MUST use the original IP address of the Unencrypted DNS Resolver as the URI host for DoH requests.
Resolver IPアドレスを使用して発見を実行する場合、クライアントは、DOHリクエストのURIホストとして、暗号化されていないDNS Resolverの元のIPアドレスを使用する必要があります。
Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to be configured to present the appropriate TLS certificate when no SNI is present for DoT, DoQ, and DoH.
IPアドレスはデフォルトでTLS SNIでサポートされていないため、IPアドレスを使用した発見をサポートするリゾルバーは、DOT、DOQ、およびDOHにSNIが存在しない場合に適切なTLS証明書を提示するように構成する必要があることに注意してください。
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a locally served zone per [RFC6303]. In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa. with NODATA and queries of any type for any domain name under resolver.arpa with NODATA.
_dns.resolver.arpaのクエリに応答することにより、DDRをサポートするDNSリゾルバー。Resolver.Arpaは、[RFC6303]ごとにローカルで提供されるゾーンとして扱う必要があります。実際には、これは、_dns.resolver.arpaのSVCB以外の任意のタイプのクエリにリゾルバーが応答することを意味します。resolver.arpa with nodataの下の任意のドメイン名の任意のタイプのnodataと任意のタイプのクエリ付き。
DNR [RFC9463] allows a network to provide designation of resolvers directly through DHCP [RFC2132] [RFC8415] and through IPv6 RA options [RFC8106]. When such indications are present, clients can suppress queries for "resolver.arpa" to the unencrypted DNS server indicated by the network over DHCP or RAs, and the DNR indications SHOULD take precedence over those discovered using "resolver.arpa" for the same resolver if there is a conflict, since DNR is considered a more reliable source.
DNR [RFC9463]を使用すると、ネットワークはDHCP [RFC2132] [RFC8415]およびIPv6 RAオプション[RFC8106]を介してリゾルバーの指定を直接提供できます。そのような適応症が存在する場合、クライアントは、DHCPまたはRASを介したネットワークで示されている暗号化されていないDNSサーバーの「sloltver.Arpa」のクエリを抑制でき、DNRの表示は、同じ廃棄物の「Resolver.Arpa」を使用して発見されたものよりも優先されるはずです。DNRはより信頼性の高いソースと見なされるため、競合がある場合。
The Designated Resolver information in DNR might not contain a full set of SvcParams needed to connect to an Encrypted DNS Resolver. In such a case, the client can use a SVCB query using a resolver name, as described in Section 5, to the Authentication Domain Name (ADN).
DNRの指定されたリゾルバー情報には、暗号化されたDNSリゾルバーに接続するために必要なSVCParamsの完全なセットが含まれていない場合があります。このような場合、クライアントは、セクション5で説明されているように、認証ドメイン名（ADN）に説明されているリゾルバー名を使用してSVCBクエリを使用できます。
Since clients can receive DNS SVCB answers over unencrypted DNS, on-path attackers can prevent successful discovery by dropping SVCB queries or answers and thus can prevent clients from switching to using encrypted DNS. Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack. To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically.
クライアントは暗号化されていないDNSよりもDNS SVCB回答を受信できるため、パス上の攻撃者はSVCBクエリや回答を削除することで成功した発見を防ぐことができ、したがって、クライアントが暗号化されたDNSの使用に切り替えるのを防ぐことができます。クライアントは、指定されたリゾルバーがないリゾルバーとそのようなアクティブな攻撃を区別することは不可能である可能性があることに注意する必要があります。発見クエリが悪意を持ってまたは意図せずにドロップされることの影響を制限するために、クライアントはSVCBクエリを定期的に再セントすることができます。
Section 8.2 of [RFC9461] describes another type of downgrade attack where an attacker can block connections to the encrypted DNS server. For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to using encrypted DNS.
[RFC9461]のセクション8.2では、攻撃者が暗号化されたDNSサーバーへの接続をブロックできる別のタイプのダウングレード攻撃について説明します。DDRの場合、クライアントは、信頼する前にサーバーへの接続を使用して指定されたリゾルバーを検証する必要があるため、これらの接続をブロックできる攻撃者は、クライアントが暗号化されたDNSの使用に切り替えることを防ぐことができます。
Encrypted DNS Resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based solely on metadata in the SVCB record, such as the HTTP path or alternate port number, which are parameters that an attacker could modify. For example, if a DoH resolver provides a filtering service for one URI path and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter. These attacks can be mitigated by providing separate resolver IP addresses or hostnames.
暗号化されていないDNSを介してDNS SVCB回答を使用して発見を可能にする暗号化されたDNSリゾルバーは、攻撃者が変更できるパラメーターであるHTTPパスや代替ポート番号など、SVCBレコードのメタデータのみに基づいて差別化された動作を提供してはなりません。たとえば、DOHリゾルバーが1つのURIパスにフィルタリングサービスと別のURIパスの非フィルターサービスを提供する場合、攻撃者は「Dohpath」パラメーターを変更することでこれらのサービスのどれを使用するかを選択できます。これらの攻撃は、個別のリゾルバーIPアドレスまたはホスト名を提供することにより、軽減できます。
While the IP address of the Unencrypted DNS Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, on a VPN, or on a network with protections like RA-Guard [RFC6105]. An attacker might try to direct encrypted DNS traffic to itself by causing the client to think that a discovered Designated Resolver uses a different IP address from the Unencrypted DNS Resolver. Such a Designated Resolver might have a valid certificate but might be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network.
暗号化されていないDNSリゾルバーのIPアドレスは、しばしば不安定なメカニズムに基づいてプロビジョニングされますが、手動構成、VPNで、またはRAガードのような保護を備えたネットワーク上で安全にプロビジョニングすることもできます[RFC6105]。攻撃者は、クライアントに発見された指定されたリゾルバーが暗号化されていないDNSリゾルバーとは異なるIPアドレスを使用しているとクライアントに考えることにより、暗号化されたDNSトラフィックを自分自身に向けようとする場合があります。このような指定されたリゾルバーは有効な証明書を持っている可能性がありますが、クライアントまたはネットワークの知識なしにユーザークエリを観察または変更しようとしている攻撃者によって操作される場合があります。
If the IP address of a Designated Resolver differs from that of an Unencrypted DNS Resolver, clients applying Verified Discovery (Section 4.2) MUST validate that the IP address of the Unencrypted DNS Resolver is covered by the SubjectAltName (SAN) of the Designated Resolver's TLS certificate. If that validation fails, the client MUST NOT automatically use the discovered Designated Resolver.
指定されたリゾルバーのIPアドレスが暗号化されていないDNSリゾルバーのIPアドレスと異なる場合、検証されたディスカバリー（セクション4.2）を適用するクライアントは、暗号化されていないDNSリゾルバーのIPアドレスが指定されたゾウムシのTLS証明書の件名（SAN）でカバーされていることを検証する必要があります。。その検証が失敗した場合、クライアントは発見された指定されたリゾルバーを自動的に使用してはなりません。
Clients using Opportunistic Discovery (Section 4.3) MUST be limited to cases where the Unencrypted DNS Resolver and Designated Resolver have the same IP address, which SHOULD be a private or local IP address. Clients that do not follow Opportunistic Discovery (Section 4.3) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain control of the Unencrypted DNS Resolver.
日和見的発見を使用するクライアント（セクション4.3）は、暗号化されていないDNSリゾルバーと指定されたリゾルバーが同じIPアドレスを持っている場合、プライベートまたはローカルのIPアドレスである必要がある場合に制限する必要があります。日和見的な発見に従わないクライアント（セクション4.3）は、最初に指定をチェックすることなく接続しようとします。暗号化されていないDNSリゾルバーの制御を獲得できませんでした。
The constraints on the use of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this document, which are referred to as Verified Discovery and Opportunistic Discovery. Clients MAY use some other mechanism to verify and use Designated Resolvers discovered using the DNS SVCB record. However, the use of such an alternate mechanism needs to take into account the attack scenarios detailed here.
ここで指定された指定されたリゾルバーの使用に関する制約は、このドキュメントで定義されている自動発見メカニズムに特に適用されます。これは、検証された発見と日和見的発見と呼ばれます。クライアントは、他のメカニズムを使用して、DNS SVCBレコードを使用して発見された指定されたリゾルバーを検証および使用できます。ただし、このような代替メカニズムの使用は、ここで詳述されている攻撃シナリオを考慮する必要があります。
IANA has registered "resolver.arpa" in the "Special-Use Domain Names" registry established by [RFC6761].
IANAは、[RFC6761]によって確立された「特別使用ドメイン名」レジストリに「Resolver.Arpa」を登録しています。
IANA has added an entry in the "Transport-Independent Locally-Served DNS Zone Registry" for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain" and listed this document as the reference.
IANAは、「Resolver.Arpa」の「トランスポートに依存しないローカルに設置されたDNSゾーンレジストリ」にエントリを追加しました。「DNS Resolver Special-Use Domain」という説明を使用して、このドキュメントを参照としてリストしました。
In accordance with Section 5 of [RFC6761], the answers to the following questions are provided relative to this document:
[RFC6761]のセクション5に従って、次の質問に対する回答は、このドキュメントに関連して提供されます。
1. Are human users expected to recognize these names as special and use them differently? In what way?
1. 人間のユーザーは、これらの名前を特別なものとして認識し、異なる方法で使用することを期待していますか？どのように？
1. No. This name is used automatically by DNS stub resolvers running on client devices on behalf of users, and users will never see this name directly.
1. いいえ。この名前は、ユーザーに代わってクライアントデバイスで実行されているDNSスタブリゾルバーによって自動的に使用され、ユーザーはこの名前を直接表示することはありません。
2. Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way?
2. アプリケーションソフトウェアの作家は、ソフトウェアにこれらの名前を特別なものとして認識し、違う方法で扱うことが期待されていますか？どのように？
2. No. There is no use case where a non-DNS application (covered by the next question) would need to use this name.
2. いいえ。非DNSアプリケーション（次の質問でカバー）がこの名前を使用する必要がある場合は、使用されていません。
3. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?
3. 名前解像度APIとライブラリの作家は、ソフトウェアにこれらの名前を特別なものとして認識し、異なる方法で扱うことが期待されると期待されていますか？もしそうなら、どうですか？
3. Yes. DNS client implementors are expected to use this name when querying for a resolver's properties instead of records for the name itself. DNS servers are expected to respond to queries for this name with their own properties instead of checking the matching zone as it would for normal domain names.
3. はい。DNSクライアントの実装者は、名前自体のレコードの代わりにリゾルバーのプロパティをクエリするときにこの名前を使用することが期待されます。DNSサーバーは、通常のドメイン名のようにマッチングゾーンをチェックする代わりに、独自のプロパティを使用して、この名前のクエリに応答することが期待されています。
4. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
4. キャッシュドメイン名サーバーの開発者は、実装がこれらの名前を特別なものとして認識し、異なる方法で扱うことを期待されることが期待されていますか？もしそうなら、どうですか？
4. Yes. Caching domain name servers should not forward queries for this name, to avoid causing validation failures due to IP address mismatch.
4. はい。キャッシュドメイン名サーバーは、IPアドレスの不一致による検証障害の原因を避けるために、この名前のクエリを転送しないでください。
5. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
5. 権威あるドメイン名サーバーの開発者は、実装がこれらの名前を特別なものとして認識し、違った方法で扱うことを期待されることを期待されていますか？もしそうなら、どうですか？
5. No. DDR is designed for use by recursive resolvers. Theoretically, an authoritative server could choose to support this name if it wants to advertise support for encrypted DNS protocols over plaintext DNS, but that scenario is covered by other work in the IETF DNSOP Working Group.
5. いいえ。DDRは、再帰的なリゾルバーで使用するように設計されています。理論的には、信頼できるサーバーは、プレーンテキストDNSを介した暗号化されたDNSプロトコルのサポートを宣伝したい場合、この名前をサポートすることを選択できますが、そのシナリオはIETF DNSOPワーキンググループの他の作業でカバーされています。
6. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?
6. この予約された特別使用ドメイン名は、DNSサーバーオペレーターに潜在的な影響を与えますか？この予約された名前の権威あるDNSサーバーを権威あるDNSサーバーを構成しようとする場合、準拠した名前サーバーソフトウェアは無効として拒否しますか？DNSサーバーオペレーターはそれについて知り、その理由を理解する必要がありますか？Name Serverソフトウェアがこの予約済みの名前の使用を妨げなくても、DNSサーバーオペレーターが認識すべきであると予想どおりに機能しない可能性のある他の方法はありますか？
6. This name is locally served, and any resolver that supports this name should never forward the query. DNS server operators should be aware that records for this name will be used by clients to modify the way they connect to their resolvers.
6. この名前はローカルで提供されており、この名前をサポートするリゾルバーはクエリを転送しないでください。DNSサーバーオペレーターは、この名前のレコードがリゾルバーへの接続方法を変更するために使用されることに注意する必要があります。
7. How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially designated entity?
7. DNSレジストリ/レジストラは、この予約されたドメイン名を登録するためにリクエストをどのように扱うべきですか？そのような要求は拒否されるべきですか？そのような要求は許可されるべきですが、特別に指定されたエンティティにのみですか？
7. IANA holds the registration for this name. Non-IANA requests to register this name should always be denied by DNS Registries/ Registrars.
7. IANAはこの名前の登録を保持しています。この名前を登録するという非アンナリクエストは、常にDNSレジストリ/レジストラによって拒否される必要があります。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[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>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/info/rfc3927>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<https://www.rfc-editor.org/info/rfc6303>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<https://www.rfc-editor.org/info/rfc6761>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC9461] Schwartz, B., "Service Binding Mapping for DNS Servers",
RFC 9461, DOI 10.17487/RFC9461, November 2023,
<https://www.rfc-editor.org/info/rfc9461>.
[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>.
[DoH-HINTS]
Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference
Hints for HTTP", Work in Progress, Internet-Draft, draft-
schinazi-httpbis-doh-preference-hints-02, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-schinazi-
httpbis-doh-preference-hints-02>.
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-17, 9 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-17>.
[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>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name
'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August
2020, <https://www.rfc-editor.org/info/rfc8880>.
The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the querying client is not interested in an answer from the authoritative "arpa" name servers. The intent of the SUDN is to allow clients to communicate with the Unencrypted DNS Resolver much like "ipv4only.arpa" allows for client-to-middlebox communication. For more context, see [RFC8880] for the rationale behind "ipv4only.arpa".
「Resolver.Arpa」Sudnは、クエリクライアントが権威ある「ARPA」名サーバーからの回答に興味がないという点で、「IPv4only.arpa」に似ています。Sudnの目的は、クライアント間通信を許可する「IPv4only.Arpa」と同様に、クライアントが暗号化されていないDNSリゾルバーと通信できるようにすることです。よりコンテキストについては、「IPv4only.arpa」の背後にある根拠については、[RFC8880]を参照してください。
These mechanisms use SVCB/HTTPS resource records [RFC9460] to communicate that a given domain designates a particular Designated Resolver for clients to use in place of an Unencrypted DNS Resolver (using a SUDN) or another Encrypted DNS Resolver (using its domain name).
これらのメカニズムは、SVCB/HTTPSリソースレコード[RFC9460]を使用して、特定のドメインが、暗号化されていないDNSリゾルバー（Sudnを使用）または別の暗号化されたDNSリゾルバー（ドメイン名を使用）の代わりに使用するための特定の指定リゾルバーを指定することを通知します。
There are various other proposals for how to provide similar functionality. There are several reasons that these mechanisms have chosen SVCB records:
同様の機能を提供する方法については、他にもさまざまな提案があります。これらのメカニズムがSVCBレコードを選択した理由はいくつかあります。
* Discovering Encrypted DNS Resolvers using DNS records keeps client logic for DNS self-contained and allows a DNS resolver operator to define which resolver names and IP addresses are related to one another.
* DNSレコードを使用して暗号化されたDNSリゾルバーを発見すると、DNSのクライアントロジックが自己完結型になり、DNSリゾルバーオペレーターがどのリゾルバー名とIPアドレスが互いに関連しているかを定義できるようになります。
* Using DNS records also does not rely on bootstrapping with higher-level application operations (such as those discussed in [DoH-HINTS]).
* DNSレコードを使用すると、高レベルのアプリケーション操作（[DOHヒント]で説明されているものなど）を使用したブートストラップにも依存していません。
* SVCB records are extensible and allow the definition of parameter keys, making them a superior mechanism for extensibility as compared to approaches such as overloading TXT records. The same keys can be used for discovering Designated Resolvers of different transport types as well as those advertised by Unencrypted DNS Resolvers or another Encrypted DNS Resolver.
* SVCBレコードは拡張可能であり、パラメーターキーの定義を許可するため、TXTレコードの過負荷などのアプローチと比較して、拡張性の優れたメカニズムになります。同じキーを使用して、異なるトランスポートタイプの指定されたリゾルバーと、暗号化されていないDNSリゾルバーまたは別の暗号化されたDNSリゾルバーによって宣伝されているものを発見することができます。
* Clients and servers that are interested in privacy of names will already need to support SVCB records in order to use the TLS Encrypted ClientHello [ECH]. Without encrypting names in TLS, the value of encrypting DNS is reduced, so pairing the solutions provides the greatest benefit.
* 名前のプライバシーに関心のあるクライアントとサーバーは、TLS暗号化されたClientHello [ECH]を使用するために、SVCBレコードを既にサポートする必要があります。TLSで名前を暗号化することなく、DNSを暗号化する価値が低下するため、ソリューションのペアリングは最大の利点をもたらします。
Tommy Pauly
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: tpauly@apple.com
Eric Kinnear
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: ekinnear@apple.com
Christopher A. Wood
Cloudflare
101 Townsend St
San Francisco, California 94107
United States of America
Email: caw@heapingbits.net
Patrick McManus
Fastly
Email: mcmanus@ducksong.com
Tommy Jensen
Microsoft
Email: tojens@microsoft.com