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
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扩展机制（EDNS0）选项，该选项用于承载有关发起DNS查询的网络以及可缓存后续响应的网络的信息。由于它存在一些已知的操作和隐私缺陷，因此将通过IETF进行修订以进行改进。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
本文档定义了一个EDNS0[RFC6891]选项，用于传输与DNS消息相关的网络信息。它将携带足够的关于发起人的网络信息，以便权威名称服务器定制响应。它还将为权威名称服务器提供指示定制答案所针对的网络地址范围的功能。此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.
实现是互操作的，在边缘情况下存在不同的行为，这些情况没有得到很好的指定。本文档描述了已知的不兼容性，作者认为最好描述系统目前的工作状态，即使不是所有人都同意原始规范（[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.
我们建议默认情况下在所有nameserver软件中关闭该功能，并且操作员仅在为其客户端提供明显好处的情况下显式启用该功能。我们还鼓励采取措施，让用户利用提供的选择退出。最后，我们建议其他人避免使用可能在未来工作中引入额外元数据的技术，因为这可能会损害用户信任。
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.
遗憾的是，目前对本规范中选择退出条款的支持有限。已知只有一个存根解析程序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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
ECS: EDNS Client Subnet.
ECS:EDNS客户端子网。
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.
服务器：转发解析程序、递归解析程序或权威名称服务器。
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.
存根解析器：客户端上的简单DNS协议实现，如[RFC1034]第5.3.1节所述。客户端到递归解析器或转发解析器。
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.
权威名称服务器：对一个或多个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.
转发解析程序：名称服务器本身不进行迭代解析，而是将该职责传递给另一个递归解析程序，在[RFC2308]第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.
从拓扑角度看，地理位置相近的主机可能仍然非常遥远，而两个地理位置较远的主机在网络上可能非常接近。
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.
第6节介绍了edns客户端子网（ECS）EDNS0选项的格式，该选项旨在以对存根解析程序和最终用户透明的方式添加到中间名称服务器发送的查询中，如第7.1节所述。ECS仅为Internet（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... /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+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的选项代码，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]中定义）OPTION-LENGTH，2个八位字节，包含有效负载的长度（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 族，2个八位字节，表示选项中包含的地址族，使用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:
地址部分的格式取决于族的值。本文档仅定义了系列1（IPv4）和系列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，一个无符号八位字节，表示用于查找的地址的最左侧有效位数。在响应中，它镜像与查询中相同的值。
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，一个无符号八位组，表示响应覆盖的地址的最左边有效位数。在查询中，它必须设置为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 地址（可变八位字节数）包含IPv4或IPv6地址，具体取决于系列，必须将其截断为源前缀长度字段指示的位数，并用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 如果服务器接收的ECS选项使用的地址八位字节太少或太多，或者设置的非零地址位超出了源前缀长度，则服务器应返回FORMERR以拒绝该数据包，作为向软件开发人员发出修复其实现请求的信号。
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选项时，递归解析器通过设置客户端地址族来初始化该选项。然后，它使用其最大可缓存前缀长度的值来设置源前缀长度。出于隐私原因，并且由于很少需要整个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选项，则必须检查其源前缀长度。然后，递归解析器的传出查询必须将源前缀长度设置为传入查询的源前缀长度或服务器的最大可缓存前缀长度中的较短者。
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.
最后，在这两种情况下，作用域前缀长度都设置为0，然后将地址添加到源前缀长度的位数，如果需要，添加尾随的0位以填充最后的八位字节。使用的八位字节总数必须仅足以覆盖源前缀长度的位，而不是通常由系列中的地址使用的全宽度。
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.
家庭和地址信息可以通过ECS选项在传入查询中使用。传递现有地址数据支持将递归解析程序用作转发解析程序的目标，但可能会遇到与递归解析程序和权威名称服务器之间的使用协议有关的策略问题。有关这一点的更多讨论，请参见第12.2节。如果递归解析器不会转发来自传入ECS选项的族和地址数据，则应返回拒绝响应。
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.
如果不受传入源前缀长度的限制，则刷新数据的后续查询必须指定递归解析器愿意缓存的最长源前缀长度，即使之前的响应表明较短的前缀长度就足够了。
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.
存根解析器可以使用ECS选项生成DNS查询，该选项设置源前缀长度以限制网络信息的显示方式。接收此类查询的中间名称服务器不得进行包含比原始查询中更多的客户端地址位的查询。
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.
源前缀长度值为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
存根解析器必须将作用域前缀长度设置为0。它可能包括族和地址数据，但如果它查询的中间名称服务器具有拒绝转发地址的策略，则应该准备好处理拒绝的响应。如果没有地址集，即源前缀长度设置为0，则应将族设置为发送查询的传输。这是给你的
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.
互操作性；如果FAMILY不是1或2，则至少有一个主要权威服务器将忽略该选项，即使如果没有地址位，该选项也不相关。
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节“递归解析器”中的说明进行准备。特别是，实现此协议的转发解析器必须遵守来自其客户端的传入查询中指示的源前缀长度限制。另见第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.
由于它所联系的递归解析器将转发解析器视为存根解析器，因此递归解析器关于传入地址信息的策略将以相同的方式应用。如果转发解析程序在发送包含非零地址的查询时收到拒绝响应，则必须在没有地址的情况下重试。
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的权威名称服务器可以使用选项中指定的地址信息生成定制响应。
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.
根据[RFC6891]第6.1.2节，尚未实现或启用ECS选项支持的权威名称服务器应在传入查询中安全地忽略它。此类服务器不得在回复中包含ECS选项，以表示不支持ECS。但是，中间名称服务器的实现者应该知道，某些名称服务器错误地回显未知的EDNS0选项。在这个协议中，这应该是无害的，因为作用域前缀长度应该返回为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]“传输注意事项”中所述，必须拒绝带有错误格式选项（例如，未知系列）的查询，并且必须将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
实现此协议并接收ECS选项的权威名称服务器必须在其响应中包含ECS选项，以指示应该相应地缓存它，而不管是否需要客户端信息来制定答案。（注意
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.
[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.
响应中的族、源前缀长度和地址必须与查询中的匹配。回传这些值有助于缓解某些攻击向量，如第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.
范围前缀长度值大于源前缀长度表示提供的前缀长度不够具体，无法选择最合适的定制响应。将来在指定网络中查询名称时应使用较长的作用域前缀长度。影响递归解析器是否使用较长长度的因素包括操作员希望为其用户提供的隐私屏蔽量，以及缓存的额外资源影响。
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.
相反，较短的作用域前缀长度表示提供了比所需更多的位，并且答案适用于更广泛的地址范围。这可能短至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.
由于与定制响应相关的网络的任何部分的逻辑拓扑可能不同，权威名称服务器可能会为不同的网络返回不同的范围前缀长度值。
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
由于某些查询可能会导致将多个RRset添加到响应中，因此，对于范围前缀长度如何应用于每个单独的RRset，原始规范中存在着令人遗憾的模糊性。例如，响应任意元查询的多个类型都可能具有不同的适用范围前缀长度值，但该协议仅能够发出一个信号。因此，响应应该包括答案中任何RRset的最长相关前缀长度，这可能会产生一个不幸的副作用，即冗余缓存一些可以更广泛缓存的数据。对于规范名称（CNAME）链的特定情况，权威名称服务器应仅将初始CNAME记录放在应答部分，以便将其明确且适当地缓存。大多数现代递归解析器使用CNAME重新启动查询，因此链的其余部分通常被忽略
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为中心的解析器，这将意味着以链中任何RRset的最长前缀长度缓存整个CNAME链。
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.
权威名称服务器用于选择定制响应的特定逻辑不在本文档的范围内。然而，实施者被鼓励仔细考虑他们在选择最佳剪裁响应的情况下对响应的范围预置长度的选择，以及对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.
权威名称服务器可能存在这样的情况：一个定制的响应适用于相对较宽的地址范围，例如IPv4/20，但某些例外情况除外，例如该/20中的几个/24范围。因为不能保证所有较长前缀长度的查询都会在较短前缀长度的查询之前到达，所以权威名称服务器不能重叠前缀。
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.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
中间名称服务器使用ECS时，是否在自己的响应中将ECS选项传递给客户端取决于客户端最初是否包含该选项。由于未使用ECS选项的客户端可能无法理解该选项，因此服务器必须
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.
在答复中没有提供一个。如果客户机查询确实包含该选项，则服务器必须在其响应中包含一个选项，特别是当它可能正在与转发解析程序进行通信时，转发解析程序需要该信息来进行自己的缓存。
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.
如果中间名称服务器收到的响应的作用域前缀长度大于其查询中提供的源前缀长度，则即使客户端位于不同的地址范围内，它仍应提供结果作为触发客户端请求的答案。中间名称服务器可以选择使用更长的源前缀长度重试，以便在响应其客户端之前获得更好的答复，只要它不超过触发解析的查询中指定的源前缀长度，但这显然会影响整个查找的延迟。
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位的响应时，它应基于选项中的数据缓存结果。如果设置了TC位，则中间解析器应通过TCP重试查询，以获取用于缓存的完整答案部分。
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.
如果响应中地址的FAMILY、SOURCE PREFIX-LENGTH和SOURCE PREFIX-LENGTH位与相应查询中的非零字段不匹配，则必须删除完整响应，如第11节所述。在对仅为隐私屏蔽指定源前缀长度的查询的响应中，族和地址字段必须包含权威名称服务器用于生成答案的适当非零信息，以便可以相应地对其进行缓存。
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，这是适用于所有客户端地址的答案。请参阅第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
如果从权威名称服务器接收到拒绝的响应，ECS感知解析程序必须在没有ECS的情况下重试查询，以将响应与权威名称服务器不负责名称的响应区分开来，这是拒绝状态的常见约定。类似地，递归解析器的客户端应该
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.
收到拒绝的响应后重试，因为不清楚拒绝的响应是由于ECS选项还是其他原因。
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.
在缓存中，应答部分中的所有资源记录必须绑定到响应中指定的网络。适当的前缀长度取决于源前缀长度、作用域前缀长度和为缓存配置的最大可缓存前缀长度之间的关系。
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.
如果作用域前缀长度不大于源前缀长度，请存储地址的作用域前缀长度位，然后将响应标记为对该范围内的所有地址有效。
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.
类似地，如果源前缀长度是为缓存配置的最大值，则存储地址的源前缀长度位，然后将响应标记为对该范围内的所有地址有效。
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.
如果源前缀长度小于配置的最大值且作用域前缀长度大于源前缀长度，请存储地址的源前缀长度位，然后将响应标记为仅对在其自己的ECS选项中指定完全相同的源前缀长度的客户端查询有效。
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.
由于查询的源前缀长度为0而缓存为/0的记录必须与由于响应的作用域前缀长度为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.
对于DNS查询，缓存查找通常首先使用<name，type，class>的查询元组进行。然后，必须根据最长前缀匹配选择适当的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 如果ECS选项指定了源前缀长度和覆盖客户端地址的地址，则会使用客户端地址，但最初会忽略源前缀长度。如果未找到覆盖项，并且源前缀长度小于缓存允许的配置最大长度，请对与源前缀长度完全匹配的项重复缓存查找。这些特殊条目不包括更长的前缀长度，如前一节所述。
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 如果有带有地址的ECS选项，则在本地策略允许的情况下，可以使用该选项中的地址。根据中间名称服务器的操作员与权威名称服务器操作员之间的协议，策略可能会有所不同；见第12.2节。如果策略不允许，则应发送拒绝响应。详见第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数据与管理局和其他章节的记录捆绑在一起，在原始规范中留下了令人遗憾的模糊性，主要是关于否定答案。最初作者的期望是，ECS实际上只用于地址请求和响应的应答部分的积极结果，这是驱动协议定义的用例。
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.
对于否定答案，解析程序和授权机构的一些独立实现并不认为部分限制必然意味着给定的名称和类型只能有肯定答案或否定答案。它们支持告诉网络的一部分数据不存在，同时告诉网络的另一部分数据存在。
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；因此，它们应该相应地设置作用域前缀长度。
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数据，并且权威名称服务器应在委托上返回零范围前缀长度。递归解析器应该将委托中的非零范围前缀长度视为零。
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消息中，即一个跃点。但是，在某些配置中，例如多层名称服务器设置，可能需要在中间名称服务器上实现传递行为。
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选项。此信息可能与传入查询的源IP地址匹配，并且可能比名称服务器通常包含在本地起源的ECS选项中的地址位更多或更少。如果中间名称服务器接收到源前缀长度设置为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选项中的信息（地址信息太少、未授权使用服务器的范围内的网络地址、专用/不可扩展的地址空间等），则应放弃查询并返回拒绝的响应。再次注意，不能仅仅因为查询提供了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).
请注意，至少有一个主要的现有实现不会返回拒绝，而是只处理查询，就好像问题信息不存在一样。这可能会导致异常情况，例如，来自中间名称服务器的响应表明它是为一个网络定制的（原始查询中传递的，因为地址必须匹配），而实际上它是为另一个网络定制的（包含中间名称服务器视为进行查询的地址的网络）。
IANA has assigned option code 8 in the "DNS EDNS0 Option Codes (OPT)" registry to edns-client-subnet.
IANA已将“DNS EDNS0选项代码（OPT）”注册表中的选项代码8分配给edns客户端子网。
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.
如[RFC4033]、[RFC4034]和[RFC4035]中所述，DNS查询中是否存在包含ECS选项的EDNS0 OPT资源记录（[RFC6891]）不会改变用于向DNS提供数据源身份验证和数据完整性的资源记录和机制的使用。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的另一个障碍。
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 RRs的处理；因此，预计在处理过程中会出现操作上的不一致。
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.
除RRSIG记录外，大多数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.
这里的另一个含义是，尽管在第7.4节中讨论了否定答案，但根据上一段，将NextSECure（NSEC）或NSEC3记录的范围限定为/0必然意味着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进行特殊感知；查询可以按原样传递。不应添加客户端的网络地址，现有ECS选项（如果存在）不应被NAT设备修改。
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
在NAT设备后面的大规模全局网络中（但是，例如，使用集中式解析器基础设施），内部中间名称服务器可能具有详细的网络布局信息，并且可能
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.
了解每个内部网络用于出口流量的外部子网。在这种情况下，中间名称服务器可以在发起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选项，而是依赖下游中间名称服务器来发起ECS选项。然而，它可以选择将该选项与它们的内部地址一起包含，以表示它自己对源前缀长度的限制。
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.
特殊网络地址的完整处理超出了本文件的范围；根据每个服务提供商的运营环境，处理这些问题可能会有所不同。作为一般准则，如果公共路由Internet上的权威名称服务器接收到在[RFC1918]或[RFC4193]专用地址空间中指定地址的查询，则应忽略地址，并根据递归解析程序的地址查找其答案。在响应中，它应该将作用域前缀长度设置为覆盖所有相关的私有空间。例如，查询源前缀长度为24的地址10.1.2.0时，返回的作用域前缀长度为8。中间名称服务器可以选择将答案缓存在一个专用地址项下[RFC6890]；见本文件第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应该对自己的网络有更详细的了解。也就是说，他们可能知道a/20中的所有24位前缀都在同一个区域。在这些情况下，为了优化缓存利用率和改善隐私，ISP的递归解析器应该将此/20中的IP地址截断为仅20位，而不是上述建议的24位。
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选项（即源前缀长度为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的递归解析程序中转发，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元组）添加信息。这使得攻击者可以通过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.
在对同一名称进行多个查询的情况下，攻击者更有可能成功发送范围前缀长度设置为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选项必须包含来自相应查询的完整系列、地址和源前缀长度字段。处理响应的中间名称服务器必须验证这些匹配，如果不匹配，则应放弃整个响应。
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节中的指示相反，该节规定，缺少ECS选项的响应应被视为具有范围前缀长度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响应敏感，即使它之前已经给出了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 用很少（如果有的话）使用的结果填充中间解析器的缓存，从而污染缓存。
o reverse-engineer the algorithms (or data) used by the Authoritative Nameserver to calculate Tailored Responses.
o 对权威名称服务器用于计算定制响应的算法（或数据）进行反向工程。
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带来的高缓存压力，在所有默认配置中都应该禁用该功能。
o Recursive Resolvers SHOULD limit the number of networks and answers they keep in the cache for any given query.
o 递归解析器应该限制它们在缓存中为任何给定查询保留的网络和答案的数量。
o Recursive Resolvers SHOULD limit the total number of different networks that they keep in cache.
o 递归解析程序应该限制它们保存在缓存中的不同网络的总数。
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 递归解析程序不得发送源前缀长度为的ECS选项，该选项在地址中提供的比特数不得超过其愿意缓存响应的比特数。
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]中定义的某些地址块）视为与递归解析器自身的标识等效。他们应该忽略并且从不转发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选项。在这个阶段，还不清楚哪种策略是最好的。
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”[public_suffix_List]）域服务器时从不发送选项。这些域以委托为中心，不太可能根据客户端的地址生成不同的响应。
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 RRs（带或不带选项）丢弃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.
如果实施了探测，则必须定期重复，例如每天重复。如果权威名称服务器指示ECS支持一个区域，则可以预期该名称服务器支持其所有区域的ECS。同样，为其一个区域使用ECS信息的权威名称服务器必须在其对ECS查询的所有响应中表明对该选项的支持。如果该选项受支持但未实际用于生成响应，则其作用域前缀长度必须设置为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，并且通常只有在为用户提供明显好处时才会启用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.
为了避免实现探测和检测机制的复杂性（以及随之而来的可能的查询丢失/延迟），实现可以使用权威名称服务器的白名单将选项发送到，可能由其域名指定。实现还允许基于其他条件（如区域或查询类型）对此进行额外配置。在撰写本文时，至少有一个实现使用了白名单。
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。特别是，RNS配置为在与顶级域或根名称服务器对话时不包括ECS选项，如第7.1节所述。因此，不添加ECS选项，并且像往常一样执行解析。
4. RNS now knows the next server to query: the Authoritative Nameserver, ANS, responsible for example.com.
4. RNS现在知道下一个要查询的服务器：权威名称服务器ANS，负责example.com。
5. RNS prepares a new query for www.example.com, including an ECS option with:
5. RNS为www.example.com准备了一个新的查询，包括一个ECS选项，其中包括：
* OPTION-CODE set to 8.
* 选项代码设置为8。
* OPTION-LENGTH set to 0x00 0x0b for the following fixed 4 octets plus the 7 octets that will be used for ADDRESS.
* 选项长度设置为0x00 0x0b，用于以下固定的4个八位字节加上将用作地址的7个八位字节。
* FAMILY set to 0x00 0x02, as IP is an IPv6 address.
* 族设置为0x00 0x02，因为IP是IPv6地址。
* SOURCE PREFIX-LENGTH set to 0x38, as RNS is configured to conceal the last 72 bits of every IPv6 address.
* 源前缀长度设置为0x38，因为RNS配置为隐藏每个IPv6地址的最后72位。
* SCOPE PREFIX-LENGTH set to 0x00, as specified by this document for all queries.
* 范围前缀长度设置为0x00，由本文档为所有查询指定。
* ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, providing only the first 56 bits of the IPv6 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选项，并生成定制响应。
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.
* 选项代码设置为8。
* OPTION-LENGTH set to 0x00 0x07.
* 选项长度设置为0x00 0x07。
* FAMILY set to 0x00 0x02.
* 族设置为0x00 0x02。
* SOURCE PREFIX-LENGTH set to 0x38, copied from the query.
* 源前缀长度设置为0x38，从查询中复制。
* SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.
* 作用域前缀长度设置为0x30，表示a/48网络。
* ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, copied from the query.
* 地址设置为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选项的响应。它验证族、源前缀长度和地址是否与查询匹配。否则，将丢弃该消息。
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选项，因此响应中的地址、作用域前缀长度和族用于缓存条目。
11. RNS sends a response to Stub Resolver, SR, without including an ECS option.
11. RNS向存根解析器SR发送响应，但不包括ECS选项。
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。这一次，将缓存响应。然而，响应与特定网络有关。如果客户端地址与缓存中的任何网络匹配，则从缓存返回响应。否则，将执行另一个查询。如果多个结果匹配，则根据常见的最佳网络匹配算法，选择范围前缀长度最长的结果。
[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，“分配的数字”，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安全扩展的资源记录”，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，“唯一本地IPv6单播地址”，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]Cotton，M.，Vegoda，L.，Bonica，R.，Ed.，和B.Haberman，“特殊用途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/RFC68911913年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_工作组]IETF，“PNS私人交换（DPRIVE）DPRIVE工作组”，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.
[元数据]Hardie，T.，Ed.，“元数据插入的设计考虑”，正在进行的工作，草稿-Hardie-privsec-METADATA-Insertion-022016年3月。
[Public_Suffix_List] "Public Suffix List", <https://publicsuffix.org/>.
[公共后缀列表]“公共后缀列表”<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]Andrews，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/RFC77192015年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]Contavali，C.，Gaast，W.，Leach，S.，和E.Lewis，“DNS请求中的客户端子网”，正在进行的工作，草稿-VANDERGAAST-edns-Client-Subnet-022013年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.
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号300室90094-2536
Email: edward.lewis@icann.org
Email: edward.lewis@icann.org
Sean Leach Fastly P.O. Box 78266 San Francisco, CA 94107 United States
Sean Leach勇敢的邮政信箱78266旧金山，CA 94107美国
Jason Moreau Akamai Technologies 150 Broadway Cambridge, MA 02142-1413 United States
Jason Moreau Akamai Technologies美国马萨诸塞州剑桥百老汇150号02142-1413
Authors' Addresses
作者地址
Carlo Contavalli Google 1600 Amphitheater Parkway Mountain View, CA 94043 United States
卡洛·康塔瓦利谷歌1600竞技场公园道山景，美国加利福尼亚州94043
Email: ccontavalli@google.com
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号，英国西南9TQ
Email: wilmer@google.com
Email: wilmer@google.com
David C Lawrence Akamai Technologies 150 Broadway Cambridge, MA 02142-1054 United States
David C Lawrence Akamai Technologies美国马萨诸塞州剑桥百老汇150号02142-1054
Email: tale@akamai.com
Email: tale@akamai.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
沃伦·库马里谷歌1600圆形剧场公园道山景，加利福尼亚州94043
Email: warren@kumari.net
Email: warren@kumari.net