返回
Hacknews-Daily

DNS 解析的哲学之问：CNAME 与 A 记录，谁先谁后？

本文深入探讨了 DNS 解析中一个看似简单却至关重要的核心问题：在解析一个可能包含 CNAME 记录的域名时，解析器应该先查询 CNAME 还是 A 记录？文章基于 Cloudflare 的实践与 RFC 标准，揭示了这一决策背后的技术权衡、历史演进以及对现代网络性能与安全性的深远影响。

文章摘要

本文围绕 DNS 解析过程中的一个基础但关键的设计决策展开：当解析器面对一个域名时，它应该优先尝试查找 CNAME 记录，还是 A/AAAA 记录？这个问题触及了 DNS 协议的核心效率与鲁棒性。Cloudflare 的工程师通过深入分析历史 RFC 文档、不同解析器的实现差异以及实际性能影响，揭示了“先 CNAME”策略的优越性。这种策略不仅能减少不必要的查询次数、提升解析速度，还能更好地处理复杂的别名链和 DNSSEC 签名验证场景。理解这一顺序背后的逻辑，对于构建高性能、高可用的网络服务至关重要。

背景与问题

域名系统（DNS）是互联网的“电话簿”，它将人类可读的域名（如 blog.cloudflare.com）转换为机器可读的 IP 地址。在这个转换过程中，CNAME（规范名称）记录和 A（地址）记录 是两种最核心的资源记录类型。A 记录直接存储 IP 地址，而 CNAME 记录则充当一个别名，指向另一个域名（即规范名称），解析器需要继续查询这个规范名称以最终获得 IP 地址。

这就引出了一个看似简单却深藏玄机的问题：当一个解析器（如递归解析器或存根解析器）收到一个需要解析的域名时，它应该先尝试获取该域名的 CNAME 记录，还是先尝试获取 A（或 AAAA）记录？

在理想的无损网络中，顺序或许无关紧要。但在现实世界中，网络存在延迟、丢包和中间件干扰。错误的查询顺序可能导致额外的、不必要的网络往返（RTT），从而显著增加域名解析的延迟。对于追求极致性能的现代 Web 应用和全球分布式服务（如 Cloudflare）而言，每一次不必要的 RTT 都意味着用户体验的下降和潜在的业务损失。

这个问题的重要性远超表面。它关系到：

  1. 解析性能：高效的查询顺序是降低 DNS 解析延迟的关键。
  2. 协议健壮性：正确的顺序有助于处理边缘情况，如 CNAME 链（CNAME 指向另一个 CNAME）或与 DNSSEC 的交互。
  3. 标准符合性：不同的 RFC 文档在不同时期有过不同的建议，理解其演进有助于实现更健壮的解析器。
  4. 基础设施优化：对于像 Cloudflare 这样运营着全球最大公共 DNS 服务（1.1.1.1）的公司，在协议层面的细微优化能带来巨大的规模效益。

Cloudflare 的文章正是从自身优化递归解析器（cloudflared 代理）和权威服务器的实践中出发，深入挖掘了这一技术细节，并给出了基于标准和实践的最佳答案。

核心内容解析

3.1 核心观点提取

  • 观点一：历史 RFC 标准存在模糊与演变 早期的 RFC（如 1034, 2308）并未严格规定查询顺序，导致不同解析器实现各异。RFC 8020（2016）最终明确了“先 CNAME”的推荐做法，以消除因顺序不当导致的额外延迟和NXDOMAIN缓存问题。

  • 观点二：“先 CNAME”策略能最小化查询次数 如果域名存在 CNAME，先查 CNAME 能直接进入别名解析流程。如果先查 A 记录且不存在，解析器会收到一个包含 CNAME 的否定响应（NODATA），但根据传统行为，它可能仍需要重新发起一次 CNAME 查询，造成浪费。

  • 观点三：否定缓存（NXDOMAIN）机制受查询顺序影响 如果先查询 A 记录，而该记录不存在，权威服务器可能返回包含 CNAME 的响应（根据 RFC 2308）。但一些旧的解析器或配置可能错误地将此情况缓存为“A记录不存在”，影响后续解析。先查 CNAME 可以避免这种混淆。

  • 观点四：DNSSEC 验证与查询顺序紧密相关 在 DNSSEC 环境下，为证明一个名称不存在（如无 A 记录），需要提供 NSEC/NSEC3 证明。如果该名称存在 CNAME，则不应返回“不存在”证明，而应返回 CNAME 记录及其签名。先查 CNAME 能更自然地适配 DNSSEC 的语义。

  • 观点五：实践是检验标准的最终标准 Cloudflare 通过测试发现，尽管标准推荐“先 CNAME”，但现实中（如某些存根解析器或库）仍存在“先 A 记录”的行为。这提醒开发者在与不同系统交互时需注意兼容性，并推动更一致的标准实施。

