glen

2026.11.11 · 预计阅读 16 分钟

DNS 是什么：从 www.bit-labs.cn 到一次网页打开的完整链路

用 bit-labs.cn 的真实解析数据，讲清 DNS 的角色与术语、一次解析的完整链路、自建权威 DNS 的步骤与坑、它到底能不能做负载均衡，以及高可用为什么不能只靠 DNS。

本文目录

DNS 是什么：从 www.bit-labs.cn 到一次网页打开的完整链路

一句话结论：DNS 是互联网的分级电话簿——把域名翻译成 IP 地址；它靠「根 → 顶级域 → 你的域名」逐级委派，每一级只知道自己下一级是谁，再用缓存把每次查询摊薄到几乎为零。

全文用 bit-labs.cn 的真实记录贯穿（2026-11-02 实测），五个问题依次回答：术语是什么、一次解析怎么走、怎么自己做权威 DNS、DNS 能不能做负载均衡、以及只靠 DNS 能不能扛住节点故障。

1. 你其实在问什么

表面上是一个问题，拆开是五层：

术语层：NS、SOA、TTL、递归、权威、委派……这些词分别在指谁？
流程层：在浏览器输入 www.bit-labs.cn 回车到页面出现，中间发生了什么？
控制层：想"自己做权威 DNS"，需要准备什么？坑在哪？
能力层：DNS 是不是顺便还做了负载均衡？
可靠性层：既然 DNS 只是"选路"，节点挂了是不是就没救？（v2 新增）

本文回答这五层。不展开：DNS 报文的逐字节格式、BIND 的高级特性、DoH/DoT 的协议细节（只在延伸问答里点一句）。

2. 先建立直觉：一个"分级问路"的类比

你到了一个陌生城市，要找一个公司的 3 号楼：

先问总机："这个城市归谁管？"——总机不会给你门牌号，只会说"问市政厅"；
问市政厅："这个园区归谁管？"——它说"问物业"；
问物业："3 号楼在哪？"——物业手里才有真正的门牌号；
你把答案抄在便签上，写个有效期，下次直接看便签。

这就是 DNS 的全部骨架：分级、每级只知下一跳、答案可缓存。

类比在哪里不成立，也要说清：

电话簿是静态的，DNS 的地址随时会变，所以才有 TTL（有效期）；
同一个名字可以对应多个 IP（多值记录），"3 号楼"可以有好几个门；
"问路"这个过程本身可以加密（DoH/DoT），也可以被"污染"（被人故意指错路）。

3. 它怎么工作

3.1 四个角色，各管一段

角色	实际例子	它知道什么
根服务器（Root）	`a`~`m.root-servers.net`，共 13 组	只知道 `.cn`、`.com` 这些顶级域交给谁管
顶级域服务器（TLD）	`a`~`e.dns.cn`、`ns.cernet.net`	只知道 `bit-labs.cn` 被委派给了谁
权威服务器（Authoritative）	`dns31.hichina.com` / `dns32.hichina.com`	持有 `bit-labs.cn` 的"官方记录"，能给出权威答案
递归解析器（Recursive）	`8.8.8.8`、`223.5.5.5`、你家路由器的 `192.168.0.1`	帮你跑腿，负责问出最终结果并缓存

关键区别一句话：权威只"指路"，递归才"跑腿到底"。这也是"迭代查询"和"递归查询"两个词的分界——权威服务器上必须关掉递归，否则它会变成可以被坏人利用的"开放解析器"。

3.2 一次完整解析

图：www.bit-labs.cn 从输入到页面出现的完整链路

sequenceDiagram
    participant B as 浏览器
    participant R as 递归解析器
    participant Root as 根服务器
    participant TLD as .cn 服务器
    participant Auth as 权威服务器 hichina
    B->>B: 先查本地缓存与 hosts
    B->>R: www.bit-labs.cn 的 A 记录？
    R->>R: 查自己的缓存（miss）
    R->>Root: .cn 的 NS 是谁？
    Root-->>R: a~e.dns.cn（委派）
    R->>TLD: bit-labs.cn 的 NS 是谁？
    TLD-->>R: dns31/dns32.hichina.com（委派）
    R->>Auth: www.bit-labs.cn 的 A 记录？
    Auth-->>R: 1.14.2.11，TTL 600
    R-->>B: 1.14.2.11（缓存 600 秒）
    B->>B: TCP 握手 + TLS 握手 + 发 HTTP 请求

