DNS附加部分是什么，它如何优化网络解析速度？

在浩瀚的数字世界中,域名系统（DNS）如同互联网的地址簿，负责将我们易于记忆的网站名称（如 www.example.com）翻译成机器能够理解的 IP 地址，DNS 的运作远比简单的“一问一答”要精妙和高效，其响应报文的设计堪称一门艺术，一个常被忽略却至关重要的部分——附加部分，正是这门艺术的点睛之笔，它就像是地址簿上附带的贴心备注，极大地提升了网络通信的效率。

为了理解附加部分的价值,我们首先需要了解 DNS 响应报文的基本构成，一个标准的 DNS 响应报文通常包含四个核心区域，它们共同协作，传递完整的信息。

DNS 报文的基本结构

我们可以将一个 DNS 响应报文想象成一封结构严谨的信件，信件被分成了四个段落，每个段落都有其特定的功能。

附加部分的核心设计理念是“预测”和“优化”，它预判客户端在获得主要答案后，可能需要立即进行下一次查询，并提前将下一次查询的结果一并返回，这种“未卜先知”的能力，正是其价值所在。

附加部分的核心价值：优化与效率

在互联网通信中,每一次查询都意味着一次网络往返，这会产生一定的延迟，对于用户而言，延迟就是等待的时间，附加部分最直接的好处，就是通过减少网络往返次数来显著降低延迟。

让我们通过一个经典的场景来理解这一点：查询邮件交换（MX）记录。

假设你的邮件服务器需要向 example.com 域发送一封邮件，它首先需要知道负责接收该域邮件的服务器是什么。

1. 没有附加部分的情况：

   

   • 第一次查询：邮件服务器向 DNS 解析器查询 example.com 的 MX 记录。
   • 第一次响应：解析器返回 MX 记录，mail.example.com。
   • 第二次查询：邮件服务器只知道邮件服务器的名称是 mail.example.com，但不知道它的 IP 地址，它必须发起第二次查询，请求 mail.example.com 的 A 记录。
   • 第二次响应：解析器返回 mail.example.com 的 IP 地址，0.2.53。
   • 结果：整个过程需要两次完整的 DNS 查询，增加了延迟。

2. 有附加部分的情况：

   • 第一次查询：邮件服务器向 DNS 解析器查询 example.com 的 MX 记录。
   • 第一次响应：解析器在回答区返回 MX 记录 mail.example.com，它在附加部分中，智能地附上了 mail.example.com 的 A 记录（IP 地址 192.0.2.53）。
   • 结果：邮件服务器在一次查询中就获得了所有必需的信息，无需再进行第二次查询，通信效率大大提高。

典型应用场景

附加部分的应用远不止于 MX 记录查询，它在多个关键场景中扮演着重要角色。

• NS 记录与胶水记录：当查询一个域的权威名称服务器（NS 记录）时，如果这些 NS 记录本身就在该域的子域下（example.com 的 NS 记录是 ns1.example.com），就会产生一个“鸡生蛋，蛋生鸡”的问题：要找到 ns1.example.com 的 IP，需要先查询 example.com 的 NS 服务器，为了解决这个循环依赖，DNS 引入了“胶水记录”，当父域服务器返回子域的 NS 记录时，会在附加部分中提供这些 NS 服务器的 IP 地址，就像胶水一样将名称和地址粘合在一起，使得客户端能够直接找到这些服务器。

• EDNS0 扩展：随着互联网的发展，原始的 DNS 协议逐渐显得力不从心，扩展机制（EDNS0）通过在附加部分中添加新的选项，极大地增强了 DNS 的功能，EDNS0 可以用来协商更大的 UDP 报文大小（突破传统 512 字节的限制），支持 DNSSEC 安全扩展，以及实现 DNS Cookie 等安全特性，可以说，附加部分是承载 DNS 现代化演进的重要载体。

并非完美：附加部分的潜在问题

尽管附加部分带来了巨大的性能优势,但它也并非完美无瑕，最主要的问题是 UDP 数据包截断。

DNS 查询默认使用 UDP 协议，因为它开销小、速度快，但 UDP 报文有大小限制（传统上为 512 字节，EDNS0 可协商更大），DNS 响应报文（包括回答区、权威区和附加部分的总和）超过了这个限制，服务器就无法通过 UDP 完整地返回，服务器会在响应报文的头部设置一个“TC”标志位，告知客户端：“信息太长，请改用 TCP 协议重新查询。”

TCP 协议虽然可靠，但建立连接的过程比 UDP 更耗时，如果附加部分中的信息过多，反而可能导致响应被截断，迫使客户端进行一次更耗时的 TCP 查询，这与附加部分设计的初衷背道而驰，DNS 服务器管理员需要仔细配置，确保附加部分提供的信息既足够有用，又不至于导致数据包过大。

DNS 附加部分是 DNS 协议设计中一个极具智慧的优化，它通过提供“额外”信息，有效减少了网络延迟，提升了用户体验，从简单的 MX 记录查询到复杂的 EDNS0 扩展，附加部分始终在幕后默默地为互联网的高效运行贡献力量，理解它的工作原理，不仅能让我们更深入地洞察 DNS 的运作机制，也能帮助我们更好地诊断和解决网络中遇到的性能问题。

相关问答 (FAQs)

问题 1：附加部分中的信息总是可靠的吗？

解答：附加部分中的信息，当它由权威域名服务器直接提供时，通常是可靠的，权威服务器返回的 MX 记录对应的 A 记录（在附加部分中），和它在回答区中返回的任何记录一样具有权威性，信息在经过中间的递归或缓存 DNS 服务器时，可能会被修改或丢弃，为了确保数据的完整性和真实性，现代 DNS 广泛采用 DNSSEC（域名系统安全扩展），DNSSEC 通过数字签名来验证 DNS 记录（包括那些可能出现在附加部分中的记录）是否被篡改，在一个部署了 DNSSEC 的环境中，即使信息来自附加部分，其真实性也是可以被验证的，但在没有 DNSSEC 的情况下，我们仍然需要信任提供信息的 DNS 服务器。

问题 2：为什么有时候我使用 dig 或 nslookup 工具查询时，看不到附加部分的信息？

解答：这背后可能有几个原因：

1. 服务器未提供：你查询的 DNS 服务器可能没有被配置为提供附加信息，或者它判断提供这些信息不必要或不合适。
2. 响应被截断：如文中所述，如果响应报文过大，超过了 UDP 的大小限制，服务器会设置 TC 标志，并且通常不会返回附加部分，而是要求客户端通过 TCP 重试，你可以使用 dig 命令查看响应头中的 tc 标志位是否为 tc。
3. 中间缓存服务器：你与权威服务器之间的递归解析器或缓存服务器可能会出于节省带宽、保护隐私或简化响应等原因，选择剥离掉附加部分的信息，然后再将响应返回给你。
4. 查询类型：并非所有类型的查询都能触发有用的附加信息，查询一个不存在的 MX 记录，自然也不会有相关的 A 记录出现在附加部分。
   你可以使用 dig +additional yourdomain.com mx 这样的命令来明确显示附加部分，或者使用 dig +trace 来观察整个查询路径上各个服务器的响应情况，从而判断附加部分是在哪一环节丢失的。