DNS 技术详解
目录
- [DNS 是什么](#DNS 是什么)
- [为什么需要 DNS](#为什么需要 DNS)
- [DNS 基本工作原理](#DNS 基本工作原理)
- [DNS 层次结构](#DNS 层次结构)
- [NS 记录与根域名服务器的区别](#NS 记录与根域名服务器的区别)
- 根域名服务器的作用与访问时机
- [Resolver 与 NS 的角色分工](#Resolver 与 NS 的角色分工)
- 递归解析与迭代解析
- 国内递归解析器相关监管
- [常见 DNS 记录类型](#常见 DNS 记录类型)
- [DNS 报文格式与协议细节](#DNS 报文格式与协议细节)
- [DNS 解析完整流程（含缓存）](#DNS 解析完整流程（含缓存）)
- 常见问题与排查
- 优化策略
- 安全与演进
- 常用命令速查
- 小结
一、DNS 是什么
DNS（Domain Name System，域名系统） 是互联网的一项基础服务，用来把人类易记的域名 （如 www.example.com）转换成机器可识别的 IP 地址 （如 93.184.216.34）。它相当于互联网的「电话簿」。
在协议栈中的位置 ：DNS 通常运行在 UDP 53 端口（也可用 TCP 53，如响应超过 512 字节或区域传输时）。
应用层
DNS 客户端/服务
UDP 53 / TCP 53
IP
二、为什么需要 DNS
| 原因 | 说明 |
|---|---|
| IP 难记 | 域名更直观，如 example.com 比 93.184.216.34 易记。 |
| 底层依赖 IP | 网络通信最终需要 IP，必须有「域名 → IP」的映射机制。 |
| 灵活管理 | 换服务器时只改 DNS 记录即可，无需通知所有用户。 |
| 负载与高可用 | 同一域名可对应多条 A 记录（多 IP），实现轮询或就近调度。 |
三、DNS 基本工作原理
- 客户端查询 ：浏览器访问
www.example.com时，先查本地缓存（操作系统、浏览器）。 - 递归解析 ：若本地没有，向配置的递归 DNS 服务器（如运营商或公共 DNS：8.8.8.8、1.1.1.1）发起请求。
- 迭代查询 ：递归服务器依次向 根 DNS → 顶级域（TLD，如 .com）→ 权威 DNS 服务器查询，最终获得 IP。
- 返回结果：递归服务器将 IP 返回给客户端，并缓存一段时间（TTL）。
查询路径概览：
权威NS TLD服务器 根服务器 递归Resolver 客户端 权威NS TLD服务器 根服务器 递归Resolver 客户端 查询 www.example.com .com 的 TLD 是谁 TLD 列表 example.com 的权威是谁 NS 记录 www.example.com 的 IP A 记录 返回 IP 并缓存
四、DNS 层次结构
| 层级 | 说明 | 示例 |
|---|---|---|
| 根域名服务器（Root） | 全球 13 组标识符，背后有多台镜像，处理顶级域查询。 | a.root-servers.net ~ m.root-servers.net |
| 顶级域服务器（TLD） | 管理某类顶级域。 | .com、.cn、.org 等 |
| 权威域名服务器 | 管理具体域名的记录。 | example.com 的 A、MX、NS 等 |
域名结构（层次化树，从右到左）：
text
. ← 根域
└── com ← 顶级域（TLD）
└── example ← 二级域
└── www ← 子域层次与查询流向：
迭代链
递归层
客户端
递归查询
返回 IP
浏览器/应用
递归 Resolver
根服务器
TLD 服务器
权威 NS
五、NS 记录与根域名服务器的区别
5.1 易混淆点
- NS（Name Server）记录 ：是某个域名在权威 DNS 上的配置，用来告诉查询者「这个域名由哪些 DNS 服务器负责解析」。例如
example.com的 NS 可能是ns1.example.com、ns2.example.com，数量由域名管理者决定，可多台、多地分布。 - 根域名服务器（Root Server） ：全球只有 13 个不同的根服务器标识符 （a.root-servers.net 到 m.root-servers.net），每个背后有多台物理服务器（镜像），总数几百台；只负责解析顶级域（如 .com、.cn），不直接解析普通网站域名。
5.2 对比小结
| 项目 | NS 记录 | 根域名服务器 |
|---|---|---|
| 是什么 | 域名的权威 DNS 服务器列表（配置项） | 全球固定的根层 DNS 服务器 |
| 数量 | 每个域名可有多个 NS（推荐至少 2 个） | 13 组标识符，背后多台镜像 |
| 作用 | 回答「该域名的 A、MX 等记录是什么」 | 回答「某 TLD（如 .com）的服务器是谁」 |
六、根域名服务器的作用与访问时机
6.1 根服务器做什么
根域名服务器的作用是：告诉递归 DNS 服务器「某顶级域（TLD）的权威服务器在哪里」。它只管第一层------顶级域，如 .com、.cn、.org。
示例 ：查 www.example.com 时，递归服务器不知道 example.com 在哪，就先问根：「.com 的权威服务器是谁？」根回答：「去问这些 .com 的 TLD 服务器（如 a.gtld-servers.net）。」
6.2 每次 DNS 请求都会发给根吗？
不会。
- 递归 DNS 有缓存：若之前已查过 .com 的 TLD 服务器地址，会直接用缓存，不再问根；TTL 没过期就不会重新查根。
- 只有第一次或缓存失效时才需要根：第一次查某个新顶级域时才会问根；查已知顶级域时，直接跳到 TLD 服务器。
6.3 完整查询流程（无缓存时，以 www.example.com 为例）
| 步骤 | 谁 → 谁 | 内容 |
|---|---|---|
| 1 | 递归服务器 → 根服务器 | 「.com 的 TLD 服务器是谁？」 |
| 2 | 根服务器 → 递归服务器 | 「这是 .com 的 TLD 服务器列表。」 |
| 3 | 递归服务器 → TLD 服务器 | 「example.com 的权威服务器是谁？」 |
| 4 | TLD 服务器 → 递归服务器 | 「这是 example.com 的 NS 记录。」 |
| 5 | 递归服务器 → 权威服务器 | 「www.example.com 的 IP 是多少？」 |
| 6 | 权威服务器 → 递归服务器 | 「IP 是 93.184.216.34。」 |
| 7 | 递归服务器 → 客户端 | 返回 IP，并缓存结果。 |
下次再查 www.example.com（在 TTL 内），递归服务器直接从缓存返回 IP，不会再去根服务器。
七、Resolver 与 NS 的角色分工
7.1 角色
| 角色 | 说明 |
|---|---|
| NS（Name Server） | 权威 DNS 服务器，保存该域名的各种记录（A、AAAA、MX 等）。只负责回答「这个域名对应的数据是什么」，不负责替用户跑完整查询链。 |
| Resolver（递归 DNS / 解析器） | 用户设备配置的 DNS（如运营商 DNS、8.8.8.8、1.1.1.1）。替用户完成完整查询：根 → TLD → 权威 NS，并把最终结果返回给用户。 |
7.2 请求流向
- 你的设备 → 只把请求发给 Resolver（如 8.8.8.8），不会直接发给域名的 NS。
- Resolver 先查自己的缓存；若无缓存或已过期，再发起递归/迭代查询（根 → TLD → 权威 NS）。
- Resolver 把结果返回给设备，并缓存。
7.3 这样设计的原因
- 用户侧简化：只需配置一个 Resolver 地址。
- 性能：Resolver 缓存大量记录，减少重复查询。
- 安全与管理：Resolver 可做过滤、拦截、加密（DoH/DoT）等。
八、递归解析与迭代解析
| 概念 | 说明 |
|---|---|
| 递归解析（Recursive） | Resolver 代表客户端，自己完成从根到权威的整条查询链，把最终结果返回给客户端。 |
| 迭代解析（Iterative） | 服务器收到请求后若不知道答案，只返回「下一个该问谁」的地址，由请求方自己去问。根服务器和 TLD 服务器通常只做迭代。 |
关系 ：对用户来说，用的是递归服务 （只问 Resolver）；Resolver 在后台对根、TLD、权威发起的是迭代查询。监管关注的是「是否对外提供开放的公共递归解析服务」，而不是服务器内部用迭代还是递归算法。
递归 vs 迭代示意：
迭代模式
问根
返回 TLD 地址
问 TLD
返回权威地址
问权威
返回 IP
客户端
根
TLD
权威
递归模式
一次请求
内部多轮
最终结果
客户端
Resolver
九、国内递归解析器相关监管
9.1 禁止：对外提供公共递归解析服务
- 在公网开放 53 端口、允许任意用户进行递归查询的 DNS 服务，在国内不被允许。
- 监管要求：根据工信部规定，只有获得相应许可的机构才能运营面向公众的递归解析系统。
- 行业标准：如《域名递归解析服务管理系统技术要求》（YD/T 6169‑2024）等。
核心：不能私自搭建对全网开放的公共 Resolver。
9.2 允许：内部使用与权威解析
| 场景 | 说明 |
|---|---|
| 内部递归解析器 | 在企业、校园或家庭内网部署 DNS，仅为内网设备提供解析，53 端口不对外。合规且常见。 |
| 权威 DNS 服务器 | 只管理自己的域名，发布 A、MX 等记录，属于「权威解析」而非「递归解析」。可对外提供解析服务，需遵守域名注册与备案规定。 |
9.3 实践建议
- 个人/家庭：直接使用运营商、阿里云、腾讯云或 114.114.114.114 等公共 DNS 即可。
- 企业内网 ：可在内网部署 DNS 为内部提供递归解析，并确保 53 端口不对公网开放 ；对外提供域名解析应使用权威 DNS，并按规定备案。
- 对外提供公共 DNS 服务：属增值电信业务，需向工信部/通管局申请相应牌照并满足相关标准。
十、常见 DNS 记录类型
10.1 类型速查表
| 记录类型 | 数值 | 说明 |
|---|---|---|
| A | 1 | 域名 → IPv4 地址（32 位） |
| AAAA | 28 | 域名 → IPv6 地址（128 位） |
| CNAME | 5 | 别名，指向另一个域名（RDATA 为域名） |
| MX | 15 | 邮件服务器地址（优先级 + 域名） |
| NS | 2 | 指定该域名的权威 DNS 服务器 |
| TXT | 16 | 文本信息，常用于验证、SPF、DKIM 等 |
| PTR | 12 | 反向解析，IP → 域名（多用于 in-addr.arpa） |
| SOA | 6 | 授权起始，域名的权威信息（序列号、刷新/重试/过期、MNAME 等） |
| SRV | 33 | 服务记录（优先级、权重、端口、目标域名） |
10.2 常见 QTYPE 与 QCLASS 数值（协议中用）
| 名称 | 数值 | 说明 |
|---|---|---|
| A | 1 | IPv4 地址 |
| NS | 2 | 名称服务器 |
| CNAME | 5 | 规范名 |
| SOA | 6 | 授权起始 |
| PTR | 12 | 指针 |
| MX | 15 | 邮件交换 |
| TXT | 16 | 文本 |
| AAAA | 28 | IPv6 地址 |
| SRV | 33 | 服务 |
| CLASS IN | 1 | Internet |
| CLASS ANY | 255 | 任意类（查询时表示「所有」） |
十一、DNS 报文格式与协议细节
11.1 整体结构
DNS 报文（基于 RFC 1035）分为五部分，请求与响应使用同一格式，通过 Header 的 QR 区分：
text
+---------------------+
| Header | 固定 12 字节
+---------------------+
| Question | 查询：QNAME + QTYPE + QCLASS（可多条）
+---------------------+
| Answer | 回答的资源记录（RR）
+---------------------+
| Authority | 权威 RR（如 NS 记录）
+---------------------+
| Additional | 附加 RR（如 A 记录伴随 NS）
+---------------------+传输 ：默认 UDP 53 ；当响应超过 512 字节 或需要区域传输（AXFR）时使用 TCP 53 。UDP 响应若被截断会置 TC=1，客户端应改用 TCP 重试。
11.2 Header（固定 12 字节）
字节与比特布局（大端序）：
text
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| 字段 | 长度（bit） | 说明 |
|---|---|---|
| ID | 16 | 事务 ID，请求与响应一致，用于匹配 |
| QR | 1 | 0=查询，1=响应 |
| Opcode | 4 | 0=标准查询，1=反向，2=服务器状态 |
| AA | 1 | 权威回答（仅响应中有效） |
| TC | 1 | 截断：响应超 512 字节时置 1，建议用 TCP 重试 |
| RD | 1 | 期望递归（客户端设 1 表示希望 Resolver 递归查） |
| RA | 1 | 递归可用（响应中表示服务器支持递归） |
| Z | 3 | 保留，须为 0 |
| RCODE | 4 | 响应码，见下表 |
| QDCOUNT | 16 | Question 条数 |
| ANCOUNT | 16 | Answer 条数 |
| NSCOUNT | 16 | Authority 条数 |
| ARCOUNT | 16 | Additional 条数 |
RCODE 常用值：
| RCODE | 值 | 含义 |
|---|---|---|
| NOERROR | 0 | 无错误 |
| FORMERR | 1 | 格式错误 |
| SERVFAIL | 2 | 服务器失败 |
| NXDOMAIN | 3 | 域名不存在 |
| NOTIMP | 4 | 未实现 |
| REFUSED | 5 | 拒绝 |
11.3 Question 部分
每条 Question 包含：
| 字段 | 长度 | 说明 |
|---|---|---|
| QNAME | 可变 | 域名，见下方「域名编码」 |
| QTYPE | 16 bit | 查询类型（1=A, 28=AAAA, 15=MX...） |
| QCLASS | 16 bit | 查询类（1=IN, 255=ANY） |
域名编码（标签序列）：
- 域名按标签 分割（如
www、example、com）。 - 每个标签前有 1 字节 表示该标签长度（0--63），后跟标签字符（ASCII）。
- 以 0 字节 结束（表示根，即空标签）。
示例 ：www.example.com 的编码（十六进制）：
text
03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00
│ w w w │ e x a m p l e │ c o m 结束
长度 3 长度 7 长度 3即：[3]www[7]example[3]com[0]。
压缩指针（用于响应中的 NAME 等）：
- 为节省空间，响应里可引用前面已出现的域名。
- 指针 ：2 字节，高 2 位为 11 ，低 14 位为从报文起始处的字节偏移（指向该位置之前的域名或子串）。
- 例如
0xC0 0x0C：表示从偏移 12 字节处开始解析域名（通常指向 Question 的 QNAME）。
11.4 Resource Record（RR）格式
Answer、Authority、Additional 中的每条记录格式一致：
text
NAME (可变) 域名，可用压缩指针
TYPE (16 bit) 记录类型
CLASS (16 bit) 通常 1 = IN
TTL (32 bit) 生存时间（秒）
RDLENGTH (16 bit) RDATA 的字节数
RDATA (可变) 根据 TYPE 解析常见 TYPE 的 RDATA 格式：
| TYPE | RDATA 含义 |
|---|---|
| A | 4 字节 IPv4 地址 |
| AAAA | 16 字节 IPv6 地址 |
| CNAME | 域名（标签序列或压缩指针） |
| NS | 域名（该域的权威服务器） |
| MX | 2 字节优先级 + 域名（邮件服务器） |
| TXT | 每段前 1 字节长度 + 文本（可多段） |
| PTR | 域名（反向解析结果） |
| SOA | MNAME（主 NS）+ RNAME（管理员邮箱）+ 序列号 + 刷新/重试/过期/最小 TTL（各 32 bit） |
11.5 查询与响应示例（概念）
查询报文（仅 Header + Question）：
text
Header:
ID=0x1234, QR=0, Opcode=0, RD=1, RA=0, RCODE=0
QDCOUNT=1, ANCOUNT=0, NSCOUNT=0, ARCOUNT=0
Question:
QNAME=www.example.com (03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00)
QTYPE=1 (A), QCLASS=1 (IN)响应报文（含 Answer）：
text
Header:
ID=0x1234, QR=1, AA=1, RA=1, RCODE=0
QDCOUNT=1, ANCOUNT=1, NSCOUNT=0, ARCOUNT=0
Question: (同上)
Answer:
NAME=www.example.com (或压缩指针 0xC0 0x0C)
TYPE=1 (A), CLASS=1 (IN), TTL=300
RDLENGTH=4, RDATA=93.184.216.34 (5D B8 D8 22)11.6 协议要点小结
| 项目 | 说明 |
|---|---|
| 字节序 | 多字节字段均为大端序（网络字节序） |
| UDP 长度 | 默认 UDP 响应 ≤ 512 字节，超则 TC=1，改用 TCP |
| 端口 | 53（UDP/TCP） |
| 规范 | RFC 1034（概念）、RFC 1035（报文格式） |
十二、DNS 解析完整流程（含缓存）
- 本地缓存 ：浏览器缓存 → 操作系统缓存 → hosts 文件。
- 本地 DNS Resolver ：若无缓存，向配置的 Resolver 发起递归查询。
- 迭代过程（由 Resolver 完成）：Resolver → 根（取 TLD 地址）→ TLD（取权威 NS）→ 权威（取最终 IP）。
- 返回与缓存：Resolver 将 IP 返回给用户，并按 TTL 缓存。
注意：用户只和 Resolver 交互，不直接访问根或权威服务器。
带缓存的解析流程：
命中
未命中
命中
未命中
命中
未命中
命中
未命中
请求域名
浏览器缓存?
返回 IP
系统缓存?
hosts 文件?
请求 Resolver
Resolver 缓存?
根 → TLD → 权威
Resolver 缓存并返回
十三、常见问题与排查
| 问题 | 现象 | 排查建议 |
|---|---|---|
| 解析延迟/超时 | 打开网页前半段卡顿 | 用 dig www.xxx.com @不同DNS 对比时延；尝试公共 DNS（如 223.5.5.5、119.29.29.29）。 |
| 解析失败/域名不存在 | 无法打开或报错 | 检查域名配置、NS 记录、权威服务器是否正常。 |
| 域名劫持/污染 | 访问正常域名跳到异常站点 | 用 nslookup/dig 对比运营商 DNS 与公共 DNS 返回的 IP 是否一致。 |
| 缓存异常 | 修改 A 记录后部分地区仍为旧 IP | 各地递归服务器 TTL 未过期仍用旧记录；可提前降低 TTL 或等待过期。 |
十四、优化策略
| 策略 | 说明 |
|---|---|
| 合理配置 DNS | 选择稳定、快速、安全的公共 DNS 或运营商 DNS。 |
| TTL 策略 | 主站/重要服务：TTL 适中（如 300--600s）；静态资源/大促前可先调高 TTL，活动后再改回。 |
| 减少 CNAME 链 | 避免 A→B→C→... 过长嵌套；重要入口尽量用 A/AAAA 直指目标。 |
| 结合 CDN | 利用 CDN 的分布式 DNS 节点做就近访问与智能调度；配合预热、刷新 DNS 缓存、调度策略使用。 |
常见公共 DNS 举例（仅供参考，以实际可用为准）：
| 服务商 | IPv4 | 说明 |
|---|---|---|
| 阿里 | 223.5.5.5 / 223.6.6.6 | 国内常用 |
| 114 | 114.114.114.114 | 国内常用 |
| 腾讯 | 119.29.29.29 | 国内常用 |
| 8.8.8.8 / 8.8.4.4 | 国际 | |
| Cloudflare | 1.1.1.1 / 1.0.0.1 | 国际，支持 DoH |
十五、安全与演进
| 方向 | 说明 |
|---|---|
| 传统 DNS | 基于 UDP 53 的查询/响应为明文，易被窃听、劫持、篡改。 |
| DoH（DNS over HTTPS） | DNS 查询通过 HTTPS 发送（如 443 端口），与网页流量混合，可防运营商窥探。 |
| DoT（DNS over TLS） | DNS 查询走 TLS 加密（通常 853 端口），端到端加密。 |
| DNSSEC | 对 DNS 记录做数字签名，验证应答未被篡改（不加密，只保证真实性）。 |
| 趋势 | 更多浏览器与应用内置加密 DNS；递归 DNS 作为网络入口的安全节点越来越重要。 |
十六、常用命令速查
| 目的 | 命令示例 |
|---|---|
| 查询 A 记录 | dig example.com 或 dig example.com A |
| 指定 DNS 服务器 | dig @8.8.8.8 example.com |
| 仅简短输出 | dig +short example.com |
| 查询 MX | dig example.com MX |
| 查询 NS | dig example.com NS |
| 反向解析 | dig -x 93.184.216.34（即 34.216.184.93.in-addr.arpa PTR） |
| 跟踪解析过程 | dig +trace example.com（依次问根、TLD、权威） |
| nslookup 查询 | nslookup example.com 或 nslookup example.com 8.8.8.8 |
| 清除本地缓存（macOS） | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| 清除本地缓存（Windows） | ipconfig /flushdns |
dig 输出关键字段 ：QUESTION（你的查询）、ANSWER（解析结果）、Authority（NS 等）、Query time（解析耗时）。
十七、小结
- DNS 是互联网的「电话簿」，核心是域名 → IP 的映射 ；通常走 UDP/TCP 53。
- 解析涉及本地缓存（浏览器→系统→hosts）、递归 Resolver、根/TLD/权威；用户只与 Resolver 通信。
- NS 记录 是域名的权威服务器配置；根服务器仅负责 TLD 指引，且多数请求因缓存不会到达根。
- 报文 ：Header（12 字节） + Question + Answer + Authority + Additional；域名用标签序列 （长度+标签+0）编码，响应中可用压缩指针；RCODE、QTYPE、RDATA 格式依 RFC 1035。
- 常见问题多与缓存、劫持、配置错误有关；可通过更换 DNS、调整 TTL、减少 CNAME、结合 CDN 优化。
- 安全方向正从明文 DNS 向 DoH / DoT / DNSSEC 演进。