前端工程师的 DNS 基础知识

Category（分类）: Other Status: 已整理

原文从“域名如何逐级解析、什么是权威 DNS、TTL 和 hosts”展开。本文尽量保留这条学习路线，同时修正域名层级、递归/迭代查询、DNS 记录和浏览器缓存等容易被误解的地方，并补充 DNSSEC、DoH/DoT 与现代排障方法。

一、DNS 是什么

DNS（Domain Name System，域名系统）把人类容易记忆的域名映射为 IP 地址以及其他服务信息。它不是一台保存所有域名的超级服务器，而是一套按层级委派、由缓存加速的分布式命名系统。

访问网站时，大致发生两件事：

DNS 解析器为域名查询 A/AAAA 等记录，得到一个或多个 IP 地址；
浏览器再使用 IP 地址，通过 HTTP/HTTPS 与目标服务建立连接。

DNS 只负责名称解析，不负责证明“这个 IP 一定属于你想访问的网站”。HTTPS/TLS 证书、应用鉴权和服务端安全策略仍然不可替代。

二、域名、根域和顶级域

1. 域名从右向左阅读

以完全限定域名（FQDN）www.example.com. 为例，最后的点也有意义：

www . example . com .
 │       │       │   │
主机/子域  注册域名  顶级域  根域

. 是 DNS 命名空间的根；
com 是顶级域（TLD）；
example.com 通常称为注册域名、可注册域名或二级域名；
www.example.com 是 example.com 下的子域名，www 也可以只是一个主机名标签。

日常书写时通常省略末尾根点，但在 DNS 配置文件中，末尾的点可以用来表示绝对域名，避免被自动拼接 $ORIGIN。

“二级域名”“三级域名”在中文语境中经常被混用。由于公共后缀可能是 co.uk、com.cn 等多级结构，实际判断注册边界应参考公共后缀列表和注册局规则，不能只按点号数量判断。

2. 根服务器不是 13 台机器

根区由 13 个根服务器标识（a.root-servers.net 到 m.root-servers.net）提供服务，每个标识背后都有分布在许多国家和网络中的多个 Anycast 实例。

根服务器主要告诉递归解析器“负责 .com、.cn、.win 等顶级域的服务器在哪里”，它们通常不会直接返回 www.example.com 的最终 IP。根服务器很重要，但不是“13 台机器全部宕机后 DNS 立刻完全停止”：递归解析器仍可能使用缓存中的记录和委派信息一段时间，系统也有多层冗余。

根服务器的当前列表可参考 IANA Root Servers。

3. 顶级域服务器

顶级域服务器管理某个顶级域下的委派信息。例如查询 www.example.com 时，根服务器会把解析器引向 .com 顶级域服务器；.com 服务器再告诉解析器 example.com 的权威名称服务器。

顶级域的分类、数量和政策会随时间变化。原文提到的 2006 年 TLD 数量和“最常见的 7 个通用顶级域”只适合作为历史背景，不能作为现在的完整列表。.arpa 是基础设施用途的特殊顶级域，常用于反向解析等场景，并不等同于普通注册型 TLD。

三、DNS 中有哪些服务器

1. Stub Resolver：应用或操作系统的存根解析器

浏览器、操作系统或本地网络中的客户端通常不会自己遍历根区，而是把查询交给一个配置好的递归解析器。这个客户端部分可以称为 stub resolver。

浏览器还可能有自己的 DNS 缓存或使用浏览器内置的安全 DNS；操作系统也可能把查询交给路由器、企业 DNS、运营商 DNS 或公共 DNS。不同系统和浏览器的具体顺序并不完全相同。

2. Recursive Resolver：递归解析器

递归解析器代表客户端完成查询，并缓存结果。它可以是：

家庭路由器转发的运营商 DNS；
企业内网 DNS；
云厂商或公共 DNS；
本机运行的 Unbound、dnsmasq 等服务。

客户端请求递归服务时，希望得到最终答案、别名链或明确错误，而不是自己继续访问根和顶级域服务器。

