什么是 dig +trace？

Dig +trace 会完整追踪所查询域名的委托链。它可以从根名称服务器，到顶级域 (TLD) 服务器，再到权威名称服务器。Dig +trace 有助于团队排查 DNS 解析问题。

最显而易见的问题是根本无法连接到某个域或子域，其表现为出现故障提示页面。另一种 DNS 解析问题是延迟，它可能使查询时间超出人类正常的忍耐限度。

平均 DNS 查找时间以毫秒 (MSEC) 计，通常在 20 毫秒到 120 毫秒之间。优化工作旨在进一步缩短这些查询时间。

在正常的 dig 命令中，您的 DNS 服务器（作为您的互联网服务提供商解析器）会发出递归请求，并检查其本地缓存中是否存在最近且未过期的 DNS 记录。但这是在理想情况下，一切按预期运行时才会发生。 

当管理员需要“深入底层”时，便会求助于 dig +trace。通常，您需要绕过常规查询流程，是因为某些环节出了错。路由链中有某个部分未能正确运行。因此，管理员需要能够剖析和研究该链的各个部分及其各种联系，找出运行不正常的环节。

当团队使用 dig +trace 时，他们实际上忽略了先前缓存的内容，因此可以运行一次全新且迭代的查询，而不会走向陈旧过时的路径。

Dig +trace 对于故障排查非常有用，因为它能让您看到 DNS 解析在何处中断。问题可能出现在根域名服务器、顶级域或权威服务器层面。它还可以检查您域名的名称服务器记录是否正确，并在更改后验证 DNS 传播情况。

dig +trace 过程实际上可归结为四个步骤。

如果用户之前输入过该域名且计算机已缓存其 IP 地址，命令提示符 (CMD) 会立即检索所需的 IP 地址。系统访问并下载请求的内容，查询过程随即结束。 

然而，如果该域名对该设备来说是新的且未知的，则继续执行后续步骤。

dig 命令查找根名称服务器，获取与被调查目标域的顶级域 (TLD) 相关联的名称服务器 (NS) 记录。

dig 命令调查 TLD 名称服务器，以发现特定域的权威名称服务器。

dig 命令随后查询权威名称服务器以获取请求的 DNS 记录。例如，“A 记录”是一种资源记录，它将便于人类使用的域名与 IPv4 或 IPv6 地址关联起来。同时，起始授权机构 (SOA) 记录保存着 DNS 区域所需的管理数据。

返回的 DNS 响应包括“答案部分”，这是能够成功响应原始查询（也称为“问题部分”）的资源记录。

此外，响应可能还包含一个列出权威名称服务器的“授权部分”，以及可能包含额外信息的“附加部分”。管理员可以精确选择他们所需的记录类型，无论是邮件服务器（MX 记录）还是名称服务器（NS 记录）。 

在路径上的每个调查步骤中，管理员都会收到输出信息，以了解每个阶段的状态以及流程是否按预期继续。

例如，管理员会看到“NOERROR”消息，这表明测试在该阶段未发生任何问题。（注：该消息并不表示整体操作的成功或失败，不应被误解。它虽然有用，但所传达的信息有限。）

有趣的是，DNS 基础设施有助于支持 DNS 层级结构，并利用巧妙的转介系统来辅助查找过程。这样，如果一台服务器无法将查询引导至完成，它实质上会将查询指引至另一台服务器，以助其推进并延续查询旅程。 

互联网使用的域名系统由在不同层级运行的多个根名称服务器构成。最重要的是在最顶层运行的 13 个逻辑根名称服务器，它们以字母表的前 13 个字母命名。

这 13 个逻辑根名称服务器中的每一个所指代的并非单一计算机或操作系统，而是代表一个指定的管理机构，负责处理所有互联网 DNS 查询流量的十三分之一。因此，当我们提及“服务器 A”时，我们指的是服务器 A 这一指定名称，它可以涵盖数量不限的单个 DNS 服务器。

同样值得注意的是，这 13 个根名称服务器被委托给各类实体——包括各类营利性公司、大学和军事组织。虽然最初大多数物理服务器的位置确实高度集中在美国，但随着时间的推移，这种格局已重新平衡。如今，物理服务器遍布全球。

以下是负责运行 13 个不同 root-servers.net 指定名称的团体：

