这是一个创建于 74 天前的主题，其中的信息可能已经有所发展或是发生改变。
| 网站 | 权威服务器 IP | 服务器名字 | 0.0.0.0/0 | 42.247.90.16/32 | 202.106.0.0/32 | 202.106.0.0/16 | 202.0.0.0/8 | 208.175.188.0/32 |
|---|---|---|---|---|---|---|---|---|
| tencent.com | 112.90.13.140 | ns1.qq.com. | 0.0.0.0/0/24 | 42.247.90.16/32/24 | 202.106.0.0/32/24 | 202.106.0.0/16/24 | 202.0.0.0/8/24 | 208.175.188.0/32/24 |
| alibaba.com | 140.205.122.66 | ns1.alibabadns.com. | 0.0.0.0/0/24 | 42.247.90.16/32/24 | 202.106.0.0/32/24 | 202.106.0.0/16/24 | 208.175.188.0/32/24 | 208.175.188.0/32/24 |
| bytedance.com | 47.108.36.164 | vip4.alidns.com. | 0.0.0.0/0/24 | 42.247.90.16/32/24 | 202.106.0.0/32/24 | 202.106.0.0/16/24 | 202.0.0.0/8/24 | 208.175.188.0/32/24 |
| baidu.com | 220.181.33.31 | ns2.baidu.com. | 0.0.0.0/0/0 | 42.247.90.16/32/0 | 202.106.0.0/32/0 | 202.106.0.0/16/0 | 202.0.0.0/8/0 | 208.175.188.0/32/0 |
| huawei.com | 124.71.94.46 | nsall.huawei.com. | 0.0.0.0/0/0 | 42.247.90.16/32/0 | 202.106.0.0/32/0 | 202.106.0.0/16/0 | 202.0.0.0/8/0 | 208.175.188.0/32/0 |
| meituan.com | 1.12.0.17 | ns3.dnsv5.com. | 0.0.0.0/0/17 | 42.247.90.16/32/28 | 202.106.0.0/32/16 | 202.106.0.0/16/16 | 202.0.0.0/8/20 | 208.175.188.0/32/20 |
| pinduoduo.com | 117.135.128.152 | ns4.dnsv5.com. | 0.0.0.0/0/17 | 42.247.90.16/32/28 | 202.106.0.0/32/16 | 202.106.0.0/16/16 | 202.0.0.0/8/20 | 208.175.188.0/32/20 |
| kuaishou.com | 117.135.128.152 | ns4.dnsv5.com. | 0.0.0.0/0/17 | 42.247.90.16/32/28 | 202.106.0.0/32/16 | 202.106.0.0/16/16 | 202.0.0.0/8/20 | 208.175.188.0/32/20 |
| didiglobal.com | 117.51.130.252 | ns4.didiwuxian.com. | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs |
| jd.com | 111.206.226.10 | ns2.jdcache.com. | 0.0.0.0/0/0 | 42.247.90.16/32/0 | 202.106.0.0/32/0 | 202.106.0.0/16/0 | 202.0.0.0/8/0 | 208.175.188.0/32/0 |
| iqiyi.com | 43.225.85.1 | ns2.iqiyi.com. | 0.0.0.0/0/0 | 42.247.90.16/32/24 | 202.106.0.0/32/18 | 202.106.0.0/16/16 | 202.0.0.0/8/8 | 208.175.188.0/32/27 |
| google.com | 216.239.32.10 | ns1.google.com. | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs |
| amazon.com | 156.154.69.10 | ns2.amzndns.net. | 不返回 ecs | 42.247.90.16/32/0 | 202.106.0.0/32/0 | 202.106.0.0/16/0 | 202.0.0.0/8/0 | 208.175.188.0/32/0 |
| youtube.com | 216.239.32.10 | ns1.google.com. | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs | 不返回 ecs |
| cloudflare.com | 162.159.4.8 | ns7.cloudflare.com. | 0.0.0.0/0/24 | 42.247.90.16/32/24 | 202.106.0.0/32/24 | 202.106.0.0/16/24 | 202.0.0.0/8/24 | 208.175.188.0/32/24 |
| netflix.com | 205.251.194.147 | ns-659.awsdns-18.net. | 0.0.0.0/0/0 | 42.247.90.16/32/32 | 202.106.0.0/32/32 | 202.106.0.0/16/16 | 202.0.0.0/8/8 | 208.175.188.0/32/32 |
| microsoft.com | 150.171.10.39 | ns1-39.azure-dns.com. | 0.0.0.0/0/0 | 42.247.90.16/32/0 | 202.106.0.0/32/0 | 202.106.0.0/16/0 | 202.0.0.0/8/0 | 208.175.188.0/32/0 |
我大概统计了当前主流网站他们的权威 DNS 服务器对于 ecs 字段的支持情况，有参考意义的是国内节点的，包括几家主流的互联网公司的门户网站，测试得到结果如下：
固定返回 scope_mask 为 24 的公司：tencent.com 、alibaba.com 、bytedance.com 、cloudflare.com ；（字节托管阿里云）
固定返回 scope_mask 为 0 的公司：baidu.com 、huawei.com 、jd.com 、microsoft.com 、amazon.com ；
返回的 scope_mask 直接复制 source_mask 复制的公司：netflix.com ；
按照匹配到的网段返回的公司：meituan.com 、pinduoduo.com 、kuaishou.com ；（这几家都托管到 DNSPod ）
不返回 ecs 字段：didiglobal.com 、google.com 、youtube.com ；
如果匹配到网段返回网段，没有匹配到的话 scope_mask 直接复制 source_mask：iqiyi.com ；
最近在研究不同网站 DNS 对 ECS 字段的响应策略，发现国内大厂的处理方式差异还挺明显的，比如腾讯、阿里这类会固定返回/24 的 scope_mask ，百度、华为则返回/0 ，还有美团、拼多多这些用 DNSPod 托管的域名，默认匹配不到时会返回/17 。
有点好奇，现在运营商子网划分有时候挺细的，那像腾讯、阿里这种固定/24 的策略，会不会让部分用户拿到不太精准的解析结果？另外 DNSPod 选/17 作为兜底粒度，在缓存效率和解析精准度之间，这种平衡方式会不会存在什么潜在问题？大家对这些不同策略的有什么看法6 条回复 2025-09-18 17:52:21 +08:00
 | 1 ranaanna 73 天前 "那像腾讯、阿里这种固定/24 的策略，会不会让部分用户拿到不太精准的解析结果？" ----不懂但个人理解似乎是反过来的？/24 表示高度个性化，缓存碎片化命中率低，解析慢，客户 ip 精准到/24 因此有泄漏位置和隐私之嫌，但客户会拿到“精准的解析结果”。难道 OP 认为应该要/32 才“精准”？ 另外/0 似乎是域名没有部署 ecs ？当然如果是用有很多 PoP 的公共 dns ，内容提供商也有很多 PoP ，缓存足够本地化和匹配，不用 ecs 反而速度和隐私可以得兼 |
 | 2 mengyx 73 天前 "像腾讯、阿里这种固定/24 的策略，会不会让部分用户拿到不太精准的解析结果？" -- 不会；在公网上，IPv4 路由表的最长前缀就是 /24 ，几乎没有 AS 会接受更明细的路由 |
 | 4 flyingcmz OP @ranaanna /24 的 ECS 粒度在国内场景下有时候是不够用的核心问题是国内运营商存在 IP 段跨地域分配的情况：一个完整的 C 段可能被拆分给不同省份的用户（比如 112.174.xxx.0/24 ，可能同时覆盖江苏和安徽的移动用户）。这种情况下，DNS 服务器仅靠/24 子网判断位置，就不够了； /0 这里考虑的话，猜测是没有部署 ecs 、或者单纯用任播这些； PoP 的话，只有运营商覆盖密度足够高，其他公有云厂商阿里云在文档也说了他们也足够多，但是 DNSPod 的话他们节点不够多，所以需要 ECS 字段才能获取定制的应答，所以如果使用了 public dns 作为递归的话，不用 ecs 还是会有很多问题。 |
 | 5 johnjiang85 72 天前 一般认为/24 已经比较精准了，当然如果支持/25-/32 或/57-/128 会更精准，但是实际上绝大部分公共 dns 只支持/24 和/56 的精度，支持更高的的精度会造成缓存的进一步大范围增长，一般是一种折衷考虑。 另一个原因是现网 isp 绝大部分是/24 的精度分配和使用，/25-/32 的精度在现网的使用大部分是用在骨干网上，不会作为终端用户来使用，也不应该直接用这些 IP 来请求，但是如果公共 dns 支持到/25-/32 精度的话，则会提高受攻击的风险，比如某些人就是用高精度的 IP 段作为 ecs 去请求，从而极大的增加了递归 DNS 的网段缓存压力。 当然/25 等更高精度的网段确实也有不同地区终端用户在使用的案例，但毕竟是极少数极少数（如 39.97.22.0/25 和 39.97.22.128/25 ），各种原因综合考量，公共 DNS 绝大部分不会进行支持，更好的方式还是 isp 应该尽量规避这种高于/24 精度的 IP 直接分配给终端用户使用。 |
| 6 flyingcmz OP @johnjiang85 好的大佬，懂您的意思了 |
Select Language