一、实验目的

了解域名系统DNS的作用

理解DNS的工作原理

观察DNS递归查询过程

观察DNS缓存的作用

二、 知识储备

在正式动手构建网络拓扑之前，我们需要理清 DNS（Domain Name System）系统的几个核心概念。DNS 并不是由一台超级计算机来完成所有解析的，而是由全球分布的服务器组成的一个倒置的树状架构。

2.1 域名空间的层级结构

在我们日常访问的完整域名（例如 m.xyz.com.）中，其实蕴含着严格的从右向左的层级关系：

• 根域（Root）：用一个英文句号 . 表示，它是整个 DNS 树的树根，隐藏在所有域名的最末尾。

• 顶级域（TLD, Top-Level Domain）：紧挨着根域，如 .com、.cn、.net 等。

• 二级域（SLD, Second-Level Domain）：在顶级域之下，如本实验中的 xyz.com。

• 主机名（Host）：位于最左侧，代表网络中具体的某一台服务器，如本实验中的 m（通常指向具体的 Web 服务器）。

（注：在日常网络访问和浏览器输入时，末尾的根域点通常被隐式省略，本实验后续的实际输入均采用常规的 m.xyz.com 形式。）

2.2 域名服务器的角色与分工

为了对应上述域名结构，我们的实验拓扑中设计了四种不同角色的域名服务器，它们各司其职：

• 本地域名服务器（Local DNS Server）： 它是客户端 PC 访问网络的“代理人”。当 PC 需要解析域名时，首选会将请求发给它。如果它不知道答案，它会代替客户端去向外网发问（即执行递归查询）。

• 根域名服务器（Root DNS Server）： 最高级别的 DNS 服务器。它不记录具体的 IP，但它知道所有的“顶级域名服务器”在哪里。它起着“最高层引路人”的作用。

• 顶级域名服务器（TLD DNS Server）： 负责管理该顶级域（如 .com）下注册的所有二级域。它负责将查询指引到具体的权威服务器。

• 权限域名服务器（Authoritative DNS Server）： 这是解析链条的终点。它是某个具体域（如 xyz.com）的真正管理者，它的数据库里存有目标主机（m.xyz.com）最终的真实 IP 地址。

2.3 递归查询 vs 迭代查询

• 递归查询（Recursive Query）：像“接力赛”或“一问到底”。客户端（PC）把问题抛给本地域名服务器后，本地域名服务器如果不知道，就必须全权代劳，直到拿到最终结果再交还给客户端。

• 标准迭代查询（Iterative Query）：像“问路”。在真实的互联网骨干网中，根和顶级域名服务器为防止自身瘫痪，严格禁止递归，只支持迭代。即它们收到本地域名服务器的请求后，绝不代劳转发，而是直接返回“引荐（Referral）”告诉本地域名服务器：“我不知道，但你可以去问 .com 的顶级域名服务器，它的 IP 是 xxx”。本地域名服务器必须自己作为主体，发起新一轮的独立询问。

实验指引：真实的互联网 DNS 架构是“客户端到本地是递归，本地到外网是迭代”。但在本实验所使用的 Cisco Packet Tracer 仿真环境中，软件底层为了简化教学拓扑，其 DNS 服务默认采用了一种非标准的“模拟链式转发（完全递归）”模型。我们在 5.4 节抓包时会看到这种特定的接力赛现象，学习时需注意其与真实公网工程的底层差异。

三、 构建实验拓扑与基础配置

3.1 构建网络拓扑

在 Cisco Packet Tracer 工作区中，拖入一台以太网交换机（如 2960 系列）、一台计算机（PC0）以及五台服务器（Server-PT，分别命名为 Server0 ~ Server4）。使用直通线将 PC 和所有服务器连接到交换机上。

实验技巧（加速 STP 收敛）： 连接完成后，交换机的相关接口会呈现橘色（处于生成树协议 STP 的阻塞/监听状态）。您可以等待几十秒让其自然变绿，或者直接点击软件左下角的 “快进时间（Fast Forward Time）” 按钮，人为加速端口的开启过程。

3.2 在相关设备旁标注IP地址等相关信息

使用软件顶部的“放置注释（Place Note）”工具，在每台设备旁边标注好规划的 IP 地址、子网掩码以及相应的域名（如 Server0 旁标注 192.168.0.3 dns_root）。养成良好的标注习惯，能极大提高后续排错的效率。

