[要約] RFC 8932は、DNSプライバシーサービス運用者への推奨事項を提供します。その目的は、ユーザーのプライバシー保護を強化することにあります。この文書は、DNSクエリの暗号化とデータ保護の実践を促進するために利用されます。
Internet Engineering Task Force (IETF) S. Dickinson
Request for Comments: 8932 Sinodun IT
BCP: 232 B. Overeinder
Category: Best Current Practice R. van Rijswijk-Deij
ISSN: 2070-1721 NLnet Labs
A. Mankin
Salesforce
October 2020
Recommendations for DNS Privacy Service Operators
DNSプライバシーサービス事業者のための推奨事項
Abstract
概要
This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users.
このドキュメントは、DNSプライバシーサービスを提供することを選択したDNS再帰リゾルバ演算子に関する運用上の、ポリシー、およびセキュリティ上の考慮事項を示しています。これらの推奨事項を使用すると、オペレータはどのサービスを提供するかについての意図的な決定を下し、これらの決定と代替案がユーザーのプライバシーに影響を与える方法を理解できます。
This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841.
この文書はまた、RFC 6841に記載されているDNSセキュリティ拡張（DNSSEC）ポリシーおよびDNSSEC実践ステートメントの類似した、再帰的なオペレータプライバシーステートメントの作家を支援するための非規範的なフレームワークを提示します。
Status of This Memo
本文書の位置付け
This memo documents an Internet Best Current Practice.
このメモはインターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。BCPの詳細情報は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/rfc8932.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8932で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Scope
3. Privacy-Related Documents
4. Terminology
5. Recommendations for DNS Privacy Services
5.1. On the Wire between Client and Server
5.1.1. Transport Recommendations
5.1.2. Authentication of DNS Privacy Services
5.1.3. Protocol Recommendations
5.1.4. DNSSEC
5.1.5. Availability
5.1.6. Service Options
5.1.7. Impact of Encryption on Monitoring by DNS Privacy
Service Operators
5.1.8. Limitations of Fronting a DNS Privacy Service with a
Pure TLS Proxy
5.2. Data at Rest on the Server
5.2.1. Data Handling
5.2.2. Data Minimization of Network Traffic
5.2.3. IP Address Pseudonymization and Anonymization Methods
5.2.4. Pseudonymization, Anonymization, or Discarding of Other
Correlation Data
5.2.5. Cache Snooping
5.3. Data Sent Onwards from the Server
5.3.1. Protocol Recommendations
5.3.2. Client Query Obfuscation
5.3.3. Data Sharing
6. Recursive Operator Privacy Statement (RPS)
6.1. Outline of an RPS
6.1.1. Policy
6.1.2. Practice
6.2. Enforcement/Accountability
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Documents
A.1. Potential Increases in DNS Privacy
A.2. Potential Decreases in DNS Privacy
A.3. Related Operational Documents
Appendix B. IP Address Techniques
B.1. Categorization of Techniques
B.2. Specific Techniques
B.2.1. Google Analytics Non-Prefix Filtering
B.2.2. dnswasher
B.2.3. Prefix-Preserving Map
B.2.4. Cryptographic Prefix-Preserving Pseudonymization
B.2.5. Top-Hash Subtree-Replicated Anonymization
B.2.6. ipcipher
B.2.7. Bloom Filters
Appendix C. Current Policy and Privacy Statements
Appendix D. Example RPS
D.1. Policy
D.2. Practice
Acknowledgements
Contributors
Authors' Addresses
The Domain Name System (DNS) is at the core of the Internet; almost every activity on the Internet starts with a DNS query (and often several). However, the DNS was not originally designed with strong security or privacy mechanisms. A number of developments have taken place in recent years that aim to increase the privacy of the DNS, and these are now seeing some deployment. This latest evolution of the DNS presents new challenges to operators, and this document attempts to provide an overview of considerations for privacy-focused DNS services.
ドメインネームシステム（DNS）はインターネットの中核にあります。インターネット上のほとんどすべてのアクティビティは、DNSクエリ（そして多くの場合数）で始まります。ただし、DNSはもともと強力なセキュリティまたはプライバシーメカニズムで設計されていませんでした。近年、DNSのプライバシーを高めることを目的とした多くの開発が行われており、これらは現在展開を見ています。DNSのこの最新の進化は、オペレータに新しい課題を提示し、このドキュメントでは、プライバシーに焦点を当てたDNSサービスに関する考慮事項の概要を説明しようとします。
In recent years, there has also been an increase in the availability of "public resolvers" [RFC8499], which users may prefer to use instead of the default network resolver, either because they offer a specific feature (e.g., good reachability or encrypted transport) or because the network resolver lacks a specific feature (e.g., strong privacy policy or unfiltered responses). These public resolvers have tended to be at the forefront of adoption of privacy-related enhancements, but it is anticipated that operators of other resolver services will follow.
近年、「Public Resolvers」[RFC8499]の利用可能性も増加しており、ユーザーは特定の機能を提供するため、デフォルトのネットワークリゾルバの代わりに使用することをお勧めします（例：良い到達可能性や暗号化されたトランスポートなど）。またはネットワークリゾルバには特定の機能（例えば、強力なプライバシーポリシーまたはフィルタリングされていない応答）がないためです。これらのパブリックリゾルガーは、プライバシー関連の機能強化の採用の最前線にある傾向がありましたが、他のリゾルバサービスのオペレータが続くと予想されます。
Whilst protocols that encrypt DNS messages on the wire provide protection against certain attacks, the resolver operator still has (in principle) full visibility of the query data and transport identifiers for each user. Therefore, a trust relationship (whether explicit or implicit) is assumed to exist between each user and the operator of the resolver(s) used by that user. The ability of the operator to provide a transparent, well-documented, and secure privacy service will likely serve as a major differentiating factor for privacy-conscious users if they make an active selection of which resolver to use.
ワイヤ上のDNSメッセージを暗号化するプロトコルは、特定の攻撃に対して保護を提供しながら、リゾルバオペレータは依然としてクエリデータの完全な可視性と各ユーザのトランスポート識別子の完全な可視性を有する。したがって、信頼関係（明示的または暗黙的）が、各ユーザーとそのユーザーが使用するリゾルバのオペレータの間に存在すると見なされます。オペレータが透明、よく文書化された安全なプライバシーサービスを提供する能力は、使用するリゾルバのアクティブな選択を行う場合、プライバシーを意識したユーザーの主要な区別要因として機能する可能性があります。
It should also be noted that there are both advantages and disadvantages to a user choosing to configure a single resolver (or a fixed set of resolvers) and an encrypted transport to use in all network environments. For example, the user has a clear expectation of which resolvers have visibility of their query data. However, this resolver/transport selection may provide an added mechanism for tracking them as they move across network environments. Commitments from resolver operators to minimize such tracking as users move between networks are also likely to play a role in user selection of resolvers.
また、単一のリゾルバ（または固定されたリゾルバセット）と、すべてのネットワーク環境で使用する暗号化されたトランスポートとを選択することを選択したユーザに対する利点と欠点の両方があることにも留意されたい。例えば、ユーザはどのリゾルバがそれらのクエリデータの可視性を有するかを明確に期待している。しかしながら、このリゾルバ/トランスポート選択は、それらをネットワーク環境にわたって移動するときにそれらを追跡するための追加されたメカニズムを提供することができる。リゾルバ演算子からのコミットメントは、ネットワーク間で移動するためのそのような追跡を最小化して、リゾルバのユーザー選択に役割を果たす可能性があります。
More recently, the global legislative landscape with regard to personal data collection, retention, and pseudonymization has seen significant activity. Providing detailed practice advice about these areas to the operator is out of scope, but Section 5.3.3 describes some mitigations of data-sharing risk.
ごく最近では、個人データ収集、保持、および疑似法に関するグローバルな立法景観が重要な活動を見てきました。これらの分野についての詳細な慣習的なアドバイスを事業者に提供することは範囲外ですが、5.3.3節ではデータ共有リスクのいくつかの軽減について説明しています。
This document has two main goals:
この文書には2つの主な目標があります。
* To provide operational and policy guidance related to DNS over encrypted transports and to outline recommendations for data handling for operators of DNS privacy services.
* DNSに関連するDNSに関連する運用上および政策のガイダンスを、DNSプライバシーサービスの事業者のためのデータ処理のための推奨事項の概要を説明するため。
* To introduce the Recursive operator Privacy Statement (RPS) and present a framework to assist writers of an RPS. An RPS is a document that an operator should publish that outlines their operational practices and commitments with regard to privacy, thereby providing a means for clients to evaluate both the measurable and claimed privacy properties of a given DNS privacy service. The framework identifies a set of elements and specifies an outline order for them. This document does not, however, define a particular privacy statement, nor does it seek to provide legal advice as to the contents of an RPS.
* 再帰的なオペレータのプライバシーに関する声明（RPS）を紹介し、RPSの作家を支援するためのフレームワークを提示する。RPSは、オペレータがプライバシーに関してそれらの運用慣行およびコミットメントを概説することを公表するべき文書であり、それによってクライアントが特定のDNSプライバシーサービスの測定可能および主張されたプライバシー特性の両方を評価するための手段を提供する。フレームワークは一連の要素を識別し、それらのアウトライン順序を指定します。しかしながら、この文書は特定のプライバシーに関する声明を定義したり、RPSの内容について法的アドバイスを提供しようとしたりしません。
A desired operational impact is that all operators (both those providing resolvers within networks and those operating large public services) can demonstrate their commitment to user privacy, thereby driving all DNS resolution services to a more equitable footing. Choices for users would (in this ideal world) be driven by other factors -- e.g., differing security policies or minor differences in operator policy -- rather than gross disparities in privacy concerns.
所望の動作上の影響は、すべてのオペレータ（ネットワーク内のリゾルバと大規模な公共サービスを事業を展開するもの）がユーザーのプライバシーへのコミットメントを実証することができ、それによってすべてのDNS解決サービスをより公平なフッディングに運転することです。ユーザーのための選択肢は（この理想的な世界で）プライバシーに関する懸念における総格差ではなく、セキュリティポリシーまたはオペレータポリシーのわずかな違いの異なる他の要因によって推進されます。
Community insight (or judgment?) about operational practices can change quickly, and experience shows that a Best Current Practice (BCP) document about privacy and security is a point-in-time statement. Readers are advised to seek out any updates that apply to this document.
コミュニティの洞察（または判断？）運用慣行については迅速に変わる可能性があり、経験はプライバシーとセキュリティに関する最良の現在の練習（BCP）文書がポイントインタイムステートメントであることを示しています。読者はこの文書に適用される更新を模索することをお勧めします。
"DNS Privacy Considerations" [RFC7626] describes the general privacy issues and threats associated with the use of the DNS by Internet users; much of the threat analysis here is lifted from that document and [RFC6973]. However, this document is limited in scope to best-practice considerations for the provision of DNS privacy services by servers (recursive resolvers) to clients (stub resolvers or forwarders). Choices that are made exclusively by the end user, or those for operators of authoritative nameservers, are out of scope.
「DNSプライバシーに関する考慮事項」[RFC7626]は、インターネットユーザーによるDNSの使用に関連する一般的なプライバシーの問題と脅威について説明しています。ここでの脅威分析の多くはその文書から持ち上げられ、[RFC6973]。ただし、このドキュメントは、サーバー（再帰的なリゾルバ）によるDNSプライバシーサービスをクライアント（スタブリゾルバまたはフォワーダ）に提供するための範囲内での最適な考慮事項に制限されています。エンドユーザーが排他的に作成されている選択、または権威あるネームサーバーの演算子は範囲外です。
This document includes (but is not limited to) considerations in the following areas:
この文書には、次の分野では考慮事項が含まれています（ただし、これらに限定されません）。
1. Data "on the wire" between a client and a server.
1. クライアントとサーバーの間のデータ "ワイヤー"。
2. Data "at rest" on a server (e.g., in logs).
2. サーバー上のデータ "At REST"（例えば、ログ内）。
3. Data "sent onwards" from the server (either on the wire or shared with a third party).
3. データ "wire上のどちらかで、またはサードパーティと共有されている）のデータ" onwards "。
Whilst the issues raised here are targeted at those operators who choose to offer a DNS privacy service, considerations for areas 2 and 3 could equally apply to operators who only offer DNS over unencrypted transports but who would otherwise like to align with privacy best practice.
ここで提起された問題は、DNSプライバシーサービスを提供することを選択した演算子を対象としていますが、エリア2と3の考慮事項は、暗号化されていないトランスポートに対してのみDNSを提供するが、その他の方法ではプライバシーのベストプラクティスと整合したいと考えられます。
There are various documents that describe protocol changes that have the potential to either increase or decrease the privacy properties of the DNS in various ways. Note that this does not imply that some documents are good or bad, better or worse, just that (for example) some features may bring functional benefits at the price of a reduction in privacy, and conversely some features increase privacy with an accompanying increase in complexity. A selection of the most relevant documents is listed in Appendix A for reference.
さまざまな方法でDNSのプライバシー特性を増減する可能性があるプロトコルの変更を記述する様々な文書があります。これは、一部の文書が良くなったり悪い、良くなったり悪くなったりすることがわかりません（たとえば）プライバシーの低下の価格で機能的な利点をもたらす可能性がある、そして逆にいくつかの特徴が増加したプライバシーを高めることができることに注意してください。複雑。最も関連のある文書の選択は、参照については付録Aに記載されています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
DNS terminology is as described in [RFC8499], except with regard to the definition of privacy-enabling DNS server in Section 6 of [RFC8499]. In this document we use the full definition of a DNS over (D)TLS privacy-enabling DNS server as given in [RFC8310], i.e., that such a server should also offer at least one of the credentials described in Section 8 of [RFC8310] and implement the (D)TLS profile described in Section 9 of [RFC8310].
DNSの用語は[RFC8499]のセクション6のPrivacy-Enabled DNSサーバーの定義に関しては、[RFC8499]で説明されています。この文書では、[RFC8310]で与えられたDNSサーバーの完全な定義を使用します。[RFC8310]のセクション9に記載されている（D）TLSプロファイルを実装します。
Other Terms:
その他の用語：
RPS: Recursive operator Privacy Statement; see Section 6.
RPS：再帰的なオペレーターのプライバシーに関する声明。セクション6を参照してください。
DNS privacy service: The service that is offered via a privacy-enabling DNS server and is documented either in an informal statement of policy and practice with regard to users privacy or a formal RPS.
DNSプライバシーサービス：プライバシーを有効にするDNSサーバーを介して提供されるサービスは、ユーザーのプライバシーまたは正式なRPSに関する非公式のポリシー宣言で文書化されています。
In the following sections, we first outline the threats relevant to the specific topic and then discuss the potential actions that can be taken to mitigate them.
次のセクションでは、最初に特定のトピックに関連する脅威の概要を概説してから、それらを軽減することができる潜在的な行動について説明します。
We describe two classes of threats:
2つのクラスの脅威を説明します。
* Threats described in [RFC6973], "Privacy Considerations for Internet Protocols"
* [RFC6973]、「インターネットプロトコルのプライバシーに関する考慮事項」で説明されている脅威
- Privacy terminology, threats to privacy, and mitigations as described in Sections 3, 5, and 6 of [RFC6973].
- [RFC6973]のセクション3,5、および6のセクション3,5、および6に記載されているプライバシーの用語、プライバシーへの脅威、および軽減。
* DNS Privacy Threats
* DNSプライバシーの脅威
- These are threats to the users and operators of DNS privacy services that are not directly covered by [RFC6973]. These may be more operational in nature, such as certificate-management or service-availability issues.
- これらは、[RFC6973]で直接カバーされていないDNSプライバシーサービスのユーザーおよび事業者に対する脅威です。これらは、証明書管理やサービス可用性の問題など、自然の中でより操作可能である可能性があります。
We describe three classes of actions that operators of DNS privacy services can take:
DNSプライバシーサービスのオペレータが取ることができる3つの行動の3つのクラスについて説明します。
* Threat mitigation for well-understood and documented privacy threats to the users of the service and, in some cases, the operators of the service.
* 脅威の軽減、よく理解されていて文書化されたプライバシーの脅威は、サービスのユーザーに対する、そして場合によっては、サービスの演算子があります。
* Optimization of privacy services from an operational or management perspective.
* 運用上または管理の観点からのプライバシーサービスの最適化
* Additional options that could further enhance the privacy and usability of the service.
* サービスのプライバシーと使いやすさをさらに強化することができる追加のオプション。
This document does not specify policy, only best practice. However, for DNS privacy services to be considered compliant with these best-practice guidelines, they SHOULD implement (where appropriate) all:
この文書はポリシーを指定しません。ベストプラクティスだけです。ただし、DNSプライバシーサービスに対応しているため、これらのベストプラクティスガイドラインに準拠していると見なされるためには、（必要に応じて）すべてを実装する必要があります。
* Threat mitigations to be minimally compliant.
* 脅威の軽減は最小限に準拠しています。
* Optimizations to be moderately compliant.
* 適度に準拠する最適化
* Additional options to be maximally compliant.
* 最大限に準拠するための追加のオプション。
The rest of this document does not use normative language but instead refers only to the three differing classes of action that correspond to the three named levels of compliance stated above. However, compliance (to the indicated level) remains a normative requirement.
この文書の残りの部分は規範的な言語を使用していませんが、代わりに上記の3つの名前付きレベルのコンプライアンスに対応する3つの異なる行動クラスのみを参照します。ただし、コンプライアンス（表示レベルへ）は規範的要件です。
In this section, we consider both data on the wire and the service provided to the client.
このセクションでは、ワイヤの両方のデータとクライアントに提供されているサービスを考慮します。
Threats described in [RFC6973]: Surveillance: Passive surveillance of traffic on the wire.
[RFC6973]で説明されている脅威：監視：ワイヤ上のトラフィックの受動監視。
DNS Privacy Threats: Active injection of spurious data or traffic.
DNSプライバシーの脅威：スプリアスデータまたはトラフィックのアクティブ注入。
Mitigations: A DNS privacy service can mitigate these threats by providing service over one or more of the following transports:
軽減：DNSプライバシーサービスは、次のトランスポートのうちの1つ以上を越えてサービスを提供することによってこれらの脅威を軽減できます。
* DNS over TLS (DoT) [RFC7858] [RFC8310].
* DNS over TLS（ドット）[RFC7858] [RFC8310]。
* DNS over HTTPS (DoH) [RFC8484].
* HTTPS（DOH）のDNS [RFC8484]。
It is noted that a DNS privacy service can also be provided over DNS over DTLS [RFC8094]; however, this is an Experimental specification, and there are no known implementations at the time of writing.
DNSプライバシーサービスはDNSを介してDTLSを介して提供され得ることが[RFC8094]であることに留意されたい。しかしながら、これは実験的な仕様であり、書き込み時に既知の実装はない。
It is also noted that DNS privacy service might be provided over DNSCrypt [DNSCrypt], IPsec, or VPNs. However, there are no specific RFCs that cover the use of these transports for DNS, and any discussion of best practice for providing such a service is out of scope for this document.
また、DNSCrypt [DNScrypt]、IPsec、またはVPNを介してDNSプライバシーサービスを提供することがあることも注意されています。しかし、DNSのためのこれらの輸送の使用をカバーする特定のRFCはありません。このようなサービスを提供するためのベストプラクティスの議論はこの文書の範囲外です。
Whilst encryption of DNS traffic can protect against active injection on the paths traversed by the encrypted connection, this does not diminish the need for DNSSEC; see Section 5.1.4.
DNSトラフィックの暗号化は、暗号化された接続によって横断されたパスでアクティブな注入から保護することができますが、これはDNSSECの必要性を減少させません。セクション5.1.4を参照してください。
Threats described in [RFC6973]: Surveillance: Active attacks on client resolver configuration.
[RFC6973]で説明されている脅威：監視：クライアントリゾルバ構成に対するアクティブな攻撃。
Mitigations: DNS privacy services should ensure clients can authenticate the server. Note that this, in effect, commits the DNS privacy service to a public identity users will trust.
軽減：DNSプライバシーサービスは、クライアントがサーバーを認証できるようにする必要があります。これにより、実際には、DNSプライバシーサービスをパブリックIDユーザーにコミットします。
When using DoT, clients that select a "Strict Privacy" usage profile [RFC8310] (to mitigate the threat of active attack on the client) require the ability to authenticate the DNS server. To enable this, DNS privacy services that offer DoT need to provide credentials that will be accepted by the client's trust model, in the form of either X.509 certificates [RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310].
ドットを使用する場合、「厳格なプライバシー」使用法プロファイル[RFC8310]を選択するクライアント（クライアント上のアクティブな攻撃の脅威を軽減するために）は、DNSサーバーを認証する機能が必要です。これを有効にするために、ドットを提供するDNSプライバシーサービスは、クライアントの信頼モデルによって受け入れられるクレデンシャルを提供する必要があります。[RFC5280]または[Subject Public Key Info]（SPKI）ピンセット[RFC8310]。
When offering DoH [RFC8484], HTTPS requires authentication of the server as part of the protocol.
DOH [RFC8484]を提供する場合、HTTPSはプロトコルの一部としてサーバーの認証を必要とします。
Anecdotal evidence to date highlights the management of certificates as one of the more challenging aspects for operators of traditional DNS resolvers that choose to additionally provide a DNS privacy service, as management of such credentials is new to those DNS operators.
今日までの逸話的証拠は、そのような資格情報の管理がそれらのDNS演算子にとって新しいことであるため、DNSプライバシーサービスを追加的に提供することを選択する従来のDNSリゾルバのオペレータのためのより困難な側面の1つとして証明書の管理を強調しています。
It is noted that SPKI pin set management is described in [RFC7858] but that key-pinning mechanisms in general have fallen out of favor operationally for various reasons, such as the logistical overhead of rolling keys.
SPKIピンセット管理は[RFC7858]に記載されているが、鍵ピン止めメカニズムは、ローリングキーの論理的オーバーヘッドなどの様々な理由で、概略ピン止めメカニズムが動作しており、概略的に推奨されていることに留意されたい。
DNS Privacy Threats: * Invalid certificates, resulting in an unavailable service, which might force a user to fall back to cleartext.
DNSプライバシーの脅威：*証明書が無効な場合は使用不可のサービスが発生し、ユーザーがクリアテキストに戻ることができます。
* Misidentification of a server by a client -- e.g., typos in DoH URL templates [RFC8484] or authentication domain names [RFC8310] that accidentally direct clients to attacker-controlled servers.
* クライアントによるサーバの誤認 - 例えば、DOH URLテンプレートのTypos [RFC8484]または認証ドメイン名[RFC8310]誤ってクライアントを攻撃的に制御されたサーバに直接転送する。
Mitigations: It is recommended that operators:
軽減：オペレータには推奨されます。
* Follow the guidance in Section 6.5 of [RFC7525] with regard to certificate revocation.
* 証明書の失効に関して[RFC7525]の第6.5項のガイダンスに従ってください。
* Automate the generation, publication, and renewal of certificates. For example, Automatic Certificate Management Environment (ACME) [RFC8555] provides a mechanism to actively manage certificates through automation and has been implemented by a number of certificate authorities.
* 証明書の世代、出版物、および更新を自動化する。たとえば、自動証明書管理環境（ACME）[RFC8555]は、自動化を通じて証明書を積極的に管理するためのメカニズムを提供し、多くの認証局によって実装されています。
* Monitor certificates to prevent accidental expiration of certificates.
* 証明書の偶発的な有効期限を防ぐために証明書を監視します。
* Choose a short, memorable authentication domain name for the service.
* サービスの短い、記憶に残る認証ドメイン名を選択してください。
DNS Privacy Threats: * Known attacks on TLS, such as those described in [RFC7457].
DNSプライバシーの脅威：* [RFC7457]に記載されているものなど、TLSの既知の攻撃。
* Traffic analysis, for example: [Pitfalls-of-DNS-Encryption] (focused on DoT).
* トラフィック分析、例えば：[Pitfalls-of-DNS暗号化]（ドットに焦点を当てています）。
* Potential for client tracking via transport identifiers.
* トランスポート識別子によるクライアント追跡の可能性
* Blocking of well-known ports (e.g., 853 for DoT).
* よく知られているポートのブロッキング（例えば、ドットのための853）。
Mitigations: In the case of DoT, TLS profiles from Section 9 of [RFC8310] and the "Countermeasures to DNS Traffic Analysis" from Section 11.1 of [RFC8310] provide strong mitigations. This includes but is not limited to:
軽減：ドットの場合、[RFC8310]のセクション9からのTLSプロファイルと[RFC8310]のセクション11.1からの「DNSトラフィック分析への対策」が強い軽減を提供します。これには含まれていますが、これらに限定されません。
* Adhering to [RFC7525].
* [RFC7525]に付着しています。
* Implementing only (D)TLS 1.2 or later, as specified in [RFC8310].
* [RFC8310]で指定されているように、（D）TLS 1.2以降のみを実装します。
* Implementing Extension Mechanisms for DNS (EDNS(0)) Padding [RFC7830] using the guidelines in [RFC8467] or a successor specification.
* DNSの拡張メカニズム（EDNS（0））パディングの実装[RFC7830] [RFC8467]のガイドラインまたは後継仕様。
* Servers should not degrade in any way the query service level provided to clients that do not use any form of session resumption mechanism, such as TLS session resumption [RFC5077] with TLS 1.2 (Section 2.2 of [RFC8446]) or Domain Name System (DNS) Cookies [RFC7873].
* TLSセッションの再開[RFC5077]（[RFC8446]のセクション2.2）またはドメインネームシステム（DNS）など、任意の形式のセッション再開メカニズムを使用しないクライアントに提供されるクエリサービスレベルでは、サーバーは劣化しないでください。）クッキー[RFC7873]。
* A DoT privacy service on both port 853 and 443. If the operator deploys DoH on the same IP address, this requires the use of the "dot" Application-Layer Protocol Negotiation (ALPN) value [dot-ALPN].
* ポート853と443の両方でのドットプライバシーサービス。オペレータが同じIPアドレスにDOHを展開する場合、これには「ドット」アプリケーション層プロトコルネゴシエーション（ALPN）値[DOT-ALPN]を使用する必要があります。
Optimizations: * Concurrent processing of pipelined queries, returning responses as soon as available, potentially out of order, as specified in [RFC7766]. This is often called "OOOR" -- out-of-order responses (providing processing performance similar to HTTP multiplexing).
最適化：* Pipeliedクエリの並行処理、[RFC7766]で指定されているように、利用可能な場合は潜在的に順番に回答を返します。これはしばしば「OOUR」と呼ばれます（HTTP多重化に似た処理性能を提供します）。
* Management of TLS connections to optimize performance for clients using [RFC7766] and EDNS(0) Keepalive [RFC7828]
* [RFC7766]とEDNS（0）KeepAliveを使用してクライアントのパフォーマンスを最適化するためのTLS接続の管理[RFC7828]
Additional Options: Management of TLS connections to optimize performance for clients using DNS Stateful Operations [RFC8490].
追加のオプション：DNSステートフルオペレーションを使用しているクライアントのパフォーマンスを最適化するためのTLS接続の管理[RFC8490]。
DNS Privacy Threats: * Known attacks on TLS, such as those described in [RFC7457].
DNSプライバシーの脅威：* [RFC7457]に記載されているものなど、TLSの既知の攻撃。
* Traffic analysis, for example: [DNS-Privacy-not-so-private] (focused on DoH).
* トラフィック分析、例えば：[DNS-Privacy-Not-Private]（DOHに焦点を当てた）。
* Potential for client tracking via transport identifiers.
* トランスポート識別子によるクライアント追跡の可能性
Mitigations: * Clients must be able to forgo the use of HTTP cookies [RFC6265] and still use the service.
軽減：*クライアントはHTTP Cookie [RFC6265]の使用を申請でき、まだサービスを使用できる必要があります。
* Use of HTTP/2 padding and/or EDNS(0) padding, as described in Section 9 of [RFC8484].
* [RFC8484]のセクション9のセクション9で説明されているように、HTTP / 2パディングおよび/またはEDNS（0）パディングの使用。
* Clients should not be required to include any headers beyond the absolute minimum to obtain service from a DoH server. (See Section 6.1 of [BUILD-W-HTTP].)
* DOHサーバーからのサービスを受けるために、クライアントは絶対最小値を超えてヘッダーを含める必要はありません。（[Build-W-HTTPのセクション6.1]を参照してください。）
DNS Privacy Threats: Users may be directed to bogus IP addresses that, depending on the application, protocol, and authentication method, might lead users to reveal personal information to attackers. One example is a website that doesn't use TLS or whose TLS authentication can somehow be subverted.
DNSプライバシーの脅威：ユーザーは、アプリケーション、プロトコル、および認証方法によっては、ユーザーが個人情報を攻撃者に明らかにするように導く可能性があるBogus IPアドレスに向けられます。一例は、TLSを使用しない、またはそのTLS認証がどういうわけか元に戻すことができるWebサイトです。
Mitigations: All DNS privacy services must offer a DNS privacy service that performs Domain Name System Security Extensions (DNSSEC) validation. In addition, they must be able to provide the DNSSEC Resource Records (RRs) to the client so that it can perform its own validation.
緩和：すべてのDNSプライバシーサービスは、ドメイン名システムセキュリティ拡張（DNSSEC）検証を実行するDNSプライバシーサービスを提供する必要があります。さらに、それらはそれ自身の検証を実行できるように、クライアントにDNSSECリソースレコード（RRS）を提供できる必要があります。
The addition of encryption to DNS does not remove the need for DNSSEC [RFC4033]; they are independent and fully compatible protocols, each solving different problems. The use of one does not diminish the need nor the usefulness of the other.
DNSへの暗号化の追加はDNSSEC [RFC4033]の必要性を削除しません。それらは独立した完全なプロトコルであり、それぞれが異なる問題を解決する。1つの使用は、必要性も他方の有用性も低下しない。
While the use of an authenticated and encrypted transport protects origin authentication and data integrity between a client and a DNS privacy service, it provides no proof (for a nonvalidating client) that the data provided by the DNS privacy service was actually DNSSEC authenticated. As with cleartext DNS, the user is still solely trusting the Authentic Data (AD) bit (if present) set by the resolver.
認証された暗号化されたトランスポートの使用は、クライアントとDNSプライバシーサービスの間の原点認証とデータの整合性を保護しますが、DNSプライバシーサービスによって提供されたデータが実際にDNSSEC認証されていたことを証明しない（非検証クライアントの場合）。ClearText DNSと同様に、ユーザーは、レゾルバによって設定された本物のデータ（AD）ビット（存在する場合）を単独で信頼しています。
It should also be noted that the use of an encrypted transport for DNS actually solves many of the practical issues encountered by DNS validating clients -- e.g., interference by middleboxes with cleartext DNS payloads is completely avoided. In this sense, a validating client that uses a DNS privacy service that supports DNSSEC has a far simpler task in terms of DNSSEC roadblock avoidance [RFC8027].
また、DNSの暗号化されたトランスポートの使用は実際にはDNS検証クライアント（例えば、ClearText DNSペイロードでのミドルボックスによる干渉）が完全に回避されることにも注意してください。この意味で、DNSSECをサポートするDNSプライバシーサービスを使用する検証クライアントは、DNSSEC RoadBlock Roverance [RFC8027]という点ではるかに簡単なタスクを持ちます。
DNS Privacy Threats: A failing DNS privacy service could force the user to switch providers, fall back to cleartext, or accept no DNS service for the duration of the outage.
DNSプライバシーの脅威：失敗したDNSプライバシーサービスは、ユーザーがプロバイダを切り替え、クリアテキストに立ち返ったり、停止期間のためにDNSサービスを受け入れたりすることを強制することができます。
Mitigations: A DNS privacy service should strive to engineer encrypted services to the same availability level as any unencrypted services they provide. Particular care should to be taken to protect DNS privacy services against denial-of-service (DoS) attacks, as experience has shown that unavailability of DNS resolving because of attacks is a significant motivation for users to switch services. See, for example, Section IV-C of [Passive-Observations-of-a-Large-DNS].
軽減：DNSプライバシーサービスは、エンジニアされていないサービスが提供されていないサービスと同じ可用性レベルにエンジニアリングされたサービスに努めます。経験が攻撃のためにDNSの使用不可能性がサービスを切り替えることが重要な動機であることを経験したので、サービス拒否（DOS）攻撃に対してDNSプライバシーサービスを保護するために特定の注意を払うべきである。例えば、[Passive-Obsevations-of-A-Large-DNS]のIV-Cのセクションを参照のこと。
Techniques such as those described in Section 10 of [RFC7766] can be of use to operators to defend against such attacks.
[RFC7766]の第10章に記載されているものなどの技術は、そのような攻撃に対して守るために演算子に使用することができます。
DNS Privacy Threats: Unfairly disadvantaging users of the privacy service with respect to the services available. This could force the user to switch providers, fall back to cleartext, or accept no DNS service for the duration of the outage.
DNSプライバシーの脅威：利用可能なサービスに関してプライバシーサービスのユーザーが不当に短い。これにより、ユーザーがプロバイダを切り替え、クリアテキストに戻るか、停止期間中にDNSサービスを受け入れないように強制することができます。
Mitigations: A DNS privacy service should deliver the same level of service as offered on unencrypted channels in terms of options such as filtering (or lack thereof), DNSSEC validation, etc.
緩和：DNSプライバシーサービスは、フィルタリング（またはその不足）、DNSSEC検証などのオプションの点で、暗号化されていないチャネル上で提供されるのと同じレベルのサービスを提供する必要があります。
5.1.7. Impact of Encryption on Monitoring by DNS Privacy Service Operators
5.1.7. DNSプライバシーサービス事業者による監視に対する暗号化の影響
DNS Privacy Threats: Increased use of encryption can impact a DNS privacy service operator's ability to monitor traffic and therefore manage their DNS servers [RFC8404].
DNSプライバシーの脅威：暗号化の使用の増加により、DNSプライバシーサービス事業者がトラフィックを監視する機能を監視する機能に影響を与えるため、DNSサーバー[RFC8404]を管理できます。
Many monitoring solutions for DNS traffic rely on the plaintext nature of this traffic and work by intercepting traffic on the wire, either using a separate view on the connection between clients and the resolver, or as a separate process on the resolver system that inspects network traffic. Such solutions will no longer function when traffic between clients and resolvers is encrypted. Many DNS privacy service operators still need to inspect DNS traffic -- e.g., to monitor for network security threats. Operators may therefore need to invest in an alternative means of monitoring that relies on either the resolver software directly, or exporting DNS traffic from the resolver using, for example, [dnstap].
DNSトラフィックのための多くの監視ソリューションは、このトラフィックの平文の性質に依存しており、クライアントとリゾルバ間の接続に関する別のビューを使用するか、ネットワークトラフィックを検査するリゾルバシステムの別のプロセスとして、ワイヤ上のトラフィックを傍受することによって機能します。。そのような解決策は、クライアントとリゾルバの間のトラフィックが暗号化されているときに機能しなくなります。多くのDNSプライバシーサービス事業者は、ネットワークセキュリティの脅威を監視するためのDNSトラフィックを検査する必要があります。したがって、オペレータは、リゾルバソフトウェアのいずれかに直接依存する代替手段、または例えば[DNSTAP]を使用してリゾルバからDNSトラフィックをエクスポートするための代替手段に投資する必要があるかもしれません。
Optimization: When implementing alternative means for traffic monitoring, operators of a DNS privacy service should consider using privacy-conscious means to do so. See Section 5.2 for more details on data handling and the discussion on the use of Bloom Filters in Appendix B.
最適化：トラフィック監視のための代替手段を実装するとき、DNSプライバシーサービスのオペレータは、プライバシーを意識した手段を使用することを考慮する必要があります。付録BのBloomフィルタの使用に関する説明と説明の詳細については、セクション5.2を参照してください。
5.1.8. Limitations of Fronting a DNS Privacy Service with a Pure TLS Proxy
5.1.8. 純粋なTLSプロキシを使用したDNSプライバシーサービスを偽装することの制限
DNS Privacy Threats: * Limited ability to manage or monitor incoming connections using DNS-specific techniques.
DNSプライバシーの脅威：* DNS固有のテクニックを使用して着信接続を管理または監視する機能。
* Misconfiguration (e.g., of the target-server address in the proxy configuration) could lead to data leakage if the proxy-to-target-server path is not encrypted.
* 対象と対象となるサーバパスが暗号化されていない場合、データリークが発生する可能性がある。
Optimization: Some operators may choose to implement DoT using a TLS proxy (e.g., [nginx], [haproxy], or [stunnel]) in front of a DNS nameserver because of proven robustness and capacity when handling large numbers of client connections, load-balancing capabilities, and good tooling. Currently, however, because such proxies typically have no specific handling of DNS as a protocol over TLS or DTLS, using them can restrict traffic management at the proxy layer and the DNS server. For example, all traffic received by a nameserver behind such a proxy will appear to originate from the proxy, and DNS techniques such as Access Control Lists (ACLs), Response Rate Limiting (RRL), or DNS64 [RFC6147] will be hard or impossible to implement in the nameserver.
最適化：オペレータの中には、多数のクライアント接続を処理する際の、DNSネームサーバーの前のTLSプロキシ（[Nginx]、[Haproxy]、または[Stunnel]）を使用してドットを実装することを選択できます。バランス機能、そして良いツールただし、現在、そのようなプロキシは通常TLSまたはDTLSを介したプロトコルとしてDNSの特定の処理がないため、それらを使用すると、プロキシレイヤとDNSサーバーでトラフィック管理を制限できます。たとえば、そのようなプロキシの背後にあるネームサーバーによって受信されたすべてのトラフィックはプロキシから発信され、アクセス制御リスト（ACL）、応答率制限（RRL）、またはDNS64 [RFC6147]などのDNSテクニックが難しく、不可能になることがわかります。ネームサーバーに実装するには。
Operators may choose to use a DNS-aware proxy, such as [dnsdist], that offers custom options (similar to those proposed in [DNS-XPF]) to add source information to packets to address this shortcoming. It should be noted that such options potentially significantly increase the leaked information in the event of a misconfiguration.
オペレータは、この欠点に対処するためのパケットにソース情報を追加するためのカスタムオプション（[DNS-XPF]で提案されているものと同様）を提供する[DNSDist]などのDNS対応のプロキシを使用することを選択できます。このような選択肢は、誤構成の場合に漏洩した情報を潜在的に増大させることに留意されたい。
Threats described in [RFC6973]: * Surveillance.
[RFC6973]に記載されている脅威：*監視。
* Stored-data compromise.
* ストアドデータの妥協
* Correlation.
* 相関。
* Identification.
* 識別。
* Secondary use.
* 二次使用
* Disclosure.
* 開示。
Other Threats * Contravention of legal requirements not to process user data.
その他の脅威*ユーザーデータを処理しない法的要件の違反。
Mitigations: The following are recommendations relating to common activities for DNS service operators; in all cases, data retention should be minimized or completely avoided if possible for DNS privacy services. If data is retained, it should be encrypted and either aggregated, pseudonymized, or anonymized whenever possible. In general, the principle of data minimization described in [RFC6973] should be applied.
軽減：DNSサービス事業者のための一般的な活動に関する推奨事項。すべての場合において、データ保持は、可能であれば、DNSプライバシーサービスの場合は完全に回避されるべきです。データが保持されている場合は、可能な限り、暗号化され、疑似値、または匿名化されている必要があります。一般に、[RFC6973]に記載されているデータ最小化の原理を適用する必要があります。
* Transient data (e.g., data used for real-time monitoring and threat analysis, which might be held only in memory) should be retained for the shortest possible period deemed operationally feasible.
* 過渡的なデータ（例えば、メモリ内でのみ保持されている可能性があるリアルタイムの監視および脅威分析に使用されるデータ）は、運用的に実行可能であると見なされる最短の期間のために保持されるべきです。
* The retention period of DNS traffic logs should be only as long as is required to sustain operation of the service and meet regulatory requirements, to the extent that they exist.
* DNSトラフィックログの保存期間は、サービスの操作を維持し、規制要件を満たすために必要な限り、存在する範囲である限りであるべきです。
* DNS privacy services should not track users except for the particular purpose of detecting and remedying technically malicious (e.g., DoS) or anomalous use of the service.
* DNS Privacy Servicesは、技術的に悪意のある（例えば、DOS）またはサービスの異常な使用を検出および修復することの特定の目的を除いて、ユーザーを追跡しないでください。
* Data access should be minimized to only those personnel who require access to perform operational duties. It should also be limited to anonymized or pseudonymized data where operationally feasible, with access to full logs (if any are held) only permitted when necessary.
* データアクセスは、運用職務を実行するためのアクセスを必要とする人員だけに最小化されるべきです。それはまた、完全なログへのアクセス（いずれかが保持されている場合）にアクセスできるように、必要に応じて許可されています。
Optimizations: * Consider use of full-disk encryption for logs and data-capture storage.
最適化：*ログとデータキャプチャストレージのフルディスク暗号化の使用を検討してください。
Data minimization refers to collecting, using, disclosing, and storing the minimal data necessary to perform a task, and this can be achieved by removing or obfuscating privacy-sensitive information in network traffic logs. This is typically personal data or data that can be used to link a record to an individual, but it may also include other confidential information -- for example, on the structure of an internal corporate network.
データ最小化とは、タスクを実行するのに必要な最小データを収集、使用、開示、および格納することを指し、これはネットワークトラフィックログ内のプライバシーに敏感な情報を削除または妨げることによって達成することができる。これは通常個人データまたはレコードを個人にリンクするために使用できるデータであるが、それはまた、内部企業ネットワークの構造上の他の機密情報を含むことができる。
The problem of effectively ensuring that DNS traffic logs contain no or minimal privacy-sensitive information is not one that currently has a generally agreed solution or any standards to inform this discussion. This section presents an overview of current techniques to simply provide reference on the current status of this work.
DNSトラフィックログがNOまたは最小限のプライバシーに敏感な情報が含まれていることを効果的に確実にするという問題は、現在合意されたソリューションまたはこの議論を知らせるための標準を持っているものではありません。このセクションでは、この作業の現在のステータスに関する参照を簡単に提供するための現在の技術の概要を示します。
Research into data minimization techniques (and particularly IP address pseudonymization/anonymization) was sparked in the late 1990s / early 2000s, partly driven by the desire to share significant corpuses of traffic captures for research purposes. Several techniques reflecting different requirements in this area and different performance/resource trade-offs emerged over the course of the decade. Developments over the last decade have been both a blessing and a curse; the large increase in size between an IPv4 and an IPv6 address, for example, renders some techniques impractical, but also makes available a much larger amount of input entropy, the better to resist brute-force re-identification attacks that have grown in practicality over the period.
データの最小化技術（そして特にIPアドレスの仮名/匿名化）の研究は、1990年代後半から2000年代後半に発症し、部分的には研究目的のためのトラフィックキャプチャの重要なコーパスを共有したいという願望によって主導されました。この分野におけるさまざまな要件を反映したいくつかの技術と、さまざまなパフォーマンス/リソースのトレードオフが10年間にわたって現れました。最後の10年間の発展は祝福と呪いの両方でした。たとえば、IPv4とIPv6アドレスとの間のサイズが大きいほど、いくつかの技術が実用的ではないが、実用的に成長したブルートフォースの再識別攻撃に抵抗するのに適したものになるほうがよい。期間。
Techniques employed may be broadly categorized as either anonymization or pseudonymization. The following discussion uses the definitions from [RFC6973], Section 3, with additional observations from [van-Dijkhuizen-et-al].
採用されている技術は、匿名化または疑似法として広く分類され得る。次の説明では、[RFC6973]、セクション3からの定義を使用しています[van-dijkhuizen-et-al]からの追加の観察があります。
* Anonymization. To enable anonymity of an individual, there must exist a set of individuals that appear to have the same attribute(s) as the individual. To the attacker or the observer, these individuals must appear indistinguishable from each other.
* 匿名化個人の匿名性を有効にするには、個人として同じ属性を持つように見える一連の個人が存在している必要があります。攻撃者またはオブザーバーに、これらの個人は互いに区別がつかないように見えなければなりません。
* Pseudonymization. The true identity is deterministically replaced with an alternate identity (a pseudonym). When the pseudonymization schema is known, the process can be reversed, so the original identity becomes known again.
* 疑似法真のアイデンティティは、別のアイデンティティ（仮想文字）に決定されています。擬間化スキーマが知られている場合、プロセスを逆にすることができるので、元の識別情報は再び知られるようになる。
In practice, there is a fine line between the two; for example, it is difficult to categorize a deterministic algorithm for data minimization of IP addresses that produces a group of pseudonyms for a single given address.
実際には、2つの間には細い線があります。例えば、単一の所与のアドレスに対する擬似文字列を生成するIPアドレスのデータ最小化のための決定論的アルゴリズムを分類することは困難である。
A major privacy risk in DNS is connecting DNS queries to an individual, and the major vector for this in DNS traffic is the client IP address.
DNSの大きなプライバシーリスクはDNSクエリを個人に接続し、DNSトラフィックではメジャーベクトルがクライアントのIPアドレスです。
There is active discussion in the space of effective pseudonymization of IP addresses in DNS traffic logs; however, there seems to be no single solution that is widely recognized as suitable for all or most use cases. There are also as yet no standards for this that are unencumbered by patents.
DNSトラフィックログのIPアドレスの効果的な仮定のスペースでは、アクティブなディスカッションがあります。しかしながら、すべての使用症例に適していると広く認識されている単一の解決策はないようです。特許によって妨げられていないこれに関する標準はまだありません。
Appendix B provides a more detailed survey of various techniques employed or under development in 2020.
付録Bは、2020年に採用されているか、または開発中のさまざまな技術のより詳細な調査を提供します。
5.2.4. Pseudonymization, Anonymization, or Discarding of Other Correlation Data
5.2.4. 疑似法、匿名化、または他の相関データの破棄
DNS Privacy Threats: * Fingerprinting of the client OS via various means, including: IP TTL/Hoplimit, TCP parameters (e.g., window size, Explicit Congestion Notification (ECN) support, selective acknowledgment (SACK)), OS-specific DNS query patterns (e.g., for network connectivity, captive portal detection, or OS-specific updates).
DNSプライバシーの脅威：*さまざまな手段を介したクライアントOSの指紋：IP TTL / HopLimit、TCPパラメータ（ウィンドウサイズ、明示的輻輳通知（ECN）サポート、選択確認（SACK））、OS固有のDNSクエリパターン（例えば、ネットワーク接続、非公開ポータル検出、OS固有のアップデートの場合）。
* Fingerprinting of the client application or TLS library by, for example, HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS version/Cipher-suite combinations, or other connection parameters.
* たとえば、HTTPヘッダー（例えば、ユーザーエージェント、accept、accept-encoding）、TLSバージョン/暗号スイートの組み合わせ、または他の接続パラメータなど、クライアントアプリケーションまたはTLSライブラリのフィンガープリント。
* Correlation of queries on multiple TCP sessions originating from the same IP address.
* 同じIPアドレスから発生する複数のTCPセッションに対するクエリの相関。
* Correlating of queries on multiple TLS sessions originating from the same client, including via session-resumption mechanisms.
* セッション再開メカニズムを含む、同じクライアントから発生した複数のTLSセッションに対するクエリの相関
* Resolvers _might_ receive client identifiers -- e.g., Media Access Control (MAC) addresses in EDNS(0) options. Some customer premises equipment (CPE) devices are known to add them [MAC-address-EDNS].
* resolvers _might_ receiveクライアント識別子 - EDNS（0）オプションのメディアアクセス制御（MAC）アドレス。いくつかの顧客宅内機器（CPE）装置はそれらを追加することが知られています[MAC-address-edns]。
Mitigations: * Data minimization or discarding of such correlation data.
軽減：*データの最小化またはその相関データの破棄。
Threats described in [RFC6973]: Surveillance: Profiling of client queries by malicious third parties.
[RFC6973]で説明されている脅威：監視：悪意のある第三者によるクライアントクエリのプロファイリング。
Mitigations: See [ISC-Knowledge-database-on-cache-snooping] for an example discussion on defending against cache snooping. Options proposed include limiting access to a server and limiting nonrecursive queries.
軽減：キャッシュスヌーピングに対する防御についての議論のための[ISC-Knowledge-Database-On-Cache-Snooping]を参照してください。提案された選択肢は、サーバへのアクセスを制限し、そして非較正のクエリを制限することを含む。
In this section, we consider both data sent on the wire in upstream queries and data shared with third parties.
このセクションでは、上流のクエリと第三者と共有されているデータの両方のデータの両方を検討します。
Threats described in [RFC6973]: Surveillance: Transmission of identifying data upstream.
[RFC6973]で説明されている脅威：監視：データの識別データの上流の送信。
Mitigations: The server should:
軽減：サーバーは次のようにします。
* implement QNAME minimization [RFC7816].
* QNAME最小化を実装します[RFC7816]。
* honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the EDNS(0) Client Subnet (ECS) option ([RFC7871], Section 7.1.2). This is as specified in [RFC8310] for DoT but applicable to any DNS privacy service.
* EDNS（0）クライアントサブネット（ECS）オプション（[RFC7871]、7.1.2）を含むクエリに0に設定されたソースプレフィックスの長さを尊重します。これはドットの場合は[RFC8310]で指定されていますが、DNSプライバシーサービスに適用されます。
Optimizations: As per Section 2 of [RFC7871], the server should either:
最適化：[RFC7871]のセクション2に従って、サーバーは次のいずれかを示します。
* not use the ECS option in upstream queries at all, or
* UpstreamクエリのECSオプションをまったく使用しないでください。
* offer alternative services, one that sends ECS and one that does not.
* 代替サービスを提供し、ECSを送信するものとそうでないものを送るもの。
If operators do offer a service that sends the ECS options upstream, they should use the shortest prefix that is operationally feasible and ideally use a policy of allowlisting upstream servers to which to send ECS in order to reduce data leakage. Operators should make clear in any policy statement what prefix length they actually send and the specific policy used.
演算子がECSオプションを上流に送信するサービスを提供している場合、それらは、操作的に実行可能で、データ漏洩を減らすためにECSを送信するためのアップストリームサーバーを許可するポリシーを理想的に使用する最短プレフィックスを使用する必要があります。演算子は、どのプレフィックス名でも、実際に送信されたものと特定のポリシーをどのプレフィックス名で明確にする必要があります。
Allowlisting has the benefit that not only does the operator know which upstream servers can use ECS, but also the operator can decide which upstream servers apply privacy policies that the operator is happy with. However, some operators consider allowlisting to incur significant operational overhead compared to dynamic detection of ECS support on authoritative servers.
AllowListingには、どのアップストリームサーバーがECSを使用できるかを知っているだけでなく、どのアップストリームサーバーがオペレータが満足しているプライバシーポリシーを適用するかを決定できます。ただし、何人かのオペレータは、信頼できるサーバー上のECSサポートの動的検出と比較して、重要な操作上のオーバーヘッドを発生させることを可能にします。
Additional options:
追加オプション：
* "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] and "NXDOMAIN: There Really Is Nothing Underneath" [RFC8020] to reduce the number of queries to authoritative servers to increase privacy.
* 「DNSSEC検証済みキャッシュの積極的な使用」[RFC8198]および「NXDOMAIN：は、この下にありません」[RFC8020]は、プライバシーを増やすための権限のあるサーバーへのクエリの数を減らすことです。
* Run a local copy of the root zone [RFC8806] to avoid making queries to the root servers that might leak information.
* 情報をリークする可能性があるルートサーバーへのクエリを作成しないように、ルートゾーン[RFC8806]のローカルコピーを実行します。
Additional options:
追加オプション：
Since queries from recursive resolvers to authoritative servers are performed using cleartext (at the time of writing), resolver services need to consider the extent to which they may be directly leaking information about their client community via these upstream queries and what they can do to mitigate this further. Note that, even when all the relevant techniques described above are employed, there may still be attacks possible -- e.g., [Pitfalls-of-DNS-Encryption]. For example, a resolver with a very small community of users risks exposing data in this way and ought to obfuscate this traffic by mixing it with "generated" traffic to make client characterization harder. The resolver could also employ aggressive prefetch techniques as a further measure to counter traffic analysis.
再帰的なリゾルバから権威あるサーバーへのクエリは（執筆時点で）ClearTextを使用して実行されるため、リゾルバサービスは、これらのアップストリームクエリを介してクライアントコミュニティに関する情報を直接漏らす可能性がある程度を考慮する必要があります。これ以上上述した全ての関連技術が採用されている場合でも、依然として攻撃が可能である。例えば、[Pitfalls-of-DNS暗号化]。たとえば、ユーザーの非常に小さなコミュニティコミュニティを持つレゾルバはこのようにしてデータを公開し、そのトラフィックを「生成された」トラフィックと混在させてクライアントのキャラクタリゼーションを難しくすることでこのトラフィックを難読化する必要があります。レゾルバは、トラフィック分析をカウンタするためのさらなる尺度として積極的なプリフェッチ技術を使用することもできます。
At the time of writing, there are no standardized or widely recognized techniques to perform such obfuscation or bulk prefetches.
書き込み時には、そのような難読化またはバルクプリフェッチを実行するための標準化されたまたは広く認識されていない技法はありません。
Another technique that particularly small operators may consider is forwarding local traffic to a larger resolver (with a privacy policy that aligns with their own practices) over an encrypted protocol, so that the upstream queries are obfuscated among those of the large resolver.
特に小規模なオペレータが、暗号化されたプロトコルを介して（独自の慣行と整列させるプライバシーポリシーを有する）ローカルトラフィックをより大きなリゾルバに転送することであることを考慮することができる。
Threats described in [RFC6973]: * Surveillance.
[RFC6973]に記載されている脅威：*監視。
* Stored-data compromise.
* ストアドデータの妥協
* Correlation.
* 相関。
* Identification.
* 識別。
* Secondary use.
* 二次使用
* Disclosure.
* 開示。
DNS Privacy Threats: Contravention of legal requirements not to process user data.
DNSプライバシーの脅威：ユーザーデータを処理しない法的要件の違反。
Mitigations: Operators should not share identifiable data with third parties.
軽減：演算子は、識別可能なデータを第三者と共有しないでください。
If operators choose to share identifiable data with third parties in specific circumstances, they should publish the terms under which data is shared.
演算子が特定の状況で第三者と識別可能なデータを共有することを選択した場合は、データが共有されている用語を公開する必要があります。
Operators should consider including specific guidelines for the collection of aggregated and/or anonymized data for research purposes, within or outside of their own organization. This can benefit not only the operator (through inclusion in novel research) but also the wider Internet community. See the policy published by SURFnet [SURFnet-policy] on data sharing for research as an example.
オペレータは、研究目的のための集約データおよび/または匿名化されたデータの収集に関する特定のガイドラインを含むことを検討してください。これは、（新しい研究に含めることによって）オペレータだけでなく、より広いインターネットコミュニティも役立ちます。例としての研究のためのデータ共有に関するSurfnet [SurfNet-Policy]によって発行されたポリシーを参照してください。
To be compliant with this Best Current Practice document, a DNS recursive operator SHOULD publish a Recursive operator Privacy Statement (RPS). Adopting the outline, and including the headings in the order provided, is a benefit to persons comparing RPSs from multiple operators.
この最善の現在の練習文書に準拠するために、DNS再帰演算子は再帰的なオペレータのプライバシーステートメント（RPS）を公開する必要があります。概要を採用し、提供されている順序の見出しを含めることは、複数の演算子からのRPSを比較する人の利益です。
Appendix C provides a comparison of some existing policy and privacy statements.
付録Cは、いくつかの既存のポリシーとプライバシーステートメントの比較を提供します。
The contents of Sections 6.1.1 and 6.1.2 are non-normative, other than the order of the headings. Material under each topic is present to assist the operator developing their own RPS. This material:
セクション6.1.1および6.1.2の内容は、見出しの順序以外に規範されていません。各トピックの下の材料は、オペレータが独自のRPを開発するのを助けるために存在します。この資料：
* Relates _only_ to matters around the technical operation of DNS privacy services, and no other matters.
* DNSプライバシーサービスの技術的な操作に関する事項には、_only_ということが関連付けられており、他の事項はありません。
* Does not attempt to offer an exhaustive list for the contents of an RPS.
* RPSの内容のための徹底的なリストを提供しようとしないでください。
* Is not intended to form the basis of any legal/compliance documentation.
* 法的/コンプライアンスの文書化の基礎を形成することを意図していません。
Appendix D provides an example (also non-normative) of an RPS statement for a specific operator scenario.
付録Dは、特定のオペレータシナリオのRPSステートメントの例（非規範）を提供します。
1. Treatment of IP addresses. Make an explicit statement that IP addresses are treated as personal data.
1. IPアドレスの扱いIPアドレスが個人データとして扱われることを明示的な声明を作成します。
2. Data collection and sharing. Specify clearly what data (including IP addresses) is:
2. データ収集と共有（IPアドレスを含む）データ（IPアドレスを含む）のものを明確に指定します。
* Collected and retained by the operator, and for what period it is retained.
* オペレータが収集して保持され、どの期間が保持されています。
* Shared with partners.
* パートナーと共有しました。
* Shared, sold, or rented to third parties.
* 共有、販売、または第三者に賃貸する。
In each case, specify whether data is aggregated, pseudonymized, or anonymized and the conditions of data transfer. Where possible provide details of the techniques used for the above data minimizations.
いずれの場合も、データが集約されているか、疑似法、または匿名化されたデータ転送の条件を指定します。可能であれば、上記のデータ最小化に使用される技法の詳細を提供する。
3. Exceptions. Specify any exceptions to the above -- for example, technically malicious or anomalous behavior.
3. 例外上記の例外を指定してください - たとえば、技術的に悪意のある、または異常な行動などです。
4. Associated entities. Declare and explicitly enumerate any partners, third-party affiliations, or sources of funding.
4. 関連エンティティ。パートナー、サードパーティの会社、または資金源を宣言して明示的に列挙する。
5. Correlation. Whether user DNS data is correlated or combined with any other personal information held by the operator.
5. 相関。ユーザーDNSデータが、オペレータが保持している他の個人情報と相関または組み合わされているかどうか。
6. Result filtering. This section should explain whether the operator filters, edits, or alters in any way the replies that it receives from the authoritative servers for each DNS zone before forwarding them to the clients. For each category listed below, the operator should also specify how the filtering lists are created and managed, whether it employs any third-party sources for such lists, and which ones.
6. 結果フィルタリングこのセクションでは、オペレータが顧客に転送する前に、各DNSゾーンに対して信頼できるサーバから受信した返信が任意の方法でフィルタリング、編集、または変更するかどうかを説明する必要があります。以下にリストされている各カテゴリについて、オペレータは、そのようなリストのサードパーティのソースを使用しているかどうかを、フィルタリングリストの作成と管理方法も指定する必要があります。
* Specify if any replies are being filtered out or altered for network- and computer-security reasons (e.g., preventing connections to malware-spreading websites or botnet control servers).
* ネットワークおよびコンピュータセキュリティ上の理由から、応答がフィルタアウトされているか変更されているか、コンピュータセキュリティの理由（WebサイトまたはBotNet制御サーバーへの接続の防止）を指定します。
* Specify if any replies are being filtered out or altered for mandatory legal reasons, due to applicable legislation or binding orders by courts and other public authorities.
* 裁判所やその他の公的機関による適用される法律または拘束力のある法律または拘束力のある法的な法的理由で、返信が除外されているか、法的な法的な理由から変更されているかどうかを指定します。
* Specify if any replies are being filtered out or altered for voluntary legal reasons, due to an internal policy by the operator aiming at reducing potential legal risks.
* 潜在的な法的リスクの低減を目的としたオペレータによる内部政策により、任意の法的な理由から、返信がフィルタリングされているか、または任意の法的な理由から変更されているかどうかを指定します。
* Specify if any replies are being filtered out or altered for any other reason, including commercial ones.
* コマーシャルのものを含む他の理由で、返信がフィルタアウトされているか変更されているかどうかを指定します。
Communicate the current operational practices of the service.
サービスの現在の運用慣行を伝えます。
1. Deviations. Specify any temporary or permanent deviations from the policy for operational reasons.
1. 偏差運用上の理由から、ポリシーから一時的または恒久的な偏差を指定します。
2. Client-facing capabilities. With reference to each subsection of Section 5.1, provide specific details of which capabilities (transport, DNSSEC, padding, etc.) are provided on which client-facing addresses/port combination or DoH URI template. For Section 5.1.2, clearly specify which specific authentication mechanisms are supported for each endpoint that offers DoT:
2. クライアントに直面する機能。セクション5.1の各サブセクションを参照して、どの機能（トランスポート、DNSSEC、パディングなど）の具体的な詳細を提供しています（トランスポート、DNSSEC、パディングなど）。5.1.2項では、ドットを提供する各エンドポイントに対してどの特定の認証メカニズムがサポートされているかを明確に指定します。
a. The authentication domain name to be used (if any).
a. 使用する認証ドメイン名（存在する場合）。
b. The SPKI pin sets to be used (if any) and policy for rolling keys.
b. SPKIピンは使用されるように設定されます（あれば）、ローリングキーのポリシー。
3. Upstream capabilities. With reference to Section 5.3, provide specific details of which capabilities are provided upstream for data sent to authoritative servers.
3. アップストリーム機能セクション5.3を参照して、権威あるサーバーに送信されたデータのためにアップストリームが提供されている機能の具体的な詳細を提供します。
4. Support. Provide contact/support information for the service.
4. サポート。サービスのための連絡先/サポート情報を提供してください。
5. Data Processing. This section can optionally communicate links to, and the high-level contents of, any separate statements the operator has published that cover applicable data-processing legislation or agreements with regard to the location(s) of service provision.
5. 情報処理。このセクションでは、オペレータが該当するデータ処理法または契約をサービス提供の場所に関してカバーするデータ処理法または契約を任意に発表した任意の任意のステートメントにリンクを任意に通信することができます。
Transparency reports may help with building user trust that operators adhere to their policies and practices.
透明レポートは、オペレータがその方針や慣行を遵守するユーザーの信頼の構築に役立ちます。
Where possible, independent monitoring or analysis could be performed of:
可能であれば、独立した監視または分析を実行することができます。
* ECS, QNAME minimization, EDNS(0) padding, etc.
* ECS、QNAME最小化、EDNS（0）パディングなど
* Filtering.
* フィルタリング。
* Uptime.
* 稼働時間。
This is by analogy with several TLS or website-analysis tools that are currently available -- e.g., [SSL-Labs] or [Internet.nl].
これは、現在入手可能ないくつかのTLSまたはWebサイト分析ツールと同様に、[SSL-Labs]または[internet.nl]。
Additionally, operators could choose to engage the services of a third-party auditor to verify their compliance with their published RPS.
さらに、オペレータは、サードパーティの監査人のサービスに従事して、公開されているRPSへのコンプライアンスを検証することを選択できます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
Security considerations for DNS over TCP are given in [RFC7766], many of which are generally applicable to session-based DNS. Guidance on operational requirements for DNS over TCP are also available in [DNS-OVER-TCP]. Security considerations for DoT are given in [RFC7858] and [RFC8310], and those for DoH in [RFC8484].
TCPを介したDNSのセキュリティ上の考慮事項は[RFC7766]で示されており、その多くはセッションベースのDNSに一般的に適用されます。TCPを介したDNSの運用要件に関するガイダンスも[DNS-over-TCP]で入手可能です。DOTのセキュリティ上の考慮事項は[RFC7858]と[RFC8310]、および[RFC8484]のDOHのためのものです。
Security considerations for DNSSEC are given in [RFC4033], [RFC4034], and [RFC4035].
DNSSECのセキュリティ上の考慮事項は[RFC4033]、[RFC4034]、[RFC4035]に記載されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]クーパー、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルのプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y。、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）およびDTLS（DTLS）」、RFC 7457、DOI 10.17487 / RFC7457、2015年2月、<https://www.rfc-editor.org/info/rfc7457>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[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>.
[RFC7766]ディッキンソン、J.、Dickinson、S.、Bellis、R.、Mankin、A.、D.ウェース、「TCPの輸送 - 実施要件」、RFC 7766、DOI 10.17487 / RFC7766、2016年3月、<https://www.rfc-editor.org/info/rfc7766>。
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, <https://www.rfc-editor.org/info/rfc7816>.
[RFC7816] Bortzmeyer、S。、「DNSクエリ名のプライバシーを改善するための最小化」、RFC 7816、DOI 10.17487 / RFC7816、2016年3月、<https：//www.rfc-editor.org/info/rfc7816>。
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-editor.org/info/rfc7828>.
[RFC7828] Wouters、P.、Cormy、J.、Dickinson、S.、およびR. Bellis、「EDNS-TCP-Keepalive EDNS0オプション」、RFC 7828、DOI 10.17487 / RFC7828、2016年4月、<https：//www.rfc-editor.org/info/rfc7828>。
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <https://www.rfc-editor.org/info/rfc7830>.
[RFC7830] MayRhofer、A。、「EDNS（0）パディングオプション」、RFC 7830、DOI 10.17487 / RFC7830、2016年5月、<https：//www.rfc-editor.org/info/rfc7830>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] HU、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D.、およびP.HOFFMAN、「トランスポート層セキュリティ（TLS）のDNSの仕様（TLS）」、RFC 7858、DOI10.17487 / RFC7858、2016年5月、<https：//www.rfc-editor.org/info/rfc7858>。
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <https://www.rfc-editor.org/info/rfc7871>.
[RFC7871] Contavalli、C、Van Der Gaast、W.、Lawrence、D.、およびW.Kumari、「DNSクエリのクライアントサブネット」、RFC 7871、DOI 10.17487 / RFC7871、2016年5月、<https：// www.rfc-editor.org / info / rfc7871>。
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8020] Bortzmeyer、S.およびS.Huque、 "NXDomain：本当にありません"、RFC 8020、DOI 10.17487 / RFC8020、2017年11月、<https://www.rfc-editor.org/info/rfc8020>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8198]藤原、K。、加藤、A。、およびW.Kumari、「DNSSEC検証キャッシュの積極的な使用」、RFC 8198、DOI 10.17487 / RFC8198、2017年7月、<https：//www.rfc-編集者。ORG / INFO / RFC8198>。
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-editor.org/info/rfc8310>.
[RFC8310]ディッキンソン、S.、Gillmor、D.、DNDY、「DNS上のDNSのための使用プロフィール」、RFC 8310、DOI 10.17487 / RFC8310、2018年3月、<https：//www.rfc-editor.org/info/rfc8310>。
[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>.
[RFC8467] MayRhofer、A.「DNSの拡張メカニズムのためのパディングポリシー（EDNS（0））、RFC 8467、DOI 10.17487 / RFC8467、2018年10月、<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>.
[RFC8484] HOFFMAN、P.およびP.Mcmanus、「HTTPS経由のDNSクエリ（DOH）」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https：//www.rfc-editor.org/info/rfc8484>。
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", RFC 8490, DOI 10.17487/RFC8490, March 2019, <https://www.rfc-editor.org/info/rfc8490>.
[RFC8490] Bellis、R.、Cheshire、S.、Dickinson、J.、Dickinson、S.、Lemon、T.、およびT.Pusateri、「DNSステートフル操作」、RFC 8490、DOI 10.17487 / RFC8490、2019年3月、<https://www.rfc-editor.org/info/rfc8490>。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499] Hoffman、P.、Sullivan、A.、K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https：//www.rfc-editor.org/情報/ RFC8499>。
[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>.
[RFC8806] kumari、W.およびP.Hoffman、「リゾルバのローカルのルートサーバの実行」、RFC 8806、DOI 10.17487 / RFC8806、2020年6月、<https://www.rfc-editor.org/info/rfc8806>。
[Bloom-filter] van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L. Allodi, "Privacy-Conscious Threat Intelligence Using DNSBLOOM", IFIP/IEEE International Symposium on Integrated Network Management (IM2019), 2019, <http://dl.ifip.org/db/conf/im/im2019/189282.pdf>.
[ブルームフィルター] van Rijswijk-Deij、R.、Rijnders、G.、Bomhoff、M.、およびL. Allodi、「DNSBLOOMを使用したプライバシー - 意識型脅威情報」、IFIP / IEEE国際シンポジウム統合ネットワーク管理（IM2019）、2019、<http://dl.ifip.org/db/conf/im/im2019/189282.pdf>。
[Brekne-and-Arnes] Brekne, T. and A. Årnes, "Circumventing IP-address pseudonymization", Communications and Computer Networks, 2005, <https://pdfs.semanticscholar.org/7b34/12c951cebe71c d2cddac5fda164fb2138a44.pdf>.
[Brekne-And-Arnes] Brekne、T.およびA.ÅRNES、「IPアドレス仮説を回避する」、通信およびコンピュータネットワーク、2005、<https：//pdfs.semanticscholar.org/7b34/12c951ce71cd2cddac5fda164.pdf>。
[BUILD-W-HTTP] Nottingham, M., "Building Protocols with HTTP", Work in Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-09, 1 November 2019, <https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-09>.
[Build-W-HTTP]ノッティンガム、M.、「HTTPを備えたプロトコルの構築」、進行中の作業、インターネットドラフト、romft-ietf-httpbis-bcp56bis-09,219、<https：//tools.ietf。org / html / draft-ietf-httpbis-bcp56bis-09>。
[Crypto-PAn] CESNET, "Crypto-PAn", commit 636b237, March 2015, <https://github.com/CESNET/ipfixcol/tree/master/base/src/ intermediate/anonymization/Crypto-PAn>.
[Crypto-Pan] CESnet、 "crypto-pan"、2015年3月、<https：//github.com/cessnet/ipfixcol/tree/master/base/src/ intermed /匿名化/暗号-PAN>。
[DNS-OVER-TCP] Kristoff, J. and D. Wessels, "DNS Transport over TCP - Operational Requirements", Work in Progress, Internet-Draft, draft-ietf-dnsop-dns-tcp-requirements-06, 6 May 2020, <https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requirements-06>.
[DNS-over-TCP]クリストフ、J.およびD.ウェース、「TCP輸送 - 業務要件上のDNS輸送」、進行中の作業、インターネットドラフト、ドラフト-IETF-DNSOP-DNS-TCP要件-06,06,62020、<https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requiretements-06>。
[DNS-Privacy-not-so-private] Silby, S., Juarez, M., Vallina-Rodriguez, N., and C. Troncoso, "DNS Privacy not so private: the traffic analysis perspective.", Privacy Enhancing Technologies Symposium, 2018, <https://petsymposium.org/2018/files/hotpets/4-siby.pdf>.
[DNS-Privacy-Not-So-Private] Silby、S.、Juarez、M.、Vallina-Rodriguez、N.、およびC.Troncoso、「DNSプライバシーはそれほどプライベートではない：トラフィック分析の観点」、プライバシー強化技術Symposium、2018年、<https：//petsymposium.org/2018/files/hotpets/4-siby.pdf>。
[DNS-XPF] Bellis, R., Dijk, P. V., and R. Gacogne, "DNS X-Proxied-For", Work in Progress, Internet-Draft, draft-bellis-dnsop-xpf-04, 5 March 2018, <https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04>.
[DNS-XPF] Bellis、R.、Dijk、PV、R. Gacogne、「DNS Xプロキシ」、進行中の作業、インターネットドラフト、ドラフト-DNSOP-XPF-04,24,5000<https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04>。
[DNSCrypt] "DNSCrypt - Official Project Home Page", <https://www.dnscrypt.org>.
[DNSCRYPT] "DNSCRYPT - 公式プロジェクトのホームページ"、<https://www.dnscrypt.org>。
[dnsdist] PowerDNS, "dnsdist Overview", <https://dnsdist.org>.
[DNSDIST] PowerDNS、「DNSDistの概要」、<https://dnsdist.org>。
[dnstap] "dnstap", <https://dnstap.info>.
[DNSTAP] "dnstap"、<https://dnstap.info>。
[DoH-resolver-policy] Mozilla, "Security/DOH-resolver-policy", 2019, <https://wiki.mozilla.org/Security/DOH-resolver-policy>.
[Doh-Resolver-Policy] Mozilla、 "Security / Doh-Resolver-Policy"、2019、<https：//wiki.mozilla.org/security/doh-resolver-policy>。
[dot-ALPN] IANA, "Transport Layer Security (TLS) Extensions: TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs", <https://www.iana.org/assignments/tls-extensiontype-values>.
[DOT-ALPN] IANA、「トランスポートレイヤセキュリティ（TLS）拡張子：TLSアプリケーション層プロトコルネゴシエーション（ALPN）プロトコルID」、<https：//www.iana.org/ashignments/tls-extensionType-values>。
[Geolocation-Impact-Assessment] Conversion Works, "Anonymize IP Geolocation Accuracy Impact Assessment", 19 May 2017, <https://www.conversionworks.co.uk/blog/2017/05/19/ anonymize-ip-geo-impact-test/>.
[地理位置 - 影響評価]変換作品、「匿名化IP地理化精度評価評価」、2017年5月19日、<https：//www.conversionworks.co.uk/blog/2017/05/19/匿名化 - IP-Geo-衝撃検定/>
[haproxy] "HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer", <https://www.haproxy.org/>.
[HAPROXY] "HAPROXY - 信頼できる、高性能TCP / HTTPロードバランサ"、<https://www.haproxy.org/>。
[Harvan] Harvan, M., "Prefix- and Lexicographical-order-preserving IP Address Anonymization", IEEE/IFIP Network Operations and Management Symposium, DOI 10.1109/NOMS.2006.1687580, 2006, <http://mharvan.net/talks/noms-ip_anon.pdf>.
[Harvan]ハーバン、M.、「プレフィックス - および辞書順序保存IPアドレス匿名化」、IEEE / IFIPネットワーク事業および管理シンポジウム、DOI 10.1109 / NOMS.2006.1687580,2006、<http://mharvan.net/talks/noms-it_anon.pdf>。
[Internet.nl] Internet.nl, "Internet.nl Is Your Internet Up To Date?", 2019, <https://internet.nl>.
[internet.nl] internet.nl、 "internet.nlはあなたのインターネットは最新のものですか？"、2019、<https://internet.nl>。
[IP-Anonymization-in-Analytics] Google, "IP Anonymization in Analytics", 2019, <https://support.google.com/analytics/ answer/2763052?hl=en>.
[IP-匿名化インアナリティクス] Google、「AnalyticsのIP匿名化」、2019、<https：//support.google.com/Analytics/ Answer / 2763052？HL = EN>。
[ipcipher1] Hubert, B., "On IP address encryption: security analysis with respect for privacy", Medium, 7 May 2017, <https://medium.com/@bert.hubert/on-ip-address-encryption-security-analysis-with-respect-for-privacy-dabe1201b476>.
[IPCipher1] Hubert、B、「IPアドレスの暗号化：プライバシーに対するセキュリティ分析」、中、中、2017年5月7日、<https：//medium.com/@bert.hubert/on-ip-address-encryption-セキュリティ - 尊重 - Privacy-Dabe1201B476>。
[ipcipher2] PowerDNS, "ipcipher", commit fd47abe, 13 February 2018, <https://github.com/PowerDNS/ipcipher>.
[ipciphion2] PowerDNS、 "IPCipher"、2018年2月13日、<https：//github.com/powerdns/ipcipher>をコミットする。
[ipcrypt] veorq, "ipcrypt: IP-format-preserving encryption", commit 8cc12f9, 6 July 2015, <https://github.com/veorq/ipcrypt>.
[IPcrypt] Veorq、 "IPCrypt：IP-Format-Serming Encryption"、COMMIT 8CC12F9、2015年7月6日、<https：//github.com/veorq/ipcrypt>。
[ipcrypt-analysis] Aumasson, J-P., "Subject: Re: [Cfrg] Analysis of ipcrypt?", message to the Cfrg mailing list, 22 February 2018, <https://mailarchive.ietf.org/arch/msg/cfrg/ cFx5WJo48ZEN-a5cj_LlyrdN8-0/>.
[IPCrypt-Analysis] Aumasson、JP、JP。、「件名：re：[CFRG] IPCryptの分析？」、CFRGメーリングリストへのメッセージ、<https：//mailarchive.ietf.org/arch/msg/CFRG / CFX5WJO48ZEN-A5CJ_LLYRDN8-0 />。
[ISC-Knowledge-database-on-cache-snooping] Goldlust, S. and C. Almond, "DNS Cache snooping - should I be concerned?", ISC Knowledge Database, 15 October 2018, <https://kb.isc.org/docs/aa-00482>.
[ISC知識データベースオンキャッシュスヌーピング] Goldlust、S.およびC. Almond、「DNSキャッシュスヌーピング - 私は心配するべきですか」、ISCナレッジデータベース、2018年10月15日、<https：//kb.isc.ORG / DOCS / AA-00482>。
[MAC-address-EDNS] Hubert, B., "Embedding MAC address in DNS requests for selective filtering", DNS-OARC mailing list, 25 January 2016, <https://lists.dns-oarc.net/pipermail/dns-operations/2016-January/014143.html>.
[MAC-address-edns] Hubert、B.、「選択的フィルタリングのためのDNS要求におけるMACアドレスの埋め込み」、DNS-OARCメーリングリスト、2016年1月25日、<https：//lists.dns-oarc.net/pipermail/dns - operations / 2016 - 1月/ 014143.html>。
[nginx] nginx.org, "nginx news", 2019, <https://nginx.org/>.
[Nginx] nginx.org、 "nginx news"、2019、<https://nginx.org/>。
[Passive-Observations-of-a-Large-DNS] de Vries, W. B., van Rijswijk-Deij, R., de Boer, P-T., and A. Pras, "Passive Observations of a Large DNS Service: 2.5 Years in the Life of Google", DOI 10.23919/TMA.2018.8506536, 2018, <http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper30.pdf>.
[A-LARGE-DNSの受動的観察] VRIE、WB、Van Rijswijk-Deij、R.、De Boer、Pt。2018年、Google "、Doi 10.23919 / TMA.2018.8506536、<http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper30.pdf>。
[pcap] The Tcpdump Group, "Tcpdump & Libpcap", 2020, <https://www.tcpdump.org/>.
[PCAP] TCPDUMPグループ「tcpdump＆libpcap」、2020、<https://www.tcpdump.org/>。
[Pitfalls-of-DNS-Encryption] Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS Encryption", Proceedings of the 13th Workshop on Privacy in the Electronic Society, pp. 191-200, DOI 10.1145/2665943.2665959, November 2014, <https://dl.acm.org/citation.cfm?id=2665959>.
[DNS暗号化] Shulman、H.、「かなり悪いプライバシー：DNS暗号化の落とし穴」、電子社会におけるプライバシーに関する第13回ワークショップの手続き、PP 191-200、DOI 10.1145 / 2665943.2665959、2014年11月、<https://dl.acm.org/catute.cfm ?id=2665959>。
[policy-comparison] Dickinson, S., "Comparison of policy and privacy statements 2019", DNS Privacy Project, 18 December 2019, <https://dnsprivacy.org/wiki/display/DP/ Comparison+of+policy+and+privacy+statements+2019>.
[政策比較]ディッキンソン、S.、「政策とプライバシーに関する比較2019年12月18日」2019年12月18日、<https：//dnsprivacy.org/wiki/display/dp/ポリシーとプライバシーに関する声明の比較2019>。
[PowerDNS-dnswasher] PowerDNS, "dnswasher", commit 050e687, 24 April 2020, <https://github.com/PowerDNS/pdns/blob/master/pdns/ dnswasher.cc>.
[PowerDNS-DNSWASHER] PowerDNS、「DNSwasher」、COMMIT 050E687,2010 2020、<https：//github.com/powerdns/pdns/blob/master/pdns/ dnswasher.cc>。
[Ramaswamy-and-Wolf] Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving IP Address Anonymization for Passive Measurement Systems", DOI 10.1109/TNET.2006.890128, 2007, <http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.
[Ramaswamy-And-Wolf] Ramaswamy、R.およびT.オオカミ、「パッシブ測定システムの高速プレフィックス保存IPアドレス匿名化」、DOI 10.1109 / TNET2006.890128,2007、<http：//www.ecs。umass.edu/ece/wolf/pubs/ton2007.pdf>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張のためのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、<https://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、M.、Massey、D.、およびS. Rose、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、<https://www.rfc-editor.org/info/rfc4035>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P.、およびH。Tschofenig、「サーバー側の状態なしのトランスポート層セキュリティ（TLS）セッション再開」、RFC 5077、DOI 10.17487 / RFC5077、2008年1月、<https://www.rfc-editor.org/info/rfc5077>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、およびI。van Beijnum、「DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス翻訳のためのDNS拡張」、RFC 6147、DOI 10.17487 / RFC6147、4月2011年、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, <https://www.rfc-editor.org/info/rfc6235>.
[RFC6235] Boschi、E.およびB. Trammell、「IPフロー匿名化サポート」、RFC 6235、DOI 10.17487 / RFC6235、2011年5月、<https：//www.rfc-editor.org/info/rfc6235>。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC6265] BARTH、A。、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<https：//www.rfc-editor.org/info/rfc6265>。
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <https://www.rfc-editor.org/info/rfc7626>.
[RFC7626] Bortzmeyer、S。、「DNSプライバシーに関する考慮事項」、RFC 7626、DOI 10.17487 / RFC7626、2015年8月、<https://www.rfc-editor.org/info/rfc7626>。
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, <https://www.rfc-editor.org/info/rfc7873>.
[RFC7873]イーストレイク3RD、D.およびM. Andrews、「ドメインネームシステム（DNS）クッキー」、RFC 7873、DOI 10.17487 / RFC7873、2016年5月、<https：//www.rfc-editor.org/info/rfc7873>。
[RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, DOI 10.17487/RFC8027, November 2016, <https://www.rfc-editor.org/info/rfc8027>.
[RFC8027]ハーメー、W.、Gudmundsson、O.、およびS.Krishnaswamy、「DNSSEC Roadblock Dreavance」、BCP 207、RFC 8027、DOI 10.17487 / RFC8027、2016年11月、<https：//www.rfc-editor.org/ INFO / RFC8027>。
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.
[RFC8094] Reddy、T.、Wing、D.、およびP. Aptil、「DNS overデータグラムトランスポート層セキュリティ（DNS）、RFC 8094、DOI 10.17487 / RFC8094、2017年2月、<https：///www.rfc-editor.org/info/rfc8094>。
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.
[RFC8404] MoriAlty、K。、ED。A. Morton、Ed。、「オペレータ上の周辺暗号化の影響」、RFC 8404、DOI 10.17487 / RFC8404、2018年7月、<https：//www.rfc-editor.org/info/rfc8404>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
[RFC8555] Barnes、R.、Hoffman-Andrews、J.、McCarney、D.、およびJ.Kasten、「自動証明書管理環境（ACME）」、RFC 8555、DOI 10.17487 / RFC8555、2019年3月、<https：//www.rfc-editor.org/info/rfc8555>。
[RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T., and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September 2019, <https://www.rfc-editor.org/info/rfc8618>.
[RFC8618]ディッキンソン、J.、Hague、J.、Dickinson、S.、Manderson、T.、J. Bond、「コンパクトDNS（C-DNS）：DNSパケットキャプチャのフォーマット、RFC 8618、DOI10.17487 / RFC8618、2019年9月、<https：//www.rfc-editor.org/info/rfc8618>。
[SSL-Labs] SSL Labs, "SSL Server Test", 2019, <https://www.ssllabs.com/ssltest/>.
[SSL-Labs] SSL Labs、 "SSL Server Test"、2019、<https://www.sslabs.com/ssltest/>。
[stunnel] Goldlust, S., Almond, C., and F. Dupont, "DNS over TLS", ISC Knowledge Database", 1 November 2018, <https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html>.
[Stunnel] Goldlust、S.、Almond、C.、F.Dupont、「TLS上のDNS」、ISC Knowledge Database "、2018年11月1日、<https：//kb.cis.org/article/aa-01386/0 / dns-over-tls.html>。
[SURFnet-policy] Baartmans, C., van Wynsberghe, A., van Rijswijk-Deij, R., and F. Jorna, "SURFnet Data Sharing Policy", June 2016, <https://surf.nl/datasharing>.
[サーフネット - ポリシー] Baartmans、C、Van Wynsberghe、A.、Van Rijswijk-Deij、R.、およびF. Jorna、2016年6月、2016年6月、<https://surf.nl/Datasharing>。
[tcpdpriv] Ipsilon Networks, Inc., "TCPDRIV - Program for Eliminating Confidential Information from Traces", 2004, <http://fly.isti.cnr.it/software/tcpdpriv/>.
[TCPDPRIV] IPSilon Networks、Inc。、「TCPDRIV - トレースから機密情報を除去するためのプログラム」、2004、<http://fly.isti.cnr.it/software/tcpdpriv/>。
[van-Dijkhuizen-et-al] Van Dijkhuizen, N. and J. Van Der Ham, "A Survey of Network Traffic Anonymisation Techniques and Implementations", ACM Computing Surveys, DOI 10.1145/3182660, May 2018, <https://doi.org/10.1145/3182660>.
[van-dijkhuizen-et-al] van dijkhuizen、N.およびJ.Fan der Ham、 "ネットワークトラフィックの匿名化技術と実装の調査"、ACMコンピューティング調査、DOI 10.1145 / 3182660、2018年5月、<https：//doi.org/10.1145/3182660
[Xu-et-al] Fan, J., Xu, J., Ammar, M.H., and S.B. Moon, "Prefix-preserving IP address anonymization: measurement-based security evaluation and a new cryptography-based scheme", DOI 10.1016/j.comnet.2004.03.033, 2004, <http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-anon.pdf>.
[Xu-et-al]ファン、J.、XU、J.、AMMAR、M.H.およびS.B.月、「プレフィックス保存IPアドレス匿名化：測定ベースのセキュリティ評価と新しい暗号化ベースのスキーム」、DOI 10.1016 / J.com2004.03.033,2004、<http://an.kaist.ac.kr/~SBMoon / Paper / Intl-Journal / 2004-CN-anon.pdf>。
This section provides an overview of some DNS privacy-related documents. However, this is neither an exhaustive list nor a definitive statement on the characteristics of any document with regard to potential increases or decreases in DNS privacy.
このセクションでは、DNSプライバシー関連の文書の概要について説明します。ただし、これは徹底的なリストでもDNSプライバシーの潜在的な増減の潜在的な影響を伴う文書の特性に関する決定的な声明でもありません。
These documents are limited in scope to communications between stub clients and recursive resolvers:
これらの文書は、スタブクライアントと再帰的リゾルバ間のコミュニケーションへの範囲で制限されています。
* "Specification for DNS over Transport Layer Security (TLS)" [RFC7858].
* "トランスポート層セキュリティ（TLS）のDNSの指定（TLS）" [RFC7858]。
* "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094]. Note that this document has the category of Experimental.
* "データグラムトランスポートレイヤセキュリティ（DTLS）" [RFC8094]。この文書には実験のカテゴリがあります。
* "DNS Queries over HTTPS (DoH)" [RFC8484].
* 「https（doh）」[RFC8484を介したDNSクエリ]。
* "Usage Profiles for DNS over TLS and DNS over DTLS" [RFC8310].
* "TLSを介したDNSおよびDNS上のDNSの使用プロファイル] [RFC8310]。
* "The EDNS(0) Padding Option" [RFC7830] and "Padding Policies for Extension Mechanisms for DNS (EDNS(0))" [RFC8467].
* "eDNS（0）パディングオプション" [RFC7830]と「DNSの拡張メカニズムのパディングポリシー（edns（0）」）[RFC8467]。
These documents apply to recursive and authoritative DNS but are relevant when considering the operation of a recursive server:
これらの文書は再帰的および権威あるDNSに適用されますが、再帰的なサーバーの操作を考慮するときに関連があります。
* "DNS Query Name Minimisation to Improve Privacy" [RFC7816].
* 「DNSクエリ名プライバシーを向上させるための最小化」[RFC7816]。
These documents relate to functionality that could provide increased tracking of user activity as a side effect:
これらの文書は、副作用としてのユーザーアクティビティの追跡を増やす可能性がある機能に関連しています。
* "Client Subnet in DNS Queries" [RFC7871].
* 「DNSクエリのクライアントサブネット」[RFC7871]。
* "Domain Name System (DNS) Cookies" [RFC7873]).
* 「ドメインネームシステム（DNS）クッキー」[RFC7873]）。
* "Transport Layer Security (TLS) Session Resumption without Server-Side State" [RFC5077], referred to here as simply TLS session resumption.
* 「サーバー側の状態なしのトランスポートレイヤセキュリティ（TLS）セッション再開」は、ここでは単なるTLSセッションの再開と呼ばれます。
* [RFC8446], Appendix C.4 describes client tracking prevention in TLS 1.3
* [RFC8446]、付録C.4はTLS 1.3のクライアント追跡防止を説明しています
* "Compacted-DNS (C-DNS): A Format for DNS Packet Capture" [RFC8618].
* "Compacted-DNS（C-DNS）：DNSパケットキャプチャのフォーマット" [RFC8618]。
* Passive DNS [RFC8499].
* パッシブDNS [RFC8499]。
* Section 8 of [RFC8484] outlines the privacy considerations of DoH. Note that (while that document advises exposing the minimal set of data needed to achieve the desired feature set), depending on the specifics of a DoH implementation, there may be increased identification and tracking compared to other DNS transports.
* [RFC8484]のセクション8は、DOHのプライバシーの考慮事項を概説しています。（その文書が所望の特徴セットを達成するのに必要な最小のデータセットを露出させる）は、DOH実装の詳細に応じて、他のDNSトランスポートと比較して識別および追跡が増加する可能性がある。
* "DNS Transport over TCP - Implementation Requirements" [RFC7766].
* "TCP - 実装要件を介したDNSトランスポート" [RFC7766]。
* "DNS Transport over TCP - Operational Requirements" [DNS-OVER-TCP].
* 「TCP - 運用上の要求を介したDNS輸送」[DNS-over-TCP]。
* "The edns-tcp-keepalive EDNS0 Option" [RFC7828].
* "edns-tcp-keepalive edns0オプション" [RFC7828]。
* "DNS Stateful Operations" [RFC8490].
* 「DNSステートフルオペレーション」[RFC8490]。
The following table presents a high-level comparison of various techniques employed or under development in 2019 and classifies them according to categorization of technique and other properties. Both the specific techniques and the categorizations are described in more detail in the following sections. The list of techniques includes the main techniques in current use but does not claim to be comprehensive.
次の表は、2019年に使用されているかまたは開発中のさまざまな技術の高レベル比較を示し、技術の分類やその他の特性に従ってそれらを分類します。特定の技術と分類の両方について、以下のセクションで詳しく説明します。テクニックのリストには、現在の使用における主な技術が含まれていますが、包括的であるとは主張しません。
+===========================+====+===+====+===+====+===+===+
| Categorization/Property | GA | d | TC | C | TS | i | B |
+===========================+====+===+====+===+====+===+===+
| Anonymization | X | X | X | | | | X |
+---------------------------+----+---+----+---+----+---+---+
| Pseudonymization | | | | X | X | X | |
+---------------------------+----+---+----+---+----+---+---+
| Format preserving | X | X | X | X | X | X | |
+---------------------------+----+---+----+---+----+---+---+
| Prefix preserving | | | X | X | X | | |
+---------------------------+----+---+----+---+----+---+---+
| Replacement | | | X | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Filtering | X | | | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Generalization | | | | | | | X |
+---------------------------+----+---+----+---+----+---+---+
| Enumeration | | X | | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Reordering/Shuffling | | | X | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Random substitution | | | X | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Cryptographic permutation | | | | X | X | X | |
+---------------------------+----+---+----+---+----+---+---+
| IPv6 issues | | | | | X | | |
+---------------------------+----+---+----+---+----+---+---+
| CPU intensive | | | | X | | | |
+---------------------------+----+---+----+---+----+---+---+
| Memory intensive | | | X | | | | |
+---------------------------+----+---+----+---+----+---+---+
| Security concerns | | | | | | X | |
+---------------------------+----+---+----+---+----+---+---+
Table 1: Classification of Techniques
表1：テクニックの分類
Legend of techniques:
テクニックの伝説：
GA = Google Analytics d = dnswasher TC = TCPdpriv C = CryptoPAn TS = TSA i = ipcipher B = Bloom filter
GA = Google Analytics D = DNSWASHER TC = TCPDPRIV C =暗号PRIV C = CRYPTOPAN TS = TSA I = IPCiPher B = Bloom Filter
The choice of which method to use for a particular application will depend on the requirements of that application and consideration of the threat analysis of the particular situation.
特定のアプリケーションに使用する方法の選択は、そのアプリケーションの要件と特定の状況の脅威分析の検討に依存します。
For example, a common goal is that distributed packet captures must be in an existing data format, such as PCAP [pcap] or Compacted-DNS (C-DNS) [RFC8618], that can be used as input to existing analysis tools. In that case, use of a format-preserving technique is essential. This, though, is not cost free; several authors (e.g., [Brekne-and-Arnes]) have observed that, as the entropy in an IPv4 address is limited, if an attacker can
たとえば、一般的な目標は、PCAP [PCAP]またはCOMPACT-DNS（C-DNS）[RFC8618]など、分散型パケットキャプチャが既存のデータ形式でなければならず、既存の分析ツールへの入力として使用できます。その場合、フォーマット保存技術の使用が不可欠です。しかし、これは無料ではありません。攻撃者ができる場合、IPv4アドレスのエントロピーが制限されている場合、いくつかの著者（例えば、Brekne-and-Arnes]）が観察されています。
* ensure packets are captured by the target and
* パケットがターゲットによってキャプチャされていることを確認します
* send forged traffic with arbitrary source and destination addresses to that target and
* そのターゲットに任意のソースアドレスと宛先アドレスを持つ鍛造トラフィックを送信します。
* obtain a de-identified log of said traffic from that target,
* そのターゲットからの上記のトラフィックの識別されたログを取得します。
any format-preserving pseudonymization is vulnerable to an attack along the lines of a cryptographic chosen-plaintext attack.
任意のフォーマット保存仮想化は、暗号化された選択された平文攻撃の行に沿った攻撃に対して脆弱です。
Data minimization methods may be categorized by the processing used and the properties of their outputs. The following builds on the categorization employed in [RFC6235]:
データ最小化方法は、使用される処理およびそれらの出力の特性によって分類され得る。[RFC6235]で採用されている分類に関する次のようなビルド：
Format-preserving. Normally, when encrypting, the original data length and patterns in the data should be hidden from an attacker. Some applications of de-identification, such as network capture de-identification, require that the de-identified data is of the same form as the original data, to allow the data to be parsed in the same way as the original.
フォーマット保存通常、暗号化すると、データ内の元のデータ長とパターンは攻撃者から隠されるべきです。ネットワークキャプチャの除去などの識別の一部のアプリケーションは、識別されたデータが元のデータと同じ形式であることを要求し、データを元のデータと同じ方法で解析することを可能にします。
Prefix preservation. Values such as IP addresses and MAC addresses contain prefix information that can be valuable in analysis -- e.g., manufacturer ID in MAC addresses, or subnet in IP addresses. Prefix preservation ensures that prefixes are de-identified consistently; for example, if two IP addresses are from the same subnet, a prefix preserving de-identification will ensure that their de-identified counterparts will also share a subnet. Prefix preservation may be fixed (i.e., based on a user-selected prefix length identified in advance to be preserved ) or general.
プレフィックス保存IPアドレスやMACアドレスなどの値には、Analysisに貴重なプレフィックス情報が含まれています。例えば、MACアドレスの製造元ID、またはIPアドレスのサブネット。接頭辞の保存により、接頭辞が一貫して識別されていることが保証されます。たとえば、2つのIPアドレスが同じサブネットからのものである場合、プレフィックスの保存除去の除去は、識別された対応物がサブネットを共有するようになります。プレフィックス保存は固定されてもよい（すなわち、予め保存されるように識別されたユーザ選択されたプレフィックス長に基づいて）または一般的なものを基にすることができる。
Replacement. A one-to-one replacement of a field to a new value of the same type -- for example, using a regular expression.
置換。例えば、正規表現を使用して、フィールドを同じタイプの新しい値に置き換えます。
Filtering. Removing or replacing data in a field. Field data can be overwritten, often with zeros, either partially (truncation or reverse truncation) or completely (black-marker anonymization).
フィルタリング。フィールド内のデータの削除または交換。フィールドデータは、部分的に（切り捨てまたは逆の切り捨て）または完全に（ブラックマーカーの匿名化）のいずれかで、ゼロを使用して上書きできます。
Generalization. Data is replaced by more general data with reduced specificity. One example would be to replace all TCP/UDP port numbers with one of two fixed values indicating whether the original port was ephemeral (>=1024) or nonephemeral (>1024). Another example, precision degradation, reduces the accuracy of, for example, a numeric value or a timestamp.
一般化データは特に減らした一般的なデータに置き換えられます。1つの例は、すべてのTCP / UDPポート番号を、元のポートがエフェメラル（> = 1024）またはNonePhereMerrer（> 1024）であるかどうかを示す2つの固定値のうちの1つで置き換えることです。別の例、精密劣化は、例えば数値またはタイムスタンプの精度を低下させる。
Enumeration. With data from a well-ordered set, replace the first data item's data using a random initial value and then allocate ordered values for subsequent data items. When used with timestamp data, this preserves ordering but loses precision and distance.
列挙。順調に順序付けられたセットからデータを使用して、ランダムな初期値を使用して最初のデータ項目のデータを置き換えてから、後続のデータ項目に順序付けられた値を割り当てます。タイムスタンプデータで使用する場合、これは注文を保持しますが、精度と距離を失います。
Reordering/shuffling. Preserving the original data, but rearranging its order, often in a random manner.
並べ替え/シャッフリング。元のデータを保存しますが、その順序を並べ替えて、しばしばランダムな方法で並べ替えます。
Random substitution. As replacement, but using randomly generated replacement values.
ランダムな置き換え置き換えとして、ランダムに生成された置換値を使用しています。
Cryptographic permutation. Using a permutation function, such as a hash function or cryptographic block cipher, to generate a replacement de-identified value.
暗号化順列ハッシュ関数や暗号化ブロック暗号などの置換関数を使用して、置換識別された値を生成します。
Since May 2010, Google Analytics has provided a facility [IP-Anonymization-in-Analytics] that allows website owners to request that all their users' IP addresses are anonymized within Google Analytics processing. This very basic anonymization simply sets to zero the least significant 8 bits of IPv4 addresses, and the least significant 80 bits of IPv6 addresses. The level of anonymization this produces is perhaps questionable. There are some analysis results [Geolocation-Impact-Assessment] that suggest that the impact of this on reducing the accuracy of determining the user's location from their IP address is less than might be hoped; the average discrepancy in identification of the user city for UK users is no more than 17%.
2010年5月から、Google Analyticsは、Webサイト所有者がすべてのユーザーのIPアドレスがGoogle Analytics処理内で匿名化されていることを要求できるようにする機能[IP-Anonymization-In Analytics]を提供しました。この非常に基本的な匿名化は、単に最下位8ビットのIPv4アドレス、および最下位80ビットのIPv6アドレスをゼロに設定するだけです。これが生産する匿名化のレベルはおそらく疑問である。いくつかの分析結果があります[地理位置衝合評価]は、そのIPアドレスからのユーザーの場所を決定する精度を低下させるということを望んでいる可能性が低いことを示唆している。英国のユーザーのユーザーシティの識別における平均的な食い違いは17％以下です。
Anonymization: Format-preserving, Filtering (truncation).
匿名化：フォーマット保存、フィルタリング（切り捨て）。
Since 2006, PowerDNS has included a de-identification tool, dnswasher [PowerDNS-dnswasher], with their PowerDNS product. This is a PCAP filter that performs a one-to-one mapping of end-user IP addresses with an anonymized address. A table of user IP addresses and their de-identified counterparts is kept; the first IPv4 user addresses is translated to 0.0.0.1, the second to 0.0.0.2, and so on. The de-identified address therefore depends on the order that addresses arrive in the input, and when running over a large amount of data, the address translation tables can grow to a significant size.
2006年以来、PowerDNSは、DNSWASHER [PowerDNS-DNSwasher]をPOWERDNS製品と含めました。これは、匿名化アドレスを持つエンドユーザーIPアドレスの1対1マッピングを実行するPCAPフィルタです。ユーザーIPアドレスとその識別された対応物の表は保持されています。最初のIPv4のユーザーアドレスは0.0.0.1、2番目から0.0.0.2などに変換されます。したがって、識別されたアドレスは、アドレスが入力に到着する順序によって異なり、大量のデータを介して実行すると、アドレス変換テーブルはかなりのサイズに拡大できます。
Anonymization: Format-preserving, Enumeration.
匿名化：フォーマット保存、列挙。
Used in [tcpdpriv], this algorithm stores a set of original and anonymized IP address pairs. When a new IP address arrives, it is compared with previous addresses to determine the longest prefix match. The new address is anonymized by using the same prefix, with the remainder of the address anonymized with a random value. The use of a random value means that TCPdpriv is not deterministic; different anonymized values will be generated on each run. The need to store previous addresses means that TCPdpriv has significant and unbounded memory requirements. The need to allocate anonymized addresses sequentially means that TCPdpriv cannot be used in parallel processing.
[TCPDPRIV]で使用され、このアルゴリズムは一連のオリジナルおよび匿名化IPアドレスペアを格納します。新しいIPアドレスが到着すると、以前のアドレスと比較され、最長のプレフィックスの一致を判断します。新しいアドレスは同じ接頭辞を使用して匿名化され、残りのアドレスはランダムな値で匿名化されます。ランダムな値の使用は、TCPDPRIVが決定論的ではないことを意味します。各実行で異なる匿名化された値が生成されます。以前のアドレスを保存する必要性は、TCPDPRIVが重要かつ無制限のメモリ要件を持っていることを意味します。匿名アドレスを割り当てる必要性は順次に、TCPDPRIVを並列処理で使用できないことを意味します。
Anonymization: Format-preserving, prefix preservation (general).
匿名化：フォーマット保存、プレフィックス保存（一般）。
Cryptographic prefix-preserving pseudonymization was originally proposed as an improvement to the prefix-preserving map implemented in TCPdpriv, described in [Xu-et-al] and implemented in the [Crypto-PAn] tool. Crypto-PAn is now frequently used as an acronym for the algorithm. Initially, it was described for IPv4 addresses only; extension for IPv6 addresses was proposed in [Harvan]. This uses a cryptographic algorithm rather than a random value, and thus pseudonymity is determined uniquely by the encryption key, and is deterministic. It requires a separate AES encryption for each output bit and so has a nontrivial calculation overhead. This can be mitigated to some extent (for IPv4, at least) by precalculating results for some number of prefix bits.
暗号化プレフィックス保存擬似断書はもともと、[XU-et-al]で説明され、[Crypto-Pan]ツールで実装されているTCPDPRIVで実装されたプレフィックス保存マップの改善として提案されています。Crypto-PANは、アルゴリズムの頭字語として頻繁に使用されています。最初は、IPv4アドレスについてのみ説明されていました。IPv6アドレスの拡張は[Harvan]で提案されました。これは、ランダム値ではなく暗号化アルゴリズムを使用し、したがって擬似系統は暗号化キーによって一意に決定され、決定論的です。それは各出力ビットに対して別々のAES暗号化を必要とし、そして非通の計算オーバーヘッドを有する。これは、ある程度のプレフィックスビットの結果を予測することによって、ある程度（少なくともIPv4の場合）軽減できます。
Pseudonymization: Format-preserving, prefix preservation (general).
疑似系統：フォーマット保存、プレフィックス保存（一般）。
Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated Anonymization (TSA) originated in response to the requirement for faster processing than Crypto-PAn. It used hashing for the most significant byte of an IPv4 address and a precalculated binary-tree structure for the remainder of the address. To save memory space, replication is used within the tree structure, reducing the size of the precalculated structures to a few megabytes for IPv4 addresses. Address pseudonymization is done via hash and table lookup and so requires minimal computation. However, due to the much-increased address space for IPv6, TSA is not memory efficient for IPv6.
[Ramaswamy-And-Wolf]で提案されている、トップハッシュサブツリー複製匿名化（TSA）は、暗号パンよりも速い処理の要件に応じて発生しました。IPv4アドレスの最上位バイトとアドレスの残りの部分のための事前に算直的なバイナリツリー構造を使用しました。メモリ容量を保存するために、レプリケーションはツリー構造内で使用され、事前計算構造のサイズをIPv4アドレスの数メガバイトに減らすことができます。アドレス疑似法はハッシュとテーブルの検索を介して行われ、最小限の計算が必要です。ただし、IPv6のためのアドレス空間が多いため、TSAはIPv6にとってメモリ効率の高いものではありません。
Pseudonymization: Format-preserving, prefix preservation (general).
疑似系統：フォーマット保存、プレフィックス保存（一般）。
A recently released proposal from PowerDNS, ipcipher [ipcipher1] [ipcipher2], is a simple pseudonymization technique for IPv4 and IPv6 addresses. IPv6 addresses are encrypted directly with AES-128 using a key (which may be derived from a passphrase). IPv4 addresses are similarly encrypted, but using a recently proposed encryption [ipcrypt] suitable for 32-bit block lengths. However, the author of ipcrypt has since indicated [ipcrypt-analysis] that it has low security, and further analysis has revealed it is vulnerable to attack.
最近リリースされたPowerDNS、IPCipher [ipcipher1] [ipcipher2]からの最近リリースされた提案は、IPv4およびIPv6アドレスのための簡単な疑似系統法です。IPv6アドレスは、キーを使用してAES-128で直接暗号化されます（パスフレーズから派生する可能性があります）。IPv4アドレスは同様に暗号化されていますが、最近提案された暗号化[IPCrypt]は32ビットブロック長に適しています。ただし、IPCryptの作者は、それ以来、セキュリティが低く、さらなる分析が攻撃に対して脆弱であることが明らかになった。
Pseudonymization: Format-preserving, cryptographic permutation.
擬似系統：フォーマット保存、暗号化順列。
van Rijswijk-Deij et al. have recently described work using Bloom Filters [Bloom-filter] to categorize query traffic and record the traffic as the state of multiple filters. The goal of this work is to allow operators to identify so-called Indicators of Compromise (IOCs) originating from specific subnets without storing information about, or being able to monitor, the DNS queries of an individual user. By using a Bloom Filter, it is possible to determine with a high probability if, for example, a particular query was made, but the set of queries made cannot be recovered from the filter. Similarly, by mixing queries from a sufficient number of users in a single filter, it becomes practically impossible to determine if a particular user performed a particular query. Large numbers of queries can be tracked in a memory-efficient way. As filter status is stored, this approach cannot be used to regenerate traffic and so cannot be used with tools used to process live traffic.
van Rijswijk-deij et al。照会トラフィックを分類し、複数のフィルターの状態としてトラフィックを記録するために、ブルームフィルター[ブルームフィルター]を使用して作業を説明しました。この作業の目的は、個々のユーザーのDNSクエリについての情報を格納する、または監視することができずに、オペレータが特定のサブネットから発信されている、または特定のサブネットから発生する、いわゆる競合の指標を特定できるようにすることです。ブルームフィルタを使用することによって、たとえば特定のクエリが行われたが、作られた一連のクエリをフィルタから回復することができない場合、高い確率で決定することが可能である。同様に、単一のフィルタ内の十分な数のユーザからクエリを混在させることによって、特定のユーザが特定のクエリを実行したかどうかを判断することは事実上不可能になる。多数のクエリは、メモリ効率の良い方法で追跡できます。フィルタステータスが格納されると、このアプローチを使用してトラフィックを再生成することはできませんので、ライブトラフィックの処理に使用されるツールでは使用できません。
Anonymized: Generalization.
匿名化：一般化
A tabular comparison of policy and privacy statements from various DNS privacy service operators based loosely on the proposed RPS structure can be found at [policy-comparison]. The analysis is based on the data available in December 2019.
提案されたRPS構造に基づく様々なDNSプライバシーサービス事業者からのポリシーとプライバシーステートメントの表形式比較は、[ポリシー比較]で見つけることができます。分析は2019年12月に利用可能なデータに基づいています。
We note that the existing policies vary widely in style, content, and detail, and it is not uncommon for the full text for a given operator to equate to more than 10 pages (A4 size) of text in a moderate-sized font. It is a nontrivial task today for a user to extract a meaningful overview of the different services on offer.
既存のポリシーはスタイル、コンテンツ、および詳細に広く異なり、特定のオペレータの全文が中程度のサイズのフォント内のテキストの10ページ（A4サイズ）に等しくなることは珍しくありません。ユーザーがオファーのさまざまなサービスの有意義な概要を抽出するのは、今日の非通のタスクです。
It is also noted that Mozilla has published a DoH resolver policy [DoH-resolver-policy] that describes the minimum set of policy requirements that a party must satisfy to be considered as a potential partner for Mozilla's Trusted Recursive Resolver (TRR) program.
また、Mozillaは、当事者がMozillaの信頼できる再帰リゾルバ（TRR）プログラムの潜在的なパートナーとして考慮されることを満たさなければならないという最低限のポリシー要件を説明するDOHリゾルバポリシー[DOH - Resolver-Policy]を発行したことにも注意されています。
The following example RPS is very loosely based on some elements of published privacy statements for some public resolvers, with additional fields populated to illustrate what the full contents of an RPS might look like. This should not be interpreted as
次のRPSの例は、いくつかのパブリックリゾルバの公開されたプライバシーステートメントのいくつかの要素に非常に緩やかに基づいています。これはASに解釈されるべきではありません
* having been reviewed or approved by any operator in any way
* 何らかの方法で任意のオペレータによってレビューまたは承認された
* having any legal standing or validity at all
* すべての法的地位や妥当性を持つ
* being complete or exhaustive
* 完全または徹底的に
This is a purely hypothetical example of an RPS to outline example contents -- in this case, for a public resolver operator providing a basic DNS Privacy service via one IP address and one DoH URI with security-based filtering. It does aim to meet minimal compliance as specified in Section 5.
これはRPSの純粋な仮想的な例であり、一例の内容を概説するためのRPSの例です。セクション5で指定されているように、最小限のコンプライアンスを満たすことを目的としています。
1. Treatment of IP addresses. Many nations classify IP addresses as personal data, and we take a conservative approach in treating IP addresses as personal data in all jurisdictions in which our systems reside.
1. IPアドレスの扱い多くの国が個人データとしてIPアドレスを分類し、私たちのシステムが存在するすべての管轄区域でIPアドレスを個人データとして扱う際の保守的なアプローチを取ります。
2. Data collection and sharing.
2. データ収集と共有
a. IP addresses. Our normal course of data management does not have any IP address information or other personal data logged to disk or transmitted out of the location in which the query was received. We may aggregate certain counters to larger network block levels for statistical collection purposes, but those counters do not maintain specific IP address data, nor is the format or model of data stored capable of being reverse-engineered to ascertain what specific IP addresses made what queries.
a. IPアドレス当社の通常のデータ管理には、ディスクに記録されているIPアドレス情報またはその他の個人データが含まれていないか、クエリが受信された場所から送信されません。特定のカウンタを統計的な収集目的でより大きなネットワークブロックレベルに集約することができますが、これらのカウンタは特定のIPアドレスデータを維持していません。。
b. Data collected in logs. We do keep some generalized location information (at the city / metropolitan-area level) so that we can conduct debugging and analyze abuse phenomena. We also use the collected information for the creation and sharing of telemetry (timestamp, geolocation, number of hits, first seen, last seen) for contributors, public publishing of general statistics of system use (protections, threat types, counts, etc.). When you use our DNS services, here is the full list of items that are included in our logs:
b. ログで収集されたデータ。私達はデバッグを行い、乱用現象を分析することができるように、いくつかの一般化された位置情報を（市/首都圏）に保管しています。また、遠隔測定の作成と共有のために収集された情報（タイムスタンプ、地理位置、ヒット数、最後に見られた、最後に見た、最後に見た）、システム使用の一般統計の公開（保護、脅威タイプ、カウントなど）。あなたが私たちのDNSサービスを使うとき、ここに私たちのログに含まれているアイテムの全リストがあります：
* Requested domain name -- e.g., example.net
* 要求されたドメイン名 - 例えば、example.net
* Record type of requested domain -- e.g., A, AAAA, NS, MX, TXT, etc.
* 要求されたドメインの記録タイプ - 例えば、A、AAAA、NS、MX、TXTなど
* Transport protocol on which the request arrived -- i.e., UDP, TCP, DoT, DoH
* リクエストが到着した輸送プロトコル - すなわち、UDP、TCP、ドット、DOH
* Origin IP general geolocation information -- i.e., geocode, region ID, city ID, and metro code
* 原点IP一般地理化情報 - すなわち、ジオコード、地域ID、市ID、およびメトロコード
* IP protocol version -- IPv4 or IPv6
* IPプロトコルバージョン - IPv4またはIPv6
* Response code sent -- e.g., SUCCESS, SERVFAIL, NXDOMAIN, etc.
* 応答コードが送信されました - 例えば、成功、SERVFAIL、NXDOMAINなど
* Absolute arrival time using a precision in ms
* MSの精度を使用した絶対到着時間
* Name of the specific instance that processed this request
* このリクエストを処理した特定のインスタンスの名前
* IP address of the specific instance to which this request was addressed (no relation to the requestor's IP address)
* この要求が解決された特定のインスタンスのIPアドレス（リクエスタのIPアドレスとは無関係）
We may keep the following data as summary information, including all the above EXCEPT for data about the DNS record requested:
要求されたDNSレコードに関するデータを除いて、上記のすべてを含む要約情報として、以下のデータを維持することがあります。
* Currently advertised BGP-summarized IP prefix/netmask of apparent client origin
* 現在宣伝されているBGP要約IPプレフィックス/希望のクライアントの起点のネットマスク
* Autonomous system number (BGP ASN) of apparent client origin
* 見かけの顧客起源の自律システム番号（BGP ASN）
All the above data may be kept in full or partial form in permanent archives.
上記のすべてのデータは、恒久的なアーカイブの全文または部分的な形式で保持される可能性があります。
c. Sharing of data. Except as described in this document, we do not intentionally share, sell, or rent individual personal information associated with the requestor (i.e., source IP address or any other information that can positively identify the client using our infrastructure) with anyone without your consent. We generate and share high-level anonymized aggregate statistics, including threat metrics on threat type, geolocation, and if available, sector, as well as other vertical metrics, including performance metrics on our DNS Services (i.e., number of threats blocked, infrastructure uptime) when available with our Threat Intelligence (TI) partners, academic researchers, or the public. Our DNS services share anonymized data on specific domains queried (records such as domain, timestamp, geolocation, number of hits, first seen, last seen) with our Threat Intelligence partners. Our DNS service also builds, stores, and may share certain DNS data streams which store high level information about domain resolved, query types, result codes, and timestamp. These streams do not contain the IP address information of the requestor and cannot be correlated to IP address or other personal data. We do not and never will share any of the requestor's data with marketers, nor will we use this data for demographic analysis.
c. データの共有この文書に記載されている場合を除き、私たちは、要求者に関連した個々の個人情報（すなわち、私達のインフラストラクチャを使用してクライアントを積極的に識別できる他の情報）に関連した個々の個人情報を、あなたの同意なしに誰かと一緒に共有、販売、または賃貸することはできません。脅威タイプ、地理化、および利用可能な場合は、脅威のメトリック、および利用可能な場合は、DNSサービスに関するパフォーマンスメトリックを含むその他の垂直メトリクス（すなわち、ブロックされた脅威の数、インフラストラクチャの稼働時間数）など、高レベルの匿名化集計統計を生成し共有します。脅威情報（TI）パートナー、学術研究者、または一般の人々で利用可能な場合。私たちのDNSサービスは、Queryed（ドメイン、タイムスタンプ、地理位置、ヒット数、最初に見た、最後に見た、最後に見た、最後に見た、最後に見た）に関する特定のドメインに関する匿名化データを共有しています。私たちのDNSサービスはまた、ドメイン解決、クエリタイプ、結果コード、およびタイムスタンプに関する高レベルの情報を格納する特定のDNSデータストリームを構築、保存して共有することもできます。これらのストリームには、要求元のIPアドレス情報が含まれず、IPアドレスまたは他の個人データと相関させることはできません。私たちは、マーケティング担当者との依頼者のデータを共有することもなく、このデータを人口統計解析に使用することもできません。
3. Exceptions. There are exceptions to this storage model: In the event of actions or observed behaviors that we deem malicious or anomalous, we may utilize more detailed logging to collect more specific IP address data in the process of normal network defense and mitigation. This collection and transmission off-site will be limited to IP addresses that we determine are involved in the event.
3. 例外このストレージモデルに例外があります。このコレクションおよび送信オフサイトは、イベントに関与していることを判断するIPアドレスに制限されます。
4. Associated entities. Details of our Threat Intelligence partners can be found at our website page (insert link).
4. 関連エンティティ。当社の脅威Intelligenceパートナーの詳細は、当社のWebサイトページ（インサートリンク）にあります。
5. Correlation of Data. We do not correlate or combine information from our logs with any personal information that you have provided us for other services, or with your specific IP address.
5. データの相関私たちは、私たちのログからの情報を相関または組み合わせていません。
6. Result filtering.
6. 結果フィルタリング
a. Filtering. We utilize cyber-threat intelligence about malicious domains from a variety of public and private sources and block access to those malicious domains when your system attempts to contact them. An NXDOMAIN is returned for blocked sites.
a. フィルタリング。システムに連絡しようとすると、さまざまなパブリックおよびプライベートソースから悪意のあるドメインについてのサイバー脅威の知性を活用してください。ブロックされたサイトにはNXDomainが返されます。
i. Censorship. We will not provide a censoring component and will limit our actions solely to the blocking of malicious domains around phishing, malware, and exploit-kit domains.
i. 検閲。我々は検閲要素を提供しないであろう、フィッシング、マルウェア、およびエクスプロイトキットドメインの周りの悪意のあるドメインのブロッキングにのみ私たちの行動を制限します。
ii. Accidental blocking. We implement allowlisting algorithms to make sure legitimate domains are not blocked by accident. However, in the rare case of blocking a legitimate domain, we work with the users to quickly allowlist that domain. Please use our support form (insert link) if you believe we are blocking a domain in error.
ii。偶然のブロッキング偶発的なドメインが偶然にブロックされていないことを確認するために、許可リストリングアルゴリズムを実装します。ただし、正当なドメインをブロックすることのまれな場合は、ユーザーがそのドメインをすばやく許可するように機能します。あなたが私たちが誤りでドメインをブロックしていると思われる場合は、サポートフォーム（挿入リンク）を使用してください。
1. Deviations from Policy. None in place since (insert date).
1. ポリシーからの逸脱それ以来の位置にはありません（挿入日）。
2. Client-facing capabilities.
2. クライアントに直面する機能。
a. We offer UDP and TCP DNS on port 53 on (insert IP address)
a. UDPとTCP DNSをポート53に提供します（IPアドレスを挿入）
b. We offer DNS over TLS as specified in RFC 7858 on (insert IP address). It is available on port 853 and port 443. We also implement RFC 7766.
b. RFC 7858 ON（IPアドレスを挿入）で指定されているようにTLSを介してDNSを提供します。ポート853とポート443で入手できます。また、RFC 7766も実装しています。
i. The DoT authentication domain name used is (insert domain name).
i. 使用されたドット認証ドメイン名は（ドメイン名を挿入）です。
ii. We do not publish SPKI pin sets.
ii。SPKIピンセットを公開していません。
c. We offer DNS over HTTPS as specified in RFC 8484 on (insert URI template).
c. RFC 8484 ON（挿入URIテンプレート）で指定されているように、HTTPSを介してDNSを提供します。
d. Both services offer TLS 1.2 and TLS 1.3.
d. どちらのサービスもTLS 1.2とTLS 1.3を提供しています。
e. Both services pad DNS responses according to RFC 8467.
e. どちらのサービスはRFC 8467に準拠したDNS応答を埋めます。
f. Both services provide DNSSEC validation.
f. どちらのサービスもDNSSEC検証を提供します。
3. Upstream capabilities.
3. アップストリーム機能
a. Our servers implement QNAME minimization.
a. 私達のサーバーはQNAMEの最小化を実装します。
b. Our servers do not send ECS upstream.
b. 私たちのサーバーはECSを上流に送信しません。
4. Support. Support information for this service is available at (insert link).
4. サポート。このサービスのサポート情報は（Insert Link）で入手できます。
5. Data Processing. We operate as the legal entity (insert entity) registered in (insert country); as such, we operate under (insert country/region) law. Our separate statement regarding the specifics of our data processing policy, practice, and agreements can be found here (insert link).
5. 情報処理。私たちは（挿入国）に登録されている法人（挿入体）として運営しています。このように、私たちは（挿入国/地域）法の下で運営しています。私たちのデータ処理ポリシー、練習、契約の詳細に関する私達の別々の声明は、ここで見つけることができます（インサートリンク）。
Acknowledgements
謝辞
Many thanks to Amelia Andersdotter for a very thorough review of the first draft of this document and Stephen Farrell for a thorough review at Working Group Last Call and for suggesting the inclusion of an example RPS. Thanks to John Todd for discussions on this topic, and to Stéphane Bortzmeyer, Puneet Sood, and Vittorio Bertola for review. Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, Jon Reed, and Lorenzo Colitti for comments at the mic. Thanks to Loganaden Velvindron for useful updates to the text.
このドキュメントの最初のドラフトとStephen Farrellの最後の呼び出しのための徹底的なレビューのための非常に徹底的なレビューのため、そして例示的なRPSを含めることを提案するためのStephen Farrell。このトピックについての議論のためのジョン・トッド、そしてStéphaneBortzmeyer、Puleet Sod、およびVittorio Bertola、およびレビューのためのVittorio Bertolaに感謝します。Daniel Kahn Gillmor、Barry Green、Paul Hoffman、Dan York、Jon Reed、Lorenzo Colittiのコメントは、Micでコメントをおかげでおかげろ）。テキストの便利なアップデートをお手伝いします。
Sara Dickinson thanks the Open Technology Fund for a grant to support the work on this document.
SARA Dickinsonこの文書の作業をサポートするための助成金のためのオープンテクノロジーファンドをありがとう。
Contributors
貢献者
The below individuals contributed significantly to the document:
以下の個人は文書に大きく貢献しました。
John Dickinson Sinodun IT Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
John Dickinson Sinodun It Magdalen CenterオックスフォードサイエンスパークオックスフォードOX4 4GAイギリス
Jim Hague Sinodun IT Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
Jim Hague Sinodun It Magdalen CenterオックスフォードサイエンスパークオックスフォードOX4 4GAイギリス
Authors' Addresses
著者の住所
Sara Dickinson Sinodun IT Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
SARA DICKINSON SINODUN ITマグダレンセンターオックスフォードサイエンスパークオックスフォードOX4 4GAイギリス
Email: sara@sinodun.com
Benno J. Overeinder NLnet Labs Science Park 400 1098 XH Amsterdam Netherlands
Benno J. Overeinder NLNet Labs Science Park 400 1098 XHアムステルダムオランダ
Email: benno@nlnetLabs.nl
Roland M. van Rijswijk-Deij NLnet Labs Science Park 400 1098 XH Amsterdam Netherlands
Roland M. van Rijswijk-Deij Nlnet Labs Science Park 400 1098 XHアムステルダムオランダ
Email: roland@nlnetLabs.nl
Allison Mankin Salesforce.com, Inc. Salesforce Tower 415 Mission Street, 3rd Floor San Francisco, CA 94105 United States of America
Allison Mankin Salesforce.com、Inc。Salesforce Tower 415ミッションストリート、サンフランシスコ、サンフランシスコ、CA 94105アメリカ合衆国
Email: allison.mankin@gmail.com