使用 Route 53 的多个复制 DNS 提供商

Jon*_*ver 3 dns-hosting amazon-route53

我管理着一些相当简单的域,只有 A 记录、CNAMES 和一些其他常见的记录类型。我经常听到的一件事是来自各种专业 DNS 提供商(例如 DynDNS、DNSimple,以及更基本的提供商(例如 GoDaddy)等)的重大中断。

虽然 AWS Route 53 从未宕机,并且有大量复制,而且他们有 100% 的正常运行时间 SLA,但我想知道将我们所有的鸡蛋放在一个篮子里是否只是自找麻烦。

有没有人知道让 Route 53 成为主要或次要 DNS 提供商的好方法(即使 DNS 领域中确实没有主要/次要这样的东西)并且有一个替代提供商可以自动检测然后将更改推送到/来自 53 号公路?

任何人都可以列出一些用于防止单点故障的技术,而不是在硬件中,而是在单个提供者中。

Mic*_*bot 8

Route 53 不支持区域传输。

对 Route53 的 DNS 区域传输 (AXFR/IXFR) 支持是一项广受欢迎的功能,我们将考虑在未来添加该功能。

https://forums.aws.amazon.com/click.jspa?searchID=6666267&messageID=326081

当然,您可以在内部系统中管理您的 DNS 记录,并通过 API 以编程方式将设置推送到 Route 53,并使用其他提供商的界面将设置推送到另一个提供商,但这并不完全是“自动的”。

Route 53 中的故障总是可能的,但似乎不太可能。它的设计方式似乎应该允许发生大量灾难性故障,而不会实际影响可用性。

该服务是集中管理的,但在全球范围内分布,并且分配给您的每个托管区域的 4 个名称服务器并不是 4 个实际服务器,每个服务器都位于特定位置,而是实际上 4 个任播 IP 地址,对应于跨区域的 4 个以上实际服务器地球。

尽管架构细节不是公开的,但坊间观察表明,当您更新 DNS 记录时,它们几乎会立即被推送到所有单个服务器,因此当单个名称服务器需要更新时,无需依赖中央数据库查资料。他们复制了副本。一旦数据在全球传播,它就可以在边缘位置进行查询,并且可以完全禁用集中管理基础设施,而不会影响服务查询的能力。

另请注意,您的每个托管区域与任何其他托管区域的共同分配名称服务器永远不会超过任何 2 个,因此即使意外影响您的一个区域的所有服务器的中断也不应该影响多个您的区域。

使用任播的事实还意味着,如果严重中断使边缘网络中的某个位置完全脱机,则该边缘的路由公告将消失,导致流量自动路由到正在公告相同 IP 地址的不同边缘。

您会注意到,您的 4 个名称服务器名称分布在 4 个顶级域(.com、.net、.org、.co.uk)中,这进一步缓解了也可能导致问题的全球 DNS 问题。53 号公路似乎经过精心设计,甚至可以解决即使发生了 53 号公路也无法控制的潜在问题。

中断从来都不是真的不可能,但我对 Route 53 设计的评估(基于我可以从外部观察到的)表明 Route 53 中的服务中断不太可能使故障转移服务变得不必要,并且可以说,添加备用服务可能会减少可靠性,如果替代服务不像 Route 53 那样具有弹性。

AWS架构博客的路线53类提供了有关设计到线路53弹性一些有趣的见解。