网络域名解析的流程

# 09.网络域名解析的流程

# 目录介绍

01.工作案例引入
- 1.1 一位SRE的DNS故障排查手记
- 1.2 故障背后的DNS知识图谱
02.域名解析查找IP地址
- 2.1 为何需要域名解析
- 2.2 域名的层次结构
- 2.3 域名到IP的映射
03.DNS基础概念和用途
- 3.1 DNS是什么
- 3.2 DNS的设计目标
- 3.3 DNS记录类型
04.DNS服务器的几种分类
- 4.1 根DNS服务器
- 4.2 顶级域DNS服务器
- 4.3 权威DNS服务器
- 4.4 本地DNS服务器
05.DNS查询的算法介绍
- 5.1 递归查询
- 5.2 迭代查询
- 5.3 递归与迭代对比
06.DNS解析流程分析说明
- 6.1 完整解析流程
- 6.2 多级缓存机制
- 6.3 TTL设计思想
07.DNS的负载均衡是什么
- 7.1 DNS轮询
- 7.2 智能DNS解析
- 7.3 HTTPDNS方案
08.从IP到MAC的寻址
- 8.1 IP地址不够用怎么办
- 8.2 ARP协议原理
- 8.3 局域网和广域网寻址差异
09.DNS安全与攻防
- 9.1 DNS劫持攻击
- 9.2 DNS缓存投毒
- 9.3 DNSSEC安全扩展
- 9.4 DoH和DoT
10.DNS高级应用
- 10.1 DNS服务发现
- 10.2 DNS故障排查
- 10.3 DNS性能优化
- 10.4 私有DNS方案
11.综合案例：从0到1优化DNS全链路
- 11.1 案例背景与目标
- 11.2 第一站：能解析就够了吗
- 11.3 第二站：缓存的多层穿透
- 11.4 第三站：让用户就近访问
- 11.5 第四站：安全与隐私加固
- 11.6 四种方案横向对比
- 11.7 案例升华：CDN与DNS的关系
- 11.8 全文知识图谱回顾
12.思考题与作业
- 12.1 基础思考题
- 12.2 进阶思考题
- 12.3 动手作业

# 01.工作案例引入

# 1.1 一位SRE的DNS故障排查手记

场景：小王是一家电商公司的 SRE（站点可靠性工程师）。公司刚完成一次大促活动，业务峰值 QPS 达到平时的 20 倍。活动结束后，运维团队收到了几类用户投诉，每一条都指向同一个容易被忽视的基础设施——DNS。

故障 ① —— "网站偶尔打不开，刷新几次又好了"：用户反馈访问 www.myshop.com 时偶尔出现"无法访问"，但刷新一两次后又正常了。小王用 dig 命令查询，发现同一个域名返回了两个 IP：1.1.1.1 和 2.2.2.2。ping 2.2.2.2 超时——原来其中一台服务器在大促后被运维关机了，但 DNS 记录没有同步删除。

故障 ② —— "用 WiFi 打不开，切成 4G 就能访问"：某省用户反馈，公司 WiFi 下无法访问官网，但切换到手机 4G 就正常。小王远程指导用户执行 nslookup www.myshop.com，WiFi 下解析出的 IP 是一个完全陌生的地址（非公司服务器），4G 下解析结果正常——用户的本地 DNS（运营商提供）被劫持了。

故障 ③ —— "海外用户说加载特别慢，要十几秒"：新加坡的用户投诉网站打开极慢。小王 tracert 发现，新加坡用户被 DNS 解析到了北京的机房 IP。新加坡到北京的 RTT 约 150ms，每个 TCP 握手 + TLS 握手 + 资源加载都要走这条路——延迟叠加后用户体感极差。

故障 ④ —— "改了 DNS 记录，有些用户 24 小时后还在访问旧 IP"：运维同事前天修改了 api.myshop.com 的 A 记录指向新服务器，但监控显示仍有一部分流量打到旧 IP。小王检查权威 DNS 上记录已更新，但用户侧的解析结果还是旧的——问题出在 TTL 上：之前的 TTL 设置为了 86400 秒（24 小时）。

故障 ⑤ —— "用户收到了钓鱼邮件，域名只差一个字母"：安全团队通报，有用户被钓鱼邮件引导访问了 www.my-shop.com（多了一个连字符），页面外观和官网一模一样。用户输入了账号密码后被盗。小王发现这个钓鱼域名正是利用了用户对域名的"视觉信任"。

疑惑链条：

"DNS 明明配了两个 IP，为什么不能自动识别哪个 IP 不可用？" → DNS 本身没有健康检查能力，需要外挂健康探测 + 动态更新（对应第 7.1 节 DNS 轮询的局限）
"本地 DNS 为什么返回了错误的 IP？" → DNS 劫持——运营商或中间人篡改了 DNS 响应。解决：HTTPDNS（绕过运营商 DNS）或 DoH/DoT（加密 DNS）（对应第 9.1/9.4 节）
"新加坡用户为什么解析到北京？" → DNS 不具备地理位置感知能力，需要 GeoDNS 智能解析（对应第 7.2 节）
"TTL 设了 24 小时，为什么是一个问题？" → 长 TTL 意味着全网各级缓存都会持有旧记录长达一天。DNS 变更前应提前降低 TTL（对应第 6.3 节）
"怎么防止域名被仿冒？" → DNSSEC 不能解决这个问题（它防篡改不防仿冒），需要注册相似域名 + 浏览器安全提示 + 用户教育（对应第 9 章）

小王这一串问题，本质都是在问：DNS 到底是怎么工作的？缓存从哪来、到哪去？如何让 DNS 又快、又准、又安全？——这正是"网络域名解析的流程"要回答的。

# 1.2 故障背后的DNS知识图谱

把这次故障翻译成 DNS 知识语言：

用户在浏览器输入 www.myshop.com
    ↓ ① 查浏览器DNS缓存
浏览器缓存（约1分钟）           ← TTL在这里起效（故障④）
    ↓ 未命中
    ↓ ② 查操作系统DNS缓存 + hosts文件
操作系统缓存                    ← 故障②中hosts被篡改会直接影响
    ↓ 未命中
    ↓ ③ 查路由器DNS缓存
路由器缓存
    ↓ 未命中
    ↓ ④ 向本地DNS服务器发起递归查询
本地DNS（ISP/公共DNS）          ← 故障②的劫持发生在这里
    ↓ 迭代查询：根→TLD→权威
    ↓
权威DNS返回A记录                ← 故障①中返回了已下线IP
    ↓
用户拿到IP，建立TCP连接          ← 故障③中拿到的是地球另一端的IP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

五类故障与后续章节的映射关系：

