Amazon Route 53 的 DNS 最佳实践

关键要点

• 高可用性与可扩展性 ：Amazon Route 53 提供可靠的 DNS 解析服务和域名注册，确保高效的网络服务。
• DNS 查询过程 ：深刻理解 DNS 查询的工作机制有助于避免网络故障。
• 命名空间管理 ：正确管理域名空间，以防止意外的域名丢失或中断。
• 托管区管理和委派 ：分层管理 DNS 委派，确保有效控制和一致性。
• 时间到期管理（TTL） ：合理选择 TTL 值，有助于提高性能并优化查询成本。

大多数网络服务依赖于 DNS 将名称解析为 IP 地址及其他信息。 提供高可用且可扩展的递归 DNS解析、，以及具有健康检查功能和各种路由能力的权威 DNS 托管区。使用 Amazon Route53，您可以以高效和可靠的方式扩展网络服务，利用 Amazon Web Services（AWS）的全球基础设施。

自2006年推出首个服务 Amazon Simple Queue Service (SQS) 以来，我们已经推出了数百种服务，而它们的共同点在于都需要使用 DNS。多年来，我们在管理高可扩展性和高可靠性网络服务的 DNS方面积累了许多最佳实践。这些最佳实践结合了我们在文档、博客、视频和演示中发布的内容，以及我们使用 Route 53 进行 DNS 管理的大量经验。

DNS 查询的日常

域名系统（DNS）是互联网的“电话簿”。应用程序、浏览器和用户通过域名（如 amazon.co.uk 或 amazon.com）在线访问信息。Web浏览器通过互联网协议（IP）地址进行交互，而 DNS 则将域名转换为 IP 地址，使浏览器能够加载互联网资源并使应用程序彼此通信。

较为复杂，涉及多个名称服务器，如 RFC 1035所描述。为了使域名易于访问和管理，DNS 管理员通常将域名结构划分为多个较小的名称，称为子域。以下图示展示了 DNS 树状结构：


当一个浏览器或应用程序尝试连接到一个域名时，背后会发生多个步骤，使网站或应用能够连接到服务器。下面的图示概述了 DNS 查询过程中所经历的步骤：

![递归 DNS删除)

本博客文章将介绍管理域名基础设施时的最佳实践，以帮助理解并避免由错误配置引起的中断。

我们将讨论以下最佳实践： 1. Route 53 命名空间账户控制 2. 托管区管理 3. 子域及委派管理 4. TTL 管理

1. Route 53 命名空间账户控制

管理 DNS 的首要方面是管理您的命名空间（即您将使用的区域和名称的层次结构）。

Route 53 允许您通过 注册域名。建议在一个受控的 AWS账户中注册域名，以防止意外操作导致域名丢失或中断，例如删除域名或禁用自动续订等。在进行任何更改时，您可以控制访问权限（请参阅 作为示例）。

2. 托管区管理

管理托管区的团队应该施加访问控制，以防止可能导致服务中断的意外操作。这些预防措施应包括避免删除托管区、记录或 DNS委派的操作。如果删除了承载区，它是无法恢复的，您需要重新创建托管区，并且这会导致客户遇到“没有此类域名”（NXDOMAIN）错误。一项重要的注意事项是，负面结果也会被递归解析器缓存，因此即使您快速重新创建，客户可能仍会因过长的缓存时间而经历不一致的结果。

虽然将一切分解为更小的子区通常较为简单，但请注意不要进行过于深入的划分。每次委派都可能需要解析器进行额外查询，从而增加管理的复杂性。在委派的同时，您必须在减少单一区域影响范围和管理过多区域之间找到平衡。在 AWS，我们选择按区域和服务进行委派。例如，ec2.eu-west-1.amazonaws.com 中的 amazonaws.com 是一个区域，委派给 eu-west-1.amazonaws.com，再委派给 ec2.eu- west-1.amazonaws.com，但您的情况可能有所不同。对于区域的委派，您还应考虑使用单独的 AWS账户，以进一步减小潜在影响的范围，但也要权衡这一分隔所带来的额外运营成本。

如果您在提供基于“软件即服务”（SaaS）类型服务，为每个客户的端点创建不同的 DNS 名称（例如，Your-service- xyz123.myservice.eu- west-1.example.com）也是值得考虑的。在这个示例中，我们在服务名称末尾添加了一个随机字符集（xyz123），这有助于防止在请求服务实例时的命名空间重叠。

为每个服务/组件创建名称使您能够在不需要客户端操作的情况下灵活迁移单个消费者到不同的端点，这对在不同分片策略中的负载平衡非常重要。请注意，根据需要在区域之间迁移或在区域之间进行负载均衡，将区域名称加入外部 DNS 名称可能并不适合您的业务，因此请权衡风险与收益。

