如何通过 Route 53 解析器终端节点实现 DNS 高可用性 网络与内容交付
实现DNS高可用性的Route 53解析器端点
作者 Kartik Bheemisetty和Randy Weinstein日期 2024年7月25日分类 高级(300) Amazon Route 53 AWS WellArchitected Framework 最佳实践 网络与内容交付 技术如何做永久链接
关键要点
实现高可用性的DNS体系结构至关重要，以保证应用程序的正常运作。利用Route 53解析器端点可增强DNS的可靠性，特别是在混合环境中。出站和入站端点的冗余设计确保在可用区失败时DNS解析仍然有效。DNS域名系统是支撑几乎所有互联网服务的关键服务。由于几乎所有应用都依赖于DNS解析，因此高可用和高性能的DNS架构对应用可用性至关重要。为了确保高可用性，DNS服务必须能够抵御组件故障和网络连接问题。
Amazon Web Services (AWS)的客户运营着结构复杂且规模不一的基础设施，包括多云的混合环境与传统数据中心的结合。正如亚马逊首席技术官Werner Vogels所言：“一切都会失败，随时都会发生。”这强调了预见潜在故障的重要性，以确保即使在可用区发生故障时，应用仍能解析DNS名称。本文将重点介绍如何利用Route 53解析器端点实现DNS韧性，并提供在混合环境中使用这些端点以增强商业关键应用DNS可靠性的示例和考虑事项。
Route 53解析器端点概述
Route 53解析器是Route 53的一项服务，提供在Amazon虚拟私有云(VPC)中运行的资源到互联网公共资源或AWS网络内其他资源的DNS解析。如果您在AWS云之外运行自定义DNS服务，Amazon Route 53提供解析器端点来建立混合DNS解析。出站端点使AWS资源能够从VPC向外部网络或其他VPC发送DNS查询。相反，入站端点则允许从外部网络或其他VPC接收DNS查询。通过使用解析器规则，您可以将DNS请求转发到适当的目标进行解析，确保不同平台和环境之间的DNS解析无缝进行。
出站端点的韧性
在深入讨论出站端点的韧性之前，我们先来了解一下当DNS查询从VPC资源通过这些端点发送时的整体DNS查询评估流程。如图1所示，当Route 53解析器接收到DNS查询时，它首先评估是否存在附加在VPC上的任何解析器规则。如果DNS查询匹配现有规则以转发到出站端点，请求将通过出站端点转发到外部DNS服务。
现在，让我们深入探讨出站端点的韧性方面。我有一个域名 exampleonpremcom，托管在两个我的内部DNS服务器上，它们是该域的权威DNS。VPC内的关键应用需要使用名称 serverexampleonpremcom 连接到这些内部应用。
如图2所示，为了达到最大的韧性，我在三个不同的可用区创建了出站端点，并关联了如图3和图4所示的解析器规则。接下来，我确保网络层已建立，并且应用程序能解析DNS名称 serverexampleonpremcom。在接收到来自工作负载子网的应用DNS请求时，Route 53解析器首先评估已关联的规则，然后为了冗余复制DNS查询并将其转发到任意两个出站端点接口1921687124，19216872120 和 1921687390。随后，出站端点根据规则定义将这些查询转发到内部DNS服务器 1041227 和 1041118。
下一步是使用AWS故障注入服务FIS模拟器运行实验，模拟可用区故障。在进行此实验时，我使用Wireshark工具捕获DNS查询数据包。应用服务器针对子域 serverexampleonpremcom 使用 AmazonProvidedDNS 即Route 53解析器初始化了多个DNS查询，如图5所示。
这些DNS查询通过出站端点发送到内部DNS服务器，如图6和图7所示。需要注意的是，我使用了一个连续的DNS查询脚本来生成该演示的流量。此外，我使用的DNS记录的生存时间TTL值设置为ZERO。如果您启用了DNS缓存，您可能不会观察到大量数据包到达您的内部DNS服务器。
接下来，我使用FIS创建了一个AZ级电源故障场景，在一个出站解析的可用区发生了2分钟的电源故障。在我的实验中，FIS在解析器可用区其IP地址为 1921687124模拟了网络中断。尽管发生了中断，应用服务器并未经历任何DNS超时。这是因为冗余已内置于解析器中，查询仍然从活动可用区的端点IP地址转发到内部DNS服务器。通过查看图8中目标服务器的Wireshark捕获，可以明显看出，DNS服务器收到了来自活动出站端点IP地址 19216872120 和 1921687390 的请求。FIS模拟结束后，所有三个端点的DNS查询恢复。
飞兔加速器官网ios此实验证明，在多个可用区配置出站解析器端点可确保在AWS托管应用的DNS韧性。
入站端点的韧性
同样，对于在内部或第三方云基础设施上运行的应用程序，当您的DNS域托管在AWS云上时，DNS韧性同样至关重要。如图9所示，当DNS查询在入站解析器端点接收时，它将查询转发到Route 53解析器进行进一步评估。然后，您需要配置内部DNS解析器以将查询转发到入站解析器端点的IP地址。现在，让我们深入探讨韧性方面。
如图10所示，域名 exampleprivatednscom 是与入站端点创建时的VPC关联的私有托管区。确保私有托管区与入站端点所在的VPC关联至关重要，否则将导致名称解析失败。
接下来，在三个可用区中创建入站端点以实现最大韧性，如图11所示。
然后，配置内部DNS解析器以将DNS查询转发到三个入站解析端点的IP地址，域名为 exampleprivatednscom，如图12所示。类似地，您需要为托管在AWS环境中的其他域配置，或者配置一般DNS转发以将所有查询转发到AWS入站端点DNS服务。
来自内部应用服务器的DNS查询为 awsappexampleprivatednscom 发送到其本地DNS解析器。正如图13所示，并根据配置的DNS转发器，查询首先发送到列表中的第一个入站端点IP地址 19216871252。第三方DNS解析器的行为可能各不相同，您需要参考供应商文档。然后，DNS查询被转发到VPC DNS，最终发送到私有托管区进行最后的名称解析。
接下来，我使用AWS FIS创建了在请求发送的可用区中进行2分钟的AZ级电源故障场景。每个DNS服务提供商可能都有其独特的解析行为，通常涉及在其配置中定义的超时设置在本测试中为5秒。它们设计得很快恢复并连接到列表中下一个可用的DNS转发器。一旦受影响的可用区重新激活，您将观察到DNS查询恢复，包括之前失败的入站端点IP地址的查询，如图14和图15所示。
此实验证明，在多个可用区配置入站解析器端点可确保在AWS运行的应用程序的DNS韧性。确保内部DNS解析器配置为将查询转发到所有入站解析器端点IP地址。
解析器端点性能及添加额外ENI
每个解析器端点IP地址可以处理高达10000个每秒QPS的UDP查询，但对于DNS over HTTPSDoH，每个网络接口的QPS要低得多。查询类型、响应大小、目标名称服务器健康状况、查询响应时间和往返延迟等因素会影响实际的QPS速率。为了确保高可用性，Route 53解析器生成多个冗余出站查询。任何响应缓慢的目标名称服务器也会减少解析器端点的容量。您应该监控CloudWatch指标 InboundQueryVolume、OutboundQueryVolume 和 OutBoundQueryAggregateVolume，以便为解析器端点和每个IP地址提供监控。如果任何解析器端点IP的最大QPS超过容量的50，建议增加一个额外的端点网络接口以获得更好的性能。
连接跟踪是一个网络概念，网络设备如防火墙、路由器或NAT设备需要跟踪和维护关于通过的IP流量状态的信息。在创建解析器端点时，可以为每个端点添加安全组，以限制允许从特定源或协议进行的DNS流量。当对端点网络接口添加限制性的安全组后，连接会被跟踪，速率可能降低至低至1500 QPS。在这种情况下，为了获得更好的性能和高可用性，您需要在每个可用区为每个端点添加额外的网络接口，或者配置安全组以避免连接跟踪，如在未跟踪的连接中所述。有关更多信息，请阅读解析器端点扩展和网络与内容交付博客帖子[使用连接跟踪改进网络