故障	症状	根因所在的知识点	对应章节
①	偶尔打不开（返回坏IP）	DNS轮询无健康检查	07.DNS负载均衡
②	WiFi不行4G行（DNS劫持）	运营商DNS篡改 → 加密DNS	09.DNS安全
③	海外用户慢（错误IP）	无地理位置感知 → GeoDNS	07.智能DNS
④	DNS变更不生效	TTL过长 → 缓存策略	06.TTL设计思想
⑤	钓鱼域名	域名视觉信任 → DNSSEC+防御	09.DNS安全

本章的主线就是沿着这五类故障，一层一层拆解 DNS 的层次结构、缓存机制、安全攻防和优化策略。读完之后，你不仅能排查这些 DNS 问题，还能理解为什么大厂都在推 HTTPDNS、为什么 CDN 的核心是智能 DNS、为什么 1.1.1.1 这个 IP 如此特殊。

# 02.域名解析查找IP地址

# 2.1 为何需要域名解析

疑惑：既然每台计算机都有唯一的IP地址，为什么不直接用IP地址访问？为什么要多此一举设计域名系统？

答疑：人类擅长记忆有意义的名字，而不是一串数字。试想你需要记住几十个常用网站的IP地址（如 220.181.38.148），这几乎不可能。域名系统的本质是一个分布式的名字到地址的映射数据库。

论证：

IPv4地址是32位数字（如 192.168.1.1），IPv6更是128位（如 2001:0db8:85a3::8a2e:0370:7334）
而 www.baidu.com 这样的名字人人都能记住
更重要的是，域名提供了一层间接性：服务器IP可以随时更换，只要更新DNS记录，用户无需感知变化

这是计算机科学中经典的"所有问题都可以通过加一层间接层来解决"的又一个体现。

回到故障⑤的场景：域名系统提供间接性的同时，也带来了"视觉信任"问题。myshop.com 和 my-shop.com 只差一个连字符，但 DNS 会把它们解析到完全不同的 IP。用户很难在浏览器地址栏注意到这个差异。

# 2.2 域名的层次结构

域名采用倒树形层次结构设计，从右到左，层级从高到低：

                        . (根域)
                       / | \
                    com  org  cn  ...    ← 顶级域 (TLD)
                   / |        \
              google baidu   taobao     ← 二级域
               / |
           www mail maps                ← 三级域（主机名）

1
2
3
4
5
6
7

以 www.baidu.com. 为例（注意末尾有一个隐含的点）：

. — 根域（通常省略不写）
com — 顶级域（Top-Level Domain），分为通用gTLD（.com/.org/.net）和国家ccTLD（.cn/.uk/.jp）
baidu — 二级域，通常对应一个组织或公司
www — 三级域/主机名，指向具体的服务器

设计思想：这种层次结构实现了分布式管理。每一级域名的管理权可以独立委派，根域名服务器只需要知道顶级域服务器的地址，顶级域服务器只需要知道权威服务器的地址，层层委派，避免了集中式管理的瓶颈。

# 2.3 域名到IP的映射

域名到IP的映射不是简单的一对一关系：

映射关系	说明	应用场景
一个域名→一个IP	最简单的映射	小型网站
一个域名→多个IP	DNS轮询返回不同IP	负载均衡
多个域名→一个IP	虚拟主机，通过Host头区分	共享服务器
域名→另一个域名(CNAME)	别名记录	CDN加速

回到故障①的场景：www.myshop.com 配置了两个 A 记录指向两台服务器。DNS 轮询让一半用户拿到已下线的那台 IP → "偶尔打不开，刷新就好了"（刷新后可能拿到另一个 IP）。

# 03.DNS基础概念和用途

# 3.1 DNS是什么

DNS（Domain Name System，域名系统）是互联网的核心基础设施之一。它本质上是一个全球分布式的、层次化的键值数据库，将域名映射为IP地址和其他资源记录。

DNS诞生于1983年，由Paul Mockapetris设计（RFC 882/883，后更新为RFC 1034/1035）。在此之前，互联网使用一个名为 HOSTS.TXT 的文件来维护主机名到IP的映射，由Stanford Research Institute统一维护。随着互联网规模爆炸式增长，集中式管理变得不可维护，DNS应运而生。

# 3.2 DNS的设计目标

DNS的设计遵循了几个核心原则：

分布式：没有单点故障，全球有13组根域名服务器（实际通过Anycast部署了数百个节点）
层次化：树状结构，管理权分级委派
缓存友好：通过TTL机制减少查询次数，提高响应速度
最终一致性：DNS记录更新后不会立即全球生效，而是随缓存过期逐步传播

这就是故障④的根源：DNS 的设计哲学是"最终一致性"而非"强一致性"。TTL 机制意味着每个缓存节点都可以在 TTL 时间内返回旧数据。这是故意的设计取舍——用"短暂的不一致"换取"极高的性能和可用性"。

# 3.3 DNS记录类型

记录类型	全称	作用	示例
A	Address	域名→IPv4地址	`baidu.com → 220.181.38.148`
AAAA	Address (IPv6)	域名→IPv6地址	`google.com → 2404:6800:4004::`
CNAME	Canonical Name	域名→另一个域名（别名）	`www.baidu.com → www.a.shifen.com`
MX	Mail Exchange	邮件服务器地址	`baidu.com → mx.baidu.com`
NS	Name Server	指定域名的权威DNS服务器	`baidu.com → dns.baidu.com`
TXT	Text	任意文本信息	域名验证、SPF记录
SOA	Start of Authority	区域的权威信息	主DNS服务器、序列号
SRV	Service	服务定位记录	`_http._tcp.example.com → web1:80`
PTR	Pointer	IP→域名（反向解析）	`148.38.181.220 → baidu.com`
CAA	Certification Authority	指定可签发证书的CA	`example.com → letsencrypt.org`

各记录类型的深度解析：

A记录和AAAA记录：最基础的记录类型，直接建立域名到IP的映射。一个域名可以配置多条A记录，DNS服务器会根据策略返回不同的IP，这是DNS负载均衡的基础。AAAA记录与A记录功能相同，只是指向IPv6地址。当客户端同时支持IPv4和IPv6时，现代操作系统会优先尝试AAAA记录（Happy Eyeballs算法）。

CNAME记录：别名记录是DNS中非常强大的间接层设计。CDN加速就是通过CNAME实现的：

CDN接入流程（以CNAME为核心）：

1. 你的域名：www.example.com
2. 添加CNAME记录：www.example.com → www.example.com.cdn.provider.net
3. CDN提供商的DNS对 cdn.provider.net 做智能解析
4. 根据用户地理位置返回最近的CDN节点IP

查询链路：
  www.example.com → CNAME → cdn.provider.net → 智能解析 → 最近CDN节点IP

1
2
3
4
5
6
7
8
9

CNAME的限制：CNAME不能与其他记录类型共存。即如果设置了CNAME，就不能再为同一个域名设置A记录、MX记录等。这是因为CNAME的语义是"这个名字是另一个名字的别名"，所有查询都应该转向目标域名。

MX记录：邮件交换记录决定了邮件的投递路径。MX记录有优先级字段，数值越小优先级越高：