3. Root、TLD 与 Authoritative DNS

权威 DNS 服务器保存某个 DNS zone 的正式记录。例如 example.com 的权威服务器由该域名的注册人或 DNS 服务商管理。

域名注册商（Registrar）和权威 DNS 服务商可以是同一家公司，也可以不是同一家公司。注册商负责注册和父区委派，权威 DNS 服务商负责保存并回答该 zone 内的记录。父区通过 NS 记录把域名委派给权威名称服务器，通常会配置多个服务器以提高可用性。

原文用 sunhao.win 举例说明“把域名授权给 DNS 服务商”。这个理解方向是对的，但不能把“域名在哪里购买”和“当前由哪家权威 DNS 服务商解析”简单画等号；应以父区中的 NS 委派为准。

四、递归查询和迭代查询

1. 一次常见的解析流程

以用户访问 www.example.com 为例：

浏览器/操作系统
      │
      ▼
本地存根解析器 ──► 本地缓存、hosts 等
      │
      ▼
递归解析器 ──命中缓存──► 返回结果
      │ 未命中
      ▼
根服务器 ──► .com 顶级域服务器 ──► example.com 权威服务器
      │                                      │
      └────────────── 缓存结果并返回 ◄────────┘

真实网络中还可能出现 CNAME 链、DNSSEC 记录、IPv6、负载均衡、分流 DNS 和服务发现记录，因此不一定只有一次 A 查询。

2. 递归查询

主机向递归解析器发起递归请求时，解析器负责继续查询并返回最终答案或错误。客户端通常只需要知道“这个域名解析到了什么”或“查询失败”。

3. 迭代查询

递归解析器向根、TLD 和权威服务器查询时，服务器可能只返回下一步的 NS 委派和必要的 glue 地址，递归解析器再向下一个服务器查询。这种“告诉你下一步去哪里”的方式就是迭代过程。

所以更准确的说法是：客户端通常请求递归服务，递归解析器在背后执行一系列迭代查询。不能把整条链路都简单称为“递归查询”。

4. DNS 主要使用 UDP，但不只使用 UDP

传统 DNS 使用 UDP/TCP 的 53 端口：

UDP 开销小，适合普通查询；
如果响应过大、被截断或需要可靠传输，解析器可以改用 TCP；
zone transfer 等区域传送通常使用 TCP；
EDNS 扩展允许更大的 UDP 响应，DNSSEC 也会增加响应体积；
DNS over TLS（DoT）通常使用 853 端口；
DNS over HTTPS（DoH）把 DNS 查询封装在 HTTPS 中，通常走 443 端口。

UDP 本身不保证报文一定到达，DNS 客户端会超时、重试或更换服务器。现代网络中还应考虑 QUIC、DoH 和 DoT，不能再简单地总结为“DNS 主要都是 UDP”。

五、常见 DNS 记录

DNS 记录称为 Resource Record（RR），不同类型表达不同信息：

类型	用途	示例或注意事项
`A`	域名映射到 IPv4 地址	`example.com. IN A 192.0.2.10`
`AAAA`	域名映射到 IPv6 地址	`example.com. IN AAAA 2001:db8::10`
`CNAME`	把别名指向规范名称	目标仍需继续解析，不能与同名的其他数据随意共存
`NS`	指定 zone 的权威名称服务器或子域委派	常出现在 zone 顶部或父区委派处
`SOA`	描述 zone 的权威起点、序列号和维护参数	也参与负缓存等机制
`MX`	指定邮件交换服务器	`preference` 数值越小通常优先级越高
`TXT`	保存文本型元数据	常用于 SPF、DKIM、域名验证等，具体语义由使用它的协议定义
`SRV`	描述某类服务的主机和端口	常见形式为 `_service._proto.example.com`，不只用于 Microsoft AD
`CAA`	限制哪些 CA 可以为域名签发证书	属于证书签发策略，不是 HTTP 鉴权
`PTR`	反向解析 IP 到名称	IPv4 使用 `in-addr.arpa`，IPv6 使用 `ip6.arpa`
`DS`、`DNSKEY`、`RRSIG`	DNSSEC 的密钥、签名和委派链	用于验证 DNS 数据来源和完整性
`HTTPS`、`SVCB`	描述服务端点、协议和连接参数	现代浏览器和网络服务可按需使用

