[要約] RFC 7871は、DNSクエリにおけるクライアントサブネットの使用方法を定義しています。目的は、クライアントのサブネット情報をDNSサーバに提供することで、より効果的なクエリ応答を可能にすることです。
Internet Engineering Task Force (IETF) C. Contavalli
Request for Comments: 7871 W. van der Gaast
Category: Informational Google
ISSN: 2070-1721 D. Lawrence
Akamai Technologies
W. Kumari
Google
May 2016
Client Subnet in DNS Queries
DNSクエリのクライアントサブネット
Abstract
概要
This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.
このドキュメントでは、DNSクエリを発信したネットワークと後続の応答をキャッシュできるネットワークに関する情報を伝達するためにアクティブに使用されているDNS（EDNS0）の拡張メカニズムについて説明します。運用上およびプライバシー上の既知の欠点がいくつかあるため、IETFを通じて改善のための改訂が行われます。
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/rfc7871.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7871で入手できます。
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 ....................................................4
2. Privacy Note ....................................................5
3. Requirements Notation ...........................................5
4. Terminology .....................................................6
5. Overview ........................................................7
6. Option Format ...................................................8
7. Protocol Description ............................................9
7.1. Originating the Option .....................................9
7.1.1. Recursive Resolvers .................................9
7.1.2. Stub Resolvers .....................................10
7.1.3. Forwarding Resolvers ...............................11
7.2. Generating a Response .....................................11
7.2.1. Authoritative Nameserver ...........................11
7.2.2. Intermediate Nameserver ............................13
7.3. Handling ECS Responses and Caching ........................14
7.3.1. Caching the Response ...............................15
7.3.2. Answering from Cache ...............................16
7.4. Delegations and Negative Answers ..........................17
7.5. Transitivity ..............................................18
8. IANA Considerations ............................................18
9. DNSSEC Considerations ..........................................19
10. NAT Considerations ............................................19
11. Security Considerations .......................................20
11.1. Privacy ..................................................20
11.2. Birthday Attacks .........................................21
11.3. Cache Pollution ..........................................22
12. Sending the Option ............................................23
12.1. Probing ..................................................23
12.2. Whitelist ................................................24
13. Example .......................................................24
14. References ....................................................26
14.1. Normative References .....................................26
14.2. Informative References ...................................27
Acknowledgements ..................................................28
Contributors ......................................................29
Authors' Addresses ................................................30
Many Authoritative Nameservers today return different responses based on the perceived topological location of the user. These servers use the IP address of the incoming query to identify that location.
今日、多くの権威ネームサーバーは、ユーザーの認識されたトポロジー上の場所に基づいて異なる応答を返します。これらのサーバーは、受信クエリのIPアドレスを使用してその場所を識別します。
Since most queries come from Intermediate Recursive Resolvers, the source address is that of the Recursive Resolver rather than of the query originator.
ほとんどのクエリは中間再帰リゾルバから送信されるため、ソースアドレスはクエリの発信元ではなく再帰リゾルバのアドレスです。
Traditionally, and probably still in the majority of instances, Recursive Resolvers are reasonably close in the topological sense to the Stub Resolvers or Forwarding Resolvers that are the source of queries. For these resolvers, using their own IP address is sufficient for Authoritative Nameservers that tailor responses based upon location of the querier.
従来、そしておそらく大多数のインスタンスでは、再帰リゾルバーはトポロジーの観点から、クエリのソースであるスタブリゾルバーまたは転送リゾルバーにかなり近いです。これらのリゾルバーでは、クエリアの場所に基づいて応答を調整する権威ネームサーバーにとって、独自のIPアドレスを使用することで十分です。
Increasingly, though, a class of Recursive Resolvers has arisen that handles query sources that are often not topologically close. The motivation for having such Centralized Resolvers varies but is usually because of some enhanced experience, such as greater cache security or applying policies regarding where users may connect. (Although political censorship usually comes to mind here, the same actions may be used by a parent when setting controls on where a minor may connect.) Similarly, many ISPs and other organizations use a Centralized Resolver infrastructure that can be distant from the clients the resolvers serve. These cases all lead to less than desirable responses from topology-sensitive Authoritative Nameservers.
ただし、トポロジ的に接近していないことが多いクエリソースを処理する再帰リゾルバーのクラスが次第に増えています。このような一元化されたリゾルバーを使用する動機はさまざまですが、通常は、より優れたキャッシュセキュリティやユーザーが接続できる場所に関するポリシーの適用など、いくつかの拡張されたエクスペリエンスが原因です。 （通常、ここでは政治的検閲が思い浮かびますが、未成年者が接続できる場所を制御するときに、親が同じアクションを使用する場合があります。）同様に、多くのISPや他の組織は、クライアントから離れた場所にある集中リゾルバーインフラストラクチャを使用しています。リゾルバーは役立ちます。これらの場合はすべて、トポロジーに依存する権威ネームサーバーからの応答が望ましいものとは言えません。
This document defines an EDNS0 [RFC6891] option to convey network information that is relevant to the DNS message. It will carry sufficient network information about the originator for the Authoritative Nameserver to tailor responses. It will also provide for the Authoritative Nameserver to indicate the scope of network addresses for which the tailored answer is intended. This EDNS0 option is intended for those Recursive Resolvers and Authoritative Nameservers that would benefit from the extension and not for general purpose deployment. This is completely optional and can safely be ignored by servers that choose not to implement or enable it.
このドキュメントでは、DNSメッセージに関連するネットワーク情報を伝達するEDNS0 [RFC6891]オプションを定義しています。 Authoritative Nameserverが応答を調整するために、発信者に関する十分なネットワーク情報を伝達します。また、Authoritative Nameserverが、調整された回答が対象とするネットワークアドレスのスコープを示すこともできます。このEDNS0オプションは、拡張の恩恵を受ける汎用の展開ではなく、再帰リゾルバーと権威ネームサーバーを対象としています。これは完全にオプションであり、実装または有効化しないことを選択したサーバーでは無視しても問題ありません。
This document also includes guidelines on how best to cache those results, and it provides recommendations on when this protocol extension should be used.
このドキュメントには、これらの結果をキャッシュする最適な方法に関するガイドラインも含まれており、このプロトコル拡張を使用する必要がある場合の推奨事項も提供します。
At least a dozen different client and server implementations have been written based on earlier draft versions of this specification. The protocol is in active production use today. While the implementations interoperate, there is varying behavior around edge cases that were poorly specified. Known incompatibilities are described in this document, and the authors believe that it is better to describe the system as it is working today, even if not everyone agrees with the details of the original specification ([VANDERGAAST]). The alternative is an undocumented and proprietary system.
この仕様の以前のドラフトバージョンに基づいて、少なくとも12の異なるクライアントとサーバーの実装が記述されています。プロトコルは今日、活発に運用されています。実装は相互運用しますが、不十分に指定されたエッジケースの周囲にはさまざまな動作があります。既知の非互換性はこのドキュメントで説明されており、作成者は、誰もが元の仕様（[VANDERGAAST]）の詳細に同意していなくても、現在機能しているシステムを説明する方が良いと考えています。別の方法は、文書化されていない独自のシステムです。
A revised proposal to improve upon the minor flaws in this protocol will be forthcoming to the IETF.
このプロトコルの軽微な欠陥を改善するための改訂された提案がIETFに近づく予定です。
If we were just beginning to design this mechanism, and not documenting existing protocol, it is unlikely that we would have done things exactly this way.
このメカニズムの設計を始めたばかりで、既存のプロトコルを文書化していなかったとしたら、この方法で正確に処理することはできません。
The IETF is actively working on enhancing DNS privacy [DPRIVE_Working_Group] and the reinjection of metadata [METADATA] has been identified as a problematic design pattern.
IETFはDNSプライバシーの強化[DPRIVE_Working_Group]に積極的に取り組んでおり、メタデータの再注入[METADATA]は問題のある設計パターンとして識別されています。
As noted above however, this document primarily describes existing behavior of a deployed method to further the understanding of the Internet community.
ただし、上記のように、このドキュメントでは主に、インターネットコミュニティの理解を深めるために、デプロイされたメソッドの既存の動作について説明します。
We recommend that the feature be turned off by default in all nameserver software, and that operators only enable it explicitly in those circumstances where it provides a clear benefit for their clients. We also encourage the deployment of means to allow users to make use of the opt-out provided. Finally, we recommend that others avoid techniques that may introduce additional metadata in future work, as it may damage user trust.
すべてのネームサーバーソフトウェアでこの機能をデフォルトでオフにし、オペレーターがクライアントに明確なメリットをもたらす状況でのみ明示的に有効にすることをお勧めします。また、ユーザーが提供されたオプトアウトを利用できるようにする手段の導入も推奨します。最後に、ユーザーの信頼を損なう可能性があるため、将来の作業で追加のメタデータを導入する可能性のある手法を他の人が避けることをお勧めします。
Regrettably, support for the opt-out provisions of this specification are currently limited. Only one stub resolver, getdns, is known to be able to originate queries with anonymity requested, and as yet no applications are known to be able to indicate that user preference to the stub resolver.
残念ながら、この仕様のオプトアウト規定のサポートは現在制限されています。 1つのスタブリゾルバーgetdnsだけが、匿名性を要求してクエリを発信できることがわかっています。それでも、ユーザーがスタブリゾルバーを優先していることを示すことができるアプリケーションはありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
ECS: EDNS Client Subnet.
X：アドオンクライアントサブネット。
Client: A Stub Resolver, Forwarding Resolver, or Recursive Resolver. A client to a Recursive Resolver or a Forwarding Resolver.
クライアント：スタブリゾルバー、転送リゾルバー、または再帰リゾルバー。再帰リゾルバまたは転送リゾルバのクライアント。
Server: A Forwarding Resolver, Recursive Resolver, or Authoritative Nameserver.
サーバー：Forwarding Resolver、Recursive Resolver、またはAuthoritative Nameserver。
Stub Resolver: A simple DNS protocol implementation on the client side as described in [RFC1034], Section 5.3.1. A client to a Recursive Resolver or a Forwarding Resolver.
スタブリゾルバー：[RFC1034]のセクション5.3.1で説明されている、クライアント側での単純なDNSプロトコルの実装。再帰リゾルバまたは転送リゾルバのクライアント。
Authoritative Nameserver: A nameserver that has authority over one or more DNS zones. These are normally not contacted by Stub Resolver or end user clients directly but by Recursive Resolvers. Described in [RFC1035], Section 6.
権威ネームサーバー：1つ以上のDNSゾーンに対する権限を持つネームサーバー。これらは通常、スタブリゾルバーやエンドユーザークライアントから直接接続されるのではなく、再帰リゾルバーから接続されます。 [RFC1035]のセクション6で説明されています。
Recursive Resolver: A nameserver that is responsible for resolving domain names for clients by following the domain's delegation chain. Recursive Resolvers frequently use caches to be able to respond to client queries quickly. Described in [RFC1035], Section 7.
再帰リゾルバー：ドメインの委任チェーンに従ってクライアントのドメイン名を解決するネームサーバー。再帰リゾルバは、クライアントのクエリにすばやく応答できるように、キャッシュを頻繁に使用します。 [RFC1035]のセクション7で説明されています。
Forwarding Resolver: A nameserver that does not do iterative resolution itself, but instead passes that responsibility to another Recursive Resolver, called a "Forwarder" in [RFC2308], Section 1.
Forwarding Resolver：自身で反復解決を行わず、代わりにその責任を[RFC2308]の「Forwarder」と呼ばれる別の再帰リゾルバーに渡すセクション1。
Intermediate Nameserver: Any nameserver in between the Stub Resolver and the Authoritative Nameserver, such as a Recursive Resolver or a Forwarding Resolver.
中間ネームサーバー：スタブリゾルバーと権威ネームサーバーの間にある任意のネームサーバー（再帰リゾルバーや転送リゾルバーなど）。
Centralized Resolvers: Intermediate Nameservers that serve a topologically diverse network address space.
集中リゾルバ：トポロジ的に多様なネットワークアドレススペースを提供する中間ネームサーバー。
Tailored Response: A response from a nameserver that is customized for the node that sent the query, often based on performance (i.e., lowest latency, least number of hops, topological distance, etc.).
テーラードレスポンス：クエリに送信したノード用にカスタマイズされたネームサーバーからのレスポンス。多くの場合、パフォーマンス（つまり、最小のレイテンシ、最小ホップ数、トポロジー距離など）に基づいています。
Topologically Close: Refers to two hosts being close in terms of the number of hops or the time it takes for a packet to travel from one host to the other. The concept of topological distance is only loosely related to the concept of geographical distance: two geographically close hosts can still be very distant from a topological perspective, and two geographically distant hosts can be quite close on the network.
トポロジー的に近い：ホップ数またはパケットが1つのホストから別のホストに移動するのにかかる時間に関して、2つのホストが近いことを指します。トポロジー距離の概念は、地理的距離の概念と大まかに関連しています。2つの地理的に近いホストはトポロジーの観点から依然として非常に離れている可能性があり、2つの地理的に離れたホストはネットワーク上で非常に近い可能性があります。
For a more comprehensive treatment of DNS terms, please see [RFC7719].
DNS用語のより包括的な扱いについては、[RFC7719]を参照してください。
The general idea of this document is to provide an EDNS0 option to allow Recursive Resolvers, if they are willing, to forward details about the origin network from which a query is coming when talking to other nameservers.
このドキュメントの一般的なアイデアは、他のネームサーバーと通信するときにクエリの送信元のネットワークに関する詳細を転送できる場合に、再帰リゾルバーが許可するEDNS0オプションを提供することです。
The format of the edns-client-subnet (ECS) EDNS0 option is described in Section 6 and is meant to be added in queries sent by Intermediate Nameservers in a way that is transparent to Stub Resolvers and end users, as described in Section 7.1. ECS is only defined for the Internet (IN) DNS class.
edns-client-subnet（ECS）EDNS0オプションの形式はセクション6で説明されており、セクション7.1で説明されているように、スタブリゾルバーとエンドユーザーに対して透過的な方法で中間ネームサーバーによって送信されるクエリに追加されることを意図しています。 ECSは、インターネット（IN）DNSクラスに対してのみ定義されます。
As described in Section 7.2, an Authoritative Nameserver could use ECS as a hint to the end user's network location and provide a better answer. Its response would also contain an ECS option, clearly indicating that the server made use of this information, and that the answer is tied to the client's network.
セクション7.2で説明したように、権威ネームサーバーはECSをエンドユーザーのネットワークロケーションへのヒントとして使用し、より適切な回答を提供できます。その応答にはECSオプションも含まれ、サーバーがこの情報を利用したこと、および回答がクライアントのネットワークに関連付けられていることが明確に示されます。
As described in Section 7.3, Intermediate Nameservers would use this information to cache the response.
セクション7.3で説明したように、中間ネームサーバーはこの情報を使用して応答をキャッシュします。
Some Intermediate Nameservers may also have to be able to forward ECS queries they receive, as described in Section 7.5.
セクション7.5で説明されているように、一部の中間ネームサーバーは、受信したECSクエリを転送できる必要がある場合もあります。
The mechanisms provided by ECS raise various security-related concerns related to cache growth, the ability to spoof EDNS0 options, and privacy. Section 11 explores various mitigation techniques.
ECSによって提供されるメカニズムは、キャッシュの増加、EDNS0オプションを偽装する機能、およびプライバシーに関連するセキュリティ関連のさまざまな懸念を引き起こします。セクション11では、さまざまな緩和手法について説明します。
The expectation, however, is that this option will primarily be used between Recursive Resolvers and Authoritative Nameservers that are sensitive to network location issues. Most Recursive Resolvers, Authoritative Nameservers, and Stub Resolvers will never need to know about this option and will continue working as they had been.
ただし、このオプションは主に、再帰的リゾルバーとネットワークロケーションの問題に敏感な権威ネームサーバーの間で使用されることが期待されています。ほとんどの再帰リゾルバー、権威ネームサーバー、およびスタブリゾルバーは、このオプションについて知る必要はなく、以前と同じように動作し続けます。
Failure to support this option or its improper handling will, at worst, cause suboptimal identification of client network location, which is a common occurrence in current Content Delivery Network (CDN) setups.
このオプションまたはその不適切な処理をサポートしないと、最悪の場合、現在のコンテンツ配信ネットワーク（CDN）セットアップでよく発生する、クライアントネットワークの場所の識別が最適ではなくなります。
Section 7.1 also provides a mechanism for Stub Resolvers to signal Recursive Resolvers that they do not want ECS treatment for specific queries.
セクション7.1では、スタブリゾルバーが特定のクエリに対するECS処理を望まないことを再帰リゾルバーに通知するメカニズムも提供します。
Additionally, operators of Intermediate Nameservers with ECS enabled are allowed to choose how many bits of the address of received queries to forward or to reduce the number of bits forwarded for queries already including an ECS option.
さらに、ECSが有効になっている中間ネームサーバーのオペレーターは、受信したクエリのアドレスの何ビットを転送するかを選択したり、すでにECSオプションが含まれているクエリの転送ビット数を減らしたりできます。
This protocol uses an EDNS0 [RFC6891] option to include client address information in DNS messages. The option is structured as follows:
このプロトコルはEDNS0 [RFC6891]オプションを使用して、クライアントメッセージ情報をDNSメッセージに含めます。オプションは次のように構成されています。
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | FAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | ADDRESS... /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00 0x08).
o （[RFC6891]で定義）ECSのOPTION-CODE、2オクテットは8（0x00 0x08）。
o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the length of the payload (everything after OPTION-LENGTH) in octets.
o （[RFC6891]で定義）2オクテットのOPTION-LENGTHには、オクテット単位のペイロード（OPTION-LENGTHの後のすべて）の長さが含まれます。
o FAMILY, 2 octets, indicates the family of the address contained in the option, using address family codes as assigned by IANA in Address Family Numbers [Address_Family_Numbers].
o FAMILY、2オクテットは、オプションに含まれるアドレスのファミリを示し、アドレスファミリ番号[Address_Family_Numbers]でIANAによって割り当てられたアドレスファミリコードを使用します。
The format of the address part depends on the value of FAMILY. This document only defines the format for FAMILY 1 (IPv4) and FAMILY 2 (IPv6), which are as follows:
アドレス部分の形式は、FAMILYの値によって異なります。このドキュメントでは、FAMILY 1（IPv4）およびFAMILY 2（IPv6）の形式のみを定義します。形式は次のとおりです。
o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost number of significant bits of ADDRESS to be used for the lookup. In responses, it mirrors the same value as in the queries.
o SOURCE PREFIX-LENGTH。ルックアップに使用されるADDRESSの左端の有効ビット数を表す符号なしオクテット。応答では、クエリと同じ値を反映します。
o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost number of significant bits of ADDRESS that the response covers. In queries, it MUST be set to 0.
o SCOPE PREFIX-LENGTH、応答がカバーするADDRESSの左端の有効ビット数を表す符号なしオクテット。クエリでは、0に設定する必要があります。
o ADDRESS, variable number of octets, contains either an IPv4 or IPv6 address, depending on FAMILY, which MUST be truncated to the number of bits indicated by the SOURCE PREFIX-LENGTH field, padding with 0 bits to pad to the end of the last octet needed.
o 可変オクテット数のADDRESSには、FAMILYに応じて、IPv4またはIPv6アドレスのいずれかが含まれます。これは、SOURCE PREFIX-LENGTHフィールドで示されるビット数に切り捨てられ、最後のオクテットの終わりまでパディングするために0ビットでパディングされます。必要。
o A server receiving an ECS option that uses either too few or too many ADDRESS octets, or that has non-zero ADDRESS bits set beyond SOURCE PREFIX-LENGTH, SHOULD return FORMERR to reject the packet, as a signal to the software developer making the request to fix their implementation.
o ADDRESSオクテットが少なすぎるか多すぎる、またはゼロ以外のADDRESSビットがSOURCE PREFIX-LENGTHを超えて設定されているECSオプションを受信するサーバーは、要求を行うソフトウェア開発者への信号として、FORMERRを返してパケットを拒否する必要があります（SHOULD）それらの実装を修正します。
All fields are in network byte order ("big-endian", per [RFC1700], Data Notation).
すべてのフィールドはネットワークバイト順です（[ビッグエンディアン]、[RFC1700]、データ表記法）。
The ECS option should generally be added by Recursive Resolvers when querying Authoritative Nameservers, as described in Section 12. The option can also be initialized by a Stub Resolver or Forwarding Resolver.
ECSオプションは、セクション12で説明されているように、権限のあるネームサーバーをクエリするときに再帰リゾルバーによって追加される必要があります。このオプションは、スタブリゾルバーまたは転送リゾルバーによって初期化することもできます。
The setup of the ECS option in a Recursive Resolver depends on the client query that triggered the resolution process.
再帰リゾルバーのECSオプションの設定は、解決プロセスをトリガーしたクライアントクエリによって異なります。
In the usual case, where no ECS option was present in the client query, the Recursive Resolver initializes the option by setting FAMILY of the client's address. It then uses the value of its maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For privacy reasons, and because the whole IP address is rarely required to determine a tailored response, this length SHOULD be shorter than the full address, as described in Section 11.
通常のケースでは、クライアントクエリにECSオプションが存在しなかった場合、再帰リゾルバーはクライアントのアドレスのFAMILYを設定してオプションを初期化します。次に、キャッシュ可能なプレフィックスの最大長の値を使用して、SOURCE PREFIX-LENGTHを設定します。プライバシー上の理由から、および調整された応答を決定するためにIPアドレス全体が必要になることはめったにないため、セクション11で説明されているように、この長さは完全なアドレスよりも短い必要があります。
If the triggering query included an ECS option itself, it MUST be examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of the incoming query's SOURCE PREFIX-LENGTH or the server's maximum cacheable prefix length.
トリガークエリにECSオプション自体が含まれている場合は、そのSOURCE PREFIX-LENGTHを調べる必要があります。次に、再帰リゾルバーの発信クエリは、SOURCE PREFIX-LENGTHを着信クエリのSOURCE PREFIX-LENGTHまたはサーバーの最大キャッシュ可能プレフィックス長の短い方に設定する必要があります。
Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and ADDRESS is then added up to SOURCE PREFIX-LENGTH number of bits, with trailing 0 bits added, if needed, to fill the final octet. The total number of octets used MUST only be enough to cover SOURCE PREFIX-LENGTH bits, rather than the full width that would normally be used by addresses in FAMILY.
最後に、どちらの場合も、SCOPE PREFIX-LENGTHが0に設定され、ADDRESSがSOURCE PREFIX-LENGTHのビット数まで追加され、最後のオクテットを満たすために、必要に応じて末尾の0ビットが追加されます。使用されるオクテットの総数は、FAMILYのアドレスで通常使用される全幅ではなく、SOURCE PREFIX-LENGTHビットをカバーするのに十分なだけである必要があります。
FAMILY and ADDRESS information MAY be used from the ECS option in the incoming query. Passing the existing address data is supportive of the Recursive Resolver being used as the target of a Forwarding Resolver, but could possibly run into policy problems with regard to usage agreements between the Recursive Resolver and Authoritative Nameserver. See Section 12.2 for more discussion on this point. If the Recursive Resolver will not forward FAMILY and ADDRESS data from the incoming ECS option, it SHOULD return a REFUSED response.
FAMILYおよびADDRESS情報は、着信クエリのECSオプションから使用できます。既存のアドレスデータを渡すことは、転送リゾルバのターゲットとして使用されている再帰リゾルバをサポートしますが、再帰リゾルバと権威ネームサーバー間の使用規約に関してポリシーの問題に遭遇する可能性があります。この点の詳細については、セクション12.2を参照してください。再帰リゾルバーが着信ECSオプションからFAMILYおよびADDRESSデータを転送しない場合は、REFUSED応答を返す必要があります（SHOULD）。
Subsequent queries to refresh the data MUST, if unrestricted by an incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX-LENGTH that the Recursive Resolver is willing to cache, even if a previous response indicated that a shorter prefix length was sufficient.
後続のクエリでデータを更新する必要があります。着信SOURCE PREFIX-LENGTHによって制限されていない場合は、以前の応答でプレフィックス長が短いことで十分だったとしても、再帰リゾルバーがキャッシュする最長のSOURCE PREFIX-LENGTHを指定する必要があります。
A Stub Resolver MAY generate DNS queries with an ECS option that sets SOURCE PREFIX-LENGTH to limit how network information should be revealed. An Intermediate Nameserver that receives such a query MUST NOT make queries that include more bits of client address than in the originating query.
スタブリゾルバーは、SOURCE PREFIX-LENGTHを設定してネットワーク情報の公開方法を制限するECSオプションを使用してDNSクエリを生成できます（MAY）。このようなクエリを受信する中間ネームサーバーは、元のクエリよりも多くのビットのクライアントアドレスを含むクエリを作成してはなりません。
A SOURCE PREFIX-LENGTH value of 0 means that the Recursive Resolver MUST NOT add the client's address information to its queries. The subsequent Recursive Resolver query to the Authoritative Nameserver will then either not include an ECS option or MAY optionally include its own address information, which is what the Authoritative Nameserver will almost certainly use to generate any Tailored Response in lieu of an option. This allows the answer to be handled by the same caching mechanism as other queries, with an explicit indicator of the applicable scope. Subsequent Stub Resolver queries for /0 can then be answered from this cached response.
SOURCE PREFIX-LENGTH値0は、再帰リゾルバーがクライアントのアドレス情報をそのクエリに追加してはならないことを意味します。次に、権威ネームサーバーへの後続の再帰リゾルバークエリにECSオプションが含まれないか、オプションで独自のアドレス情報を含めることができます。これは、権威ネームサーバーがオプションの代わりに調整応答を生成するためにほぼ確実に使用するものです。これにより、適切なスコープを明示的に示すことで、他のクエリと同じキャッシュメカニズムで回答を処理できます。 / 0に対する後続のスタブリゾルバークエリは、このキャッシュされた応答から応答できます。
A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include FAMILY and ADDRESS data, but should be prepared to handle a REFUSED response if the Intermediate Nameserver that it queries has a policy that denies forwarding of ADDRESS. If there is no ADDRESS set, i.e., SOURCE PREFIX-LENGTH is set to 0, then FAMILY SHOULD be set to the transport over which the query is sent. This is for interoperability; at least one major authoritative server will ignore the option if FAMILY is not 1 or 2, even though it is irrelevant if there are no ADDRESS bits.
スタブリゾルバーはSCOPE PREFIX-LENGTHを0に設定する必要があります。FAMILYおよびADDRESSデータを含めることができますが、照会する中間ネームサーバーがADDRESSの転送を拒否するポリシーを持っている場合は、REFUSED応答を処理できるように準備する必要があります。 ADDRESSが設定されていない場合、つまりSOURCE PREFIX-LENGTHが0に設定されている場合は、クエリを送信するトランスポートにFAMILY SHOULDを設定する必要があります。これは相互運用性のためです。 FAMILYが1または2でない場合、少なくとも1つの主要な権威サーバーがこのオプションを無視します。ただし、ADDRESSビットがない場合は関係ありません。
Forwarding Resolvers essentially appear to be Stub Resolvers to whatever Recursive Resolver is ultimately handling the query, but they look like a Recursive Resolver to their client. A Forwarding Resolver using this option MUST prepare it as described in Section 7.1.1, "Recursive Resolvers". In particular, a Forwarding Resolver that implements this protocol MUST honor SOURCE PREFIX-LENGTH restrictions indicated in the incoming query from its client. See also Section 7.5.
転送リゾルバーは、本質的には、最終的にクエリを処理する再帰リゾルバーにとってはスタブリゾルバーのように見えますが、クライアントにとっては再帰リゾルバーのように見えます。このオプションを使用する転送リゾルバは、7.1.1項「再帰リゾルバ」で説明されているように準備する必要があります。特に、このプロトコルを実装するForwarding Resolverは、そのクライアントからの着信クエリに示されているSOURCE PREFIX-LENGTH制限を遵守する必要があります。セクション7.5も参照してください。
Since the Recursive Resolver it contacts will treat the Forwarding Resolver like a Stub Resolver, the Recursive Resolver's policies regarding incoming ADDRESS information will apply in the same way. If the Forwarding Resolver receives a REFUSED response when it sends a query that includes a non-zero ADDRESS, it MUST retry with no ADDRESS.
連絡先の再帰リゾルバは転送リゾルバをスタブリゾルバのように扱うため、受信アドレス情報に関する再帰リゾルバのポリシーは同じ方法で適用されます。 Forwarding Resolverがゼロ以外のADDRESSを含むクエリを送信するときにREFUSED応答を受信した場合、それはADDRESSなしで再試行する必要があります。
When a query containing an ECS option is received, an Authoritative Nameserver supporting ECS MAY use the address information specified in the option to generate a tailored response.
ECSオプションを含むクエリを受信すると、ECSをサポートする権威ネームサーバーは、オプションで指定されたアドレス情報を使用して、調整された応答を生成できます（MAY）。
Authoritative Nameservers that have not implemented or enabled support for the ECS option ought to safely ignore it within incoming queries, per [RFC6891], Section 6.1.2. Such a server MUST NOT include an ECS option within replies to indicate lack of support for it. Implementers of Intermediate Nameservers should be aware, however, that some nameservers incorrectly echo back unknown EDNS0 options. In this protocol, that should be mostly harmless, as the SCOPE PREFIX-LENGTH should come back as 0, thus marking the response as covering all networks.
ECSオプションのサポートを実装または有効にしていない権威ネームサーバーは、[RFC6891]のセクション6.1.2に従って、着信クエリ内でそれを安全に無視する必要があります。そのようなサーバーは、それに対するサポートの欠如を示すために、返信内にECSオプションを含めてはなりません（MUST NOT）。ただし、中間ネームサーバーの実装者は、一部のネームサーバーが不明なEDNS0オプションを誤ってエコーバックすることに注意してください。このプロトコルでは、SCOPE PREFIX-LENGTHが0として返され、応答をすべてのネットワークをカバーするものとしてマークするため、ほとんど無害です。
A query with a wrongly formatted option (e.g., an unknown FAMILY) MUST be rejected and a FORMERR response MUST be returned to the sender, as described in [RFC6891], "Transport Considerations".
[RFC6891]の「トランスポートに関する考慮事項」で説明されているように、誤ってフォーマットされたオプション（不明なFAMILYなど）を含むクエリは拒否する必要があり、FORMERR応答を送信者に返す必要があります。
An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer. (Note that the requirement in [RFC6891] to reserve space for the OPT record could mean that the Answer section of the response will be truncated and fall back to TCP indicated accordingly.) If an ECS option was not included in a query, one MUST NOT be included in the response even if the server is providing a Tailored Response -- presumably based on the address from which it received the query.
このプロトコルを実装し、ECSオプションを受信する権威ネームサーバーは、応答を作成するためにクライアント情報が必要かどうかに関係なく、それに応じてキャッシュする必要があることを示すために、応答にECSオプションを含める必要があります。 （[RFC6891]でOPTレコード用のスペースを予約するという要件は、応答の回答セクションが切り捨てられ、それに応じてTCPにフォールバックされることを意味する場合があります。）ECSオプションがクエリに含まれていない場合、サーバーが調整された応答を提供している場合でも、応答には含まれません-おそらくクエリを受信したアドレスに基づいています。
FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.
FAMILY、SOURCE PREFIX-LENGTH、および応答のADDRESSは、クエリのそれらと一致する必要があります。これらの値をエコーバックすると、セクション11で説明されているように、特定の攻撃ベクトルを軽減するのに役立ちます。
SCOPE PREFIX-LENGTH in the response indicates the network for which the answer is intended.
応答のSCOPE PREFIX-LENGTHは、応答が意図されているネットワークを示します。
A SCOPE PREFIX-LENGTH value longer than SOURCE PREFIX-LENGTH indicates that the provided prefix length was not specific enough to select the most appropriate Tailored Response. Future queries for the name within the specified network SHOULD use the longer SCOPE PREFIX-LENGTH. Factors affecting whether the Recursive Resolver would use the longer length include the amount of privacy masking the operator wants to provide their users, and the additional resource implications for the cache.
SOURCE PREFIX-LENGTHよりも長いSCOPE PREFIX-LENGTH値は、指定されたプレフィックス長が、最も適切な調整済み応答を選択するのに十分具体的ではなかったことを示します。指定されたネットワーク内の名前に対する今後のクエリでは、長いSCOPE PREFIX-LENGTHを使用する必要があります（SHOULD）。再帰リゾルバーがより長い長さを使用するかどうかに影響を与える要因には、オペレーターがユーザーに提供したいプライバシーマスクの量、およびキャッシュに対する追加のリソースの影響が含まれます。
Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits than necessary were provided, and the answer is suitable for a broader range of addresses. This could be as short as 0, to indicate that the answer is suitable for all addresses in FAMILY.
逆に、短いSCOPE PREFIX-LENGTHは、必要以上のビットが提供されたことを示し、答えはより広い範囲のアドレスに適しています。これは、回答がFAMILYのすべてのアドレスに適していることを示すために、0と同じくらい短い場合があります。
As the logical topology of any part of the network with regard to the tailored response can vary, an Authoritative Nameserver may return different values of SCOPE PREFIX-LENGTH for different networks.
調整された応答に関するネットワークの任意の部分の論理トポロジーは変化する可能性があるため、権威ネームサーバーは、ネットワークごとに異なる値のSCOPE PREFIX-LENGTHを返すことがあります。
Since some queries can result in multiple RRsets being added to the response, there is an unfortunate ambiguity from the original specification as to how SCOPE PREFIX-LENGTH would apply to each individual RRset. For example, multiple types in response to an ANY metaquery could all have different applicable SCOPE PREFIX-LENGTH values, but this protocol only has the ability to signal one. The response SHOULD therefore, include the longest relevant PREFIX-LENGTH of any RRset in the answer, which could have the unfortunate side effect of redundantly caching some data that could be cached more broadly. For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway. For message-focused resolvers, rather than RRset-focused ones, this will mean caching the entire CNAME chain at the longest PREFIX-LENGTH of any RRset in the chain.
一部のクエリでは複数のRRsetが応答に追加される可能性があるため、SCOPE PREFIX-LENGTHが個々のRRsetにどのように適用されるかについては、元の仕様から不幸なあいまいさが存在します。たとえば、ANYメタクエリに応答する複数のタイプはすべて、適用可能な異なるSCOPE PREFIX-LENGTH値を持つ可能性がありますが、このプロトコルは1つのシグナルしか送信できません。したがって、応答には、RRセットの最も長い関連するPREFIX-LENGTHを回答に含める必要があります。これにより、より広範囲にキャッシュされる可能性のある一部のデータを重複してキャッシュするという残念な副作用が生じる可能性があります。正規名（CNAME）チェーンの特定のケースでは、Authoritative Nameserverは最初のCNAMEレコードのみをAnswerセクションに配置して、明確かつ適切にキャッシュされるようにする必要があります（SHOULD）。最近のほとんどの再帰リゾルバーはCNAMEでクエリを再起動するため、チェーンの残りの部分は通常無視されます。 RRsetに重点を置いたリゾルバーではなく、メッセージに重点を置いたリゾルバーの場合、これはCNAMEチェーン全体をチェーン内のRRsetの最も長いPREFIX-LENGTHでキャッシュすることを意味します。
The specific logic that an Authoritative Nameserver uses to choose a tailored response is not in the scope of this document. Implementers are encouraged, however, to carefully consider their selection of SCOPE PREFIX-LENGTH for the response in the event that the best tailored response cannot be determined, and what the implications would be over the life of the TTL.
権威ネームサーバーが調整された応答を選択するために使用する特定のロジックは、このドキュメントの範囲外です。ただし、実装者は、最適に調整された応答を決定できない場合の応答のSCOPE PREFIX-LENGTHの選択と、TTLの寿命全体に対する影響を慎重に検討することをお勧めします。
Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.
権威ネームサーバーは、1つの調整応答がIPv4 / 20などの比較的広いアドレス範囲に適している場合がありますが、/ 20内のいくつかの/ 24範囲などの一部の例外は除きます。短いプレフィックス長で応答される前に、すべての長いプレフィックス長のクエリが到着することは保証できないため、権威ネームサーバーはプレフィックスをオーバーラップしてはなりません（MUST NOT）。
When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:
権威ネームサーバーの接頭辞の長さが長いテーラードレスポンス内に長い接頭辞の長さのテーラードレスポンスがある場合、実装は次のいずれかになります。
1. Deaggregate the shorter prefix response into multiple longer prefix responses, or
1. 短い接頭辞応答を複数の長い接頭辞応答に分解する、または
2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.
2. クエリの順序によってどの回答がキャッシュされるかが決まることをオペレーターに警告し、警告して続行するか、これをエラーとして扱い、構成のロードを拒否します。
This choice should be documented for the operator, for example, in the user manual.
この選択は、オペレーターのために、例えばユーザーマニュアルに文書化する必要があります。
When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.
重複を修正するためにデアグリゲーションする場合、同じ回答の複数のコピーを持つことから生じるオーバーヘッドを削減するために、アドレス空間をカバーするのに必要な最小限のものを使用するようにプレフィックス長を最適化する必要があります。簡単な例として、1.2.0 / 20の調整済み応答がAであるが、Bに1.2.3 / 24の例外が1つある場合、権限のあるネームサーバーは1.2.0 / 23、1.2の調整済み応答を提供する必要があります。 2 / 24、1.2.4 / 22、および1.2.8 / 21はすべてAを指し、1.2.3 / 24はBを指します。
When an Intermediate Nameserver uses ECS, whether it passes an ECS option in its own response to its client is predicated on whether the client originally included the option. Because a client that did not use an ECS option might not be able to understand it, the server MUST NOT provide one in its response. If the client query did include the option, the server MUST include one in its response, especially as it could be talking to a Forwarding Resolver, which would need the information for its own caching.
中間ネームサーバーがECSを使用する場合、クライアントへの独自の応答でECSオプションを渡すかどうかは、クライアントが最初にオプションを含めたかどうかに基づいています。 ECSオプションを使用しなかったクライアントはそれを理解できない可能性があるため、サーバーは応答でそれを提供してはなりません（MUST NOT）。クライアントクエリにオプションが含まれていた場合、サーバーはその応答にオプションを含める必要があります。特に、転送リゾルバと通信している可能性があるため、独自のキャッシュに情報が必要になります。
If an Intermediate Nameserver receives a response that has a longer SCOPE PREFIX-LENGTH than SOURCE PREFIX-LENGTH that it provided in its query, it SHOULD still provide the result as the answer to the triggering client request even if the client is in a different address range. The Intermediate Nameserver MAY instead opt to retry with a longer SOURCE PREFIX-LENGTH to get a better reply before responding to its client, as long as it does not exceed a SOURCE PREFIX-LENGTH specified in the query that triggered resolution, but this obviously has implications for the latency of the overall lookup.
中間ネームサーバーが、クエリで提供したSOURCE PREFIX-LENGTHよりもSCOPE PREFIX-LENGTHが長い応答を受信した場合、クライアントが別のアドレスにある場合でも、トリガーしているクライアント要求への応答として結果を提供する必要があります（SHOULD）。範囲。中間ネームサーバーは、解決をトリガーしたクエリで指定されたSOURCE PREFIX-LENGTHを超えない限り、代わりに、より長いSOURCE PREFIX-LENGTHで再試行してクライアントに応答する前に、より良い応答を取得することを選択できます（MAY）。ルックアップ全体のレイテンシへの影響。
The logic for using the cache to determine whether the Intermediate Nameserver already knows the response to provide to its client is covered in the next section.
キャッシュを使用して中間ネームサーバーがクライアントに提供する応答をすでに知っているかどうかを判断するロジックについては、次のセクションで説明します。
When an Intermediate Nameserver receives a response containing an ECS option and without the TC bit set, it SHOULD cache the result based on the data in the option. If the TC bit was set, the Intermediate Resolver SHOULD retry the query over TCP to get the complete Answer section for caching.
中間ネームサーバーがECSオプションを含み、TCビットが設定されていない応答を受信した場合、オプションのデータに基づいて結果をキャッシュする必要があります（SHOULD）。 TCビットが設定されている場合、中間リゾルバーは、TCP経由でクエリを再試行して、キャッシュ用の完全な回答セクションを取得する必要があります（SHOULD）。
If FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of ADDRESS in the response don't match the non-zero fields in the corresponding query, the full response MUST be dropped, as described in Section 11. In a response to a query that specified only SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS fields MUST contain the appropriate non-zero information that the Authoritative Nameserver used to generate the answer, so that it can be cached accordingly.
応答のADDRESSのFAMILY、SOURCE PREFIX-LENGTH、およびSOURCE PREFIX-LENGTHビットが対応するクエリのゼロ以外のフィールドと一致しない場合は、セクション11で説明されているように、完全な応答をドロップする必要があります。プライバシーマスキングのSOURCE PREFIX-LENGTHのみを指定したクエリ、FAMILYおよびADDRESSフィールドには、権威ネームサーバーが回答を生成するために使用した適切なゼロ以外の情報が含まれている必要があります。
If no ECS option is contained in the response, the Intermediate Nameserver SHOULD treat this as being equivalent to having received a SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client addresses. See further discussion on the security implications of this in Section 11.
ECSオプションが応答に含まれていない場合、中間ネームサーバーはこれを、すべてのクライアントアドレスに適した応答である0のSCOPE PREFIX-LENGTHを受信したものと同等に扱う必要があります（SHOULD）。これのセキュリティへの影響については、セクション11で詳しく説明します。
If a REFUSED response is received from an Authoritative Nameserver, an ECS-aware resolver MUST retry the query without ECS to distinguish the response from one where the Authoritative Nameserver is not responsible for the name, which is a common convention for the REFUSED status. Similarly, a client of a Recursive Resolver SHOULD retry after receiving a REFUSED response because it is not sufficiently clear whether the REFUSED response was because of the ECS option or some other reason.
権限のあるネームサーバーからREFUSED応答を受信した場合、ECS対応のリゾルバーはECSなしでクエリを再試行して、応答を、権限のあるネームサーバーが名前に関与しないものと区別する必要があります。これは、REFUSEDステータスの一般的な規則です。同様に、再帰リゾルバーのクライアントは、REFUSED応答がECSオプションによるものか、その他の理由によるものかが十分に明確でないため、REFUSED応答の受信後に再試行する必要があります（SHOULD）。
In the cache, all resource records in the Answer section MUST be tied to the network specified in the response. The appropriate prefix length depends on the relationship between SOURCE PREFIX-LENGTH, SCOPE PREFIX-LENGTH, and the maximum cacheable prefix length configured for the cache.
キャッシュでは、Answerセクションのすべてのリソースレコードが、応答で指定されたネットワークに関連付けられている必要があります。適切なプレフィックス長は、SOURCE PREFIX-LENGTH、SCOPE PREFIX-LENGTH、およびキャッシュに構成されたキャッシュ可能な最大プレフィックス長の関係によって異なります。
If SCOPE PREFIX-LENGTH is not longer than SOURCE PREFIX-LENGTH, store SCOPE PREFIX-LENGTH bits of ADDRESS, and then mark the response as valid for all addresses that fall within that range.
SCOPE PREFIX-LENGTHがSOURCE PREFIX-LENGTHより長くない場合は、ADDRESSのSCOPE PREFIX-LENGTHビットを格納し、その範囲内にあるすべてのアドレスに対して応答を有効としてマークします。
Similarly, if SOURCE PREFIX-LENGTH is the maximum configured for the cache, store SOURCE PREFIX-LENGTH bits of ADDRESS, and then mark the response as valid for all addresses that fall within that range.
同様に、SOURCE PREFIX-LENGTHがキャッシュに構成された最大値である場合、ADDRESSのSOURCE PREFIX-LENGTHビットを格納し、その範囲内にあるすべてのアドレスに対して応答を有効としてマークします。
If SOURCE PREFIX-LENGTH is shorter than the configured maximum and SCOPE PREFIX-LENGTH is longer than SOURCE PREFIX-LENGTH, store SOURCE PREFIX-LENGTH bits of ADDRESS, and then mark the response as valid only to answer client queries that specify exactly the same SOURCE PREFIX-LENGTH in their own ECS option.
SOURCE PREFIX-LENGTHが構成された最大値より短く、SCOPE PREFIX-LENGTHがSOURCE PREFIX-LENGTHより長い場合は、ADDRESSのSOURCE PREFIX-LENGTHビットを格納し、応答を有効とマークして、まったく同じものを指定するクライアントクエリに応答する独自のECSオプションのSOURCE PREFIX-LENGTH。
The handling of DNSSEC-related records in the Answer section was unspecified in the original draft version of this document and is inconsistently handled in existing implementations. A Resource Record Signature (RRSIG) must obviously be tied to the RRset that it signs, but it is RECOMMENDED that all other DNSSEC records be scoped at /0. See Section 9 for more information.
回答セクションのDNSSEC関連レコードの処理は、このドキュメントの元のドラフトバージョンでは指定されておらず、既存の実装では一貫して処理されていません。リソースレコード署名（RRSIG）は、署名するRRsetに明らかに関連付けられている必要がありますが、他のすべてのDNSSECレコードのスコープを/ 0にすることをお勧めします。詳細については、セクション9を参照してください。
Note that the Additional and Authority sections from a DNS response message are specifically excluded here. Any records from these sections MUST NOT be tied to a network. See Section 7.4 for more information.
ここでは、DNS応答メッセージの「追加」セクションと「権限」セクションが明確に除外されていることに注意してください。これらのセクションのレコードは、ネットワークに関連付けてはいけません。詳細は、7.4項を参照してください。
Records that are cached as /0 because of a query's SOURCE PREFIX-LENGTH of 0 MUST be distinguished from those that are cached as /0 because of a response's SCOPE PREFIX-LENGTH of 0. The former should only be used for other /0 queries that the Intermediate Resolver receives, but the latter is suitable as a response for all networks.
クエリのSOURCE PREFIX-LENGTHが0であるために/ 0としてキャッシュされるレコードは、応答のSCOPE PREFIX-LENGTHが0であるために/ 0としてキャッシュされるレコードと区別する必要があります。前者は他の/ 0クエリにのみ使用する必要があります中間リゾルバが受信しますが、後者はすべてのネットワークの応答として適しています。
Although omitting network-specific caching will significantly simplify an implementation, the resulting drop in cache hits is very likely to defeat most latency benefits provided by ECS. Therefore, implementing full caching support as described in this section is strongly RECOMMENDED.
ネットワーク固有のキャッシュを省略すると実装が大幅に簡素化されますが、結果としてキャッシュヒットが減少すると、ECSによって提供されるほとんどの遅延の利点が失われる可能性が高くなります。したがって、このセクションで説明するように完全なキャッシュサポートを実装することを強くお勧めします。
Enabling support for ECS in an Intermediate Nameserver will significantly increase the size of the cache, reduce the number of results that can be served from cache, and increase the load on the server. Implementing the mitigation techniques described in Section 11 is strongly recommended. For cache size issues, implementers should consider data storage formats that allow the same answer data to be shared among multiple prefixes.
中間ネームサーバーでECSのサポートを有効にすると、キャッシュのサイズが大幅に増加し、キャッシュから提供できる結果の数が減少し、サーバーの負荷が増加します。セクション11で説明されている緩和手法の実装を強くお勧めします。キャッシュサイズの問題については、実装者は、同じ応答データを複数のプレフィックス間で共有できるようにするデータストレージ形式を検討する必要があります。
Cache lookups are first done as usual for a DNS query, using the query tuple of <name, type, class>. Then, the appropriate RRset MUST be chosen based on the longest prefix matching. The client address to use for comparison will depend on whether the Intermediate Nameserver received an ECS option in its client query.
キャッシュルックアップは、<name、type、class>のクエリタプルを使用して、DNSクエリの通常どおり最初に実行されます。次に、最長のプレフィックスマッチングに基づいて適切なRRsetを選択する必要があります。比較に使用するクライアントアドレスは、中間ネームサーバーがクライアントクエリでECSオプションを受信したかどうかによって異なります。
o If no ECS option was provided, the client's address is used.
o ECSオプションが指定されていない場合は、クライアントのアドレスが使用されます。
o If there was an ECS option specifying SOURCE PREFIX-LENGTH and ADDRESS covering the client's address, the client address is used but SOURCE PREFIX-LENGTH is initially ignored. If no covering entry is found and SOURCE PREFIX-LENGTH is shorter than the configured maximum length allowed for the cache, repeat the cache lookup for an entry that exactly matches SOURCE PREFIX-LENGTH. These special entries, which do not cover longer prefix lengths, occur as described in the previous section.
o クライアントのアドレスをカバーするSOURCE PREFIX-LENGTHおよびADDRESSを指定するECSオプションがあった場合、クライアントアドレスが使用されますが、SOURCE PREFIX-LENGTHは最初は無視されます。対象となるエントリが見つからず、SOURCE PREFIX-LENGTHがキャッシュに設定されている最大長より短い場合は、SOURCE PREFIX-LENGTHと完全に一致するエントリに対してキャッシュルックアップを繰り返します。これらの特別なエントリは、より長いプレフィックス長を対象としていないため、前のセクションで説明したように発生します。
o If there was an ECS option with an ADDRESS, the ADDRESS from it MAY be used if the local policy allows. The policy can vary depending on the agreements the operator of the Intermediate Nameserver has with Authoritative Nameserver operators; see Section 12.2. If the policy does not allow it, a REFUSED response SHOULD be sent. See Section 7.5 for more information.
o ADDRESSを指定したECSオプションがあった場合、ローカルポリシーで許可されていれば、そこからのADDRESSを使用できます。ポリシーは、中間ネームサーバーのオペレーターが権限のあるネームサーバーのオペレーターと交わしている合意によって異なります。セクション12.2を参照してください。ポリシーで許可されていない場合は、REFUSED応答を送信する必要があります（SHOULD）。詳細については、セクション7.5を参照してください。
If a matching network is found and the relevant data is unexpired, the response is generated as per Section 7.2.
一致するネットワークが見つかり、関連データが期限切れでない場合、セクション7.2に従って応答が生成されます。
If no matching network is found, the Intermediate Nameserver MUST perform resolution as usual. This is necessary to avoid Tailored Responses in the cache from being returned to the wrong clients, and to avoid a single query coming from a client on a different network from polluting the cache with a Tailored Response for all the users of that resolver.
一致するネットワークが見つからない場合、中間ネームサーバーは通常どおり解決を実行する必要があります。これは、キャッシュ内のテイラードレスポンスが間違ったクライアントに返されるのを防ぎ、別のネットワーク上のクライアントからの単一のクエリが、そのリゾルバーのすべてのユーザーのテイラードレスポンスでキャッシュを汚染するのを防ぐために必要です。
The prohibition against tying ECS data to records from the Authority and Additional sections left an unfortunate ambiguity in the original specification, primarily with regard to negative answers. The expectation of the original authors was that ECS would only really be used for address requests and the positive result in the response's Answer section, which was the use case that was driving the definition of the protocol.
ECSデータをAuthorityおよびAdditionalセクションからのレコードに結びつけることの禁止は、主に否定的な回答に関して、元の仕様にあいまいなあいまいさを残しました。元の作成者の予想では、ECSは実際にはアドレス要求にのみ使用され、肯定的な結果は応答のAnswerセクションにあります。これは、プロトコルの定義を推進するユースケースでした。
For negative answers, some independent implementations of both resolvers and authorities did not see the section restriction as necessarily meaning that a given name and type must only have either positive ECS-tagged answers or a negative answer. They support being able to tell one part of the network that the data does not exist, while telling another part of the network that it does.
否定的な回答の場合、リゾルバーと当局の両方の一部の独立した実装では、セクションの制限が必ずしも指定された名前とタイプに肯定的なECSタグ付き回答または否定的な回答のいずれかのみが含まれることを意味するとは見なされませんでした。それらは、データが存在しないことをネットワークの別の部分に伝えながら、データが存在しないことをネットワークの一部に伝えることができることをサポートします。
Several other implementations, however, do not support being able to mix positive and negative answers; thus, interoperability is a problem. It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.
ただし、他のいくつかの実装では、肯定的な回答と否定的な回答を混在させることができません。したがって、相互運用性が問題になります。否定的な回答に関する特定の動作に依存しないことをお勧めしますが、権威ネームサーバーは、中間ネームサーバーがすべての否定的な回答を/ 0として扱うことを控えめに期待する必要があります。したがって、それに応じてSCOPE PREFIX-LENGTHを設定する必要があります。
This issue is expected to be revisited in a future revision of the protocol, possibly blessing the mixing of positive and negative answers. There are implications for cache data structures that developers should consider when writing new ECS code.
この問題は、プロトコルの将来の改訂で再検討されることが期待されており、肯定的回答と否定的回答の混合を祝福する可能性があります。キャッシュデータ構造には、新しいECSコードを作成するときに開発者が考慮すべき影響があります。
The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations. A Recursive Resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation as though it were zero.
代表団の訴訟は、簡単に解読することができます。運用上、権限のあるサーバーがアドレス情報を使用してカスタマイズされた委任を提供している場合、次の反復クエリの回答を使用するのはリゾルバーです。したがって、追加セクションのアドレスはECSデータを無視する必要があり（SHOULD）、権威ネームサーバーは委任に対してゼロのSCOPE PREFIX-LENGTHを返す必要があります（SHOULD）。再帰リゾルバは、委任内のゼロ以外のSCOPE PREFIX LENGTHをゼロであるかのように扱う必要があります（SHOULD）。
Generally, ECS options will only be present in DNS messages between a Recursive Resolver and an Authoritative Nameserver, i.e., one hop. However, in certain configurations, for example, multi-tier nameserver setups, it may be necessary to implement transitive behavior on Intermediate Nameservers.
一般に、ECSオプションは、再帰リゾルバーと権威ネームサーバー間のDNSメッセージ、つまり1ホップにのみ存在します。ただし、特定の構成（多層ネームサーバーのセットアップなど）では、中間ネームサーバーで推移的な動作を実装する必要がある場合があります。
Any Intermediate Nameserver that forwards ECS options received from its clients MUST fully implement the caching behavior described in Section 7.3.
クライアントから受信したECSオプションを転送する中間ネームサーバーは、7.3で説明されているキャッシュ動作を完全に実装する必要があります。
An Intermediate Nameserver MAY forward ECS options with address information. This information MAY match the source IP address of the incoming query, and MAY have more or fewer address bits than the nameserver would normally include in a locally originated ECS option. If an Intermediate Nameserver receives a query with SOURCE PREFIX-LENGTH set to 0, it MUST NOT include client address information in queries made to resolve that client's request (see Section 7.1.2).
中間ネームサーバーは、アドレス情報を含むECSオプションを転送してもよい（MAY）。この情報は着信クエリの送信元IPアドレスと一致する場合があり、ネームサーバーがローカルで生成されたECSオプションに通常含めるよりも多いまたは少ないアドレスビットを持つ場合があります。中間ネームサーバーがSOURCE PREFIX-LENGTHが0に設定されたクエリを受信する場合、そのクライアントの要求を解決するために行われるクエリにクライアントアドレス情報を含めてはなりません（セクション7.1.2を参照）。
If, for any reason, the Intermediate Nameserver does not want to use the information in an ECS option it receives (too little address information, network address from a range not authorized to use the server, private/unroutable address space, etc.), it SHOULD drop the query and return a REFUSED response. Note again that a query MUST NOT be refused solely because it provides 0 address bits.
何らかの理由で、中間ネームサーバーが受信するECSオプションの情報を使用したくない場合（アドレス情報が少なすぎる、サーバーの使用が許可されていない範囲のネットワークアドレス、プライベート/ルーティングできないアドレススペースなど）、クエリを削除し、REFUSED応答を返す必要があります。クエリは、アドレスビットが0であることだけを理由として拒否されてはならないことに注意してください。
Be aware that at least one major existing implementation does not return REFUSED and instead just processes the query as though the problematic information were not present. This can lead to anomalous situations, such as a response from the Intermediate Nameserver that indicates it is tailored for one network (the one passed in the original query, since the ADDRESS must match) when actually it is for another network (the one which contains the address that the Intermediate Nameserver saw as making the query).
少なくとも1つの既存の主要な実装がREFUSEDを返さず、問題のある情報が存在しないかのようにクエリを処理するだけであることに注意してください。これは、実際には別のネットワーク（以下を含むネットワーク）の場合に、1つのネットワーク（元のクエリで渡されたもので、ADDRESSが一致する必要がある）に合わせて調整されていることを示す中間ネームサーバーからの応答など、異常な状況を引き起こす可能性があります。中間ネームサーバーがクエリを実行したと見なしたアドレス）。
IANA has assigned option code 8 in the "DNS EDNS0 Option Codes (OPT)" registry to edns-client-subnet.
IANAは、「DNS EDNS0オプションコード（OPT）」レジストリのオプションコード8をedns-client-subnetに割り当てました。
IANA has updated the reference to refer to this RFC.
IANAは、このRFCを参照するように参照を更新しました。
The presence or absence of an EDNS0 OPT resource record ([RFC6891]) containing an ECS option in a DNS query does not change the usage of the resource records and mechanisms used to provide data origin authentication and data integrity to the DNS, as described in [RFC4033], [RFC4034], and [RFC4035]. OPT records are not signed.
DNSクエリにECSオプションを含むEDNS0 OPTリソースレコード（[RFC6891]）が存在してもしなくても、リソースレコードの使用法と、DNSにデータ発信元認証とデータ整合性を提供するために使用されるメカニズムは変更されません。 [RFC4033]、[RFC4034]、および[RFC4035]。 OPTレコードは署名されていません。
Use of this option, however, does imply increased DNS traffic between any given Recursive Resolver and Authoritative Nameserver, which could be another barrier to further DNSSEC adoption in this area.
ただし、このオプションを使用すると、指定された再帰リゾルバーと権威ネームサーバー間のDNSトラフィックが増加することを意味します。これは、この領域でDNSSECをさらに採用するためのもう1つの障壁となる可能性があります。
The initial version of this protocol, against which several Authoritative and Recursive Nameserver implementations were written, did not discuss the handling of DNSSEC RRs; thus, it is expected that there are operational inconsistencies in handling them.
このプロトコルの最初のバージョンは、いくつかの権威および再帰的なネームサーバーの実装に対して作成されましたが、DNSSEC RRの処理については説明していませんでした。したがって、それらの処理には運用上の不整合があることが予想されます。
Given the intention of this document to describe how ECS is currently deployed, specifying new requirements for DNSSEC handling is out of scope. However, some recommendations can be made as to what is most likely to result in successful interoperation for a DNSSEC-signed ECS zone, mainly from the point of view of Authoritative Nameservers.
このドキュメントでは、ECSが現在どのように展開されているかを説明することを意図しているため、DNSSEC処理の新しい要件の指定は範囲外です。ただし、主に権威ネームサーバーの観点から、DNSSECで署名されたECSゾーンの相互運用が成功する可能性が最も高いものについて、いくつかの推奨事項を作成できます。
Most DNSSEC records SHOULD be scoped at /0, except for the RRSIG records, which MUST be tied to the RRset that they sign in a Tailored Response. While it is possible to conceive of a way to get other DNSSEC records working in a network-specific way, it has little apparent benefit or likelihood of working with deployed validating resolvers.
ほとんどのDNSSECレコードは、/ 0をスコープとする必要があります（ただし、RRSIGレコードは、カスタマイズされた応答でサインインするRRsetに関連付ける必要があります）。他のDNSSECレコードをネットワーク固有の方法で機能させる方法を想像することは可能ですが、展開された検証リゾルバーを操作する明らかな利点や可能性はほとんどありません。
One further implication here is that, despite the discussion about negative answers in Section 7.4, scoping NextSECure (NSEC) or NSEC3 records at /0 per the previous paragraph necessarily implies that DNSSEC-signed negative answers must also be network-invariant.
ここでのもう1つの意味は、セクション7.4での否定的な回答についての議論にもかかわらず、前の段落の/ 0でのNextSECure（NSEC）またはNSEC3レコードのスコープ指定は、DNSSEC署名された否定的な回答もネットワーク不変でなければならないことを必然的に意味することです。
Special awareness of ECS in devices that perform Network Address Translation (NAT) as described in [RFC2663] is not required; queries can be passed through as is. The client's network address SHOULD NOT be added, and existing ECS options, if present, SHOULD NOT be modified by NAT devices.
[RFC2663]で説明されているように、ネットワークアドレス変換（NAT）を実行するデバイスのECSを特別に認識する必要はありません。クエリはそのままパススルーできます。クライアントのネットワークアドレスは追加してはならず（SHOULD NOT）、既存のECSオプションが存在する場合は、NATデバイスによって変更してはなりません（SHOULD NOT）。
In large-scale global networks behind a NAT device (but, for example with Centralized Resolver infrastructure), an internal Intermediate Nameserver might have detailed network layout information, and may know which external subnets are used for egress traffic by each internal network. In such cases, the Intermediate Nameserver MAY use that information when originating ECS options.
NATデバイスの背後にある大規模なグローバルネットワークでは（ただし、集中型リゾルバーインフラストラクチャを使用している場合など）、内部の中間ネームサーバーに詳細なネットワークレイアウト情報があり、各内部ネットワークによる下りトラフィックにどの外部サブネットが使用されているかを知っている場合があります。このような場合、中間ネームサーバーは、ECSオプションを生成するときにその情報を使用できます。
In other cases, if a Recursive Resolver knows that it is situated behind a NAT device, it SHOULD NOT originate ECS options with their external IP address and instead rely on downstream Intermediate Nameservers to do so. It MAY, however, choose to include the option with their internal address for the purposes of signaling its own limit for SOURCE PREFIX-LENGTH.
他のケースでは、再帰リゾルバーがNATデバイスの背後にあることを知っている場合、外部IPアドレスを使用してECSオプションを生成せず、代わりにダウンストリームの中間ネームサーバーに依存する必要があります。ただし、SOURCE PREFIX-LENGTHの独自の制限を通知する目的で、内部アドレスとともにオプションを含めることを選択する場合があります。
Full treatment of special network addresses is beyond the scope of this document; handling them will likely differ according to the operational environments of each service provider. As a general guideline, if an Authoritative Nameserver on the publicly routed Internet receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] private address space, it SHOULD ignore ADDRESS and look up its answer based on the address of the Recursive Resolver. In the response, it SHOULD set SCOPE PREFIX-LENGTH to cover all of the relevant private space. For example, a query for ADDRESS 10.1.2.0 with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX-LENGTH of 8. The Intermediate Nameserver MAY elect to cache the answer under one entry for special-purpose addresses [RFC6890]; see Section 11.3 of this document.
特別なネットワークアドレスの完全な取り扱いは、このドキュメントの範囲外です。これらの処理は、各サービスプロバイダーの運用環境によって異なる可能性があります。一般的なガイドラインとして、公にルーティングされたインターネット上の権威ネームサーバーが[RFC1918]または[RFC4193]プライベートアドレス空間でADDRESSを指定するクエリを受信した場合、ADDRESSを無視し、再帰リゾルバーのアドレスに基づいて回答を検索する必要があります。 。応答では、関連するすべてのプライベートスペースをカバーするようにSCOPE PREFIX-LENGTHを設定する必要があります（SHOULD）。たとえば、SOURCE PREFIX-LENGTHが24のADDRESS 10.1.2.0のクエリは、返されるSCOPE PREFIX-LENGTHが8になります。中間ネームサーバーは、専用アドレス[RFC6890]の1つのエントリの下に回答をキャッシュすることを選択できます。このドキュメントのセクション11.3を参照してください。
With the ECS option, the network address of the client that initiated the resolution becomes visible to all servers involved in the resolution process. Additionally, it will be visible from any network traversed by the DNS packets.
ECSオプションを使用すると、解決を開始したクライアントのネットワークアドレスが、解決プロセスに関与するすべてのサーバーに表示されます。さらに、DNSパケットが通過するすべてのネットワークから表示されます。
To protect users' privacy, Recursive Resolvers are strongly encouraged to conceal part of the user's IP address by truncating IPv4 addresses to 24 bits. 56 bits are recommended for IPv6, based on [RFC6177].
ユーザーのプライバシーを保護するために、再帰リゾルバーは、IPv4アドレスを24ビットに切り捨てることによってユーザーのIPアドレスの一部を隠すことを強くお勧めします。 [RFC6177]に基づくIPv6には56ビットが推奨されます。
ISPs should have more detailed knowledge of their own networks. That is, they might know that all 24-bit prefixes in a /20 are in the same area. In those cases, for optimal cache utilization and improved privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in this /20 to just 20 bits, instead of 24 as recommended above.
ISPは、自社のネットワークについてより詳細な知識を持っている必要があります。つまり、/ 20内のすべての24ビットプレフィックスが同じエリアにあることを知っている可能性があります。それらの場合、最適なキャッシュ利用と改善されたプライバシーのために、ISPの再帰リゾルバーはこの/ 20のIPアドレスを上記の推奨の24ではなく20ビットに切り捨てるべきです（SHOULD）。
Users who wish their full IP address to be hidden need to configure their client software, if possible, to include an ECS option specifying the wildcard address (i.e., a SOURCE PREFIX-LENGTH of 0).
完全なIPアドレスを非表示にすることを希望するユーザーは、可能であれば、ワイルドカードアドレスを指定するECSオプション（つまり、SOURCE PREFIX-LENGTHが0）を含めるようにクライアントソフトウェアを構成する必要があります。
As described in previous sections, this option will be forwarded across all the Recursive Resolvers supporting ECS, which MUST NOT modify it to include the network address of the client.
前のセクションで説明したように、このオプションは、ECSをサポートするすべての再帰リゾルバー全体に転送されます。クライアントのネットワークアドレスを含めるように変更しないでください。
Note that even without an ECS option, any server queried directly by the user will be able to see the full client IP address. Recursive Resolvers or Authoritative Nameservers MAY use the source IP address of queries to return a cached entry or to generate a Tailored Response that best matches the query.
ECSオプションがなくても、ユーザーが直接クエリしたサーバーは完全なクライアントIPアドレスを確認できることに注意してください。再帰リゾルバーまたは権限のあるネームサーバーは、クエリのソースIPアドレスを使用して、キャッシュされたエントリを返すか、クエリに最も一致する調整された応答を生成できます。
ECS adds information to the DNS query tuple (q-tuple). This allows an attacker to send a caching Intermediate Nameserver multiple queries with spoofed IP addresses either in the ECS option or as the source IP. These queries will trigger multiple outgoing queries with the same name, type, and class, just with different address information in the ECS option.
ECSは、DNSクエリタプル（q-tuple）に情報を追加します。これにより、攻撃者はECSオプションで、またはソースIPとして偽装されたIPアドレスを使用して、キャッシング中間ネームサーバーに複数のクエリを送信できます。これらのクエリは、ECSオプションのアドレス情報が異なるだけで、同じ名前、タイプ、クラスの複数の送信クエリをトリガーします。
With multiple queries for the same name in flight, the attacker has a higher chance of success to send a matching response with SCOPE PREFIX-LENGTH set to 0 to get it cached for all hosts.
実行中の同じ名前に対する複数のクエリを使用すると、攻撃者はSCOPE PREFIX-LENGTHを0に設定して一致する応答を送信し、すべてのホストでキャッシュされるようにする可能性が高くなります。
To counter this, the ECS option in a response packet MUST contain the full FAMILY, ADDRESS, and SOURCE PREFIX-LENGTH fields from the corresponding query. Intermediate Nameservers processing a response MUST verify that these match, and they SHOULD discard the entire response if they do not.
これに対抗するには、応答パケットのECSオプションに、対応するクエリの完全なFAMILY、ADDRESS、およびSOURCE PREFIX-LENGTHフィールドを含める必要があります。応答を処理する中間ネームサーバーは、これらが一致することを確認する必要があります。一致しない場合は、応答全体を破棄する必要があります（SHOULD）。
The requirement to discard is categorized as "SHOULD" instead of "MUST" because it stands in opposition to the instruction in Section 7.3, which states that a response lacking an ECS option should be treated as though it had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an attacker does not need to worry about matching the original ECS option data and just needs to flood back responses that have no ECS option at all.
破棄の要件は、7.3節の指示に対抗するため、「必須」ではなく「SHOULD」として分類されます。これは、ECSオプションのない応答は、SCOPE PREFIX-LENGTHの0.これが常に当てはまる場合、攻撃者は元のECSオプションデータの照合について心配する必要はなく、ECSオプションがまったくない応答をフラッドバックするだけで済みます。
This type of attack could be detected in ongoing operations by marking whether the responding nameserver had previously been sending ECS options and/or by taking note of an incoming flood of bogus responses and flagging the relevant query for re-resolution. This type of detection is more complex than existing nameserver responses to spoof floods, and it would also need to be sensitive to a nameserver legitimately stopping ECS replies even though it had previously given them.
このタイプの攻撃は、応答中のネームサーバーが以前にECSオプションを送信していたかどうかをマークすることにより、および/または受信した偽の応答のフラッドを記録し、関連するクエリに再解決のフラグを立てることにより、進行中の操作で検出できます。このタイプの検出は、スプーフィングフラッドに対する既存のネームサーバーの応答よりも複雑であり、以前に与えられていたとしても、ネームサーバーがECS応答を合法的に停止することに敏感である必要があります。
It is simple for an arbitrary resolver or client to provide false information in the ECS option, or to send UDP packets with forged source IP addresses.
任意のリゾルバーまたはクライアントがECSオプションで誤った情報を提供したり、偽造されたソースIPアドレスでUDPパケットを送信したりするのは簡単です。
This could be used to:
これは次の目的で使用できます。
o pollute the cache of Intermediate Resolvers by filling it with results that will rarely (if ever) be used.
o Intermediate Resolversのキャッシュを、めったに使われない結果で埋めることで汚染します。
o reverse-engineer the algorithms (or data) used by the Authoritative Nameserver to calculate Tailored Responses.
o Authoritative Nameserverがテイラードレスポンスを計算するために使用するアルゴリズム（またはデータ）をリバースエンジニアリングします。
o mount a denial-of-service attack against an Intermediate Nameserver by forcing it to perform many more recursive queries than it would normally do, due to how caching is handled for queries containing the ECS option.
o ECSオプションを含むクエリのキャッシュの処理方法により、通常よりも多くの再帰クエリを実行するように強制することにより、中間ネームサーバーに対してサービス拒否攻撃を仕掛けます。
Even without malicious intent, Centralized Resolvers providing answers to clients in multiple networks will need to cache different responses for different networks, putting more memory pressure on the cache.
悪意がなくても、複数のネットワークのクライアントに回答を提供する集中型リゾルバーは、異なるネットワークに対して異なる応答をキャッシュする必要があり、キャッシュにより多くのメモリ負荷をかけます。
To mitigate those problems:
これらの問題を軽減するには：
o Recursive Resolvers implementing ECS should only enable it in deployments where it is expected to bring clear advantages to the end users, such as when expecting clients from a variety of networks or from a wide geographical area. Due to the high cache pressure introduced by ECS, the feature SHOULD be disabled in all default configurations.
o ECSを実装する再帰リゾルバーは、さまざまなネットワークや広い地理的領域のクライアントを期待する場合など、エンドユーザーに明確な利点をもたらすことが期待される展開でのみ有効にする必要があります。 ECSによって導入される高いキャッシュプレッシャーのため、この機能はすべてのデフォルト構成で無効にする必要があります（SHOULD）。
o Recursive Resolvers SHOULD limit the number of networks and answers they keep in the cache for any given query.
o 再帰リゾルバは、特定のクエリに対してキャッシュに保持するネットワークと回答の数を制限する必要があります（SHOULD）。
o Recursive Resolvers SHOULD limit the total number of different networks that they keep in cache.
o 再帰リゾルバは、キャッシュに保持するさまざまなネットワークの総数を制限する必要があります（SHOULD）。
o Recursive Resolvers MUST NOT send an ECS option with SOURCE PREFIX-LENGTH providing more bits in ADDRESS than they are willing to cache responses for.
o 再帰リゾルバーは、応答をキャッシュするよりも多くのビットをADDRESSに提供するSOURCE PREFIX-LENGTHでECSオプションを送信してはなりません（MUST NOT）。
o Recursive Resolvers should implement algorithms to improve the cache hit rate, given the size constraints indicated above. Recursive Resolvers MAY, for example, decide to discard more-specific cache entries first.
o 上記のサイズ制限がある場合、再帰リゾルバはアルゴリズムを実装してキャッシュヒット率を向上させる必要があります。たとえば、再帰リゾルバは、より具体的なキャッシュエントリを最初に破棄することを決定する場合があります。
o Authoritative Nameservers and Recursive Resolvers should discard ECS options that are either obviously forged or otherwise known to be wrong. They SHOULD at least treat unroutable addresses, such as some of the address blocks defined in [RFC6890], as equivalent to the Recursive Resolver's own identity. They SHOULD ignore and never forward ECS options specifying other routable addresses that are known not to be served by the query source.
o 権威ネームサーバーと再帰リゾルバーは、明らかに偽造されているか、そうでなければ間違っていることがわかっているECSオプションを破棄する必要があります。それらは、[RFC6890]で定義されているいくつかのアドレスブロックなどのルーティング不可能なアドレスを、再帰リゾルバー自身のアイデンティティと同等のものとして扱う必要があります（SHOULD）。クエリソースから提供されないことがわかっている他のルーティング可能なアドレスを指定するECSオプションを無視して転送しないでください。
o The ECS option is just a hint to Authoritative Nameservers for customizing results. They can decide to ignore the content of the ECS option based on blacklists or whitelists, rate-limiting mechanisms, or any other logic implemented in the software.
o ECSオプションは、結果をカスタマイズするための権威ネームサーバーへのヒントにすぎません。彼らは、ブラックリストまたはホワイトリスト、レート制限メカニズム、またはソフトウェアに実装されているその他のロジックに基づいて、ECSオプションのコンテンツを無視することを決定できます。
When implementing a Recursive Resolver, there are two strategies on deciding when to include an ECS option in a query. At this stage, it's not clear which strategy is best.
再帰リゾルバーを実装する場合、クエリにECSオプションを含めるタイミングを決定する方法は2つあります。この段階では、どの戦略が最適かは明らかではありません。
A Recursive Resolver can send the ECS option with every outgoing query. However, it is RECOMMENDED that resolvers remember which Authoritative Nameservers did not return the option with their response and omit client address information from subsequent queries to those nameservers.
再帰リゾルバーは、すべての発信クエリでECSオプションを送信できます。ただし、リゾルバーはどの権威ネームサーバーがオプションを返さずに応答したかを記憶し、それらのネームサーバーへの後続のクエリからクライアントアドレス情報を省略することをお勧めします。
Additionally, Recursive Resolvers SHOULD be configured never to send the option when querying root, top-level, and effective top-level (i.e., "public suffix" [Public_Suffix_List]) domain servers. These domains are delegation-centric and are very unlikely to generate different responses based on the address of the client.
さらに、再帰リゾルバーは、ルート、トップレベル、および実効トップレベル（つまり、「パブリックサフィックス」[Public_Suffix_List]）ドメインサーバーをクエリするときにオプションを送信しないように構成する必要があります（SHOULD）。これらのドメインは委任中心であり、クライアントのアドレスに基づいて異なる応答を生成することはほとんどありません。
When probing, it is important that several things are probed: support for ECS, support for EDNS0, support for EDNS0 options, or possibly an unreachable nameserver. Various implementations are known to drop DNS packets with OPT RRs (with or without options), thus several probes are required to discover what is supported.
調査する場合、ECSのサポート、EDNS0のサポート、EDNS0オプションのサポート、または到達不能なネームサーバーなど、いくつかの事項を調査することが重要です。 OPT RR（オプションの有無にかかわらず）を使用してDNSパケットをドロップするさまざまな実装が知られているため、サポートされているものを検出するには、いくつかのプローブが必要です。
Probing, if implemented, MUST be repeated periodically, e.g., daily. If an Authoritative Nameserver indicates ECS support for one zone, it is to be expected that the nameserver supports ECS for all of its zones. Likewise, an Authoritative Nameserver that uses ECS information for one of its zones MUST indicate support for the option in all of its responses to ECS queries. If the option is supported but not actually used for generating a response, its SCOPE PREFIX-LENGTH MUST be set to 0.
プロービングは、実装されている場合、定期的に、たとえば毎日繰り返す必要があります。権威ネームサーバーが1つのゾーンのECSサポートを示している場合、ネームサーバーがそのすべてのゾーンのECSをサポートしていることが期待されます。同様に、ゾーンの1つにECS情報を使用する権威ネームサーバーは、ECSクエリに対するすべての応答でオプションのサポートを示す必要があります。オプションがサポートされているが実際に応答の生成に使用されていない場合は、そのSCOPE PREFIX-LENGTHを0に設定する必要があります。
As described previously, it is expected that only a few Recursive Resolvers will need to use ECS, and that it will generally be enabled only if it offers a clear benefit to the users.
前述のように、ECSを使用する必要があるのは少数の再帰リゾルバーだけであり、ユーザーに明確な利点を提供する場合にのみ、通常は有効になります。
To avoid the complexity of implementing a probing and detection mechanism (and the possible query loss/delay that may come with it), an implementation could use a whitelist of Authoritative Nameservers to send the option to, likely specified by their domain name. Implementations MAY also allow additional configuring of this based on other criteria, such as zone or query type. As of the time of this writing, at least one implementation makes use of a whitelist.
プローブおよび検出メカニズムの実装の複雑さ（およびそれに伴う可能性のあるクエリの損失/遅延）を回避するために、実装では、権限ネームサーバーのホワイトリストを使用して、おそらくドメイン名で指定されたオプションを送信できます。実装では、ゾーンやクエリタイプなどの他の基準に基づいて、これを追加構成することもできます（MAY）。この記事の執筆時点では、少なくとも1つの実装がホワイトリストを利用しています。
An advantage of using a whitelist is that partial client address information is only disclosed to nameservers that are known to use the information, improving privacy.
ホワイトリストを使用する利点は、部分的なクライアントアドレス情報が、その情報を使用することがわかっているネームサーバーにのみ開示され、プライバシーが向上することです。
A drawback is scalability. The operator needs to track which Authoritative Nameservers support ECS, making it harder for new Authoritative Nameservers to start using the option.
欠点は拡張性です。オペレーターは、ECSをサポートする権威ネームサーバーを追跡する必要があるため、新しい権威ネームサーバーがオプションの使用を開始するのが難しくなります。
Similarly, Authoritative Nameservers can also use whitelists to limit the feature to only certain clients. For example, a CDN that does not want all of their mapping trivially walked might require a legal agreement with the Recursive Resolver operator, to clearly describe the acceptable use of the feature.
同様に、権威ネームサーバーはホワイトリストを使用して、機能を特定のクライアントのみに制限することもできます。たとえば、すべてのマッピングが簡単に実行されることを望まないCDNは、機能の許容される使用法を明確に説明するために、再帰リゾルバーオペレーターとの法的合意を必要とする場合があります。
The maintenance of access control mechanisms is out of scope for this protocol definition.
アクセス制御メカニズムの保守は、このプロトコル定義の範囲外です。
1. A Stub Resolver, SR, with the IP address 2001:0db8:fd13:4231:2112:8a2e:c37b:7334 tries to resolve www.example.com by forwarding the query to the Recursive Resolver, RNS, asking for recursion.
1. IPアドレス2001：0db8：fd13：4231：2112：8a2e：c37b：7334を持つスタブリゾルバーSRは、再帰を要求する再帰リゾルバーRNSにクエリを転送することにより、www.example.comを解決しようとします。
2. RNS, supporting ECS, looks up www.example.com in its cache. An entry is found neither for www.example.com nor for example.com.
2. ECSをサポートするRNSは、www.example.comをキャッシュで検索します。 www.example.comにもexample.comにもエントリが見つかりません。
3. RNS builds a query to send to the root and .com servers. The implementation of RNS provides facilities so that an administrator can configure it not to forward ECS in certain cases. In particular, RNS is configured not to include an ECS option when talking to Top-Level-Domain or root nameservers, as described in Section 7.1. Thus, no ECS option is added, and resolution is performed as usual.
3. RNSは、ルートサーバーと.comサーバーに送信するクエリを作成します。 RNSの実装は、管理者が特定の場合にECSを転送しないように構成できるように機能を提供します。特に、7.1節で説明したように、トップレベルドメインまたはルートネームサーバーと通信するときに、RNSはECSオプションを含まないように構成されています。したがって、ECSオプションは追加されず、解決は通常どおり実行されます。
4. RNS now knows the next server to query: the Authoritative Nameserver, ANS, responsible for example.com.
4. これで、RNSは次のクエリを行うサーバーを認識します。example.comを担当する権限ネームサーバー、ANS。
5. RNS prepares a new query for www.example.com, including an ECS option with:
5. RNSは、次のECSオプションを含むwww.example.comの新しいクエリを準備します。
* OPTION-CODE set to 8.
* OPTION-CODEは8に設定されています。
* OPTION-LENGTH set to 0x00 0x0b for the following fixed 4 octets plus the 7 octets that will be used for ADDRESS.
* OPTION-LENGTHは、次の固定4オクテットとADDRESSに使用される7オクテットに対して0x00 0x0bに設定されます。
* FAMILY set to 0x00 0x02, as IP is an IPv6 address.
* FAMILYは0x00 0x02に設定されています。これは、IPがIPv6アドレスであるためです。
* SOURCE PREFIX-LENGTH set to 0x38, as RNS is configured to conceal the last 72 bits of every IPv6 address.
* RNSはすべてのIPv6アドレスの最後の72ビットを隠すように構成されているため、SOURCE PREFIX-LENGTHは0x38に設定されています。
* SCOPE PREFIX-LENGTH set to 0x00, as specified by this document for all queries.
* SCOPE PREFIX-LENGTHは0x00に設定され、すべてのクエリに対してこのドキュメントで指定されています。
* ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, providing only the first 56 bits of the IPv6 address.
* ADDRESSを0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42に設定し、IPv6アドレスの最初の56ビットのみを提供します。
6. The query is sent. ANS understands and uses ECS. It parses the ECS option, and generates a Tailored Response.
6. クエリが送信されます。 ANSはECSを理解して使用します。 ECSオプションを解析し、Tailored Responseを生成します。
7. Due its internal implementation, ANS finds a response that is tailored for the whole /16 of the client that performed the query.
7. その内部実装により、ANSは、クエリを実行したクライアントの/ 16全体に合わせて調整された応答を見つけます。
8. ANS adds an ECS option in the response, containing:
8. ANSは、以下を含むECSオプションを応答に追加します。
* OPTION-CODE set to 8.
* OPTION-CODEは8に設定されています。
* OPTION-LENGTH set to 0x00 0x07.
* OPTION-LENGTHは0x00 0x07に設定されています。
* FAMILY set to 0x00 0x02.
* FAMILYは0x00 0x02に設定されています。
* SOURCE PREFIX-LENGTH set to 0x38, copied from the query.
* クエリからコピーされたSOURCE PREFIX-LENGTHが0x38に設定されました。
* SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.
* SCOPE PREFIX-LENGTHは0x30に設定され、/ 48ネットワークを示します。
* ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, copied from the query.
* ADDRESSは0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42に設定され、クエリからコピーされます。
9. RNS receives the response containing an ECS option. It verifies that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. If not, the message is discarded.
9. RNSは、ECSオプションを含む応答を受信します。 FAMILY、SOURCE PREFIX-LENGTH、およびADDRESSがクエリと一致することを確認します。そうでない場合、メッセージは破棄されます。
10. The response is interpreted as usual. Since the response contains an ECS option, ADDRESS, SCOPE PREFIX-LENGTH, and FAMILY in the response are used to cache the entry.
10. 応答は通常どおりに解釈されます。応答にはECSオプションが含まれているため、応答内のADDRESS、SCOPE PREFIX-LENGTH、およびFAMILYを使用してエントリをキャッシュします。
11. RNS sends a response to Stub Resolver, SR, without including an ECS option.
11. RNSは、ECSオプションを含めずに、スタブリゾルバーSRに応答を送信します。
12. RNS receives another query to resolve www.example.com. This time, a response is cached. The response, however, is tied to a particular network. If the client's address matches any network in the cache, then the response is returned from the cache. Otherwise, another query is performed. If multiple results match, the one with the longest SCOPE PREFIX-LENGTH is chosen, as per common best-network-match algorithms.
12. RNSは、www.example.comを解決するための別のクエリを受け取ります。今回は、応答がキャッシュされます。ただし、応答は特定のネットワークに関連付けられています。クライアントのアドレスがキャッシュ内のいずれかのネットワークと一致する場合、応答はキャッシュから返されます。それ以外の場合は、別のクエリが実行されます。複数の結果が一致する場合は、一般的な最適ネットワーク一致アルゴリズムに従って、SCOPE PREFIX-LENGTHが最も長いものが選択されます。
[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>。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, DOI 10.17487/RFC1700, October 1994, <http://www.rfc-editor.org/info/rfc1700>.
[RFC1700] Reynolds、J。およびJ. Postel、「Assigned Numbers」、RFC 1700、DOI 10.17487 / RFC1700、1994年10月、<http://www.rfc-editor.org/info/rfc1700>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://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, <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>。
[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, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://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, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< http://www.rfc-editor.org/info/rfc4035>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<http://www.rfc-editor.org/info/rfc4193>。
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>.
[RFC6177] Narten、T.、Huston、G。、およびL. Roberts、「エンドサイトへのIPv6アドレスの割り当て」、BCP 157、RFC 6177、DOI 10.17487 / RFC6177、2011年3月、<http：//www.rfc- editor.org/info/rfc6177>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、エド、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、DOI 10.17487 / RFC6890、2013年4月、< http://www.rfc-editor.org/info/rfc6890>。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://www.rfc-editor.org/info/rfc6891>.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<http：// www.rfc-editor.org/info/rfc6891>。
[Address_Family_Numbers] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[Address_Family_Numbers] IANA、「Address Family Numbers」、<http://www.iana.org/assignments/address-family-numbers>。
[DPRIVE_Working_Group] IETF, "PNS PRIVate Exchange (dprive) DPRIVE Working Group", 2015, <https://datatracker.ietf.org/wg/dprive/charter/>.
[DPRIVE_Working_Group] IETF、「PNS PRIVate Exchange（dprive）DPRIVE Working Group」、2015、<https://datatracker.ietf.org/wg/dprive/charter/>。
[METADATA] Hardie, T., Ed., "Design considerations for Metadata Insertion", Work in Progress, draft-hardie-privsec-metadata-insertion-02, March 2016.
[METADATA] Hardie、T。、編、「メタデータ挿入の設計上の考慮事項」、進行中の作業、draft-hardie-privsec-metadata-insertion-02、2016年3月。
[Public_Suffix_List] "Public Suffix List", <https://publicsuffix.org/>.
[Public_Suffix_List]「パブリックサフィックスリスト」、<https://publicsuffix.org/>。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <http://www.rfc-editor.org/info/rfc2308>.
[RFC2308]アンドリュース、M。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、DOI 10.17487 / RFC2308、1998年3月、<http://www.rfc-editor.org/info/rfc2308>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<http://www.rfc-editor.org/info / rfc2663>。
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719] Hoffman、P.、Sullivan、A。、およびK. Fujiwara、「DNS用語」、RFC 7719、DOI 10.17487 / RFC7719、2015年12月、<http://www.rfc-editor.org/info/rfc7719 >。
[VANDERGAAST] Contavalli, C., Gaast, W., Leach, S., and E. Lewis, "Client Subnet in DNS Requests", Work in Progress, draft-vandergaast-edns-client-subnet-02, July 2013.
[VANDERGAAST] Contavalli、C.、Gaast、W.、Leach、S。、およびE. Lewis、「DNSリクエストのクライアントサブネット」、Work in Progress、draft-vandergaast-edns-client-subnet-02、2013年7月。
Acknowledgements
謝辞
The authors wish to thank Darryl Rodden for his work as a co-author,
and the following people for reviewing this document and for
providing useful feedback: Paul S. R. Chisholm, B. Narendran,
Leonidas Kontothanassis, David Presotto, Philip Rowlands, Chris
Morrow, Kara Moscoe, Alex Nizhner, Warren Kumari, and Richard Rabbat
from Google; Terry Farmer, Mark Teodoro, Edward Lewis, and Eric
Burger from Neustar; David Ulevitch and Matthew Dempsky from OpenDNS;
Patrick W. Gilmore and Steve Hill from Akamai; Colm MacCarthaigh and
Richard Sheehan from Amazon; Tatuya Jinmei from Infoblox; Andrew
Sullivan from Dyn; John Dickinson from Sinodun; Mark Delany from
Apple; Yuri Schaeffer from NLnet Labs; Duane Wessels Verisign;
Antonio Querubin; Daniel Kahn Gillmor from the ACLU; Evan Hunt and
Mukund Sivaraman from the Internet Software Consortium; Russ Housley
from Vigilsec; Stephen Farrell from Trinity College Dublin; Alissa
Cooper from Cisco; Suzanne Woolf; and all of the other people that
replied to our emails on various mailing lists.
Contributors
貢献者
The individuals below contributed significantly to this document.
以下の個人は、このドキュメントに大きく貢献しました。
Edward Lewis ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States
Edward Lewis ICANN 12025 Waterfront Drive、Suite 300 Los Angeles、CA 90094-2536 United States
Email: edward.lewis@icann.org
Sean Leach Fastly P.O. Box 78266 San Francisco, CA 94107 United States
Sean Leach Fastly P.O. Box 78266 San Francisco、CA 94107アメリカ合衆国
Jason Moreau Akamai Technologies 150 Broadway Cambridge, MA 02142-1413 United States
Jason Moreau Akamai Technologies 150 Broadway Cambridge、MA 02142-1413 United States
Authors' Addresses
著者のアドレス
Carlo Contavalli Google 1600 Amphitheater Parkway Mountain View, CA 94043 United States
Carlo Contavalli Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: ccontavalli@google.com
Wilmer van der Gaast Google Belgrave House, 76 Buckingham Palace Road London SW1W 9TQ United Kingdom
Wilmer van der Gaast Google Belgrave House、76 Buckingham Palace Road London SW1W 9TQイギリス
Email: wilmer@google.com
David C Lawrence Akamai Technologies 150 Broadway Cambridge, MA 02142-1054 United States
David C Lawrence Akamai Technologies 150 Broadway Cambridge、MA 02142-1054 United States
Email: tale@akamai.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net