站点出問题时，多數人的排查顺序是程序、服務器、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 的問题往往不是天天出現，但一旦出現就是全站級別。把它列入常規巡检，比事後從零排查要省力得多。