DNS：互联网的电话簿

本文是《计算机网络学习笔记》系列的第七篇。每次在浏览器里输入 www.google.com 并按下回车，第一件发生的事不是 TCP 握手，不是 TLS 握手，也不是发 HTTP 请求——而是一次 DNS 查询。在拿到目标服务器的 IP 地址之前，后续的一切都无从开始。DNS 就是这个"万事开头"的翻译官。

一、为什么需要 DNS？

IPv4 地址是 32 位整数，人类阅读形式长这样：142.250.185.78；IPv6 更难记：2404:6800:4008:c07::64。记住一个还勉强，记住几十上百个常用网站的 IP，不现实。

DNS（Domain Name System，域名系统）的核心职责只有一件事：

域名  ──────────────────────►  IP 地址
www.google.com  ────────────►  142.250.185.78

但 DNS 不只是一个"翻译词典"，它是一套分布式的、层级化的、高可用的全球查询系统，每天承载着数万亿次查询，支撑着整个互联网的寻址基础设施。

二、UDP + 53 端口：为什么 DNS 不用 TCP？

DNS 运行在 UDP 协议之上，使用 53 端口。

选择 UDP 而非 TCP，原因是：

角度	说明
速度	UDP 无需建立连接，省去 TCP 三次握手的 1.5 个 RTT，查询延迟更低
包大小	绝大多数 DNS 查询和响应都很小（几十到几百字节），完全在一个 UDP 包里放得下
无状态	DNS 本身有请求/响应的匹配机制（标识符字段），不需要 TCP 的有序连接来保证配对
轻量	服务器要同时处理海量查询，UDP 的开销远低于 TCP

DNS 什么时候用 TCP？

当响应数据太大（超过 512 字节，或启用 EDNS 后超过协商的上限），DNS 服务器会在响应中设置一个截断标志（TC=1），告知客户端"太大了，你来用 TCP 重新问一遍"。另外，DNS 区域传输（Zone Transfer，权威服务器之间同步数据）也固定走 TCP。

顺便说一下 UDP 的核心特征：无连接、不可靠、轻量。不建立连接、不保证送达、不保证顺序、不重传。正因如此，UDP 的头部只有 8 个字节（TCP 头部是 20 字节），适合一问一答型的小数据量通信。DNS、DHCP、视频直播等场景都是 UDP 的典型用户。

三、DNS 协议格式

DNS 请求和响应使用完全相同的报文格式，通过标志字段中的一个比特位来区分是查询还是回答。

 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                      标识符 (16)                 |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                    问题数量 (16)                  |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                    回答数量 (16)                  |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                   授权记录数量 (16)               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                   附加记录数量 (16)               |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                      问题区域                     |
 |                      回答区域                     |
 |                      授权区域                     |
 |                      附加区域                     |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

固定头部（12 字节）各字段说明：

字段	含义
标识符（ID）	16 位随机数，用于将响应与请求配对。客户端发出查询时生成，服务端原样回传
QR	1 位，0 = 查询报文，1 = 回答报文
Opcode	4 位，查询类型，0 = 标准查询
AA	权威回答标志，1 = 本响应来自权威服务器
TC	截断标志，1 = 响应太大被截断，请用 TCP 重试
RD	期望递归，1 = 客户端希望服务器代为递归查询
RA	支持递归，1 = 服务器支持递归查询
RCODE	响应状态码，0 = 成功，1 = 格式错误，2 = 服务器失败，3 = 域名不存在（NXDOMAIN）
四个计数字段	依次指示后面四个区域（问题/回答/授权/附加）各有多少条记录

问题区域记录本次查询的内容，包含：

查询的域名（如 www.google.com）
查询类型（如 A、AAAA、MX 等）
查询类（通常为 IN，代表互联网）

四、七种常见记录类型

DNS 里不只有"域名到 IP"的映射，它是一个通用的分布式数据库，存储着各种类型的记录。

类型	全称	作用	典型场景
A	Address	域名 → IPv4 地址	最基础的记录，`example.com` 指向 `93.184.216.34`
AAAA	Quad-A	域名 → IPv6 地址	名字来源：IPv4 是 32 位，IPv6 是 128 位 = 32×4，所以四个 A
CNAME	Canonical Name	域名 → 另一个域名（别名）	`www.example.com` → `example.com`；或指向 CDN 域名
MX	Mail Exchange	域名 → 邮件服务器域名	告诉发件方，给 `@example.com` 发邮件应该投递到哪台服务器
NS	Name Server	指定该域名的权威 DNS 服务器	相当于"我不知道，去问他"；告诉互联网谁负责管理这个域
TXT	Text	存储任意文本	SPF 反垃圾邮件声明；域名所有权验证（Google / 阿里云等）
PTR	Pointer	IP 地址 → 域名（反向解析）	邮件服务器反垃圾检测；服务器日志里显示域名而非 IP

