DNS 域名解析

|-------|------------|-------------------------------------------------|
| 位 | 名称 | 含义 |
| 0 | QR | 0=查询（Query），1=响应（Response） |
| 1-4 | Opcode | 操作码，0=标准查询，1=逆查询（IP -> 域名，已被废弃），2=服务器状态请求 |
| 5 | AA | Authoritative Answer，权威应答（仅响应中有效） |
| 6 | TC | Truncated，报文被截断（通常因 UDP >512 字节） |
| 7 | RD | Recursion Desired，客户端希望服务器递归查询 |
| 8 | RA | Recursion Available，服务器支持递归查询 |
| 9-11 | Z | 保留位，必须为 0 |
| 12-15 | RCODE | 响应码：0=无错误，1=格式错误，2=服务器失败，3=域名不存在，4=不支持查询类型，5=拒绝 |

其中，AA（权威应答）= 1时：

表示当前 DNS 应答报文是由"**权威域名服务器"**返回的，该服务器对所查询的域名区域具有管理权，其提供的数据是权威、可信的

权威域名服务器

权威域名服务器是指负责管理某个特定域名区域（Zone）的 DNS 服务器

例如：

example.com 的权威域名服务器可能为 ns1.example.com 、ns2.example.com

当查询 www.example.com 的 A 记录时，只有这些权威服务器返回的结果才带有 **AA=1，**权威服务器的数据来源于域名管理员配置的"区域文件（Zone File）"，是最原始、最准确的数据

而当AA = 0时：

表示该应答来自非权威服务器，如本地 DNS 缓存服务器（如运营商 DNS、8.8.8.8）、递归解析器（Resolver）、中间缓存服务器，它们的数据是"从别处查来并缓存的"，不是原始数据源，这类应答可能过期（取决于 TTL），不一定最新

QDCOUNT / ANCOUNT / NSCOUNT / ARCOUNT（各 2 字节）： 表示后续各部分包含的记录条数

例如：

;; ANSWER SECTION:

www.baidu.com. 300 IN A 180.101.49.12

www.baidu.com. 300 IN A 180.101.49.11

此时 ANCOUNT = 2（两条 A 记录）

Question（问题部分）

用于告诉服务器"你想查什么"：

QNAME（域名） ：使用"标签长度+内容"格式编码，以 0x00 结尾

例如：www.example.com 编码为：

0x03 'w' 'w' 'w' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00
↑长度 ↑字符 ↑长度 ↑字符... ↑长度 ↑字符 ↑结束

支持"消息压缩"（使用指针指向之前出现的相同域名，节省空间），例如 0xC0 0x0C 表示"指向报文偏移量 0x0C 处的域名"

QTYPE（查询类型）（2字节）：

|-----|-------|---------|
| 值 | 类型 | 说明 |
| 1 | A | IPv4 地址 |
| 2 | NS | 域名服务器 |
| 5 | CNAME | 别名 |
| 15 | MX | 邮件服务器 |
| 28 | AAAA | IPv6 地址 |
| 255 | ANY | 所有记录 |

QCLASS（查询类别）（2字节 ）：用于指定查询的网络类别或命名空间，通常为 1

1 ->IN：Internet（互联网），绝大多数 DNS 查询都使用这个类别，用于 IPv4/IPv6 域名解析、邮件路由等）

其他值如：

2 -> CS：CSNET class（已废弃）------ 早期 CSNET 网络使用，现已不用

3 -> CH ：CHAOS（混沌类）------ 用于 Chaosnet 协议，现代极少使用，有时用于版本查询

Resource Record（资源记录）

Answer/Authority/Additional ，这三个部分结构完全相同，每条记录称为一个 RR（Resource Record ），且 只有应答报文（Response）才包含 Answer/Authority/Additional 部分 ，查询报文（Query）中这些部分为空

NAME（域名）：使用和 QNAME 相同的"标签+长度"格式，支持指针压缩

TYPE/CLASS：同 QTYPE / QCLASS

**TTL（Time To Live）：**该记录在缓存中可保存的秒数，例如：300 = 5 分钟，86400 = 1 天

RDATA（资源数据）：根据 TYPE 不同，内容格式不同