3.2 技术深度分析

要理解查询顺序的优劣，需要深入 DNS 协议交互的细节。我们通过一个例子来剖析两种策略。

假设我们要解析域名 alias.example.com，其 DNS 记录设置为：

alias.example.com.    IN    CNAME   target.example.com.
target.example.com.   IN    A       192.0.2.1

场景一：解析器采用“先 A 记录”策略

  1. 解析器向权威服务器发送查询：QNAME=alias.example.com, QTYPE=A
  2. 权威服务器检查：alias.example.com 没有 A 记录，但有一个 CNAME 记录。
  3. 根据 RFC 1034 和 RFC 2308，当查询的类型记录不存在，但存在 CNAME 时，权威服务器应在应答的“Answer”部分返回这个 CNAME 记录，并将应答码（RCODE）设为 0（成功），但“Answer”部分不包含请求的 A 记录。这被称为 NODATA 响应（有名称，无此类型数据）。
  4. 解析器收到响应，看到 CNAME 记录。此时，一个“聪明”的解析器可以立即使用这个 CNAME 值（target.example.com）发起新一轮 A 记录查询。 然而，问题在于：
    • RFC 兼容性问题：一些旧的解析器或严格遵循早期逻辑的库，可能会认为这个对 A 记录的查询“失败”了，需要以原始名称（alias.example.com）重新发起一个 QTYPE=CNAME 的查询来“正式”获取 CNAME。这就产生了一次完全多余的查询。
    • 否定缓存：如果解析器或中间缓存错误地将这个 NODATA 响应解释为“alias.example.com 的 A 记录不存在”并缓存下来，短期内对 alias.example.com 的 A 记录查询都可能直接返回空，直到缓存过期。

场景二：解析器采用“先 CNAME”策略

  1. 解析器向权威服务器发送查询：QNAME=alias.example.com, QTYPE=CNAME
  2. 权威服务器检查并直接返回 CNAME 记录。
  3. 解析器立即获得规范名称 target.example.com，然后对其发起 A 记录查询。
  4. 最终获得 IP 地址 192.0.2.1。

对比分析：

  • 查询次数：“先 CNAME”策略在成功路径上是最优的，总是以最少的必要查询完成解析。“先 A 记录”策略在最佳实现下可能等价，但在许多现实实现中会多一次查询。
  • 逻辑清晰性：“先 CNAME”策略的解析流程更线性、更符合直觉：先确定这个名字是不是别名，如果是，就解析别名；如果不是，再找它的地址记录。
  • 与 DNSSEC 的协同：DNSSEC 的核心是为存在的记录提供签名（RRSIG），并为不存在的记录/类型提供不存在的证明（NSEC/NSEC3）。对于存在 CNAME 的名称，其“A 记录不存在”的状态是特殊的（因为有 CNAME 存在）。先查询 CNAME，可以直接获得签名的 CNAME 记录，避免了处理针对不存在的 A 记录的、复杂的 NSEC 证明，简化了验证逻辑。

Cloudflare 文章中提到，他们通过修改 cloudflared 代理（作为存根解析器）的逻辑，将其从“先 A 记录”改为“先 CNAME”，从而减少了与上游递归解析器（如 1.1.1.1）之间不必要的通信，提升了边缘网络的解析性能。

3.3 实践应用场景

