亚马逊AWS官方博客
全新 Amazon Route 53 Global Resolver：统一、安全的全球 DNS 解析服务（预览版）
亚马逊云科技最近推出了一款填补架构空白的新产品：Amazon Route 53 Global Resolver。它的定位是“统一、安全、可全球访问的 DNS 解析端点”，这标志着 AWS 在 DNS 解析服务链路上提供了统一的全球边缘入口。您可以通过官方博客和开发者指南了解这款产品的基础功能和使用方法。
对于许多关注基础设施架构的读者而言，Global Resolver 带来的可能性是令人兴奋的。然而，不是所有场景都需要一个全球性的解析器。Global Resolver 的真正意义，在于它为特定需求提供了精准的解决方案。
因此我们撰写了这篇补充文章，旨在：
- 场景甄别：明确 Global Resolver 究竟适用于哪些场景，哪些用户能从中获得显著价值。
- 落地实践：分享在实际配置，测试，和使用过程中的一些注意事项。
接下来，我们将从两个最本质且需求迥异的场景出发，来解析 Global Resolver 的定位和价值，这份区分也将有助于您判断它是否是您当前架构的理想选择。
Global Resolver 的应用场景
面向企业网络（To Business）：混合云与全球骨干网的 DNS 架构统一
对于跨国企业或需要处理大量混合云流量的组织来说，Global Resolver 的核心价值在于帮助它们在复杂的多网络环境下构建一条稳健、安全且策略统一的 DNS 链路。
随着企业 IT 资产逐渐分散在本地数据中心、企业网络与多个 AWS 云区域之间，DNS 已成为架构中最容易产生碎片化和潜在脆弱的环节。本地网络有自身的解析规则，云上 VPC 拥有私有 Hosted zone，它们既独立又需要在某些关键点互通。同时，企业必须维持严格的内部访问控制、合规监测，以及对关键业务域名的安全策略过滤。
Global Resolver 利用 AWS 的全球 Anycast 网络，让企业用户在任意地理位置，都能以完全一致的方式访问所有 DNS 命名空间——无论是公共互联网域名，还是 AWS 上的 Public 与 Private Hosted Zones。它通过集成 Route 53 DNS Firewall 等安全服务，提供了统一的过滤和安全策略执行点。此外，由于 DNS 流量需经过公网传输，DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 协议还可以保护企业的敏感应用的 DNS 请求不会被窃听与篡改，确保最后一公里的安全。
简而言之，如果您的组织正在构建一个跨区域、多网络的混合云基础设施，并希望将 DNS 升级为一个统一、高度可管理且具有全球一致性体验的基础设施层，那么 Global Resolver 是高度契合您的需求的。
面向终端应用（To Client）：规避 DNS 污染，确保全球一致的解析体验
对于 iOS、Android 或桌面端的终端应用开发者而言，Global Resolver 的意义与企业侧完全不同。终端应用开发者无需担心企业级的策略控制或私有命名空间，他们真正关注的是：应用能否在任何国家、任何网络环境下，稳定且不受干扰地解析到准确无误的 IP 地址？
在移动互联场景中，终端用户所连接的本地 ISP 或公共网络 DNS 有可能是不可信的环境，它们可能导致解析延迟高，甚至存在 DNS 污染或劫持的风险。因此，越来越多的移动应用选择主动采用 DoH/DoT，与可信赖的安全解析端点直接通信，从而绕过本地不安全的 DNS 环境。
Global Resolver 天然具备 Anycast 能力，并支持带 Token 的访问控制，为终端应用提供了一个安全、低延迟的 DoH/DoT 目标。它不仅能确保请求和响应的加密安全，还能避免共享公共 DNS 出口带来的性能波动。当应用需要分发敏感资源、或依赖域名在全球各地都提供统一且快速的响应逻辑时，Global Resolver 提供了一个理想的解决方案，助力应用开发者实现全球用户体验的标准化和最优化。
部署与使用 Global Resolver 的注意事项
在将 Global Resolver 引入生产环境之前，您需要了解若干设计与操作层面的细节，以便在架构决策和实际操作中避免常见误区。
To Business 场景注意事项
Global Resolver 是对公网可达的 Anycast 服务：私有地址不可作为 access source
Global Resolver 的解析入口位于 AWS 的 Anycast 公网边缘节点，因此它只能看到来自客户端的“公网出口地址”。这带来两个重要的架构影响。其一，当您在 Global Resolver 上配置 access source（用以限制允许访问的客户端 IP）时，不能使用 RFC1918 私有地址段（例如 10/8、172.16/12、192.168/16）。Global Resolver 只会看到客户端的公网 IP（通常是 NAT 网关、IGW 或出口设备的地址），因此 access source 必须以这些公网地址为准。其二，对于位于 VPC 内或企业内网的实例（例如 EC2、内网主机），若要访问 Global Resolver，它们必须走公网出口：VPC 中的资源需要通过 Internet Gateway（IGW）或 NAT 出口；企业内部的客户端也需要通过 NAT/公网出口，而不能仅依赖私有 VPN、Direct Connect 或专线将 DNS 请求“直接”送到 Global Resolver。
如果您需要一个“私有解析器”并通过私有链路直接访问，应该使用 Route 53 VPC Resolver inbound endpoints 和 outbound endpoints，而不是 Global Resolver。
私有 Hosted Zone 会覆盖同名的公共解析
如果某个 Private hosted zone 被关联到 Global Resolver，则相同域名的 Public hosted zone 就不会再通过 Global Resolver 返回结果了。这个工作逻辑和 VPC Resolver 完全一样。
例如，您有一个 public hosted zone example.com，包含公网域名记录 public.example.com，也有一个 private hosted zone example.com，包含私网域名记录 private.example.com。只要 private hosted zone 被关联在 Global Resolver 上，那么所有经过 Global Resolver 的查询都只能得到 private.example.com 的结果，而不会再得到 public.example.com 的结果。
因此，在设计内部和公网 DNS 时，更稳妥的方式往往是让两者名字明确区分开，比如内部使用 example.internal、corp.example 或其它专门的内部域名，而不是和公网域名完全同名。这样可以避免意外的解析覆盖，也让 Global Resolver 的行为更加清晰、可控。
To Client 场景注意事项
仅需 Access token 鉴权
在面向终端设备或客户端应用（iOS/Android/桌面客户端）的场景中，Global Resolver 常被用作一个可信的远端解析端点，以规避本地 DNS 劫持或污染。对于这类使用者，Global Resolver 提供的 Token 机制本身就是访问控制手段：只要客户端在请求中携带有效 Token，解析请求就会被接受，因而并不需要再额外配置 access source 规则。但是，请注意 access token 的最长有效期是 365 天。
实践中的一个建议是：为 To-B（企业/混合云）与 To-C（客户端/应用）分别建立独立的 Global Resolver 实例。企业实例可启用更严格的 access source、DNS Firewall 与私有 Hosted Zone 关联；客户端实例可只依赖 Token 作为权限边界，简化配置并避免企业策略误用到面向互联网的客户端上。将两类流量分开管理能最大限度降低权限错配或策略冲突的风险。
DoH/DoT 的测试与协议细节：遵从 RFC8484 和 RFC7858 的约定
Global Resolver 遵循 RFC 8484 (DNS over HTTPS) 和 RFC 7858 (DNS over TLS)。在测试和调试时，应当按照各协议的行为规范来构造查询。
DoH (GET)
使用 cURL 进行 GET 测试时，dns= 参数必须是 DNS 查询报文的 base64url 编码（对原始 DNS wire-format 进行 base64 编码，并使用 URL-safe 字符集）。格式示例为：https://<resolver>/dns-query?token=<TOKEN>&dns=<BASE64URL>。
DoH (POST)
POST 请求的 body 必须是原始的 DNS 二进制报文，Content-Type 为 application/dns-message。
DoT 携带 Access token 的方式：通过 EDNS0 选项传递
在 DoT 的场景里，由于没有 HTTP Header 这样的元数据载体，Token 必须被封装在 DNS 报文内部。具体而言，Token 是通过 EDNS0 扩展字段传递的。EDNS0 的设计初衷即为 DNS 协议提供扩展“容器”，因此携带 Token 这类自定义鉴权信息是符合协议设计的。
客户端在构造 DNS 查询时，在 OPT RR 中插入一个自定义的 EDNS0 选项 (Option Code: 0xffa0)。该选项的 Data 字段即为 Token 的字符串数据。Global Resolver 收到查询后，它会从 EDNS0 的指定字段中取出 Token，与自身的策略进行比对。匹配则继续解析，不匹配则拒绝。
关于测试工具的说明
虽然 dig 或 kdig 等工具理论上支持通过 +ednsopt 发送自定义 Hex 数据，但需要手动将 Token 转码并构造 Payload，过程较为繁琐且容易出错；而 dog、doggo 等工具在 DoT 模式下通常尚未提供自定义 EDNS0 选项的接口。
因此，若要验证带 Token 的 DoT 解析，建议编写简单的 Python/Go 脚本进行测试。而对于常规的连通性或 ECS (EDNS Client Subnet) 验证，依然可以使用这些工具通过 DoH 协议快速完成，如下所示 (Resolver 域名，token，和 IP 地址已模糊处理)：
总结
Global Resolver 的出现为跨网络、多环境的 DNS 架构提供了一个更干净、更统一的解决方案。它让企业能够在全球范围内，以一致的安全方式暴露内部解析能力，同时也让移动端与桌面端应用在任何网络环境下都能获得可靠、不被污染的解析结果。对混合云用户来说，它补上了原本跨公网访问私有域名这一点上的空白；而对面向全球用户的应用来说，它提供了一个稳定的、可控的、安全的 DoH/DoT 入口。
最后，如果您的系统涉及到移动端或桌面端的客户端开发，那么 Access token 的管理就成了一个必须关注的部分。应用无法依赖系统级设置来调用 Global Resolver，因此 Token 需要由应用自行安全地保存与使用。无论采用 Keychain、Keystore 或等效的加密存储方式，都应确保 Token 不会以明文暴露。而且要牢记：Token 的有效期最长只有 365 天。这意味着 Token 需要被纳入您应用版本迭代的计划中，无论是通过应用更新周期自动刷新，还是通过后端下发机制滚动替换，都需要有明确的生命周期管理方案。
Global Resolver 的可用区域不包括北京和宁夏。对于在亚马逊云科技中国区域开展业务的读者，我们推荐您了解 Static BGP (S-BGP) 服务。它是专为中国区域设计的一种成本优化型数据传输服务。通过这项服务，我们致力于帮助客户在保证网络性能的同时显著降低数据传输成本。 S-BGP 可为符合条件的客户提供高达 20%～70% 的数据传输费用节省。详细的内容可以点击这里。
本篇作者
AWS 架构师中心： 云端创新的引领者探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用
|
 |