设备	IP 地址	子网掩码	角色 / 域名
PC0	192.168.0.1	255.255.255.0	客户端（DNS 指向 192.168.0.6）
Server4	192.168.0.2	255.255.255.0	Web 服务器（m.xyz.com）
Server0	192.168.0.3	255.255.255.0	根域名服务器
Server1	192.168.0.4	255.255.255.0	.com 顶级域服务器（dns.com）
Server2	192.168.0.5	255.255.255.0	权限域名服务器（dns.abc.com，管理 xyz.com）
Server3	192.168.0.6	255.255.255.0	本地域名服务器（dns.xyz.com）（注：本地域名服务器，客户端首选 DNS）

3.3 配置IP地址、子网掩码以及DNS服务器的IP地址

依次打开每台设备，进入 桌面 (Desktop) -> IP 配置 (IP Configuration) 界面。为所有设备配置同一网段的静态 IP 地址（例如 192.168.0.1 ~ 192.168.0.6）和子网掩码 255.255.255.0。

关键点： 在 PC0 的配置界面中，必须将其 “DNS 服务器（DNS Server）” 地址明确指定为本地域名服务器（Server 3）的 IP：192.168.0.6。

3.4 网络底层连通性预热

在拓扑搭建完毕且 IP 配置完成后，我们需要在 实时工作模式（Realtime） 下，通过 PC0 向所有服务器进行连通性测试。

操作步骤： 打开 PC0 的 命令提示符 (Command Prompt)，依次输入以下命令并回车确认收到回复（Reply）：

ping 192.168.0.2 //测试 Web 服务器

ping 192.168.0.3 //测试 根域名服务器

ping 192.168.0.4 //测试 顶级域名服务器

ping 192.168.0.5 //测试 权限域名服务器

ping 192.168.0.6 //测试 本地域名服务器

【核心原理解析】：为什么一定要提前做 Ping 测试？

很多人会跳过这一步直接去配 DNS，从而在后续抓包时陷入混乱。提前 Ping 通全网具有四大无可替代的工程意义：

1. 物理与网络层排错：验证网络拓扑是否构建成功，以及各设备的 IP 地址和子网掩码配置是否绝对正确。

2. 排除 ARP 干扰（纯净抓包准备）：Ping 过程会让 PC0 和各服务器提前通过 ARP（地址解析协议）获取到彼此的 MAC 地址，并将映射关系存入设备的 ARP 缓存中。这样在后续进入仿真模式观察 DNS 交互时，就不会被大量突发的 ARP 广播包（泛洪）干扰视线。

3. 完成交换机自学习：Ping 产生的报文会促使交换机进行源 MAC 地址学习，提前建立好完整的 MAC 地址表，确保后续的 DNS 单播报文能够被精准转发。

如果测试失败，请检查网络拓扑、计算机PC0、服务器Server0~Server4各自的IP地址和子网掩码配置是否正确。

四、核心实验配置

在本实验中，我们的终极目标是让计算机 PC0 通过浏览器，使用域名 m.xyz.com 成功访问 Web 服务器（Server 4）。这就要求网络中的各级 DNS 服务器通力合作，层层解析未知域名。我们将在各服务器的图形用户界面（GUI）中依次进行静态资源记录的配置。

4.1 配置本地域名服务器（Server 3）

首先，我们需要配置本地域名服务器（Server 3）。本地域名服务器是解析的“第一站”，我们需要为其添加指向根服务器的“根提示”和底层路由。

【原理解析】

从配置完成的图例可以看出，本地域名服务器 Server 3 的 DNS 资源记录列表中，添加了两条 DNS 资源记录：

• 第一条（NS记录）：名称为一个英文句号 .（表示 DNS 树状结构的根域），NS 类型表示这是一条名称（或域名）服务器记录，dns_root 是根域名服务器的名称。这条 DNS 资源记录（即根提示）的作用是：让本地域名服务器收到任何待解析的未知域名请求时，都会向名称为 dns_root 的根域名服务器进行查询。

• 第二条（A记录）：dns_root 是根域名服务器的名称，A Record 类型表示这是一条主机与其 IP 地址映射关系的记录（即粘滞记录），192.168.0.3 是根域名服务器的 IP 地址。

【具体配置步骤】

请按照以下步骤，在 Server 3 的图形用户界面中完成上述理论配置：

（1）进入配置界面：在网络拓扑图中，单击打开本地域名服务器 Server 3。

