Internet Engineering Task Force (IETF)                     S. Bortzmeyer
Request for Comments: 7816                                         AFNIC
Category: Experimental                                        March 2016
ISSN: 2070-1721
        

DNS Query Name Minimisation to Improve Privacy

プライバシーを向上させるDNSクエリ名の最小化

Abstract

概要

This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.

このドキュメントでは、DNSプライバシーを改善する手法、「QNAME最小化」と呼ばれる手法について説明します。この手法では、DNSリゾルバーは元の完全なQNAMEを上流のネームサーバーに送信しません。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are 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/rfc7816.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7816で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright（c）2016 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 and Background .....................................2
   2. QNAME Minimisation ..............................................3
   3. Possible Issues .................................................4
   4. Protocol and Compatibility Discussion ...........................5
   5. Operational Considerations ......................................5
   6. Performance Considerations ......................................6
   7. On the Experimentation ..........................................6
   8. Security Considerations .........................................7
   9. References ......................................................7
      9.1. Normative References .......................................7
      9.2. Informative References .....................................8
   Appendix A. An Algorithm to Perform QNAME Minimisation .............9
   Appendix B. Alternatives  .........................................10
   Acknowledgments ...................................................11
   Author's Address ..................................................11
        

1. Introduction and Background

1. 紹介と背景

The problem statement is described in [RFC7626]. The terminology ("QNAME", "resolver", etc.) is also defined in this companion document. This specific solution is not intended to fully solve the DNS privacy problem; instead, it should be viewed as one tool amongst many.

問題の説明は[RFC7626]で説明されています。用語（「QNAME」、「リゾルバー」など）も、この関連ドキュメントで定義されています。この特定のソリューションは、DNSプライバシーの問題を完全に解決することを意図したものではありません。代わりに、それは多くの中で1つのツールと見なされるべきです。

QNAME minimisation follows the principle explained in Section 6.1 of [RFC6973]: the less data you send out, the fewer privacy problems you have.

QNAMEの最小化は、[RFC6973]のセクション6.1で説明されている原則に従います。送信するデータが少ないほど、プライバシーの問題が少なくなります。

Currently, when a resolver receives the query "What is the AAAA record for www.example.com?", it sends to the root (assuming a cold resolver, whose cache is empty) the very same question. Sending the full QNAME to the authoritative name server is a tradition, not a protocol requirement. In a conversation with the author in January 2015, Paul Mockapetris explained that this tradition comes from a desire to optimise the number of requests, when the same name server is authoritative for many zones in a given name (something that was more common in the old days, where the same name servers served .com and the root) or when the same name server is both recursive and authoritative (something that is strongly discouraged now). Whatever the merits of this choice at this time, the DNS is quite different now.

現在、リゾルバーはクエリ「www.example.comのAAAAレコードとは何ですか？」を受信すると、ルートに（キャッシュが空のコールドリゾルバーを想定して）まったく同じ質問を送信します。正式なネームサーバーに完全なQNAMEを送信することは、プロトコルの要件ではなく、伝統です。 2015年1月の作者との会話で、Paul Mockapetrisは、この伝統は要求の数を最適化したいという願望から来ていると説明しました。同じネームサーバーが特定の名前（以前はより一般的であったもの）の多くのゾーンに対して信頼できる同じ名前のサーバーが.comとルートにサービスを提供した日）、または同じ名前のサーバーが再帰的で信頼できる場合（現在は強く非推奨）。現時点でのこの選択のメリットが何であれ、DNSは今ではかなり異なります。

2. QNAME Minimisation

2. QNAMEの最小化

The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. In the example in the previous section, sending "What are the NS records for .com?" would have been sufficient (since it will be the answer from the root anyway). The rest of this section describes the recommended way to do QNAME minimisation -- the way that maximises privacy benefits (other alternatives are discussed in the appendices).

この考え方は、DNSリゾルバーから信頼できるネームサーバーに送信されるデータの量を最小限に抑えることです。前のセクションの例では、「。comのNSレコードは何ですか？」を送信します。 （とにかくルートからの答えになるので）十分だったでしょう。このセクションの残りの部分では、QNAMEの最小化を行うための推奨される方法、つまりプライバシーの利点を最大化する方法について説明します（他の代替案は付録で説明されています）。

