EDNS 客户端子网 (ECS) 指南

简介

RFC 7871 - DNS 查询中的客户端子网 - 定义一种机制，用于 Google 公共 DNS 等递归解析器将部分客户端 IP 地址信息发送到权威 DNS 域名服务器。在响应来自公共 DNS 解析器的名称查询时，内容分发网络 (CDN) 和对延迟敏感的服务会使用此属性来提供准确的地理位置响应。

RFC 描述了权威域名服务器必须实现的 ECS 功能；但实现者并不总是遵循这些要求。此外，RFC 并未解决的 ECS 操作和部署问题可能会导致解析器（例如 Google 公共 DNS）在权威域名服务器中自动检测 ECS 支持，以及需要 ECS 白名单的解析器（例如 OpenDNS）。

这些准则旨在帮助权威 DNS 实现者和运维人员避免可能导致 ECS 出现问题的许多常见错误。

术语定义

我们使用以下术语来描述 ECS 操作：

  • 如果域名服务器使用 ECS 响应来回复具有匹配 ECS 选项的 ECS 响应，则 ECS 也会实现（或支持）该 ECS（即使 ECS 选项的全局前缀长度始终为 /0 时也是如此）。

  • 如果使用非零源前缀发送的 ECS 查询收到 ECS 响应（非零范围），则已启用 ECS。