example.com  MX  10 mail1.example.com    ← 主邮件服务器
example.com  MX  20 mail2.example.com    ← 备份邮件服务器
example.com  MX  30 mail3.example.com    ← 第二备份

当mail1不可用时，邮件会自动投递到mail2

1
2
3
4
5

PTR记录：反向DNS解析，从IP地址查找域名。主要用于邮件服务器验证发件人身份（反垃圾邮件），以及网络故障排查时通过IP反查域名。

SOA记录：每个DNS区域（Zone）有且只有一条SOA记录，包含该区域的管理信息：

SOA记录的关键字段：
  MNAME:   主DNS服务器的域名
  RNAME:   区域管理员的邮箱（@用.替代）
  SERIAL:  序列号（每次修改递增，从DNS用此判断是否需要同步）
  REFRESH: 从DNS多久检查一次主DNS的更新
  RETRY:   检查失败后多久重试
  EXPIRE:  从DNS在多长时间联系不上主DNS后放弃服务
  MINIMUM: 否定缓存的TTL（域名不存在时缓存多久）

1
2
3
4
5
6
7
8

# 04.DNS服务器的几种分类

# 4.1 根DNS服务器

根DNS服务器是DNS层次结构的最顶层。全球共有13组根服务器（名为A到M），由不同组织管理。

疑惑：为什么只有13组根服务器？是性能限制吗？

答疑：这是由于DNS最初的响应消息限制在512字节（UDP包），13组服务器的地址信息刚好能放进一个UDP包里。但实际上通过Anycast技术，每组根服务器在全球有多个镜像节点，实际节点数超过1500个。

根服务器不直接解析域名，它只负责"指路"——告诉你该去找哪个顶级域服务器。

# 4.2 顶级域DNS服务器

管理如 .com、.org、.cn 等顶级域下所有域名的注册信息。当本地DNS收到根服务器的指引后，会向顶级域服务器查询。

# 4.3 权威DNS服务器

存储特定域名的最终解析记录。例如 baidu.com 的权威DNS服务器知道 www.baidu.com 对应的IP地址。

权威DNS是域名所有者可以直接控制的服务器，所有的DNS记录增删改查最终都在这里完成。

回到故障①：权威DNS上 www.myshop.com 的 A 记录指向了两台服务器的 IP，其中一台已下线。权威 DNS 本身不负责健康检查——这是 DNS 设计上的"职责边界"：DNS 负责名字→地址映射，不负责地址可达性检查。

# 4.4 本地DNS服务器

也叫递归DNS服务器（Recursive DNS Resolver），通常由ISP（互联网服务提供商）或企业提供。它是用户设备和DNS层级结构之间的代理，负责代替用户完成整个查询链路。

本地DNS服务器是DNS架构中最关键的"中间人"。它缓存了大量的解析结果，使得绝大多数DNS查询无需真正到达根服务器或权威服务器。

本地DNS的工作职责：

递归查询代理：替用户完成从根到权威的完整查询链路
缓存管理：根据TTL缓存查询结果，加速后续查询
否定缓存：缓存"域名不存在"的结果（NXDOMAIN），避免重复查询不存在的域名
安全过滤：部分DNS服务器会过滤恶意域名（如恶意软件的C&C服务器域名）

回到故障②：用户的本地 DNS（运营商提供）被劫持，返回了错误的 IP。这不是权威 DNS 的问题，而是中间人（递归 DNS）被污染。

知名的公共DNS服务：

DNS服务	IPv4地址	IPv6地址	特点
Google	`8.8.8.8` / `8.8.4.4`	`2001:4860:4860::8888`	全球覆盖最广
Cloudflare	`1.1.1.1` / `1.0.0.1`	`2606:4700:4700::1111`	延迟最低，注重隐私
阿里DNS	`223.5.5.5` / `223.6.6.6`	`2400:3200::1`	国内速度快
腾讯DNS	`119.29.29.29`	`2402:4e00::`	国内覆盖好
OpenDNS	`208.67.222.222`	-	提供安全过滤

# 05.DNS查询的算法介绍

# 5.1 递归查询

递归查询是指：客户端向本地DNS发出请求后，本地DNS"全权代理"查询过程，逐级向上查询，最终将结果返回给客户端。客户端只需发一次请求。

客户端 ──请求──→ 本地DNS（全权负责，逐级查询后返回结果）

# 5.2 迭代查询

迭代查询是指：本地DNS向根服务器查询时，根服务器不会代劳，而是返回"你应该去问谁"，本地DNS再继续向下一级查询。

本地DNS ──→ 根DNS：请告诉我baidu.com的IP
根DNS ──→ 本地DNS：我不知道，但.com的TLD服务器在X.X.X.X
本地DNS ──→ TLD DNS：请告诉我baidu.com的IP  
TLD DNS ──→ 本地DNS：我不知道，但baidu.com的权威DNS在Y.Y.Y.Y
本地DNS ──→ 权威DNS：请告诉我www.baidu.com的IP
权威DNS ──→ 本地DNS：IP是220.181.38.148

1
2
3
4
5
6

# 5.3 递归与迭代对比

对比项	递归查询	迭代查询
查询方式	"帮我查到底"	"告诉我去哪儿查"
压力分布	集中在被请求者	分散在请求者
典型场景	客户端→本地DNS	本地DNS→各级DNS服务器
缓存效果	请求者可缓存最终结果	每级都可缓存中间结果

设计思想：实际DNS查询是递归和迭代的结合。客户端到本地DNS用递归（用户不需要知道DNS内部结构），本地DNS到各级DNS服务器用迭代（减轻根服务器压力）。

为什么不能全部用递归？

如果本地DNS到根服务器也用递归查询，根服务器就需要帮每一个查询从头到尾走完全程。全球每天有数万亿次DNS查询，如果全部压在13组根服务器上，根服务器将不堪重负。

为什么不能全部用迭代？

如果客户端自己做迭代查询，意味着每个用户设备都需要知道根服务器地址、理解DNS协议的查询流程、处理各种异常情况。这对终端用户来说过于复杂，也不利于缓存优化。

因此，递归+迭代的组合是一种经典的分层设计：

对外简单：用户只需要知道一个本地DNS地址
内部高效：本地DNS通过迭代查询分散负载
缓存友好：本地DNS服务大量用户，缓存命中率高

# 06.DNS解析流程分析说明

# 6.1 完整解析流程

当你在浏览器输入 www.baidu.com 时，完整的DNS解析流程：

1. 浏览器DNS缓存 → 命中则直接使用
       │ 未命中
2. 操作系统DNS缓存（含hosts文件）→ 命中则返回
       │ 未命中
3. 路由器DNS缓存 → 命中则返回
       │ 未命中
4. ISP本地DNS服务器缓存 → 命中则返回
       │ 未命中
