实现DNS高可用性的Route 53解析器端点

作者 : Kartik Bheemisetty和Randy Weinstein
日期 : 2024年7月25日
分类 : [高级(300)](https://aws.amazon.com/blogs/networking-and-content- delivery/category/learning-levels/advanced-300/ "查看所有高级(300)的文章"), , , , ,

关键要点

• 实现高可用性的DNS体系结构至关重要，以保证应用程序的正常运作。
• 利用Route 53解析器端点可增强DNS的可靠性，特别是在混合环境中。
• 出站和入站端点的冗余设计确保在可用区失败时DNS解析仍然有效。

DNS（域名系统）是支撑几乎所有互联网服务的关键服务。由于几乎所有应用都依赖于DNS解析，因此高可用和高性能的DNS架构对应用可用性至关重要。为了确保高可用性，DNS服务必须能够抵御组件故障和网络连接问题。

Amazon Web Services (AWS)的客户运营着结构复杂且规模不一的基础设施，包括多云的混合环境与传统数据中心的结合。正如亚马逊首席技术官WernerVogels所言：“一切都会失败，随时都会发生 。”这强调了预见潜在故障的重要性，以确保即使在可用区发生故障时，应用仍能解析DNS名称。本文将重点介绍如何利用Route53解析器端点实现DNS韧性，并提供在混合环境中使用这些端点以增强商业关键应用DNS可靠性的示例和考虑事项。

Route 53解析器端点概述

Route 53解析器是Route53的一项服务，提供在Amazon虚拟私有云(VPC)中运行的资源到互联网公共资源或AWS网络内其他资源的DNS解析。如果您在AWS云之外运行自定义DNS服务，AmazonRoute53提供解析器端点来建立混合DNS解析。使AWS资源能够从VPC向外部网络或其他VPC发送DNS查询。相反，则允许从外部网络或其他VPC接收DNS查询。通过使用，您可以将DNS请求转发到适当的目标进行解析，确保不同平台和环境之间的DNS解析无缝进行。

出站端点的韧性

在深入讨论出站端点的韧性之前，我们先来了解一下当DNS查询从VPC资源通过这些端点发送时的整体DNS查询评估流程。如图1所示，当Route53解析器接收到DNS查询时，它首先评估是否存在附加在VPC上的任何解析器规则。如果DNS查询匹配现有规则以转发到出站端点，请求将通过出站端点转发到外部DNS服务。

![图1: 删除)

现在，让我们深入探讨出站端点的韧性方面。我有一个域名 example-on- prem.com，托管在两个我的内部DNS服务器上，它们是该域的权威DNS。VPC内的关键应用需要使用名称 server.example- onprem.com 连接到这些内部应用。

![图2: 删除)

如图2所示，为了达到最大的韧性，我在三个不同的可用区创建了出站端点，并关联了如图3和图4所示的解析器规则。接下来，我确保网络层已建立，并且应用程序能解析DNS名称 server.example-onprem.com。在接收到来自工作负载子网的应用DNS请求时，Route53解析器首先评估已关联的规则，然后为了冗余复制DNS查询并将其转发到任意两个出站端点接口（192.168.71.24，192.168.72.120 和 192.168.73.90）。随后，出站端点根据规则定义将这些查询转发到内部DNS服务器 10.4.1.227 和 10.4.1.118。

![图3: 删除)

![图4: 删除)

下一步是使用模拟器运行实验，模拟可用区故障。在进行此实验时，我使用工具捕获DNS查询数据包。应用服务器针对子域 server.example-on-prem.com 使用 AmazonProvidedDNS （即Route53解析器）初始化了多个DNS查询，如图5所示。

![图5: Wireshark捕获应用服务器向Route 53解析器(VPC删除)

这些DNS查询通过出站端点发送到内部DNS服务器，如图6和图7所示。需要注意的是，我使用了一个连续的DNS查询脚本来生成该演示的流量。此外，我使用的DNS记录的生存时间（TTL）值设置为ZERO。如果您启用了DNS缓存，您可能不会观察到大量数据包到达您的内部DNS服务器。

![图6: Wireshark捕获DNS服务器1，托管 example-onprem.com删除)

![图7: Wireshark捕获DNS服务器2，托管 example-onprem.com删除)

接下来，我使用FIS创建了一个AZ级电源故障场景，在一个出站解析的可用区发生了2分钟的电源故障。在我的实验中，FIS在解析器可用区（其IP地址为 192.168.71.24）模拟了网络中断。尽管发生了中断，应用服务器并未经历任何DNS超时。这是因为冗余已内置于解析器中，查询仍然从活动可用区的端点IP地址转发到内部DNS服务器。通过查看图8中目标服务器的Wireshark捕获，可以明显看出，DNS服务器收到了来自活动出站端点IP地址 192.168.72.120 和 192.168.73.90 的请求。FIS模拟结束后，所有三个端点的DNS查询恢复。

![图8: 删除)

此实验证明，在多个可用区配置出站解析器端点可确保在AWS托管应用的DNS韧性。

入站端点的韧性

同样，对于在内部或第三方云基础设施上运行的应用程序，当您的DNS域托管在AWS云上时，DNS韧性同样至关重要。如图9所示，当DNS查询在入站解析器端点接收时，它将查询转发到Route53解析器进行进一步评估。然后，您需要配置内部DNS解析器以将查询转发到入站解析器端点的IP地址。现在，让我们深入探讨韧性方面。

![图9: 删除)

如图10所示，域名 example-private-dns.com 是与入站端点创建时的VPC关联的私有托管区。确保私有托管区与入站端点所在的VPC关联至关重要，否则将导致名称解析失败。

![图10: 删除)

接下来，在三个可用区中创建入站端点以实现最大韧性，如图11所示。

![图11: 删除)

然后，配置内部DNS解析器以将DNS查询转发到三个入站解析端点的IP地址，域名为 example-private- dns.com，如图12所示。类似地，您需要为托管在AWS环境中的其他域配置，或者配置一般DNS转发以将所有查询转发到AWS入站端点DNS服务。

![图12: 删除)

来自内部应用服务器的DNS查询为 aws-app.example-private-dns.com 发送到其本地DNS解析器。正如图13所示，并根据配置的DNS转发器，查询首先发送到列表中的第一个入站端点IP地址 192.168.71.252。第三方DNS解析器的行为可能各不相同，您需要参考供应商文档。然后，DNS查询被转发到VPCDNS，最终发送到私有托管区进行最后的名称解析。

![图13: 删除)

接下来，我使用AWSFIS创建了在请求发送的可用区中进行2分钟的AZ级电源故障场景。每个DNS服务提供商可能都有其独特的解析行为，通常涉及在其配置中定义的超时设置（在本测试中为5秒）。它们设计得很快恢复并连接到列表中下一个可用的DNS转发器。一旦受影响的可用区重新激活，您将观察到DNS查询恢复，包括之前失败的入站端点IP地址的查询，如图14和图15所示。

![图14: 删除)

![图15: 删除)

此实验证明，在多个可用区配置入站解析器端点可确保在AWS运行的应用程序的DNS韧性。确保内部DNS解析器配置为将查询转发到所有入站解析器端点IP地址。

解析器端点性能及添加额外ENI

每个解析器端点IP地址可以处理高达10,000个每秒（QPS）的UDP查询，但对于DNS overHTTPS（DoH），每个网络接口的QPS要低得多。查询类型、响应大小、目标名称服务器健康状况、查询响应时间和往返延迟等因素会影响实际的QPS速率。为了确保高可用性，Route53解析器生成多个冗余出站查询。任何响应缓慢的目标名称服务器也会减少解析器端点的容量。您应该监控 InboundQueryVolume、OutboundQueryVolume 和 OutBoundQueryAggregateVolume，以便为解析器端点和每个IP地址提供监控。如果任何解析器端点IP的最大QPS超过容量的50%，建议增加一个额外的端点网络接口以获得更好的性能。

是一个网络概念，网络设备（如防火墙、路由器或NAT设备）需要跟踪和维护关于通过的IP流量状态的信息。在创建解析器端点时，可以为每个端点添加安全组，以限制允许从特定源或协议进行的DNS流量。当对端点网络接口添加限制性的安全组后，连接会被跟踪，速率可能降低至低至1,500QPS。在这种情况下，为了获得更好的性能和高可用性，您需要在每个可用区为每个端点添加额外的网络接口，或者配置安全组以避免连接跟踪，如在中所述。有关更多信息，请阅读和网络与内容交付博客帖子[使用连接跟踪改进网络