DNS 协议详解：域名系统的幕后工作

作者：Yolo 发布时间： 2026-06-24 阅读量：7
网络协议

DNS 协议详解：域名系统的幕后工作

网络安全系列 · 网络协议篇

每当你在浏览器输入 www.example.com，背后发生了一系列精密的协作。你的设备并不直接认识这个域名，它需要借助 DNS（Domain Name System，域名系统） 将人类可读的域名转换为机器能理解的 IP 地址。这个过程看似简单，却是整个互联网运转的基石。

一、为什么需要 DNS？

1.1 域名 vs IP 地址

互联网上的每台设备都通过 IP 地址 进行通信。IPv4 地址如 142.250.185.68，IPv6 地址如 2404:6800:4003:c02::64。这些数字串对计算机来说很友好，但对人类来说难以记忆。

域名（Domain Name） 就是为了解决这个问题而生的。它使用层次化的字符串来表示网络资源，例如：

www.example.com
├── www      (子域名/主机名)
├── example  (二级域名)
└── com      (顶级域名/TLD)

1.2 DNS 的本质

DNS 是一个分布式的、层次化的数据库系统，它的核心功能就是域名解析——将域名映射到对应的 IP 地址。

可以把 DNS 想象成互联网的电话簿：


  • 你知道联系人的名字（域名）

  • DNS 帮你查到对应的电话号码（IP 地址）


二、DNS 的层次结构

DNS 采用树状层次结构，从根域开始向下延伸：

. (根域)
                    │
    ┌───────┬───────┼───────┬───────┐
    │       │       │       │       │
   .com    .org    .net    .cn    .edu
    │
    example.com
    │
www.example.com

2.1 各级域名说明

层级示例说明
根域.最顶层，通常省略不写
顶级域 (TLD).com, .org, .cn由 ICANN 管理
二级域example.com用户/组织注册的域名
子域www.example.com由域名所有者自行划分

2.2 常见顶级域名

类型示例用途
通用 TLD.com, .net, .org商业、网络、组织
国家代码.cn, .jp, .uk国家/地区
新通用 TLD.app, .dev, .blog特定用途

三、DNS 解析流程

当你在浏览器访问 www.example.com 时，发生了什么？

3.1 完整的解析过程

┌─────────────┐     ┌──────────────┐     ┌─────────────┐     ┌──────────────┐
│   用户设备   │────▶│  本地 DNS    │────▶│  根域名服务器 │────▶│  TLD 服务器  │
│  (浏览器)    │     │  (递归解析器) │     │              │     │  (.com)      │
└─────────────┘     └──────────────┘     └─────────────┘     └──────────────┘
       ▲                                                            │
       │                                                            ▼
       │                                                     ┌──────────────┐
       └────────────────────────────────────────────────────│ 权威域名服务器 │
                                                            │ example.com  │
                                                            └──────────────┘

3.2 详细步骤

Step 1: 检查浏览器缓存


  • 浏览器会缓存最近访问过的域名解析结果

  • 如果命中，直接返回 IP，流程结束


Step 2: 检查操作系统缓存

  • 浏览器未命中，查询操作系统的 DNS 缓存

  • Windows: ipconfig /displaydns

  • Linux: 通过 systemd-resolved 或 nscd 缓存


Step 3: 查询本地 DNS 服务器

  • 操作系统缓存未命中，向配置的 DNS 服务器发起查询

  • 通常是你的路由器或 ISP 提供的 DNS（如 8.8.8.8, 114.114.114.114）

  • 这个 DNS 服务器称为递归解析器（Recursive Resolver）


Step 4: 根域名服务器查询

  • 本地 DNS 也没有缓存，向根域名服务器查询

  • 全球只有 13 组根域名服务器（字母 A-M），如 a.root-servers.net

  • 根服务器不知道具体 IP，但知道 .com 的 TLD 服务器地址


