如何在注册商变更后监控 DNS 传播
DNS 迁移在纸面上看起来很简单，但在实践中却会引发真实的事故。在注册商处更新记录，TTL 过期，全世界刷新 DNS 缓存，一切正常运行。故事通常是这样讲的。但实际上，部分传播会经常发生：一些解析器提供新记录，一些提供旧记录，最终用户的行为会沿着区域或 ISP 的边界出现分化。本指南介绍如何监控 DNS 迁移、需要检查什么，以及如何捕捉那些无声 DNS 不会暴露的故障。
DNS 传播的实际工作原理
当您在注册商处更改 DNS 记录时，旧记录会一直留在全球各地的解析器缓存中，直到其 TTL 过期。不同的解析器在不同的时间刷新；一些严格遵守 TTL，一些会向上取整。结果是会有一个时间窗口（通常是一个 TTL 加上几分钟，但有时长达数小时），在此期间不同用户会看到不同的记录。
您自己的解析器可能是最后一个更新的，因为操作系统和应用程序会在 OS 层级解析器之上激进地缓存 DNS。经典的错误是从自己的笔记本电脑 ping 新的端点，看到它能工作，宣布传播完成，然后在第二天早上发现欧盟客户仍在访问旧的 IP。
迁移期间应监控的内容
四种 DNS 记录类型覆盖了常见的迁移情况。在变更期间，每一种都需要有自己的监控。
- A 和 AAAA 记录：针对您正在迁移的主机名。首要检查项：是否提供了新的 IP？
- CNAME 记录：针对任何使用 CNAME 的子域。如果其中一个链接指向不存在的主机，CNAME 链可能会无声地中断。
- MX 记录：如果涉及电子邮件。错误的 MX 迁移会导致电子邮件被无声拒绝，且没有明显的面向客户的症状。
- NS 记录：如果您正在更换 DNS 提供商。NS 记录是基础；如果它错了，其他一切都无关紧要。
多区域检查
在单个区域的单个解析器上运行的 DNS 监控器完全失去了意义。真正有意思的问题是新记录是否已传播到所有地方，而不是您监控器的本地解析器是否已刷新。
像 dnschecker.org 这样的工具允许您以交互方式跨多个区域抽查传播情况。对于自动化监控，您需要一个能检查多个解析器并在出现分歧时告警的工具。如果您的监控工具只从一个位置进行检查，请在宣布迁移完成之前从其他区域运行额外的手动检查（通常使用蜂窝数据网络的手机就足够了）。
在迁移前降低 TTL
最有用的准备工作是在变更前 24 至 48 小时降低受影响记录的 TTL。新的 TTL 必须先传播，这就是为什么需要提前期。
- 迁移前：将 TTL 从默认的 3600（1 小时）降低到 60（1 分钟）。等待 TTL 下降的传播，这需要一个旧 TTL 周期加上一个缓冲时间。
- 迁移期间：更新记录。解析器在 60 秒内刷新。
- 迁移后：监控 24 小时以捕捉任何卡住的缓存。在确信传播完成后，将 TTL 恢复到 3600。
捕捉无声的部分传播故障
部分传播是真正会带来痛苦的故障模式。一半的客户看到新端点，一半看到旧端点，如果您自己的监控只在一个地方进行检查，这种半坏状态对它来说是不可见的。
有三种信号可以捕捉到它。提及旧行为或旧主机名的支持工单激增。区域间用户指标出现分化（美国转化率下降而欧盟保持平稳）。一个明确分别检查每个区域解析器的监控，并在出现分歧时告警。在迁移后至少运行这三种信号 24 小时。
迁移前检查清单
迁移前两天，将所有受影响记录的 TTL 降低到 60 秒。前一天，为新的记录值添加 DNS 监控器，由于记录尚未更改，预期它们会触发告警。在迁移日，更新记录。监控器变为绿色。观察 24 小时，关注多区域分歧和支持工单量。一旦两者都干净持续 24 小时，恢复 TTL 并移除临时监控器。当指标干净时，迁移才算完成，而不是在记录更新时。
