站点访问异常的时候，很多人的第一反应是服务器挂了、程序报错了、被攻击了。但有一类问题藏得更靠前：域名解析。它处在用户和服务器之间的第一跳，平时几乎没人想起，一旦出错，表现却五花八门——有的地区能打开、有的打不开，有的设备正常、有的直接报错。排查时容易先怀疑程序，绕一大圈才回到解析上。
哪些现象可能指向解析问题
- 同一时间，不同地区或不同运营商的访问结果不一致。
- 修改解析后，等了很久仍然不生效，或者只有部分网络生效。
- 换了服务器，但仍有用户被解析到旧 IP 上。
- 主域名正常，某个子域名却打不开。
- 接了 CDN 之后，回源异常或证书与解析对不上。
- 邮箱、站点验证、第三方服务的记录突然失效。
这些现象不一定都是解析造成的，但只要出现，就值得把解析记录先过一遍，因为它是最容易查、也最容易被忽略的一层。
解析记录自查清单
记录类型与指向是否正确
A 记录、AAAA 记录、CNAME、MX、TXT、NS 各司其职，先确认有没有重复、冲突或早已过期的记录。重点看指向的 IP 是不是当前正在使用的服务器地址，换机、换服务商之后有没有同步更新。残留的旧记录不一定马上出问题，但在迁移或切换时会突然冒出来。
TTL 是否设置得合理
TTL 太短，解析频繁变更会增加不必要的压力；太长，变更生效慢，出问题时回滚也慢。较稳妥的做法是：计划迁移前提前把 TTL 调小，等切换稳定几天后再调回常规值。如果从没关注过这项，可以先看看当前设置是多少。
子域名与泛解析
- 常用子域名如 www、m、api、static 是否都有正确记录。
- 是否使用了泛解析，以至于测试域名、临时域名也被指向生产环境。
- 历史上开过的子域名是否还能访问，有没有已经不再使用的入口。
CDN 与 CNAME 的对应关系
接入 CDN 后，源站 IP 通常不应直接暴露，解析应指向服务商提供的 CNAME。需要确认 CNAME 是否按服务商要求填写、证书是否覆盖当前域名、回源配置是否与源站实际地址一致。改动其中一环时，最好把另外两环一起看。
解析商与 NS 是否一致
NS 记录决定了域名由哪家解析服务商负责。常见问题是：在 A 平台改了记录，但域名的 NS 还指向 B 平台，等于白改。迁移解析服务商时，这条尤其要先确认。
变更时的操作建议
- 变更前先截图或导出当前解析记录，留一份快照。
- 提前降低 TTL，给后续调整留出空间。
- 分批修改，先动低流量、影响面小的记录。
- 变更后从多个网络环境分别验证解析结果。
- 观察一段时间后再收尾，不要刚改完就下结论。
- 准备好回滚方案，出问题时能快速还原。
日常可以做的小事
- 定期从不同地区节点解析主域名，对比结果是否一致。
- 把域名到期、证书到期、解析服务商账号安全放在同一张日历里。
- 解析服务商账号开启二次验证，避免账号层面的意外变更。
- 把 DNS 自查写进季度运维清单，而不是等故障发生才翻记录。
解析不是设置一次就一劳永逸的事。它和服务器、证书、CDN 一样，需要定期回头看。
DNS 自查并不复杂，成本也不高，但它能把很多模糊的访问故障缩小到明确的范围。真正省时间的，往往不是出了事之后的补救，而是平时就清楚自己的解析结构长什么样。