• 服务器 A（a.root-servers.net）：运营商：VeriSign, Inc.，该公司在全球范围内提供互联网基础设施和域名注册服务。

• 服务器 B（b.root-servers.net）：运营商：南加州大学 (ISI)。USC 的信息科学研究所致力于研究先进的计算机与通信技术。

• 服务器 C（c.root-servers.net）：运营商：Cogent Communications，这是一家管理着庞大光纤网络并提供托管服务的国际 ISP。

• 服务器 D（d.root-servers.net）：运营商：马里兰大学，由其高级网络基础设施与互联网全球服务 (ACIGS) 团队负责管理。

• 服务器 E（e.root-servers.net）：运营商：美国国家航空航天局 (NASA)，具体由其网络与电信服务 (NaTS) 业务线负责。 

• 服务器 F（f.root-servers.net）：运营商：Internet Systems Consortium, Inc.，这是一家通过提供多种软件和协议来支持互联网的非营利性机构。 

• 服务器 G（g.root-servers.net）：运营商：美国国防部网络信息中心 (NIC)，该中心还负责管理国防部的 IPv6 地址规划。

• 服务器 H（h.root-servers.net）：运营商：美国陆军研究实验室 (ARL)，其前身为弹道研究实验室 (BRL)。 

• 服务器 I（i.root-servers.net）：运营商：Netnod，这是一家瑞典的非营利性互联网基础设施组织，主要以北欧地区的互联服务而闻名。 

• 服务器 J（j.root-servers.net）：运营商：VeriSign, Inc.（参见服务器 A）。 

• 服务器 K（k.root-servers.net）：运营商：Reseaux IP Europeens Network Coordination Centre (RIPE NCC)，这是一家专注于欧洲、中东和亚洲地区的非营利性区域性互联网注册管理机构。 

• 服务器 L（l.root-servers.net）：运营商：Internet Corporation for Assigned Names and Numbers (ICANN)，该非营利组织最初通过美国政府合同成立，现已发展成为一个独立的、以全球为中心的组织。

• 服务器 M（m.root-servers.net）：运营商：WIDE 项目（Widely Integrated Distributed Environment 的缩写），该互联网项目始于三所日本大学的合作。 

查询流量在这 13 个服务器之间平均分配，没有任何一个服务器承担比其他服务器更多的流量。区域因素可能影响用户最常访问哪些服务器，但总体而言流量相似，主要涉及对互联网服务提供商地址的请求。

需要 13 个实体来管理 DNS 查询流量的原因是，每年产生的 DNS 查询量高达数万亿次。一些估计认为总数会超过 100 万亿，但这些数字是基于经验的推测。这是一个如此庞大的数字，以至于实际上无法精确计算。

还有一些间接相关的问题也应予以说明：

• 一种从 DNS 获取更多效用的方法是使用 DNS 扩展机制 (EDNS)。EDNS 是一组针对 DNS 协议的增强功能。当管理员遇到更大的 DNS 消息载荷时，EDNS 能够适应传输这些超大的数据包。除了容纳更大的消息外，EDNS 还提供诸如 EDNS 客户端子网 (ECS) 选项等功能，该选项可提升常受延迟问题影响的应用程序的性能水平。 

• OPT 伪区段是 EDNS 引入的一种独特类型的 DNS 记录。它携带有用的交易信息，但不包含标准 DNS 数据。OPT 伪区段包含在 DNS 消息的“附加数据”部分中。它提供诸如 EDNS 版本、标志以及用户数据报协议（一种常用的查询格式）的最大数据包大小等详细信息。 

• Linux 操作系统和某些类 Unix 系统依赖 /etc/resolv.conf 配置文件来通知系统激活其解析器例程，以查找相应主机名的 IP 地址。此文件的内容包括 DNS 服务器的 IP 地址、要搜索的域列表、本地域名以及用于确定解析器操作的选项。这些操作可以包括全局选项，即管理员可单方面应用的设置。 

• 不常真正使用 DNS 的类 Unix 系统通常包含一个手册页（或称为“man page”）。该页面作为文档，概述了关于特定命令文件、系统调用或配置文件的定义信息。手册页提供了关于系统文件和工具的基本背景信息，重点关注诸如命令或程序名称、概要、描述和选项等内容。