注意两个容易忽略的细节：

第 4 步递归器拿到的是委派（referral），不是答案。它会顺着线索自己往下问，客户端全程只发一次请求。
在问 hichina 之前，递归器还得先把 dns31.hichina.com 这个主机名解析成 IP——所以一次网页打开，背后往往是"一串"查询。

3.3 术语速查表

术语	一句话解释	在哪一步出现
Zone（区）	一个权威服务器负责的命名空间切片，`bit-labs.cn` 就是一个 zone	委派边界
Delegation（委派）	父区用 NS 记录把子区交出去	第 3、5 步
Glue（胶水记录）	父区顺带保存子区 NS 的 A 记录，避免"先有鸡还是先有蛋"	委派时
TTL	缓存存活秒数，`600` = 最多缓存 10 分钟	答案里
RRset	同名同类型的记录集合，整组一起更新、一起缓存	多值 A
SOA	zone 的身份证：主 NS、管理员邮箱、serial、refresh/retry/expire/minimum	权威档案
NXDOMAIN / NODATA	"这个名字不存在" / "名字存在但没有这种记录"，都会被否定缓存	缓存
DNSSEC	用签名证明"答案没被篡改"，父区存子区的 DS 记录	安全
Anycast	同一个 IP 在多地同时宣告，路由把用户送到最近那台	公共 DNS

4. 关键细节

4.1 TTL 与缓存：为什么"改了记录不立刻生效"

递归解析器把答案连同 TTL 一起缓存，倒计时没走完就继续给旧答案。所以：

你改了记录，已经缓存过的地方要等旧 TTL 过期；
把 TTL 改小，只影响"之后被缓存的新答案"，管不到旧缓存；
要频繁切换的域名（比如挂 CDN、做灰度），通常把 TTL 压到 60~120 秒，但代价是权威服务器的查询量上升。

4.2 委派与 glue：自建权威最大的坑

假设你要把权威换成自己的 ns1.bit-labs.cn，而这个名字本身就在 bit-labs.cn 里面：

递归器要查 www.bit-labs.cn → 得先知道 ns1.bit-labs.cn 的 IP；
而查 ns1.bit-labs.cn → 又得先找到 bit-labs.cn 的权威服务器……

死循环。解法是父区（.cn）在委派 NS 记录时附带 A 记录，这就是 glue record，在注册商/云厂商控制台里通常叫"自定义 DNS"或"胶水记录"。NS 名字放在别的域下（如 ns1.example.net）可以绕开，但也要求你能控制那个域。

4.3 常用记录类型

类型	作用	典型用法
`A` / `AAAA`	IPv4 / IPv6 地址	最核心的记录
`CNAME`	别名，指向另一个名字	接 CDN；不能出现在 zone 顶点，也不能与其他记录共存
`NS`	本 zone 的权威服务器名单	委派
`SOA`	zone 元信息与序列号	主从同步、否定缓存时长
`MX`	邮件服务器（带优先级）	收邮件必须有，否则该域收不了信
`TXT`	任意文本	站点所有权验证、SPF
`CAA`	允许哪些 CA 给本域签发证书	防误签发
`PTR`	反向解析（IP → 名字）	邮件反垃圾、日志可读

4.4 传输与安全

UDP 53 是默认；应答太大（或被截断，TC 标志位）时自动转 TCP 53，所以两个端口都要放行。
主从复制：AXFR（全量）/ IXFR（增量）/ NOTIFY（变更通知）/ TSIG（传输认证）。
DNSSEC：签名链从根一路下来，父区存子区的 DS 记录；能防投毒，但要维护密钥轮转。
DoH / DoT / DoQ：把递归查询加密（443/853），解决"路上被偷看/被篡改"。

5. 例子：给 bit-labs.cn 做一次真实体检

下面全部是 2026-11-02 在 Windows 上实测的结果（命令见附录）：