Step 5: TLD 服务器查询

  • 根服务器返回 .com TLD 服务器的地址

  • 本地 DNS 向 TLD 服务器查询 example.com

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


Step 6: 权威域名服务器查询

  • 本地 DNS 向 example.com 的权威服务器查询 www.example.com

  • 权威服务器返回最终的 IP 地址


Step 7: 返回结果并缓存

  • 本地 DNS 将结果返回给用户设备

  • 同时在各级缓存中保存结果，设置 TTL（生存时间）


3.3 解析类型

类型说明
递归查询客户端只发一次请求，DNS 服务器负责全程查询
迭代查询DNS 服务器返回下一级服务器地址，客户端继续查询

实际场景中，用户设备发起递归查询，本地 DNS 服务器使用迭代查询向上级查询。

四、DNS 记录类型

DNS 数据库中存储了多种类型的资源记录（Resource Record, RR）：

4.1 常见记录类型

记录类型用途示例
AIPv4 地址记录www.example.com. A 192.0.2.1
AAAAIPv6 地址记录www.example.com. AAAA 2001:db8::1
CNAME别名记录blog.example.com. CNAME www.example.com.
MX邮件交换记录example.com. MX 10 mail.example.com.
NS域名服务器记录example.com. NS ns1.example.com.
TXT文本记录用于 SPF、DKIM 验证
SOA起始授权记录包含区域的管理信息
PTR反向解析记录IP 反查域名
SRV服务定位记录定义特定服务的服务器

4.2 记录详解

A 记录（Address Record）

最基础的记录，将域名指向 IPv4 地址：

www.example.com.    3600    IN    A    192.0.2.1

  • 3600：TTL，缓存时间（秒）
  • IN：Internet 类
  • A：记录类型
CNAME 记录（Canonical Name）

为一个域名创建别名：

blog.example.com.    3600    IN    CNAME    www.example.com.

⚠️ 注意：CNAME 记录不能与其他记录共存于同一域名。

MX 记录（Mail Exchange）

指定邮件服务器：

example.com.    3600    IN    MX    10    mail.example.com.
example.com.    3600    IN    MX    20    mail2.example.com.

  • 数字越小优先级越高
  • 10 的优先级高于 20

五、DNS 协议细节

5.1 传输协议

DNS 主要使用两种传输协议：

协议端口特点
UDP53默认方式，速度快，适合小数据包
TCP53区域传输或大响应时使用

普通查询使用 UDP，因为请求和响应都很小（通常小于 512 字节）。当响应超过 512 字节时，会切换到 TCP。

5.2 DNS 报文格式

DNS 报文分为查询（Query）和响应（Response）两种，格式相同：

+---------------------+
|        Header       |  12 字节
+---------------------+
|       Question      |  查询问题
+---------------------+
|        Answer       |  回答记录
+---------------------+
|      Authority      |  权威记录
+---------------------+
|      Additional     |  附加记录
+---------------------+

Header 字段：

字段长度说明
Transaction ID16 bit匹配请求和响应
Flags16 bit标志位（QR/Opcode/AA/TC/RD/RA等）
QDCOUNT16 bit问题数
ANCOUNT16 bit回答记录数
NSCOUNT16 bit权威记录数
ARCOUNT16 bit附加记录数

Flags 标志位：

位名称含义
0QR0=查询, 1=响应
1-4Opcode操作码（0=标准查询）
5AA权威回答
6TC截断（响应超过512字节）
7RD期望递归
8RA递归可用

5.3 使用 dig 命令查看 DNS 解析

# 基本查询
dig www.example.com

# 指定记录类型
dig example.com MX
dig example.com NS

# 跟踪完整解析过程
dig +trace www.example.com

# 指定 DNS 服务器
dig @8.8.8.8 www.example.com

# 查看响应详情
dig +all www.example.com

dig 输出示例：

; <<>> DiG 9.16.1-Ubuntu <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.com.           IN      A

;; ANSWER SECTION:
www.example.com.    3600    IN      A       192.0.2.1