5. 本地DNS发起迭代查询：
   → 根DNS服务器（返回.com TLD地址）
   → .com TLD服务器（返回baidu.com权威DNS地址）
   → baidu.com权威DNS服务器（返回IP: 220.181.38.148）
       │
6. 本地DNS缓存结果，返回给客户端
7. 浏览器缓存结果，发起TCP连接

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

疑惑：每一步缓存都受 TTL 控制，那这些缓存是独立过期的吗？

答疑：是的。每一级缓存都有自己的 TTL 计时器。假设你设置了 TTL=3600 秒（1 小时）：

浏览器缓存在 14:00 拿到记录 → 15:00 过期
运营商 DNS 缓存在 14:05 拿到记录 → 15:05 过期
这就是故障④的根因——即使权威 DNS 已更新，各级缓存仍持有旧数据直到各自过期。

# 6.2 多级缓存机制

DNS的缓存机制体现了经典的空间换时间设计思想。多级缓存的命中率非常高，大多数DNS查询在前4步就能命中缓存，真正需要走完全程的查询占比很低。

缓存层级	缓存位置	刷新方式
浏览器缓存	内存	关闭浏览器或手动清除
操作系统缓存	内存	`ipconfig /flushdns`(Win)或 `dscacheutil -flushcache`(Mac)
路由器缓存	路由器内存	重启路由器
ISP DNS缓存	DNS服务器	根据TTL自动过期

# 6.3 TTL设计思想

TTL（Time To Live）是DNS记录的"有效期"，单位为秒。

TTL过短（如30秒）：DNS变更快速生效，但DNS服务器查询压力大
TTL过长（如86400秒=1天）：减少查询压力，但DNS变更生效慢

对应故障④的最佳实践：平时设置较长TTL（如3600秒），在计划做DNS切换前，提前将TTL降低（如60秒），切换完成后再恢复。

DNS变更的正确姿势（对应故障④）：

Day 0（变更前24小时）：
  将TTL从86400秒（24小时） → 600秒（10分钟）
  等待24小时，确保全网旧TTL过期

Day 1（变更当天）：
  将TTL从600秒 → 60秒
  等待10分钟
  
  更改A记录指向新IP
  观察流量是否切到新服务器
  
  稳定后：
  将TTL从60秒 → 3600秒（1小时）
  
为什么不能一步到位？
  → 因为在TTL=86400时改记录，有些缓存要等24小时才刷新
  → 先降TTL，等全网旧缓存过期后，再改记录 → 新记录最长10分钟生效

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 07.DNS的负载均衡是什么

# 7.1 DNS轮询

DNS负载均衡是最简单的负载均衡方案。同一个域名配置多个A记录，DNS服务器每次返回不同顺序的IP列表。

www.example.com → 1.1.1.1, 2.2.2.2, 3.3.3.3  （第一次查询）
www.example.com → 2.2.2.2, 3.3.3.3, 1.1.1.1  （第二次查询）
www.example.com → 3.3.3.3, 1.1.1.1, 2.2.2.2  （第三次查询）

1
2
3

客户端通常使用返回列表中的第一个IP，这样流量就被分散到不同服务器上。

局限性（对应故障①）：DNS轮询无法感知服务器的健康状态和负载情况。如果某台服务器宕机，DNS仍然会返回它的IP。解决方式是外挂健康检查 → 自动摘除坏IP → 更新DNS记录（或在前端加负载均衡器如Nginx/HAProxy，DNS只指向LB的VIP）。

# 7.2 智能DNS解析

智能DNS（也叫GeoDNS）根据用户的地理位置返回最近的服务器IP。这正是故障③的解决方案：

北京用户查询 → 返回北京机房IP (RTT ~3ms)
上海用户查询 → 返回上海机房IP (RTT ~3ms)
新加坡用户查询 → 返回新加坡机房IP (RTT ~3ms)

1
2
3

工作原理：智能DNS通过用户本地DNS服务器的IP地址来判断用户地理位置，返回就近的机房IP。这是CDN（内容分发网络）的基础技术之一。

智能DNS = 普通DNS + IP 地理位置数据库 + 区域路由策略

查询流程：
  1. 用户查询 cdn.example.com
  2. 请求到达智能DNS服务器
  3. 智能DNS查用户的本地DNS IP → 判断属于"华南"
  4. 返回华南机房的IP列表

1
2
3
4
5
6
7

# 7.3 HTTPDNS方案

疑惑：传统DNS基于UDP协议，容易被劫持（运营商DNS劫持、DNS污染），怎么办？

答疑：HTTPDNS将DNS解析请求通过HTTP(S)协议发送到专门的DNS服务器，绕过了传统的DNS解析链路。这正是故障②的终极解决方案。

传统DNS：  客户端 →(UDP)→ 本地DNS → ... → 权威DNS
HTTPDNS：  客户端 →(HTTPS)→ HTTPDNS服务器 → 直接返回IP

1
2

对比项	传统DNS	HTTPDNS
协议	UDP	HTTP/HTTPS
防劫持	容易被劫持	不经过ISP，难以劫持
精确调度	依赖LocalDNS位置	基于客户端真实IP
实时性	依赖TTL缓存	可主动推送更新
适用场景	通用	移动端App

主流HTTPDNS方案：

阿里云 HTTPDNS
腾讯云 HTTPDNS（DNSPod）
百度 HTTPDNS
自建 HTTPDNS（基于开源方案）

回到故障②的解决方案：App 内集成 HTTPDNS SDK → DNS 解析不再经过运营商本地 DNS → 直接从 HTTPDNS 服务器获取正确 IP → 同时绕过劫持和精准调度。

# 08.从IP到MAC的寻址

# 8.1 IP地址不够用怎么办

IPv4地址空间只有约43亿个（2^32），早在2011年就已经分配完毕。解决方案包括：

NAT（网络地址转换）：多台设备共享一个公网IP，通过端口号区分
CIDR（无类别域间路由）：更灵活地划分子网，减少IP浪费
IPv6：128位地址空间（2^128），足够给地球上每一粒沙子分配一个IP

# 8.2 ARP协议原理

ARP（Address Resolution Protocol）将IP地址解析为MAC地址。工作过程：

1. 主机A想发数据给IP为192.168.1.2的主机B
2. A先查ARP缓存表，看是否有B的MAC地址
3. 如果没有，A广播ARP请求："谁是192.168.1.2？请告诉我你的MAC地址"
4. 局域网内所有设备收到广播，只有B回复："我是192.168.1.2，我的MAC是XX:XX:XX:XX:XX:XX"
5. A收到回复，缓存这个映射关系，然后发送数据帧

1
2
3
4
5

# 8.3 局域网和广域网寻址差异

局域网通信：直接通过MAC地址寻址，不需要路由器介入。

跨网段通信：数据包的IP地址始终是最终目标，但MAC地址在每一跳都会变化：

主机A(MAC-A) → 路由器1(MAC-R1) → 路由器2(MAC-R2) → 主机B(MAC-B)