域名更容易被爬虫访问，并且对不存在的记录查询也比较敏感。为了降低成本并改善用户界面的体验，您可以考虑为您的区域创建一个通配符 DNS 记录，该记录别名指向 的分发，配备长期缓存的错误页面或 HTTP重定向。请确保在您的域名顶点（example.com）处有一个记录，并与通配符 (*.example.com) 一并存在，因为通配符不涵盖顶点。此外，如果您的端点支持 IPv6，请确保有 AAAA 记录，否则客户可能会导致额外的 NODATA 查询费用。您可以在 中了解更多关于防止不必要的 NXDOMAIN 和 NODATA 查询费用的信息。

3. DNS 委派管理

您应该仔细考虑要创建的 DNS委派级别。如上所述，尽量避免深层子域委派，这会增加维护的开销。考虑定义一个层次结构，将托管区的权威性赋予正确的所有者。如果只有一个团队管理整个命名空间，最好保持较少的粒度层次；但如果有多个团队并希望他们管理自己的托管区域，则需要创建委派，使每个团队能够管理自己的托管区域。

一个常见的错误是试图通过创建子域而未遵循结构扩展域名结构。不正确的域名结构可能导致 DNS 响应不一致，从而导致应用程序中断。

假设您创建了两个公共托管区，分别是父域和子域：

example.com -> ApexDomain -> NS 委派给 sub.example.com sub.example.com -> 公共托管区域

接着，您在 example.com 托管区中创建一个 NS 记录，以委派 sub.example.com 的记录责任给 sub.example.com托管区。

如果您在 example.com（顶点域托管区）中存在 sub.example.com 的记录，来自权威名称服务器的 DNS 响应可能会不一致，您需要在 sub.example.com 托管区下重新创建这些记录。以下是错误设置的示意图：


将 sub.example.com 记录放在两个托管区中会造成模糊性。当 DNS 解析器解析如 api.sub.example.com的记录时，解析器会根据其缓存的 NS（名称服务器）记录的状态，直接查询 sub.example.com 名称服务器或查询 example.com名称服务器：

• 如果解析器查询 example.com 名称服务器获取 api.sub.example.com 的记录，且该名称服务器在 example.com 区域存在对应答案，则返回该答案；若不存在则返回 sub.example.com 的 NS 记录。
• 如果解析器查询 sub.example.com 名称服务器，这些名称服务器会返回 sub.example.com 区域的答案，或者如果没有该记录，则返回负面响应（NXDOMAIN 或无答案），或者甚至返回与预期不同的响应，如上图所示。

为确保一致性，请在 sub.example.com 区域中创建所有 sub.example.com 记录，并在 example.com 托管区中创建 NS记录，将责任委派给 sub.example.com 托管区，然后从 example.com 区域删除所有 sub.example.com记录。这样可以确保解析器始终从 sub.example.com 托管区获取答案，并始终解决 DNS 查询的含糊性。

4. TTL 管理

DNS 使用缓存来提高性能并减少递归树上每个部分的负载。为了使 DNS管理员能够管理该缓存，每条记录都有一个时间到期值（TTL）以及在权威启动（SOA）记录中指定的 TTL，用于负面答案（如 NXDOMAIN等）的缓存。并非所有解析器或客户端都可能遵循 TTL，大多数会遵循，因此选择适合您工作负载的 TTL 值非常重要。我们建议将负缓存TTL设置为 900秒，这是在 Route 53 中创建托管区时的默认值。

为单独记录选择 TTL 是一个权衡决策，涉及多个因素。首要考虑因素是您更改的频率。对于 NS 记录，这些记录不经常更改，因此您可以保持较长的 TTL，例如默认的 172,800 秒（2 天），以减少来自客户端的查询成本并提高性能。其他指向生产端点的记录，您可能希望保持在 60 秒到 300 秒（5分钟）之间。TTL越低，您可以将客户端快速重定向到不同的端点。但这会导致解析器生成更多查询，从而可能导致客户端访问应用程序的延迟增加。值得注意的是，客户端通常仅在初始化会话时执行 DNS 请求。因此，如果您有一个长期存在的 TCP 会话处于活动状态或具有扩展的超时期，即使您更新了 DNS 记录、故障转移或加权处理并且 TTL已过期，您可能也不会看到该客户端迁移到不同的端点。

结论

借助 Amazon Route 53，您可以以可扩展和可靠的方式注册、托管和解析您的域名。本文回顾了您可以使用的最佳实践，从而进一步提高您在 Route53 上的体验。请审查您现有的域名，如还未迁移至 Route 53，请考虑进行迁移，并采纳这里描述的最佳实践。

作者介绍

Scott Morrison

 Scott 是 AWS 的高级解决方案架构师，专注于网络领域，帮助客户设计坚韧且经济高效的网络架构。业余时间，Scott喜欢编程以解决独特问题。闲暇时，他常常在拉斯维加斯外的沙漠中越野或偶尔参加扑克比赛。

Renato Gentil

 Renato 是位于爱尔兰的高级技术客户经理，精通 Route 53。他拥有 AWS 网络专职认证，并与全球不同客户在大规模 Route 53 和可恢复性场景中工作。在业余时间，Renato 喜欢与孩子们玩 Uno、观看电影或弹奏贝斯吉他。