一个会频繁更改的DNSlogging？

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

虽然这将适用于您的计划，但这不是最好的计划。 你可能需要有一个或更多的备用服务器，在线，几乎所有的时间什么都不做。 只有在主服务器出现问题时，才会切换到下一个服务器。

即使你有1分钟的TTL，一个logging最有可能是有效的更多的：

1. 浏览器caching

   浏览器通常会将DNSloggingcaching不同的时间。 Firefox使用60秒 ，Chrome使用60秒 ，IE 3.x及更早版本caching24小时 ，IE 4.x及以上版本caching30分钟。

2. OScaching

   Windows 通常不会兑现TTL 。 DND的TTL与IPv4数据包的TTL不同。 这更多的是一个新鲜的迹象，而不是强制更新。 Linux可以configurationnscd来设置用户需要的时间，忽略DNS TTL。 例如，它可以caching一周的条目。

3. ISPcaching

   互联网服务提供商可以（也有一些）使用积极的caching来降低stream量。 它们不仅可以改变TTL，而且可以cachinglogging并将其返回给客户端，而不需要询问上游的DNS服务器。 这在移动ISP上更普遍，因为它们改变了TTL，所以移动客户端不会抱怨stream量延迟。

一个负载均衡器被做成你想要的。 使用负载均衡器时，可以同时在线连接2个或4个或10个服务器，分配负载。 如果其中一个脱机，服务将不会受到影响。 更改DNSlogging将在服务器closures和DNS更改之间发生停机。 这将需要一分多钟，因为您必须检测停机时间，更改logging，并等待它们传播。

所以使用一个负载平衡器。 这是做你想做的，你知道什么期望。 一个快速通量的DNS设置会有混合和不一致的结果。

DNS及其运作方式可能伴随着更多的误解，传奇，迷信和神话等IT方面的问题。

当我们谈论变化的“传播”时，即使是那些知道我们基本上在说谎（或者至less是过于简单化）的人，也倾向于使用这个词来描述同时非常简单和直接的东西。但难以解释…而且与传播本身无关，而是与caching和负面caching有关，这两者都是系统工作的基本组成部分（可以说，它是如何避免直接崩溃的自己的体重） – 基本上是从内到外，与实际的“传播”相反，拉 – 不推。

对于短期TTL的所有令人担忧和不安的事情，他们倾向于经常工作，以至于简单地尝试它们可能符合您的利益。 在$ {day_job}，当我们的网站从“旧”平台迁移到“新”平台时，通常意味着他们正在进行迁移，以至于基础架构中的任何内容都不能共享。 我在移植的第一步是将TTL降低到60秒之前，以便旧的TTL有多倍的耗尽，这使得我有理由相信，这些具有短TTL的过渡性RR将“传播出去“。 当我准备好切换时，我重新configuration旧的平衡器¹到新系统的发夹stream量 – 在互联网上 – 这样平衡器不再平衡多个内部系统，而是平衡所有请求到一个外部系统 – 新平台的平衡器

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

我总是惊喜于过渡发生的速度。 坚持似乎几乎总是search蜘蛛和第三方“健康检查”网站，莫名其妙地locking在旧的logging。

但是有一种可预见的情况：当用户的浏览器窗口保持打开状态时，他们倾向于locking已经发现的地址，并且经常持续到他们所有的浏览器窗口closures。

但是在上面的叙述中，你可以find解决这个问题的办法：一个“负载平衡器” – 特别是更准确地说，是一个反向代理 – 可以是你公开的DNSlogging指向的系统。

然后，反向代理将请求转发到正确的目标IP地址，然后使用第二个具有短TTL的“虚拟”主机名parsing该虚拟主机名，该虚拟主机名指向真实的后端服务器。3由于代理始终遵守虚拟DNS条目，您确保快速和完整的切换。

不利的一面是，您可能会通过不必要的额外基础设施路由stream量，或者为多个networking边界的传输付费。

在全球范围内有服务提供这种能力，而我最熟悉的是CloudFront。 （最有可能的是，Cloudflare可以达到完全一样的目的，因为我所做的小testing表明它的行为是正确的，我相信也有其他的。）

虽然主要是作为CDN销售的，但CloudFront的核心是一个反向代理的全球networking， 可以selectcaching响应。 如果www.example.com指向CloudFront，并将CloudFrontconfiguration为将这些请求转发到backend.example.com ，而backend.example.com的DNSlogging使用短TTL，则CloudFront将做正确的事情，因为它确实兑现那短暂的TTL。 当后端logging发生变化时，stream量将在TTL运行时全部迁移。

前端logging中指向CloudFront的TTL以及浏览器和cachingparsing器是否遵守这一规则并不重要，因为后端目标的更改不需要对www.example.comlogging进行更改…所以概念“互联网”对于www.example.com的正确目标是一致的，无论后端系统是在哪里发生的。

这对我来说，完全解决了这个问题，通过减轻浏览器对源服务器IP的“跟随”变化的任何需要。

TL; dr：将请求路由到作为真实Web服务器的代理的系统，以便只有代理configuration需要适应源服务器IP的更改 – 而不是面向浏览器的DNS。

请注意，CloudFront还通过在前端强加的一些DNS魔术最大限度地减less了延迟，从而使www.example.com根据查询www.example.com的浏览器的位置parsing到最优化的CloudFront边缘位置，因此，是最小的机会stream量采取从浏览器到边缘到源头的不必要的迂回路线…但这部分是透明的，自动的，在问题的范围之外。

当然，通过减less原始服务器或传输的负载，内容caching也可能是有价值的 – 我已经在CloudFront上configuration了原始服务器位于ADSL电路上的网站，而ADSL本质上受到上行带宽的限制。 CloudFront为了获取内容而连接的源服务器不需要是AWS生态系统内的服务器。

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

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

³当代理服务器是一个或多个您控制的服务器时，您可以select使用背面的DNS跳过，只需在代理configuration中使用IP地址，但随后讨论的托pipe/分布式scheme需要第二层DNS 。

当我更改DNSlogging时，往往旧的IP地址将被使用数月。 话虽如此，例如，亚马逊用于创build回退服务的TTL仅为几秒钟。

代替更改DNS，您可以将代理服务器/负载平衡器放在它的前面。

你可以看看使用dynamicDNS。 这是专门为@glglgl在上面的评论中提到的场景而devise的。 我相信他们使用低TTL，如前所述，可能不是100％有效，因为客户可以自由地忽略它。 但它的作品“相当不错”。

即使你不经常改变你的知识产权，重要的是保持你的TTL合理。 很多年前，我曾经为改变互联网服务提供商而改变了我们的IP。 不幸的是，我们把TTL设置为一个月的荒谬，所以旧的DNSlogging被搁置了很长时间。