省级DNS地址别照抄：验证运营商递归解析与CDN调度

上周有人在群里甩了张截图标题写着某运营商32个省的DNS地址大全区底下跟着一长串以 202.96 开头的服务器IP说照着填完家里宽带打开网页要转三圈才出来。这种事我见过太多次了问题多半不在地址本身而在于这个地址和你当前的接入位置、线路类型、拨号方式三者压根不匹配。DNS地址和所谓最快的服务器IP这两件事被太多帖子混在一起讲抄的人也就跟着一起糊涂。这篇东西想解决的就是这个糊涂账一份省级DNS列表从哪来才可信、怎么确认它现在还有没有用、所谓4G最快服务器IP在技术上到底指什么、以及怎么用几条命令自己测出结论而不是照抄别人。适合手上有一堆抄来的地址不知道填哪个的人也适合想搞清楚运营商递归解析和CDN调度关系的人。基础的部分我会讲得慢一点涉及命令和脚本的地方会给出可复现的写法你照着跑一遍基本就有感觉了。1. 那张流传很广的省级DNS对照表抄完为什么反而更慢1.1 省级分配这件事和行政区划不是一回事很多人默认一个省一个DNS所以看到32个省列了32组地址觉得很合理。实际网络里的组织方式要粗粝得多。运营商的递归解析服务器通常按大区或者按城域网来部署一个省里往往同时存在多组、甚至十几组合格的递归地址分布在不同的机房通过路由策略把用户导向最近的那一组。你在省内A市拨号拿到的地址和在B市拨号拿到的地址很可能根本不是一个段。这就解释了一个现象网上流传的某省DNS通常只是某个时间点、某个城市、某条特定线路上下发到的一对主备地址被截图保存下来然后被反复转载。它在采集的那一刻是对的,但你所在的城域网如果不往那个机房走填进去之后每次查询都要多绕一跳甚至跨城解析时延自然就上去了。所以那张表的问题不在于假而在于窄——它只代表一个点却被当成一个面来用。还有一个更隐蔽的点递归服务器地址是有生命周期的。地址池调整、机房搬迁、集群扩容都会导致某些老地址降级成低优先级甚至直接下线。你在帖子里看到的地址可能确实还在响应但它响应得慢因为背后那台机器已经不再是主力了。1.2 三类最常见的失效场景实际排查下来抄来的地址不好用基本落在下面这三种情况里。失效类型表面现象实际原因地址回收或重新规划解析超时、间歇性无响应老递归集群下线地址池被重新分配调度权重变更能解析但很慢网页首屏卡地址仍有效但已降为备份节点双栈配置错配部分站点打不开部分正常终端优先走IPv6却填了纯IPv4的解析器第三种最容易被忽略。现在的系统大多是IPv6优先如果你手动把DNS改成一个只监听IPv4的地址解析请求走v4出去但访问目标站点时又走v6回来中间多了一次协议栈切换和可能的路径重选。表现出来就是有的站秒开有的站一直转圈你换浏览器、清缓存都治不好。1.3 判断一个地址现在还值不值得用两个动作就够不用一上来就大动干戈。先做最朴素的两件事看它回答得快不快看它答得准不准。第一件事直接问它。把下面这条命令里的地址换成你要验证的那个# Linux / macOS连续问 10 次看平均耗时和是否有超时 for i in $(seq 1 10); do dig short time2 tries1 www.example.com 202.96.xx.xx | head -1 done如果十次里有两三次直接超时这个地址基本可以放弃了不用再纠结。如果都能答但耗时忽高忽低比如在 8ms 和 120ms 之间反复横跳说明它虽然活着但路由不稳定同样不建议长期用。第二件事看它返回的IP是不是就近的。这一步是区分好坏的关键同一个域名用运营商本地递归去问和用一个异地递归去问返回的CDN边缘节点IP往往不一样。你把两个结果分别 ping 一下延迟差距一目了然。# 分别用两个不同的解析器查同一个域名 dig short cdn.example.com 202.96.xx.xx # 候选地址A dig short cdn.example.com 202.96.yy.yy # 候选地址B把这两条命令返回的IP各 ping 二十次取平均。如果A返回的节点比B近了三四十毫秒那基本不用犹豫选A。这个判断方法比看任何大全都直接因为它测的是端到端的真实路径而不是纸面上的地址归属。2. 拿到本省真实DNS的四个入口比网上抄靠谱得多2.1 拨号状态里就写着只是没人去看最靠谱的来源永远是你自己这条线路当下被下发了什么。PPPoE拨号成功后BRAS会把主备两个递归地址推给客户端Windows上一条命令就能看到ipconfig /all输出里找DNS 服务器那几行通常会有两个地址第一个是主用第二个是备用。这两个地址是运营商针对你这个接入点动态分配的比你从任何帖子里抄的都准。如果是路由器拨号、终端接在路由器后面那就登录路由器后台找WAN口状态或者外网设置页面里面一般会显示获得的DNS服务器。这里有个细节值得注意很多家用路由器默认开启了自己的DNS转发dnsmasq终端上ipconfig /all看到的其实是路由器的内网地址比如 192.168.1.1而不是运营商下发的真实地址。想看真实值必须进路由器后台。2.2 移动网络下的获取方式要绕一下手机在Wi-Fi下看DNS很简单进Wi-Fi详情就能看到。但在蜂窝数据下系统一般不会把运营商下发的解析器地址暴露给用户界面。安卓部分机型还能通过调试桥读到adb shell getprop | grep -i net.dns新一些的系统版本可能读不到返回空或者只有net.dns1一个值这属于正常现象不用怀疑手机坏了。iOS 就更封闭界面上完全看不到。这种情况下我的建议是别折腾直接用系统默认——移动网络下的解析器是跟着基站和核心网走的你手动指定的那个地址大概率还不如系统自动选的近。2.3 命令行反查当前真正生效的解析器终端上配置了哪些和实际在用哪个经常是两回事。Linux 和 macOS 上最直接# macOS scutil --dns | grep nameserver | head -5 # Linuxsystemd-resolved 环境 resolvectl status | grep -A2 DNS Servers # 通用 cat /etc/resolv.conf/etc/resolv.conf在有些发行版上只是个软链接或者被其他服务托管改了不一定生效这一点踩过坑的人应该都有印象。所以优先看resolvectl或者scutil的输出那才是解析栈真正在用的配置。2.4 为什么运营商下发通常优于手动填写这里要把原理说透不然容易被公共DNS更快的说法带偏。运营商递归解析器在物理位置上离你近这只是一半原因。更关键的是源IP归属。当你用运营商本地递归去查一个接了CDN的域名时递归服务器把你的查询转发给CDN的全局负载均衡系统GSLB 看到的源IP是这台递归服务器的地址它能判断出这个查询来自某省某运营商的网内于是返回同网、同省、甚至同城的边缘节点。换成第三方公共解析器就不一样了。那台服务器可能在别的省份甚至别的运营商网内GSLB 看到的是一个异地源IP它只能按那个位置返回节点。结果就是你的请求被调度到一个物理上更远的边缘节点解析这一步看着挺快公共DNS的响应时间确实漂亮但真正下载资源的时候跨了网、跨了省,整体体验反而更差。这就是典型的解析快、访问慢很多人只测了解析那一步就下结论正好掉进这个坑里。3. 4G最快服务器IP这个说法混淆了两个完全不同的东西3.1 测速节点IP和DNS解析IP不是一回事搜索词里经常把这两件事捆在一起实际上它们服务于完全不同的目的。DNS服务器IP的作用是把域名翻译成IP它本身不传输你的业务流量除非你用了加密DNS那是另一回事。而所谓最快的服务器IP在绝大多数语境下指的是测速时用来打流量的那个目标节点或者游戏、下载场景下的接入节点。你 ping 它得到的是这条路径的往返时延和丢包情况跟域名解析没有直接关系。把这两者混为一谈最典型的后果就是有人找了一堆最快IP填进DNS设置里然后发现上不了网。因为那些地址根本不监听53端口压根不是解析服务器。3.2 移动网络下的就近是怎么发生的4G/5G 场景下哪个服务器IP快这个问题比固网更动态。原因在于移动网络的接入点是跟着你走的你在城东连的基站和城西连的不是同一个背后走的核心网网关也可能不同。同一个IP早上在公司测出来 15ms晚上回家测出来 60ms这不是IP变了是路径变了。所以移动网络下追求一个固定最快IP意义有限。真正有用的做法是维护一个候选池让工具在每次连接时自己挑。候选池里放什么放你常用业务的实际接入地址——比如你常用的测速站点、常用服务的接入域名解析出来的IP而不是网上抄来的一串陌生地址。3.3 用延迟加丢包两个维度筛别只看延迟只测延迟容易被误导。有些节点延迟很低但丢包严重实际吞吐惨不忍睹。我一般的筛法是两个指标一起看# 连续 50 次看平均延迟、最大延迟、丢包率 ping -c 50 候选IP判读的时候有个经验值可以参考平均延迟低于 30ms、最大延迟不超过平均值的 3 倍、丢包为 0这三条同时满足才算稳。如果平均延迟 20ms 但最大延迟飙到 300ms说明路径上有拥塞或者队列抖动这种节点在打游戏或者视频会议时体验会很差哪怕它平均看起来很美。想要看得更细用 mtr 沿着路径逐跳看mtr -r -c 50 候选IP输出里如果某一跳开始丢包且后面每一跳都继承了这个丢包率说明问题出在那一跳如果只有中间某一跳丢包而最后一跳不丢那通常是那台路由器对 ICMP 做了限速不代表链路真有问题。这个区别很关键不少人看到中间跳红了一片就以为线路坏了其实业务流量根本没受影响。4. DNS解析质量怎么测三个指标缺一个都会误判4.1 解析时延只是入场券很多人测DNS就测一个查一个域名要多久这个指标有用但非常片面。它只反映第一次查询缓存未命中的开销而且受测试域名影响极大。你拿一个本地根本没有缓存的冷门域名去测和拿一个热门域名去测结果能差十倍。真正有参考价值的做法是准备一组域名覆盖不同类型一个热门站点、一个冷门站点、一个走CDN的静态资源域名然后对每个候选DNS分别跑一轮记录每一次的耗时看的是分布而不是单次值。#!/usr/bin/env bash # 对多个候选 DNS 逐域名测解析耗时 DOMAINS(www.example.com static.example.com api.example.com) DNS_LIST(202.96.xx.xx 202.96.yy.yy 202.96.zz.zz) for d in ${DNS_LIST[]}; do echo $d for dom in ${DOMAINS[]}; do total0 for i in $(seq 1 5); do t$(dig short time3 tries1 $dom $d /dev/null 21; echo $?) # 用 query time 更准从 dig 的统计行里取 qt$(dig $dom $d 2/dev/null | grep -o Query time: [0-9]* | grep -o [0-9]*) total$((total ${qt:-3000})) done echo $dom 平均 ${((total/5))} ms done done注意脚本里tries1这个参数不设的话 dig 默认会重试超时也会被掩盖成慢而不是失败测出来的数就没意义了。4.2 命中率与TTL的关系决定了你日常的体感解析时延影响的是第一次命中率影响的才是每一天。递归服务器对常见域名是有缓存的缓存有效期由域名自身的 TTL 决定。TTL 长的域名你第二次、第三次查询基本都是缓存直接返回几毫秒就完事TTL 短的域名缓存频繁失效每次都要回源时延就上去了。这解释了一个常见困惑为什么有人测 DNS 觉得都差不多快实际用起来却感觉某个明显更顺。差别往往不在单次查询而在于这个递归服务器对常用域名的缓存覆盖率高不高。大运营商的主力递归节点服务用户多、缓存热,命中率天然占优一些小节点或者新上线的地址缓存是冷的什么都要回源问一遍。判断方法也很土把同一个域名连续查十次看后九次的时间是不是稳定在个位数毫秒。如果十次都差不多说明它压根没缓存或者每次都给你返回不同结果这种地址拿来日常用意义不大。4.3 CDN调度准确性最容易踩的假快陷阱前面提过一次这里展开说因为这是整个话题里最容易误判的地方。假设你测出某个公共 DNS 的解析时延只有 3ms本地运营商递归是 8ms。数字上看公共 DNS 赢了你换了。结果换完之后发现视频加载变慢、软件下载速度掉了一半。原因在于那 3ms 只代表它回答你快不代表它给你的答案对。验证方法很直接用两个解析器查同一个 CDN 域名把各自返回的IP拿出来分别 ping。# 拿到两边的解析结果 A$(dig short cdn.example.com 202.96.xx.xx | head -1) B$(dig short cdn.example.com 公共DNS地址 | head -1) # 分别测往返时延 ping -c 20 $A ping -c 20 $B如果 A 的延迟明显低于 B说明本地递归给出的节点更近那 3ms 的解析优势完全不值一提。解析省下的 5ms抵不过传输多绕的 30ms。这个账很多人算不过来是因为只盯着解析工具上那个数字看。4.4 一套可以照着跑的对比流程把上面这些串起来我日常用的验证流程大概是这个顺序大概十分钟能跑完一轮从路由器 WAN 口读出当前下发的两个地址记为基准组。从网上找来的列表里挑两三个同省地址记为对照组。用 4.1 的脚本对两组分别测解析耗时各跑五轮。用 4.3 的方法对同一个 CDN 域名比对返回IP的实际延迟。用 4.2 的方法看重复查询是否有缓存命中。三项综合只要对照组没有在任何一项上明显胜出就别换。这个流程跑下来你会发现绝大多数情况下基准组运营商下发的那两个综合表现最好。这不是巧合是设计使然。5. 想自己维护一份省级对照表该怎么做5.1 表结构这么设计后面才不用返工如果你确实有跨省的需求比如做多地部署测试、给不同地区的同事做支持与其收藏别人的表不如自己建一张。字段不用多但这几个必须有字段说明省份/城市精确到地市比只到省有用得多运营商线路同省不同线路走的机房可能不同主用地址拨号实际下发值不要手填备用地址同上采集时间精确到日超过三个月的要复核采集方式拨号下发 / 后台读取 / 他人提供验证状态已验证 / 待验证 / 已失效采集方式这一列看着多余实际上最有用。凡是标着他人提供的用之前一律按待验证处理标着拨号下发的可信度最高。有了这一列你半年后回头看这张表才知道哪些数据能直接用。5.2 批量验证的写法地址多了以后手工一个个 ping 不现实写个小循环批量跑#!/usr/bin/env bash # 批量检查 DNS 地址可用性输出格式便于粘贴回表格 while IFS, read -r province ip; do [ -z $ip ] continue result$(dig short time2 tries1 www.example.com $ip 2/dev/null | head -1) if [ -n $result ]; then qt$(dig www.example.com $ip 2/dev/null | grep -o Query time: [0-9]* | grep -o [0-9]*) echo $province,$ip,OK,${qt}ms else echo $province,$ip,FAIL,- fi done dns_list.csvdns_list.csv里每行一个省份,地址跑完直接出结果。这个脚本没什么技巧但比手工靠谱得多尤其是地址数量上了二三十个之后。5.3 复核节奏别等出问题才想起来我的习惯是每季度过一遍。触发复核的信号有三个任何一个出现就手动跑一次换了宽带套餐或者换了光猫、所在小区做了线路改造、常用站点开始出现莫名卡顿。前两个是外部变化第三个是结果反馈。复核不用全量跑先跑你常用的那几个省其他的标个待复核放着。真到用的时候再验证比维护一张永远最新的表现实得多——那张表根本不存在谁声称有都是在卖快照。6. 折腾这些年几条反直觉的结论6.1 全局替换DNS绝大多数时候是负收益我早期也干过这事看到一个新地址就想全局换上觉得优化了。后来发现大部分所谓优化都是自嗨。原因前面说过手动填的地址丢失了源IP归属信息CDN调度会偏。除非你能确认新地址在你这条线路上、在解析时延、缓存命中、调度准确性三项上都不输否则别动。真要改我的做法是只改特定设备的特定场景。比如某台常做下载的机器手动指定一个缓存命中率高的地址其他设备一律保持自动。这样即使改错了影响面也可控。6.2 移动网络下手动指定 DNS 的意义比固网小得多固网拨号下发的地址相对稳定你能测出一个固定结论。移动网络不是这样你的接入网关跟着位置变测试结果的时效性很短。今天测出来 A 比 B 快 10ms明天换个地方可能就是反过来的。所以在手机上手填 DNS我一般只在两种情况下做一是明确知道当前网络环境有解析异常比如某些域名解析不出来而其他网络正常二是需要临时绕过某个有问题的解析结果。日常使用就让系统自动选省心且不容易出错。6.3 什么时候手动指定反而是对的也不是完全没用。有两种场景手动指定确实有优势。第一种是设备本身不支持自动获取比如某些老旧的嵌入式设备、部分网络摄像头、打印机它们的网络配置界面只能填静态地址那就只能手填这时候用拨号下发的那两个值最稳。第二种是需要固定解析行为的调试场景。比如你在排查为什么这台机器访问某个服务总是走到错误的节点这时候把 DNS 固定住排除解析层面的变量才能定位到真正的问题。这种用法是为了控制变量不是为了提速目的完全不同。最后分享一个我自己一直在用的小习惯每次换网络环境换城市、换宽带、换手机卡之后花两分钟跑一遍ipconfig /all或者resolvectl status把当下下发的地址记到表里顺手 ping 一下看延迟。时间长了你会发现这张自己攒出来的表比任何一份网上流传的大全都好用因为每一条后面都有你自己的验证记录而不是一串来路不明的数字。