Instead of sending the full QNAME and the original QTYPE upstream, a resolver that implements QNAME minimisation and does not already have the answer in its cache sends a request to the name server authoritative for the closest known ancestor of the original QNAME. The request is done with:

完全なQNAMEと元のQTYPEアップストリームを送信する代わりに、QNAME最小化を実装し、キャッシュにまだ回答がないリゾルバーは、元のQNAMEの最も近い既知の祖先に対して権威のあるネームサーバーにリクエストを送信します。リクエストは次のように行われます：

o the QTYPE NS

o QTYPE NS

o the QNAME that is the original QNAME, stripped to just one label more than the zone for which the server is authoritative

o 元のQNAMEであるQNAME。サーバーが権限を持つゾーンよりも1つだけ多くラベルが削除されます

For example, a resolver receives a request to resolve foo.bar.baz.example. Let's assume that it already knows that ns1.nic.example is authoritative for .example and the resolver does not know a more specific authoritative name server. It will send the query QTYPE=NS,QNAME=baz.example to ns1.nic.example.

たとえば、リゾルバはfoo.bar.baz.exampleを解決する要求を受け取ります。 ns1.nic.exampleが.exampleに対して信頼できることをすでに知っていて、リゾルバがより具体的な信頼できるネームサーバーを知らないと仮定しましょう。クエリQTYPE = NS、QNAME = baz.exampleをns1.nic.exampleに送信します。

The minimising resolver works perfectly when it knows the zone cut (zone cuts are described in Section 6 of [RFC2181]). But zone cuts do not necessarily exist at every label boundary. If we take the name www.foo.bar.example, it is possible that there is a zone cut between "foo" and "bar" but not between "bar" and "example". So, assuming that the resolver already knows the name servers of .example, when it receives the query "What is the AAAA record of www.foo.bar.example?", it does not always know where the zone cut will be. To find the zone cut, it will query the .example name servers for the NS records for bar.example. It will get a NODATA response, indicating that there is no zone cut at that point, so it has to query the .example name servers again with one more label, and so on. (Appendix A describes this algorithm in deeper detail.)

最小化リゾルバーは、ゾーンカットを認識しているときに完全に機能します（ゾーンカットについては、[RFC2181]のセクション6で説明されています）。ただし、ゾーンカットは必ずしもすべてのラベル境界に存在するわけではありません。 www.foo.bar.exampleという名前を使用すると、「foo」と「bar」の間でゾーンがあり、「bar」と「example」の間ではないゾーンが存在する可能性があります。したがって、リゾルバがすでに.exampleのネームサーバーを知っていると仮定すると、「www.foo.bar.exampleのAAAAレコードは何ですか？」というクエリを受け取ったときに、ゾーンカットがどこにあるかが常にわかるとは限りません。ゾーンカットを見つけるために、それは.exampleネームサーバーにbar.exampleのNSレコードを照会します。この時点ではゾーンカットがないことを示すNODATA応答が返されるため、.exampleのネームサーバーにもう一度ラベルを付けてクエリを実行する必要があります。 （付録Aでは、このアルゴリズムについて詳しく説明しています。）

Since the information about the zone cuts will be stored in the resolver's cache, the performance cost is probably reasonable. Section 6 discusses this performance discrepancy further.

ゾーンカットに関する情報はリゾルバーのキャッシュに格納されるため、パフォーマンスコストはおそらく妥当です。セクション6では、このパフォーマンスの不一致についてさらに説明します。

Note that DNSSEC-validating resolvers already have access to this information, since they have to know the zone cut (the DNSKEY record set is just below; the DS record set is just above).

DNSSEC検証リゾルバーはゾーンカットを知っている必要があるため、すでにこの情報にアクセスできます（DNSKEYレコードセットはすぐ下にあり、DSレコードセットはすぐ上にあります）。

3. Possible Issues

3. 考えられる問題

QNAME minimisation is legal, since the original DNS RFCs do not mandate sending the full QNAME. So, in theory, it should work without any problems. However, in practice, some problems may occur (see [Huque-QNAME-Min] for an analysis and [Huque-QNAME-storify] for an interesting discussion on this topic).

