上一篇文章《使用公共 DNS 上网的弊端（一）》我讲到当我们使用公共 DNS 上网时可能会因为该 DNS 的出口与本地实际网络所属区域和运营商不一致而导致调度不准，进而影响连接速度可能变慢。这篇文章同时发到了咱们 CloudXNS 的微信公众号上，不少小伙伴与我们产生了互动。
有的小伙伴就问到：“如果是支持 Edns-Client-Subnet 的公共 DNS，还会存在我说的问题吗？”
不得不佩服小伙伴们的学识！（比灰姑娘可厉害多了……
什么是 Edns-Client-Subnet ？
Edns-Client-Subnet，简称 ECS，是由 Google 提交的一份 DNS 扩展协议，主要作用是允许 DNS resolver 传递用户的 IP 地址给权威 DNS 服务器。
关于 ECS 的 RFC 草案提出了很多年，直到 2016 年 5 月才被纳入正式 RFC 7871。
过去我曾在 CloudXNS 官方文章 《【CloudXNS 教您几招】如何让多 ip 域名配置游刃有余？[1]》中侧面提到过关于 ECS 的概念及测试示例，感兴趣的小伙伴可以先去看看。
ECS 支持现状
过去 ECS 一直作为一个 RFC 草案存在，真正成为规范至今也仅仅一年。
如果要让域名的来访用户真正能访问到正确的区域和运营商站点，不仅仅用户使用的本地 DNS 要支持 ECS，同时域名使用的权威 DNS 也要支持。
而事实上，ECS 的普及程度并不高。目前市场上支持 ECS 的权威 DNS 不多，支持 ECS 的递归 DNS 更是少之又少。像在中国，就并没有哪个运营商的本地 DNS 支持。
同时，更多的网站主并不很了解 DNS 相关业务知识。大多数站主随便找个注册商购买了一个域名然后填写几条记录并完事，懂得多点的知道找个智能 DNS 做分区解析。仅此而已。
那么，假设域名使用了支持 ECS 的智能 DNS 和 CDN，访问的用户也使用支持 ECS 的公共 DNS，这中间还会不会有什么问题呢？
ECS 的弊端
访问网站时的解析时间将可能增加
我们知道，DNS 是有逐级缓存的。我们常常访问的网站大多可以直接从本地 DNS 缓存中读取解析结果，只有当我们是整个区域及运营商中访问某个冷门站点的第一个用户，才会最终到权威 DNS 上去查询站点的解析结果。这时候解析时间会远高于访问热门站点。（不懂的话，再去温习一下《转载：从理论到实践，全方位认识DNS（理论篇）》
如果 DNS 查询请求使用包含 ECS 信息（比如 192.168.1.0/24 ），那么 DNS 响应会返回一个 /0，即为每个人缓存。这代表每个子网的缓存结果都是独立的，如果你的子网中过去从未有人使用支持 EDNS 的本地 DNS 访问过某个网站，这意味着你将从头走一遍域名解析。
ECS 可能也并不能解决网络归属问题
在 RFC 7871 中有提到，当增加 ECS 信息后将可能带来生日攻击（章节 11.2）。为了解决这个问题，当响应包中的 ECS 选项不够完整时，则应该被丢弃该 ECS 回复，即使请求中有 ECS 信息。
那么一旦这种例外的情况在用户的一般使用中出现，这个 DNS 便依然解决不了用户网络归属的问题。
结语
事实上，网络延迟和 DNS 解析是网站访问中很重要但可能并不会明显拖慢速度的环节。我们仍可以综合考虑访问速度和安全等多方面来选择使用本地递归 DNS：净网大使选个优质的公共 DNS，懒癌患者就自动获取 DNS，某 DNS 的钟情粉丝就继续抱住你那家那位去吧。
要是你是个仅仅只追求速度的 Windows PC 用户，CloudXNS 提供的“_一键优化 DNS 设置_”（点击下载）工具可以一用。
