迁移 - 以零停机时间更改 DNS 中记录的 IP答案

【问题标题】：Migration - Changing IP of A Record in DNS with Zero downtime迁移 - 以零停机时间更改 DNS 中记录的 IP
【发布时间】：2019-01-03 23:11:06
【问题描述】：

我正在将我的 API 从提供商迁移到 AWS。

我的 A 记录的 TTL 为 30 秒，所以我知道浏览器等会在 30 秒内获取旧 ip。

我想在这 30 秒 TTL 开始时收到通知，以便停止提供新的 api 请求并使迁移成为零错误。

我怎样才能知道从以前的提供商 ip 切换到 AWS ip 的确切时间？

【问题讨论】：

您没有保证所有缓存都遵守如此低的 TTL，即使它们超出标准。另外，为什么要停止在旧 IP 上提供服务？继续这样做，您自然会看到流量消失，然后您就可以停用 IP。至于 IP 更改何时可见（在权威名称服务器上），这完全取决于您的 DNS 提供商。然而，这不是一个与编程相关的问题，所以你在这里跑题了。

标签： api amazon-web-services dns migration migrate

【解决方案1】：

你不能在任何实际意义上。

您误解了 DNS 的工作原理。 DNS 由一个全球复制的系统组成，该系统将 DNS 名称解析为 IP 地址（在其基本级别）。这种复制需要多长时间，因人而异。我可以指望复制，最终。我可以管理或控制此复制吗，不可以。

TTL 是生存时间值。这是建议而非要求。许多 DNS 解析器不尊重此值。典型的 TTL 以小时、天或周为单位。不是秒。许多客户端会忽略一个较短的 TTL。

如果您希望停机时间接近于零，最佳做法是什么？您复制您的服务，以便旧的 DNS 条目和新的 DNS 条目都可以工作。预计这需要几天而不是几秒钟。

如果您还要将记录（注册）移至 AWS，请额外增加一两天。所有注册商都会告诉您，该过程可能需要几天时间才能完成。还有转移请求在以后被撤销的风险（我曾多次从 Network Solutions 转移到 Route 53）。即使在向 AWS 付款并更新记录之后，该域在数周后仍因某些“未知”原因跳回 Network Solutions。

在我的最佳实践中，我通知我的客户为关键任务系统制定 30 天计划。

【讨论】：

准确地说，它不是“复制”（即使每个人都这么说）而是复兴，因为更改不是自上而下推动的，当递归解析器决定需要数据（空缓存或过期 TTL）。
这是建议而非要求。我不同意。这是记录应该保留在缓存中的最长时间，解析器应该尊重这一点（作为最大值，因此他们可以在之前重新查询）。在实践中，它们确实是一些限制此值的解析器，特别是在太小时，但有人可能会争辩说它们违反了标准。
@PatrickMevzek - 理论上我同意你的看法。但是，我们必须为现实世界构建我们的系统。如果标准的一部分被忽略（故意、意外或错误），我们必须接受这个事实并解决它。根据 TTL 值的行为构建企业系统充其量只会让人失望。
我并不是说完全相反。将值钳制到最大值的解析器会产生更多的网络流量，但不会造成任何伤害，但钳制过短值的解析器确实违背了发布者的意愿，因此会造成问题。但与此同时，人们使用非常短的 TTL，例如 30 秒甚至 5 或 1 秒，有时会看到，可能并不完全了解 DNS 以及它是如何使用的，所以我对试图保护自己基础设施的解析器感到有些同情。
至于“转移请求将在以后撤销。”然后您似乎在这里谈论的是注册商转移，而不是权威名称服务器的更改。它们是正交的，当然除非您将注册商用作 DNS 提供商，这有其自身的缺点和好处。