元のDNS RFCは完全なQNAMEの送信を義務付けていないため、QNAMEの最小化は合法です。したがって、理論的には、問題なく動作するはずです。ただし、実際にはいくつかの問題が発生する可能性があります（分析については[Huque-QNAME-Min]を、このトピックに関する興味深い議論については[Huque-QNAME-storify]を参照してください）。

Some broken name servers do not react properly to QTYPE=NS requests. For instance, some authoritative name servers embedded in load balancers reply properly to A queries but send REFUSED to NS queries. This behaviour is a protocol violation, and there is no need to stop improving the DNS because of such behaviour. However, QNAME minimisation may still work with such domains, since they are only leaf domains (no need to send them NS requests). Such a setup breaks more than just QNAME minimisation. It breaks negative answers, since the servers don't return the correct SOA, and it also breaks anything dependent upon NS and SOA records existing at the top of the zone.

壊れたネームサーバーの中には、QTYPE = NSリクエストに適切に反応しないものがあります。たとえば、ロードバランサーに組み込まれた一部の信頼できるネームサーバーは、Aクエリに正しく応答しますが、NSクエリにREFUSEDを送信します。この動作はプロトコル違反であり、そのような動作のためにDNSの改善を停止する必要はありません。ただし、QNAMEの最小化は、リーフドメインのみであるため（NSリクエストを送信する必要がないため）、このようなドメインでも機能します。このような設定は、QNAMEの最小化以上のものを壊します。サーバーは正しいSOAを返さないため、否定的な回答を壊し、ゾーンの上部に存在するNSおよびSOAレコードに依存するものも壊します。

Another way to deal with such incorrect name servers would be to try with QTYPE=A requests (A being chosen because it is the most common and hence a QTYPE that will always be accepted, while a QTYPE NS may ruffle the feathers of some middleboxes). Instead of querying name servers with a query "NS example.com", we could use "A _.example.com" and see if we get a referral.

このような不正なネームサーバーを処理する別の方法は、QTYPE = Aリクエストを試すことです（Aが最も一般的であり、したがって常に受け入れられるQTYPEであるので、Aが選択されますが、QTYPE NSは、いくつかのミドルボックスの羽をフリルする可能性があります）。 。 「NS example.com」というクエリでネームサーバーにクエリを実行する代わりに、「A _.example.com」を使用して、参照を取得するかどうかを確認できます。

A problem can also appear when a name server does not react properly to ENTs (Empty Non-Terminals). If ent.example.com has no resource records but foobar.ent.example.com does, then ent.example.com is an ENT. Whatever the QTYPE, a query for ent.example.com must return NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly return NXDOMAIN for ENTs. If a resolver queries only foobar.ent.example.com, everything will be OK, but if it implements QNAME minimisation, it may query ent.example.com and get an NXDOMAIN. See also Section 3 of [DNS-Res-Improve] for the other bad consequences of this bad behaviour.

ネームサーバーがENT（空の非端末）に適切に反応しない場合にも問題が発生する可能性があります。 ent.example.comにリソースレコードがなく、foobar.ent.example.comにある場合、ent.example.comはENTです。 QTYPEが何であれ、ent.example.comのクエリはNODATA（NOERROR / ANSWER：0）を返す必要があります。ただし、一部のネームサーバーは、ENTに対してNXDOMAINを誤って返します。リゾルバーがfoobar.ent.example.comのみをクエリする場合、すべてがOKですが、QNAME最小化を実装する場合、ent.example.comをクエリしてNXDOMAINを取得する場合があります。この悪い振る舞いの他の悪い結果については、[DNS-Res-Improve]のセクション3も参照してください。

A possible solution, currently implemented in Knot, is to retry with the full query when you receive an NXDOMAIN. It works, but it is not ideal for privacy.

現在Knotに実装されている可能な解決策は、NXDOMAINを受け取ったときに完全なクエリで再試行することです。動作しますが、プライバシーには理想的ではありません。

Other practices that do not conform to the DNS protocol standards may pose a problem: there is a common DNS trick used by some web hosters that also do DNS hosting that exploits the fact that the DNS protocol (pre-DNSSEC) allows certain serious misconfigurations, such as parent and child zones disagreeing on the location of a zone cut. Basically, they have a single zone with wildcards for each TLD, like:

