[要約] この文書は、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.
このドキュメントでは、インターネットコミュニティ向けの実験的プロトコルを定義しています。このドキュメントは、Internet Engineering Task Force (IETF) の成果物です。これはIETFコミュニティの合意を表しています。公開レビューを受け、Internet Engineering Steering Group (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.
Copyright (c) 2024 IETF Trustおよび文書の著者として特定された人物。All rights reserved.
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ドキュメントに関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eで説明されているRevised BSD Licenseテキストが含まれている必要があり、Revised BSD Licenseで説明されているように保証なしで提供されます。
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", "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上のDNS ([RFC1035])。
DoQ:
DoQ：
DNS over QUIC ([RFC9250]).
DNS over QUIC ([RFC9250])。
DoT:
DoT：
DNS over TLS ([RFC7858]).
DNS over TLS ([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]）と呼ばれるDNS over HTTPSの使用を追求していません。現在、リソースの過度の使用を伴うことなく、日和見的または一方的な方法で、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.
このドキュメントで説明されているプロトコルは、権威サーバーにとってOPTIONAL（任意）です。このドキュメントで説明されているプロトコルを実装することを選択する権威サーバーは、ポート853にDoTまたはDoQの少なくとも1つを実装しなければなりません（MUST）。
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.
このドキュメントで説明されているプロトコルを実装することを選択する権威サーバーは、クライアントがApplication-Layer Protocol Negotiation (ALPN) を使用することを要求してもかまいません（MAY）（[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トランスポートと同じ権威ゾーンデータから応答を生成しなければなりません（MUST）。暗号化されたトランスポートには、暗号化されていないDNSトランスポートとは異なる可能性のある独自の特徴的な応答サイズがあるため、応答サイズと関連オプション（例：DNSの拡張メカニズム（EDNS0））およびフラグ（例：切り捨て（TC）ビット）は、トランスポートに基づいて異なる場合があります。言い換えれば、特定のクエリへの応答の内容は、トランスポートの種類に関係なく同じでなければなりません（MUST）。
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:
このような再帰リゾルバに追加の軽微なタイムアウトが発生しないようにするには、プールオペレーターは次のようにすべきです（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.
同様の懸念が、エニーキャストIPアドレスから応答する権威サーバーにも適用されます。サーバーのプールが不均一な状態にある限り、特定のクライアントIPアドレスを別のレスポンダーに切り替えるフラッピングルートは、追加のタイムアウトを招くリスクがあります。エニーキャストリスニング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サーバーは、代替サーバーの資格情報を選択するためにServer Name Indication (SNI) に依存してもかまいません（MAY）。ただし、このようなサーバーは、クライアントによって提供されたSNI（またはSNIの欠如）に基づいて異なるリソースレコードを提供してはなりません（MUST NOT）。なぜなら、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は、DoT接続を管理するサーバーに有用なガイダンスを提供します。
An authoritative server facing unforeseen resource exhaustion SHOULD cleanly close open connections from recursive resolvers based on the authoritative server's preferred prioritization.
予期せぬリソースの枯渇に直面している権威サーバーは、権威サーバーの優先順位付けに基づいて、再帰リゾルバからのオープンな接続をきれいに閉じるべきです（SHOULD）。
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].
各応答の匿名性セットを増やすために、権威サーバーは、可能な場合に送信するすべての応答に対して賢明なパディングメカニズムを使用すべきです（SHOULD）。クエリでEDNS0オプションを受信しないなど、権威サーバーがパディングを追加する機能は制限される場合があります。具体的には、DoTサーバーは、可能であればEDNS0パディング[RFC7830]を使用すべきであり（SHOULD）、DoQサーバーは[RFC9250]のセクション5.4のガイダンスに従うべきです（SHOULD）。どれだけパディングするかはこのドキュメントの範囲外ですが、[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.
このドキュメントで説明されているプロトコルは、再帰リゾルバにとってOPTIONAL（任意）です。このセクションでは、再帰リゾルバによる一方的な採用に適したプロービングポリシーの概要を説明します。このポリシーに従うことで、解決の失敗や大幅な遅延が生じることはないはずです。
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, protocol) のタプルに基づいて、どの日和見的な暗号化トランスポートプロトコルが最近機能したかを記憶します。
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.
たとえば、ns0.example.comという名前の権威サーバーが2つのインストールによって提供されているとします。1つは2001:db8::7でこのガイダンスに従っており、もう1つは2001:db8::8でレガシー（平文ポート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.
このドキュメントでは、暗号化トランスポート <transport> の foo パラメータを参照するために、<transport>-foo という表記を使用します。たとえば、DoT-persistence は、権威サーバーが DoT 経由で接続に成功したことを再帰リゾルバが記憶する期間を示します。さらに、任意の暗号化トランスポートについて説明する場合、<transport> の代わりに E を使用して、使用中の暗号化トランスポートを総称的に意味します。たとえば、暗号化トランスポート E を介して送信されたクエリを処理する場合、E-timeout への参照は、クエリが DoT 経由で送信された場合は DoT-timeout を意味し、クエリが DoQ 経由で送信された場合は DoQ-timeout を意味すると理解する必要があります。
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]」と呼ばれます。このドキュメントでは、再帰リゾルバの平文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つを実装しなければなりません（MUST）。再帰リゾルバは、DoTのクライアント側を実装すべきです（SHOULD）。再帰リゾルバは、DoQのクライアント側を実装すべきです（SHOULD）。
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".
再帰リゾルバからのDoTクエリは、「dot」のALPNを使用してTCPポート853をターゲットにしなければなりません（MUST）。再帰リゾルバからのDoQクエリは、「doq」のALPNを使用してUDPポート853をターゲットにしなければなりません（MUST）。
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.
このドキュメントでは、再帰-権威間ホップに焦点を当てていますが、このドキュメントの戦略を実装する再帰リゾルバは、ローカルホストからのクエリのみを受け入れる場合を除き、暗号化されたトランスポートを介してクライアントからのクエリも受け入れるべきです（SHOULD）。
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.
再帰リゾルバは、接触する権威サーバーごとに状態の記録を保持すべきです（SHOULD）。これは、権威サーバーの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から権威サーバーにパケットを送信できる場合、再帰リゾルバが使用中のアドレスを知っていれば、使用する各ソースアドレスに対して1つずつ、2つの異なる権威IPごとの状態セットを保持できます。これらの状態テーブルを各ソースアドレスに対して別々に保持することで、ロードバランサーの背後にあるプールされた権威サーバーが、偶発的なタイムアウトを最小限に抑えながら部分的なロールアウトを行うことが可能になります（セクション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.
接続の試行と結果の状態を追跡することに加えて、再帰リゾルバは、暗号化されたプロトコルの確立されたセッションの状態を記録すべきです（SHOULD）。セッションの識別方法の詳細は、トランスポートプロトコルの実装（TLSセッションチケットまたはTLSセッションID、QUIC接続IDなど）に依存します。ここで推奨されるセッション再開の使用は、チケットが、以下の表のように再帰リゾルバによるクライアントサーバーの相互作用を追跡するために使用される (clientIP, serverIP, protocols) タプルによって定義されたコンテキスト内にのみ保存されるため、多少制限されます。ただし、セッション再開は、状況によってはハンドシェイクを最適化する機能を依然として提供します。
Each record should contain the following fields for each supported encrypted transport, each of which would initially be null:
各レコードには、サポートされている各暗号化トランスポートについて次のフィールドを含める必要があります。各フィールドは最初は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.
session、queries、および last-activity フィールドを除き、このキャッシュ情報は、管理アクションによって明示的にクリアされない限り、サーバーの再起動をまたいで保持する必要があります。
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] を使用して、IPアドレスXへの暗号化トランスポートEのフィールド foo の値を示します。
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.
たとえば、DoT-initiated[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.
このドキュメントでは、表記 any-E-queries を使用して、暗号化されたトランスポート上の任意のクエリを示します。
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のいずれかについて、次のいずれかが当てはまる場合、再帰リゾルバはDo53を介してXにクエリを送信すべきではありません（SHOULD NOT）。
* 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].
それ以外の場合、暗号化されたトランスポートのアクティブなセッションがなく、最後に成功した暗号化されたトランスポート接続がずっと前であった場合、再帰リゾルバはDo53を介してXにクエリを送信します。その場合、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を介して送信された平文で再帰リゾルバに到着した場合、再帰リゾルバは以下を実行する必要があります。
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
* Rをさらに処理し、
* 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が any-E-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).
- これを失敗したクエリとして扱います（つまり、別の権威サーバーにフォールバックする、要求クライアントにSERVFAILを返すなど、応答しないまたは非準拠の権威サーバーに対するリゾルバのポリシーに従います）。
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への新しい接続を開始したり、以前の接続を再開したりすべきではありません（SHOULD NOT）。代わりに、既存のセッションを通じて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への新しい接続を開始してもかまいません（MAY）。
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.
暗号化されたトランスポートを介して新しい接続を開始するかどうかを検討する前に、権威IPアドレスXへの暗号化されたトランスポートEについて、タイマーを調べ、その状態をリフレッシュすべきです。
* If E-session[X] is in state pending, and
* E-session[X] が保留中の状態であり、かつ
* T0 - E-initiated[X] > E-timeout, then
* T0 - E-initiated[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:
新しい暗号化されたトランスポートを試みるためにリソースが利用可能な場合、再帰リゾルバは、次のいずれかが真である限り、Eを介して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-initiated[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へのセッションを開始する場合、E-resumptions[X] が空でない場合、1つのチケットをスタックからポップし、前のセッションを再開しようとするために使用する必要があります。それ以外の場合、最初のClientHelloハンドシェイクは、セッションを再開しようとすべきではありません。
When initiating a connection, the recursive resolver should take the following steps:
接続を開始するとき、再帰リゾルバは次の手順を実行する必要があります。
* set E-initiated[X] to T0,
* E-initiated[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] にこの接続を促したクエリのハンドルを、必要に応じて unsent または early のステータスで挿入します（以下を参照）。
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クエリを初期データで送信すべきです（SHOULD）。
If it does so, the status of Q in E-queries[X] should be set to early instead of unsent.
そうする場合、E-queries[X] のQのステータスは、unsentではなくearlyに設定する必要があります。
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].
新しい接続を開始するとき（古いセッションを再開するかどうかにかかわらず）、再帰リゾルバは権威サーバーからセッション再開チケットを要求すべきです（SHOULD）。権威サーバーが再開チケットを提供する場合、再帰リゾルバはそれを 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を送信すべきではありません（SHOULD NOT）。
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を送信する必要がある場合、Encrypted 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.
このプロービングポリシーは一方的で日和見的であるため、このポリシーに基づいて接続するクライアントは、サーバーが提示した証明書を受け入れなければなりません（MUST）。クライアントがサーバーのIDを確認できない場合、その情報をレポート、ロギング、またはその他の分析の目的に使用してもかまいません（MAY）。ただし、結果が平文にフォールバックすることになり、セッションのコンテンツがパッシブネットワークモニターに漏れるため、認証失敗のために接続を拒否してはなりません（MUST NOT）。
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] を更新して、状態が established になるようにし、
* sets E-status[X] to success,
* E-status[X] を success に設定し、
* 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が early の場合、
o sets the status of Q to sent.
o Qのステータスを sent に設定します。
- 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のステータスを sent に設定します。
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] を fail に設定し、
* 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が他の any-E-queries[X] または Do53-queries[X] に存在しない場合、Qを Do53-queries[X] に追加し、クエリQをDo53を介してXに送信します。
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] を fail に設定し、
* 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が他の any-E-queries[X] または Do53-queries[X] に存在しない場合、Qを Do53-queries[X] に追加し、クエリQをDo53を介してXに送信します。
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が他の any-E-queries[X] または Do53-queries[X] に存在しない場合、Qを Do53-queries[X] に追加し、クエリQをDo53を介してXに送信します。
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の権威サーバーへの平文クエリにフォールバックするようにトリガーされることに注意してください。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の状態が sent に設定されていることを確認します。
* 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].
クエリごとに匿名性セットを増やすには、再帰リゾルバは送信するすべてのクエリに対して賢明なパディングメカニズムを使用すべきです（SHOULD）。具体的には、DoTクライアントはEDNS0パディング[RFC7830]を使用すべきであり（SHOULD）、DoQクライアントは[RFC9250]のセクション5.4のガイダンスに従うべきです（SHOULD）。どれだけパディングするかはこのドキュメントの範囲外ですが、[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).
単一の権威サーバーへの単一の暗号化されたトランスポートで複数のクエリが多重化されている場合、再帰リゾルバはクエリをパイプライン化すべきであり（SHOULD）、順序不同で応答を受信できなければなりません（MUST）。特定の暗号化されたトランスポートでこれを最大限に達成する方法に関するガイダンスについては、[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.
時間T5で、IPアドレスXを持つ権威サーバーから暗号化されたトランスポートEを介して、クエリQに関連付けられたクエリ固有の応答R（よく形成されたDNS応答または非同期タイムアウト）が再帰リゾルバに到着した場合、再帰リゾルバは以下を実行する必要があります。
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
* Rをさらに処理し、
* 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.
o 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]または any-E-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).
- これを失敗したクエリとして扱います（つまり、別の権威サーバーにフォールバックする、要求クライアントにSERVFAILを返すなど、応答しないまたは非準拠の権威サーバーに対するリゾルバのポリシーに従います）。
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.
このような状況では、再帰リゾルバは合理的な優先順位付けスキームを使用して、アクティブな接続を閉じるべきです（SHOULD）。
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.
接続コストを償却してレイテンシを最小限に抑えることを検討しているいくつかの再帰リゾルバは、特定の権威サーバーにクエリを合成して、暗号化されたトランスポートセッションをアクティブに保つことを選択する場合があります（MAY）。
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.
このドキュメントのガイダンスは、ほとんどのクエリに対してパッシブなネットワーク監視者に対する防御を提供します。アクティブな攻撃者に対しては防御しません。また、再帰リゾルバのキャッシュがコールドのときに、Happy Eyeballsの最適化（[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サーバーは、権威ある応答のクエリと再帰的な応答のクエリを区別できる必要があります（たとえば、権威サーバーにRecursion Desired (RD) フラグがセットされていないすべてのクエリを処理させることにより）。
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で説明したように、このドキュメントで説明されているプロトコルは、アクティブな攻撃者に対する防御を提供しません。キャプティブポータルが動作しているネットワークでは、一部の通信が積極的に傍受される場合があります（たとえば、ネットワークがユーザーをリダイレクトしてキャプティブポータルサーバーとの対話を完了しようとする場合）。キャプティブポータル検出とインターネット接続チェックを実行するノードで動作する再帰リゾルバは、ノードのインターネット接続チェックポリシーが満たされるまで、権威サーバーへの暗号化されたトランスポートプローブを遅らせるべきです（SHOULD）。
[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秒あたりのパケット数、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トランスポートを提供することを約束した権威サーバーとの間の通信に対するアクティブな攻撃を防ぐことを望んでいる再帰リゾルバであると想定しています。このユースケースの固有の部分は、名前の権威ネームサーバーのいずれかに認証された暗号化された接続を作成できない場合、再帰リゾルバがクライアントにSERVFAIL応答で応答したいということです。
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アドレスに基づいて暗号化されたトランスポートに関する日和見状態をスコープしますが、暗号化されたトランスポートを提供する意図のシグナルは、IPアドレスよりも、DNSのクエリ対象ゾーンまたはネームサーバー名によってスコープされる可能性が高くなります。
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.
多くの人々が、著者以外にもこのドキュメントの開発に貢献しました。その中には、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、および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