这一知识在以下场景中具有直接的应用价值：

  1. 递归解析器与公共 DNS 服务开发与优化： 如果你正在构建或维护一个递归 DNS 解析器（如自建内部 DNS 或公共 DNS 服务），确保采用“先 CNAME”的查询策略是优化性能、减少上游查询负载的关键一步。这能直接降低平均解析延迟。

  2. 客户端库与存根解析器实现： 在应用程序中集成 DNS 解析功能时（使用如 getaddrinfo 或各类语言的 DNS 库），了解底层库的查询顺序行为很重要。对于性能敏感的应用（如高频服务发现、CDN 动态调度），可以考虑实现或选择更智能的、遵循“先 CNAME”策略的 DNS 客户端。

  3. 调试复杂的 DNS 问题： 当遇到诡异的“域名解析时好时坏”、“偶尔找不到 A 记录”等问题时，排查思路中可以加入对查询顺序的考虑。特别是当环境中存在混合的、新旧不同的解析器时，顺序不一致可能导致间歇性故障。使用 dig +trace 或检查解析器日志，观察实际的查询序列。

  4. 设计高可用与全球负载均衡架构： 在利用 CNAME 指向云服务商（如 AWS CloudFront, Google Cloud Load Balancing）或 CDN 的域名时，理解解析顺序有助于预估端到端解析延迟，并设计更有效的故障转移和多活策略。例如，知道解析器会高效地追踪 CNAME 链，可以更放心地使用多层别名来实现灵活的流量管理。

最佳实践建议：在设计和配置 DNS 基础设施时，应默认遵循 RFC 8020 的指导，即优先查询 CNAME 记录。同时，在权威 DNS 服务器上，确保正确配置了 CNAME 记录，并避免将其与其他记录类型（如 MX、SOA、NS 等）置于同一名称下（这违反了 RFC 标准），以防止解析器出现未定义行为。

深度分析与思考

4.1 文章价值与意义

Cloudflare 这篇文章的价值在于，它将聚光灯投向了一个被广泛使用却极少被深入讨论的协议底层细节。DNS 作为互联网基石，其稳定性和性能被视为理所当然。然而，正是对这些“理所当然”的细节进行持续审视和优化，才推动了整个互联网基础设施的不断进化。

  • 对技术社区的价值：它完成了一次出色的“考古”与“布道”。通过梳理从 RFC 1034 到 RFC 8020 近三十年的标准演进，文章为社区提供了清晰的技术历史脉络。它不仅仅给出了“应该怎么做”的结论，更解释了“为什么应该这样做”以及“历史上为什么不是这样”，这种深度对于教育开发者和网络工程师至关重要。
  • 对行业的影响：Cloudflare 作为全球领先的网络服务提供商，其技术实践具有风向标意义。公开分享此类优化细节，能够推动其他 DNS 软件实现者、云服务商和大型企业检查并优化自己的系统，从而在整体上提升互联网的解析效率和健壮性。这符合其“帮助构建更好的互联网”的使命。
  • 创新点与亮点：文章的亮点在于其问题驱动的分析方式。从一个具体的性能优化点出发，延伸到协议标准、历史兼容性、安全特性（DNSSEC）等多个维度，展示了优秀工程师的系统性思维。它证明了，即使在最成熟的基础协议中，依然存在通过深度理解来获取性能增益的空间。

4.2 对读者的实际应用价值

对于不同角色的读者，本文提供了多层次的价值：

  • 对于运维工程师/SRE：你将更深刻地理解 DNS 解析延迟的构成。当下次进行性能调优或故障排查时，你不仅会看缓存命中率，还会思考解析器逻辑、查询顺序是否是最优的。你可以用 dig 命令的 +short +trace 选项，实际观察不同场景下的查询路径，验证理论。
  • 对于软件开发工程师：在开发微服务、实现服务发现或任何依赖域名解析的分布式系统时，你会意识到 DNS 解析并非一个简单的“黑盒”调用。选择正确的客户端 DNS 库、合理设置超时与重试、理解解析器行为，对于构建弹性和高性能的应用至关重要。
  • 对于网络协议爱好者或学生：本文是一个绝佳的案例研究，展示了互联网标准是如何在实践中通过解决具体问题而逐步演进的。它教你如何阅读 RFC，如何权衡兼容性与先进性，以及如何将协议文本转化为高效的代码实现。