CNAME 是别名记录。解析器需要继续查询它指向的规范名称，最终可能得到 A/AAAA 等记录。一个名称如果配置了 CNAME，通常不能再同时配置 A、MX、TXT 等其他数据；zone apex 的 CNAME 还会与必须存在的 SOA/NS 冲突。标准 CNAME 不能无条件放在 zone apex。ANAME 已由 RFC 8976 标准化，用于表达 apex 别名，但权威 DNS 和解析器的部署支持仍需确认；DNS 服务商还可能提供 ALIAS、CNAME flattening 等控制台能力。它们都不等于标准 CNAME 可以直接放在根域。

2. NS 不会自动让 A 记录失效

原文“NS 记录优先于 A 记录、同一主机有 NS 时 A 记录不生效”的说法不正确，应删除。NS 记录表达的是名称服务器委派，A/AAAA 记录表达地址；它们的作用和查询类型不同。DNS 是否返回某条记录取决于 zone、委派边界、查询类型和服务器实现，不能用“NS 优先级高于 A”概括。

3. URL 转发不是标准 DNS 记录

一些注册商控制台提供“显性 URL”“隐形 URL”或“URL 转发”选项，但这通常是 HTTP 重定向、反向代理或服务商自定义功能，不是 DNS 标准 RR。DNS 没有能把完整 URL 作为访问目标并触发 HTTP 重定向的标准 RR；TXT 等记录虽然可以保存 URL 文本，但不会改变浏览器地址栏。

六、权威应答、缓存应答和 TTL

1. 权威应答

如果响应来自负责该 zone 的权威数据，DNS 响应通常会设置 AA（Authoritative Answer）标志。权威服务器也可能返回 NXDOMAIN 或 NODATA，表示名称不存在或没有请求的记录类型。

2. 非权威应答

递归解析器从自己的缓存返回答案时，通常不是权威应答。非权威不等于错误，它只表示这个服务器不是该 zone 的权威来源。排查时可以用 dig 查看 ANSWER、AUTHORITY、AD 和 AA 等信息。

3. TTL 是缓存时间上限

DNS 记录中的 TTL（Time To Live）以秒为单位，通常作为递归解析器缓存这条数据的期限上限。TTL 到期后，解析器通常需要重新向上游查询，但解析器也可能设置上限、使用 stale-cache 等策略；实际客户端还可能有浏览器、操作系统、路由器、CDN 或应用层缓存。

修改权威记录后，不存在一个瞬间同步到全球的“DNS 传播”过程。旧记录会按照各级缓存的 TTL 逐步过期，否定结果也可能因负缓存而持续一段时间。发布前应提前降低 TTL，发布后再按稳定性提高，而不是修改后反复刷新浏览器等待“传播”。

HTTP 缓存和 DNS 缓存是两套不同机制：清除 DNS 缓存不一定清除浏览器的 HTTP 缓存，DevTools 的 Disable cache 也不一定清除所有 DNS 缓存。

七、hosts 文件与本地调试

在 DNS 出现之前，主机名和 IP 可以直接写在本地 hosts 文件中。今天仍可以用它做本地调试或临时覆盖，但具体解析顺序由操作系统、浏览器和网络配置共同决定，不能对所有平台绝对断言“浏览器缓存一定先于 hosts”。

常见位置：

Windows：C:\Windows\System32\drivers\etc\hosts；
Linux、macOS：/etc/hosts。

示例：

127.0.0.1  article.local
::1        article.local

hosts 适合开发调试，不适合用来给公众网站“加速”。长期遗留的 hosts 条目可能导致访问错误、证书不匹配或安全风险，使用完应及时删除。