（2）定位 DNS 服务：在弹出的窗口中，选择顶部菜单栏的 “服务”（Services） 选项卡，然后在左侧服务列表中单击 DNS。

（3）添加根提示（NS记录）：在右侧的配置框中输入以下信息，以指定根域的管理者：

• 名称（Name）：输入一个英文半角句号 . （请确保输入法在英文状态，且前后绝对不要带空格）。
• 类型（Type）：在下拉菜单中选择 NS 记录（NS Record）。
• 详细信息（Detail）：输入 dns_root。
• 单击 “添加”（Add） 按钮。

（4）添加粘滞记录（A记录）：紧接着输入以下信息，以打通底层的 IP 路由：

• 名称（Name）：输入刚才设定的服务器名称 dns_root。
• 类型（Type）：在下拉菜单中选择 A 记录（A Record）。
• 地址（Address）：输入根域名服务器的 IP 地址 192.168.0.3。
• 单击 “添加”（Add） 按钮。

（5）开启服务并确认：在界面最上方的“DNS 服务”选项中，勾选 “开启”（On） 单选按钮。此时，在下方的资源记录列表框中，应该能清晰地看到刚才添加的两条记录。单击“DNS 缓存”按钮，还可以查看当前的缓存状态。

【知识补充：为什么要输入一个“.”？】 在严格的 DNS 底层协议规范中，所有的完整域名都必须以代表根域的英文句号 . 结尾（即完全限定域名 FQDN）。平时我们在软件中配置常规域名时，系统会自动在末尾隐式补全这个点。但在配置最高层的“根”本身时，必须手动输入这个绝对符号 .，否则系统将无法识别解析路径的终点。

4.2 配置根域名服务器（Server 0）

【角色定位】

根域名服务器是 DNS 解析的“最高指挥枢纽”。它本身并不记录具体的最终 Web 主机 IP，但它掌握着所有顶级域（如 .com、.net、.cn）管理者的名单。因此，我们在 Server 0 上的配置核心是实现顶级域的向下授权（Zone Delegation）。

【原理解析】

从配置完成的图例可以看出，根域名服务器 Server 0 的 DNS 资源记录列表中，添加了两条关联的 DNS 资源记录：

• 第一条（NS记录）：名称为 com（代表顶级域名 .com），NS 类型表示这是一条域名服务器记录，dns.com 是管理该顶级域的服务器名称。这条记录的作用是：当根域名服务器收到待解析的 .com 后缀域名请求时，会指引查询者去向名为 dns.com 的顶级域名服务器进行下一步查询。

• 第二条（A记录）：dns.com 是顶级域名服务器的名称，A Record 类型表示这是一条主机与其 IP 地址映射关系的记录（即粘滞记录），192.168.0.4 是顶级域名服务器的底层路由 IP 地址。

【具体配置步骤】

在本地域名服务器将查询请求转发至根域后，根域名服务器（Server 0）需要指明 .com 顶级域（TLD）的管理者。请按照以下步骤进行配置：

（1）进入配置界面：在网络拓扑图中，单击打开根域名服务器 Server 0。

（2）定位 DNS 服务：在弹出的窗口中，选择顶部菜单栏的 “服务”（Services） 选项卡，然后在左侧服务列表中单击 DNS。

（3）添加顶级域授权（NS记录）：在右侧的配置框中输入以下信息，向下授权 .com 域：

• 名称（Name）：输入 com（代表 .com 顶级域）。
• 类型（Type）：在下拉菜单中选择 NS 记录（NS Record）。
• 详细信息（Detail/服务器名称）：输入顶级域名服务器的名称 dns.com。
• 单击 “添加”（Add） 按钮。

（4）添加粘滞记录（A记录）：紧接着输入以下信息，提供顶级域名服务器的真实网络地址：

• 名称（Name）：输入刚才指定的服务器名称 dns.com。
• 类型（Type）：在下拉菜单中选择 A 记录（A Record）。
• 地址（Address）：输入顶级域名服务器的 IP 地址 192.168.0.4。
• 单击 “添加”（Add） 按钮。

（5）开启服务并确认：在界面最上方的“DNS 服务”选项中，确认已勾选 “开启”（On） 单选按钮。此时，在下方的资源记录列表框中，应该能清晰地看到刚才添加的两条记录。

4.3 配置顶级域名服务器（Server 1）

【角色定位】