几个容易混淆的点：

CNAME 不能直接指向 IP，只能指向另一个域名，最终还是要有一条 A/AAAA 记录落地；
MX 记录的值是域名，不是 IP，还需要有对应的 A 记录解析出邮件服务器的 IP；
NS 记录决定了"谁说了算"——如果你在域名注册商那里修改 NS 指向，就是把这个域名的解析权交给了新的 DNS 服务商；
TXT 记录是当今互联网的"多功能工具箱"：v=spf1 include:_spf.google.com ~all 这样的 SPF 记录、google-site-verification=xxx 这样的验证记录，都存在 TXT 里。

五、三级层级结构

全球 DNS 系统是一棵倒置的树，从根往下分为三级：

                         . （根）
                         |
        ┌────────────────┼────────────────┐
       .com            .cn             .org   ← TLD（顶级域）
        |
  ┌─────┴──────┐
google.com   baidu.com                       ← 权威 DNS
    |
www.google.com                               ← 具体主机

根 DNS 服务器

全球共 13 个逻辑根服务器（a.root-servers.net 到 m.root-servers.net），但背后有 1000 多台物理服务器分布在各地（通过任播 Anycast 技术，用户会就近访问最近的副本）；
根服务器不知道具体域名的 IP，只知道各 TLD 服务器的地址，负责把查询引导到正确的 TLD。

TLD DNS 服务器

顶级域服务器管理 .com、.net、.org、.cn 等顶级域。例如 .com 的 TLD 服务器知道所有 xxx.com 域名的权威 DNS 服务器在哪里。

权威 DNS 服务器

权威服务器才是真正存放 DNS 记录的地方。每个组织或公司都有自己的权威 DNS 服务器（或委托给 DNS 服务商管理），它能直接回答"google.com 的 IP 是多少"这类问题。

六、一次完整的解析流程

输入 www.google.com 后，DNS 解析会经历以下步骤：

浏览器/应用
    ↓ ① 检查本地缓存（浏览器缓存、操作系统缓存）
    ↓   命中 → 直接返回，结束
    ↓   未命中 ↓
操作系统
    ↓ ② 检查 /etc/hosts（hosts 文件优先级最高）
    ↓   命中 → 直接返回，结束
    ↓   未命中 ↓
本地递归解析器（运营商或公共 DNS，如 8.8.8.8）
    ↓ ③ 检查自己的缓存
    ↓   命中 → 直接返回（大多数查询在这里结束）
    ↓   未命中 ↓
根 DNS 服务器
    ↓ ④ 问：www.google.com 在哪？
    ↓ ← 答：我不知道，但 .com 的 TLD 服务器在 a.gtld-servers.net
TLD DNS 服务器（.com）
    ↓ ⑤ 问：www.google.com 在哪？
    ↓ ← 答：我不知道，但 google.com 的权威 DNS 在 ns1.google.com
权威 DNS 服务器（Google）
    ↓ ⑥ 问：www.google.com 的 A 记录是什么？
    ↓ ← 答：142.250.185.78
本地递归解析器
    ↓ ⑦ 缓存结果（根据 TTL），返回给客户端
浏览器
    ✓ 拿到 IP，开始 TCP 连接

两个关键概念：

递归查询：客户端把查询"外包"给递归解析器，解析器代替客户端跑完整个链路，最后把结果返回；
迭代查询：递归解析器向每一级 DNS 服务器查询，每次得到"去问下一个"的指引，自己负责追踪到底。上图中，递归解析器和各级 DNS 之间走的就是迭代查询。

TTL（Time To Live）：每条 DNS 记录都有 TTL 值，单位秒，表示缓存可以保存多久。TTL=300 意味着最多 5 分钟后必须重新查询。这就是为什么修改 DNS 记录后需要等一段时间才能在全球生效——全球各地的缓存需要等各自的 TTL 到期才会刷新。

七、常用公共 DNS

不用运营商默认的 DNS，可以获得更快的解析速度和更高的安全性：

# 国内推荐
223.5.5.5        # 阿里 DNS（AliDNS）——速度快，无广告劫持，支持 DoH/DoT
119.29.29.29     # 腾讯 DNS（DNSPod）——对腾讯系产品有加速，被腾讯收购
114.114.114.114  # 114 DNS——老牌稳定，但部分地区有广告劫持，不推荐