;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jun 24 08:00:00 CST 2026

六、DNS 安全威胁

DNS 是互联网的基础设施，自然也成为了攻击者的目标。

6.1 DNS 劫持（DNS Hijacking）

攻击者篡改 DNS 解析结果，将用户导向恶意网站。

常见方式：


  • 本地劫持：修改 hosts 文件或本地 DNS 配置

  • 路由器劫持：攻击路由器，篡改 DNS 服务器地址

  • ISP 劫持：某些 ISP 会劫持不存在的域名到广告页面

  • DNS 服务器劫持：入侵 DNS 服务器修改记录


防护措施：

  • 使用可信的 DNS 服务器（如 8.8.8.8, 1.1.1.1）

  • 启用 DNSSEC

  • 定期检查 hosts 文件


6.2 DNS 缓存投毒（DNS Cache Poisoning）

攻击者向 DNS 缓存服务器注入虚假的 DNS 记录。

原理：


  • 利用 DNS 响应的不可信性

  • 伪造响应包，抢在真实响应前到达

  • 一旦缓存被污染，所有查询该域名的用户都会受到影响


Kaminsky 攻击（2008）：

  • 利用 DNS 的 Transaction ID 只有 16 位（65536 种可能）

  • 通过快速猜测 ID，在窗口期内伪造响应

  • 现代 DNS 已采用随机化源端口来缓解


6.3 DNS 隧道（DNS Tunneling）

利用 DNS 查询和响应传输数据，绕过防火墙。

原理：


  • 将数据编码到子域名中：data-encoded.example.com

  • DNS 服务器提取数据并响应

  • 可以传输任意数据，包括文件、命令等


检测方法：

  • 监控异常大量的 DNS 查询

  • 分析子域名长度和模式

  • 检查指向同一域名的异常流量


6.4 DNS 放大攻击（DNS Amplification）

利用 DNS 响应比请求大的特点，进行 DDoS 攻击。

原理：


  • 发送小的 DNS 查询（约 60 字节）

  • 服务器返回大的响应（可达 4000+ 字节）

  • 伪造源 IP，将流量放大后导向受害者


防护：

  • 限制 DNS 响应大小

  • 实施源 IP 验证（BCP38）

  • 禁用递归查询对公网开放


七、DNS 安全扩展（DNSSEC）

7.1 为什么需要 DNSSEC？

传统 DNS 缺乏认证机制：


  • 客户端无法验证响应的真实性

  • 响应可能在传输中被篡改

  • 无法防止缓存投毒


DNSSEC（DNS Security Extensions） 通过数字签名解决这些问题。

7.2 DNSSEC 工作原理

DNSSEC 使用公钥加密对 DNS 记录进行签名：

┌─────────────────────────────────────────┐
│  Zone: example.com                      │
│  ┌─────────────┐    ┌─────────────┐    │
│  │  ZSK (私钥)  │───▶│  签名记录    │    │
│  └─────────────┘    └─────────────┘    │
│         │                               │
│         ▼                               │
│  ┌─────────────┐                        │
│  │  ZSK (公钥)  │◀── 包含在 DNSKEY 记录中 │
│  └─────────────┘                        │
│         │                               │
│         ▼                               │
│  ┌─────────────┐    ┌─────────────┐    │
│  │  KSK (私钥)  │───▶│  签名 ZSK   │    │
│  └─────────────┘    └─────────────┘    │
└─────────────────────────────────────────┘

关键概念：

术语说明
ZSKZone Signing Key，用于签名区域记录
KSKKey Signing Key，用于签名 ZSK
DNSKEY存储公钥的记录
RRSIG资源记录的数字签名
DSDelegation Signer，父区域对子区域 KSK 的哈希
NSEC/NSEC3用于证明域名不存在（防止否定回答伪造）

7.3 信任链

DNSSEC 建立了从根域到目标域的信任链：

