🧭 DNS 域名系统：互联网的分布式解析引擎

🌱 创建: 2026/04/01 ⏱️ 更新: 2026/05/22

**DNS(Domain Name System 域名系统)**是互联网的基石服务之一，其核心规范最初定义于 RFC 1034 和 RFC 1035。作为一种运行在应用层（OSI 第七层）的分布式数据库系统，DNS 的主要职责是将人类可读的完全限定域名（FQDN，如 www.example.com）映射为机器可路由的 IP 地址（如 192.0.2.1 或 2001:db8::1）。

本指南将全面拆解 DNS 的命名空间拓扑、查询生命周期以及底层传输机制。

1. 倒置的树状拓扑：DNS 命名空间

DNS 并没有一个中心化的超级服务器来存储全球所有的域名映射。相反，它采用了一种高度可扩展的、倒置的树状层级架构。

根域（Root Domain，.）：位于树的绝对顶端。全球共有 13 组根逻辑服务器（由 A 到 M 命名，通过任播 Anycast 技术分布在世界各地）。它们不记录具体的 IP，只负责指引方向。
顶级域（Top-Level Domain, TLD）：由根域指向。分为通用顶级域（gTLD，如 .com, .net, .org）和国家/地区代码顶级域（ccTLD，如 .cn, .uk）。
二级域（Second-Level Domain, SLD）：由 TLD 指向。这是企业或个人向域名注册商实际购买的部分（如 example.com）。
子域/主机名（Subdomain / Hostname）：由域名的所有者在自己的权威 DNS 服务器上自行划分和配置（如 www.example.com 或 api.example.com）。

规范说明：在严谨的协议层面，一个绝对域名（FQDN）的末尾必须带有一个点号（代表根域），例如 www.example.com.。日常使用中操作系统会自动补全这个隐藏的根节点。

2. 解析生命周期：递归与迭代查询

当客户端尝试访问一个域名时，DNS 的解析过程是一场精密的网络接力赛。整个过程涉及两种截然不同的查询模式：递归查询（Recursive Query）和迭代查询（Iterative Query）。

2.1 客户端侧：存根解析器与缓存

当应用程序（如浏览器）发起请求时，操作系统的 存根解析器（Stub Resolver） 会首先介入：

检查本地 hosts 文件（硬编码的最高优先级映射）。
检查操作系统自身的 DNS 缓存。
如果未命中，则向系统配置的 本地 DNS 服务器（Local DNS / 递归解析器） 发起递归查询。
- 递归查询的含义是：“我不管你用什么方法，你必须直接给我最终的 IP 地址结果，或者告诉我解析失败。”

2.2 服务器侧：迭代查询的逐级寻址

本地 DNS 服务器（通常由 ISP 运营商提供，或为 8.8.8.8 等公共 DNS）接到任务后，如果自身缓存也没有记录，就会代替客户端向互联网发起迭代查询：

询问根服务器：本地 DNS 向根服务器（.）询问 www.example.com 的 IP。根服务器回答：“我不知道，但你应该去问 .com 的 TLD 服务器，这是它的 IP。”
询问 TLD 服务器：本地 DNS 向 .com 服务器询问。TLD 服务器回答：“我不知道具体的 IP，但这个域名的权威名称服务器（Authoritative Nameserver） 是 ns1.example.com，你去问它。”
询问权威服务器：本地 DNS 向该域名的权威服务器发起最终查询。权威服务器查找自己的区域文件（Zone File），并返回 www 记录对应的真实 IP 地址。
返回并缓存：本地 DNS 服务器将最终的 IP 地址返回给客户端操作系统的存根解析器，并将该记录缓存在自己的内存中，缓存保留时间由记录的 TTL（Time to Live，生存时间） 决定。

3. 核心资源记录类型 (Resource Records, RR)

DNS 区域文件（Zone File）由多条资源记录组成。除了最常见的 IPv4 映射，DNS 还可以承载多种类型的元数据。

admin@tech-fortress:~# cat /var/named/example.com.zone

