cdn加速与dns的关系：解析顺序、缓存生效与常见配置误区

很多人把 cdn加速与dns的关系 理解成「上了 CDN 就不用管解析」，结果上线后一部分用户拿到旧 IP，另一部分直接打不开。这篇从一次真实的递归查询走一遍，把解析顺序、CNAME 链路、TTL 生效窗口和几个高频配置误区拆开讲，命令都可以直接复制运行，不需要额外环境，照着敲一遍就能对上自己的域名。

一次请求到底先问谁

用户在地址栏敲下域名，浏览器先查自己的 DNS 缓存，再交给操作系统的 stub resolver，接着读 hosts 文件。这三步都没命中，查询才会发给本地递归解析器，由它去问根、问顶级域、问权威服务器。cdn加速与dns的关系 就藏在这一跳里：权威服务器返回的往往不是 A 记录，而是一条 CNAME。

递归解析器看到 CNAME 必须继续追，直到拿到最终的 A 或 AAAA。被追到的那台权威服务器由 CDN 厂商托管，它根据递归解析器的出口 IP 判断运营商和地理位置，返回一个相对较近的边缘节点地址。所以 cdn加速与dns的关系 的前半段，确认的是「去哪个机房」，后半段才决定「怎么把内容送回来」。

机房出口那台权威服务器通常只占几个 U，上游接路由器，中间串交换机和配线架。真正麻烦的不是链路，是每一层都可能留下缓存。

这也解释了一个常见现象：你在本机改了解析，同事那边还是旧地址。他的递归解析器缓存了上一次的答案，和你的 CDN 配置没有关系。

CNAME 接入与解析顺序

接入 CDN 最常见的方式，是把业务域名 CNAME 到厂商给的加速域名上。这条记录本身很短，却把解析责任转交了出去：递归解析器看到 CNAME 会重新发起一次针对加速域名的查询，由厂商的调度系统给出边缘节点 IP。整条链路多了一跳，也多了一次被缓存的机会。

dig +trace www.example.com A
dig www.example.com CNAME +short
dig @8.8.8.8 www.example.com A +noall +answer

+trace 从根开始逐级打印，能看清 CNAME 在哪一步返回、又被谁继续追下去。第二条只看 CNAME 目标，用来确认接入是否生效。第三条指定公共解析器，对比不同递归出口拿到结果的差异。想弄明白 cdn加速与dns的关系，把这三条输出摆在一起看就够了。

根域名（apex，例如 example.com）不能直接挂 CNAME，这是协议层面的限制：apex 必须保留 SOA 和 NS。部分厂商提供 ALIAS 或 ANAME 这类伪记录，在权威侧展开成 A 记录返回，效果接近 CNAME，兼容性取决于你的 DNS 服务商，以官方文档为准。

链越长，单次查询的往返次数越多，首次解析的耗时越明显。厂商一般建议控制在一到两跳，超过三跳就该回头看是不是套了两层 CDN，或者旧记录没清干净。

TTL 与缓存生效时间

链路定完之后，剩下的变量是每一跳能缓存多久，也就是 TTL，单位秒。它不是一个「到点全网刷新」的开关，而是每个递归解析器各自倒计时。真实生效时间取决于链路上所有 TTL 的最小值，还要叠加解析器自己的取整策略，有的解析器会把过小的 TTL 抬到一个下限。

把 TTL 从 3600 改成 60，并不会让已经缓存了 3600 秒的那批解析器立刻更新。稳妥的顺序是迁移前提前一个旧 TTL 周期把 TTL 降下来，等缓存自然过期，再切 IP，观察一段时间之后把 TTL 调回去。cdn加速与dns的关系 在这一步最清楚：DNS 的 TTL 管「去哪台机器」，CDN 的缓存头管「这台机器上的文件新不新」，两者不能互相替代。

还有一种负面缓存容易被忽略。查询一个不存在的子域时，权威服务器在 SOA 里给出的 negative TTL 会让解析器把「不存在」这个结论也记住。刚配好记录却解析不到，常常是上一次失败还没过期。

常见配置误区

把 CDN 的缓存时间和 DNS 的 TTL 混为一谈，是最普遍的一个。改了源站文件、刷新了 CDN 缓存，用户看到的还是旧内容，于是转头去动 DNS。两层缓存的失效机制完全不同，动错地方只会让问题更难定位。

另一个误区是认为 TTL 越小越好。TTL 压到几十秒，解析器几乎每次都要回源查询，权威服务器的 QPS 明显上升，解析延迟也更不稳定。稳定期用较长的 TTL，只在变更窗口前降低，是更省心的节奏。这类改动对 cdn加速与dns的关系 的影响常被低估。

还有人把泛解析 CNAME 和邮件记录挂在同一个名字下。CNAME 会独占该名字，同名的 MX 记录在严格实现里会被忽略，等发现收不到邮件再回头查 DNS，代价很高。这也说明 cdn加速与dns的关系 不止影响网页，凡是依赖这个域名的服务都会被牵连。

上线前怎么自查

改完解析别急着刷新浏览器。先用 dig 指定不同的公共解析器，对比返回的 A 记录和剩余 TTL；再用 curl 看响应头里的缓存状态。两条命令组合起来，能区分是 DNS 没生效，还是边缘节点上还挂着旧对象。

dig @223.5.5.5 www.example.com A +noall +answer
curl -sI https://www.example.com/ | grep -iE 'cache-control|age|x-cache'

第一条输出最后一个数字是剩余 TTL，数值越大说明这台解析器缓存得越新。第二条里 Age 是对象在边缘节点上已存在的时长，计龄依据是 Cache-Control 的 s-maxage，没有这个字段才退回 max-age；拿浏览器侧的 max-age 去比 Age，结论正好相反。各家头字段不完全一样，以官方文档为准。把 cdn加速与dns的关系 记成「先查指向、再查对象」，读这两行输出就不会乱。

如果两个解析器返回的 IP 分属不同厂商的网段，说明 CNAME 还没有完全收敛，或者旧记录在某处仍然生效。这时候去查权威区的记录列表，比反复清本地缓存有用得多。

把 cdn加速与dns的关系 拆成「解析」和「分发」两段来看，自查就有顺序可循：先确认域名指到哪个机房，再确认那台机器上的对象是不是新的。顺序对了，大多数「改了没生效」的问题都能在十分钟内定位。

排查完记得把临时的短 TTL 改回去。留着一个几十秒的 TTL 在线上跑，平时看不出差别，流量高峰时权威 DNS 会先扛不住。