|-----------|-----------------------------------------------|
| TYPE | RDATA 格式示例 |
| A | 4 字节IPv4 地址 →0x5DB8D822=93.184.216.34 |
| AAAA | 16 字节IPv6 地址 |
| CNAME | 压缩格式域名 → 指向 example.com |
| NS | 压缩格式域名 →ns1.example.com |
| MX | 2 字节优先级 + 域名 →10 mail.example.com |
| TXT | 长度+字符串 →0x0B "v=spf1 -all" |

Answer

回答部分 ，对查询问题的直接答案 ------ 即你查询的记录类型所对应的资源记录

包含与查询匹配的记录，如 IP 地址（A、AAAA）、别名（CNAME）、邮箱服务器（MX）等

例如：

;; ANSWER SECTION:

www.baidu.com. 300 IN A 180.101.49.12

www.baidu.com. 300 IN A 180.101.49.11

Authority

授权部分 ，提供**"谁是权威**"的信息，通常用于指示"该域由哪些权威服务器管理"或"用于缓存控制的 SOA 记录

包含NS（Name Server）记录 → 告诉你"这个域名该问谁"、SOA（Start of Authority）记录 → 用于负缓存（Negative Caching）时告知 TTL

例如：

当域名不存在时，就返回：

;; AUTHORITY SECTION:

example.com. 900 IN SOA ns1.example.com. admin.example.com. ( ... )

告诉你"这个域归谁管 + 负缓存时间"

Additional

：附加部分 ，提供**"额外有用信息"**，帮助客户端减少后续查询，提升效率。不是必须的，但能优化性能，包含 NS/MX 附带 IP、EDNS 扩展支持等

例如：

胶水记录（Glue Records）： 当 Authority 或 Answer 中包含域名（如 NS 或 MX），附加部分可提供这些域名的 IP 地址，避免客户端再次查

;; ANSWER SECTION:

example.com. 172800 IN NS ns1.example.com.

example.com. 172800 IN NS ns2.example.com.

;; ADDITIONAL SECTION:

ns1.example.com. 172800 IN A 192.0.2.10

ns2.example.com. 172800 IN A 192.0.2.20

客户端拿到 NS 后，直接用附加的 A 记录连接，无需再查 ns1.example.com 的 IP

总而言之，Answer 是"你要的答案"，Authority 是"谁管这事"，Additional 是"顺手给你的小抄"

Answer Section：核心答案，直接回应查询

Authority Section：用于错误处理、委派、缓存控制

Additional Section：性能优化神器，减少 DNS 查询轮次，支持现代扩展（如 CDN、DNSSEC）

接下来，我们通过 Wireshark 抓包来看实际的 DNS 报文

抓包分析

我们以查询 AAAA www.baidu.com 地址为例

请求

可以看到 DNS 的传输协议为 UDP：

源端口：62277（客户端随机端口）

目的端口：53（标准 DNS 端口）

UDP 长度：39 字节（包含 UDP 头 + DNS 数据）

我们重点来看 DNS 层：

Header 部分：

Transaction ID：0x83ee（十进制：33758），用于匹配请求与响应（后续响应中会相同）

Flags：0x0100，二进制为 0000 0001 0000 0000：

QR=0：这是 查询（Query），不是响应

Opcode=0：标准查询（Standard Query）

AA=0：非权威应答

TC=0：未截断（响应不会被截断）

RD=1：递归查询（希望 DNS 服务器帮你查）

RA=0：无意义（查询中为 0）

AD=0，CD=0：无 DNSSEC 认证/检查（普通查询）

因此，这是一个 **标准、递归、非权威的 DNS 查询请求，**希望 DNS 服务器"帮我查到底"，并返回结果

Questions：1，即查询一个域名

Answer RRs：0，没有答案（因为是请求）

Authority RRs：0，没有授权记录

Additional RRs：0，没有附加记录

Queries（问题部分）：

www.baidu.com: type AAAA, class IN

**QNAME：www.baidu.com，**要查询的域名（结尾点省略了）

**QTYPE：AAAA，**查询 IPv6 地址

**QCLASS：IN，**Internet 类别（默认，通常省略）

即，用户正在尝试通过 IPv6 访问百度网站

我们继续看响应

响应

Wireshark 显示**[Response In: 518]**，即响应在 Frame 518 中：