bit-labs.cn      NS   dns31.hichina.com / dns32.hichina.com
bit-labs.cn      SOA  dns31.hichina.com hostmaster.hichina.com
                      serial=2026082815 refresh=3600 retry=1200 expire=86400 TTL=600
bit-labs.cn      A    1.14.2.11                TTL 600
www.bit-labs.cn  A    1.14.2.11                TTL 600
*.bit-labs.cn    A    101.200.231.29           TTL 600
bit-labs.cn      TXT  "google-site-verification=4g2Kpl..."
AAAA / MX / CAA      （无）

读出来的结论：

委派正常：.cn 把 bit-labs.cn 交给了阿里云万网（hichina）的两个权威，双 NS 满足基本冗余。
权威本身是高可用集群：dns31.hichina.com 解析出 8 个 IP（47.118.199.219、39.96.153.59…），不是单机。
www 是裸 A 记录，不是 CNAME：说明当前没有走 CDN。若要接 CDN，www 得改成 CNAME；而裸域 bit-labs.cn 因为顶点不能放 CNAME，只能靠 CNAME 展平（flattening）或 ALIAS/ANAME。
有泛解析：随手查一个 random-xxx.bit-labs.cn，返回 101.200.231.29。所以"不存在的子域"在这台域名上不会返回 NXDOMAIN，而是落到通配记录——排查时很容易被误导。
没有 AAAA：纯 IPv6 环境下打不开；没有 MX：这个域名目前收不了邮件；没有 CAA：任何 CA 都能给它签发证书。
没有按地域分流：8.8.8.8 / 223.5.5.5 / 119.29.29.29 三个递归器返回的都是同一份 1.14.2.11。

6. 自建权威 DNS：先选路线，再谈配置

图：三条路线的选择

flowchart TD
    A[要自己掌控解析？] -->|只想改记录| B[用云解析<br/>阿里/DNSPod/Cloudflare]
    A -->|要完全自建| C{有 2 台以上<br/>公网 VPS 吗}
    C -->|有| D[自建 BIND/Knot/NSD<br/>注册自己的 NS]
    C -->|没有| E[hidden master<br/>+ 服务商做 secondary]
    D --> F[关键难点<br/>glue · 双活 · 抗 DDoS]

A 路线（99% 的人）：在云控制台写记录。bit-labs.cn 现在就走这条。

B 路线（真正"自己的权威"）：BIND 9 / Knot DNS / NSD / PowerDNS 任选，跑在两台以上机器。别用 dnsmasq，它是转发/递归用的，不是权威。

C 路线（生产常见）：自建 hidden master 存源数据，交给云厂商做 secondary 或 Anycast 对外。

自建的最短清单（BIND 9）

两台以上公网机器，固定 IP，放行 53/udp 和 53/tcp。
定 NS 名：ns1.bit-labs.cn、ns2.bit-labs.cn。
写 zone 文件（SOA、NS、A、泛解析都要有）：

$ORIGIN bit-labs.cn.
$TTL 600
@   IN SOA ns1.bit-labs.cn. hostmaster.bit-labs.cn. (
        2026082801 ; serial：每改一次记录必须加一
        3600       ; refresh
        1200       ; retry
        86400      ; expire
        600 )      ; 否定缓存 TTL
@    IN NS  ns1.bit-labs.cn.
@    IN NS  ns2.bit-labs.cn.
ns1  IN A   203.0.113.10
ns2  IN A   203.0.113.11
@    IN A   1.14.2.11
www  IN A   1.14.2.11
*    IN A   101.200.231.29

配置 named.conf：关闭递归、只允许从服务器做 AXFR：

options {
    listen-on port 53 { any; };
    recursion no;                       # 权威服务器必须关递归
    allow-transfer { 203.0.113.11; };
    allow-query    { any; };
};
zone "bit-labs.cn" IN {
    type master;
    file "/etc/bind/db.bit-labs.cn";
    also-notify { 203.0.113.11; };
};

