AWS.com 与 Google.com 的 DNSSEC 启用现状：一次技术排查引发的思考

背景

DNSSEC（Domain Name System Security Extensions，域名系统安全扩展）是 DNS 协议的一组安全扩展，旨在通过数字签名防止 DNS 欺骗和缓存投毒攻击。在理想的安全架构中，DNSSEC 能够确保用户解析到的 IP 地址确实属于目标域名，而非被中间人篡改后的恶意地址。

近期，一位技术用户在 Hacker News 上分享了一次令人惊讶的 DNS 查询经历。该用户在使用 Verisign 的公共 DNS WHOIS 检查器时，发现了一些反直觉的结果：作为全球云计算巨头的 AWS（Amazon Web Services）及其母公司 Amazon.com，竟然没有启用 DNSSEC。这一发现与公众对大型科技公司安全标准的普遍认知形成了鲜明对比，从而引发了一系列关于 DNS 安全配置的技术探讨。

核心内容

该用户在帖子中详细记录了他的排查过程。他首先使用 delv 工具（DNSSEC 验证查询工具）对几个主要域名进行了测试，以验证 DNSSEC 的启用状态。

1. Amazon.com 和 AWS.com 的状态 用户首先检查了 amazon.com，结果显示为“unsigned answer”（未签名答案），这意味着该域名的 DNS 记录没有经过数字签名：

~ ❯ delv amazon.com
; unsigned answer
amazon.com. 2 IN A 98.82.161.185
amazon.com. 2 IN A 98.87.170.71
amazon.com. 2 IN A 98.87.170.74

出于对 AWS 安全能力的信任，用户推测 AWS 的子域名 aws.com 应该启用了 DNSSEC，但测试结果同样令人失望：

~ ❯ delv aws.com
; unsigned answer
aws.com. 59 IN A 143.204.142.107
aws.com. 59 IN A 143.204.142.125
aws.com. 59 IN A 143.204.142.53
aws.com. 59 IN A 143.204.142.119

2. 排除工具故障 为了确认是否是自己使用的客户端或工具存在问题，用户转而测试了 Google 和 Cloudflare 的域名。

• Google.com：尽管用户预期 Google 作为安全标杆会启用 DNSSEC，但测试结果显示 google.com 同样返回了“unsigned answer”：

  ~ ❯ delv google.com
  ; unsigned answer
  google.com. 141 IN A 173.194.42.101
  ... (其他 IP 地址)
  

• Cloudflare.com：作为对比，Cloudflare 的测试结果则完全不同，显示为“fully validated”（完全验证通过），并包含了 RRSIG（资源记录签名）记录：

  ~ ❯ delv cloudflare.com
  ; fully validated
  cloudflare.com. 134 IN A 104.16.132.229
  cloudflare.com. 134 IN A 104.16.133.229
  cloudflare.com. 134 IN RRSIG A 13 2 300 20260612003424 20260609223424 34505 cloudflare.com. ...
  

3. 结论与疑问 由于 Cloudflare 的域名能够正确通过 DNSSEC 验证，用户确认其本地工具和客户端配置无误。因此，问题的核心在于 Amazon.com、AWS.com 以及 Google.com 这些顶级域名提供商或所有者，为何在其核心域名上未启用 DNSSEC。

用户引用了 AWS 官方关于此主题的一篇文章，并指出了缺乏 DNSSEC 的风险：在没有 DNSSEC 的情况下，无法通过密码学手段证明 DNS 记录的准确性。这意味着 DNS 服务器的缓存可能会返回攻击者伪造的 IP 地址，从而导致用户被重定向到恶意网站。

关键要点

• 事实核查结果：通过 delv 工具验证，Amazon.com、aws.com 和 google.com 当前均未启用 DNSSEC（返回 unsigned answer）。
• 对比案例：Cloudflare.com 成功启用了 DNSSEC，并返回了完整的 RRSIG 签名记录，证明测试环境和方法是正确的。
• 安全原理：DNSSEC 的核心作用是提供密码学证明，确保 DNS 响应数据的完整性和真实性，防止 DNS 缓存投毒（Cache Poisoning）和中间人攻击。
• 潜在风险：未启用 DNSSEC 的域名，其 DNS 解析过程缺乏完整性校验，存在被攻击者篡改解析结果的风险，可能导致用户访问到假冒的服务器。
• 行业现状：即使是 AWS 和 Google 这样以安全著称的科技巨头，在其主域名上也可能存在未启用 DNSSEC 的情况，这反映了大规模基础设施在安全配置上的复杂性或权衡。

意义与影响

这一发现虽然看似是一个技术细节，但它揭示了互联网基础设施安全中的一个重要现实：知名不等于绝对安全，默认配置不等于最佳实践。

1. 对大型科技公司的警示：AWS 和 Google 作为全球互联网的基础设施提供商，其域名安全性具有风向标意义。如果连它们的核心域名都未启用 DNSSEC，可能意味着在大规模分布式系统中，DNSSEC 的部署面临着技术复杂性、成本或向后兼容性的挑战。这也提醒用户，不能仅凭品牌知名度来假设其所有服务都具备最高级别的安全配置。

2. DNSSEC 部署的复杂性：DNSSEC 的启用并非简单的开关操作，它涉及密钥管理、签名轮换、DNS 记录更新以及递归解析器的支持等多个环节。对于拥有海量子域名和复杂网络架构的公司来说，全面启用 DNSSEC 是一项巨大的工程。Google 和 AWS 可能采取了其他补偿性安全措施（如 HTTP Strict Transport Security, 证书透明度等）来弥补 DNSSEC 的缺失，但这并不改变 DNS 层本身缺乏密码学保护的事实。

3. 用户安全意识的重要性：对于普通用户而言，这一事件提醒我们，在使用互联网服务时，应意识到 DNS 层潜在的安全风险。虽然现代浏览器和操作系统引入了额外的安全机制（如 HSTS 预加载列表），但了解 DNSSEC 的作用有助于我们更全面地理解网络安全架构。

4. 推动行业进步：此类公开的讨论和验证有助于提高行业对 DNSSEC 部署的关注度。随着越来越多的安全专家指出这一缺口，可能会促使 AWS、Google 等公司重新评估其 DNS 安全策略，加速 DNSSEC 的全面普及，从而提升整个互联网的基础设施安全性。

总之，这次排查不仅是一次技术验证，更是一次对互联网安全现状的深刻反思。它表明，即使在最顶级的科技巨头中，安全配置的完善程度也可能存在差异，持续的安全审计和最佳实践的推广至关重要。