站点出问题时，多数人的排查顺序是程序、服务器、CDN，最后才想到 DNS。但解析恰恰是访问链路上最靠前的一环，它一旦不对，后端做得再顺也送不到访客和蜘蛛面前。更麻烦的是，DNS 故障的表现往往很像别的问题：有时是打不开，有时是时好时坏，有时只有某个地区的用户受影响。这篇整理一套可以定期执行的解析自查思路。
先把手上的解析记录理清楚
不少团队对自家域名的解析记录其实只有模糊印象，等到要迁移或加服务时才临时翻后台。建议至少每季度导出一次解析记录，逐条确认用途和负责人。常见的记录类型大致有这几类：
- A / AAAA 记录：指向服务器 IP，通常是主站和子站的入口，改动影响最大。
- CNAME 记录：多用于接入 CDN、对象存储或第三方服务，改的是别名而非 IP。
- MX 记录：决定企业邮箱收信走向，误删会导致邮件静默丢失。
- TXT 记录：承载 SPF、DKIM、域名验证等信息，常被当成“看不懂的遗留项”删掉。
- NS 记录：声明权威服务器，一般不动，但迁移 DNS 服务商时是关键。
梳理时要特别留意那些“看起来没人用”的子域名。它们可能早在几年前的活动中配置过，指向的服务器早已下线，成为解析层面的死链。蜘蛛如果频繁请求这类地址并拿到解析失败，对整站的抓取体验没有好处。
TTL 设多少合适
TTL 决定解析结果被各级缓存保留多久，是一个典型的“平时无所谓、迁移时要命”的参数。
稳定期可以长一些
如果服务器和接入方式长期不变，TTL 设在几小时到一天之间比较常见，能减少解析请求压力，也能让访客的解析结果更稳定。
迁移前必须提前调短
如果计划在某个时间点切换 IP 或更换服务商，至少提前一到两个 TTL 周期把 TTL 调到几分钟级别。否则旧记录会在各地缓存里继续生效，出现同一时间有人访问新站、有人访问旧站的情况。切换完成并观察稳定后，再把 TTL 调回正常值。
迁移当天才去改 TTL 是常见误区。缓存不会因为你着急就立刻过期，提前准备比临时加急有效得多。
多线路解析与故障转移
如果使用了多线路解析或带健康检查的解析服务，需要确认几件事：健康检查的探测地址是否仍然有效、探测频率是否合理、切换后的备用节点是否真的能承接流量。有些配置看起来是双活，实际备用节点早已停止维护，切换过去反而更慢。建议在不影响线上的前提下，定期做一次手动切换演练，确认备用路径可用。
更换服务器时的建议顺序
- 新环境部署完成，用 hosts 绑定或测试域名先验证功能和证书。
- 把 TTL 调短，等待旧缓存自然过期。
- 正式修改解析记录，指向新 IP 或新别名。
- 观察多地解析结果，确认大部分节点已更新。
- 确认稳定运行后，再关停旧服务器，别急着立刻释放。
- 把 TTL 调回常规值，并记录本次变更的时间和原因。
别忽略邮件和验证类记录
主站能打开，不代表邮件记录没问题。如果迁移时误删了 MX 或 SPF，对外发信可能被判为可疑，通知邮件进垃圾箱，注册验证码收不到。这类问题通常要等用户反馈才被发现，排查成本比事前检查高得多。迁移前把邮件相关记录单独截图存档，是一个成本很低的习惯。
把解析纳入日常监控
解析状态适合用轻量方式定期抽查，而不是等出事再查。可以从多地节点定时查询主域和关键子域的解析结果，比较返回的 IP 是否在预期范围内；同时监控权威服务器是否可达。一旦发现解析结果异常或延迟明显升高，能比用户投诉更早收到信号。对于依赖蜘蛛抓取的站点，解析层的不稳定同样会影响抓取节奏，稳定的解析是后续所有优化的前提。
一份可执行的检查清单
- 解析记录清单是否完整，每条是否有人负责。
- 是否存在指向已下线服务器的闲置子域名。
- TTL 是否与近期的迁移计划匹配。
- 邮件与域名验证类记录是否完好。
- 多线路或故障转移配置是否做过实际演练。
- 解析状态是否纳入监控并有告警通道。
DNS 的问题往往不是天天出现，但一旦出现就是全站级别。把它列入常规巡检，比事后从零排查要省力得多。