记录类型 (Type)	协议定义	核心功能与应用场景	典型值示例
`A`	RFC 1035	IPv4 地址记录。将域名直接映射到一个 32 位的 IPv4 地址。	`192.0.2.1`
`AAAA`	RFC 3596	IPv6 地址记录。将域名映射到一个 128 位的 IPv6 地址。	`2001:db8::1`
`CNAME`	RFC 1035	规范名称记录（别名）。将一个域名指向另一个域名，而非直接指向 IP。常用于 CDN 接入或多个子服务复用同一主机。	`lb.cdn.example.net.`
`MX`	RFC 1035	邮件交换记录。指定负责接收该域名电子邮件的服务器。附带优先级数字，数字越小优先级越高。	`10 mail.example.com.`
`TXT`	RFC 1035	文本记录。允许向 DNS 附加任意文本。现代主要用于域名所有权验证（如 SSL 证书申请）、以及防垃圾邮件机制（SPF, DKIM, DMARC）。	`"v=spf1 include:_spf.example.com ~all"`
`NS`	RFC 1035	名称服务器记录。将某个 DNS 区域（Zone）委派给指定的权威 DNS 服务器进行解析。	`ns1.example.com.`
`PTR`	RFC 1035	指针记录（反向解析）。根据 IP 地址反查对应的域名。通常配置在特定的 `in-addr.arpa` 区域中，常用于邮件服务器的信誉验证。	`mail.example.com.`

工程陷阱：CNAME 记录具有排他性。如果一个主机名（如 www.example.com）被配置了 CNAME，那么该主机名绝不能再配置其他类型的记录（如 MX 或 TXT），否则会导致解析严重冲突。唯一的例外是 DNSSEC 相关的签名记录。

4. 底层传输机制：UDP 53 与 TCP 53

DNS 协议被分配了著名的熟知端口（Well-known Port）—— 端口 53。独特的是，DNS 同时依赖 UDP 和 TCP 协议，在不同场景下进行切换。

4.1 UDP/53 (无连接的快速查询)

在绝大多数情况下，客户端的常规 DNS 解析请求（如查询一个 A 记录）都是通过 UDP 端口 53 发送的。

原因：UDP 无需建立三次握手，延迟极低，消耗资源极小，非常适合承载体量细微的 DNS 请求报文。
限制：传统的 DNS over UDP 报文大小被硬性限制在 512 字节以内。如果权威服务器的响应包超过 512 字节（例如包含大量 IP 轮询的记录或 DNSSEC 签名），响应报文将被截断，并设置 TC（Truncated，截断）标志位。

4.2 TCP/53 (面向连接的可靠传输)

当协议栈遇到以下两种情况时，会自动切换或强制使用 TCP 端口 53：

响应被截断：如果客户端收到带有 TC 标志的 UDP 响应包，存根解析器会立即使用 TCP 重新发起相同的查询，以获取完整数据。
区域传输（Zone Transfer, AXFR/IXFR）：主域名服务器向辅助域名服务器同步包含成百上千条记录的完整 Zone File 时，必须使用可靠的 TCP 流进行大体积传输。

5. 现代演进：加密 DNS 的崛起

传统的 DNS（UDP/53 和 TCP/53）采用明文传输，这导致用户的浏览记录（查询的域名）极其容易被中间人（如 ISP 或公共 Wi-Fi 提供者）监听、劫持和篡改。

为了解决最后一英里的隐私与安全问题，现代网络架构引入了加密 DNS 协议：

DoT (DNS over TLS, RFC 7858)：使用独立的 TCP 端口 853，在标准的 TLS 加密隧道内封装 DNS 报文。
DoH (DNS over HTTPS, RFC 8484)：将 DNS 查询封装为 HTTPS 请求（TCP/443），与正常的网页流量混在一起，极难被防火墙特征库精准封杀，是目前主流浏览器默认采用的安全解析方案。

📚 权威规范参考 (RFCs)

RFC 1034 / RFC 1035: Domain Names - Concepts and Facilities / Implementation and Specification (核心基石标准)
RFC 2136: Dynamic Updates in the Domain Name System (DDNS)
RFC 7858: Specification for DNS over Transport Layer Security (DoT)
RFC 8484: DNS Queries over HTTPS (DoH)