本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon Route 53 DNS 的最佳实践
<a name="best-practices-dns"></a>

使用 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/)。