DNS 解析链路与 TTL 的取舍

改完 DNS 记录要等几分钟到几小时才生效，排查时每个环节看到的还都不一样——因为每一层都在缓存。

一次解析的完整链路

浏览器缓存 → 操作系统缓存（/etc/hosts 与 resolver）
  → 本地递归服务器（运营商或 114/8.8.8.8）
    → 根服务器 → .com TLD → 权威服务器

递归服务器把最终结果缓存 TTL 秒。你改了权威记录，全世界各地的递归缓存里还是旧值，直到各自过期——这就是「生效慢」的全部原因。

TTL 的取舍

TTL 是「允许缓存多久」。它是可靠性与灵活性的交换：

• TTL 长（如 86400）：递归命中率高、解析快、权威服务器压力小，但切换时全网生效慢；
• TTL 短（如 300）：切换灵活，缓存穿透多、解析略慢。

迁移服务器的标准做法：提前 24-48 小时把 TTL 降到 300，迁移完成观察稳定后再升回 3600/86400。

排查工具

dig +trace example.com        # 完整链路，从根开始
dig example.com @8.8.8.8      # 指定递归服务器看缓存
dig example.com @ns1.dns.com  # 直接问权威，看真实记录
nslookup -type=mx example.com

三个结果对比能定位「到底哪里没生效」：权威已更新 + 8.8.8.8 还是旧值 = 递归缓存没过期，等待或换网段验证。

几个实践要点

• CNAME 与 A 记录的选择：接入 CDN/对象存储用 CNAME；裸域（example.com）按 DNS 规范不能与 CNAME 共存（有 ANAME/ALIAS 的服务商除外）；
• MX/SPF/DKIM/DMARC 是邮件可信四件套，改邮件服务时一起核对；
• 解析故障的第一判断依据：dig 直连权威是否正确——正确则是缓存问题，错误则是记录配错；
• 域名解析服务商本身是单点，重要业务考虑双服务商（主从）。

DNS 是互联网里「改了马上生效」错觉最多的地方。把 TTL 的语义讲给业务方听，能省掉大量「为什么用户还看到旧站」的沟通成本。