数据帧在每一跳的变化：
第1跳：源MAC=MAC-A,  目标MAC=MAC-R1,  源IP=IP-A,  目标IP=IP-B
第2跳：源MAC=MAC-R1, 目标MAC=MAC-R2,  源IP=IP-A,  目标IP=IP-B
第3跳：源MAC=MAC-R2, 目标MAC=MAC-B,   源IP=IP-A,  目标IP=IP-B

1
2
3
4
5
6

设计思想：IP地址负责"全局寻路"（从哪里到哪里），MAC地址负责"局部传递"（下一步交给谁）。这种分层设计使得网络层和数据链路层各司其职，互不耦合。

为什么不能只用IP地址，不用MAC地址？

历史和兼容性：以太网协议（MAC寻址）比IP协议更早出现，已经广泛部署
效率考虑：局域网内的数据转发只需要查MAC地址表（二层交换），比查路由表（三层路由）快得多
协议独立性：数据链路层不只为IP服务，它也支持ARP、IPX等其他协议
安全隔离：MAC地址是硬件标识，不随网络环境变化，可用于网络接入控制（如802.1X认证）

ARP缓存表的安全问题：ARP协议是无状态的，任何设备都可以发送ARP回复，这导致了ARP欺骗攻击：

ARP欺骗攻击流程：
1. 正常情况：网关IP(192.168.1.1) → 网关MAC(AA:AA:AA)
2. 攻击者广播假ARP回复：192.168.1.1的MAC是BB:BB:BB(攻击者MAC)
3. 受害者更新ARP缓存：192.168.1.1 → BB:BB:BB
4. 此后受害者发给网关的数据都先经过攻击者（中间人攻击）

防御措施：
  - 静态ARP绑定（手动将网关IP和MAC绑定）
  - 动态ARP检测（DAI，交换机验证ARP包的合法性）
  - 使用VPN加密通信（即使被劫持也无法解密）

1
2
3
4
5
6
7
8
9
10

# 09.DNS安全与攻防

# 9.1 DNS劫持攻击

DNS劫持是指攻击者篡改DNS解析结果，将用户导向恶意网站：

DNS劫持的常见方式：

1. 本地hosts文件篡改
   恶意软件修改 /etc/hosts 或 C:\Windows\System32\drivers\etc\hosts
   添加恶意映射：192.168.1.100 www.bank.com
   
2. 路由器DNS篡改（对应故障②的一种可能）
   攻击者修改路由器的DNS服务器设置
   所有连接该路由器的设备都会被劫持
   
3. 运营商DNS劫持（对应故障②最常见的情况）
   ISP篡改DNS响应，将用户请求重定向到广告页面
   或在HTTP响应中注入广告代码
   
4. 中间人攻击DNS
   在用户和DNS服务器之间截获并篡改DNS报文
   DNS使用UDP协议且没有加密，容易被攻击

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

疑惑：我怎么知道自己的DNS有没有被劫持？

答疑：

使用 nslookup 或 dig 命令比较不同DNS服务器的解析结果
如果解析结果不一致，可能存在劫持
使用DNS泄漏测试网站检查

# 9.2 DNS缓存投毒

**DNS缓存投毒（DNS Cache Poisoning）**是指攻击者向DNS服务器注入虚假的解析记录：

DNS缓存投毒的原理：

1. 攻击者向本地DNS服务器查询 www.bank.com
2. 本地DNS向权威DNS服务器发起查询
3. 在权威DNS响应到达之前，攻击者伪造响应
   - 源IP伪装为权威DNS的IP
   - 需要猜对Transaction ID（16位，65536种可能）
   - 需要猜对源端口
4. 如果伪造的响应先到达，DNS服务器会缓存恶意记录
5. 后续所有用户查询 www.bank.com 都会得到恶意IP

Kaminsky攻击（2008年）改进：
  不需要等待真正的查询，可以不断发送伪造响应
  大幅提高了攻击成功率

1
2
3
4
5
6
7
8
9
10
11
12
13
14

防御措施：

源端口随机化（增加猜测难度）
Transaction ID随机化
DNSSEC（密码学验证）
DNS over HTTPS/TLS（加密传输）

# 9.3 DNSSEC安全扩展

**DNSSEC（DNS Security Extensions）**通过数字签名来验证DNS响应的真实性：

DNSSEC的工作原理：

1. 权威DNS服务器用私钥对DNS记录签名
2. 签名作为RRSIG记录一起返回
3. 解析器用公钥（DNSKEY记录）验证签名
4. 公钥的真实性由上级域的DS记录保证
5. 一级一级向上验证，直到根域

验证链：
  根域(.) → .com → example.com → www.example.com
  每一级都签名验证，确保数据未被篡改

DNSSEC能防：
  ✓ DNS缓存投毒
  ✓ DNS响应篡改

DNSSEC不能防：
  ✗ DNS查询的隐私泄露（查询仍然明文）
  ✗ 已存在于权威DNS中的恶意记录
  ✗ 域名仿冒（故障⑤：my-shop.com是真实注册的域名，DNSSEC只管签名验证不管是否仿冒）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 9.4 DoH和DoT

**DoH（DNS over HTTPS）和DoT（DNS over TLS）**通过加密DNS查询来保护用户隐私，直接解决故障②的劫持问题：

传统DNS：
  用户 ──UDP 53端口(明文)──→ DNS服务器
  任何中间节点都能看到你查询了什么域名

DoT（DNS over TLS）：
  用户 ──TLS 853端口(加密)──→ DNS服务器
  查询内容加密，但853端口容易被识别和封锁

DoH（DNS over HTTPS）：
  用户 ──HTTPS 443端口(加密)──→ DNS服务器
  查询内容加密，且与正常HTTPS流量无法区分
  更难被封锁

1
2
3
4
5
6
7
8
9
10
11
12

特性	传统DNS	DoT	DoH
加密	无	TLS	HTTPS
端口	53/UDP	853/TCP	443/TCP
防篡改	否	是	是
防窃听	否	是	是
难被封锁	-	中等	很难
主流支持	所有	部分	Chrome/Firefox

主流DoH服务器：

Cloudflare：https://1.1.1.1/dns-query
Google：https://dns.google/dns-query
阿里DNS：https://dns.alidns.com/dns-query

# 10.DNS高级应用

# 10.1 DNS服务发现

DNS不仅用于域名解析，还广泛用于服务发现（Service Discovery）：

SRV记录用于服务发现：

_服务名._协议.域名  TTL  IN  SRV  优先级 权重 端口 主机名

示例：
_http._tcp.example.com  300  IN  SRV  10 60 80 web1.example.com
_http._tcp.example.com  300  IN  SRV  10 40 80 web2.example.com
_http._tcp.example.com  300  IN  SRV  20  0 80 web3.example.com

含义：
  example.com的HTTP服务由3台服务器提供
  web1和web2优先级相同(10)，按6:4权重分配流量
  web3是备份(优先级20)，只在前两台不可用时使用