Header：

Transaction ID：0x83ee，与请求完全一致，确认是对应响应

Flags：0x8180

按位分解：

|-------|------------|---|-------------------------------------------------|
| 位 | 名称 | 值 | 说明 |
| 15 | QR | 1 | 这是响应（Response） |
| 14-12 | Opcode | 0 | 标准查询（Standard Query） |
| 11 | AA | 0 | 非权威应答------ 该服务器不是 baidu.com 的权威服务器（如递归解析器） |
| 10 | TC | 0 | 消息未截断（完整响应） |
| 9 | RD | 1 | 请求递归（客户端希望递归查询） |
| 8 | RA | 1 | 递归可用（Recursion Available）------ 服务器支持递归查询 |
| 7 | Z | 0 | 保留位 |
| 6 | AD | 0 | 回答未认证（无 DNSSEC 验证） |
| 5 | CD | 0 | 不检查（Check Disable） |
| 4-0 | RCODE | 0 | 无错误（No error） |

即，这是一个成功的、非权威的 DNS 响应，由递归 DNS 服务器返回，支持递归查询，但未启用 DNSSEC

Questions：1，查询一个域名

Answer RRs：3，返回了 3 条答案记录

Authority RRs：0，没有授权记录

Additional RRs：0，没有附加记录

Questions：

www.baidu.com: type AAAA, class IN，与请求一致，确认是针对 www.baidu.com 的 AAAA 查询

Answer（回答部分）：

其中，第一条 ------ CNAME 记录：

www.baidu.com: type CNAME, class IN, cname www.a.shifen.com

CNAME 值为 www.a.shifen.com，表示 www.baidu.com 是一个别名，实际指向的是 www.a.shifen.com

也就是说，www.baidu.com 只是一个别名，而 www.a.shifen.com 才是百度的 真实服务器入口

其中shifen.com 是百度公司注册并管理的域名 ，主要用于承载百度搜索、百度首页等核心服务的后端服务器集群 ，通过 CNAME 从 baidu.com 域名指向 shifen.com，从而实现：

统一管理 ：所有百度子域名（如 tieba.baidu.com、map.baidu.com）都可以 CNAME 到不同的 shifen.com 子域，集中管理后端 IP

负载均衡：www.a.shifen.com 可返回多个 IP（A/AAAA），实现智能调度和负载分担

CDN/ 高可用：shifen.com 后端可接入 CDN、反向代理、异地多活架构，提升访问速度和稳定性

快速切换：若某机房故障，只需修改 shifen.com 的解析，无需动 baidu.com 主域

隐藏架构：用户看到的是 baidu.com，实际访问的是 shifen.com，增强安全性和灵活性

第二条 ------ AAAA 记录：

www.a.shifen.com: type AAAA, class IN, addr 2409:8c00:6c21:11eb:0:ff:b0bf:59ca

查询出 www.a.shifen.com 的地址为 2409:8c00:6c21:11eb:0:ff:b0bf:59ca，这是一个有效的 IPv6 地址，属于百度的公网 IP 段

第三条 ------ AAAA 记录：

www.a.shifen.com: type AAAA, class IN, addr 2409:8c00:6c21:118b:0:ff:b0e8:f003

www.a.shifen.com 的地址为 2409:8c00:6c21:118b:0:ff:b0e8:f003，是 www.a.shifen.com 的另一个 IPv6 地址

因此，其整体解析过程为：

接下来，我们继续来学习 DNS 的层级架构

DNS 层级结构

DNS 采用 树状结构来组织和管理全球的域名，这种结构使得域名解析高效、可扩展、分布式管理：

每一层都由不同的权威 DNS 服务器负责管理，解析时从根开始逐级委托，最终找到目标 IP

我们分别来看每一层

根域（Root Zone）

表示整个 DNS 树的起点 ，由 13 组根服务器 （逻辑上，实际有数百个镜像节点）负责管理，分布在全球，根服务器不直接解析域名，只告诉查询者"去问哪个顶级域服务器"

这 13 组根域名服务器由不同的运营机构负责：

