本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Amazon Route 53 的最佳实践
本节提供了 Amazon Route 53 各个组件的最佳实践，包括：
1. **DNS 最佳实践：**
+ 了解生存时间 (TTL) 值和响应能力与可靠性之间的权衡取舍。
+ 尽可能使用别名记录代替 CNAME 记录，以提高性能并节省成本。
+ 配置默认路由策略，确保所有客户端都能收到响应。
+ 利用基于延迟的路由来最大限度地减少应用程序延迟，利用 geolocation/geoproximity 路由来实现稳定性和可预测性。
+ 使用面向自动化工作流程的 `GetChange` API 验证更改的传播。
+ 委托来自父区域的子域以实现一致的路由。
+ 使用多值应答路由，避免大量的单一响应。
1. **Resolver 最佳实践：**
+ 通过避免同一 VPC 同时与 Resolver 规则及其入站端点相关联来防止路由循环。
+ 实施安全组规则以减少连接跟踪开销，并最大程度地提高查询吞吐量。
+ 配置入站端点，采用多个可用区中的 IP 地址以实现冗余。
+ 请注意潜在的 DNS 区域行走攻击，如果您的终端遇到限制，请联系 Su AWS pport。
1. **运行状况检查最佳实践：**
+ 遵循有关优化 Amazon Route 53 运行状况检查的建议，确保可靠监控资源
通过遵循这些最佳实践，就可以优化 DNS 基础设施的性能、可靠性和安全性，确保将流量高效地路由到应用程序和服务
**Topics**
+ [Amazon Route 53 DNS 的最佳实践](best-practices-dns.md)
+ [VPC 解析器的最佳实践](best-practices-resolver.md)
+ [Amazon Route 53 运行状况检查的最佳实践](best-practices-healthchecks.md)
# Amazon Route 53 DNS 的最佳实践
使用 Amazon Route 53 DNS 服务时，请遵循以下最佳实践来获得最佳结果。
**使用数据层面功能进行 DNS 故障转移和应用恢复**
Route 53 的数据层面（包括运行状况检查和 Amazon 应用程序恢复控制器 (ARC) 路由控制在全球范围内分布，旨在于存在严重事件时依然能够实现 100% 的可用性和功能性。它们彼此集成，不依赖于控制面板的功能。虽然这些服务（包括其控制台）的控制面板通常非常可靠，但它们的设计方式更集中，且会优先考虑持久性和一致性，而不是高可用性。对于灾难恢复期间的失效转移等方案，我们建议您使用 Route 53 运行状况检查和 ARC 路由控制之类的功能，这些功能将依赖数据面板功能来更新 DNS。有关更多信息，请参阅[控制和数据层面概念](route-53-concepts.md#route-53-concepts-control-and-data-plane)和[博客：使用 Amazon Route 53 创建灾难恢复机制](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)。
**为 DNS 记录选择 TTL 值**
DNS TTL 是数字值（以秒为单位），DNS 解析器用于决定在不对 Route 53 进行另一次查询的情况下，记录可以缓存的时长。必须为所有 DNS 记录指定 TTL。TTL 值的推荐范围为 60 到 172,800 秒。
选择 TTL 就是在延迟和可靠性以及对变化的响应能力之间进行权衡。由于记录时间较短 TTLs ，DNS 解析器会更快地注意到记录的更新，因为他们必须更频繁地进行查询。这会增加查询量（和成本）。随着 TTL 不断延长，DNS 解析器会更频繁地应答缓存中的查询，这样的操作通常更快、更便宜，且在某些情况下更可靠，因为它避免了在互联网上开展的查询。没有所谓正确的选择，但您可以考虑是响应性还是可靠性对您而言更重要。
设置 TTL 值时要考虑的事项包括：
+ 将 DNS 记录设置 TTLs 为您可以承受的等待更改生效的时间长度。对于委派（NS 记录集）或其他很少更改的记录（例如 MX 记录）而言，情况尤其如此。对于这些记录，建议使用 TTLs 更长的时间。1 小时（3600 秒）和 1 天（86,400 秒）之间的值是较为常见的选择。
+ 对于需要作为快速故障转移机制的一部分进行更改的记录（尤其是经过健康检查的记录），较低的值 TTLs是合适的。在这种情况下，通常选择将 TTL 设置为 60 秒或 120 秒。
+ 当您要更改关键 DNS 条目时，我们建议您暂时缩短 TTLs。如果需要，您随后可以快速进行更改、观察和回滚。在更改完成并按预期工作后，您可以增加 TTL。
有关更多信息，请参阅 [TTL（秒）](resource-record-sets-values-shared.md#rrsets-values-common-ttl)。
**CNAME 记录**
DNS CNAME 记录是一种将一个域名指向另一个域名的方法。如果 DNS 解析器解析了 domain-1.example.com 并找到指向 domain-2.example.com 的别名记录，则 DNS 解析器必须继续解析 domain-2.example.com，然后才能响应。这些记录适用于许多情况，例如当网站拥有多个域名时确保一致性。
但是，DNS 解析器必须进行更多查询才能回答 CNAMEs，这会增加延迟和成本。在可能的情况下，使用 Route 53 别名记录是一种速度更快、价格更低的替代方案。别名记录允许 Route 53 对 AWS 资源（例如负载均衡器）和同一托管区域内的其他域直接做出响应。
有关更多信息，请参阅 [将互联网流量路由到您的 AWS 资源](routing-to-aws-resources.md)。
**高级 DNS 路由**
+ 使用地理位置、地理邻近或基于延迟的路由时，请始终设置默认值，除非您希望某些客户端接收*没有应答*的响应。
+ 为了尽量减少应用程序延迟，请使用基于延迟的路由。这种类型的路由数据可能会经常更改。
+ 要确保路由稳定性和可预测性，请使用地理位置或地理邻近路由。
有关更多信息，请参阅 [地理位置路由](routing-policy-geo.md)、[地理位置临近度路由](routing-policy-geoproximity.md) 和 [基于延迟的路由](routing-policy-latency.md)。
**DNS 更改传播**
当您使用 Route 53 控制台或 API 创建或更新记录或托管区域时，更改需要一段时间才能在互联网上反映出来。这被称为*更改传播*。尽管在全球范围内的传播通常不到一分钟，但偶尔会出现延迟，例如由于同步到一个位置的问题，或者在极少数情况下由于中央控制面板内出现问题。如果您正在构建自动配置工作流程，并且必须等待变更传播完成后再继续下一个工作流程步骤，请使用 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API 验证您的 DNS 更改是否已生效（`Status =INSYNC`）。
**DNS 委派**
当您在 DNS 中委派多个级别的子域时，始终从父区域委派非常重要。例如，如果您正在委派 www.dept.example.com，则应该从 dept.example.com 区域执行，而不是从 example.com 区域执行。从*祖父*区域到*子*区域的委派可能根本无法正常工作，也可能仅以不一致的方式工作。有关更多信息，请参阅 [路由子域的流量](dns-routing-traffic-for-subdomains.md)。
**DNS 响应的大小**
避免创建大型单个响应。如果响应大于 512 字节，则许多 DNS 解析器必须通过 TCP 而不是 UDP 重试，这会降低可靠性并导致响应速度变慢。我们建议使用多值应答路由，它将选择 8 个运行正常的随机 IP 来将响应保持在 512 字节边界内。
有关更多信息，请参阅 [多值应答路由](routing-policy-multivalue.md) 和 [DNS 回包大小测试服务器](https://www.dns-oarc.net/oarc/services/replysizetest/)。
# VPC 解析器的最佳实践
本节提供优化 Amazon Route 53 VPC 解析器的最佳实践，涵盖以下主题：
1. **避免使用 Resolver 端点循环配置：**
+ 确保同一 VPC 不会同时与 Resolver 规则及其入站端点相关联，从而防止路由循环。
+ 利用 AWS RAM 它在账户 VPCs 之间共享，同时保持正确的路由配置。
有关更多信息，请参阅 [避免使用 Resolver 端点循环配置](best-practices-resolver-endpoints.md)。
1. **Resolver 端点扩展：**
+ 实施根据连接状态允许通信的安全组规则，以减少连接跟踪开销
+ 遵循针对入站和出站 Resolver 端点的推荐安全组规则，最大程度地提高查询吞吐量。
+ 监控生成 DNS 流量的唯一 IP 地址和端口组合，避免出现容量限制。
有关更多信息，请参阅 [Resolver 端点扩展](best-practices-resolver-endpoint-scaling.md)。
1. **Resolver 端点的高可用性：**
+ 创建入站端点，采用至少两个可用区中的 IP 地址以实现冗余。
+ 配置额外的网络接口，以确保维护或流量激增期间的可用性
有关更多信息，请参阅 [解析程序端点的高可用性](best-practices-resolver-endpoint-high-availability.md)。
1. **防止 DNS 区域步行攻击：**
+ 注意潜在的 DNS 区域步行攻击，攻击者会试图从 DNSSEC 签名的 DNS 区域检索所有内容。
+ 如果您的终端由于怀疑区域行走而出现限流，请联系 Support AWS 寻求帮助。
有关更多信息，请参阅 [DNS 区域步行](best-practices-resolver-zone-walking.md)。
通过遵循这些最佳实践，您可以优化 VPC Resolver 部署的性能、可扩展性和安全性，从而确保您的应用程序和资源可靠、高效地解析 DNS。
# 避免使用 Resolver 端点循环配置
不要将同一 VPC 与 Resolver 规则及其入站端点关联（无论它是端点的直接目标，还是通过本地部署 DNS 服务器）。当 Resolver 规则中的出站端点指向与规则共享 VPC 的入站端点时，可能会导致一个循环，其中查询在入站和出站端点之间持续传递。
仍然可以使用 AWS Resource Access Manager (AWS RAM) 将转发规则与其他 VPCs 账户共享的转发规则相关联。与中心关联的私有托管区域（或中央 VPC）仍将从查询解析到入站端点，因为转发解析程序规则不会更改此分辨率。
# Resolver 端点扩展
Resolver 端点安全组使用连接跟踪来收集有关进出端点的流量信息。每个端点接口都具有可跟踪的最大连接数，并且大量 DNS 查询可能会超过连接，从而导致节流和查询丢失。连接跟踪 AWS是监控流经安全组的流量状态的默认行为（SGs）。在中使用连接跟踪 SGs 会降低流量的吞吐量，但是，您可以实现未跟踪的连接以减少开销并提高性能。有关更多信息，请参阅[未跟踪的连接](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections)。
如果使用限制性安全组规则强制执行连接跟踪，或者通过网络负载均衡器路由查询（请参阅[自动跟踪的连接](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)），则对于一个端点来说，每个 IP 地址每秒处理的最大查询总数可能低至 1500。
**入站 Resolver 端点的入口和出口安全组规则建议**
****
|
|
| **入口规则** |
| --- |
| 协议类型 | 端口号 | 源 IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
| **出口规则** |
| --- |
| 协议类型 | 端口号 | 目的地 IP |
| TCP | 全部 | 0.0.0.0/0 |
| UDP | 全部 | 0.0.0.0/0 |
**出站 Resolver 端点的入口和出口安全组规则建议**
****
|
|
| **入口规则** |
| --- |
| 协议类型 | 端口号 | 源 IP |
| TCP | 全部 | 0.0.0.0/0 |
| UDP | 全部 | 0.0.0.0/0 |
| **出口规则** |
| --- |
| 协议类型 | 端口号 | 目的地 IP |
| TCP | 53 | 0.0.0.0/0 |
| UDP | 53 | 0.0.0.0/0 |
**注意**
**安全组端口要求：**
**入站端点**需要入口规则，这些规则允许端口 53 上的 TCP 和 UDP 接收来自您网络的 DNS 查询。出口规则可以允许所有端口，因为端点可能需要响应来自不同源端口的查询。
**出站端点**需要出口规则，这些规则允许 TCP 和 UDP 访问您网络上用于 DNS 查询的端口。上面的示例中显示端口 53，因为它是最常见的 DNS 端口，但您的网络可能使用不同的端口。入口规则可以允许所有端口容纳来自 DNS 服务器的响应。
**入站 Resolver 端点**
对于使用入站解析程序端点的客户端，如果您拥有超过 40,000 个唯一 IP 地址和端口组合来生成 DNS 流量，弹性网络接口的容量将受到影响。
# 解析程序端点的高可用性
在创建 VPC 解析器入站终端节点时，Route 53 要求您创建至少两个 IP 地址，网络上的 DNS 解析器会将查询转发到这两个 IP 地址。您还应在至少两个可用区中指定 IP 地址以实现冗余。
如果您要求任何时候都可用多个弹性网络接口端点，我们建议您在自身需求的基础上至少再多创建一个的网络接口，以确保您有额外的容量可用于处理可能的流量激增。额外的网络接口还可确保维护或升级等服务操作期间的可用性。
有关更多信息，请参阅这篇详细的博客文章：[如何使用解析器端点实现 DNS 的高可用性](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/)以及[创建或编辑入站端点时指定的值](resolver-forwarding-inbound-queries-values.md)。
# DNS 区域步行
DNS 区域步行攻击试图从 DNSSEC 签名的 DNS 区域获取所有内容。如果 VPC Resolver 团队检测到的流量模式与在您的终端节点上行走 DNS 区域时生成的流量模式相匹配，则服务团队将限制您的终端节点上的流量。因此，您可能会发现 DNS 查询超时的百分比很高。
如果您观察到终端节点的容量减少并且认为终端节点受到了错误限制，请前往 h https://console.aws.amazon.com/support/ ome\$1/ 创建支持案例。
# Amazon Route 53 运行状况检查的最佳实践
有效的运行状况检查配置对于维持高可用性和弹性基础设施至关重要。以下是设置和管理 Amazon Route 53 运行状况检查时要考虑的一些最佳实践：
1. **对运行状况检查端点使用弹性 IP 地址：**
+ 对运行状况检查端点使用弹性 IP 地址以确保监控的一致性。
+ 如果不再使用 Amazon EC2 实例，请记住删除任何关联的运行状况检查，以避免潜在的安全风险或数据泄露。
有关更多信息，请参阅 [您在创建或更新运行状况检查时指定的值](health-checks-creating-values.md)。
1. **配置适当的运行状况检查间隔：**
+ 根据应用程序的要求和所监控资源的重要性设置运行状况检查的间隔。
+ 间隔越短，故障检测速度就越快，但可能会增加 Route 53 的成本和资源负荷。
+ 较长的间隔可以降低成本和资源负荷，但可能会导致故障检测产生延迟。
有关更多信息，请参阅 [高级配置（仅限“监控端点”）](health-checks-creating-values.md#health-checks-creating-values-advanced)。
1. **实现告警通知：**
+ 将 Amazon 配置 CloudWatchalarms 为在运行状况检查失败或恢复时接收通知。
+ 根据应用程序要求和资源的预期行为设置适当的告警阈值。
+ 将通知集成在监控和事件响应流程中。
有关更多信息，请参阅 [使用监控运行状况检查 CloudWatch](monitoring-health-checks.md)。
1. **策略性地利用运行状况检查区域：**
+ 根据用户和资源的地理分布选择运行状况检查区域。
+ 考虑对关键资源使用多个运行状况检查区域，以提高可靠性并降低区域中断的影响。
1. **监控运行状况检查日志和指标：**
+ 定期查看 Route 53 运行状况检查日志和 CloudWatch 指标，以确定潜在问题或性能瓶颈
+ 分析运行状况检查失败的原因，并采取适当措施来解决潜在的问题。
1. **实施失效转移和失效自动恢复策略：**
+ 利用 Route 53 的失效转移路由策略，在出现故障时自动将流量路由到运行状况良好的资源。
+ 规划并测试失效转移和失效自动恢复流程，以确保中断和恢复期间实现无缝过渡。
有关更多信息，请参阅 [配置 DNS 故障转移](dns-failover-configuring.md)。
1. **定期查看和更新运行状况检查：**
+ 根据需要更新运行状况检查端点、间隔和告警阈值，以保持最佳的监控和性能。
通过遵循这些最佳实践，就可以有效地利用 Amazon Route 53 运行状况检查来监控资源的运行状况和可用性，从而确保应用程序和服务拥有可靠和高性能的基础设施。