权威域名服务器准则

  1. 为启用 ECS 的地区所有权威域名服务器都必须为该地区启用 ECS。

    • 即使只有一个域名服务器未实施 ECS 或为区域启用 ECS，它也会快速成为大多数缓存数据的来源。由于其响应具有全局范围，因此会在 TTL 到期之前将其响应所有同名查询（无论客户端子网为何）。来自实现 ECS 的服务器的响应只能用于特定范围内的客户端查询，因此与全局范围响应相比，使用它们的可能性要低得多。

  2. 实现 ECS 的权威域名服务器必须2 针对从 IP 地址或 NS 主机名传送的 ECS 查询发送 ECS 响应，即便这些区域并未启用 ECS。

    • Google 公共 DNS 按 IP 地址（而不是域名服务器主机名或 DNS 区域）自动检测 ECS 支持，因为地址数量小于域名服务器主机名的数量，并且远远少于 DNS 区域的数量。如果权威域名服务器未始终向 ECS 查询发送 ECS 响应（即使在未启用 ECS 的可用区），Google Public DNS 可能会停止向其发送 ECS 查询。

  3. 实现 ECS 的权威域名服务器必须使用 ECS 响应来响应所有 ECS 查询，包括否定和引荐响应。

    • 对 ECS 支持的自动检测同样如此。

    • 否定响应（NXDOMAIN 和 NODATA）应3使用全局 /0 范围，以获得更好的缓存以及与 RFC 7871 的兼容性。

    • 除了 NXDOMAIN 和 NODATA（答案部分为空）之外，对 ECS 查询的其他错误响应（尤其是 SERVFAIL 和 REFUSED）还应包含具有全局 /0 范围的匹配 ECS 选项。

      • 如果权威域名服务器正尝试从 DoS 攻击中减轻负载，服务器可能会在没有 ECS 数据的情况下返回 SERVFAIL；这样做会导致 Google 公共 DNS 停止向 ECS 发送查询（这可能会减少他们发送的合法查询的数量，但不会影响随机子网域攻击查询）。减少 DoS 攻击期间的合法查询负载不一定会提高合法查询的成功率（但可以通过缓存为所有客户端提供响应）。

        更有效的负载均衡方法是发送具有全局 /0 范围的所有响应，以便 Google 公共 DNS 继续发送 ECS 查询。这样一来，Google 公共 DNS 可以在攻击停止后更快地返回地理位置定位响应，因为 Google 无需重新检测 ECS 支持，只需在全局范围响应 TTL 到期后重新查询即可。

    • 引荐（委托）响应还必须具有匹配的 ECS 数据，并且应4 使用全局 /0 范围。请注意，委托响应永远不会转发到地址出现在 ECS 数据中的客户端，因此所有位于地理位置的 NS、A 或 AAAA 记录都应由解析器的客户端 IP 地址而不是 ECS 数据来选择。

  4. 实现 ECS 的权威域名服务器必须在对使用 ECS 选项接收的所有查询类型的响应中包括匹配的 ECS 选项。使用 ECS 数据响应 IPv4 地址 (A) 查询还不够好；对 A、AAAA、PTR、MX 或任何其他查询类型的响应必须具有匹配的 ECS 数据，或者解析器可能会将响应作为伪造响应而丢弃，Google 公共 DNS 可能会停止发送包含 ECS 数据的查询。

    具体而言，针对 SOA、NS 和 DS 查询的 ECS 响应应始终使用全局 /0 范围，以便获得更好的缓存效果以及对委托的一致视图（可以通过地理位置定位对域名服务器主机名的 A/AAAA 查询作出响应）。对任何不会根据 ECS 数据发生变化的查询类型（例如 TXT、PTR 等）的响应不应使用与源前缀长度相等的范围，而应使用全局 /0 范围以获得更好的缓存并减少查询负载。

  5. 返回已启用 ECS 的 CNAME 响应的权威域名服务器应5 仅包含链中的第一个 CNAME，并且 CNAME 链的最终目标应启用相同范围的前缀长度相同的 ECS。由于 ECS 规范的歧义，某些递归解析器（特别是未绑定的6）可能会返回最终非 CNAME 网域的响应（如果未启用 ECS，则为 /0）。

  6. 即使是只使用 IPv4 的域名服务器，ECS 数据也可能包含 IPv6 地址（反之亦然，但 IPv6 专用域名服务器很少见）。

    • 域名服务器需要返回有效的 ECS 选项数据（/0 范围可以，但来源地址和前缀长度必须匹配）。

    • 您可以为 IPv4 和 IPv6 地址分别启用地区的 ECS。

  7. 返回启用 ECS 的响应的权威域名服务器不得7 在其回答中重叠范围前缀。以下是范围重叠的前缀示例：

    • 来源前缀为 198.18.0.0/15 的查询：范围 A 为 198.0.0.0/8 的响应 A

    • 来源前缀为 198.51.100/24 的查询：范围 前缀为 198.51.0.0/16 的响应 B

    如果客户端按上述顺序查询启用了 ECS 的递归解析器，两个查询都可能会收到响应 A，因为缓存响应 A 的范围包含第二个查询的前缀范围。即使客户端查询以相反的顺序执行，并且两个查询都转发到权威域名服务器，缓存的响应可能会以不同的时间过期；对重叠前缀 198.51.100/24 中的递归解析器的后续查询可能会获得响应 A 或 B。

  8. 首次在域名服务器上实现 ECS 支持时，请为域名服务器启用新 IP 地址，以为这些 ECS 启用的区域提供服务。

    • 如果实现 ECS 但返回全局范围结果的权威域名服务器开始返回某个区域的 ECS 响应，Google 公共 DNS 会在以前的全局范围响应的 TTL 到期后，开始返回查询的地理位置响应。

    • ECS 支持的 Google 公共 DNS 自动检测功能在极少数情况下会自动检测 IP 地址（或域名服务器主机名）是否缺少 ECS 支持（超时、返回 FORMERR、BADVERS 或发送非 ECS 响应）。系统会自动检测对这些 IP 地址（或 NS 主机名）的新 ECS 实现，或者完全不自动检测。

  9. 请确保网络连接可靠，并将任何响应速率限制设置得足够高，以便域名服务器不会丢弃查询（更糟糕的是，在响应时会包含缺少匹配的 ECS 选项的错误）。

    • 对于在 ECS 查询上实现响应速率限制的域名服务器，最好的响应是设置了截断 (TC) 标志的 NODATA，其中包含匹配的问题部分和匹配的 ECS 选项。

  10. 及时响应所有查询（最好在 1 秒内）。

    • 对 ECS 查询使用在线 Geo-IP 查找服务将无法可靠地运行，因为 DNS 查询和在线 Geo-IP 服务的累计延迟时间不太可能在 1 秒内。ECS 支持的 Google 公共 DNS 自动检测功能认为延迟响应表明 ECS 支持不佳或不完整，并降低了未来通过 ECS 发送查询的可能性。如果足够多的响应延迟，它会停止发送 ECS 查询。

RFC 7871 参考文档和其他脚注

1 https://tools.ietf.org/html/rfc7871#page-12

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.

2 https://tools.ietf.org/html/rfc7871#section-7.2.1

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.

3 https://tools.ietf.org/html/rfc7871#section-7.4

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.

4 https://tools.ietf.org/html/rfc7871#section-7.4

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.

5 https://tools.ietf.org/html/rfc7871#page-12

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.

6 https://unbound.net/pipermail/unbound-users/2015-May/003875.html

在 CNAME 链中使用最终网域的范围在 Unbound 中不会造成损害，因为它通常部署为本地桩或转发解析器，其中所有客户端都位于同一子网中，并且获得相同的响应。

7 https://tools.ietf.org/html/rfc7871#page-13

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.

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

  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.

……

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.