注册 glue 记录（见 4.2），否则解析链会断。
在注册商处改 NS，把 bit-labs.cn 从 hichina 换到 ns1/ns2.bit-labs.cn。生效时间受 .cn 侧 TTL 影响，可能几小时。
主从 + 监控：rndc 管理、多点 dig 巡检、告警。
上 DNSSEC（可选）：签 zone 后到注册商提交 DS。
抗 DDoS：DNS 是 UDP 反射放大重灾区，单机基本挡不住；生产要 Anycast 或高防。

一句话总结：技术门槛在 zone 文件，真正的门槛在 glue、双活和抗攻击。这也是大多数人停在 A 路线的原因。

7. DNS 做负载均衡吗？

做，但它是整条链路里"最粗的那一层"。

7.1 它能做的

手段	原理	适用
多值 A / AAAA（轮询）	同一名字返回多条地址，客户端自己挑	无状态服务、多机房入口
加权轮询	权威按比例返回不同地址	灰度、按容量分配
地理 / 运营商分流	按递归器源 IP 判断归属	电信/联通/海外分流
就近（latency）路由	按实测 RTT 选最近节点	全球化业务
故障转移	权威带健康检查，主 IP 挂了换备 IP	容灾

7.2 它的五个硬伤

缓存让切换变慢：TTL 600 意味着切换后 10 分钟内仍有用户拿到旧 IP。
协议本身没有健康感知：健康检查是服务商在权威之外加的，不是 DNS 的能力。
客户端不一定听话：浏览器/操作系统会按自己的规则排序、并行连接、失败重试，流量不会严格均分。
不做会话保持，也看不到连接数——它只在"名字 → 地址"这一层分配。
故障面极大：权威挂了，整个站点就"消失"。所以 DNS 侧的高可用比负载均衡本身更重要。

7.3 正确的分层

图：流量分配的分层

flowchart LR
    U[用户] --> D[DNS<br/>就近/分流 分钟级]
    D --> A[Anycast<br/>机房级]
    A --> L4[L4 负载均衡<br/>连接级]
    L4 --> L7[L7 Ingress<br/>HTTP 路由/灰度]
    L7 --> S[应用]

DNS 负责"让用户找到最近的入口"，真正的流量分发交给 L4/L7 负载均衡。两者叠加才是生产做法，而不是二选一。

8. DNS 撑不起高可用：故障切换的真实时序

先纠正一个前提：第 7 节说的是"DNS 能做负载均衡，只是最粗的那一层"，不是"做不了"。但由此推出来的担忧是对的——只靠单值 DNS，节点挂了就是真挂。这一节讲清楚：那个场景为什么无解、DNS 能补救多少、完整的可用性应该由谁保证。

8.1 先拆开"DNS 返回的那个节点"

"DNS 返回美国节点"里的这个 IP，背后可能是四种完全不同的东西，故障半径差三个数量级：

这个 IP 背后是	挂掉时的影响	谁兜底
一台裸服务器	美国用户全部失败	只能靠 DNS 换记录
一个 L4 负载均衡的 VIP（双机）	单机挂 → 秒级切换	VRRP / Keepalived 漂移
一个 Anycast 入口（多地同 IP）	某地机器挂 → 撤销 BGP 宣告	路由收敛
一个 CDN 边缘集群	通常内部已有副本	CDN 自己

结论：那个场景之所以"无解"，不是因为 DNS 不行，而是因为从 DNS 到服务之间没有任何冗余，DNS 成了唯一会切换的东西。

8.2 DNS 的三层补救，但都有延迟

补救一：返回多条 A 记录，给客户端留退路。 实测对比：

www.cloudflare.com  A 104.16.123.96 / 104.16.124.96   TTL 6     ← 两条 + 超短 TTL
www.taobao.com      CNAME → 淘宝 CDN，再回两条 A        TTL 50    ← CDN 多 IP
www.bit-labs.cn     A 1.14.2.11                         TTL 600   ← 单条，真单点

多条记录时，浏览器和部分客户端会在连接失败后尝试下一个地址（curl、Go 等会遍历地址列表）。但不是所有客户端都这样：有的只取第一条，失败就直接报错。所以多 A 是补救，不是保证。

