玩软路由不折腾DNS是没有灵魂的。

———我说的

如果网站使用了CDN，那么全球的CDN节点都可以认为是这个网站的服务器，显然选择一个优化过的 / 距离自己最近的CDN节点很重要，一个使用了CDN的网站大概率它的权威域名服务器同样是这家CDN提供的，自家的权威域名服务器分配自家的CDN服务器还是很合理的。

那权威域名服务器该如何知道客户端的IP呢？

先简化一下上一期的DNS结构图（直接以8.8.8.8作为递归解析服务器）：

flowchart LR
  a("客户端")
  b("`递归解析服务器
  (8.8.8.8)`")
  c("权威域名服务器")
  a --> b
  b --> a
  b --> c
  c --> b

不难看出，实际上域名解析是由 8.8.8.8 替我们完成的，权威域名服务器只知道 8.8.8.8 使用的IP，所以权威域名服务器会按照这个IP去寻找就近的结果，这样就变成了接近 8.8.8.8 的出口IP的结果了。

所以，为了能尽可能的使结果接近客户端的IP，8.8.8.8 会挑选几台离客户端比较近的服务器去完成解析，比如你人在美国，8.8.8.8 就会挑选几台在同在美国的服务器去解析。显然，做一个为全球服务的递归解析没有遍布全球服务器是不行的。

就像上一期提到的根域名服务器一样，8.8.8.8、1.1.1.1、9.9.9.9 等等DNS服务器也使用了任播技术，它们会用一台离你近的服务器接受你的请求，然后将你的请求分配到离你近的几个服务器上，由这几个服务器解析完再将结果原路返回给你。

EDNS 客户端子网(ECS)

上述情况是没有使用ECS的情况，如果使用了ECS，情况就有所不同了。

ECS就是将客户端的IP放在DNS请求中，递归解析服务器收到请求后也会把这个IP交给权威域名服务器，权威域名服务器会按照客户端的IP响应结果。使用了ECS后无论什么位置的服务器都可以获得优化的解析结果，当然这需要客户端、递归解析服务器和权威域名服务器都支持才行。

flowchart LR
  a("客户端")
  b("`递归解析服务器
  (8.8.8.8)`")
  c("权威域名服务器")
  a --客户端的IP--> b
  b --> a
  b --客户端的IP--> c
  c --> b

因为需要将自己的IP填入DNS请求中，所以ECS会有一些隐私问题，Cloudflare的DNS(1.1.1.1)因此不支持ECS功能。
不过没人规定一定要写自己的IP，你可以写一个其他离你比较近的IP，比如运营商DNS的出口IP，做到隐私、速度两手抓。