经常更改的 DNS 记录？

Question

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

让我们说example.org指向203.0.113.0. 两分钟后，它必须指向198.51.100.0。

它将是域后面的普通网站（“普通”仅在使用普通网络浏览器访问的意义上）但寿命非常短。在切换或关闭之前，域最多将指向一个地址 3-4 小时。无需保护 DNS 服务器免受频繁查询的影响。

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

不知何故，我不相信这一点......某些 ISP 或浏览器可能会忽略或覆盖 TTL，不是吗？如果这是一个有效的问题，预期的合理 TTL 是多少？

谢谢！

Answer 1

这称为Fast Flux 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 设置将产生混合和不一致的结果。

Answer 2

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

即使我们这些知道我们在谈论变化的“传播”时本质上是在撒谎（或至少是极度简单化）的人，仍然倾向于使用该术语来描述——同时——极其简单和直接的东西......但很难解释......并且与传播本身无关，但与缓存和负缓存有关，这两者都是系统工作方式的重要组成部分（并且可以说，它如何避免在它自己的重量）——本质上是由内而外，与实际的“传播”相反，拉——而不是推。

对于所有关于短 TTL 的担忧和苦恼，它们往往更有效，以至于简单地尝试它们可能符合您的利益。在 ${day_job}，当我们的站点从“旧”平台迁移到“新”平台时，这通常意味着它们的迁移方式是基础架构中的任何内容都不会共享。我在这种迁移中的第一步是在切割之前将 TTL 降低到 60 秒，这样旧的 TTL 就会有自身的多个倍数用完，这给我一个合理的保证，即这些具有短 TTL 的过渡 RR 将“传播出去” .” 当我准备好削减时，我重新配置旧的平衡器¹ 以发夹流量到新系统——通过互联网——这样平衡器不再平衡多个内部系统，而是“

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

我总是对转变发生的速度感到惊喜。坚持不懈的似乎几乎总是搜索蜘蛛和第三方“健康检查”站点，它们莫名其妙地锁定了旧记录。

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

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

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

不利的一面是，您可能会通过不必要的额外基础设施来路由流量，或者为跨多个网络边界的传输支付更多的冗余费用。

有些服务在全球范围内提供这种功能，我最熟悉的是 CloudFront。（最有可能的是，Cloudflare 的用途完全相同，因为我所做的少量测试表明它的行为也正确，我相信还有其他用途。）

虽然主要作为 CDN 销售，但 CloudFront 的核心是一个全球反向代理网络，具有选择性缓存响应的能力。如果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 .