如何创建可以频繁更改的域名记录？
假设example.org指向203.0.113.0。两分钟后它必须指向198.51.100.0。
域名后面将是普通网站（“普通”仅指使用普通网络浏览器访问的网站），但寿命非常短。域名最多会指向一个地址 3-4 小时，之后就会切换或关闭。无需保护 DNS 服务器免受频繁查询的影响。
我的方法是将 TTL 设置为 60 秒，并在需要切换时更改记录。在最坏的情况下，这将导致用户最多等待 60 秒才能访问新服务器。
不知为何，我不太相信这一点……有些 ISP 或浏览器可能会忽略或覆盖 TTL，不是吗？如果这是一个合理的担忧，那么合理的 TTL 应该是多少？
谢谢你！
答案1
这就是所谓的Fast Flux DNS 记录. 这通常是恶意软件作者隐藏其基础设施服务器的方式。
虽然这适用于您的计划，但这不是最好的计划。您可能需要有一台或多台备用服务器，在线，并且几乎一直不做任何事情。只有当您的主服务器出现问题时，您才会切换到下一个服务器。
即使您的 TTL 为 1 分钟，一条记录的有效期也很可能会超过 1 分钟：
浏览器缓存
浏览器通常会缓存 DNS 记录一段时间。Firefox 使用60 秒，Chrome 使用60 秒IE 3.x 及更早版本也缓存24小时，IE 4.x 及以上版本缓存30分钟。
操作系统缓存
Windows 将通常不遵守 TTL。DND 的 TTL 与 IPv4 数据包的 TTL 不同。它更多的是新鲜度指示，而不是强制刷新。Linux 可以配置 nscd 来设置用户想要的时间量，而不管 DNS TTL。例如，它可以缓存条目一周。
ISP 缓存
ISP 可以（有些会）使用积极缓存来减少流量。它们不仅可以更改 TTL，还可以缓存记录并将其返回给客户端，甚至无需询问上游 DNS 服务器。这在移动 ISP 上更为普遍，因为它们会更改 TTL，这样移动客户端就不会抱怨流量延迟。
负载平衡器就是为了满足您的需求而设计的。有了负载平衡器，您可以同时让 2 台、4 台或 10 台服务器在线，从而分担负载。如果其中一台服务器离线，服务不会受到影响。更改 DNS 记录会在服务器离线和更改 DNS 之间产生停机时间。这将花费一分钟以上的时间，因为您必须检测停机时间、更改记录并等待它们传播。
因此请使用负载平衡器。它可以做您想做的事情，而且您确切地知道会发生什么。快速通量 DNS 设置会产生混乱且不一致的结果。
答案2
DNS 及其工作原理可能与 IT 的任何方面一样伴随着更多的误解、传说、迷信和神话。
即使我们当中有些人知道，当我们谈论变化的“传播”时，我们本质上是在撒谎（或至少是大大简化），但仍然倾向于使用这个术语来描述某种东西——同时——极其简单和直接……但很难解释……而且与传播无关本身但一切都与缓存和负缓存有关，这两者都是系统工作方式的重要组成部分（并且可以说是它如何避免在自身重量下彻底崩溃） - 本质上是从内到外，与实际的“传播”相反，拉 - 而不是推。
尽管人们对短 TTL 感到担忧和焦虑，但它们往往能发挥作用，因此您可能也想尝试一下。在 ${day_job}，当我们的网站从“旧”平台迁移到“新”平台时，这通常意味着它们正在以一种基础设施中没有任何内容共享的方式进行迁移。我在这种迁移中的第一步是在切换之前将 TTL 降低到 60 秒，以便旧 TTL 有多个倍数可以耗尽，从而让我有理由相信这些具有短 TTL 的过渡 RR 将“传播出去”。当我准备好切换时，我会重新配置旧平衡器¹，以将流量发夹到新系统（通过互联网），这样平衡器就不再平衡多个内部系统，而是将所有请求“平衡”到单个外部系统——新平台的平衡器²。
然后我切换 DNS，并观察新的平衡器和旧的平衡器。
我总是惊喜地发现这种转变发生得如此之快。坚持者似乎几乎总是搜索蜘蛛和第三方“健康检查”网站，它们莫名其妙地抓住了旧记录。
但有一种情况是可以预见的：当用户的浏览器窗口保持打开状态时，他们倾向于锁定已经发现的地址，并且通常会持续存在，直到所有浏览器窗口都关闭。
但在上面的叙述中，您找到了问题的解决方案：“负载均衡器” - 具体来说，更准确地说是反向代理 - 可以是您的公开 DNS 记录指向的系统。
然后，反向代理将请求转发到正确的目标 IP 地址，它使用具有较短 TTL 的第二个“虚拟”主机名进行解析，该主机名指向真正的后端服务器。³ 因为代理始终遵守该虚拟 DNS 条目上的 DNS TTL，所以可以确保快速、彻底地切换。
缺点是，您可能会通过不必要的额外基础设施来路由流量，或者为跨多个网络边界的传输支付更多的费用。
有一些服务可以在全球范围内提供这种功能，我最熟悉的是 CloudFront。（最有可能的是，Cloudflare 可以实现完全相同的目的，因为我所做的少量测试表明它也能正常运行，而且我相信还有其他服务。）
尽管 CloudFront 主要作为 CDN 进行营销，但其核心是一个全球反向代理网络，具有以下功能：可选地缓存响应。如果www.example.com指向 CloudFront，并且 CloudFront 配置为将这些请求转发到backend.example.com，并且的 DNS 记录backend.example.com使用短 TTL，则 CloudFront 将执行正确的操作，因为它确实遵守该短 TTL。当后端记录发生变化时，流量将在 TTL 耗尽时全部迁移。
指向 CloudFront 的前端记录上的 TTL，以及浏览器和缓存解析器是否遵守它并不重要，因为对后端目标的更改不需要更改记录www.example.com……因此“互联网”对于正确目标的概念www.example.com是一致的，无论后端系统位于何处。
对我来说，这彻底解决了问题，因为浏览器不再需要“跟随”原始服务器 IP 的变化。
tl; dr：将请求路由到作为真实 Web 服务器的代理的系统，这样只有代理配置需要适应原始服务器 IP 的变化 - 而不是面向浏览器的 DNS。
请注意，CloudFront 还通过它在前端施加的一些 DNS 魔法来最大限度地减少延迟，从而www.example.com根据查询浏览器的位置解析到最优的 CloudFront 边缘位置www.example.com，因此流量从浏览器到边缘再到原点需要不必要地绕行的路线的可能性很小……但这部分是透明和自动的，超出了问题的范围。
当然，内容缓存也可能通过减少原始服务器或传输的负载而发挥价值——我已在 CloudFront 上配置了网站，其中原始服务器位于 ADSL 线路上，而 ADSL 的上行带宽天生就受到限制。CloudFront 连接以获取内容的原始服务器不必是 AWS 生态系统内的服务器。
¹ 我将平衡器视为单个实体，但实际上它有多个节点。当平衡器是 ELB 时，平衡器后面的机器充当虚拟应用服务器，并实际执行与新平台平衡器的连接，因为 ELB 无法自行执行此操作。
² 新平衡器对旧平衡器的唯一了解是，它需要信任旧平衡器的 X-Forwarded-For，并且它不应该对旧平衡器的源地址进行任何基于 IP 的速率限制。
³ 当代理是您控制的一个或多个服务器时，您可以选择跳过在后端使用 DNS，而只是在代理配置中使用 IP 地址，但随后讨论的托管/分布式场景需要第二层 DNS。
答案3
当我更改 DNS 记录时，旧 IP 地址通常会被使用数月。话虽如此，但 Amazon 仅使用几秒钟的 TTL 来创建后备服务。
您无需更改 DNS，而是可以在其前面放置代理服务器/负载平衡器。
答案4
您可以考虑使用动态 DNS。这恰恰是针对 @glglgl 在上面的评论中提到的场景而设计的。我相信他们使用了较低的 TTL，正如前面指出的那样，这可能不是 100% 有效，因为客户端可以自由地忽略它。但它工作得“相当好”。
即使您不经常更改 IP，保持合理的 TTL 也很重要。很多年前，我以前工作的公司更换了 ISP，导致我们的 IP 也发生了变化。不幸的是，我们将 TTL 设置为一个月这样的荒谬时间，因此旧的 DNS 记录被保留了很长时间。