1
2
3
4
5
6
7
8
9
10
11
12
13

在微服务架构中，DNS服务发现被广泛使用：

Kubernetes：每个Service自动获得DNS名称（如 my-service.my-namespace.svc.cluster.local）
Consul：提供DNS接口查询注册的服务
CoreDNS：Kubernetes的默认DNS服务器

# 10.2 DNS故障排查

DNS问题是网络故障中最常见的原因之一。常用的排查工具和方法：

DNS排查工具：

1. nslookup（跨平台）
   nslookup www.example.com
   nslookup www.example.com 8.8.8.8  # 指定DNS服务器
   
2. dig（Linux/macOS，最详细）
   dig www.example.com
   dig @8.8.8.8 www.example.com     # 指定DNS服务器
   dig +trace www.example.com        # 显示完整的递归查询路径
   dig www.example.com +short        # 只显示结果IP
   
3. host（Linux/macOS，简洁）
   host www.example.com
   
4. 查看DNS缓存
   Windows: ipconfig /displaydns
   macOS: 无直接命令，可用 dscacheutil -flushcache 清除
   Linux: systemd-resolve --statistics

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

常见DNS问题及解决：

问题	症状	排查方法	解决方案
DNS服务器不可达	所有域名都无法解析	ping DNS服务器IP	更换DNS服务器
DNS记录错误	特定域名解析到错误IP	dig +trace追踪	修改DNS记录
DNS缓存过期	域名解析到旧IP	检查TTL值	清除本地DNS缓存
DNS劫持	域名解析到非预期IP	比较不同DNS结果	使用加密DNS
DNS超时	域名解析很慢或超时	dig查看各阶段耗时	优化DNS服务器

# 10.3 DNS性能优化

DNS解析时间直接影响用户体验。优化策略：

DNS性能优化策略：

1. DNS预解析（dns-prefetch）
   &lt;link rel="dns-prefetch" href="//cdn.example.com">
   浏览器在空闲时提前解析域名，节省实际请求时的DNS时间

2. 预连接（preconnect）
   &lt;link rel="preconnect" href="https://cdn.example.com">
   不仅解析DNS，还提前建立TCP+TLS连接

3. 减少域名数量
   每多一个域名就多一次DNS解析
   合理规划：主站1个 + CDN 1个 + API 1个

4. 选择快速的DNS服务
   公共DNS：Cloudflare(1.1.1.1)、Google(8.8.8.8)
   延迟通常 &lt; 10ms

5. DNS缓存优化
   对稳定的域名设置较长的TTL（如1天）
   对可能变化的域名设置较短的TTL（如5分钟）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# 10.4 私有DNS方案

在企业内网和云环境中，通常需要私有DNS来管理内部域名：

私有DNS方案：

1. 企业内网DNS
   将内部服务注册到私有DNS服务器
   如：gitlab.internal.company.com → 10.0.1.100
   外部无法解析这些域名，保证了安全性

2. Split-Horizon DNS（分裂视图DNS）
   同一个域名，内部和外部解析到不同IP
   
   外部用户查询 api.company.com → 203.0.113.1（公网IP/CDN）
   内部用户查询 api.company.com → 10.0.1.50（内网IP）
   
   内部用户直接走内网，更快更安全

3. 云平台私有DNS
   AWS Route 53 Private Hosted Zones
   阿里云 PrivateZone
   腾讯云 Private DNS
   
   VPC内部的DNS解析，外部不可见
   
4. Kubernetes CoreDNS
   自动为Service和Pod分配DNS名称
   pod-ip.namespace.pod.cluster.local
   service-name.namespace.svc.cluster.local

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 11.综合案例：从0到1优化DNS全链路

前面我们分别讲了 DNS 的层次结构、缓存机制、负载均衡、安全攻防等知识。但这些知识点如果是孤立地看，很难形成"排查和优化 DNS"的系统能力。

本章用一个贯穿全文的实战案例——从最基础的"能解析就行"开始，一步步优化 DNS 全链路，经历四个版本的进化。读完这一节，你应该能形成"拿到一个域名就能分析出它的解析全链路、瓶颈在哪、如何优化"的能力。

# 11.1 案例背景与目标

假设我们是一家电商公司，域名为 www.myshop.com，日活 500 万用户，分布在全国和海外。当前的 DNS 配置是最简单的状态——域名注册商提供的免费 DNS 服务，一条 A 记录指向唯一的源站 IP。

用户投诉集中在三类问题：

部分区域访问慢（对应故障③）
偶尔解析失败（对应故障①②）
DNS 变更后长时间不生效（对应故障④）

我们将在四个阶段逐步优化：

阶段	核心方案	解决问题	对应故障
第一站	理解当前DNS链路	建立基线，找出瓶颈	—
第二站	缓存优化+TTL策略	DNS变更不生效	④
第三站	智能DNS解析	就近访问，海外加速	③
第四站	安全加固	防劫持防投毒	①②⑤

# 11.2 第一站：能解析就够了吗——解析链路的基线测量

先用 dig +trace 看看当前域名的完整解析链路：

$ dig +trace www.myshop.com

# 第一步：查询根服务器
.  518400 IN NS a.root-servers.net.
# 收到 .com 顶级域服务器列表

# 第二步：查询 .com 顶级域服务器
com.  172800 IN NS a.gtld-servers.net.
# 收到 myshop.com 的权威DNS服务器

# 第三步：查询权威DNS
www.myshop.com.  3600 IN A 203.0.113.10
# 拿到最终 IP

1
2
3
4
5
6
7
8
9
10
11
12
13

基线测量：用 dig 测量各阶段耗时（重复 10 次取平均）：

第一次查询（冷启动，无缓存，走完整链路）：
  根服务器查询：  ~45ms
  TLD服务器查询： ~35ms
  权威DNS查询：   ~12ms
  总计：          ~92ms

第二次查询（热缓存，本地DNS已缓存）：
  本地DNS缓存命中： ~3ms

浏览器首次访问 www.myshop.com 时：
  DNS解析：   ~92ms（冷启动）或 ~3ms（命中缓存）
  TCP握手：   ~30ms
  TLS握手：   ~60ms
  HTTP响应：  ~50ms
  总计：      ~232ms（冷启动）或 ~143ms（缓存命中）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

诊断结果：当前链路功能正常，但存在以下问题：

TTL=3600 秒（1 小时），变更不能更快生效（故障④）
只有一条 A 记录，无冗余（故障①）
无论用户在哪个城市，都解析到同一个 IP（故障③）

# 11.3 第二站：缓存的多层穿透——TTL策略优化

目标：确保 DNS 变更能在可控时间内全球生效。

方案：制定 TTL 变更策略。

平时配置（稳定期）：
  www.myshop.com.  3600 IN A 203.0.113.10
  www.myshop.com.  3600 IN A 203.0.113.11  # 加一条冗余

