DNS 迁移到 Cloudflare 素以琐碎而著称：导入区域、指向名称服务器、等待其传播。停电三个小时的队伍正是按照这个剧本进行的。问题在于，“琐碎”描述的是完美的案例，而制作却很少是完美的。
自动导入不能为您做什么
当您将域添加到 Cloudflare 时，平台会查询当前提供商的权威服务器并尝试导入区域中的所有记录。结果是一个看起来完整的记录列表——而且几乎总是如此。 “几乎”就是风险所在。
用于 DANE（[DNS 命名实体身份验证4）的 TLSA 类型记录通常不会导入。对于某些具有非标准配置的 SRV 记录、具有多个标志或异常值的 CAA 记录以及先前提供程序通过非标准响应提供的任何记录，也会发生同样的情况。 Cloudflare 导入只是一个起点，而不是忠诚度的保证。
正确的协议是：导入后，以BIND格式导出当前提供者区域（大多数提供者都提供这种）并手动比较两组记录。诸如 0 之类的工具针对导出的区域文件揭示了导入遗漏的内容。此步骤需要 20 分钟，并且避免在名称服务器移交后发现电子邮件证书已停止验证，因为 TLSA 记录丢失。
Cloudflare 代理和非 HTTP 服务
Cloudflare 对于每个 A 或 AAAA 记录以两种模式运行：代理（流量通过 Cloudflare 网络，隐藏真实 IP）和仅 DNS（纯解析，无中介）。默认情况下，导入的 MX 记录仅限 DNS，这是正确的，因为 SMTP 不通过 Cloudflare 代理。
指向电子邮件服务器或除 HTTP/HTTPS 之外的任何服务的 A 记录会出现此问题。指向 SMTP 服务器的名为 1 的 A 记录可能会在配置过程中意外被代理，特别是当有人查看记录并启用批量代理时。结果是，电子邮件服务器现在公开 Cloudflare IP，而不是真实 IP，并且外部 SMTP 连接到达的代理不知道如何处理它们。该错误不是立即发生的 - 某些电子邮件客户端会再次尝试，超时需要几分钟，并且问题在变得一致之前会出现间歇性。
通过 DNS 公开的数据库也会发生同样的情况。解析到代理后面的 MySQL 或 PostgreSQL 服务器的 A 记录会返回 Cloudflare IP。应用程序尝试连接到端口 3306 或 5432，代理拒绝（默认情况下不支持这些端口），并且连接因超时而失败。该服务似乎已关闭，但 DNS 正在“工作”——它只是指向了错误的位置。
在翻转名称服务器之前，请检查每条 A 和 AAAA 记录并确认正确的模式。规则很简单：如果该地址处的服务不专门在端口 80 和 443 上以 HTTP/HTTPS 方式响应，则该模式必须是仅 DNS。
TTL 和传播窗口
名称服务器传播不是瞬时的，当前提供者中记录的 TTL 决定了世界各地的解析器丢弃旧缓存所需的时间。如果您的记录的 TTL 为 86400 秒（24 小时）（许多提供商的标准），并且您现在打开名称服务器，则某些解析器将继续为旧记录提供长达 24 小时的服务，无论 Cloudflare 已经说了些什么。
正确的策略在迁移前两天开始。将当前提供程序上所有关键记录的 TTL 降低至 300 秒（五分钟）。等待相当于原TTL的时间：如果记录为3600秒，则等待一小时；如果是 86400，请等待 24 小时。然后才打开名称服务器。因此，当发生更改时，世界各地的缓存最多会在五分钟内过期，并且迁移过程中出现的任何问题都会很快得到解决 - 您不必在事件发生时等待 24 小时缓存过期。
这一步最常被忽视，因为它需要提前规划。那些在迁移前一天到达并注意到 TTL 为 86400 的人有两种选择：降低 TTL 并等待 24 小时后再继续，或者接受较长传播窗口的风险。第二种选择是导致停电持续时间超过应有时间的最常见途径。
DNSSEC：将传播转变为验证失败的细节
如果域在当前提供商处启用了 DNSSEC，则在不处理注册商处的 DS 记录的情况下迁移名称服务器会导致所有检查 DNSSEC 的解析器验证失败。解析器收到域使用 DNSSEC 的通知（通过注册商处的 DS 记录），查询 Cloudflare，接收使用 Cloudflare 密钥签名的签名，并拒绝响应，因为密钥与仍指向先前提供商的 DS 不匹配。
正确的顺序有四个步骤，中间有等待窗口。首先，从注册商处删除 DS 记录（不是在 DNS 提供商处，而是在注册域名的注册商处）。其次，等待 DS 记录的 TTL 过期 — 通常在一到四个小时之间，具体取决于记录器。第三，将名称服务器转移到 Cloudflare。第四，在 Cloudflare 仪表板中启用 DNSSEC 并添加平台向注册商提供的新 DS 记录。跳过第一步和第三步之间的等待期是迁移中发生 DNSSEC 事件的最常见原因。
如何构建迁移，以免在压力下临时凑合
三十分钟内结束的迁移和变成三小时事件的迁移之间的区别几乎总是在组织方面。执行良好的团队会在宣布迁移完成之前提前定义谁验证每个步骤、配置回滚的内容以及成功标准是什么。
有效的操作顺序从比较当前提供商和 Cloudflare 之间的区域开始，在任何枢转之前完成。具有 SPF、DKIM 和 DMARC 的域需要特别注意：TXT 记录可能包含自动导入重新格式化的引号或串联，即使内容看起来正确，也会破坏验证。 SIP、XMPP 或 Minecraft 等服务的 SRV 记录需要手动优先级和权重字段检查。
名称服务器移交后，验证协议具有必须按顺序运行的三个命令。 dig @1.1.1.1 +short exemplo.com NS 命令确认 Cloudflare 已经对该解析器上的域具有权威性。 dig @8.8.8.8 +short mail.exemplo.com A 命令验证电子邮件日志是否返回服务器的真实 IP，而不是 Cloudflare IP。在周转后的前三十分钟内从外部地址发送电子邮件的测试将结束基本验证周期。
回滚需要在迁移之前而不是迁移期间定义标准。如果在切换域名服务器二十分钟后，其中一个关键服务未正确响应，则必须自动做出恢复到以前的域名服务器的决定，而无需召开协调会议。 DNS 事件的决策窗口很短，停电期间的争论会放大影响。
另请阅读
- [Cloudflare DNS：远远超出解析名称的网络基础设施5
- [Cloudflare 负载均衡和地理转向：当 DNS 成为智能流量层6
- [DNSSEC 与 Cloudflare：它保护什么、不保护什么以及如何顺利激活7
- [Cloudflare Durable Objects：边缘的一致状态 - 真正改变的是什么88
- [Cloudflare 电子邮件路由：在您的域上接收电子邮件 - 以及不包括的内容9
- 【Cloudflare KV：当你需要写10时，全球分布式意味着什么？