补救二：带健康检查的故障转移（GTM / Route53 failover / Cloudflare LB）。 权威侧定期探测节点，节点挂了就不再返回它。但"探测到"不等于"用户立刻恢复"：

图：一次 DNS 故障转移要等多久

sequenceDiagram
    participant U as 美国用户
    participant R as 递归解析器
    participant G as GTM 探测
    participant N as 美国节点
    N--xG: 节点挂掉
    G->>G: 连续 3 次失败才判定（20~30s）
    G->>G: 记录改成备用 IP（毫秒级）
    R-->>U: 缓存里的旧 IP 还要等 600s 才过期
    U->>N: 这 600s 内继续连旧 IP，继续失败

探测判定 20~30s  +  改记录 ~0s  +  用户侧旧缓存 ≤ TTL（600s）
──────────────────────────────────────────────────────────
最坏恢复时间 ≈ 10 分钟

这就是"只靠 DNS 做高可用"的致命伤：TTL 越长越稳（权威压力小），但切换越慢。把 TTL 压到 30~60 秒，最坏时间才能压到分钟以内，代价是权威查询量上升。

补救三：权威自己也要高可用。 bit-labs.cn 有 dns31/dns32 两组 NS，而 dns31.hichina.com 自己还解析出 8 个 IP——这是权威侧的 Anycast。权威挂了才是真正的"全站消失"，这一层必须先冗余。

8.3 更彻底的做法：Anycast 让 DNS 不参与故障切换

大厂和 CDN 的做法是：入口永远是一个固定的 Anycast IP，全球解析到的都是它；某个机房挂了就撤销该机房的 BGP 宣告，路由在秒级到几十秒内把流量送到别的机房。

DNS 记录完全不用改，没有 TTL 等待；
"美国节点挂了"对用户基本无感；
代价：需要自己的 AS 号和 IP 段，或者买云厂商的 Anycast 产品。

所以"DNS 里只有一条 A 记录"有时反而是高可用——冗余藏在 IP 后面，不在 DNS 里。

8.4 RTO 阶梯：故障粒度决定恢复时间

故障粒度	兜底机制	用户感知的不可用
单个后端进程挂	LB 健康检查摘除	1~5 秒
单台 LB 挂	双机 VIP 漂移 / Anycast	1~10 秒
单机房挂（但有多机房）	撤销 BGP / GTM 切换	秒级 ~ 分钟级
单机房挂 + DNS 单值 + TTL 600	只能等 DNS	最长 10 分钟
DNS 权威全挂	多 NS + Anycast	秒级 ~ 分钟级

8.5 回到 bit-labs.cn：现在就是一个真实的单点

www.bit-labs.cn  A  1.14.2.11  TTL 600   ← 单值，无健康检查

含义很直接：这台机器挂了，全球用户要等 10 分钟（TTL 到期才可能拿到新地址），这期间没有任何机制会替你改记录。最小成本改造顺序：

加第二条 A（另一台机器 / 另一个可用区），TTL 降到 60；
接 CDN 或全局流量管理（GTM），www 用 CNAME 交出去，换来健康检查 + 就近 + 秒级摘除；
裸域 bit-labs.cn 用 CNAME 展平 / ALIAS 接同一套；
入口后面补 L4 双机——DNS 再快，也快不过 LB 的 1 秒。

一句话：DNS 不是高可用方案，它只是"入口选路"。 高可用的本质是三层叠加：每层有备份（多 NS、多 IP、多实例、多机房）+ 快速检测（健康检查、BGP）+ 客户端有退路（多地址重试）。

9. 常见误区（来自本次追问）