DNSプロトコル標準に準拠していない他のプラクティスが問題を引き起こす可能性があります。一部のWebホスティング業者がDNSホスティングを行う一般的なDNSトリックがあり、DNSプロトコル（DNSSEC以前）が特定の深刻な誤設定を許可するという事実を悪用しています。親ゾーンと子ゾーンがゾーンカットの位置で一致しないなど。基本的に、次のように、TLDごとにワイルドカードを含む単一のゾーンがあります。

*.example. 60 IN A 192.0.2.6

*。例。 60 IN A 192.0.2.6

(They could just wildcard all of "*.", which would be sufficient. We don't know why they don't do it.)

（「*。」のすべてをワイルドカードにするだけで十分です。なぜそうしないのかわかりません。）

This lets them have many web-hosting customers without having to configure thousands of individual zones on their name servers. They just tell the prospective customer to point their NS records at the hoster's name servers, and the web hoster doesn't have to provision anything in order to make the customer's domain resolve. NS queries to the hoster will therefore not give the right result, which may endanger QNAME minimisation (it will be a problem for DNSSEC, too).

これにより、ネームサーバーで数千の個別ゾーンを構成する必要なく、多くのWebホスティング顧客が利用できるようになります。それらは、見込み顧客にNSレコードをホスティング業者のネームサーバーに向けるように指示するだけであり、ウェブホスティング業者は顧客のドメインを解決させるために何もプロビジョニングする必要はありません。したがって、ホスティング事業者へのNSクエリでは正しい結果が得られず、QNAMEの最小化が危険にさらされる可能性があります（DNSSECでも問題になります）。

4. Protocol and Compatibility Discussion

4. プロトコルと互換性に関する議論

QNAME minimisation is compatible with the current DNS system and therefore can easily be deployed; since it is a unilateral change to the resolver, it does not change the protocol. (Because it is a unilateral change, resolver implementers may do QNAME minimisation in slightly different ways; see the appendices for examples.)

QNAMEの最小化は現在のDNSシステムと互換性があるため、簡単に展開できます。リゾルバに対する一方的な変更であるため、プロトコルは変更されません。 （これは一方的な変更であるため、リゾルバー実装者はQNAMEの最小化をわずかに異なる方法で行う場合があります。例については付録を参照してください。）

One should note that the behaviour suggested here (minimising the amount of data sent in QNAMEs from the resolver) is NOT forbidden by Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035]. As stated in Section 1, the current method, sending the full QNAME, is not mandated by the DNS protocol.

ここで提案されている動作（リゾルバーからQNAMEで送信されるデータの量を最小限に抑える）は、[RFC1034]のセクション5.3.3または[RFC1035]のセクション7.2では禁止されていないことに注意してください。セクション1で述べたように、完全なQNAMEを送信する現在の方法は、DNSプロトコルでは必須ではありません。

One may notice that many documents that explain the DNS and that are intended for a wide audience incorrectly describe the resolution process as using QNAME minimisation (e.g., by showing a request going to the root, with just the TLD in the query). As a result, these documents may confuse readers that use them for privacy analysis.

DNSを説明し、幅広い読者を対象とした多くのドキュメントが、QNAMEの最小化を使用した解決プロセスを誤って説明していることに気づくかもしれません（たとえば、クエリにTLDのみを指定して、ルートに向かうリクエストを示すことにより）。その結果、これらのドキュメントは、プライバシー分析にそれらを使用する読者を混乱させる可能性があります。

5. Operational Considerations

5. 運用上の考慮事項

The administrators of the forwarders, and of the authoritative name servers, will get less data, which will reduce the utility of the statistics they can produce (such as the percentage of the various QTYPEs) [Kaliski-Minimum].

フォワーダーおよび信頼できるネームサーバーの管理者は、取得するデータが少なくなるため、作成できる統計（さまざまなQTYPEのパーセンテージなど）の有用性が低下します[Kaliski-Minimum]。

DNS administrators are reminded that the data on DNS requests that they store may have legal consequences, depending on your jurisdiction (check with your local lawyer).

