[要約] この文書は、DNSサーバー（再帰リゾルバと権威サーバー）が、他のピアとの調整なしにDNSクエリのプライバシーを保護するために取ることができる手順を示しています。この文書のガイダンスによって提供される保護は、能動的な攻撃者によって打破される可能性がありますが、より強力な防御策よりも展開が簡単でリスクが少ないはずです。この文書の目標は、DNSエコシステムの再帰から権威へのホップでの機会主義的な暗号化トランスポートの展開を簡素化し、加速することです。基盤となる暗号化トランスポートの簡単な展開が広がることで、より強力な暗号保護の将来の仕様化が促進されるかもしれません。
Internet Engineering Task Force (IETF) D. K. Gillmor, Ed.
Request for Comments: 9539 ACLU
Category: Experimental J. Salazar, Ed.
ISSN: 2070-1721
P. Hoffman, Ed.
ICANN
February 2024
This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses.
このドキュメントでは、DNSサーバー（再帰的リソースバーと権威あるサーバー）が、パッシブネットワークモニターに対してDNSクエリプライバシーを守るために（他のピアと調整せずに）一方的に（他のピアと調整せずに）取得できる手順を定めています。このドキュメントのガイダンスによって提供される保護は、アクティブな攻撃者によって打ち負かされる可能性がありますが、より強力な防御よりも展開するのがより簡単でリスクが少ないはずです。
The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks.
このドキュメントの目標は、DNSエコシステムの再帰的なホップにおける日和見暗号化された輸送の展開を簡素化し、高速化することです。日和見的に基礎となる暗号化された輸送のより広い簡単な展開は、より強力な攻撃に対するより強力な暗号化保護の将来の仕様を促進する可能性があります。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9539.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9539で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Requirements Language
1.2. Terminology
2. Priorities
2.1. Minimizing Negative Impacts
2.2. Protocol Choices
3. Guidance for Authoritative Servers
3.1. Pooled Authoritative Servers behind a Load Balancer
3.2. Authentication
3.3. Server Name Indication
3.4. Resource Exhaustion
3.5. Pad Responses to Mitigate Traffic Analysis
4. Guidance for Recursive Resolvers
4.1. High-Level Overview
4.2. Maintaining Authoritative State by IP Address
4.3. Overall Recursive Resolver Settings
4.4. Recursive Resolver Requirements
4.5. Authoritative Server Encrypted Transport Connection State
4.6. Probing Policy
4.6.1. Sending a Query over Do53
4.6.2. Receiving a Response over Do53
4.6.3. Initiating a Connection over Encrypted Transport
4.6.4. Establishing an Encrypted Transport Connection
4.6.5. Failing to Establish an Encrypted Transport Connection
4.6.6. Encrypted Transport Failure
4.6.7. Handling Clean Shutdown of an Encrypted Transport
Connection
4.6.8. Sending a Query over Encrypted Transport
4.6.9. Receiving a Response over Encrypted Transport
4.6.10. Resource Exhaustion
4.6.11. Maintaining Connections
4.6.12. Additional Tuning
5. IANA Considerations
6. Privacy Considerations
6.1. Server Name Indication
6.2. Modeling the Probability of Encryption
7. Security Considerations
8. Operational Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Assessing the Experiment
Appendix B. Defense against Active Attackers
B.1. Signaling Mechanism Properties
B.2. Authentication of Authoritative Servers
B.3. Combining Protocols
Acknowledgements
Authors' Addresses
This document aims to provide guidance to DNS implementers and operators who want to simply enable protection against passive network observers.
このドキュメントは、パッシブネットワークオブザーバーに対する保護を単純に有効にしたいDNS実装者とオペレーターにガイダンスを提供することを目的としています。
In particular, it focuses on mechanisms that can be adopted unilaterally by recursive resolvers and authoritative servers, without any explicit coordination with the other parties. This guidance provides opportunistic security (see [RFC7435]), that is, encrypting things that would otherwise be in the clear, without interfering with or weakening stronger forms of security.
特に、他の当事者との明示的な調整なしに、再帰的なリゾルバーと権威あるサーバーによって一方的に採用できるメカニズムに焦点を当てています。このガイダンスは、日和見的なセキュリティ（[RFC7435を参照]を参照）を提供します。つまり、より強力な形式のセキュリティを妨害したり弱めたりすることなく、明確なものを暗号化します。
This document also briefly introduces (but does not try to specify) how a future protocol might permit defense against an active attacker in Appendix B.
また、このドキュメントでは、将来のプロトコルが付録Bでアクティブな攻撃者に対する防御をどのように許可するかを簡単に紹介します（ただし、指定しようとしません）。
The protocol described here offers three concrete advantages to the DNS ecosystem:
ここで説明するプロトコルは、DNSエコシステムに3つの具体的な利点を提供します。
* Protection from passive attackers of DNS queries in transit between recursive and authoritative servers.
* 再帰サーバーと権威あるサーバーの間の輸送中のDNSのパッシブ攻撃者からの保護。
* A road map for gaining real-world experience at scale with encrypted protections of this traffic.
* このトラフィックの暗号化された保護を伴う、大規模に現実世界のエクスペリエンスを獲得するためのロードマップ。
* A bridge to some possible future protection against a more powerful attacker.
* より強力な攻撃者に対する将来の保護の可能性への橋。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Unilateral:
一方的：
Capable of opportunistic probing without external coordination with any of the other parties.
他の当事者との外部調整なしに日和見的な調査が可能です。
Do53:
do53：
DNS over port 53 ([RFC1035]) for traditional cleartext transport.
従来のクリアテキスト輸送用のポート53（[RFC1035]）を超えるDNS。
DoQ:
doq：
DNS over QUIC ([RFC9250]).
dns over quic（[rfc9250]）。
DoT:
ドット：
DNS over TLS ([RFC7858]).
TLSを超えるDNS（[RFC7858]）。
Encrypted transports:
暗号化された交通機関：
DoQ and DoT, collectively.
DOQとDOT、集合的に。
The protocol described in this document was developed with two priorities: minimizing negative impacts and retaining flexibility in the underlying encrypted transport protocol.
このドキュメントで説明されているプロトコルは、2つの優先順位で開発されました。これは、マイナスの影響を最小限に抑え、基礎となる暗号化された輸送プロトコルの柔軟性を保持することです。
The protocol described in this document aims to minimize potentially negative impacts caused by the probing of encrypted transports for the systems that adopt the protocol, for the parties that those systems communicate with, and for uninvolved third parties. The negative impacts that this protocol specifically tries to minimize are:
このドキュメントで説明されているプロトコルは、プロトコルを採用するシステム、それらのシステムが通信する当事者、および無溶解された第三者のために、プロトコルを採用するシステムの暗号化された輸送の調査によって引き起こされる潜在的にマイナスの影響を最小限に抑えることを目的としています。このプロトコルが特に最小化しようとするマイナスの影響は次のとおりです。
* excessive bandwidth use,
* 過度の帯域幅の使用、
* excessive use of computational resources (CPU and memory in particular), and
* 計算リソース（特にCPUとメモリ）の過度の使用、および
* the potential for amplification attacks (where DNS resolution infrastructure is wielded as part of a DoS attack).
* 増幅攻撃の可能性（DNS解像度インフラストラクチャがDOS攻撃の一部として使用される場合）。
Although this document focuses specifically on strategies used by DNS servers, it does not go into detail on the specific protocols used because those protocols, in particular DoT and DoQ, are described in other documents. The DoT specification ([RFC7858]) says that it:
このドキュメントは、DNSサーバーが使用する戦略に特に焦点を当てていますが、これらのプロトコル、特にDOTとDOQが他のドキュメントで説明されているため、使用される特定のプロトコルについては詳しく説明しません。DOT仕様（[RFC7858]）は次のように述べています。
...focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.
... DPRIVEワーキンググループの憲章によると、スタブから再回復するトラフィックの保護に焦点を当てています。再帰的なトラフィックへのプロトコルの将来のアプリケーションを妨げるものではありません。
It further says:
さらに言う：
It might work equally between recursive clients and authoritative servers...
再帰的なクライアントと権威あるサーバーの間で平等に機能する可能性があります...
The DoQ specification ([RFC9250]) says:
DOQ仕様（[RFC9250]）は次のように述べています。
For the recursive to authoritative scenario, authentication requirements are unspecified at the time of writing and are the subject of ongoing work in the DPRIVE WG.
信頼できるシナリオへの再帰的な場合、執筆時点で認証要件は不特定であり、DPRIVE WGで継続的な作業の対象となっています。
The protocol described in this document specifies the use of DoT and DoQ without authentication of the server.
このドキュメントで説明されているプロトコルは、サーバーの認証なしでDOTとDOQの使用を指定しています。
This document does not pursue the use of DNS over HTTPS, commonly called "DoH" ([RFC8484]), in this context because a DoH client needs to know the path part of a DoH endpoint URL. Currently, there are no mechanisms for a DNS recursive resolver to predict the path on its own, in an opportunistic or unilateral fashion, without incurring an excessive use of resources. If such mechanisms are later defined, the protocol in this document can be updated to accommodate them.
この文書は、DOHクライアントがDOHエンドポイントURLのパス部分を知る必要があるため、このコンテキストでは、一般的に「DOH」（[RFC8484]）と呼ばれるHTTPSを介したDNSの使用を追求していません。現在、リソースの過度の使用を伴うことなく、日和見的または一方的な方法で、それ自体でパスを予測するためのDNS再帰リゾルバーのメカニズムはありません。そのようなメカニズムが後で定義された場合、このドキュメントのプロトコルを更新してそれらに対応できます。
The protocol described in this document is OPTIONAL for authoritative servers. An authoritative server choosing to implement the protocol described in this document MUST implement at least one of either DoT or DoQ on port 853.
このドキュメントで説明されているプロトコルは、権威あるサーバーに対してオプションです。このドキュメントで説明されているプロトコルを実装することを選択する権威あるサーバーは、ポート853にDOTまたはDOQの少なくとも1つを実装する必要があります。
An authoritative server choosing to implement the protocol described in this document MAY require clients to use Application-Layer Protocol Negotiation (ALPN) (see [RFC7301]). The ALPN strings the client will use are given in Section 4.4.
このドキュメントで説明されているプロトコルを実装することを選択する権威あるサーバーは、クライアントがアプリケーション層プロトコルネゴシエーション（ALPN）を使用することを要求する場合があります（[RFC7301]を参照）。クライアントが使用するALPN文字列は、セクション4.4に記載されています。
An authoritative server implementing DoT or DoQ MUST populate the response from the same authoritative zone data as the unencrypted DNS transports. Encrypted transports have their own characteristic response size that might be different from the unencrypted DNS transports, so response sizes and related options (e.g., Extension Mechanisms for DNS (EDNS0)) and flags (e.g., the TrunCation (TC) bit) might vary based on the transport. In other words, the content of the responses to a particular query MUST be the same regardless of the type of transport.
DOTまたはDOQを実装する権威あるサーバーは、暗号化されていないDNSトランスポートと同じ権威あるゾーンデータからの応答を入力する必要があります。暗号化されたトランスポートには、暗号化されていないDNSトランスポートとは異なる可能性のある独自の特徴的な応答サイズがあるため、応答サイズと関連オプション（DNS（EDNS0）の拡張メカニズム）およびフラグ（たとえば、切り捨て（TC）ビット）はベースになる可能性があります。輸送で。言い換えれば、特定のクエリへの応答の内容は、輸送の種類に関係なく同じでなければなりません。
Some authoritative DNS servers are structured as a pool of authoritatives standing behind a load balancer that runs on a single IP address, forwarding queries to members of the pool. In such a deployment, individual members of the pool typically get updated independently from each other.
一部の権威あるDNSサーバーは、単一のIPアドレスで実行されるロードバランサーの後ろに立っている権威あるプールとして構成され、プールのメンバーにクエリを転送します。このような展開では、プールの個々のメンバーは通常、互いに独立して更新されます。
A recursive resolver following the guidance in Section 4 and interacting with such a pool likely does not know that it is a pool. If some members of the pool follow the protocol specified in this document while others do not, the recursive client might see the pool as a single authoritative server that sometimes offers and sometimes refuses encrypted transport.
セクション4のガイダンスに続いて再帰的なリゾルバーは、そのようなプールと対話しても、それがプールであることを知らない可能性があります。プールの一部のメンバーは、このドキュメントで指定されたプロトコルに従っていますが、他のメンバーはそうでない場合、再帰的なクライアントは、プールを時々暗号化された輸送を提供し、時には拒否する単一の権威あるサーバーとして見るかもしれません。
To avoid incurring additional minor timeouts for such a recursive resolver, the pool operator SHOULD:
このような再帰リゾルバーに追加のマイナーなタイムアウトが発生しないようにするには、プールオペレーターは次のようにする必要があります。
* ensure that all members of the pool enable the same encrypted transport(s) within the span of a few seconds (such as within 30 seconds), or
* プールのすべてのメンバーが、数秒（30秒以内など）のスパン内で同じ暗号化された輸送を有効にすること、または
* ensure that the load balancer maps client requests to pool members based on client IP addresses, or
* ロードバランサーがクライアントのIPアドレスに基づいてプールメンバーにクライアントのリクエストをマッピングするか、または
* use a load balancer that forwards queries/connections on encrypted transports to only those members of the pool known (e.g., via monitoring) to support the given encrypted transport.
* 暗号化されたトランスポートのクエリ/接続を転送するロードバランサーを使用して、特定の暗号化された輸送をサポートするために、既知のプールのメンバーのみ（監視を介して）を使用します。
Similar concerns apply to authoritative servers responding from an anycast IP address. As long as the pool of servers is in a heterogeneous state, any flapping route that switches a given client IP address to a different responder risks incurring an additional timeout. Frequent changes of routing for anycast listening IP addresses are also likely to cause problems for TLS, TCP, or QUIC connection state as well, so stable routes are important to ensure that the service remains available and responsive. The servers in a pool can share session information to increase the likelihood of successful resumptions.
同様の懸念が、Anycast IPアドレスから応答する権威あるサーバーにも適用されます。サーバーのプールが不均一な状態にある限り、特定のクライアントIPアドレスを別のレスポンダーリスクに切り替える羽ばたきルートは、追加のタイムアウトを負担します。AnycastリスニングIPアドレスのルーティングの頻繁な変更も、TLS、TCP、またはQUIC接続状態に問題を引き起こす可能性が高いため、サービスが利用可能で応答性の高いものを確保するためには、安定したルートが重要です。プール内のサーバーは、セッション情報を共有して、繰り返しを成功させる可能性を高めることができます。
For unilateral deployment, an authoritative server does not need to offer any particular form of authentication.
一方的な展開のために、権威あるサーバーは特定の形式の認証を提供する必要はありません。
One simple deployment approach would just be to provide a self-issued, regularly updated X.509 certificate. Whether the certificates used are short-lived or long-lived is up to the deployment. This mechanism is supported by many TLS and QUIC clients and will be acceptable for any opportunistic connection. The server could provide a normal PKI-based certificate, but there is no advantage to doing so at this time.
単純な展開アプローチの1つは、自己発行の定期的に更新されたX.509証明書を提供することです。使用されている証明書が短命であるか、長寿命であるかは、展開次第です。このメカニズムは、多くのTLSおよびQUICクライアントによってサポートされており、日和見的なつながりには受け入れられます。サーバーは通常のPKIベースの証明書を提供できますが、現時点ではそれを行うことに利点はありません。
An authoritative DNS server that wants to handle unilateral queries MAY rely on Server Name Indication (SNI) to select alternate server credentials. However, such a server MUST NOT serve resource records that differ based on SNI (or on the lack of an SNI) provided by the client because a probing recursive resolver that offers SNI might or might not have used the right server name to get the records it is looking for.
一方的なクエリを処理したい権威あるDNSサーバーは、サーバー名表示（SNI）に依存して、代替サーバーの資格情報を選択できます。ただし、このようなサーバーは、SNIが提供するSNIが提供するSNI（またはSNIの欠如）に基づいて異なるリソースレコードを提供してはなりません。探しています。
A well-behaved recursive resolver may keep an encrypted connection open to an authoritative server to amortize the costs of connection setup for both parties.
行儀の良い再帰リゾルバーは、暗号化された接続を権威あるサーバーに開いて、両当事者の接続セットアップのコストを償却することができます。
However, some authoritative servers may have insufficient resources available to keep many connections open concurrently.
ただし、一部の権威あるサーバーには、多くの接続を同時に開いたままにするために利用可能なリソースが不十分な場合があります。
To keep resources under control, authoritative servers should proactively manage their encrypted connections. Section 5.5 of [RFC9250] offers useful guidance for servers managing DoQ connections. Section 3.4 of [RFC7858] offers useful guidance for servers managing DoT connections.
リソースを制御するために、権威あるサーバーは暗号化された接続を積極的に管理する必要があります。[RFC9250]のセクション5.5は、DOQ接続を管理するサーバーに便利なガイダンスを提供します。[RFC7858]のセクション3.4は、ドット接続を管理するサーバーに有用なガイダンスを提供します。
An authoritative server facing unforeseen resource exhaustion SHOULD cleanly close open connections from recursive resolvers based on the authoritative server's preferred prioritization.
予期せぬリソースの疲労に直面している権威あるサーバーは、権威あるサーバーの優先順位付けに基づいて、再帰的なリゾルバーからオープンな接続をきれいに閉じたはずです。
In the case of unanticipated resource exhaustion, close connections until resources are back in control. A reasonable prioritization scheme would be to close connections with no outstanding queries, ordered by idle time (longest idle time gets closed first), then close connections with outstanding queries, ordered by age of outstanding query (oldest outstanding query gets closed first).
予期しないリソースの疲労の場合、リソースが制御されるまで接続します。合理的な優先順位付けスキームは、アイドル時間（最長のアイドル時間が最初に閉じられる）で注文された未解決のクエリなしで接続を密接に接続することです。その後、未払いのクエリの年齢（最古の未払いのクエリが最初に閉じられます）で注文された未払いのクエリとの緊密な接続があります。
When resources are especially tight, the authoritative server may also decline to accept new connections over encrypted transport.
リソースが特にタイトな場合、権威あるサーバーは、暗号化されたトランスポートを介した新しい接続を受け入れることも拒否される場合があります。
To increase the anonymity set for each response, the authoritative server SHOULD use a sensible padding mechanism for all responses it sends when possible. The ability for the authoritative server to add padding might be limited, such as by not receiving an EDNS0 option in the query. Specifically, a DoT server SHOULD use EDNS0 padding [RFC7830] if possible, and a DoQ server SHOULD follow the guidance in Section 5.4 of [RFC9250]. How much to pad is out of scope of this document, but a reasonable suggestion can be found in [RFC8467].
各応答の匿名セットを増やすために、権威あるサーバーは、可能な場合に送信するすべての応答に対して賢明なパディングメカニズムを使用する必要があります。クエリでEDNS0オプションを受信しないなど、権威あるサーバーがパディングを追加する機能は制限される場合があります。具体的には、DOTサーバーは、可能であればEDNS0パディング[RFC7830]を使用する必要があり、DOQサーバーは[RFC9250]のセクション5.4のガイダンスに従う必要があります。このドキュメントの範囲外であるかどうかをパッドする量ですが、[RFC8467]には合理的な提案があります。
The protocol described in this document is OPTIONAL for recursive resolvers. This section outlines a probing policy suitable for unilateral adoption by any recursive resolver. Following this policy should not result in failed resolutions or significant delays.
このドキュメントで説明されているプロトコルは、再帰的なリゾルバーに対してオプションです。このセクションでは、再帰リゾルバーによる一方的な採用に適した調査ポリシーの概要を説明します。このポリシーに従うことで、解決策や大幅な遅延が失敗することはありません。
In addition to querying on Do53, the recursive resolver will try DoT, DoQ, or both concurrently. The recursive resolver remembers what opportunistic encrypted transport protocols have worked recently based on a (clientIP, serverIP, protocol) tuple.
DO53でのクエリに加えて、再帰リゾルバーはDOT、DOQ、またはその両方を同時に試します。再帰的なリゾルバーは、（clientip、serverIp、プロトコル）タプルに基づいて、日和見暗号化された輸送プロトコルが最近機能したものを覚えています。
If a query needs to go to a given authoritative server, and the recursive resolver remembers a recent successful encrypted transport to that server, then it doesn't send the query over Do53 at all. Rather, it only sends the query using the encrypted transport protocol that was recently shown to be good.
クエリが特定の権威あるサーバーに移動する必要があり、再帰リゾルバーがそのサーバーへの最近の成功した暗号化されたトランスポートを覚えている場合、DO53を超えてクエリを送信しません。むしろ、最近良いことが示された暗号化されたトランスポートプロトコルを使用してクエリを送信するだけです。
If the encrypted transport protocol fails, the recursive resolver falls back to Do53 for that serverIP. When any encrypted transport fails, the recursive resolver remembers that failure for a reasonable amount of time to avoid flooding an incompatible server with requests that it cannot accept. The description of how an encrypted transport protocol fails is in Section 4.6.4 and the sections following that.
暗号化されたトランスポートプロトコルが失敗した場合、再帰リゾルバーはそのServerIPのDO53に戻ります。暗号化されたトランスポートが失敗した場合、再帰的なリゾルバーは、受け入れられない要求で互換性のないサーバーに浸水することを避けるために、合理的な時間の間の失敗を覚えています。暗号化された輸送プロトコルがどのように失敗するかの説明は、セクション4.6.4にあり、それに続くセクション。
See the subsections below for a more detailed description of this protocol.
このプロトコルのより詳細な説明については、以下のサブセクションを参照してください。
In designing a probing strategy, the recursive resolver could record its knowledge about any given authoritative server with different strategies, including at least:
調査戦略を設計する際に、再帰リゾルバーは、少なくとも以下を含むさまざまな戦略を持つ特定の権威あるサーバーに関する知識を記録できます。
* the authoritative server's IP address,
* 権威あるサーバーのIPアドレス、
* the authoritative server's name (the NS record used), or
* 権威あるサーバーの名前（使用されているNSレコード）、または
* the zone that contains the record being looked up.
* 見上げられているレコードを含むゾーン。
This document encourages the first strategy, to minimize timeouts or accidental delays, and does not describe the other two strategies.
このドキュメントは、タイムアウトや偶発的な遅延を最小限に抑えるための最初の戦略を奨励し、他の2つの戦略については説明しません。
A timeout (accidental delay) is most likely to happen when the recursive client believes that the authoritative server offers encrypted transport, but the actual server reached declines encrypted transport (or worse, filters the incoming traffic and does not even respond with an ICMP destination port unreachable message, such as during rate limiting).
再帰的なクライアントが権威あるサーバーが暗号化されたトランスポートを提供していると信じているが、実際のサーバーは暗号化されたトランスポートを減少させた場合、タイムアウト（偶発的な遅延）が発生する可能性が最も高くなります（またはさらに悪いことに、ICMP宛先ポートで応答することさえできませんレート制限などの到達不可能なメッセージ）。
By associating the state with the authoritative IP address, the client can minimize the number of accidental delays introduced (see also Sections 3.1 and 4.5).
状態を権威あるIPアドレスに関連付けることにより、クライアントは導入された偶発的な遅延の数を最小限に抑えることができます（セクション3.1および4.5も参照）。
For example, consider an authoritative server named ns0.example.com that is served by two installations: one at 2001:db8::7 that follows this guidance and one at 2001:db8::8 that is a legacy (cleartext port 53-only) deployment. A recursive client who associates state with the NS name and reaches 2001:db8::7 first will "learn" that ns0.example.com supports encrypted transport. A subsequent query over encrypted transport dispatched to 2001:db8::8 would fail, potentially delaying the response.
たとえば、2つのインストールで提供されるNS0.example.comという名前の権威あるサーバーを考えてみましょう。1つは2001年：DB8 :: 7はこのガイダンスに続き、1つは2001年：DB8 :: 8はレガシーです（ClearText Port 53--のみ）展開。NSの名前に関連付けて2001年に到達する再帰クライアント：DB8 :: 7は、NS0.example.comが暗号化されたトランスポートをサポートすることを「学習」します。2001年に派遣された暗号化されたトランスポートを介した後続のクエリ：db8 :: 8は失敗し、応答を遅らせる可能性があります。
A recursive resolver implementing the protocol in this document needs to set system-wide values for some default parameters. These parameters may be set independently for each supported encrypted transport, though a simple implementation may keep the parameters constant across encrypted transports.
このドキュメントでプロトコルを実装する再帰リゾルバーは、一部のデフォルトパラメーターのシステム全体の値を設定する必要があります。これらのパラメーターは、サポートされている各暗号化されたトランスポートごとに独立して設定される場合がありますが、単純な実装により、暗号化された輸送全体でパラメーターが一定に保たれる場合があります。
+=============+==================================+===========+
| Name | Description | Suggested |
| | | Default |
+=============+==================================+===========+
| persistence | How long the recursive resolver | 3 days |
| | remembers a successful encrypted | (259200 |
| | transport connection | seconds) |
+-------------+----------------------------------+-----------+
| damping | How long the recursive resolver | 1 day |
| | remembers an unsuccessful | (86400 |
| | encrypted transport connection | seconds) |
+-------------+----------------------------------+-----------+
| timeout | How long the recursive resolver | 4 seconds |
| | waits for an initiated encrypted | |
| | connection to complete | |
+-------------+----------------------------------+-----------+
Table 1: Recursive Resolver System Parameters per Encrypted Transport
表1：暗号化された輸送ごとの再帰リゾルバーシステムパラメーター
This document uses the notation <transport>-foo to refer to the foo parameter for the encrypted transport <transport>. For example, DoT-persistence would indicate the length of time that the recursive resolver will remember that an authoritative server had a successful connection over DoT. Additionally, when describing an arbitrary encrypted transport, we use E in place of <transport> to generically mean whatever encrypted transport is in use. For example, when handling a query sent over encrypted transport E, a reference to E-timeout should be understood to mean DoT-timeout if the query is sent over DoT, and to mean DoQ-timeout if the query is sent over DoQ.
このドキュメントでは、notation <transport> -fooを使用して、暗号化されたトランスポート<Transport>のFOOパラメーターを参照しています。たとえば、Dot-Persistenceは、再帰的なリゾルバーが、権威あるサーバーがDOTを介して接続が成功したことを覚えている時間の長さを示します。さらに、任意の暗号化された輸送を説明する場合、<トランスポート>の代わりにEを使用して、暗号化された輸送が使用されているものを一般的に意味します。たとえば、暗号化されたトランスポートEを介して送信されたクエリを処理する場合、e-Timeoutへの参照は、クエリがDOTを介して送信された場合、ドットタイムアウトを意味し、クエリがDOQで送信された場合にDOQタイムアウトを意味することを理解する必要があります。
This document also assumes that the recursive resolver maintains a list of outstanding cleartext queries destined for the authoritative server's IP address X. This list is referred to as "Do53-queries[X]" This document does not attempt to describe the specific operation of sending and receiving cleartext DNS queries (Do53) for a recursive resolver. Instead it describes a "bolt-on" mechanism that extends the recursive resolver's operation on a few simple hooks into the recursive resolver's existing handling of Do53.
また、このドキュメントでは、再帰リゾルバーが、権威あるサーバーのIPアドレスXに導かれる未解決のクリアテキストクエリのリストを維持していることも想定しています。このリストは、「do53-queries [x]」と呼ばれます。再帰リゾルバーのClearText DNSクエリ（DO53）を受信します。代わりに、再帰リゾルバーの操作をいくつかの単純なフックで再帰リゾルバーの既存のDO53の取り扱いに拡張する「ボルトオン」メカニズムについて説明します。
Implementers or deployers of DNS recursive resolvers that follow the strategies in this document are encouraged to publish their preferred values of these parameters.
このドキュメントの戦略に従うDNS再帰リゾルバーの実装者または展開は、これらのパラメーターの好みの値を公開することを奨励されています。
To follow the strategies in this document, a recursive resolver MUST implement at least one of either DoT or DoQ in its capacity as a client of authoritative nameservers. A recursive resolver SHOULD implement the client side of DoT. A recursive resolver SHOULD implement the client side of DoQ.
このドキュメントの戦略に従うには、再帰的なリゾルバーは、権威ある名前サーバーのクライアントとしての能力で、DOTまたはDOQの少なくとも1つを実装する必要があります。再帰的なリゾルバーは、ドットのクライアント側を実装する必要があります。再帰的なリゾルバーは、DOQのクライアント側を実装する必要があります。
DoT queries from the recursive resolver MUST target TCP port 853 using an ALPN of "dot". DoQ queries from the recursive resolver MUST target UDP port 853 using an ALPN of "doq".
再帰リゾルバーからのドットクエリは、「ドット」のALPNを使用してTCPポート853をターゲットにする必要があります。再帰リゾルバーからのDOQクエリは、「DOQ」のALPNを使用してUDPポート853をターゲットにする必要があります。
While this document focuses on the recursive-to-authoritative hop, a recursive resolver implementing the strategies in this document SHOULD also accept queries from its clients over some encrypted transport unless it only accepts queries from the localhost.
このドキュメントでは、再帰的から承認へのホップに焦点を当てていますが、このドキュメントの戦略を実装する再帰リゾルバーは、ローカルホストからのクエリのみを受け入れない限り、暗号化されたトランスポートを介してクライアントからのクエリも受け入れる必要があります。
The recursive resolver SHOULD keep a record of the state for each authoritative server it contacts, indexed by the IP address of the authoritative server and the encrypted transports supported by the recursive resolver.
再帰的なリゾルバーは、接触する権威あるサーバーごとに状態の記録を保持する必要があります。これは、権威あるサーバーのIPアドレスと、再帰リゾルバーによってサポートされる暗号化されたトランスポンドによってインデックス付けされます。
Note that the recursive resolver might record this per-authoritative-IP state for each source IP address it uses as it sends its queries. For example, if a recursive resolver can send a packet to authoritative servers from IP addresses 2001:db8::100 and 2001:db8::200, it could keep two distinct sets of per-authoritative-IP state: one for each source address it uses, if the recursive resolver knows the addresses in use. Keeping these state tables distinct for each source address makes it possible for a pooled authoritative server behind a load balancer to do a partial rollout while minimizing accidental timeouts (see Section 3.1).
再帰的なリゾルバーは、クエリを送信するときに使用する各ソースIPアドレスに対して、この承認ごとのIP状態を記録する可能性があることに注意してください。たとえば、再帰リゾルバーがIPアドレス2001から信頼できるサーバーにパケットを送信できる場合：DB8 :: 100および2001：DB8 :: 200では、著者ごとのIP状態の2つの異なるセットを保持できます。再帰的なリゾルバーが使用中のアドレスを知っている場合、使用します。これらの状態テーブルを各ソースアドレスに明確に保つことで、ロードバランサーの後ろのプールされた権威あるサーバーが偶発的なタイムアウトを最小限に抑えながら部分的なロールアウトを行うことができます（セクション3.1を参照）。
In addition to tracking the state of connection attempts and outcomes, a recursive resolver SHOULD record the state of established sessions for encrypted protocols. The details of how sessions are identified are dependent on the transport protocol implementation (such as a TLS session ticket or TLS session ID, a QUIC connection ID, and so on). The use of session resumption as recommended here is limited somewhat because the tickets are only stored within the context defined by the (clientIP, serverIP, protocols) tuples used to track client-server interaction by the recursive resolver in a table like the one below. However, session resumption still offers the ability to optimize the handshake in some circumstances.
接続の試みと結果の状態を追跡することに加えて、再帰的なリゾルバーは、暗号化されたプロトコルの確立されたセッションの状態を記録する必要があります。セッションの特定方法の詳細は、トランスポートプロトコルの実装（TLSセッションチケットまたはTLSセッションID、QUIC接続IDなど）に依存します。ここで推奨されるセッション再開の使用は、（clientIP、serverIP、プロトコル、プロトコル）タプルによって定義されたコンテキスト内にのみ保存されているため、下のテーブルの再帰リゾルバーによるクライアントサーバーの相互作用を追跡するために使用されるタプルのみが保存されるため、やや制限されています。ただし、セッション再開は、状況によっては握手を最適化する機能を依然として提供します。
Each record should contain the following fields for each supported encrypted transport, each of which would initially be null:
各レコードには、サポートされている暗号化された輸送ごとに次のフィールドを含める必要があります。
+===============+======================================+=========+
| Name | Description | Retain |
| | | Across |
| | | Restart |
+===============+======================================+=========+
| session | The associated state of any existing | no |
| | established session (the structure | |
| | of this value is dependent on the | |
| | encrypted transport implementation). | |
| | If session is not null, it may be in | |
| | one of two states: pending or | |
| | established. | |
+---------------+--------------------------------------+---------+
| initiated | Timestamp of the most recent | yes |
| | connection attempt | |
+---------------+--------------------------------------+---------+
| completed | Timestamp of the most recent | yes |
| | completed handshake (which can | |
| | include one where an existing | |
| | session is resumed) | |
+---------------+--------------------------------------+---------+
| status | Enumerated value of success, fail, | yes |
| | or timeout associated with the | |
| | completed handshake | |
+---------------+--------------------------------------+---------+
| last-response | A timestamp of the most recent | yes |
| | response received on the connection | |
+---------------+--------------------------------------+---------+
| resumptions | A stack of resumption tickets (and | yes |
| | associated parameters) that could be | |
| | used to resume a prior successful | |
| | session | |
+---------------+--------------------------------------+---------+
| queries | A queue of queries intended for this | no |
| | authoritative server, each of which | |
| | has additional status of early, | |
| | unsent, or sent | |
+---------------+--------------------------------------+---------+
| last-activity | A timestamp of the most recent | no |
| | activity on the connection | |
+---------------+--------------------------------------+---------+
Table 2: Recursive Resolver State per-Authoritative-IP and per-Encrypted Transport
表2：再帰溶解状態の著作権IPおよび暗号化された輸送
Note that the session fields in aggregate constitute a pool of open connections to different servers.
集合体のセッションフィールドは、異なるサーバーへのオープン接続のプールを構成することに注意してください。
With the exception of the session, queries, and last-activity fields, this cache information should be kept across restart of the server unless explicitly cleared by administrative action.
セッション、クエリ、および最後のアクティビティフィールドを除き、このキャッシュ情報は、管理アクションによって明示的にクリアされない限り、サーバーの再開全体に保持する必要があります。
This document uses the notation E-foo[X] to indicate the value of field foo for encrypted transport E to IP address X.
このドキュメントでは、表記E-Foo [x]を使用して、暗号化されたトランスポートEのフィールドFOOの値をIPアドレスXに示します。
For example, DoT-initiated[192.0.2.4] represents the timestamp when the most recent DoT connection packet was sent to IP address 192.0.2.4.
たとえば、ドット開始[192.0.2.4]は、最新のDOT接続パケットがIPアドレス192.0.2.4に送信されたときのタイムスタンプを表します。
This document uses the notation any-E-queries to indicate any query on an encrypted transport.
このドキュメントでは、表記法を使用して、暗号化されたトランスポートのクエリを示します。
When a recursive resolver discovers the need for an authoritative lookup to an authoritative DNS server using that server's IP address X, it retrieves the connection state records described in Section 4.5 associated with X from its cache.
再帰的なリゾルバーが、そのサーバーのIPアドレスXを使用して権威あるDNSサーバーへの権威ある検索の必要性を発見すると、キャッシュからXに関連付けられたセクション4.5で説明されている接続状態レコードを取得します。
Some of the subsections that follow offer pseudocode that corresponds roughly to an asynchronous programming model for a recursive resolver's interactions with authoritative servers. All subsections also presume that the time of the discovery of the need for lookup is time T0.
以下のサブセクションの一部は、再帰的なリゾルバーと権威あるサーバーとの相互作用のための非同期プログラミングモデルに大まかに対応する擬似コードを提供します。また、すべてのサブセクションは、検索の必要性が発見された時期は時間T0であると推測しています。
If any of the records discussed here are absent, they are treated as null.
ここで議論されている記録のいずれかが存在しない場合、それらはヌルとして扱われます。
The recursive resolver must decide whether to initially send a query over Do53, or over either of the supported encrypted transports (DoT or DoQ).
再帰的なリゾルバーは、最初にDO53を介してクエリを送信するか、サポートされている暗号化されたトランスポート（DOTまたはDOQ）を介してクエリを送信するかを決定する必要があります。
Note that a recursive resolver might initiate this query via any or all of the known transports. When multiple queries are sent, the initial packets for each connection can be sent concurrently, similar to the method used in the document known as "Happy Eyeballs" ([RFC8305]). However, unlike Happy Eyeballs, when one transport succeeds, the other connections do not need to be terminated; instead they can be continued to establish whether the IP address X is capable of communicating on the relevant transport.
再帰的なリゾルバーは、既知のトランスポートのいずれかまたはすべてを介してこのクエリを開始する可能性があることに注意してください。複数のクエリが送信されると、各接続の初期パケットは、「Happy Eyeballs」（[RFC8305]）として知られるドキュメントで使用される方法と同様に、同時に送信できます。ただし、幸せな眼球とは異なり、1つの輸送が成功すると、他の接続を終了する必要はありません。代わりに、IPアドレスXが関連する輸送で通信できるかどうかを確立することができます。
For any of the supported encrypted transports E, the recursive resolver SHOULD NOT send a query to X over Do53 if either of the following holds true:
サポートされている暗号化されたトランスポートEのいずれかの場合、再帰リゾルバーは、次のいずれかが当てはまる場合は、x over do53にクエリを送信しないでください。
* E-session[X] is in the established state, or
* e-session [x]は確立された状態にあります、または
* E-status[X] is success and (T0 - E-last-response[X]) < persistence.
* e-status [x]は成功であり、（t0-e-last-response [x]）<永続性。
This indicates that one successful connection to a server that the client then closed cleanly would result in the client not sending the next query over Do53.
これは、クライアントがきれいに閉じたサーバーへの接続が1つ成功すると、クライアントがDO53を超えて次のクエリを送信しないことを示しています。
Otherwise, if there is no outstanding session for any encrypted transport, and the last successful encrypted transport connection was long ago, the recursive resolver sends a query to X over Do53. When it does so, it inserts a handle for the query in Do53-queries[X].
それ以外の場合、暗号化されたトランスポートの未解決のセッションがなく、最後に成功した暗号化されたトランスポート接続がずっと前にあった場合、再帰リゾルバーはXにクエリをDO53上に送信します。その場合、do53-queries [x]にクエリのハンドルを挿入します。
When any response R (a well-formed DNS response, asynchronous timeout, asynchronous destination port unreachable, etc.) for query Q arrives at the recursive resolver in cleartext sent over Do53 from an authoritative server with IP address X, the recursive resolver should perform the following.
クエリQの応答r（よく形成されたDNS応答、非同期タイムアウト、非同期宛先ポートなど）が、IPアドレスXを搭載した権威あるサーバーからDO53を介して送信されたClearTextの再帰リゾルバーに到着する場合、再帰的な制度装置は実行する必要があります。次の。
If Q is not in Do53-queries[X]:
qがdo53-queries [x]にない場合：
* process R no further (do not respond to a cleartext response to a query that is not outstanding).
* それ以上のプロセスはありません（未解決のクエリに対するクリアテキスト応答に応答しないでください）。
Otherwise, if Q was marked as already processed:
それ以外の場合、Qがすでに処理されているとマークされている場合：
* remove Q from Do53-queries[X],
* do53-queries [x]からqを削除し、
* discard any content from the response, and process R no further.
* 応答からコンテンツを破棄し、それ以上の処理を処理しません。
If R is a well-formed DNS response:
rが適切に形成されたDNS応答である場合：
* remove Q from Do53-queries[X],
* do53-queries [x]からqを削除し、
* process R further, and
* さらに処理します
* for each supported encrypted transport E:
* サポートされている暗号化された輸送ごとに：e：
- if Q is in E-queries[X], then
- qがe-queries [x]にある場合、
o mark Q as already processed.
o すでに処理されているQをマークします。
However, if R is malformed or a failure (e.g., a timeout or destination port unreachable), and
ただし、Rが不正行為または障害（例えば、タイムアウトまたは宛先ポートが到達できない場合）の場合、
* if Q is not in any of any-E-queries[X], then
* qが任意のQueries [x]のいずれにも含まれていない場合、
- treat this as a failed query (i.e., follow the resolver's policy for unresponsive or non-compliant authoritatives, such as falling back to another authoritative server, returning SERVFAIL to the requesting client, and so on).
- これを失敗したクエリとして扱います（つまり、別の権威あるサーバーに戻る、リクエストクライアントにサーブファイルを返すなど、反応しないまたは非準拠の権威者に関するResolverのポリシーに従います）。
If any E-session[X] is in the established state, the recursive resolver SHOULD NOT initiate a new connection or resume a previous connection to X over Do53 or E, but should instead send queries to X through the existing session (see Section 4.6.8).
e-session [x]が確立された状態にある場合、再帰リゾルバーは新しい接続を開始したり、以前のdo53またはeへの以前の接続を再開したりする必要はありませんが、代わりに既存のセッションを通じてxにクエリを送信する必要があります（セクション4.6を参照してください。.8）。
If the recursive resolver prefers one encrypted transport over another, but only the unpreferred encrypted transport is in the established state, it MAY also initiate a new connection to X over its preferred encrypted transport while concurrently sending the query over the established encrypted transport E.
再帰リゾルバーが1つの暗号化されたトランスポートを別の輸送よりも好みますが、確立された状態にあるが、未反対の暗号化された輸送のみが確立された状態にある場合、確立された暗号化された輸送E.上でクエリを同時に送信しながら、優先される暗号化された輸送を介してXへの新しい接続を開始する可能性があります。
Before considering whether to initiate a new connection over an encrypted transport, the timer should be examined, and its state possibly refreshed, for encrypted transport E to authoritative IP address X.
暗号化されたトランスポートを介して新しい接続を開始するかどうかを検討する前に、暗号化されたトランスポートEのために、信頼できるIPアドレスXへの輸送のために、タイマーを調べ、その状態をリフレッシュする可能性があります。
* If E-session[X] is in state pending, and
* e-session [x]が保留中の状態である場合、そして
* T0 - E-initiated[X] > E-timeout, then
* T0-e開始[x]> e-timeout、次に
- set E-session[X] to null, and
- e-session [x]をnullに設定します
- set E-status[X] to timeout.
- e-status [x]をタイムアウトに設定します。
When resources are available to attempt a new encrypted transport, the recursive resolver should only initiate a new connection to X over E as long as one of the following holds true:
新しい暗号化されたトランスポートを試みるためにリソースが利用可能な場合、再帰的なリゾルバーは、次のいずれかが真である限り、xを超えるxを超える新しい接続を開始する必要があります。
* E-status[X] is success, or
* e-status [x]は成功です
* E-status[X] is either fail or timeout and (T0 - E-completed[X]) > damping, or
* e-status [x]は失敗またはタイムアウトであり、（t0-e-completed [x]）> damping、または
* E-status[X] is null and E-initiated[X] is null.
* e-status [x]はnullで、e開始[x]はnullです。
When initiating a session to X over encrypted transport E, if E-resumptions[X] is not empty, one ticket should be popped off the stack and used to try to resume a previous session. Otherwise, the initial ClientHello handshake should not try to resume any session.
暗号化されたトランスポートEをXにxにセッションを開始する場合、e-resumptions [x]が空でない場合、1つのチケットをスタックからポップし、前のセッションを再開しようとするために使用する必要があります。それ以外の場合、最初のClientHelloの握手は、セッションを再開しようとしないでください。
When initiating a connection, the recursive resolver should take the following steps:
接続を開始するとき、再帰リゾルバーは次の手順を実行する必要があります。
* set E-initiated[X] to T0,
* e開始[x]をt0に設定し、
* store a handle for the new session (which should have pending state) in E-session[X], and
* e-session [x]に新しいセッション（保留中の状態があるはずです）のハンドルを保存し、
* insert a handle for the query that prompted this connection in E-queries[X], with status unsent or early, as appropriate (see below).
* e-queries [x]でこの接続を促したクエリのハンドルを挿入します。
Modern encrypted transports like TLS 1.3 offer the chance to send "early data" from the client in the initial ClientHello in some contexts. A recursive resolver that initiates a connection over an encrypted transport according to this guidance in a context where early data is possible SHOULD send the DNS query that prompted the connection in the early data, according to the sending guidance in Section 4.6.8.
TLS 1.3のような最新の暗号化されたトランスポートは、一部のコンテキストで最初のClientHelloでクライアントから「初期データ」を送信する機会を提供します。セクション4.6.8の送信ガイダンスに従って、初期のデータが可能なコンテキストでこのガイダンスに従ってこのガイダンスに従って接続を開始する再帰リゾルバーをこのガイダンスに従って、初期のデータの接続を促すDNSクエリを送信する必要があります。
If it does so, the status of Q in E-queries[X] should be set to early instead of unsent.
そうする場合、e-queries [x]のqのステータスは、無関心ではなく早期に設定する必要があります。
When initiating a new connection (whether by resuming an old session or not), the recursive resolver SHOULD request a session resumption ticket from the authoritative server. If the authoritative server supplies a resumption ticket, the recursive resolver pushes it into the stack at E-resumptions[X].
新しい接続を開始するとき（古いセッションを再開するかどうかにかかわらず）、再帰リゾルバーは権威あるサーバーからセッション再開チケットを要求する必要があります。権威あるサーバーが再開チケットを提供する場合、再帰リゾルバーはそれをe-Resumptions [x]のスタックに押し込みます。
For modern encrypted transports like TLS 1.3, most client implementations expect to send a Server Name Indication (SNI) in the ClientHello.
TLS 1.3のような最新の暗号化されたトランスポートの場合、ほとんどのクライアントの実装は、clienthelloでサーバー名表示（SNI）を送信することを期待しています。
There are two complications with selecting or sending an SNI in this unilateral probing.
この一方的な調査でSNIの選択または送信には、2つの合併症があります。
* Some authoritative servers are known by more than one name; selecting a single name to use for a given connection may be difficult or impossible.
* 一部の権威あるサーバーは、複数の名前で知られています。特定の接続に使用する単一の名前を選択することは困難または不可能です。
* In most configurations, the contents of the SNI field are exposed on the wire to a passive adversary. This potentially reveals additional information about which query is being made based on the NS of the query itself.
* ほとんどの構成では、SNIフィールドの内容がワイヤー上でパッシブ敵にさらされます。これにより、クエリ自体のNSに基づいてどのクエリが作成されているかについての追加情報が潜在的に明らかになります。
To avoid additional leakage and complexity, a recursive resolver following this guidance SHOULD NOT send an SNI to the authoritative server when attempting encrypted transport.
追加の漏れと複雑さを避けるために、このガイダンスに続く再帰リゾルバーは、暗号化されたトランスポートを試みる際に権威あるサーバーにSNIを送信する必要はありません。
If the recursive resolver needs to send an SNI to the authoritative server for some reason not found in this document, using Encrypted ClientHello ([TLS-ECH]) would reduce leakage.
再帰リゾルバーがこのドキュメントで見つからない理由で信頼できるサーバーにSNIを送信する必要がある場合、暗号化されたClientHello（[TLS-ECH]）を使用すると漏れが減少します。
Because this probing policy is unilateral and opportunistic, the client connecting under this policy MUST accept any certificate presented by the server. If the client cannot verify the server's identity, it MAY use that information for reporting, logging, or other analysis purposes; however, it MUST NOT reject the connection due to the authentication failure, as the result would be falling back to cleartext, which would leak the content of the session to a passive network monitor.
この調査ポリシーは一方的で日和見的であるため、このポリシーに基づいて接続するクライアントは、サーバーが提示した証明書を受け入れる必要があります。クライアントがサーバーのIDを確認できない場合、その情報をレポート、ロギング、またはその他の分析の目的に使用する場合があります。ただし、結果がClearTextに戻るため、認証障害のために接続を拒否してはなりません。これにより、セッションのコンテンツがパッシブネットワークモニターに漏れます。
When an encrypted transport connection actually completes (e.g., the TLS handshake completes) at time T1, the recursive resolver sets E-completed[X] to T1 and does the following.
暗号化されたトランスポート接続が実際に完了すると（たとえば、TLSハンドシェイクが完了する）、時間T1で、再帰リゾルバーはe-completed [x]からT1を設定し、次のことを行います。
If the handshake completed successfully, the recursive resolver:
握手が正常に完了した場合、再帰リゾルバー：
* updates E-session[X] so that it is in state established,
* e-session [x]を更新して、州が確立されるように、
* sets E-status[X] to success,
* e-status [x]を成功に設定し、
* sets E-last-response[X] to T1,
* e-last-response [x]からt1を設定します。
* sets E-completed[X] to T1, and
* e-completed [x]からt1を設定します
* for each query Q in E-queries[X]:
* e-queries [x]の各クエリqについて：
- if early data was accepted and Q is early, then
- 初期のデータが受け入れられ、Qが早い場合、
o sets the status of Q to sent.
o qのステータスを送信します。
- Otherwise:
- さもないと：
o sends Q through the session (see Section 4.6.8) and sets the status of Q to sent.
o セッションでQを送信し（セクション4.6.8を参照）、qのステータスを送信します。
If, at time T2, an encrypted transport handshake completes with a failure (e.g., a TLS alert):
時間T2で、暗号化されたトランスポートハンドシェイクが障害とともに完了した場合（例：TLSアラート）。
* set E-session[X] to null,
* e-session [x]をnullに設定し、
* set E-status[X] to fail,
* e-status [x]を失敗するように設定し、
* set E-completed[X] to T2, and
* e-completed [x]をt2に設定します
* for each query Q in E-queries[X]:
* e-queries [x]の各クエリqについて：
- if Q is not present in any other any-E-queries[X] or in Do53-queries[X], add Q to Do53-queries[X] and send query Q to X over Do53.
- Qが他の任意のQueries [x]またはdo53-queries [x]に存在しない場合、qをdo53-queries [x]に追加し、query qをx over do53に送信します。
Note that this failure will trigger the recursive resolver to fall back to cleartext queries to the authoritative server at IP address X. It will retry encrypted transport to X once the damping timer has elapsed.
この障害により、再帰リゾルバーがIPアドレスXの信頼できるサーバーへのクリアテキストクエリに戻るようにトリガーされることに注意してください。減衰タイマーが経過したら、暗号化されたトランスポートをXに再試行します。
Once established, an encrypted transport might fail for a number of reasons (e.g., decryption failure or improper protocol sequence).
確立されると、暗号化された輸送がいくつかの理由で故障する可能性があります（例：復号化の障害または不適切なプロトコルシーケンス）。
If this happens:
これが発生した場合：
* set E-session[X] to null,
* e-session [x]をnullに設定し、
* set E-status[X] to fail, and
* e-status [x]を失敗するように設定します
* for each query Q in E-queries[X]:
* e-queries [x]の各クエリqについて：
- if Q is not present in any other any-E-queries[X] or in Do53-queries[X], add Q to Do53-queries[X] and send query Q to X over Do53.
- Qが他の任意のQueries [x]またはdo53-queries [x]に存在しない場合、qをdo53-queries [x]に追加し、query qをx over do53に送信します。
Note that this failure will trigger the recursive resolver to fall back to cleartext queries to the authoritative server at IP address X. It will retry encrypted transport to X once the damping timer has elapsed.
この障害により、再帰リゾルバーがIPアドレスXの信頼できるサーバーへのクリアテキストクエリに戻るようにトリガーされることに注意してください。減衰タイマーが経過したら、暗号化されたトランスポートをXに再試行します。
At time T3, the recursive resolver may find that authoritative server X cleanly closes an existing outstanding connection (most likely due to resource exhaustion, see Section 3.4).
時間T3では、再帰的なリゾルバーは、権威あるサーバーXが既存の優れた接続をきれいに閉じていることを発見する場合があります（おそらく、リソースの使い果たしが原因で、セクション3.4を参照）。
When this happens:
これが起こるとき：
* set E-session[X] to null, and
* e-session [x]をnullに設定します
* for each query Q in E-queries[X]:
* e-queries [x]の各クエリqについて：
- if Q is not present in any other any-E-queries[X] or in Do53-queries[X], add Q to Do53-queries[X] and send query Q to X over Do53.
- Qが他の任意のQueries [x]またはdo53-queries [x]に存在しない場合、qをdo53-queries [x]に追加し、query qをx over do53に送信します。
Note that this premature shutdown will trigger the recursive resolver to fall back to cleartext queries to the authoritative server at IP address X. Any subsequent query to X will retry the encrypted connection promptly.
この時期尚早のシャットダウンにより、再帰リゾルバーがIPアドレスXの信頼できるサーバーへのクリアテキストクエリに戻るようにトリガーされることに注意してください。
When sending a query to an authoritative server over encrypted transport at time T4, the recursive resolver should take a few reasonable steps to ensure privacy and efficiency. After sending query Q, the recursive resolver should:
時間T4で暗号化されたトランスポートを介して権威あるサーバーにクエリを送信する場合、再帰リゾルバーはプライバシーと効率を確保するためにいくつかの合理的な手順を実行する必要があります。クエリqを送信した後、再帰リゾルバーは次のようにする必要があります。
* Ensure that Q's state in E-queries[X] is set to sent.
* e-queries [x]のQの状態が送信されるように設定されていることを確認してください。
* Set E-last-activity[X] to T4.
* e-last-activity [x]からt4を設定します。
The recursive resolver should also consider the guidance in the following subsections.
再帰リゾルバーは、次のサブセクションのガイダンスも考慮する必要があります。
To increase the anonymity set for each query, the recursive resolver SHOULD use a sensible padding mechanism for all queries it sends. Specifically, a DoT client SHOULD use EDNS0 padding [RFC7830], and a DoQ client SHOULD follow the guidance in Section 5.4 of [RFC9250]. How much to pad is out of scope of this document, but a reasonable suggestion can be found in [RFC8467].
クエリごとに匿名セットを増やすには、再帰リゾルバーが送信するすべてのクエリに対して賢明なパディングメカニズムを使用する必要があります。具体的には、DOTクライアントはEDNS0パディング[RFC7830]を使用する必要があり、DOQクライアントは[RFC9250]のセクション5.4のガイダンスに従う必要があります。このドキュメントの範囲外であるかどうかをパッドする量ですが、[RFC8467]には合理的な提案があります。
When multiple queries are multiplexed on a single encrypted transport to a single authoritative server, the recursive resolver SHOULD pipeline queries and MUST be capable of receiving responses out of order. For guidance on how to best achieve this on a given encrypted transport, see Section 6.2.1.1 of [RFC7766] (for DoT) and Section 5.6 of [RFC9250] (for DoQ).
単一の権威あるサーバーへの単一の暗号化されたトランスポートで複数のクエリが多重化されている場合、再帰的なリゾルバーはパイプラインクエリを行う必要があり、回答を順番に受信できる必要があります。特定の暗号化されたトランスポートでこれを最大限に達成する方法に関するガイダンスについては、[RFC7766]のセクション6.2.1.1（DOT）および[RFC9250]のセクション5.6（DOQ）を参照してください。
Even though session-level events on encrypted transports like clean shutdown (see Section 4.6.7) or encrypted transport failure (see Section 4.6.6) can happen, some events happen on encrypted transports that are specific to a query and are not session-wide. This subsection describes how the recursive resolver deals with events related to a specific query.
クリーンシャットダウン（セクション4.6.7を参照）や暗号化された輸送障害（セクション4.6.6を参照）などの暗号化されたトランスポートに関するセッションレベルのイベントが発生する可能性がありますが、一部のイベントは、クエリに固有でセッションではない暗号化されたトランスポートで発生します。広い。このサブセクションでは、再帰リゾルバーが特定のクエリに関連するイベントをどのように扱うかについて説明します。
When a query-specific response R (a well-formed DNS response or an asynchronous timeout) associated with query Q arrives at the recursive resolver over encrypted transport E from an authoritative server with IP address X at time T5, the recursive resolver should perform the following.
クエリ固有の応答r（よく形成されたDNS応答または非同期タイムアウト）がクエリQに関連付けられている場合、時間XでIPアドレスXを持つ権威あるサーバーから暗号化された輸送Eを超える再帰リゾルバーに到着すると、再帰解像度は実行されるはずです続く。
If Q is not in E-queries[X]:
qがe-queries [x]にない場合：
* discard the response and process R no further (do not respond to an encrypted response to a query that is not outstanding).
* 応答を破棄し、それ以上のプロセスrはありません（未解決のクエリに対する暗号化された応答に応答しないでください）。
Otherwise:
さもないと：
* remove Q from E-queries[X],
* e-queries [x]からqを削除し、
* set E-last-activity[X] to T5, and
* e-last-activity [x]からt5、および
* set E-last-response[X] to T5.
* e-last-response [x]をt5に設定します。
If Q was marked as already processed:
Qがすでに処理されているとマークされている場合：
* discard the response and process the response no further.
* 応答を破棄し、応答をそれ以上処理します。
If R is a well-formed DNS response:
rが適切に形成されたDNS応答である場合：
* process R further, and
* さらに処理します
* for each supported encrypted transport N other than E:
* e以外のサポートされている暗号化された輸送nについて：
- if Q is in N-queries[X], then
- qがn-queries [x]にある場合、
o mark Q as already processed.
o すでに処理されているQをマークします。
* If Q is in Do53-queries[X]:
* qがdo53-queries [x]にある場合：
- mark Q as already processed.
- すでに処理されているQをマークします。
However, if R is malformed or a failure (e.g., timeout), and
ただし、rが不正行為または障害（例：タイムアウト）である場合、および
* if Q is not in Do53-queries[X] or in any of any-E-queries[X], then
* qがdo53-queries [x]または任意のqueries [x]にない場合、
- treat this as a failed query (i.e., follow the resolver's policy for unresponsive or non-compliant authoritative servers, such as falling back to another authoritative server, returning SERVFAIL to the requesting client, and so on).
- これを失敗したクエリとして扱います（つまり、別の権威あるサーバーに戻る、サワイルを要求クライアントに返すなど、反応しないまたは非準拠の権威あるサーバーのリゾルバーのポリシーに従ってください）。
To keep resources under control, a recursive resolver should proactively manage outstanding encrypted connections. Section 5.5 of [RFC9250] offers useful guidance for clients managing DoQ connections. Section 3.4 of [RFC7858] offers useful guidance for clients managing DoT connections.
リソースを制御するために、再帰的なリゾルバーは、傑出した暗号化された接続を積極的に管理する必要があります。[RFC9250]のセクション5.5は、DOQ接続を管理するクライアントに便利なガイダンスを提供します。[RFC7858]のセクション3.4は、DOT接続を管理するクライアントに便利なガイダンスを提供します。
Even with sensible connection management, a recursive resolver doing unilateral probing may find resources unexpectedly scarce and may need to close some outstanding connections.
賢明な接続管理があっても、一方的な調査を行う再帰リゾルバーは、リソースが予想外に不足していることがわかり、いくつかの未解決の接続を閉じる必要がある場合があります。
In such a situation, the recursive resolver SHOULD use a reasonable prioritization scheme to close outstanding connections.
このような状況では、再帰リゾルバーは合理的な優先順位付けスキームを使用して、未解決の接続を閉じる必要があります。
One reasonable prioritization scheme would be to close outstanding established sessions based on E-last-activity[X] (i.e, the oldest timestamp gets closed first).
合理的な優先順位付けスキームの1つは、e-last-activity [x]（つまり、最も古いタイムスタンプが最初に閉鎖される）に基づいて、顕著な確立されたセッションを締めくくることです。
Note that when resources are limited, a recursive resolver following this guidance may also choose not to initiate new connections for encrypted transport.
リソースが制限されている場合、このガイダンスに従って再帰的なリゾルバーは、暗号化された輸送の新しい接続を開始しないことも選択する場合があることに注意してください。
Some recursive resolvers looking to amortize connection costs and minimize latency MAY choose to synthesize queries to a particular authoritative server to keep an encrypted transport session active.
接続コストを償却してレイテンシを最小限に抑えることを検討しているいくつかの再帰的なリゾルバーは、特定の権威あるサーバーにクエリを合成して、暗号化されたトランスポートセッションをアクティブに保つことを選択する場合があります。
A recursive resolver that adopts this approach should try to align the synthesized queries with other optimizations. For example, a recursive resolver that "pre-fetches" a particular resource record to keep its cache "hot" can send that query over an established encrypted transport session.
このアプローチを採用する再帰リゾルバーは、合成されたクエリを他の最適化と整列させる必要があります。たとえば、キャッシュを「ホット」に保つために特定のリソースレコードを「事前にフェッチ」する再帰リゾルバーは、確立された暗号化されたトランスポートセッションでそのクエリを送信できます。
A recursive resolver's state table for an authoritative server can contain additional information beyond what is described above. The recursive resolver might use that additional state to change the way it interacts with the authoritative server in the future. Some examples of additional states include the following.
権威あるサーバー用の再帰的なリゾルバーの状態テーブルには、上記のものを超えて追加情報を含めることができます。再帰的なリゾルバーは、その追加の状態を使用して、将来の権威あるサーバーとの対話方法を変更する可能性があります。追加の状態のいくつかの例には、以下が含まれます。
* Whether the server accepts "early data" over a transport such as DoQ.
* サーバーがDOQなどのトランスポートを介して「初期データ」を受け入れるかどうか。
* Whether the server fails to respond to queries after the handshake succeeds.
* ハンドシェイクが成功した後、サーバーがクエリに応答できないかどうか。
* Tracking the round-trip time of queries to the server.
* サーバーへのクエリの往復時間を追跡します。
* Tracking the number of timeouts (compared to the number of successful queries).
* タイムアウトの数を追跡します（クエリの成功数と比較）。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
A recursive resolver querying an authoritative server over DoT or DoQ that sends a Server Name Indication (SNI) in the clear in the cryptographic handshake leaks information about the intended query to a passive network observer.
暗号化された握手のクリアにサーバー名表示（SNI）を送信するDOTまたはDOQを介して権威あるサーバーをクエリする再帰リゾルバーは、受動的なネットワークオブザーバーに意図したクエリに関する情報を漏らします。
In particular, if two different zones refer to the same nameserver IP addresses via differently named NS records, a passive network observer can distinguish the queries to one zone from the queries to the other.
特に、2つの異なるゾーンが異なる名前付きNSレコードを介して同じ名前アーバーIPアドレスを参照する場合、パッシブネットワークオブザーバーはクエリをクエリから他のゾーンに区別できます。
Omitting SNI entirely, or using Encrypted ClientHello to hide the intended SNI, avoids this additional leakage. However, a series of queries that leak this information is still an improvement over cleartext.
SNIを完全に省略するか、暗号化されたClientHelloを使用して意図したSNIを非表示にすると、この追加の漏れを避けます。ただし、この情報をリークする一連のクエリは、クリアテキストよりも改善されています。
Given that there are many parameter choices that can be made by recursive resolvers and authoritative servers, it is reasonable to consider the probability that queries would be encrypted. Such a measurement would also certainly be affected by the types of queries being sent by the recursive resolver, which, in turn, is also related to the types of queries that are sent to the recursive resolver by the stub resolvers and forwarders downstream. Doing this type of research would be valuable to the DNS community after initial implementation by a variety of recursive resolvers and authoritative servers because it would help assess the overall DNS privacy value of implementing the protocol. Thus, it would be useful if recursive resolvers and authoritative servers reported percentages of queries sent and received over the different transports.
再帰的なリゾルバーと権威あるサーバーによって作成できる多くのパラメーターの選択があることを考えると、クエリが暗号化される確率を考慮することは合理的です。このような測定は、再帰リゾルバーによって送信されるクエリの種類によって確かに影響を受けるでしょう。これは、スタブリゾルバーと下流のフォワーダーによって再帰的なリゾルバーに送信されるクエリのタイプにも関連しています。このタイプの研究を行うことは、プロトコルの実装の全体的なDNSプライバシー値を評価するのに役立つため、さまざまな再帰リゾルバーと権威あるサーバーによる最初の実装後のDNSコミュニティにとって価値があります。したがって、再帰的なリゾルバーと権威あるサーバーが、異なる輸送で送信および受信されたクエリの割合を報告した場合に役立ちます。
The guidance in this document provides defense against passive network monitors for most queries. It does not defend against active attackers. It can also leak some queries and their responses due to Happy Eyeballs optimizations ([RFC8305]) when the recursive resolver's cache is cold.
このドキュメントのガイダンスは、ほとんどのクエリのパッシブネットワークモニターに対する防御を提供します。アクティブな攻撃者に対して防御しません。また、再帰的なリゾルバーのキャッシュが寒いときに、幸せな眼球の最適化（[RFC8305]）のために、いくつかのクエリとその応答を漏らすことができます。
Implementation of the guidance in this document should increase deployment of opportunistic encrypted DNS transport between recursive resolvers and authoritative servers at little operational risk.
このドキュメントでのガイダンスの実装は、再帰的リゾルバーと権威あるサーバー間の日和見暗号化されたDNS輸送の展開をほとんど運用上のリスクで展開するはずです。
However, implementers cannot rely on the guidance in this document for robust defense against active attackers: they should treat it as a stepping stone en route to stronger defense.
ただし、実装者は、アクティブな攻撃者に対する堅牢な防御のために、このドキュメントのガイダンスに依存することはできません。彼らは、より強力な防御への途中で踏み台として扱う必要があります。
In particular, a recursive resolver following the guidance in this document can easily be forced by an active attacker to fall back to cleartext DNS queries. Or, an active attacker could position itself as a machine-in-the-middle, which the recursive resolver would not defend against or detect due to lack of server authentication. Defending against these attacks without risking additional unexpected protocol failures would require signaling and coordination that are out of scope for this document.
特に、このドキュメントのガイダンスに続く再帰的なリゾルバーは、アクティブな攻撃者が簡単にクリアテキストDNSクエリに戻ることを余儀なくされる可能性があります。または、アクティブな攻撃者は自分自身を中程度の機械として位置付けることができます。これは、サーバー認証の不足のために再帰的なリゾルバーが防御したり検出したりしません。追加の予期しないプロトコルの障害を危険にさらすことなく、これらの攻撃に対して防御するには、このドキュメントの範囲外のシグナルと調整が必要です。
This guidance is only one part of operating a privacy-preserving DNS ecosystem. A privacy-preserving recursive resolver should adopt other practices as well, such as QNAME minimization ([RFC9156]), local root zone ([RFC8806]), etc., to reduce the overall leakage of query information that could infringe on the client's privacy.
このガイダンスは、プライバシーを提供するDNSエコシステムの運用の一部にすぎません。プライバシーを提供する再帰リゾルバーは、クライアントのプライバシーを侵害する可能性のあるクエリ情報の全体的な漏れを減らすために、QName最小化（[RFC9156]）、ローカルルートゾーン（[RFC8806]）など、他のプラクティスも採用する必要があります。。
As recursive resolvers implement this protocol, authoritative servers will see more probing on port 853 of IP addresses that are associated with NS records. Such probing of an authoritative server should generally not cause any significant problems. If the authoritative server is not supporting this protocol, it will not respond on port 853; if it is supporting this protocol, it will act accordingly.
再帰的なリゾルバーがこのプロトコルを実装すると、権威あるサーバーは、NSレコードに関連付けられているIPアドレスのポート853でより多くの調査を行います。権威あるサーバーのこのような調査は、一般に重大な問題を引き起こさないはずです。権威あるサーバーがこのプロトコルをサポートしていない場合、ポート853で応答しません。このプロトコルをサポートしている場合、それに応じて機能します。
However, a system that is a public recursive resolver that supports DoT and/or DoQ may also have an IP address that is associated with NS records. This could be accidental (such as a glue record with the wrong target address) or intentional. In such a case, a recursive resolver following this protocol will look for authoritative answers to ports 53 and 853 on that IP address. Additionally, the DNS server answering on port 853 would need to be able to differentiate queries for recursive answers from queries for authoritative answers (e.g., by having the authoritative server handle all queries that have the Recursion Desired (RD) flag unset).
ただし、DOTおよび/またはDOQをサポートする公開再帰リゾルバーであるシステムには、NSレコードに関連付けられたIPアドレスも搭載されている場合があります。これは、偶発的（ターゲットアドレスが間違っている接着剤レコードなど）または意図的なものである可能性があります。そのような場合、このプロトコルに続く再帰的なリゾルバーは、そのIPアドレスのポート53および853に対する権威ある回答を探します。さらに、ポート853で応答するDNSサーバーは、信頼できる回答のクエリから再帰的な回答のクエリを区別できる必要があります（たとえば、信頼できるサーバーに再帰が望ましい（RD）フラグUNSETを持つすべてのクエリを処理させることにより）。
As discussed in Section 7, the protocol described in this document provides no defense against active attackers. On a network where a captive portal is operating, some communications may be actively intercepted (e.g., when the network tries to redirect a user to complete an interaction with a captive portal server). A recursive resolver operating on a node that performs captive portal detection and Internet connectivity checks SHOULD delay encrypted transport probes to authoritative servers until after the node's Internet connectivity check policy has been satisfied.
セクション7で説明したように、このドキュメントで説明されているプロトコルは、アクティブな攻撃者に対する防御を提供しません。キャプティブポータルが動作しているネットワークでは、一部の通信が積極的に傍受される場合があります（たとえば、ネットワークがユーザーをリダイレクトしてキャプティブポータルサーバーとの対話を完了しようとする場合）。キャプティブポータル検出とインターネット接続チェックを実行するノードで動作する再帰リゾルバーは、ノードのインターネット接続チェックポリシーが満たされるまで、暗号化されたトランスポートプローブを権威あるサーバーに遅らせるはずです。
[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>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[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>.
[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>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015,
<https://www.rfc-editor.org/info/rfc7672>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016,
<https://www.rfc-editor.org/info/rfc7830>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8460] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,
and M. Risher, "SMTP TLS Reporting", RFC 8460,
DOI 10.17487/RFC8460, September 2018,
<https://www.rfc-editor.org/info/rfc8460>.
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
and J. Jones, "SMTP MTA Strict Transport Security (MTA-
STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
<https://www.rfc-editor.org/info/rfc8461>.
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
October 2018, <https://www.rfc-editor.org/info/rfc8467>.
[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>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<https://www.rfc-editor.org/info/rfc8806>.
[RFC9102] Dukhovni, V., Huque, S., Toorop, W., Wouters, P., and M.
Shore, "TLS DNSSEC Chain Extension", RFC 9102,
DOI 10.17487/RFC9102, August 2021,
<https://www.rfc-editor.org/info/rfc9102>.
[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
Name Minimisation to Improve Privacy", RFC 9156,
DOI 10.17487/RFC9156, November 2021,
<https://www.rfc-editor.org/info/rfc9156>.
[TLS-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>.
[DNS-ER] Arends, R. and M. Larson, "DNS Error Reporting", Work in
Progress, Internet-Draft, draft-ietf-dnsop-dns-error-
reporting-07, 17 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
dns-error-reporting-07>.
This document is an Experimental RFC. In order to assess the success of the experiment, some key metrics could be collected by the technical community about the deployment of the protocol in this document. These metrics will be collected in recursive resolvers, authoritative servers, and the networks containing them. Some key metrics include the following.
このドキュメントは実験的なRFCです。実験の成功を評価するために、このドキュメントのプロトコルの展開についてテクニカルコミュニティによっていくつかの重要なメトリックを収集することができます。これらのメトリックは、再帰的なリゾルバー、権威あるサーバー、およびそれらを含むネットワークで収集されます。いくつかの重要なメトリックには、以下が含まれます。
* Comparison of the CPU and memory use between Do53 and encrypted transports.
* DO53と暗号化された輸送の間のCPUとメモリの使用の比較。
* Comparison of the query response rates between Do53 and encrypted transports.
* DO53と暗号化された輸送の間のクエリ応答率の比較。
* Measurement of server authentication successes and failures.
* サーバー認証の成功と障害の測定。
* Measurement and descriptions of observed attack traffic, if any.
* 観察された攻撃トラフィックの測定と説明（ある場合）。
* Comparison of transactional bandwidth (ingress/egress, packets per second, bytes per second) between Do53 and encrypted transports.
* DO53と暗号化された輸送の間のトランザクション帯域幅（イングレス/出口、パケット、1秒あたりのバイト）の比較。
The protocol described in this document provides no defense against active attackers. A future protocol for recursive-to-authoritative DNS might want to provide such protection.
このドキュメントで説明されているプロトコルは、アクティブな攻撃者に対する防御を提供しません。再帰的から有権者へのDNSの将来のプロトコルは、そのような保護を提供したいと思うかもしれません。
This appendix assumes that the use case for that future protocol is a recursive resolver that wants to prevent an active attack on communication between it and an authoritative server that has committed to offering encrypted DNS transport. An inherent part of this use case is that the recursive resolver would want to respond with a SERVFAIL response to its client if it cannot make an authenticated encrypted connection to any of the authoritative nameservers for a name.
この付録は、その将来のプロトコルのユースケースは、暗号化されたDNSトランスポートを提供することを約束した権威あるサーバーとの間の通信に対する積極的な攻撃を防ぐことを望んでいる再帰リゾルバーであると想定しています。このユースケースの固有の部分は、名前の権威ある名前アーバーのいずれかに認証された暗号化された接続を作成できない場合、クライアントへのサーブファイルの応答で再帰的なリゾルバーが応答したいということです。
However, an authoritative server that merely offers encrypted transport (for example, by following the guidance in Section 3) has made no such commitment, and no recursive resolver that prioritizes delivery of DNS records to its clients would want to "fail closed" unilaterally.
ただし、暗号化されたトランスポートを単に提供する権威あるサーバー（たとえば、セクション3のガイダンスに従うことで）は、そのようなコミットメントを行いませんでした。また、クライアントへのDNSレコードの配信を優先する再帰リゾルバーは、一方的に「閉鎖」したいと考えています。
Therefore, such a future protocol would need at least three major distinctions from the protocol described in this document:
したがって、このような将来のプロトコルには、このドキュメントで説明されているプロトコルから少なくとも3つの大きな区別が必要になります。
* A signaling mechanism that tells the recursive resolver that the authoritative server intends to offer authenticated encryption.
* 信頼できるサーバーが認証された暗号化を提供することを意図していることを再帰的なリゾルバに伝えるシグナリングメカニズム。
* Authentication of the authoritative server.
* 権威あるサーバーの認証。
* A way to combine defense against an active attacker with the defenses described in this document.
* アクティブな攻撃者に対する防御を、この文書に記載されている防御を組み合わせる方法。
This can be thought of as a DNS analog to [RFC8461] or [RFC7672].
これは、[RFC8461]または[RFC7672]のDNSアナログと考えることができます。
To defend against an active attacker, the signaling mechanism needs to be able to indicate that the recursive resolver should fail closed if it cannot authenticate the server for a particular query.
アクティブな攻撃者を防御するには、シグナリングメカニズムが、特定のクエリに対してサーバーを認証できない場合、再帰リゾルバーが閉じたままになることを示すことができる必要があります。
The signaling mechanism itself would have to be resistant to downgrade attacks from active attackers.
シグナリングメカニズム自体は、アクティブな攻撃者からの攻撃のダウングレードに耐性がなければなりません。
One open question is how such a signal should be scoped. While this document scopes opportunistic state about encrypted transport based on the IP addresses of the client and server, signaled intent to offer encrypted transport is more likely to be scoped by the queried zone in the DNS or by the nameserver name than by the IP address.
未解決の質問の1つは、そのような信号をどのようにスコープする必要があるかです。このドキュメントは、クライアントとサーバーのIPアドレスに基づいた暗号化されたトランスポートに関する日和見状態を範囲しますが、暗号化されたトランスポートを提供する意図があることは、DNSのクエリゾーンまたはIPアドレスよりも名前サーバー名によってスコープされる可能性が高くなります。
A reasonable authoritative server operator or zone administrator probably doesn't want to risk breaking anything when they first enable the signal. Therefore, a signaling mechanism should probably also offer a means to report problems to the authoritative server operator without the client failing closed. Such a mechanism is likely to be similar to those described in [RFC8460] or [DNS-ER].
合理的な権威あるサーバーオペレーターまたはゾーン管理者は、おそらく最初に信号を有効にするときに何かを壊すリスクがありたくないでしょう。したがって、シグナル伝達メカニズムは、クライアントが閉じていることなく、権威あるサーバーオペレーターに問題を報告する手段もおそらく提供する必要があります。このようなメカニズムは、[rfc8460]または[dns-er]に記載されているメカニズムと類似している可能性があります。
Forms of server authentication might include:
サーバー認証のフォームには次のものが含まれます。
* An X.509 certificate issued by a widely known certification authority associated with the common NS names used for this authoritative server.
* この権威あるサーバーに使用される一般的なNS名に関連する広く知られている認証機関によって発行されたX.509証明書。
* DNS-Based Authentication of Named Entities (DANE) (to avoid infinite recursion, the DNS records necessary to authenticate could be transmitted in the TLS handshake using the DNSSEC chain extension (see [RFC9102])).
* DNSベースの名前付きエンティティ（DANE）の認証（無限の再帰を回避するために、認証に必要なDNSレコードは、DNSSECチェーン拡張を使用してTLSハンドシェイクに送信できます（[RFC9102]を参照）））。
A recursive resolver would have to verify the server's identity. When doing so, the identity would presumably be based on the NS name used for a given query or the IP address of the server.
再帰的なリゾルバーは、サーバーのIDを確認する必要があります。そうする場合、IDはおそらく、特定のクエリまたはサーバーのIPアドレスに使用されるNS名に基づいています。
If this protocol gains reasonable adoption, and a newer protocol that can offer defense against an active attacker were available, deployment is likely to be staggered and incomplete. This means that an operator that wants to maximize confidentiality for their users will want to use both protocols together.
このプロトコルが合理的な採用を獲得し、アクティブな攻撃者に対する防御を提供できる新しいプロトコルが利用可能である場合、展開はずらして不完全になる可能性があります。これは、ユーザーの機密性を最大化したいオペレーターが両方のプロトコルを一緒に使用したいことを意味します。
Any new stronger protocol should consider how it interacts with the opportunistic protocol defined here, so that operators are not faced with the choice between widespread opportunistic protection against passive attackers (this document) and more narrowly targeted protection against active attackers.
新しい強力なプロトコルは、ここで定義されている日和見プロトコルとの相互作用を検討する必要があります。これにより、オペレーターは、パッシブ攻撃者に対する広範な日和見的保護（この文書）とアクティブな攻撃者に対するより狭いターゲットの保護の選択に直面していません。
Many people contributed to the development of this document beyond the authors, including Alexander Mayrhofer, Brian Dickson, Christian Huitema, Dhruv Dhody, Eric Nygren, Erik Kline, Florian Obser, Haoyu Song, Jim Reid, Kris Shrishak, Peter Thomassen, Peter van Dijk, Ralf Weber, Rich Salz, Robert Evans, Sara Dickinson, Scott Hollenbeck, Stephane Bortzmeyer, Yorgos Thessalonikefs, and the DPRIVE Working Group.
多くの人々は、アレクサンダー・メールホーファー、ブライアン・ディクソン、クリスチャン・フイテマ、ドルフ・ドディ、エリック・ニグレン、エリック・クライン、フロリアン・オブザー、ハオユ・ソン、ジム・リード、クリス・シュリシャク、ピーター・トーマセン、ペテロ・ヴァン・バンシ、ラルフ・ウェーバー、リッチ・サルツ、ロバート・エヴァンス、サラ・ディキンソン、スコット・ホレンベック、ステファン・ボルツマイヤー、ヨルゴス・テッサロニケフ、およびDPRIVEワーキンググループ。
Daniel Kahn Gillmor (editor)
American Civil Liberties Union
125 Broad St.
New York, NY 10004
United States of America
Email: dkg@fifthhorseman.net
Joey Salazar (editor)
Alajuela
20201
Costa Rica
Email: joeygsal@gmail.com
Paul Hoffman (editor)
ICANN
United States of America
Email: paul.hoffman@icann.org