4.3 可能的实践场景

  1. 项目应用：
    • 自建智能 DNS 解析器：如果你在开发类似 Pi-hole、AdGuard Home 的本地 DNS 工具，或者为内部网络定制解析策略，务必在核心解析循环中实现“先 CNAME”逻辑。
    • 云原生环境下的 DNS 优化：在 Kubernetes 集群中，CoreDNS 是默认的 DNS 服务器。可以审查其插件链和配置，确保其向上游查询时行为最优。同时，应用程序的 sidecar 代理或服务网格（如 Istio）中的 DNS 代理组件，也应遵循此最佳实践。
  2. 学习路径：
    • 入门：理解 DNS 基础记录类型（A, AAAA, CNAME, MX, TXT 等）和基本解析过程。
    • 进阶：深入研究 RFC 1034, RFC 2308, RFC 8020 等关键文档，理解缓存、否定缓存、DNSSEC 原理。
    • 实践：使用 Wireshark 或 tcpdump 抓取 DNS 报文，分析真实软件（如操作系统解析器、公共 DNS）的查询序列，与理论对照。
  3. 工具推荐：
    • 诊断工具：dig (附带 +trace, +norecurse, +bufsize=4096 等参数), drill, kdig。
    • 协议分析：Wireshark (DNS 过滤器)， dnscap。
    • 权威服务器：BIND 9, PowerDNS, Knot DNS。
    • 递归解析器：Unbound, BIND (递归模式), Cloudflare 1.1.1.1。

4.4 个人观点与思考

Cloudflare 的文章清晰地论证了“先 CNAME”的合理性。但我想补充一点关于**协议演进与“现实重力”**的思考。

理论上完美的标准，在落地时总会遇到历史包袱。文章中提到的“某些存根解析器仍然先查询 A 记录”就是例证。这背后可能是为了兼容那些不符合 RFC 2308 的古老权威服务器（可能只返回 NXDOMAIN 而不返回 CNAME），也可能是某些代码库多年未更新的惯性。

这给我们两个启示：

  1. 渐进式优化：像 Cloudflare 这样，在自己的可控环节（cloudflared 与自己的权威服务器之间）率先实施优化，是务实的选择。他们不需要等待全世界所有的存根解析器都改变，就能在自己的网络内收获性能红利。
  2. 标准推广的长期性：RFC 8020 发布于 2016 年，但观念的普及和实现的统一仍需时日。这需要像 Cloudflare、Google、ISC（BIND 维护者）等关键组织持续发声、分享数据，并最终将最佳实践固化到主流操作系统和开发库的默认行为中。

此外，随着 DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 的普及，查询的传输层发生了变化，但应用层协议的逻辑并未改变。在加密 DNS 时代，减少不必要的查询轮次对于降低连接建立开销和总体延迟同样重要，甚至更为关键，因为每次加密查询的握手成本更高。

技术栈/工具清单

本文讨论的核心技术围绕 DNS 协议栈及其实现：

  • 核心协议：
    • DNS (Domain Name System) - RFC 1034, 1035
    • DNS 否定缓存 - RFC 2308
    • 处理 CNAME 的权威服务器需求 - RFC 8020
    • DNSSEC - RFC 4033, 4034, 4035 及相关
  • 关键工具与软件：
    • 诊断工具：dig (来自 BIND bind-utils), kdig (来自 Knot DNS), drill (来自 ldns), nslookup, host。
    • 网络分析：Wireshark, tcpdump。
    • 递归解析器实现：Unbound, BIND 9 (作为递归器), PowerDNS Recursor。
    • 权威服务器实现：BIND 9, PowerDNS Authoritative, Knot DNS, NSD。
    • 公共 DNS 服务：Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9。
  • 学习资源：
    • RFC 阅读：所有关键 RFC 可在 IETF Datatracker 获取。
    • 书籍：《DNS and BIND》（Cricket Liu 著）是经典入门与参考书。
    • 在线互动：通过 DNSViz 可视化分析域名和 DNSSEC 链。

相关资源与延伸阅读

  • 原文链接（必须阅读）：What came first: the CNAME or the A record? - Cloudflare 博客原文，包含更详细的测试方法和数据。
  • 关键 RFC 文档：
    • [RFC 1034: Domain Names - Concepts and Facilities