我有一个域名（目前托管在 dyn.com 上），其中有一条A指向我们生产 IP 地址的记录。
我们正在转移到 Amazon EC2 并使用负载均衡器，建议我们使用CNAME而不是A记录，因为负载均衡器可能会定期更改 IP 地址。
不幸的是，我似乎无法无缝地完成这种转变——我必须先删除 A 记录，然后添加 CNAME，这可能会导致新记录传播时出现停机。
有没有什么方法可以顺利地完成这项工作，并且零停机时间（或极少停机时间）？
答案1
那里是你可以在这里使用一个技巧。话虽如此，韦斯利是个聪明人，你应该听他的。我并没有因为这么说而得到报酬，但我希望有一天能改变这一点。
假设您尝试更改名为...www的区域中的一条记录。example.com.
*在区域中创建临时通配符 A 记录 ( )。提交更改。测试它，确保通配符记录按预期运行并覆盖 NXDOMAIN 响应。- 删除
wwwA 记录。提交。 - 添加新的 CNAME 记录。提交。再次测试。
*当您满意时，删除通配符记录。- 听从 Wesley 的建议，找到一个不会强迫您经历此类麻烦的 DNS 提供商。
由于这关系到你的声誉，你可能需要快速复习关于维基百科关于如何处理通配符的说法。确保您正在添加一个通配符，其点数与要删除的记录相同，因为通配符记录不会遍历点。（如果您想要正确的 RFC 术语，则称为标签）
此外，这应该是不言而喻的，但所有这些测试都应该直接针对您的权威服务器运行。（不是针对您正在运行测试的计算机配置的默认解析器）
答案2
我们正在迁移到 Amazon EC2 并使用负载均衡器，建议我们使用 CNAME 而不是 A 记录
我真诚地希望您没有对您的顶级域名进行 CNAME。如果您的 DNS 主机有自尊心，则不会允许这样做。如果它是一个可耻且卑鄙的主机，您可以这样做，但您会失去一部分灵魂（但无论如何您都在使用 EC2，因此看起来对您灵魂的担忧已经微不足道了）。
您无法使用 CNAME 记录将区域顶点与 Elastic Load Balancing 实例关联。DNS 规则禁止在区域顶点（例如 example.com）创建 CNAME 记录。例如，如果您拥有 example.com 域名，则可以对 foo.example.com 子域名使用 CNAME 记录，但不能对 example.com 区域顶点使用 CNAME 记录。
继续...
...因为负载平衡器可能会定期更改 IP 地址。
不，负载均衡器不应该定期更改 IP 地址。这就是他们的观点。它们保持不变，并充当消费者和内容基础设施之间的抽象层。如果有人告诉您负载均衡器的 IP 地址可能会定期更改，请向他们询问清楚。
Amazon ELB 已到位，因此目标是将您的域名 CNAME 为 ELB 的名称。我现在了解情况了。
不幸的是，我似乎无法无缝地完成这种转变——我必须先删除 A 记录，然后添加 CNAME，这可能会导致新记录传播时出现停机。
如果没有一些多播诡计，甚至没有 BGP 的一点点古怪，DNS 本身就不可能实现零停机时间更改。但是，您可以通过将记录的 TTL 值降低到允许的最短时间，将停机时间的可能性降到最低。通常为 60 秒，但如果您的 DNS 主机不允许它降到这么低，那么请让您的干草叉增强，因为那太糟糕了。无论如何，将您的记录降低到尽可能低的数字，然后等待上一个 TTL 值的时间。如果您之前的 TTL 值为 3600 秒，则在将 TTL 值更改为 60 秒后等待一个小时。
等待这么长时间后，您可以将 A 记录更改为 CNAME，这样大约只会有 60 秒的停机时间。
我做过类似的切换，没有停机时间，但同步是在数据存储上进行的，因此在模糊的切换期间，任何过滤到新旧系统的事务都会与后端魔法同步。除非你处理大量用户和金钱，否则这通常会花费比合理更多的时间和精力。
TTL 已经为 60 秒，但 SOA NXDOMAIN TTL 为 1800 秒
...只有当您的域名发生某些事情并返回 NXDOMAIN 响应时，这才会成为问题，而当您将记录从 A 更改为 CNAME 时则不会出现此问题。
因此，删除现有的 A 记录可能会导致停机时间长达 30 分钟（据我所知）
不，因为您不是在删除，而是在更改，并且任何合理的 DNS 主机都会一次性删除 A 记录并添加 CNAME，因此您不会使用 NXDOMAIN 响应任何请求。
如果 Dyn 将对区域的每次更改都视为单独提交到区域文件的原子操作，那么您就有可能返回 NXDOMAIN 响应。这对于 Dyn 来说是一件很糟糕的事情，但并不完全令人惊讶。
我似乎无法通过 dyn.com 进行更改
我的看法（加上 5 美元可以在星巴克买一杯咖啡）：Dyn 是一个糟糕的 DNS 主机。