DNS管理者は、管轄区域によっては、保存するDNS要求に関するデータに法的責任が生じる可能性があることに注意してください（最寄りの弁護士に確認してください）。

6. Performance Considerations

6. パフォーマンスに関する考慮事項

The main goal of QNAME minimisation is to improve privacy by sending less data. However, it may have other advantages. For instance, if a root name server receives a query from some resolver for A.example followed by B.example followed by C.example, the result will be three NXDOMAINs, since .example does not exist in the root zone. Under query name minimisation, the root name servers would hear only one question (for .example itself) to which they could answer NXDOMAIN, thus opening up a negative caching opportunity in which the full resolver could know a priori that neither B.example nor C.example could exist. Thus, in this common case the total number of upstream queries under QNAME minimisation would be counterintuitively less than the number of queries under the traditional iteration (as described in the DNS standard).

QNAMEの最小化の主な目的は、送信するデータを少なくしてプライバシーを向上させることです。ただし、他の利点があります。たとえば、ルートネームサーバーがリゾルバからA.example、B.example、C.exampleのクエリを受け取った場合、.exampleはルートゾーンに存在しないため、結果は3つのNXDOMAINにな​​ります。クエリ名の最小化では、ルートネームサーバーはNXDOMAINに答えることができる質問（.example自体）を1つだけ聞くため、完全なリゾルバーがB.exampleもCもないアプリオリを知ることができる否定的なキャッシュの機会が開かれます。 .exampleが存在する可能性があります。したがって、この一般的なケースでは、QNAME最小化での上流のクエリの総数は、従来の反復（DNS標準で説明されている）でのクエリの数よりも直感的に少なくなります。

QNAME minimisation may also improve lookup performance for TLD operators. For a typical TLD, delegation-only, and with delegations just under the TLD, a two-label QNAME query is optimal for finding the delegation owner name.

QNAMEの最小化により、TLDオペレーターの検索パフォーマンスも向上する可能性があります。代表的なTLD、委任のみ、および委任がTLDのすぐ下にある場合、委任所有者名を見つけるには2つのラベルのQNAMEクエリが最適です。

