[要約] RFC 7626は、DNSプライバシーに関する考慮事項を提供するためのものであり、DNSトラフィックのプライバシー保護に関するガイドラインを提供しています。その目的は、ユーザーのプライバシーを保護し、DNSトラフィックの監視や悪用を防止することです。
Internet Engineering Task Force (IETF) S. Bortzmeyer
Request for Comments: 7626 AFNIC
Category: Informational August 2015
ISSN: 2070-1721
DNS Privacy Considerations
DNSプライバシーに関する考慮事項
Abstract
概要
This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions.
このドキュメントでは、インターネットユーザーによるDNSの使用に関連するプライバシーの問題について説明します。現在の状況を分析することを目的としており、解決策を規定するものではありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7626.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7626で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Alleged Public Nature of DNS Data . . . . . . . . . . 4
2.2. Data in the DNS Request . . . . . . . . . . . . . . . . . 5
2.3. Cache Snooping . . . . . . . . . . . . . . . . . . . . . 6
2.4. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. In the Servers . . . . . . . . . . . . . . . . . . . . . 8
2.5.1. In the Recursive Resolvers . . . . . . . . . . . . . 8
2.5.2. In the Authoritative Name Servers . . . . . . . . . . 9
2.5.3. Rogue Servers . . . . . . . . . . . . . . . . . . . . 10
2.6. Re-identification and Other Inferences . . . . . . . . . 11
2.7. More Information . . . . . . . . . . . . . . . . . . . . 11
3. Actual "Attacks" . . . . . . . . . . . . . . . . . . . . . . 11
4. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
This document is an analysis of the DNS privacy issues, in the spirit of Section 8 of [RFC6973].
このドキュメントは、[RFC6973]のセクション8の精神に基づくDNSプライバシー問題の分析です。
The Domain Name System is specified in [RFC1034], [RFC1035], and many later RFCs, which have never been consolidated. It is one of the most important infrastructure components of the Internet and often ignored or misunderstood by Internet users (and even by many professionals). Almost every activity on the Internet starts with a DNS query (and often several). Its use has many privacy implications and this is an attempt at a comprehensive and accurate list.
ドメインネームシステムは、[RFC1034]、[RFC1035]、および統合されたことのない多くのRFCで指定されています。これは、インターネットの最も重要なインフラストラクチャコンポーネントの1つであり、インターネットユーザー（および多くの専門家）によって無視されたり誤解されたりすることがよくあります。インターネット上のほとんどすべてのアクティビティは、DNSクエリ（多くの場合、複数）で始まります。これを使用すると、プライバシーに多くの影響が出ます。これは、包括的で正確なリストを作成するための試みです。
Let us begin with a simplified reminder of how the DNS works. (See also [DNS-TERMS].) A client, the stub resolver, issues a DNS query to a server, called the recursive resolver (also called caching resolver or full resolver or recursive name server). Let's use the query "What are the AAAA records for www.example.com?" as an example. AAAA is the QTYPE (Query Type), and www.example.com is the QNAME (Query Name). (The description that follows assumes a cold cache, for instance, because the server just started.) The recursive resolver will first query the root name servers. In most cases, the root name servers will send a referral. In this example, the referral will be to the .com name servers. The resolver repeats the query to one of the .com name servers. The .com name servers, in turn, will refer to the example.com name servers. The example.com name server will then return the answer. The root name servers, the name servers of .com, and the name servers of example.com are called authoritative name servers. It is important, when analyzing the privacy issues, to remember that the question asked to all these name servers is always the original question, not a derived question. The question sent to the root name servers is "What are the AAAA records for www.example.com?", not "What are the name servers of .com?". By repeating the full question, instead of just the relevant part of the question to the next in line, the DNS provides more information than necessary to the name server.
DNSがどのように機能するかを簡単に思い出してみましょう。 （[DNS-TERMS]も参照してください。）クライアントであるスタブリゾルバーは、再帰リゾルバー（キャッシングリゾルバーまたはフルリゾルバーまたは再帰ネームサーバーとも呼ばれる）と呼ばれるサーバーにDNSクエリを発行します。 「www.example.comのAAAAレコードは何ですか？」というクエリを使用してみましょう。例として。 AAAAはQTYPE（クエリタイプ）で、www.example.comはQNAME（クエリ名）です。 （たとえば、サーバーが起動したばかりなので、以下の説明ではコールドキャッシュを想定しています。）再帰リゾルバは最初にルートネームサーバーにクエリを送信します。ほとんどの場合、ルートネームサーバーは紹介を送信します。この例では、紹介先は.comネームサーバーになります。リゾルバーは、いずれかの.comネームサーバーに対してクエリを繰り返します。 .comネームサーバーは、example.comネームサーバーを参照します。その後、example.comネームサーバーが回答を返します。ルートネームサーバー、.comのネームサーバー、およびexample.comのネームサーバーは、権威ネームサーバーと呼ばれます。プライバシーの問題を分析する場合、これらすべてのネームサーバーに尋ねられる質問は常に元の質問であり、派生した質問ではないことを覚えておくことが重要です。ルートネームサーバーに送信される質問は、「。comのネームサーバーは何ですか？」ではなく、「www.example.comのAAAAレコードは何ですか？」です。質問の関連部分だけを次の行に繰り返すのではなく、質問全体を繰り返すことにより、DNSはネームサーバーに必要以上の情報を提供します。
Because DNS relies on caching heavily, the algorithm described just above is actually a bit more complicated, and not all questions are sent to the authoritative name servers. If a few seconds later the stub resolver asks the recursive resolver, "What are the SRV records of _xmpp-server._tcp.example.com?", the recursive resolver will remember that it knows the name servers of example.com and will just query them, bypassing the root and .com. Because there is typically no caching in the stub resolver, the recursive resolver, unlike the authoritative servers, sees all the DNS traffic. (Applications, like web browsers, may have some form of caching that does not follow DNS rules, for instance, because it may ignore the TTL. So, the recursive resolver does not see all the name resolution activity.)
DNSはキャッシングに大きく依存しているため、上記で説明したアルゴリズムは実際には少し複雑であり、すべての質問が信頼できるネームサーバーに送信されるわけではありません。数秒後、スタブリゾルバが再帰リゾルバに「_xmpp-server._tcp.example.comのSRVレコードとは何ですか？」と尋ねた場合、再帰リゾルバはexample.comのネームサーバーを認識していることを記憶し、ルートと.comをバイパスしてそれらをクエリします。通常、スタブリゾルバーにはキャッシングがないため、権限のあるサーバーとは異なり、再帰リゾルバーはすべてのDNSトラフィックを認識します。 （例えば、Webブラウザーなどのアプリケーションは、TTLを無視する可能性があるため、DNSルールに従わない何らかの形式のキャッシングを備えている場合があります。そのため、再帰リゾルバーはすべての名前解決アクティビティを認識しません。）
It should be noted that DNS recursive resolvers sometimes forward requests to other recursive resolvers, typically bigger machines, with a larger and more shared cache (and the query hierarchy can be even deeper, with more than two levels of recursive resolvers). From the point of view of privacy, these forwarders are like resolvers, except that they do not see all of the requests being made (due to caching in the first resolver).
DNS再帰リゾルバは、他の再帰リゾルバ（通常はより大きなマシン）にリクエストを転送する場合があることに注意してください。これは、共有キャッシュが大きく、共有されます（再帰リゾルバが2レベルを超えると、クエリ階層がさらに深くなる場合があります）。プライバシーの観点から見ると、これらのフォワーダーはリゾルバーのようなものですが、（最初のリゾルバーでのキャッシュのために）行われているすべての要求が表示されるわけではありません。
Almost all this DNS traffic is currently sent in clear (unencrypted). There are a few cases where there is some channel encryption, for instance, in an IPsec VPN, at least between the stub resolver and the resolver.
現在、このDNSトラフィックのほとんどすべてがクリア（暗号化されていない）で送信されています。たとえば、IPsec VPNでは、少なくともスタブリゾルバとリゾルバの間にチャネル暗号化がある場合がいくつかあります。
Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp]. This has practical consequences when considering encryption of the traffic as a possible privacy technique. Some encryption solutions are only designed for TCP, not UDP.
今日、ほとんどすべてのDNSクエリはUDP [thomas-ditl-tcp]経由で送信されます。これは、トラフィックの暗号化を可能なプライバシーテクニックとして検討する場合に実際的な影響があります。一部の暗号化ソリューションは、UDPではなく、TCP専用に設計されています。
Another important point to keep in mind when analyzing the privacy issues of DNS is the fact that DNS requests received by a server are triggered by different reasons. Let's assume an eavesdropper wants to know which web page is viewed by a user. For a typical web page, there are three sorts of DNS requests being issued:
DNSのプライバシー問題を分析する際に留意すべきもう1つの重要な点は、サーバーが受信したDNS要求がさまざまな理由でトリガーされるという事実です。盗聴者が、ユーザーがどのWebページを表示しているかを知りたいとしましょう。一般的なWebページの場合、3種類のDNS要求が発行されます。
Primary request: this is the domain name in the URL that the user typed, selected from a bookmark, or chose by clicking on an hyperlink. Presumably, this is what is of interest for the eavesdropper.
プライマリリクエスト：これは、ユーザーが入力したURL、ブックマークから選択したURL、またはハイパーリンクをクリックして選択したURLのドメイン名です。おそらく、これが盗聴者にとって興味深いものです。
Secondary requests: these are the additional requests performed by the user agent (here, the web browser) without any direct involvement or knowledge of the user. For the Web, they are triggered by embedded content, Cascading Style Sheets (CSS), JavaScript code, embedded images, etc. In some cases, there can be dozens of domain names in different contexts on a single web page.
二次要求：これらは、ユーザーの直接の関与や知識なしにユーザーエージェント（ここでは、Webブラウザー）によって実行される追加の要求です。 Webの場合、埋め込みコンテンツ、カスケードスタイルシート（CSS）、JavaScriptコード、埋め込み画像などによってトリガーされます。場合によっては、1つのWebページのさまざまなコンテキストに数十のドメイン名が存在することがあります。
Tertiary requests: these are the additional requests performed by the DNS system itself. For instance, if the answer to a query is a referral to a set of name servers, and the glue records are not returned, the resolver will have to do additional requests to turn the name servers' names into IP addresses. Similarly, even if glue records are returned, a careful recursive server will do tertiary requests to verify the IP addresses of those records.
3次要求：これらは、DNSシステム自体によって実行される追加の要求です。たとえば、クエリに対する回答が一連のネームサーバーへの参照であり、グルーレコードが返されない場合、リゾルバーはネームサーバーの名前をIPアドレスに変換するために追加の要求を行う必要があります。同様に、グルーレコードが返された場合でも、慎重に再帰的なサーバーが3次要求を行って、それらのレコードのIPアドレスを確認します。
It can be noted also that, in the case of a typical web browser, more DNS requests than strictly necessary are sent, for instance, to prefetch resources that the user may query later or when autocompleting the URL in the address bar. Both are a big privacy concern since they may leak information even about non-explicit actions. For instance, just reading a local HTML page, even without selecting the hyperlinks, may trigger DNS requests.
また、通常のWebブラウザーの場合、たとえばユーザーが後でクエリする可能性があるリソースをプリフェッチしたり、アドレスバーでURLをオートコンプリートしたりするために、厳密に必要な数よりも多くのDNS要求が送信されることにも注意してください。どちらも、非明示的なアクションについても情報を漏らす可能性があるため、プライバシーに関する大きな懸念事項です。たとえば、ハイパーリンクを選択しなくても、ローカルのHTMLページを読み取るだけでDNS要求がトリガーされる場合があります。
For privacy-related terms, we will use the terminology from [RFC6973].
プライバシー関連の用語については、[RFC6973]の用語を使用します。
This document focuses mostly on the study of privacy risks for the end user (the one performing DNS requests). We consider the risks of pervasive surveillance [RFC7258] as well as risks coming from a more focused surveillance. Privacy risks for the holder of a zone (the risk that someone gets the data) are discussed in [RFC5936] and [RFC5155]. Non-privacy risks (such as cache poisoning) are out of scope.
このドキュメントでは、主にエンドユーザー（DNS要求を実行するユーザー）のプライバシーリスクの研究に焦点を当てています。広範囲にわたる監視のリスク[RFC7258]と、より焦点を絞った監視から生じるリスクを考慮します。ゾーンの所有者のプライバシーリスク（誰かがデータを取得するリスク）については、[RFC5936]と[RFC5155]で説明されています。非プライバシーリスク（キャッシュポイズニングなど）は対象外です。
It has long been claimed that "the data in the DNS is public". While this sentence makes sense for an Internet-wide lookup system, there are multiple facets to the data and metadata involved that deserve a more detailed look. First, access control lists and private namespaces notwithstanding, the DNS operates under the assumption that public-facing authoritative name servers will respond to "usual" DNS queries for any zone they are authoritative for without further authentication or authorization of the client (resolver). Due to the lack of search capabilities, only a given QNAME will reveal the resource records associated with that name (or that name's non-existence). In other words: one needs to know what to ask for, in order to receive a response. The zone transfer QTYPE [RFC5936] is often blocked or restricted to authenticated/authorized access to enforce this difference (and maybe for other reasons).
「DNSのデータは公開されている」と長い間主張されてきました。この文はインターネット全体の検索システムには意味がありますが、関連するデータとメタデータには複数の側面があり、より詳細に見る価値があります。まず、アクセス制御リストとプライベート名前空間にもかかわらず、DNSは、公に面した権威ネームサーバーが、クライアント（リゾルバ）の追加の認証または承認なしに、権威のあるすべてのゾーンに対する「通常の」DNSクエリに応答するという想定の下で動作します。検索機能がないため、特定のQNAMEだけがその名前に関連付けられているリソースレコードを明らかにします（またはその名前が存在しません）。つまり、応答を受け取るためには、何を要求するかを知る必要があります。ゾーン転送QTYPE [RFC5936]は、この違いを強制するために（場合によっては他の理由で）ブロックまたは認証/承認されたアクセスに制限されています。
Another differentiation to be considered is between the DNS data itself and a particular transaction (i.e., a DNS name lookup). DNS data and the results of a DNS query are public, within the boundaries described above, and may not have any confidentiality requirements. However, the same is not true of a single transaction or a sequence of transactions; that transaction is not / should not be public. A typical example from outside the DNS world is: the web site of Alcoholics Anonymous is public; the fact that you visit it should not be.
考慮すべきもう1つの違いは、DNSデータ自体と特定のトランザクション（つまり、DNS名のルックアップ）の間です。 DNSデータとDNSクエリの結果は、上記の境界内で公開され、機密性の要件がない場合があります。ただし、単一のトランザクションまたは一連のトランザクションには同じことが当てはまりません。そのトランザクションは公開されていないか、公開されるべきではありません。 DNSの世界の外からの典型的な例は次のとおりです。AlcoholicsAnonymousのWebサイトは公開されています。あなたがそれを訪問するという事実はすべきではありません。
The DNS request includes many fields, but two of them seem particularly relevant for the privacy issues: the QNAME and the source IP address. "source IP address" is used in a loose sense of "source IP address + maybe source port", because the port is also in the request and can be used to differentiate between several users sharing an IP address (behind a Carrier-Grade NAT (CGN), for instance [RFC6269]).
DNSリクエストには多くのフィールドが含まれていますが、そのうちの2つはQNAMEとソースIPアドレスのプライバシーの問題に特に関連しているようです。 「送信元IPアドレス」は、「送信元IPアドレス+おそらく送信元ポート」という大まかな意味で使用されます。これは、ポートもリクエストに含まれ、IPアドレスを共有する複数のユーザーを区別するために使用できるためです（キャリアグレードNATの背後） （CGN）、例えば[RFC6269]）。
The QNAME is the full name sent by the user. It gives information about what the user does ("What are the MX records of example.net?" means he probably wants to send email to someone at example.net, which may be a domain used by only a few persons and is therefore very revealing about communication relationships). Some QNAMEs are more sensitive than others. For instance, querying the A record of a well-known web statistics domain reveals very little (everybody visits web sites that use this analytics service), but querying the A record of www.verybad.example where verybad.example is the domain of an organization that some people find offensive or objectionable may create more problems for the user. Also, sometimes, the QNAME embeds the software one uses, which could be a privacy issue. For instance, _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org. There are also some BitTorrent clients that query an SRV record for _bittorrent-tracker._tcp.domain.example.
QNAMEは、ユーザーが送信したフルネームです。ユーザーが何をしているかについての情報を提供します（「example.netのMXレコードとは何ですか？」とは、おそらくexample.netの誰かにメールを送信したいことを意味します。コミュニケーション関係について明らかにする）。一部のQNAMEは他よりも機密性が高くなります。たとえば、よく知られているWeb統計ドメインのAレコードをクエリしても、明らかにならない（誰もがこの分析サービスを使用するWebサイトにアクセスする）が、www.verybad.exampleのAレコードをクエリすると、verybad.exampleは、一部の人々が不快または不快であると考える組織は、ユーザーにとってより多くの問題を引き起こす可能性があります。また、QNAMEには使用するソフトウェアが埋め込まれている場合があり、プライバシーの問題になる可能性があります。たとえば、_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org。 SRVレコードに_bittorrent-tracker._tcp.domain.exampleを照会する一部のBitTorrentクライアントもあります。
Another important thing about the privacy of the QNAME is the future usages. Today, the lack of privacy is an obstacle to putting potentially sensitive or personally identifiable data in the DNS. At the moment, your DNS traffic might reveal that you are doing email but not with whom. If your Mail User Agent (MUA) starts looking up Pretty Good Privacy (PGP) keys in the DNS [DANE-OPENPGPKEY], then privacy becomes a lot more important. And email is just an example; there would be other really interesting uses for a more privacy-friendly DNS.
QNAMEのプライバシーに関するもう1つの重要なことは、将来の使用法です。今日、プライバシーの欠如は、機密情報または個人を特定できる可能性のあるデータをDNSに配置する際の障害となっています。現時点では、DNSトラフィックにより、メールを行っているのにだれとは行っていないことがわかる場合があります。メールユーザーエージェント（MUA）がDNS [DANE-OPENPGPKEY]でPretty Good Privacy（PGP）キーの検索を開始した場合、プライバシーはより重要になります。また、メールは一例です。よりプライバシーに配慮したDNSには、他にも本当に興味深い用途があります。
For the communication between the stub resolver and the recursive resolver, the source IP address is the address of the user's machine. Therefore, all the issues and warnings about collection of IP addresses apply here. For the communication between the recursive resolver and the authoritative name servers, the source IP address has a different meaning; it does not have the same status as the source address in an HTTP connection. It is now the IP address of the recursive resolver that, in a way, "hides" the real user. However, hiding does not always work. Sometimes [CLIENT-SUBNET] is used (see its privacy analysis in [denis-edns-client-subnet]). Sometimes the end user has a personal recursive resolver on her machine. In both cases, the IP address is as sensitive as it is for HTTP [sidn-entrada].
スタブリゾルバーと再帰リゾルバー間の通信では、ソースIPアドレスはユーザーのマシンのアドレスです。したがって、IPアドレスの収集に関するすべての問題と警告がここに適用されます。再帰リゾルバと権限のあるネームサーバー間の通信では、送信元IPアドレスの意味が異なります。 HTTP接続の送信元アドレスと同じステータスではありません。ある意味で、実際のユーザーを「隠す」のは、再帰リゾルバのIPアドレスです。ただし、非表示が常に機能するとは限りません。 [CLIENT-SUBNET]が使用される場合があります（[denis-edns-client-subnet]のプライバシー分析を参照）。エンドユーザーは、自分のマシンに個人的な再帰リゾルバを持っていることがあります。どちらの場合も、IPアドレスはHTTP [sidn-entrada]の場合と同じように重要です。
A note about IP addresses: there is currently no IETF document that describes in detail all the privacy issues around IP addressing. In the meantime, the discussion here is intended to include both IPv4 and IPv6 source addresses. For a number of reasons, their assignment and utilization characteristics are different, which may have implications for details of information leakage associated with the collection of source addresses. (For example, a specific IPv6 source address seen on the public Internet is less likely than an IPv4 address to originate behind a CGN or other NAT.) However, for both IPv4 and IPv6 addresses, it's important to note that source addresses are propagated with queries and comprise metadata about the host, user, or application that originated them.
IPアドレスに関するメモ：現在、IPアドレス指定に関するすべてのプライバシー問題を詳細に説明するIETF文書はありません。それまでの間、ここでの説明はIPv4とIPv6の両方の送信元アドレスを含めることを目的としています。いくつかの理由により、それらの割り当てと使用率の特性は異なり、送信元アドレスの収集に関連する情報漏洩の詳細に影響を与える可能性があります。 （たとえば、公衆インターネット上で見られる特定のIPv6送信元アドレスは、IPv4アドレスよりもCGNまたは他のNATの背後で発生する可能性が低くなります。）ただし、IPv4アドレスとIPv6アドレスの両方について、送信元アドレスがクエリし、それらを発信したホスト、ユーザー、またはアプリケーションに関するメタデータを含みます。
The content of recursive resolvers' caches can reveal data about the clients using it (the privacy risks depend on the number of clients). This information can sometimes be examined by sending DNS queries with RD=0 to inspect cache content, particularly looking at the DNS TTLs [grangeia.snooping]. Since this also is a reconnaissance technique for subsequent cache poisoning attacks, some counter measures have already been developed and deployed.
再帰リゾルバのキャッシュの内容は、それを使用しているクライアントに関するデータを明らかにする可能性があります（プライバシーのリスクはクライアントの数に依存します）。この情報は、特にDNS TTL [grangeia.snooping]を調べて、キャッシュコンテンツを検査するためにRD = 0でDNSクエリを送信することで検査できる場合があります。これは、後続のキャッシュポイズニング攻撃に対する偵察手法でもあるため、いくつかの対策がすでに開発および導入されています。
DNS traffic can be seen by an eavesdropper like any other traffic. It is typically not encrypted. (DNSSEC, specified in [RFC4033], explicitly excludes confidentiality from its goals.) So, if an initiator starts an HTTPS communication with a recipient, while the HTTP traffic will be encrypted, the DNS exchange prior to it will not be. When other protocols will become more and more privacy-aware and secured against surveillance, the DNS may become "the weakest link" in privacy.
DNSトラフィックは、他のトラフィックと同様に盗聴者に見られる可能性があります。通常は暗号化されません。 （[RFC4033]で指定されているDNSSECでは、機密性が目標から明示的に除外されています。）したがって、開始者が受信者とHTTPS通信を開始すると、HTTPトラフィックは暗号化されますが、その前のDNS交換は暗号化されません。他のプロトコルがますますプライバシーを意識し、監視から保護されるようになると、DNSはプライバシーの「最も弱いリンク」になる可能性があります。
An important specificity of the DNS traffic is that it may take a different path than the communication between the initiator and the recipient. For instance, an eavesdropper may be unable to tap the wire between the initiator and the recipient but may have access to the wire going to the recursive resolver, or to the authoritative name servers.
DNSトラフィックの重要な特性は、開始者と受信者の間の通信とは異なるパスを取る可能性があることです。たとえば、盗聴者はイニシエーターと受信者の間のワイヤーをタップできないかもしれませんが、再帰リゾルバーに行くワイヤー、または権威ネームサーバーにアクセスできます。
The best place to tap, from an eavesdropper's point of view, is clearly between the stub resolvers and the recursive resolvers, because traffic is not limited by DNS caching.
盗聴者の観点からは、トラフィックはDNSキャッシングによって制限されないため、スタブリゾルバと再帰リゾルバの間が明らかに最適な場所です。
The attack surface between the stub resolver and the rest of the world can vary widely depending upon how the end user's computer is configured. By order of increasing attack surface:
スタブリゾルバーと他の世界との間の攻撃面は、エンドユーザーのコンピューターの構成方法によって大きく異なります。攻撃面の増加順に：
The recursive resolver can be on the end user's computer. In (currently) a small number of cases, individuals may choose to operate their own DNS resolver on their local machine. In this case, the attack surface for the connection between the stub resolver and the caching resolver is limited to that single machine.
再帰リゾルバは、エンドユーザーのコンピュータに配置できます。 （現在）少数のケースでは、個人がローカルマシンで独自のDNSリゾルバーを操作することを選択する場合があります。この場合、スタブリゾルバーとキャッシングリゾルバー間の接続の攻撃面は、その単一のマシンに限定されます。
The recursive resolver may be at the local network edge. For many/most enterprise networks and for some residential users, the caching resolver may exist on a server at the edge of the local network. In this case, the attack surface is the local network. Note that in large enterprise networks, the DNS resolver may not be located at the edge of the local network but rather at the edge of the overall enterprise network. In this case, the enterprise network could be thought of as similar to the Internet Access Provider (IAP) network referenced below.
再帰リゾルバはローカルネットワークエッジにある場合があります。多くの/ほとんどのエンタープライズネットワークおよび一部の住宅ユーザーの場合、ローカルネットワークのエッジにあるサーバーにキャッシュリゾルバーが存在する場合があります。この場合、攻撃面はローカルネットワークです。大規模なエンタープライズネットワークでは、DNSリゾルバーはローカルネットワークのエッジではなく、エンタープライズネットワーク全体のエッジにある場合があることに注意してください。この場合、エンタープライズネットワークは、以下で参照するインターネットアクセスプロバイダー（IAP）ネットワークと同様に考えることができます。
The recursive resolver can be in the IAP premises. For most residential users and potentially other networks, the typical case is for the end user's computer to be configured (typically automatically through DHCP) with the addresses of the DNS recursive resolvers at the IAP. The attack surface for on-the- wire attacks is therefore from the end-user system across the local network and across the IAP network to the IAP's recursive resolvers.
再帰リゾルバは、IAP構内に置くことができます。ほとんどの住宅ユーザーおよび潜在的に他のネットワークの場合、典型的なケースは、エンドユーザーのコンピューターがIAPのDNS再帰リゾルバーのアドレスを使用して（通常はDHCPを介して自動的に）構成されることです。したがって、オンザワイヤ攻撃の攻撃面は、ローカルネットワーク全体およびIAPネットワーク全体のエンドユーザーシステムから、IAPの再帰リゾルバまでです。
The recursive resolver can be a public DNS service. Some machines may be configured to use public DNS resolvers such as those operated today by Google Public DNS or OpenDNS. The end user may have configured their machine to use these DNS recursive resolvers themselves -- or their IAP may have chosen to use the public DNS resolvers rather than operating their own resolvers. In this case, the attack surface is the entire public Internet between the end user's connection and the public DNS service.
再帰リゾルバは、パブリックDNSサービスにすることができます。一部のマシンは、GoogleパブリックDNSまたはOpenDNSによって現在操作されているようなパブリックDNSリゾルバーを使用するように構成されている場合があります。エンドユーザーは、これらのDNS再帰リゾルバー自体を使用するようにマシンを構成している可能性があります。あるいは、IAPが独自のリゾルバーを操作するのではなく、パブリックDNSリゾルバーを使用することを選択している可能性があります。この場合、攻撃面は、エンドユーザーの接続とパブリックDNSサービスの間のパブリックインターネット全体です。
Using the terminology of [RFC6973], the DNS servers (recursive resolvers and authoritative servers) are enablers: they facilitate communication between an initiator and a recipient without being directly in the communications path. As a result, they are often forgotten in risk analysis. But, to quote again [RFC6973], "Although [...] enablers may not generally be considered as attackers, they may all pose privacy threats (depending on the context) because they are able to observe, collect, process, and transfer privacy-relevant data." In [RFC6973] parlance, enablers become observers when they start collecting data.
[RFC6973]の用語を使用すると、DNSサーバー（再帰リゾルバーと権限のあるサーバー）はイネーブラーであり、通信パスに直接接続することなく、イニシエーターと受信者間の通信を容易にします。その結果、リスク分析で忘れられることがよくあります。しかし、もう一度引用すると[RFC6973]、「イネーブラーは一般に攻撃者とは見なされないかもしれませんが、観察、収集、処理、および転送できるため、それらはすべてプライバシーの脅威をもたらす可能性があります（コンテキストによって異なります）。プライバシー関連データ。」 [RFC6973]用語では、イネーブラーはデータの収集を開始するとオブザーバーになります。
Many programs exist to collect and analyze DNS data at the servers -- from the "query log" of some programs like BIND to tcpdump and more sophisticated programs like PacketQ [packetq] [packetq-list] and DNSmezzo [dnsmezzo]. The organization managing the DNS server can use this data itself, or it can be part of a surveillance program like PRISM [prism] and pass data to an outside observer.
サーバーでDNSデータを収集して分析するための多くのプログラムが存在します。BINDなどの一部のプログラムの「クエリログ」からtcpdumpまで、さらにはPacketQ [packetq] [packetq-list]やDNSmezzo [dnsmezzo]などのより高度なプログラムもあります。 DNSサーバーを管理する組織は、このデータ自体を使用することも、PRISM [プリズム]などの監視プログラムの一部としてデータを外部の監視者に渡すこともできます。
Sometimes, this data is kept for a long time and/or distributed to third parties for research purposes [ditl] [day-at-root], security analysis, or surveillance tasks. These uses are sometimes under some sort of contract, with various limitations, for instance, on redistribution, given the sensitive nature of the data. Also, there are observation points in the network that gather DNS data and then make it accessible to third parties for research or security purposes ("passive DNS" [passive-dns]).
場合によっては、このデータは長期間保持されるか、研究目的[ditl] [day-at-root]、セキュリティ分析、または監視タスクのためにサードパーティに配布されます。これらの用途は、ある種の契約の下にある場合があり、データの機密性を考慮して、再配布などのさまざまな制限があります。また、ネットワークにはDNSデータを収集し、調査やセキュリティの目的で第三者がアクセスできるようにする観測ポイントがあります（「パッシブDNS」[passive-dns]）。
Recursive Resolvers see all the traffic since there is typically no caching before them. To summarize: your recursive resolver knows a lot about you. The resolver of a large IAP, or a large public resolver, can collect data from many users. You may get an idea of the data collected by reading the privacy policy of a big public resolver, e.g., <https://developers.google.com/speed/public-dns/ privacy>.
再帰リゾルバは通常、その前にキャッシュがないため、すべてのトラフィックを認識します。要約すると、再帰リゾルバはあなたのことをよく知っています。大規模なIAPのリゾルバー、または大規模なパブリックリゾルバーは、多くのユーザーからデータを収集できます。大きなパブリックリゾルバのプライバシーポリシー（<https://developers.google.com/speed/public-dns/privacy>など）を読むことで、収集されたデータのアイデアを得ることができます。
Unlike what happens for recursive resolvers, observation capabilities of authoritative name servers are limited by caching; they see only the requests for which the answer was not in the cache. For aggregated statistics ("What is the percentage of LOC queries?"), this is sufficient, but it prevents an observer from seeing everything. Still, the authoritative name servers see a part of the traffic, and this subset may be sufficient to violate some privacy expectations.
再帰リゾルバで起こることとは異なり、権威ネームサーバーの監視機能はキャッシングによって制限されます。回答がキャッシュになかったリクエストのみが表示されます。集約された統計（「LOCクエリのパーセンテージは？」）の場合、これで十分ですが、オブザーバーがすべてを見ることができなくなります。それでも、権威のあるネームサーバーはトラフィックの一部を確認しますが、このサブセットはプライバシーの期待に違反するのに十分な場合があります。
Also, the end user typically has some legal/contractual link with the recursive resolver (he has chosen the IAP, or he has chosen to use a given public resolver), while having no control and perhaps no awareness of the role of the authoritative name servers and their observation abilities.
また、エンドユーザーは通常、再帰リゾルバとの法的/契約上のリンクを持ち（IAPを選択したか、特定のパブリックリゾルバを使用することを選択しました）、権限のある名前の役割を制御および認識していない可能性があります。サーバーとその観測能力。
As noted before, using a local resolver or a resolver close to the machine decreases the attack surface for an on-the-wire eavesdropper. But it may decrease privacy against an observer located on an authoritative name server. This authoritative name server will see the IP address of the end client instead of the address of a big recursive resolver shared by many users.
前述のように、ローカルリゾルバーまたはマシンの近くにあるリゾルバーを使用すると、ネットワーク上の盗聴者に対する攻撃面が減少します。ただし、権限のあるネームサーバーにいるオブザーバーに対するプライバシーが低下する可能性があります。この権威ネームサーバーは、多くのユーザーが共有する大きな再帰リゾルバのアドレスではなく、エンドクライアントのIPアドレスを参照します。
This "protection", when using a large resolver with many clients, is no longer present if [CLIENT-SUBNET] is used because, in this case, the authoritative name server sees the original IP address (or prefix, depending on the setup).
この「保護」は、多数のクライアントで大規模なリゾルバーを使用する場合、[CLIENT-SUBNET]を使用すると存在しなくなります。これは、この場合、権威ネームサーバーが元のIPアドレス（または設定によってはプレフィックス）を認識するためです。 。
As of today, all the instances of one root name server, L-root, receive together around 50,000 queries per second. While most of it is "junk" (errors on the Top-Level Domain (TLD) name), it gives an idea of the amount of big data that pours into name servers. (And even "junk" can leak information; for instance, if there is a typing error in the TLD, the user will send data to a TLD that is not the usual one.)
現在、1つのルートネームサーバーであるL-rootのすべてのインスタンスは、1秒あたり約50,000のクエリを受信しています。その大部分は「ジャンク」（トップレベルドメイン（TLD）名のエラー）ですが、ネームサーバーに注がれるビッグデータの量がわかります。 （そして「ジャンク」であっても情報が漏洩する可能性があります。たとえば、TLDに入力エラーがある場合、ユーザーは通常とは異なるTLDにデータを送信します。）
Many domains, including TLDs, are partially hosted by third-party servers, sometimes in a different country. The contracts between the domain manager and these servers may or may not take privacy into account. Whatever the contract, the third-party hoster may be honest or not but, in any case, it will have to follow its local laws. So, requests to a given ccTLD may go to servers managed by organizations outside of the ccTLD's country. End users may not anticipate that, when doing a security analysis.
TLDを含む多くのドメインは、時には別の国にあるサードパーティのサーバーによって部分的にホストされています。ドメインマネージャとこれらのサーバー間の契約では、プライバシーが考慮される場合と考慮されない場合があります。契約が何であれ、サードパーティのホスティング業者は正直であるかどうかは不明ですが、いずれにしても、現地の法律に従う必要があります。したがって、特定のccTLDへのリクエストは、ccTLDの国外の組織によって管理されるサーバーに送信される可能性があります。エンドユーザーは、セキュリティ分析を行うときにそれを予期しない場合があります。
Also, it seems (see the survey described in [aeris-dns]) that there is a strong concentration of authoritative name servers among "popular" domains (such as the Alexa Top N list). For instance, among the Alexa Top 100K, one DNS provider hosts today 10% of the domains. The ten most important DNS providers host together one third of the domains. With the control (or the ability to sniff the traffic) of a few name servers, you can gather a lot of information.
また、「人気のある」ドメイン（AlexaのトップNリストなど）の中に権威のあるネームサーバーが集中しているようです（[aeris-dns]で説明されている調査を参照）。たとえば、Alexa Top 100Kのうち、1つのDNSプロバイダーが今日ドメインの10％をホストしています。最も重要な10のDNSプロバイダーは、ドメインの3分の1をホストします。いくつかのネームサーバーの制御（またはトラフィックを傍受する機能）を使用すると、多くの情報を収集できます。
The previous paragraphs discussed DNS privacy, assuming that all the traffic was directed to the intended servers and that the potential attacker was purely passive. But, in reality, we can have active attackers redirecting the traffic, not to change it but just to observe it.
前の段落では、すべてのトラフィックが目的のサーバーに送信され、潜在的な攻撃者が純粋に受動的であると仮定して、DNSプライバシーについて説明しました。しかし実際には、トラフィックをリダイレクトするのではなく、変更するだけでなく、監視するだけのアクティブな攻撃者がいる可能性があります。
For instance, a rogue DHCP server, or a trusted DHCP server that has had its configuration altered by malicious parties, can direct you to a rogue recursive resolver. Most of the time, it seems to be done to divert traffic by providing lies for some domain names. But it could be used just to capture the traffic and gather information about you. Other attacks, besides using DHCP, are possible. The traffic from a DNS client to a DNS server can be intercepted along its way from originator to intended source, for instance, by transparent DNS proxies in the network that will divert the traffic intended for a legitimate DNS server. This rogue server can masquerade as the intended server and respond with data to the client. (Rogue servers that inject malicious data are possible, but it is a separate problem not relevant to privacy.) A rogue server may respond correctly for a long period of time, thereby foregoing detection. This may be done for what could be claimed to be good reasons, such as optimization or caching, but it leads to a reduction of privacy compared to if there was no attacker present. Also, malware like DNSchanger [dnschanger] can change the recursive resolver in the machine's configuration, or the routing itself can be subverted (for instance, [ripe-atlas-turkey]).
たとえば、不正なDHCPサーバー、または悪意のあるユーザーによって構成が変更された信頼されたDHCPサーバーは、不正な再帰リゾルバに誘導する可能性があります。ほとんどの場合、一部のドメイン名に嘘をつけることでトラフィックをそらすために行われているようです。ただし、トラフィックをキャプチャして、ユーザーに関する情報を収集するためだけに使用できます。 DHCPを使用する以外の攻撃も可能です。 DNSクライアントからDNSサーバーへのトラフィックは、発信元から目的のソースへの途中で傍受される可能性があります。たとえば、正当なDNSサーバー向けのトラフィックを迂回するネットワーク内の透過DNSプロキシによって、このようなトラフィックが傍受される可能性があります。この不正なサーバーは、目的のサーバーになりすまし、クライアントにデータで応答できます。 （悪意のあるデータを挿入する不正サーバーは可能ですが、プライバシーとは関係のない別の問題です。）不正サーバーは長期間正しく応答し、それによって検出を妨害する可能性があります。これは、最適化やキャッシングなどの正当な理由であると主張される可能性がある場合に行われますが、攻撃者がいない場合と比較してプライバシーが低下します。また、DNSchanger [dnschanger]のようなマルウェアは、マシンの構成で再帰リゾルバを変更したり、ルーティング自体を破壊したりする可能性があります（たとえば、[ripe-atlas-turkey]）。
A practical consequence of this section is that solutions for DNS privacy may have to address authentication of the server, not just passive sniffing.
このセクションの実際の結果は、DNSプライバシーのソリューションでは、パッシブスニッフィングだけでなく、サーバーの認証に対処する必要がある場合があることです。
An observer has access not only to the data he/she directly collects but also to the results of various inferences about this data.
オブザーバーは、直接収集したデータだけでなく、このデータに関するさまざまな推論の結果にもアクセスできます。
For instance, a user can be re-identified via DNS queries. If the adversary knows a user's identity and can watch their DNS queries for a period, then that same adversary may be able to re-identify the user solely based on their pattern of DNS queries later on regardless of the location from which the user makes those queries. For example, one study [herrmann-reidentification] found that such re-identification is possible so that "73.1% of all day-to-day links were correctly established, i.e. user u was either re-identified unambiguously (1) or the classifier correctly reported that u was not present on day t+1 any more (2)." While that study related to web browsing behavior, equally characteristic patterns may be produced even in machine-to-machine communications or without a user taking specific actions, e.g., at reboot time if a characteristic set of services are accessed by the device.
たとえば、DNSクエリを使用してユーザーを再識別できます。攻撃者がユーザーのIDを知っており、一定期間DNSクエリを監視できる場合、同じ攻撃者は、ユーザーがDNSクエリを作成した場所に関係なく、後でDNSクエリのパターンのみに基づいてユーザーを再識別できる可能性があります。クエリ。たとえば、ある調査[herrmann-reidentification]は、そのような再識別が可能であり、「毎日のリンクの73.1％が正しく確立された、つまりユーザーuが明確に再識別された（1）または分類子uがt + 1日目にもう存在しないことを正しく報告しました（2）。」この調査はウェブブラウジングの動作に関連していますが、マシン間の通信でも、ユーザーが特定のアクションを実行しなくても（たとえば、再起動時にデバイスの一連の特徴的なサービスにアクセスした場合）、特徴的なパターンが生成される場合があります。
For instance, one could imagine that an intelligence agency identifies people going to a site by putting in a very long DNS name and looking for queries of a specific length. Such traffic analysis could weaken some privacy solutions.
たとえば、諜報機関が非常に長いDNS名を入力し、特定の長さのクエリを探すことで、サイトにアクセスする人々を特定すると想像できます。このようなトラフィック分析は、一部のプライバシーソリューションを弱める可能性があります。
The IAB privacy and security program also have a work in progress [RFC7624] that considers such inference-based attacks in a more general framework.
IABのプライバシーとセキュリティプログラムには、このような推論ベースの攻撃をより一般的なフレームワークで検討する進行中の作業もあります[RFC7624]。
Useful background information can also be found in [tor-leak] (about the risk of privacy leak through DNS) and in a few academic papers: [yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and [federrath-fuchs-herrmann-piosecny].
有用な背景情報は、[tor-leak]（DNSを介したプライバシーリークのリスクについて）およびいくつかの学術論文にもあります：[yanbin-tsudik]、[castillo-garcia]、[fangming-hori-sakurai]、および[federrath-fuchs-herrmann-piosecny]。
A very quick examination of DNS traffic may lead to the false conclusion that extracting the needle from the haystack is difficult. "Interesting" primary DNS requests are mixed with useless (for the eavesdropper) secondary and tertiary requests (see the terminology in Section 1). But, in this time of "big data" processing, powerful techniques now exist to get from the raw data to what the eavesdropper is actually interested in.
DNSトラフィックの非常に迅速な調査は、干し草の山から針を引き出すことが難しいという誤った結論につながる可能性があります。 「興味深い」プライマリDNSリクエストは、役に立たない（盗聴者にとって）セカンダリおよびターシャリリクエストと混在しています（セクション1の用語を参照）。しかし、この「ビッグデータ」処理の時代には、生データから盗聴者が実際に興味を持っているものに到達するための強力な手法が今存在します。
Many research papers about malware detection use DNS traffic to detect "abnormal" behavior that can be traced back to the activity of malware on infected machines. Yes, this research was done for the good, but technically it is a privacy attack and it demonstrates the power of the observation of DNS traffic. See [dns-footprint], [dagon-malware], and [darkreading-dns].
マルウェア検出に関する多くの研究論文では、DNSトラフィックを使用して、感染したマシン上のマルウェアのアクティビティにまで遡ることができる「異常な」動作を検出しています。はい、この調査は善のために行われましたが、技術的にはプライバシー攻撃であり、DNSトラフィックの監視の力を示しています。 [dns-footprint]、[dagon-malware]、および[darkreading-dns]を参照してください。
Passive DNS systems [passive-dns] allow reconstruction of the data of sometimes an entire zone. They are used for many reasons -- some good, some bad. Well-known passive DNS systems keep only the DNS responses, and not the source IP address of the client, precisely for privacy reasons. Other passive DNS systems may not be so careful. And there is still the potential problems with revealing QNAMEs.
パッシブDNSシステム[passive-dns]を使用すると、ゾーン全体のデータを再構築できます。それらは多くの理由で使用されます-いくつかは良い、いくつかは悪いです。よく知られているパッシブDNSシステムは、正確にプライバシー上の理由から、DNS応答のみを保持し、クライアントのソースIPアドレスは保持しません。他のパッシブDNSシステムはそれほど注意深くないかもしれません。また、QNAMEの公開には潜在的な問題がまだあります。
The revelations (from the Edward Snowden documents, which were leaked from the National Security Agency (NSA)) of the MORECOWBELL surveillance program [morecowbell], which uses the DNS, both passively and actively, to surreptitiously gather information about the users, is another good example showing that the lack of privacy protections in the DNS is actively exploited.
ユーザーに関する情報を不正に収集するためにDNSを受動的および能動的に使用するMORECOWBELL監視プログラム[morecowbell]の啓示（国家安全保障局（NSA）からリークされたEdward Edwardの文書から） DNSのプライバシー保護の欠如が積極的に悪用されていることを示す良い例。
To our knowledge, there are no specific privacy laws for DNS data, in any country. Interpreting general privacy laws like [data-protection-directive] (European Union) in the context of DNS traffic data is not an easy task, and we do not know a court precedent here. See an interesting analysis in [sidn-entrada].
私たちの知る限り、どの国でも、DNSデータに関する特定のプライバシー法はありません。 [data-protection-directive]（欧州連合）などの一般的なプライバシー法をDNSトラフィックデータのコンテキストで解釈することは簡単な作業ではありません。ここで判例が判るのもわかりません。 [sidn-entrada]の興味深い分析を参照してください。
This document is entirely about security, more precisely privacy. It just lays out the problem; it does not try to set requirements (with the choices and compromises they imply), much less define solutions. Possible solutions to the issues described here are discussed in other documents (currently too many to all be mentioned); see, for instance, [QNAME-MINIMIZATION] for the minimization of data or [TLS-FOR-DNS] about encryption.
このドキュメントは完全にセキュリティ、より正確にはプライバシーについてです。それは問題を説明するだけです。要件を設定しようとするのではなく（それらが意味する選択と妥協により）、ソリューションの定義ははるかに少なくなります。ここで説明する問題の考えられる解決策は、他のドキュメントで説明されています（現在のところ、すべてを説明するには多すぎます）。たとえば、データの最小化については[QNAME-MINIMIZATION]を、暗号化については[TLS-FOR-DNS]を参照してください。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[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, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[aeris-dns] Vinot, N., "Vie privee: et le DNS alors?", (In French), 2015, <https://blog.imirhil.fr/vie-privee-et-le-dns-alors.html>.
[aeris-dns] Vinot、N。、「Vie privee：et le DNS then？」、（フランス語）、2015、<https://blog.imirhil.fr/vie-privee-et-le-dns-alors .html>。
[castillo-garcia] Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous Resolution of DNS Queries", 2008, <http://deic.uab.es/~joaquin/papers/is08.pdf>.
[castillo-garcia] Castillo-Perez、S。およびJ. Garcia-Alfaro、「Anonymous Resolution of DNS Queries」、2008、<http://deic.uab.es/~joaquin/papers/is08.pdf>。
[CLIENT-SUBNET] Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", Work in Progress, draft-ietf-dnsop-edns-client-subnet-02, July 2015.
[クライアントサブネット] Contavalli、C.、Gaast、W.、Lawrence、D。、およびW. Kumari、「DNSクエリのクライアントサブネット」、作業中、draft-ietf-dnsop-edns-client-subnet-02 、2015年7月。
[dagon-malware] Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a Malicious Resolution Authority", ISC/OARC Workshop, 2007, <https://www.dns-oarc.net/files/workshop-2007/ Dagon-Resolution-corruption.pdf>.
[dagon-malware] Dagon、D。、「破損したDNS解決パス：悪意のある解決機関の台頭」、ISC / OARCワークショップ、2007年、<https://www.dns-oarc.net/files/workshop-2007 / Dagon-Resolution-corruption.pdf>。
[DANE-OPENPGPKEY] Wouters, P., "Using DANE to Associate OpenPGP public keys with email addresses", Work in Progress, draft-ietf-dane-openpgpkey-03, April 2015.
[DANE-OPENPGPKEY] Wouters、P。、「DANEを使用してOpenPGP公開鍵を電子メールアドレスに関連付ける」、作業中、draft-ietf-dane-openpgpkey-03、2015年4月。
[darkreading-dns] Lemos, R., "Got Malware? Three Signs Revealed In DNS Traffic", InformationWeek Dark Reading, May 2013, <http://www.darkreading.com/analytics/security-monitoring/ got-malware-three-signs-revealed-in-dns-traffic/d/ d-id/1139680>.
[darkreading-dns] Lemos、R。、「Got Malware？Three Signs Revealed in DNS Traffic」、InformationWeek Dark Reading、2013年5月、<http://www.darkreading.com/analytics/security-monitoring/ got-malware- three-signs-revealed-in-dns-traffic / d / d-id / 1139680>。
[data-protection-directive] European Parliament, "Directive 95/46/EC of the European Pariament and of the council on the protection of individuals with regard to the processing of personal data and on the free movement of such data", Official Journal L 281, pp. 0031 - 0050, November 1995, <http://eur-lex.europa.eu/LexUriServ/ LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>.
[データ保護指令]欧州議会、「個人データの処理およびかかるデータの自由な移動に関する個人の保護に関する欧州議会および理事会の指令95/46 / EC」、公式ジャーナルL 281、pp。0031-0050、1995年11月、<http://eur-lex.europa.eu/LexUriServ/ LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>。
[day-at-root] Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A Day at the Root of the Internet", ACM SIGCOMM Computer Communication Review, Vol. 38, Number 5, DOI 10.1145/1452335.1452341, October 2008, <http://www.sigcomm.org/sites/default/files/ccr/ papers/2008/October/1452335-1452341.pdf>.
[rootでの日] Castro、S.、Wessels、D.、Fomenkov、M。、およびK. Claffy、「A Day at the Root of the Root of the Internet」、ACM SIGCOMM Computer Communication Review、Vol。 38、番号5、DOI 10.1145 / 1452335.1452341、2008年10月、<http://www.sigcomm.org/sites/default/files/ccr/papers/2008/October/1452335-1452341.pdf>。
[denis-edns-client-subnet] Denis, F., "Security and privacy issues of edns-client-subnet", August 2013, <https://00f.net/2013/08/07/ edns-client-subnet/>.
[Dennis-Addons-Client-Subnet] Dennis、F。、「Addons-Client-Subnetのセキュリティとプライバシーの問題」、2013年8月、<Http：//00f.net/2013/08/07/ Addons-Client-Subnet />。
[ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002, <http://www.caida.org/projects/ditl/>.
[ditl] CAIDA、「インターネットの1日（DITL）の1日」、2002年、<http://www.caida.org/projects/ditl/>。
[dns-footprint] Stoner, E., "DNS Footprint of Malware", OARC Workshop, October 2010, <https://www.dns-oarc.net/files/ workshop-201010/OARC-ers-20101012.pdf>.
[dns-footprint] Stoner、E。、「マルウェアのDNSフットプリント」、OARCワークショップ、2010年10月、<https://www.dns-oarc.net/files/workshop-201010/OARC-ers-20101012.pdf> 。
[DNS-TERMS] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", Work in Progress, draft-ietf-dnsop-dns-terminology-03, June 2015.
[DNS-TERMS] Hoffman、P.、Sullivan、A.、およびK. Fujiwara、「DNS Terminology」、Work in Progress、draft-ietf-dnsop-dns-terminology-03、2015年6月。
[dnschanger] Wikipedia, "DNSChanger", October 2013, <https://en.wikipedia.org/w/ index.php?title=DNSChanger&oldid=578749672>.
[dnschanger] Wikipedia、「DNSChanger」、2013年10月、<https://en.wikipedia.org/w/ index.php？title = DNSChanger＆oldid = 578749672>。
[dnsmezzo] Bortzmeyer, S., "DNSmezzo", 2009, <http://www.dnsmezzo.net/>.
[dnsmezzo] Bortzmeyer、S。、「DNSmezzo」、2009、<http://www.dnsmezzo.net/>。
[fangming-hori-sakurai] Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of Privacy Disclosure in DNS Query", 2007 International Conference on Multimedia and Ubiquitous Engineering (MUE 2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957, DOI 10.1109/MUE.2007.84, April 2007, <http://dl.acm.org/citation.cfm?id=1262690.1262986>.
[fangming-hori-sakurai] Fangming、Z.、Hori、Y.、and K. Sakurai、 "Analysis of Privacy Disclosure in DNS Query"、2007 International Conference on Multimedia and Ubiquitous Engineering（MUE 2007）、Seoul、Korea、ISBN ：0-7695-2777-9、pp。952-957、DOI 10.1109 / MUE.2007.84、April 2007、<http://dl.acm.org/citation.cfm?id=1262690.1262986>。
[federrath-fuchs-herrmann-piosecny] Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny, "Privacy-Preserving DNS: Analysis of Broadcast, Range Queries and Mix-based Protection Methods", Computer Security ESORICS 2011, Springer, page(s) 665-683, ISBN 978-3-642-23821-5, 2011, <https://svs.informatik.uni-hamburg.de/publications/2011/ 2011-09-14_FFHP_PrivacyPreservingDNS_ESORICS2011.pdf>.
[federrath-fuchs-herrmann-piosecny] Federrath、H.、Fuchs、K.、Herrmann、D。、およびC. Piosecny、「プライバシー保護DNS：ブロードキャストの分析、範囲クエリ、および混合ベースの保護方法」、コンピュータSecurity ESORICS 2011、Springer、ページ665-683、ISBN 978-3-642-23821-5、2011、<https://svs.informatik.uni-hamburg.de/publications/2011/2011-09- 14_FFHP_PrivacyPreservingDNS_ESORICS2011.pdf>。
[grangeia.snooping] Grangeia, L., "DNS Cache Snooping or Snooping the Cache for Fun and Profit", February 2004, <http://www.msit2005.mut.ac.th/msit_media/1_2551/nete4630/ materials/20080718130017Hc.pdf>.
[grangeia.snooping] Grangeia、L.、 "DNS Cache Snooping or Snooping for Cache for Fun and Profit"、2004年2月、<http://www.msit2005.mut.ac.th/msit_media/1_2551/nete4630/materials/ 20080718130017Hc.pdf>。
[herrmann-reidentification] Herrmann, D., Gerber, C., Banse, C., and H. Federrath, "Analyzing Characteristic Host Access Patterns for Re-Identification of Web User Sessions", DOI 10.1007/978-3-642-27937-9_10, 2012, <http://epub.uni-regensburg.de/21103/1/ Paper_PUL_nordsec_published.pdf>.
[herrmann-reidentification] Herrmann、D.、Gerber、C.、Banse、C。、およびH. Federrath、「Analyzing Characteristic Host Access Patterns for re-Identification of Web User Sessions」、DOI 10.1007 / 978-3-642- 27937-9_10、2012、<http://epub.uni-regensburg.de/21103/1/ Paper_PUL_nordsec_published.pdf>。
[morecowbell] Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, "NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January 2015, <https://gnunet.org/morecowbell>.
[morecowbell] Grothoff、C.、Wachs、M.、Ermert、M。、およびJ. Appelbaum、「NSAのMORECOWBELL：Knell for DNS」、GNUnet e.V.、2015年1月、<https://gnunet.org/morecowbell>。
[packetq] Dot SE, "PacketQ, a simple tool to make SQL-queries against PCAP-files", 2011, <https://github.com/dotse/packetq/wiki>.
[packetq] Dot SE、「PacketQ、PCAPファイルに対してSQLクエリを作成するためのシンプルなツール」、2011、<https://github.com/dotse/packetq/wiki>。
[packetq-list] PacketQ, "PacketQ Mailing List", <http://lists.iis.se/mailman/listinfo/packetq>.
[packetq-list] PacketQ、「PacketQメーリングリスト」、<http://lists.iis.se/mailman/listinfo/packetq>。
[passive-dns] Weimer, F., "Passive DNS Replication", April 2005, <http://www.enyo.de/fw/software/dnslogger/#2>.
[passive-dns] Weimer、F。、「パッシブDNSレプリケーション」、2005年4月、<http://www.enyo.de/fw/software/dnslogger/#2>。
[prism] Wikipedia, "PRISM (surveillance program)", July 2015, <https://en.wikipedia.org/w/index.php?title=PRISM_ (surveillance_program)&oldid=673789455>.
[プリズム]ウィキペディア、「PRISM（監視プログラム）」、2015年7月、<https://en.wikipedia.org/w/index.php?title=PRISM_（surveillance_program）＆oldid = 673789455>。
[QNAME-MINIMIZATION] Bortzmeyer, S., "DNS query name minimisation to improve privacy", Work in Progress, draft-ietf-dnsop-qname-minimisation-04, June 2015.
[QNAME-MINIMIZATION] Bortzmeyer、S。、「プライバシーを改善するためのDNSクエリ名の最小化」、Work in Progress、draft-ietf-dnsop-qname-minimization-04、2015年6月。
[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, <http://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月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <http://www.rfc-editor.org/info/rfc5155>.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<http： //www.rfc-editor.org/info/rfc5155>。
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, <http://www.rfc-editor.org/info/rfc5936>.
[RFC5936] Lewis、E。およびA. Hoenes、編、「DNSゾーン転送プロトコル（AXFR）」、RFC 5936、DOI 10.17487 / RFC5936、2010年6月、<http://www.rfc-editor.org/info / rfc5936>。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269] Ford、M.、Ed。、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「Issues with IP Address Sharing」、RFC 6269、DOI 10.17487 / RFC6269、2011年6月、 <http://www.rfc-editor.org/info/rfc6269>。
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/info/rfc7624>.
[RFC7624] Barnes、R.、Schneier、B.、Jennings、C.、Hardie、T.、Trammell、B.、Huitema、C。、およびD. Borkmann、「広範にわたる監視に直面した場合の機密性：脅威モデルand Problem Statement」、RFC 7624、DOI 10.17487 / RFC7624、2015年8月、<http://www.rfc-editor.org/info/rfc7624>。
[ripe-atlas-turkey] Aben, E., "A RIPE Atlas View of Internet Meddling in Turkey", March 2014, <https://labs.ripe.net/Members/emileaben/ a-ripe-atlas-view-of-internet-meddling-in-turkey>.
[ripe-atlas-turkey] Aben、E。、「トルコのインターネットMeddlingのRIPEアトラスビュー」、2014年3月、<https://labs.ripe.net/Members/emileaben/ a-ripe-atlas-view- of-internet-meddling-in-turkey>。
[sidn-entrada] Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M. Simon, "A privacy framework for 'DNS big data' applications", November 2014, <https://www.sidnlabs.nl/uploads/tx_sidnpublications/ SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>.
[sidn-entrada] Hesselman、C.、Jansen、J.、Wullink、M.、Vink、K。、およびM. Simon、「「DNSビッグデータ」アプリケーションのプライバシーフレームワーク」、2014年11月、<https：/ /www.sidnlabs.nl/uploads/tx_sidnpublications/ SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf>。
[thomas-ditl-tcp] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in Root Server DITL Data", DNS-OARC 2014 Fall Workshop, October 2014, <https://indico.dns-oarc.net/event/20/ session/2/contribution/15/material/slides/1.pdf>.
[thomas-ditl-tcp] Thomas、M。、およびD. Wessels、「Analysis of TCP Traffic in Root Server DITL Data」、DNS-OARC 2014 Fall Workshop、2014年10月、<https：//indico.dns-oarc。 net / event / 20 / session / 2 / contribution / 15 / material / slides / 1.pdf>。
[TLS-FOR-DNS] Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "TLS for DNS: Initiation and Performance Considerations", Work in Progress, draft-ietf-dprive-start-tls-for-dns-01, July 2015.
[TLS-FOR-DNS] Zi、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D.、and P. Hoffman、 "TLS for DNS：Initiation and Performance Considerations"、Work in進捗状況、draft-ietf-dprive-start-tls-for-dns-01、2015年7月。
[tor-leak] Tor, "DNS leaks in Tor", 2013, <https://www.torproject.org/docs/ faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>.
[tor-leak] Tor、「TorのDNSリーク」、2013、<https://www.torproject.org/docs/ faq.html.en＃WarningsAboutSOCKSandDNSInformationLeaks>。
[yanbin-tsudik] Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks in the Domain Name System", October 2009, <http://arxiv.org/abs/0910.2472>.
[yanbin-tsudik] Yanbin、L.およびG. Tsudik、「Total Plugging Privacy Leaks in the Domain Name System」、2009年10月、<http://arxiv.org/abs/0910.2472>。
Acknowledgments
謝辞
Thanks to Nathalie Boulvard and to the CENTR members for the original work that led to this document. Thanks to Ondrej Sury for the interesting discussions. Thanks to Mohsen Souissi and John Heidemann for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz, Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for proofreading, providing technical remarks, and making many readability improvements. Thanks to Dan York, Suzanne Woolf, Tony Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis for good written contributions. And thanks to the IESG members for the last remarks.
このドキュメントにつながったオリジナルの作業を行ったNathalie BoulvardとCENTRメンバーに感謝します。興味深い議論をしてくれたOndrej Suryに感謝します。校正についてはMohsen SouissiとJohn Heidemannに、校正については、Paul Hoffman、Matthijs Mekking、Marcos Sanz、Tim Wicinski、Francis Dupont、Allison Mankin、およびWarren Kumariに感謝します。良い貢献をしてくれたDan York、Suzanne Woolf、Tony Finch、Stephen Farrell、Peter Koch、Simon Josefsson、Frank Denisに感謝します。そして最後の発言のためのIESGメンバーに感謝します。
Author's Address
著者のアドレス
Stephane Bortzmeyer AFNIC 1, rue Stephenson Montigny-le-Bretonneux 78180 France
ステファンボルツマイヤーAFNIC 1、rue Stephenson Montigny-le-Bretonneux 78180 France
Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI: http://www.afnic.fr/