顶级域名服务器（如管理 .com 的服务器）收到来自根服务器的引流后，需要进一步向下授权，指明二级域（如 xyz.com）的具体权威管理者是谁。它是连接宏观顶级域与具体企业/组织域名的核心桥梁。

【原理解析】

从配置完成的图例可以看出，顶级域名服务器 Server 1 的 DNS 资源记录列表中，同样添加了两条配合使用的资源记录：

• 第一条（NS记录）：名称为 xyz.com（表示顶级域名 .com 下的二级域名），NS 类型表示这是一条域名服务器记录，dns.abc.com 是负责管理该二级域的权限域名服务器名称。这条记录的作用是：当 Server 1 收到待解析的 xyz.com 域名请求时，会明确指出“请去向名为 dns.abc.com 的服务器进行权威查询”。

• 第二条（A记录）：dns.abc.com 是该权限域名服务器的名称，A Record 类型表示这是一条主机与其 IP 地址映射关系的记录（即粘滞记录），192.168.0.5 是这台权限域名服务器的实际网络 IP 地址。

【具体配置步骤】

在根服务器指明了顶级域的管理者后，请按照以下步骤在顶级域名服务器（Server 1）中完成二级域的授权配置：

（1）进入配置界面：在网络拓扑图中，单击打开顶级域名服务器 Server 1。

（2）定位 DNS 服务：选择顶部菜单栏的 “服务”（Services） 选项卡，然后在左侧服务列表中单击 DNS。

（3）添加二级域授权（NS记录）：在右侧的配置框中输入以下信息，向下授权 xyz.com 域：

• 名称（Name）：输入 xyz.com。
• 类型（Type）：在下拉菜单中选择 NS 记录（NS Record）。
• 详细信息（Detail）：输入权限域名服务器的名称 dns.abc.com。
• 单击 “添加”（Add） 按钮。

（4）添加粘滞记录（A记录）：紧接着输入以下信息，提供该权限域名服务器的底层路由地址：

• 名称（Name）：输入刚才指定的服务器名称 dns.abc.com。
• 类型（Type）：在下拉菜单中选择 A 记录（A Record）。
• 地址（Address）：输入权限域名服务器的 IP 地址 192.168.0.5。
• 单击 “添加”（Add） 按钮。

（5）开启服务并确认：在界面最上方的“DNS 服务”选项中，确认已勾选 “开启”（On） 单选按钮。此时，在下方的资源记录列表中应包含上述两条记录。

【排错预警：IP 地址的一致性约束】 请务必注意，在 Server 1 中添加的 NS 记录的“详细信息”（如 dns.abc.com），必须与下一条 A 记录中的“名称”完全一致。更重要的是，该 A 记录中绑定的 地址（Address） 必须与权限服务器（Server 2）网卡上配置的静态 IP（192.168.0.5）严格相同。 （注：真实工程中，管理 xyz.com 的服务器通常命名为 ns1.xyz.com。本实验沿用 dns.abc.com 是为了验证跨域名的绝对匹配逻辑，务必小心拼写）。

【原理解析 · 跨域授权说明】
请注意，我们在 NS 记录中填写的“权限域名服务器名称”是 dns.abc.com，看起来和它要管理的 xyz.com 域名没有直接关系。这不是错误，而是 DNS 设计中的一种标准做法（跨域授权）。通过这种机制，abc.com 的服务器也能受权管理 xyz.com 的解析。我们同时添加的 A 记录（将 dns.abc.com 指向 192.168.0.5），就是为了在授权的同时，提供一条“寻路线索”（粘滞记录/胶水记录），让解析器能顺利找到它。同时，也请注意区分，我们命名为 dns.xyz.com 的本地域名服务器（Server 3）只是一个递归解析器，它本身并不负责 xyz.com 的权威解析。

4.4 配置权限域名服务器（Server 2）

【角色定位】

权限域名服务器是整个 DNS 分布式迭代解析链条的“终点”。它不再向其他域名服务器进行区授权（Zone Delegation），而是作为特定域（xyz.com）的最终权威管理者，直接提供目标主机所对应的物理网络 IP 地址，即给出权威应答（Authoritative Answer）。

【原理解析】

从配置完成的图例可以看出，权限域名服务器 Server 2 的 DNS 资源记录列表中，仅添加了一条起决定性作用的 DNS 资源记录：

• A 记录（主机记录）：名称为 m.xyz.com（表示域名 xyz.com 下的三级域名主机 m），A Record 类型表示这是一条特定主机域名与其 IP 地址直接映射的记录，192.168.0.2 正是远端目标 Web 服务器（Server 4）的实际 IPv4 地址。