QNAME minimisation can decrease performance in some cases -- for instance, for a deep domain name (like www.host.group.department.example.com, where host.group.department.example.com is hosted on example.com's name servers). Let's assume a resolver that knows only the name servers of .example. Without QNAME minimisation, it would send these .example name servers a query for www.host.group.department.example.com and immediately get a specific referral or an answer, without the need for more queries to probe for the zone cut. For such a name, a cold resolver with QNAME minimisation will, depending on how QNAME minimisation is implemented, send more queries, one per label. Once the cache is warm, there will be no difference with a traditional resolver. Actual testing is described in [Huque-QNAME-Min]. Such deep domains are especially common under ip6.arpa.

QNAMEの最小化は、たとえば、深いドメイン名（www.host.group.department.example.comなど、host.group.department.example.comがexample.comのネームサーバーでホストされている場合）の場合にパフォーマンスを低下させる可能性があります）。 .exampleのネームサーバーのみを知っているリゾルバーを想定します。 QNAMEの最小化がなければ、これらの.exampleネームサーバーにwww.host.group.department.example.comのクエリを送信し、ゾーンカットをプローブするためのクエリを追加する必要なく、特定の紹介または回答をすぐに取得します。そのような名前の場合、QNAME最小化を使用したコールドリゾルバーは、QNAME最小化の実装方法に応じて、ラベルごとに1つずつ、より多くのクエリを送信します。キャッシュがウォームになると、従来のリゾルバーとの違いはありません。実際のテストは[Huque-QNAME-Min]で説明されています。そのような深いドメインは、ip6.arpaの下で特に一般的です。

7. On the Experimentation

7. 実験について

This document has status "Experimental". Since the beginning of time (or DNS), the fully qualified host name was always sent to the authoritative name servers. There was a concern that changing this behaviour may engage the Law of Unintended Consequences -- hence this status.

このドキュメントのステータスは「実験的」です。当初（またはDNS）以来、完全修飾ホスト名は常に権威ネームサーバーに送信されていました。この振る舞いを変更することは意図しない結果の法則に関与するかもしれないという懸念がありました-したがってこのステータスです。

The idea behind the experiment is to observe QNAME minimisation in action with multiple resolvers, various authoritative name servers, etc.

実験の背後にある考え方は、複数のリゾルバー、さまざまな信頼できるネームサーバーなどとのQNAME最小化の動作を観察することです。

8. Security Considerations

8. セキュリティに関する考慮事項

QNAME minimisation's benefits are clear in the case where you want to decrease exposure to the authoritative name server. But minimising the amount of data sent also, in part, addresses the case of a wire sniffer as well as the case of privacy invasion by the servers. (Encryption is of course a better defense against wire sniffers, but, unlike QNAME minimisation, it changes the protocol and cannot be deployed unilaterally. Also, the effect of QNAME minimisation on wire sniffers depends on whether the sniffer is on the DNS path.)

権威ネームサーバーへの露出を減らしたい場合、QNAME最小化の利点は明らかです。ただし、送信されるデータの量を最小限に抑えることは、一部には、ワイヤースニッファーの場合や、サーバーによるプライバシーの侵害の場合にも対処します。 （暗号化はもちろんワイヤースニファーに対するより優れた防御策ですが、QNAMEの最小化とは異なり、プロトコルを変更し、一方的に展開することはできません。また、ワイヤースニファーに対するQNAMEの最小化の効果は、スニファーがDNSパス上にあるかどうかによって異なります。）

QNAME minimisation offers zero protection against the recursive resolver, which still sees the full request coming from the stub resolver.

QNAMEの最小化は、スタブリゾルバーからの完全な要求を引き続き確認する再帰リゾルバーに対するゼロ保護を提供します。

All the alternatives mentioned in Appendix B decrease privacy in the hope of improving performance. They must not be used if you want maximum privacy.

付録Bに記載されているすべての代替案は、パフォーマンスを向上させるためにプライバシーを低下させます。最大限のプライバシーが必要な場合は使用しないでください。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[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>。

[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <http://www.rfc-editor.org/info/rfc7626>.

[RFC7626] Bortzmeyer、S。、「DNSプライバシーに関する考慮事項」、RFC 7626、DOI 10.17487 / RFC7626、2015年8月、<http://www.rfc-editor.org/info/rfc7626>。

9.2. Informative References

9.2. 参考引用

[DNS-Res-Improve] Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness", Work in Progress, draft-vixie-dnsext-resimprove-00, June 2010.

[DNS-Res-Improve] Vixie、P.、Joffe、R。、およびF. Neves、「回復力、堅牢性、および応答性のためのDNSリゾルバーの改善」、Work in Progress、draft-vixie-dnsext-resimprove-00、 2010年6月。

[HAMMER] Kumari, W., Arends, R., Woolf, S., and D. Migault, "Highly Automated Method for Maintaining Expiring Records", Work in Progress, draft-wkumari-dnsop-hammer-01, July 2014.

[ハンマー]クマリW.、アーレンズR.、ウルフS.、およびD.ミゴール、「期限切れ記録を維持するための高度に自動化された方法」、作業中、draft-wkumari-dnsop-hammer-01、2014年7月。

[Huque-QNAME-Min] Huque, S., "Query name minimization and authoritative server behavior", May 2015, <https://indico.dns-oarc.net/event/21/contribution/9>.

[Huque-QNAME-Min] Huque、S.、「クエリ名の最小化と信頼できるサーバーの動作」、2015年5月、<https://indico.dns-oarc.net/event/21/contribution/9>。

[Huque-QNAME-storify] Huque, S., "Qname Minimization @ DNS-OARC", May 2015, <https://storify.com/shuque/qname-minimization-dns-oarc>.

[Huque-QNAME-storify] Huque、S。、「Qname Minimization @ DNS-OARC」、2015年5月、<https://storify.com/shuque/qname-minimization-dns-oarc>。

[Kaliski-Minimum] Kaliski, B., "Minimum Disclosure: What Information Does a Name Server Need to Do Its Job?", March 2015, <http://blogs.verisigninc.com/blog/entry/ minimum_disclosure_what_information_does>.

[Kaliski-Minimum] Kaliski、B。、「Minimum Disclosure：どの情報はネームサーバーがその仕事をするために必要ですか？」、2015年3月、<http://blogs.verisigninc.com/blog/entry/ minimum_disclosure_what_information_does>。

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.

[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<http://www.rfc-editor.org/info/rfc2181>。

Appendix A. An Algorithm to Perform QNAME Minimisation

付録A. QNAME最小化を実行するアルゴリズム

This algorithm performs name resolution with QNAME minimisation in the presence of zone cuts that are not yet known.

このアルゴリズムは、まだ知られていないゾーンカットがある場合に、QNAME最小化を使用して名前解決を実行します。

Although a validating resolver already has the logic to find the zone cuts, implementers of other resolvers may want to use this algorithm to locate the cuts. This is just a possible aid for implementers; it is not intended to be normative:

検証するリゾルバにはゾーンカットを見つけるロジックがすでにありますが、他のリゾルバの実装者はこのアルゴリズムを使用してカットを見つけることができます。これは実装者のための可能な支援にすぎません。それは規範的であるように意図されていません：

(0) If the query can be answered from the cache, do so; otherwise, iterate as follows:

（0）クエリがキャッシュから回答できる場合は、回答してください。それ以外の場合は、次のように繰り返します。

(1) Find the closest enclosing NS RRset in your cache. The owner of this NS RRset will be a suffix of the QNAME -- the longest suffix of any NS RRset in the cache. Call this ANCESTOR.

（1）キャッシュ内で最も近い囲まれたNS RRsetを見つけます。このNS RRsetの所有者は、QNAMEのサフィックス、つまりキャッシュ内のNS RRsetの最も長いサフィックスになります。これを祖先と呼びます。

(2) Initialise CHILD to the same as ANCESTOR.

（2）CHILDをANCESTORと同じに初期化します。

(3) If CHILD is the same as the QNAME, resolve the original query using ANCESTOR's name servers, and finish.

（3）CHILDがQNAMEと同じ場合は、ANCESTORのネームサーバーを使用して元のクエリを解決し、終了します。

(4) Otherwise, add a label from the QNAME to the start of CHILD.

（4）それ以外の場合は、QNAMEからCHILDの先頭にラベルを追加します。

(5) If you have a negative cache entry for the NS RRset at CHILD, go back to step 3.

（5）CHILDのNS RRsetに負のキャッシュエントリがある場合は、手順3に戻ります。

(6) Query for CHILD IN NS using ANCESTOR's name servers. The response can be:

（6）ANCESTORのネームサーバーを使用して、CHILD IN NSを照会します。応答は次のいずれかです。

(6a) A referral. Cache the NS RRset from the authority section, and go back to step 1.

（6a）紹介。権限セクションからNS RRsetをキャッシュし、ステップ1に戻ります。

(6b) An authoritative answer. Cache the NS RRset from the answer section, and go back to step 1.

（6b）信頼できる回答。回答セクションからNS RRsetをキャッシュし、手順1に戻ります。

(6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response to the original query, and stop.

（6c）NXDOMAINの回答。元のクエリに応答してNXDOMAIN回答を返し、停止します。

(6d) A NOERROR/NODATA answer. Cache this negative answer, and go back to step 3.

（6d）NOERROR / NODATAの回答。この否定的な回答をキャッシュして、ステップ3に戻ります。

Appendix B. Alternatives

付録B.代替案

Remember that QNAME minimisation is unilateral, so a resolver is not forced to implement it exactly as described here.

QNAMEの最小化は一方的であるため、ここで説明するようにリゾルバーがそれを正確に実装する必要はありません。

There are several ways to perform QNAME minimisation. See Section 2 for the suggested way. It can be called the aggressive algorithm, since the resolver only sends NS queries as long as it does not know the zone cuts. This is the safest, from a privacy point of view. Another possible algorithm, not fully studied at this time, could be to "piggyback" on the traditional resolution code. At startup, it sends traditional full QNAMEs and learns the zone cuts from the referrals received, then switches to NS queries asking only for the minimum domain name. This leaks more data but could require fewer changes in the existing resolver codebase.

QNAMEの最小化を実行する方法はいくつかあります。推奨される方法については、セクション2を参照してください。リゾルバはゾーンカットを認識しない限り、NSクエリのみを送信するため、アグレッシブアルゴリズムと呼ぶことができます。これはプライバシーの観点から最も安全です。現時点で完全には研究されていない別の可能なアルゴリズムは、従来の解決コードを「ピギーバック」することです。起動時に、従来の完全なQNAMEを送信し、受信した紹介からゾーンカットを学習してから、最小ドメイン名のみを要求するNSクエリに切り替えます。これにより、より多くのデータがリークしますが、既存のリゾルバーコードベースの変更が少なくて済みます。

In the above specification, the original QTYPE is replaced by NS (or may be A, if too many servers react incorrectly to NS requests); this is the best approach to preserve privacy. But this erases information about the relative use of the various QTYPEs, which may be interesting for researchers (for instance, if they try to follow IPv6 deployment by counting the percentage of AAAA vs. A queries). A variant of QNAME minimisation would be to keep the original QTYPE.

上記の仕様では、元のQTYPEはNSに置き換えられます（NSリクエストに反応するサーバーが多すぎる場合はAになる場合があります）。これはプライバシーを保護するための最良のアプローチです。ただし、これにより、さまざまなQTYPEの相対的な使用に関する情報が消去されます。これは、研究者にとって興味深いかもしれません（たとえば、AAAA対Aクエリの割合をカウントしてIPv6の展開を追跡しようとした場合）。 QNAME最小化の変形は、元のQTYPEを維持することです。

Another useful optimisation may be, in the spirit of the HAMMER idea [HAMMER], to probe in advance for the introduction of zone cuts where none previously existed (i.e., confirm their continued absence, or discover them).

別の有用な最適化は、HAMMERのアイデアの精神[HAMMER]で、以前は存在しなかったゾーンカットの導入を事前に調査する（つまり、継続的な不在を確認する、またはそれらを発見する）場合があります。

To address the "number of queries" issue described in Section 6, a possible solution is to always use the traditional algorithm when the cache is cold and then to move to QNAME minimisation (precisely defining what is "hot" or "cold" is left to the implementer). This will decrease the privacy but will guarantee no degradation of performance.

セクション6で説明した「クエリ数」の問題に対処するには、キャッシュがコールドのときに常に従来のアルゴリズムを使用し、QNAMEの最小化に移行する（「ホット」または「コールド」が何であるかを正確に定義する）実装者に）。これによりプライバシーは低下しますが、パフォーマンスの低下は保証されません。

Acknowledgments

謝辞

Thanks to Olaf Kolkman for the original idea during a KLM flight from Amsterdam to Vancouver, although the concept is probably much older (e.g., <https://lists.dns-oarc.net/pipermail/dns-operations/ 2010-February/005003.html>). Thanks to Shumon Huque and Marek Vavrusa for implementation and testing. Thanks to Mark Andrews and Francis Dupont for the interesting discussions. Thanks to Brian Dickson, Warren Kumari, Evan Hunt, and David Conrad for remarks and suggestions. Thanks to Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone cut algorithm in Appendix A and for discussion of the algorithm. Thanks to Paul Vixie for pointing out that there are practical advantages (besides privacy) to QNAME minimisation. Thanks to Phillip Hallam-Baker for the fallback on A queries, to deal with broken servers. Thanks to Robert Edmonds for an interesting anti-pattern.

アムステルダムからバンクーバーへのKLM飛行中の最初のアイデアを提供してくれたOlaf Kolkmanに感謝します。 005003.html>）。実装とテストを行ったShumon HuqueとMarek Vavrusaに感謝します。興味深い議論をしてくれたMark AndrewsとFrancis Dupontに感謝します。 Brian Dickson、Warren Kumari、Evan Hunt、David Conradに発言と提案をありがとう。 Mohsen Souissiの校正に感謝します。付録Aのゾーンカットアルゴリズムとアルゴリズムの説明について、Tony Finchに感謝します。 QNAMEの最小化には（プライバシー以外に）実用的な利点があることを指摘してくれたPaul Vixieに感謝します。壊れたサーバーを処理するためのAクエリのフォールバックを提供してくれたPhillip Hallam-Bakerに感謝します。興味深いアンチパターンを提供してくれたRobert Edmondsに感謝します。

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/