经常更改的DNS记录？[关闭]

如何制作经常更改的域记录？

假设example.org指向203.0.113.0。两分钟后，它必须指向198.51.100.0。

它将是域后面的普通网站（仅在使用普通Web浏览器访问的意义上为“普通”），但使用寿命很短。域在切换或关闭之前最多只能指向3-4小时。无需保护DNS服务器免遭频繁查询。

我的方法是将TTL设置为60秒，并在必须进行切换时简单地更改记录。在最坏的情况下，这将导致用户最多等待60秒才能访问新服务器。

某种程度上我不信任...某些ISP或浏览器可以忽略或覆盖TTL，不是吗？如果确实有问题，可以预期会有一个合理的TTL吗？

谢谢！

这称为快速通量DNS记录。这通常是恶意软件作者隐藏其基础结构服务器的方式。

虽然这将对您的计划有效，但这不是最佳计划。您可能需要在线拥有一台或更多备用服务器，并且几乎始终不执行任何操作。仅当主服务器出现问题时，您才切换到下一个。

即使您的TTL为1分钟，一条记录也可能更有效：

1. 浏览器缓存

   浏览器通常会将DNS记录缓存可变的时间。Firefox使用60秒，Chrome也使用60秒，IE 3.x及更早版本缓存24小时，IE 4.x及更高版本缓存30分钟。

2. 操作系统缓存

   Windows 通常不会使用TTL。DND的TTL与IPv4数据包的TTL不同。它比强制刷新更能表示新鲜度。Linux可以将nscd配置为设置用户所需的时间量，而不考虑DNS TTL。例如，它可以将条目缓存一周。

3. ISP缓存

   ISP可以（并且有些人会）使用主动缓存来减少流量。他们不仅可以更改TTL，还可以缓存记录并将其返回给客户端，而无需询问上游DNS服务器。这在移动ISP上更为普遍，因为它们会更改TTL，因此移动客户端不会抱怨流量延迟。

负载均衡器可以完全满足您的需求。有了负载均衡器，您可以同时使2或4或10台服务器全部联机，以分担负载。如果其中之一脱机，该服务将不会受到影响。从服务器关闭到DNS更改之间，更改DNS记录将具有停机时间。这将花费一分钟以上的时间，因为您必须检测停机时间，更改记录并等待它们传播。

因此，请使用负载平衡器。它可以做您想要的，并且您知道确切的期望。快速的通量DNS设置将产生混合和不一致的结果。

DNS及其工作方式可能伴随着IT的更多方面的误解，传说，迷信和神话。

即使是当我们谈论变化的“传播”时，那些知道我们本质上在撒谎（或至少大大简化）的人，仍然倾向于使用该术语来描述-同时-极其简单明了的事物。仍然难以解释...并且与传播本身无关，但是与缓存和否定缓存有关，这两者都是系统工作方式的基本组成部分（并且可以说，它如何避免在以下情况下彻底崩溃）重量）-本质上是由内而外，与实际的“传播”相反，即为拉力-而非推力。

对于所有有关短TTL的担忧和烦恼，它们往往更常工作，以至于简单尝试一下可能符合您的利益。在$ {day_job}，当我们的站点从“旧”平台迁移到“新”平台时，通常意味着它们的迁移方式是不共享基础结构中的任何内容。我进行此类迁移的第一步是在切割前将TTL降低到60s，以使旧TTL具有自身的多个倍数以耗尽，从而为我提供了合理的保证，即这些带有短TTL的过渡RR将“传播” ”。当我准备好进行削减时，我将重新配置旧的平衡器¹，以通过Internet限制到新系统的流量，以使平衡器不再平衡多个内部系统，而是“

然后我切换DNS，并观察新的平衡器和旧的平衡器。

我总是对过渡发生得如此迅速感到惊讶。阻碍似乎几乎总是搜索蜘蛛和第三方“健康检查”站点，这些站点莫名其妙地锁定了旧记录。

但是，有一种情况可以预见地崩溃：当用户的浏览器窗口保持打开状态时，它们往往会锁定到已发现的地址，并且该地址通常会一直持续到关闭所有浏览器窗口为止。

但是，在上面的叙述中，您找到了解决问题的方法：“负载平衡器”（具体地说，更准确地说是反向代理）可以是您公开的DNS记录指向的系统。

然后，反向代理将请求转发到正确的目标IP地址，它使用第二个带有短TTL的“虚拟”主机名进行解析，该主机名指向真实的后端服务器。³因为代理始终在该主机上接受DNS TTL虚拟DNS条目，可以确保快速，完整地切换。

不利的一面是，您可能通过不必要的额外基础结构路由通信，或者为跨多个网络边界的传输支付了多余的冗余。

有一些服务可以在全球范围内提供这种功能，而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记录...因此，“ Internet”的概念www.example.com无论后端系统碰巧在何处，对于正确的目标而言，它始终是一致的。

对我来说，这可以通过使浏览器无需“跟随”对原始服务器IP的更改来完全解决问题。

tl; dr：将请求路由到充当真实Web服务器代理的系统，以便仅代理配置需要适应原始服务器IP的更改-而不是面向浏览器的DNS。

请注意，CloudFront还通过强加在前端的一些DNS魔术来最大程度地减少延迟，从而www.example.com根据查询的浏览器的位置将其解析为最佳的CloudFront边缘位置www.example.com，因此，流量通过不必要的circuit回路由的可能性很小从浏览器到边缘再到起源……但这部分是透明，自动的，不在问题范围之内。

而且，当然，通过减少原始服务器或传输上的负载，内容缓存也可能很有价值-我已经在CloudFront上配置了原始服务器位于ADSL电路上的网站，而ADSL固有地受到上游带宽的限制。CloudFront连接以获取内容的原始服务器不必是AWS生态系统内的服务器。

¹我将平衡器称为单个实体，而实际上它具有多个节点。当平衡器是ELB时，平衡器后面的机器将充当虚拟应用服务器，并实际发动到新平台的平衡器，因为ELB不能自己做到这一点。

²新平衡器对旧平衡器的唯一了解是，它需要信任旧平衡器的X-Forwarded-For，并且不应对旧平衡器的源地址进行任何基于IP的速率限制。

³当代理是您控制的一台或多台服务器时，您可以选择跳过在背面使用DNS，而仅在代理配置中使用IP地址，但是随后讨论的托管/分布式方案需要第二层DNS 。

当我更改DNS记录时，通常旧的IP地址将被使用几个月。话虽如此，例如，仅几秒钟的TTL就是Amazon用于创建后备服务的时间。

您可以在其前面放置一个代理服务器/负载平衡器，而不用更改DNS。

您可以考虑使用动态DNS。正是针对@glglgl在上面的评论中提到的场景而设计的。我相信他们使用的TTL低，如前所述，由于客户可以随意忽略它，因此可能并非100％有效。但是它“非常好”。

即使您不经常更改IP，保持TTL合理也很重要。许多年前，我曾经为变更的ISP工作的公司，导致我们的IP发生了变化。不幸的是，我们将TTL设置为一个月就很荒谬，因此旧的DNS记录被保留了很长时间。