|--------|-------------------------------------------|-----------|-----------------------------|
| 名称 | 运营机构 | 国家/地区 | 备注 |
| A | Verisign | 美国 | 同时运营 .com/.net，全球节点最多 |
| B | USC-ISI | 美国 | 南加州大学信息科学研究所 |
| C | Cogent Communications | 美国 | 商业 ISP |
| D | University of Maryland | 美国 | 马里兰大学 |
| E | NASA | 美国 | 美国宇航局 |
| F | Internet Systems Consortium (ISC) | 美国 | 开源组织，也运营 F-Root 和 BIND 软件 |
| G | Defense Information Systems Agency (DISA) | 美国 | 美国国防部 |
| H | U.S. Army Research Lab | 美国 | 美国陆军实验室 |
| I | Netnod | 瑞典 | 欧洲首个根服务器运营方 |
| J | Verisign | 美国 | 同 A，但独立部署 |
| K | RIPE NCC | 荷兰 | 欧洲 IP 地址注册机构 |
| L | ICANN | 美国 | 互联网名称与数字地址分配机构（管理整个 DNS 体系） |
| M | WIDE Project | 日本 | 亚洲首个根服务器，由日本 WIDE 项目运营 |

每组根服务器都有唯一的 IPv4 和 IPv6 地址 ，虽然大部分在美国，但通过 Anycast 技术，每组都在全球部署了数百个镜像节点

Anycast

任播（Anycast） 是一种网络寻址和路由策略，允许多个地理位置不同的服务器 使用相同的 IP 地址 ，客户端请求会被路由到"最近"或"最优"的一个节点，其核心思想是：一个 IP，多个位置，路由决定谁响应

单播 vs 广播 vs 组播 vs 任播：

|-------------------|------------|------------|----------------------|
| 类型 | 目标数量 | 说明 | 示例 |
| 单播（Unicast） | 1 个 | 一对一通信 | 访问某台特定服务器 |
| 广播（Broadcast） | 所有 | 一对所有（局域网内） | ARP 请求 |
| 组播（Multicast） | 多个（订阅者） | 一对多（特定组） | 视频会议、IPTV |
| 任播（Anycast） | 多个（但只响应一个） | 一对最近（路由决定） | DNS 根服务器、CDN、DDoS 防护 |

客户端无感知，自动连接到最近节点：

多个服务器配置相同的公网 IP 地址

通过 BGP （边界网关协议， 负责在**自治系统（AS）之间交换路由信息）**向互联网宣告该 IP

路由器根据 "最短路径"（AS Path、Metric 等）选择最优节点

客户端请求主动被导向最近/最优节点

例如：访问 8.8.8.8，但不知道背后是哪个数据中心：

客户端 A（北京） → 路由器 → 最近节点：北京服务器（8.8.8.8）

客户端 B（纽约） → 路由器 → 最近节点：纽约服务器（8.8.8.8）

客户端 C（伦敦） → 路由器 → 最近节点：伦敦服务器（8.8.8.8）

所有服务器 IP 都是 8.8.8.8，但物理位置不同

也就是说，每个 "根服务器"（如 a.root-servers.net），在全球有多个物理服务器 ，共享同一个 IP ，当用户访问时，网络自动路由到地理位置最近/延迟最低的节点

那么，为什么是 13 组，不能更多吗？

这是一个历史性设计限制：

DNS 响应最初限制在 512 字节 UDP 包 内（RFC 1035），根服务器的 NS 记录 + 对应的 A 记录必须能装进一个包，因此，计算后，最多能容纳 13 组服务器的信息地址

所以，13 是逻辑名称的限制，而不是技术瓶颈

根域文件包含内容：.com 由哪些服务器负责，.cn 由哪些服务器负责，如：

.com 的 NS 记录：

a.gtld-servers.net.

b.gtld-servers.net.

...

对应的 A 记录：

a.gtld-servers.net. → 192.5.6.30

b.gtld-servers.net. → 192.33.14.30

...

例如：当查询 www.example.com 时，首先需要查询**.com 的域名服务器地址**，向根服务器查询，根服务器就会返回 .com 的顶级域服务器地址

顶级域（Top-Level Domain，TLD）

位于根域之下，如 .com, .org, .net, .cn, .jp, .edu, .gov, .io

由不同的机构管理：

.com：Verisign（美国公司）

.cn：CNNIC（中国互联网络信息中心）