八、现代 DNS 调试方法

1. 查询指定记录

# 查询 IPv4、IPv6 和别名
dig A example.com
dig AAAA example.com
dig CNAME www.example.com

# 直接询问指定递归解析器
dig @1.1.1.1 A example.com
dig @8.8.8.8 A example.com

# 查看权威委派链，不使用普通递归缓存完成整条查询
dig +trace example.com

在 Windows 中也可以使用：

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

dig +trace 适合理解根、TLD 到权威服务器的路径，但它不等于普通用户每次访问时的实际路径；企业网络、防火墙和本地配置也可能阻止某些直接查询。

2. 查看 DNSSEC

dig +dnssec example.com
dig +dnssec +multi example.com

DNSSEC 的签名验证应由支持验证的递归解析器完成。客户端看到 RRSIG 不代表自己已经验证了整条信任链，排查时要结合 AD 标志、解析器配置和专用 DNSSEC 工具判断。

3. 清理缓存

不同系统的命令不同，且只能清理其中一层：

# Windows
ipconfig /flushdns

# systemd-resolved 的 Linux 发行版
sudo resolvectl flush-caches

macOS 可按系统版本使用 dscacheutil 和 mDNSResponder 相关命令。浏览器内部页面和命令会随版本变化，原文提到的 chrome://net-internals 方案不应再当作通用教程；更可靠的方式是用 dig、系统命令和 DevTools Network/Performance 记录定位问题。

九、DNS 安全与隐私

1. DNSSEC：验证来源和完整性

DNSSEC 使用 DNSKEY、DS、RRSIG 等记录建立从根区到目标 zone 的信任链，让支持验证的解析器能够检测并拒绝未通过验证的篡改或伪造数据。DNSSEC 本身不阻止攻击，也不会加密查询内容，不能隐藏用户查询了哪个域名。

2. DoH 和 DoT：保护客户端到解析器的传输

DoH 把 DNS 查询放进 HTTPS，DoT 则通过 TLS 传输 DNS。它们可以降低本地网络被动监听和简单篡改的风险，但要注意：

解析服务商仍可能看到查询内容；
使用了 DoH 不等于服务端回答一定真实，DNSSEC 负责的是数据验证；
企业网络的安全策略、家长控制和分流规则可能受到影响；
应选择可信解析器并阅读其隐私策略。

3. 常见风险

DNS 缓存投毒和伪造响应；
恶意或配置错误的递归解析器；
DNS rebinding 让同一域名在不同时间指向不同地址；
公共解析、企业内网解析和公网权威解析不一致导致的 split-horizon 问题；
残留 CNAME 指向已删除资源导致的子域接管风险。

DNS 解析结果不能替代服务端鉴权。即使 DNS 指向正确，也应使用 HTTPS、证书校验、Host/Origin 校验和应用层权限控制。

十、原文 `sunhao.win` 案例如何阅读

原文最后用 dig +trace www.sunhao.win 展示了根服务器、.win 顶级域和 sunhao.win 权威服务器之间的关系。这个案例的教学目的仍然有效，但其中的域名状态、NS 地址、TTL、IP 地址和 dig 版本都是当时的快照，不能直接当作今天的解析结果。

现在可以用下面的命令观察同样的过程：

dig +trace www.example.com
dig NS example.com
dig +noall +answer +authority www.example.com A

排查具体业务时，应记录查询时间、查询的解析器、网络环境、记录类型和 TTL，不能只凭一次浏览器访问下结论。

原文：前端工程师的 DNS 基础知识（本地归档）
RFC 1034：Domain Names—Concepts and Facilities
RFC 1035：Domain Names—Implementation and Specification
IANA Root Servers
RFC 8484：DNS Queries over HTTPS
RFC 9364：DNS Security Extensions (DNSSEC)
RFC 8976：ANAME DNS Resource Record
Google Public DNS：DNS-over-HTTPS