❌ "DNS 只是翻译域名，跟负载均衡没关系"
→ ✅ DNS 能做，只是粒度粗、有缓存延迟、不带健康感知。定入口位置用 DNS，分流量用 LB。
❌ "自己搭权威 DNS = 一台 VPS 开个 53 端口"
→ ✅ 还要：注册 NS 名与 glue、关掉递归防滥用、至少双机、抗 DDoS、DNSSEC。缺 glue 会直接解析链断裂。
❌ "把 TTL 改小，切换就能立刻生效"
→ ✅ 已经缓存出去的旧记录，仍要等旧 TTL 到期；改小只影响后续缓存。
❌ "查一个不存在的子域应该报 NXDOMAIN"
→ ✅ bit-labs.cn 有泛解析 *.bit-labs.cn，任何子域都会拿到 101.200.231.29。排查时要先想到通配记录。
❌ "裸域也能 CNAME 到 CDN"
→ ✅ zone 顶点不能有 CNAME（会和 NS/SOA 冲突），必须用 CNAME 展平、ALIAS/ANAME，或让 DNS 商帮你回源。
❌ "递归和权威是同一种服务器"
→ ✅ 权威只讲"归谁管"（迭代），递归负责"问到结果"（递归）；开放递归还是一种被攻击者滥用的漏洞。
❌ "DNS 能做负载均衡，就等于有 DNS 就高可用"
→ ✅ DNS 只是分钟级兜底：健康检查几十秒 + 旧缓存等 TTL。真正的秒级切换在 LB 和 Anycast 上，DNS 是最后一道防线，不是第一道。
❌ "返回多条 A 记录，客户端就一定会在失败后换下一个"
→ ✅ 浏览器多半会，但 curl、自研程序、部分系统库只取第一条，失败就直接报错。多 A 是补救，不是保证。

10. 三句话回顾

是什么：DNS 是分级、可缓存的名字解析系统，把域名翻译成 IP；权威服务器是每个 zone 的"官方档案"。
怎么工作：客户端问递归器，递归器从根开始逐级拿委派，最后问到权威拿到答案，再按 TTL 缓存。
怎么用：日常托管在云解析即可；自建权威的技术门槛不高，难的是 glue、双活、抗攻击；DNS 能做粗粒度负载均衡，精细分流交给 L4/L7；但高可用不能只靠 DNS——秒级靠 LB 与 Anycast，分钟级才轮到 DNS 的故障转移。

附录：实测命令

# Windows 自带
Resolve-DnsName www.bit-labs.cn -Type A
nslookup www.bit-labs.cn dns31.hichina.com      # 绕过缓存，直接问权威
nslookup -type=soa bit-labs.cn 8.8.8.8
Resolve-DnsName bit-labs.cn -Type NS -Server 8.8.8.8

# Linux/macOS 更顺手
dig www.bit-labs.cn A
dig +trace www.bit-labs.cn        # 从根开始，逐跳显示委派链
dig @a.dns.cn bit-labs.cn NS      # 直接问顶级域服务器
dig @dns31.hichina.com www.bit-labs.cn A +norec   # 验证权威的非递归应答

排查口诀：先分清"解析问题"还是"连接问题"——nslookup @权威 有答案但浏览器打不开，那就是本地缓存 / CDN / 证书 / 端口的问题，别在 DNS 上浪费时间和精力。

附：延伸问答

问：自己搭了权威 DNS，还需要递归解析器吗？ 答：需要。客户端和权威之间一定隔着递归器（运营商或公共 DNS）；自建权威只承担"回答本 zone 的记录"，不替用户跑腿。
问：DNS 会被"污染"怎么办？ 答：查询链路上被伪造应答。解法是 DNSSEC（验签）或 DoH/DoT（加密传输），二者解决的是不同环节的问题。
问：CDN 和多 A 记录会冲突吗？ 答：不会，但用途不同。CDN 靠 CNAME 把域名交给 CDN 自己的权威，由它按地域返回边缘 IP；你直接写多 A 是在自己的权威上做分流。两者可以叠加但容易互相覆盖，选一种。
问：bit-labs.cn 想上线 IPv6 要改什么？ 答：在权威上加 www AAAA 与裸域 AAAA，同时确认服务器/负载均衡有 IPv6 地址与路由，再逐步放量。

修订记录

v1 2026-11-02：初稿，基于 bit-labs.cn 的实测解析数据整理。
v2 2026-11-02：新增第 8 节「DNS 撑不起高可用」：故障半径拆解、切换时序图与 10 分钟最坏估算、RTO 阶梯表、Anycast 反例、bit-labs.cn 单点改造顺序；常见误区 +2 条；第 1 节问题清单补"可靠性层"。

加载评论中…

暂无上一篇

暂无下一篇