# 国际推荐
8.8.8.8          # Google Public DNS——稳定可靠，解析速度全球领先
1.1.1.1          # Cloudflare DNS——号称全球最快，主打隐私保护（不记录日志）

如何切换 DNS？

Windows：网络适配器属性 → IPv4 → 首选 DNS 服务器
Linux/macOS：编辑 /etc/resolv.conf，或在网络管理器中配置
路由器：在路由器的 WAN/LAN 设置里改 DNS，全局生效，家里所有设备都走新 DNS

八、DNS 的安全问题

DNS 劫持（DNS Hijacking）

运营商或中间人篡改 DNS 响应，把正确的 IP 替换成另一个地址（通常是广告页面或仿冒网站）。国内部分运营商会把解析失败的域名（NXDOMAIN）重定向到自己的广告页。

表现：访问一个不存在的域名，却跳转到了充满广告的"搜索页"。

解法：换一个不劫持的 DNS，或使用 DoH/DoT。

DNS 污染（DNS Spoofing / Poisoning）

GFW 对特定域名（如 google.com）的 DNS 查询注入伪造的响应，返回一个错误的 IP，让你根本连接不上目标服务器。

表现：nslookup google.com 返回一个不属于 Google 的 IP。

解法：DoH（通过 HTTPS 加密 DNS 查询）。

DNS over HTTPS（DoH）

传统 DNS 是明文 UDP，查询内容对所有中间节点完全可见，运营商可以看到你访问了哪些域名，也可以伪造响应。

DoH 把 DNS 查询包裹在 HTTPS 里发送：

传统 DNS:
  客户端 ──UDP 53──► DNS 服务器（明文，中间节点可见可改）

DoH:
  客户端 ──HTTPS 443──► DoH 服务器（加密，中间节点看不到也改不了）

DoH 使用标准的 HTTPS 443 端口，流量与普通网页浏览混在一起，极难被识别和干扰。

启用 DoH：

Chrome：设置 → 隐私和安全 → 安全 DNS → 选择自定义，填入 https://dns.alidns.com/dns-query（阿里）或 https://1.1.1.1/dns-query（Cloudflare）
Firefox：网络设置 → 启用基于 HTTPS 的 DNS

九、调试工具

nslookup

Windows/Linux/macOS 均内置，最常用的 DNS 调试命令：

# 查询域名的 A 记录（默认）
nslookup www.baidu.com

# 查询指定类型的记录
nslookup -type=MX gmail.com
nslookup -type=TXT github.com
nslookup -type=NS google.com

# 指定使用特定的 DNS 服务器查询（绕过系统默认 DNS）
nslookup www.google.com 8.8.8.8

dig（Linux/macOS，更专业）

# 完整查询，显示所有细节
dig www.google.com

# 只显示 IP（简洁输出）
dig +short www.google.com

# 查询 MX 记录
dig MX gmail.com

# 追踪完整的解析链路（从根服务器开始）
dig +trace www.google.com

# 反向解析（IP → 域名）
dig -x 8.8.8.8

dig +trace 是学习 DNS 解析过程的神器，它会显示从根服务器开始的每一步迭代查询，正好对应第六节"完整解析流程"中的每个步骤。

总结

要点	内容
协议	运行在 UDP 53 端口之上（响应过大时回退 TCP）
功能	域名 ↔ IP 地址的双向翻译；存储 A/AAAA/CNAME/MX/NS/TXT/PTR 等多种记录
架构	三级层级：根（13个）→ TLD（.com/.cn）→ 权威服务器
缓存	本地缓存 → OS 缓存 → 递归解析器缓存 → 权威服务器，逐级命中
安全	明文存在劫持和污染风险，DoH 通过 HTTPS 加密解决
调试	nslookup（通用）、dig（专业，支持 +trace 追踪全链路）

DNS 是互联网基础设施中最"隐形"却最重要的一环——它每天默默地运转着，但一旦出问题（解析错误、被劫持、TTL 设置不当导致迁移慢），后果会立刻影响到每一个用户。理解 DNS，是每一个和网络打交道的开发者的必修课。

本系列前六篇：
· 第一篇：《TCP 协议格式详解》
· 第二篇：《TCP 三次握手与四次挥手》
· 第三篇：《TCP 可靠数据传输》
· 第四篇：《TCP 流量控制与拥塞控制》
· 第5篇：《TLS：HTTPS 背后的加密握手》
· 第6篇：《HTTP 协议进化史》

*参考资料：《计算机网络：自顶向下方法》