根域 (.) KSK
    │
    ├── 签名 .com 区域的 DS 记录
    │
    ▼
.com 区域的 KSK
    │
    ├── 签名 example.com 的 DS 记录
    │
    ▼
example.com 的 KSK
    │
    ├── 签名 ZSK
    │
    ▼
example.com 的 ZSK
    │
    ├── 签名所有记录

7.4 DNSSEC 的局限

  • 不加密数据：只提供认证，不保护隐私
  • 增加响应大小：签名记录使 DNS 响应变大
  • 部署复杂：需要密钥管理和定期轮换
  • DANE：结合 DNSSEC 和 TLS，用于证书验证

八、DoH 与 DoT：加密的 DNS

DNSSEC 解决了认证问题，但没有解决隐私问题——DNS 查询仍然是明文传输的。

8.1 DNS over TLS (DoT)

使用 TLS 加密 DNS 查询：

客户端 ──TLS──▶ DNS 服务器:853

  • 端口：853
  • 全程加密，防止中间人窃听
  • 但独立的端口容易被识别和阻断

8.2 DNS over HTTPS (DoH)

通过 HTTPS 传输 DNS 查询：

客户端 ──HTTPS──▶ DoH 服务器:443

  • 端口：443（与普通 HTTPS 相同）
  • 流量与正常网站流量混合，难以区分
  • 更好的隐私保护，但也引发了一些争议

8.3 对比

特性DoTDoH
端口853443
传输层TLSHTTPS
隐蔽性低高
部署难度简单较复杂
应用场景系统级浏览器级

8.4 配置 DoH

Firefox：

设置 → 网络设置 → 启用基于 HTTPS 的 DNS
选择提供商：Cloudflare, NextDNS 等

Chrome：

设置 → 隐私和安全 → 安全 → 使用安全 DNS

九、实际应用场景

9.1 负载均衡

通过 DNS 实现简单的负载均衡：

www.example.com.    300    IN    A    192.0.2.1
www.example.com.    300    IN    A    192.0.2.2
www.example.com.    300    IN    A    192.0.2.3

客户端会随机使用其中一个 IP，实现流量分发。

9.2 CDN 加速

CDN 利用 DNS 将用户导向最近的边缘节点：

用户在北京 ──▶ DNS 返回北京节点 IP
用户在上海 ──▶ DNS 返回上海节点 IP

通过智能 DNS 解析，根据用户地理位置返回最优 IP。

9.3 故障转移

通过动态修改 DNS 记录实现故障转移：

正常: www.example.com ──▶ 192.0.2.1 (主)
故障: www.example.com ──▶ 192.0.2.2 (备)

9.4 内网 DNS

企业内网通常部署私有 DNS：


  • 解析内部域名（如 intranet.company.com）

  • 屏蔽恶意域名

  • 分流内外网流量


十、总结

DNS 是互联网的"电话簿"，虽然用户几乎感知不到它的存在，但每一次网页访问、每一封邮件发送都离不开它。

核心要点：

  1. 分布式设计：DNS 采用层次化的分布式架构，保证了扩展性和可靠性
  2. 缓存机制：多级缓存加速解析，但也带来了 TTL 和一致性问题
  3. 安全挑战：DNS 劫持、缓存投毒、隧道等攻击威胁持续存在
  4. 安全增强：DNSSEC 提供认证，DoH/DoT 提供加密，共同提升 DNS 安全性
下一步学习：
  • 深入了解 DNSSEC 的部署和配置
  • 学习使用 BIND、CoreDNS 等 DNS 服务器软件
  • 探索基于 DNS 的安全检测和威胁情报
📚 系列文章索引

网络安全系列正在持续更新中，涵盖 Web 安全、认证授权、前端安全、密码学、渗透测试等多个方向。欢迎持续关注！

本文发表于 2026-06-24，如有错误欢迎指正。

上一篇：ARP 协议：地址解析的幕后英雄
下一篇：对称加密：AES与ChaCha20