如何制作可以频繁更改的域名logging?
假设example.org
指向203.0.113.0
。 两分钟后,它必须指向198.51.100.0
。
这将是域名后面的正常网站(仅在使用普通网页浏览器访问的意义上的“正常”),但寿命很短。 域名在被切换或closures之前最多会指向一个3-4小时的地址。 没有必要保护DNS服务器免受频繁的查询。
我的方法是将TTL设置为60秒,只需在切换时更改logging。 在最坏的情况下,会导致用户等待最多60秒才能访问新的服务器。
不知何故,我不信任…有些ISP或浏览器可以忽略或重写TTL,不是吗? 如果这是一个有效的担忧,那么预期的TTL是多less?
谢谢!
这被称为快速通量DNSlogging 。 这通常是恶意软件作者隐藏其基础架构服务器的方式。
虽然这将适用于您的计划,但这不是最好的计划。 你可能需要有一个或更多的备用服务器,在线,几乎所有的时间什么都不做。 只有在主服务器出现问题时,才会切换到下一个服务器。
即使你有1分钟的TTL,一个logging最有可能是有效的更多的:
浏览器caching
浏览器通常会将DNSloggingcaching不同的时间。 Firefox使用60秒 ,Chrome使用60秒 ,IE 3.x及更早版本caching24小时 ,IE 4.x及以上版本caching30分钟。
OScaching
Windows 通常不会兑现TTL 。 DND的TTL与IPv4数据包的TTL不同。 这更多的是一个新鲜的迹象,而不是强制更新。 Linux可以configurationnscd来设置用户需要的时间,忽略DNS TTL。 例如,它可以caching一周的条目。
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.com
logging进行更改…所以概念“互联网”对于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被搁置了很长时间。