变更前操作（提前48小时）：
  Step 1: 将 TTL 从 3600 → 600（10分钟）
  Step 2: 等待 3600 秒（原 TTL 过期）
  
变更当天：
  Step 3: 将 TTL 从 600 → 60（1分钟）
  Step 4: 等待 600 秒（上次 TTL 过期）
  Step 5: 修改 A 记录指向新 IP
  Step 6: 观察流量，确认后 TTL 恢复到 3600

1
2
3
4
5
6
7
8
9
10
11
12
13

效果验证：

# 修改前：TTL=3600
$ dig www.myshop.com
;; ANSWER SECTION:
www.myshop.com.  3600 IN A 203.0.113.10

# 修改后：TTL=60
$ dig www.myshop.com
;; ANSWER SECTION:
www.myshop.com.  60 IN A 203.0.113.20  # 新IP

# 1分钟后再次查询，TTL 递减
$ dig www.myshop.com
;; ANSWER SECTION:
www.myshop.com.  45 IN A 203.0.113.20

1
2
3
4
5
6
7
8
9
10
11
12
13
14

关键洞察：TTL 本质是"用一致性换性能"。DNS 是互联网中最大规模的缓存系统——如果没有 TTL，每次查询都要穿透到权威 DNS，13 组根服务器瞬间被击垮。

# 11.4 第三站：让用户就近访问——智能DNS

目标：北京用户访问北京机房，上海用户访问上海机房，新加坡用户访问新加坡机房。

方案：接入智能 DNS 服务（如 DNSPod、阿里云 DNS、AWS Route 53）。

智能DNS配置（以 GeoDNS 为例）：

记录1：默认线路 → 203.0.113.10（源站，兜底）
记录2：华北线路 → 1.1.1.1（北京机房）
记录3：华东线路 → 2.2.2.2（上海机房）
记录4：华南线路 → 3.3.3.3（广州机房）
记录5：东南亚线路 → 4.4.4.4（新加坡机房）

用户查询 → 智能DNS识别本地DNS的源IP → 判断地理位置 → 返回就近IP

1
2
3
4
5
6
7
8
9

配合 CDN：对于静态资源，用 CNAME 接入 CDN：

# 静态资源使用 CDN
static.myshop.com.  CNAME  static.myshop.com.cdn.cloudflare.net

# CDN 提供商的 DNS 做智能解析
static.myshop.com.cdn.cloudflare.net.  300 IN A [最近的CDN节点IP]

查询链路：
  static.myshop.com
    → CNAME → static.myshop.com.cdn.cloudflare.net
    → CDN智能DNS根据用户位置
    → 返回最近CDN节点IP（RTT &lt; 10ms）

1
2
3
4
5
6
7
8
9
10
11

效果对比：

优化前（故障③场景）：
  新加坡用户 → www.myshop.com → 203.0.113.10（北京源站）
  RTT: ~150ms
  页面加载：~3秒

优化后：
  新加坡用户 → www.myshop.com → 4.4.4.4（新加坡机房）
  静态资源 → static.myshop.com → CDN新加坡节点
  RTT: ~3ms
  页面加载：~0.8秒
  
提升：约 3.75 倍

1
2
3
4
5
6
7
8
9
10
11
12

# 11.5 第四站：安全与隐私加固

目标：防止 DNS 劫持（故障②）和缓存投毒，保护用户隐私。

方案：多层防护。

安全加固方案：

1. DNSSEC（防篡改）：
   在权威DNS上启用 DNSSEC 签名
   www.myshop.com → A记录 + RRSIG签名
   解析器可以验证响应的真实性

2. DoH/DoT（防劫持+防窃听）：
   客户端配置 DoH：
     Chrome: 设置 → 隐私和安全 → 使用安全DNS → Cloudflare(1.1.1.1)
     Firefox: 设置 → 网络设置 → 启用基于HTTPS的DNS
   服务端：部署 DoH 代理（如 dnscrypt-proxy）

3. HTTPDNS（移动端防劫持）：
   App 集成 HTTPDNS SDK
   DNS 解析不再经过运营商本地 DNS
   直接基于客户端 IP 做精准调度

4. 域名保护（防仿冒，对应故障⑤）：
   注册相似域名：my-shop.com, myshop.net, myshop.cn
   启用注册商域名锁（防止域名被转移）
   配置 CAA 记录限制可签发证书的 CA

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

DoH 效果验证：

# 传统 DNS（UDP 53，明文）
$ dig www.myshop.com
# 抓包可见：查询内容完全明文

# DoH（HTTPS 443，加密）
$ curl -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=www.myshop.com&type=A'
# 抓包：只能看到与1.1.1.1的HTTPS连接，看不到具体查询内容

1
2
3
4
5
6
7
8

# 11.6 四种方案横向对比

维度	第一站基线	第二站 TTL优化	第三站智能DNS	第四站安全加固
DNS解析时间（首次）	~92ms	~92ms	~45ms（就近）	~50ms（DoH略慢）
DNS解析时间（缓存）	~3ms	~3ms	~3ms	~3ms
变更生效时间	1小时	1分钟	1分钟	1分钟
就近访问	❌ 全部打到源站	❌ 全部打到源站	✅ 按地理位置	✅
防劫持	❌	❌	❌	✅ DoH/HTTPDNS
防篡改	❌	❌	❌	✅ DNSSEC
冗余/高可用	单IP	双IP	多地域多IP	多地域多IP
用户RTT（就近）	50-200ms	50-200ms	3-10ms	3-10ms
对应故障	—	④	③	①②⑤
对应章节	6.1	6.3	7.2/7.3	9.3/9.4

用户体验优化路径：

页面加载时间（首次访问，含DNS解析）
│
│  3.0s  ████████████  第一站（基线：全部打到北京源站）
│  3.0s  ████████████  第二站（TTL优化：变更快了，速度不变）
│  0.8s  ███           第三站（智能DNS+CDN：就近访问）
│  0.8s  ███           第四站（安全加固：速度不变，安全性质变）
│
└────────────────────────────→ 优化阶段

安全等级：
│
│  ★☆☆☆  第一站（有被劫持风险）
│  ★☆☆☆  第二站（同上）
│  ★★☆☆  第三站（智能DNS自带一定防护）
│  ★★★★  第四站（DNSSEC+DoH+HTTPDNS三层防护）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 11.7 案例升华：CDN与DNS的关系

理解了上面四个阶段，再看 CDN 的工作原理就豁然开朗了——CDN 的调度本质就是智能 DNS + CNAME：

CDN 的 DNS 调度流程：

用户访问 static.myshop.com
    ↓
1. 权威DNS返回 CNAME：static.myshop.com → myshop.cdn.com
    ↓
2. 本地DNS向 cdn.com 的权威DNS查询
    ↓