【具体配置步骤】

在顶级域名服务器指明了二级域的权威管理者后，我们需要在权限域名服务器（Server 2）中完成最终的资源映射。请按照以下步骤进行配置：

（1）进入配置界面：在网络拓扑图中，单击打开权限域名服务器 Server 2。

（2）定位 DNS 服务：在弹出的窗口中，选择顶部菜单栏的 “服务”（Services） 选项卡，然后在左侧服务列表中单击 DNS。

（3）添加主机解析（A记录）：在右侧的配置框中输入以下信息，直接建立应用层域名与网络层 IP 的映射：

• 名称（Name）：输入完整的最终域名 m.xyz.com（代表 xyz.com 域下的主机 m）。
• 类型（Type）：在下拉菜单中选择 A 记录（A Record）。
• 地址（Address）：输入目标 Web 服务器的实际 IP 地址 192.168.0.2。
• 单击 “添加”（Add） 按钮。

（4）开启服务并确认：在界面最上方的“DNS 服务”选项中，确认已勾选 “开启”（On） 单选按钮。此时，在下方的资源记录列表（Resource Records）中，应仅包含这条唯一的 A 记录。

五、应用层验证与仿真抓包剖析

在底层网络连通且各级 DNS 服务器配置就绪后，我们将在真实时间流逝下验证 DNS 解析的结果，并为后续单步抓包剖析协议工作机制做好环境准备。

5.1 通过Web服务器的域名对其进行访问

首先，我们需要在实时工作模式（Realtime）下，验证整条 DNS 授权链路是否已成功打通。

操作步骤：

• 确认 Web 服务状态：首先单击打开 Web 服务器（Server 4），进入 “服务”（Services） 选项卡，确保左侧的 HTTP 服务处于 “开启”（On） 状态。
• 确保软件当前处于 实时工作模式（Realtime）。
• 单击打开计算机 PC0，进入 桌面 (Desktop) 选项卡，选择 Web 浏览器 (Web Browser)。
• 在浏览器的 URL 地址栏中，输入 Web 服务器 Server 4 的完整域名：m.xyz.com。单击 “Go” 按钮或按下回车键。

现象观察：若配置完全无误，经过短暂的解析延迟后，PC0 的浏览器中将成功加载并显示 Web 服务器 Server 4 提供的默认网页界面。

【故障诊断与排查指南】：如果访问失败提示 Host Name Unresolved怎么办？

请立刻停止盲目尝试，严格按照以下顺序进行工程排错：

1. 核对终端网卡指向：检查计算机 PC0 的 IP 配置，其“DNS 服务器”参数是否准确指向了本地域名服务器 Server 3 的 IP 地址（192.168.0.6）。

2. 核对服务状态与拼写：依次检查 Server 0、Server 1、Server 2、Server 3，确认所有服务器的 DNS 服务已勾选为 “开启”（On）；重点核查资源记录中的域名拼写是否出现空格或字母错漏。

5.2 查看并删除各域名服务器的DNS缓存中的内容

经过上述步骤的初步访问，计算机 PC0 已经通过本地域名服务器 Server 3 成功完成了一次 DNS 递归查询。在这个过程中，作为递归查询代理（Recursive Resolver）的 Server 3，会将最终拿到的 IP 记录在自己的动态缓存中，以提升下一次的解析效率。(注：Server 0 和 Server 1 作为权限授权服务器，只提供引荐，不会产生该域名的缓存)。 为了方便我们在接下来的仿真模式中，从零开始观察完整的 DNS 交互报文流向，我们必须对本地域名服务器进行“缓存大扫除”：

• 单击打开本地域名服务器 Server 3 的 DNS 服务配置界面。
• 单击界面下方的 “DNS 缓存”（DNS Cache） 按钮，弹出缓存对话框，在此处可直观查看到刚才产生的动态缓存内容。
• 单击 “清空缓存”（Clear Cache） 按钮，即可将记忆抹除。

5.3 选择要监视的网络协议

在 Packet Tracer 界面右下角，将工作模式由“实时（Realtime）”切换至 “仿真（Simulation）” 模式。单击仿真面板中的 “显示/全部不显示”（Show All/None） 按钮清空默认协议，然后单击 “编辑筛选器”（Edit Filters）。在 IPv4 选项卡中，仅勾选 DNS 协议。这样可以屏蔽其他冗余报文，专注于域名解析相关的事件。