.edu：EDUCAUSE（美国高等教育信息化联盟）

......

TLD 服务器不解析具体网站，只告诉查询者"example.com 的权威服务器是谁"

例如：.com 服务器会返回 example.com 的权威 DNS 服务器（如 ns1.example.com）

二级域（Second-Level Domain，SLD）

用户注册的"主域名"，如：example.com、baidu.com、wikipedia.org

由域名注册商（如 GoDaddy、阿里云、腾讯云）协助用户设置，用户可以在此层级设置权威 DNS 服务器（NS 记录），比如

example.com 的 NS 记录：

ns1.example.com

ns2.example.com

或使用云服务商 DNS：

ns1.alidns.com

dns10.hichina.com

这一层开始，域名所有者可以完全控制解析记录（A、CNAME、MX、TXT 等）

子域/主机（Subdomain/Host）

在二级域下创建的子域名或主机名，如：

www.example.com

mail.example.com

api.example.com

blog.example.com

......

由二级域的权威 DNS 服务器负责解析，可设置 A 记录（IP）、CNAME（别名）、MX（邮件）等

接下来，我们就可以来看 DNS 是如何解析域名的了

DNS 工作流程

我们仍以访问 www.baidu.com 为例

检查本地缓存

浏览器先查看自己是否缓存过该域名的 IP，若已有缓存，则直接使用缓存中的 IP 地址

例如：Chrome 查看 DNS 解析缓存：

若缓存中没有，应用程序会调用系统 DNS 解析接口， 操作系统 DNS 客户端服务（Dnscache）介入，检查本地 DNS 缓存

windows 可通过ipconfig /displaydns 查看本地 DNS 缓存：

此外，系统还会检查本地的 hosts 文件 （如：C:\Windows\System32\drivers\etc\hosts），查看是否有手动绑定的 IP

上述过程中，一旦找到，则直接使用，解析结束

若未找到，则进入下一步 ------ 向 DNS 服务器发起请求

向 DNS 服务器发起请求

DNS 解析器向配置的 本地 DNS 服务器（如运营商 DNS、、公共 DNS 8.8.8.8、114.114.114.114）发送查询请求）

这个 DNS 服务器通常由你的 ISP（网络运营商）自动分配 ，也可以手动设置（如改用 Cloudflare 的 1.1.1.1）

在网络设置中：

自动（DHCP） 表示设备通过 DHCP 协议自动获取 DNS 服务器地址

当设备连接到一个网络（如 Wi-Fi 或有线网络）时，DHCP 服务器会为你分配 IP 地址、子网掩码、网关，以及 **DNS 服务器地址，"自动"**意味着你不需要自己输入 DNS（如 8.8.8.8），系统会从网络中的 DHCP 服务器获取

例如：

设备连接到网络（例如家里的 Wi-Fi）

发起 DHCP 请求（DHCP Discover）

路由器（或 DHCP 服务器）响应（DHCP Offer）（包含内容 IP 地址 、子网掩码 、默认网关 、DNS 服务器地址（如 192.168.1.1 或 114.114.114.114））

设备接收并配置这些参数

本地 DNS 服务器接收到请求后，就会去寻找答案，然后再返回结果

DNS 服务器迭代查询

本地 DNS 服务器开启 "迭代查询"，逐级询问：

1. 问根域名服务器（Root DNS Server）

全球有13 组根服务器（集群，分布在世界各地）

本地 DNS 询问根服务器: " .com 顶级域名的服务器在哪？"

根服务器返回**.com 顶级域名的服务器地址**

2. 问顶级域名服务器（TLD Server）

本地 DNS 继续问 .com 的 TLD 服务器：" baidu.com 的权威 DNS 服务器在哪？"

TLD 服务器返回 baidu.com 的权威域名服务器地址

3. 问权威域名服务器（Authoritative DNS Server）

本地 DNS 最后去问 baidu.com 的权威服务器："请告诉我 www.baidu.com 的IP 是多少？"

权威服务器查找自己的区域文件（zone file），找到 www 的 A 记录（如 39.156.70.239），返回这个 IP 地址给本地 DNS 服务器

4. 本地 DNS 服务器返回结果并缓存