3. cdn.com 智能DNS：
   - 查本地DNS的IP → 判断用户在"上海"
   - 返回上海CDN节点的IP列表
   - 附带内部健康状态（宕机的节点不返回）
    ↓
4. 用户连接上海CDN节点（RTT ~3ms）
   - 如果节点有缓存：直接返回（命中率 > 95%）
   - 如果节点无缓存：回源到 myshop.com 源站拉取

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

CDN的DNS设计与小王故障的对应：

CDN机制	解决小王什么故障	原理
智能DNS	故障③（海外用户慢）	就近调度，RTT从150ms降到3ms
内部健康检查	故障①（返回坏IP）	CDN的DNS只返回健康的节点IP
短TTL（60-300s）	故障④（变更不生效）	CDN节点IP变化频繁，TTL必须短
HTTPS+自有DNS	故障②（劫持）	不走运营商DNS，加密传输

一句话总结：CDN 用 DNS 做全局调度，用缓存做就近加速，用短 TTL 做灵活切换。DNS 不是 CDN 的附属品，DNS 是 CDN 的大脑。

# 11.8 全文知识图谱回顾

走到这里，我们用"DNS 全链路优化"把全文核心串完了。最后用一张图收敛所有知识点：

                    小王的五类故障
                    │
    ┌───────┬───────┼───────┬───────┐
    │       │       │       │       │
   ①坏IP   ②劫持   ③慢     ④不生效  ⑤仿冒
    │       │       │       │       │
    ▼       ▼       ▼       ▼       ▼
 DNS轮询  加密DNS  智能DNS  TTL策略  域名保护
 无健康   DoH/DoT  GeoDNS  缓存设计  DNSSEC
 [7.1]   [9.4]   [7.2]   [6.3]   [9.3]
    │       │       │       │       │
    └───────┴───────┼───────┴───────┘
                    │
        ┌───────────┴───────────┐
        │                       │
  DNS层次结构 [2/3/4章]    DNS查询算法 [5章]
  根→TLD→权威→本地       递归 vs 迭代
        │                       │
        └───────────┬───────────┘
                    │
     基线→TTL优化→智能DNS→安全加固
     DNS全链路优化的四次进化 [第11章]
                    │
                    ▼
          CDN / HTTPDNS / CoreDNS
          主流方案的设计智慧 [11.7节]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

最终的方法论沉淀——排查或设计一个 DNS 方案时，都应该问自己三个问题：

谁来解析？（用运营商的还是自己的？公共 DNS 还是 HTTPDNS？→ 速度 vs 可控性）
解析多久？（TTL 设多长？变更时怎么处理？→ 一致性 vs 性能）
安不安全？（会不会被劫持？有没有签名验证？→ 便利性 vs 安全性）

把这三个问题问到位，你就从"域名配个 A 记录"进化到了"懂 DNS 基础设施的工程师"。

# 12.思考题与作业

# 12.1 基础思考题

DNS的层次结构：以 www.example.co.uk. 为例，从右到左写出完整的域名层次（根→顶级→二级→三级），并说明每一级由什么组织管理。
递归 vs 迭代：为什么客户端到本地DNS用递归查询，而本地DNS到根/TLD服务器用迭代查询？如果反过来（客户端迭代、本地DNS递归到根）会有什么问题？
TTL的双刃剑：某网站的 A 记录 TTL 设为 86400（1天）。元旦那天服务器 IP 变更，运维修改了 DNS 记录后，为什么有些用户直到 1 月 2 日还在访问旧 IP？如果这个网站是银行支付网关，IP 变更的最佳 TTL 策略是什么？
CNAME的限制：为什么设置了CNAME记录后就不能再为同一个域名设置A记录、MX记录？请从DNS解析流程的角度解释。

# 12.2 进阶思考题

故障④的数学分析：假设一个域名的 A 记录 TTL=3600 秒，权威 DNS 在 T0 时刻修改了记录。请问最终用户在什么时间范围内可能获取到旧记录？如果全球有 1000 个递归 DNS 缓存了该记录，且每个递归 DNS 的缓存起始时间均匀分布在 [T0-3600, T0] 之间，新记录完全生效需要多长时间？
HTTPDNS为什么能防劫持：HTTPDNS 走 HTTPS 协议绕过了运营商本地 DNS。但如果运营商在 TCP 层劫持了到 HTTPDNS 服务器的连接（比如把 https://httpdns.example.com 的 IP 解析到自己的服务器），HTTPDNS 还能防劫持吗？这种情况下应该怎么防护？（提示：证书固定 / Certificate Pinning）
DNS vs CDN 的职责边界：DNS 轮询能实现简单负载均衡，但为什么实际生产环境中 DNS 轮询不能替代专业的负载均衡器（如 Nginx/HAProxy/F5）？列出至少 3 个 DNS 轮询无法解决的问题。
Anycast的魔法：13 组根服务器能服务全球亿万级查询，靠的是 Anycast 技术。请解释 Anycast 的工作原理，并说明为什么 DNS 能用 Anycast 而 TCP 长连接不能用 Anycast。

# 12.3 动手作业

作业一（必做）：用 dig 追踪 DNS 解析全过程。

# 1. 追踪一个域名的完整解析链路
dig +trace www.baidu.com

# 2. 对比不同 DNS 服务器的解析结果
dig @8.8.8.8 www.baidu.com
dig @1.1.1.1 www.baidu.com
dig @223.5.5.5 www.baidu.com

# 3. 查看 TTL 变化
dig www.baidu.com
# 隔几秒再查一次，观察 TTL 递减

1
2
3
4
5
6
7
8
9
10
11

把 dig +trace 的输出记录下来，标注每一步查询的是哪类 DNS 服务器（根/TLD/权威）。
对比不同 DNS 服务器返回的 IP 是否相同？TTL 是否相同？如果不一致，分析可能的原因。

作业二（选做）：搭建本地 DNS 缓存服务器。

在你的开发机上用 Docker 部署一个 CoreDNS 实例，配置上游 DNS 为 8.8.8.8。
把你电脑的 DNS 设置为 127.0.0.1（指向 CoreDNS）。
用 dig 测试：① 第一次查询某域名的耗时 ② 第二次查询同一域名的耗时 ③ CoreDNS 的缓存命中率。
对比有了本地缓存服务器后的 DNS 解析加速效果。

作业三（架构思考）：设计一个跨地域的 DNS 架构。

假设你的公司业务覆盖华北、华东、华南、东南亚四个区域，每个区域有独立的机房。
设计 DNS 架构方案，包含：智能 DNS 分线路策略、CDN CNAME 配置、故障切换方案、安全防护措施。
画出"用户请求 → DNS解析 → 返回IP → 访问机房"的完整链路图。
标注每个环节的耗时量级。

# 参考

https://cloud.tencent.com/developer/article/2301115

https://zhuanlan.zhihu.com/p/705751265

上次更新: 2026/06/09, 15:47:57

← 传输数据的设计思想 HTTP服务设计流程→