Amazon Route 53 的 DNS 最佳实践

大多数 Web 服务依赖 DNS 将名称解析为 IP 地址，有时还需要解析其他信息。Amazon Route 53 提供高度可用且可扩展的递归 DNS 解析、域名注册和包括健康检查功能的权威 DNS 托管服务，以及广泛的路由功能。使用 Amazon Route 53，您可以利用 Amazon Web Services (AWS) 的全球影响力，以高性能和可靠的方式扩展您的 Web 服务。

自 2006 年推出我们的第一个服务 Amazon Simple Queue Service (Amazon SQS) 以来，我们已经推出了数百项服务，它们都有一个共同点：都需要使用 DNS。多年来，我们在为高度可扩展和可靠的 Web 服务管理 DNS 方面学到了许多最佳实践。以下最佳实践结合了我们在文档、博客、视频和演讲中发布的内容以及我们使用 Route 53 进行 DNS 管理运营 Web 服务的丰富经验。

DNS 查询介绍

域名系统 (DNS) 是互联网的电话簿。应用程序、浏览器和人们通过域名（如 amazon.co.uk 或 amazon.com）访问在线信息。Web 浏览器通过互联网协议 (IP) 地址进行交互，DNS 将域名翻译为 IP 地址，以便浏览器可以加载互联网资源，应用程序可以相互通信。

DNS 解析过程 是广泛的，需要涉及许多名称服务器，如 RFC 1035 中所述。为了使域名易于访问和管理，DNS 管理员会将域名结构分解为更小的名称，通常称为子域，以便于访问，请参阅下图以了解 DNS 树结构：

图 1：DNS 树结构

当浏览器或应用程序尝试连接到域名时，在后台会发生多个步骤，以允许网站或应用程序连接到服务器。在下图中，我们概述了 DNS 查询期间的步骤：

图 2：递归 DNS 解析步骤

本文将介绍管理域名基础设施的最佳实践，以帮助理解并防止因配置错误而导致的停机。

我们将讨论以下最佳实践：

1. Route 53 名称空间帐户控制
2. 托管区域管理
3. 子域和委派管理
4. TTL 管理

1) Route 53 名称空间帐户控制

管理 DNS 的第一个也是最重要的方面是管理您的名称空间（您将使用的托管区和域名的层次设计）。

Route 53 允许您使用控制台或 API 注册域名。建议在一个严格控制的 AWS 帐户中注册域名，并防止可能导致域名丢失或停机的不必要操作，例如删除域名、禁用自动续订等。您可以控制访问以进行任何此类更改（请参阅 Route 53 中的 IAM 策略控制 示例）。

2) 托管区域管理

管理托管区域的团队应具有访问控制，以防止可能导致停机的不必要操作。预防措施应包括防止删除托管区域、删除记录或 DNS 委派。如果删除托管区域，则无法恢复，您需要重新创建托管区域，这可能会导致问题，特别是对于在删除 DNS 记录时收到“无此域”（NXDOMAIN）错误的客户端。一个重要方面是递归解析器也会缓存负面答案，因此即使您快速重新创建，客户仍可能会因负面缓存而在 TTL（生存时间）期间经历不一致的结果。

虽然通常可以将所有内容分解为更小的子域名，但要谨慎不要太深入。每个委派可能需要解析器进行额外的查询并创建需要管理的额外依赖项。您必须在减少单个区域影响范围的委派与要管理和导航的区域数量之间找到适当的平衡。在 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 记录，将其别名指向 Amazon CloudFront 分发，带有长时间缓存的错误页面或 HTTP 重定向。确保您的域名顶点（example.com）上有一个记录，除了通配符 (*.example.com)，因为通配符不覆盖顶点。此外，如果您的端点支持 IPv6，请确保有 AAAA 记录，否则您的客户可能会产生额外的 NODATA 查询成本。您可以在 AWS DDoS Resiliency 白皮书中的最佳实践 中阅读更多有关防止不必要的 NXDOMAIN 和 NODATA 查询费用的信息。

3) DNS 委派管理

您应仔细考虑要创建的 DNS 委派级别。如上所述，尽量避免深层子域委派，这可能会带来不必要的维护开销。考虑定义一个可以赋予托管区域正确所有权的层次结构。如果由一个团队管理整个名称空间，最好有一个较不细化的层次结构，但是，如果有多个团队并希望他们管理自己的托管区域，那么您将需要创建委派，以便每个团队可以管理自己的托管区域。

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

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

example.com -> 顶点域 -> 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 托管区域下重新创建这些记录。请参阅图 3 的不正确设置：

图 3：不正确的委派设置

在两个托管区域中都有 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 托管区域获取 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，您可以以可扩展、可靠的方式注册、托管和解析您的域名。本文回顾了您可以使用的最佳实践，以进一步提升您在 Route 53 上的体验。回顾您现有的域名，并考虑将它们迁移到 Route 53，如果尚未这样做，请采用本文中概述的最佳实践。

本文翻译自：DNS best practices for Amazon Route 53