本地 DNS 服务器拿到 www.baidu.com → 39.156.70.239 后，将结果返回给浏览器，同时在本地缓存这个记录（根据TTL 时间，比如 300 秒），下次有人问就直接返回，不用再查

浏览器在拿到 IP 地址 39.156.70.239 后，后续就会继续发起 TCP 连接、发送 HTTP/ HTTPS 请求、服务器响应......

总体流程

详细解析过程

接下来，我们通过**命令行（nslookup）**来模拟一下本地 DNS 服务器后续的解析过程：

查询根域名服务器 → 返回根域名服务器地址

↓
$根服务器\] 查询 .com 服务器→ 返回 .com TLD 服务器地址 ↓ \[.com TLD 服务器\] 查询 baidu.com 权威服务器地址 → 返回 baidu.com 权威服务器地址 ↓ \[权威 DNS 服务器\] 查询 www.baidu.com 服务器地址 → 返回 www.baidu.com 的 IP$

查看 DNS 的根服务器：

启动 nslookup 进入交互模式，使用 set type=ns 设置查询类型为 NS（Name Server）记录，查询根域 .：

其中第一部分 为非权威应答（Non-authoritative answer）： 使用当前 DNS 服务器（192.168.173.176）返回的根服务器列表， 它不是根服务器本身，而是从缓存或上游 DNS 获取了这些信息，所以是 非权威应答（Non-authoritative）

第二部分为 IPv6 地址：显示了部分根服务器的 IPv6 地址（AAAA 记录）

接着，我们选择一个根服务器进行通信，并向该根域名服务器咨询 .com域名服务器的地址：

此时，返回了 .com 的顶级域的权威 DNS 服务器列表 ，因为我们直接查询的是 根服务器，它在根区（Root Zone）中存储了 .com、.org 等顶级域名 NS 记录，它的 NS 查询具有权威性

其中，gtld 即 Generic Top-Level Domain，通用顶级域名，是互联网上最常见、最商业化的域名后缀（如 .com, .org, .app），由全球性机构管理，面向公众开放注册，是 DNS 体系中根服务器直接管辖的核心部分

TLD 类型：

|------------------------|-------------------------------|--------------------|--------------------------------------------------|--------------------------------------------------|
| 类型 | 全称 | 中文 | 示例 | 管理机构 |
| gTLD | Generic Top-Level Domain | 通用顶级域 | .com,.org,.net,.info,.xyz,.app,.ai | ICANN 授权注册局（如 Verisign、Public Interest Registry） |
| ccTLD | Country Code Top-Level Domain | 国家/地区代码顶级域 | .cn（中国）,.jp（日本）,.uk（英国）,.us（美国） | 各国 NIC（如 CNNIC、JPNIC） |
| sTLD | Sponsored Top-Level Domain | 赞助型顶级域（部分归类为 gTLD） | .edu（教育）,.gov（政府）,.mil（军事） | 特定机构管理（如 Educause） |
| Infrastructure TLD | 基础设施顶级域 | 基础设施专用 | .arpa（用于反向 DNS、ENUM 等） | IETF / IANA |

常见 gTLD：

.com：商业（最主流）

.org：非营利组织

.net：网络服务

.app：应用程序

.ai：人工智能

.io：技术/游戏

我们继续从中选择一个服务器进行通信，并咨询 baidu.com 的域名服务器地址：

可以看到，baidu.com 的权威 DNS 服务器有 5个（ns1~ns7），这些域名各自对应着多个 IP 地址，我们仍然随机选择一个，并咨询 www.baidu.com 的IP 地址：

此时我们可以看到一条 CNAME 结果，也就是说 www.baidu.com 是一个别名，实际指向的是 www.a.shifen.com，因此，我们需要得到 www.a.shifen.com 的 IP 地址：

此时返回了a.shifen.com 的 5 个权威 DNS 服务器及其 IP 地址，我们再从中选择一个，查询 www.a.shifen.com 的地址：

此时返回的结果，就是我们需要的 www.a.shifen.com 的 IP 地址

我们再总结一下上述流程：

用户 → 本地 DNS → 根服务器 → .com 权威服务器 → baidu.com 权威服务器 → a.shifen.com 权威服务器 → 最终 IP

DNS 是什么

DNS 报文结构

Header