5.4 观察DNS递归查询过程

在模拟工作模式（Simulation）下，计算机 PC0 使用浏览器访问 m.xyz.com。单击单步模拟（Capture / Forward），我们将观察到数据包像“接力赛”一样在拓扑中进行单向传递。

第一阶段：递归查询请求转发 (Query Forwarding)

（1）PC0 → Server 3：PC0 发出 DNS 请求至本地域名服务器（Server 3）。

（2）Server 3 → Server 0：Server 3 在本地区域未找到记录，作为代理，将请求发往根域名服务器（Server 0）。

（3）Server 0 → Server 1：Server 0 发现请求属于 .com 域，触发 PT 特定的转发机制，直接将包送至顶级域名服务器（Server 1）。

（4）Server 1 → Server 2：Server 1 发现属于 xyz.com 域，再次代劳转发给权限域名服务器（Server 2）。

【仿真现象硬核解析】：为什么抓包时会看到交换机泛洪和设备打叉（×）？

在单步观察去程的 DNS 单播报文时，您可能会看到报文被交换机发往了所有端口，且其他无关服务器头上出现了红色的“×”。 原理解释：这并非系统报错，而是经典的未知单播泛洪（Unknown Unicast Flooding）现象。由于距离 3.4 节的连通性测试已过去一段时间，交换机内部的 MAC 地址表已超时老化清空。当交换机收到目标明确的 DNS 单播报文时，由于不知道目标设备的具体端口，只能采取泛洪转发。无关服务器收到不属于自己的单播帧后，会在网卡底层直接丢弃（显示为打叉），而真正的目标服务器则会正常接收并处理。

第二阶段：权威应答逐级回传 (Response Relaying)

此时，权限域名服务器 Server2 已经在自己的本地区域文件里找到了最终答案（192.168.0.2）。由于在“去程阶段”交换机已经重新学习并刷新了各个端口的 MAC 地址，接下来的回传将全过程精准单播，不再有任何泛洪：

（5）Server 2 → Server 1：Server 2 找到权威 A 记录答案，将应答报文发回给 Server 1。

（6）Server 1 → Server 0：Server 1 把答案回传给 Server 0。

（7）Server 0 → Server 3：Server 0 回传给 Server 3。

（8）Server 3 → PC0：Server 3 把最终答案交到 PC0 手上。

实验注意事项：由于 DNS 缓存机制的存在，上述完整的逐级查询过程，只有在清空相关设备的 DNS 缓存后的第一次访问时才会出现。

【学术深度探讨：仿真现象 vs 真实互联网】

本实验中观察到的现象是经典的“完全递归查询”模型。Cisco Packet Tracer 为了直观展示层级授权关系，简化了底层逻辑，允许根和顶级域名服务器替客户端“跑腿”。但在真实的互联网骨干网中：为了防止性能瘫痪，根域名服务器（Server 0）和顶级域名服务器（Server 1）严格禁止递归。它们采用的是迭代查询（Iterative Query）：即 Server 0 收到请求后，不向下转发，而是直接向 Server 3 返回一个引荐（Referral），让 Server 3 自己去问 Server 1。因此，真实公网中的报文流向通常是 Server 3 不断与各级服务器进行“折返跑”。本实验保留 PT 的仿真现象，旨在帮助初学者直观理解 DNS 的宏观层级拓扑。

5.5 观察DNS缓存的作用

理论上，DNS 的逐级查询极其消耗网络带宽与服务器资源。为了验证缓存机制的工程价值，我们进行二次访问测试。

• 操作步骤与现象观察：保持在仿真模式下，不要清除任何设备的缓存。再次在 PC0 的浏览器中输入 m.xyz.com 并回车。单击单步观察。

• 结论分析：您可以清晰地观察到，PC0 发出的 DNS 请求到达本地域名服务器 Server 3 后，Server 3 直接向 PC0 返回了应答报文，不再向根服务器（Server 0）发起任何后续查询链路。

• 原理解释：在 5.4 的首次查询过程中，本地域名服务器 Server 3 已经将 m.xyz.com 与 192.168.0.2 的映射关系记录在了自身的动态 DNS 缓存中。当遇到相同的解析请求时，它能够凭借记忆直接向客户端返回结果（在真实网络报文中，这种凭借缓存给出的答案会被标记为非权威应答 Non-authoritative answer），从而极大降低了外网的寻址延迟。