| 8 张知识图，从递归查询、缓存与 TTL，讲到 DoH、DoT、DNSSEC，最后用 dig 串起一套可复用的排障路径。
当你在浏览器里输入 deepjerry.com，浏览器最终需要的是一个可以建立网络连接的 IP 地址。
那么，这个地址是谁查到的？是不是浏览器从根服务器一路问到网站服务器？改完 DNS 记录后，为什么有人立刻生效，有人却还看到旧地址？HTTPS 已经加密，DNS 查询还会不会暴露？用了 DoH、DoT 或DNSSEC，是不是就彻底安全了？
这篇文章通过 8 张知识图卡，从一次域名解析开始，依次讲清 DNS 的分层角色、递归与迭代、缓存与TTL、常见记录、隐私边界、加密 DNS、DNSSEC，以及如何用 dig 定位故障。
看完之后，你应该不只记住“DNS 把域名变成 IP”，还能够判断：问题发生在哪一层、谁能看到什么、哪种安全机制解决的究竟是什么问题。
一、DNS 不是一台“互联网电话簿”
把 DNS 比作电话簿，有助于入门，却也容易让人误以为：互联网上存在一台保存所有域名与 IP 的服务器。
真实的 DNS 是一套分层、分布式的查询系统。一次常见解析会涉及几类角色：
- 应用或浏览器调用操作系统提供的解析接口；
- Stub resolver（存根解析器）把问题交给递归解析器；
- Recursive resolver（递归解析器）从缓存回答，或者继续向 DNS 层级查询；
- 根、顶级域和目标域名的权威服务器，分别对自己负责的 zone 提供权威数据。
这里的“权威”不是“知道全互联网的答案”，而是“对自己负责的区域数据有权威”。根服务器通常告诉递归解析器下一步去哪里找，并不会直接返回目标网站的 IP。
二、冷缓存时，一次解析经历了什么？
假设递归解析器没有任何可用缓存，要查询 www.example.com 的地址。简化后的过程是：
- 浏览器通过系统解析能力把请求交给存根解析器；
- 存根解析器请求递归解析器给出最终答案；
- 递归解析器询问根服务器，获得 .com 的委派信息；
- 递归解析器询问 .com 顶级域服务器，获得 example.com 的权威服务器信息；
- 递归解析器询问目标域名的权威服务器，取得 A、AAAA，或需要继续追随的 CNAME；
- 递归解析器缓存结果，并把最终答案返回给客户端。
这是一张教学用的“冷缓存路线图”，不是每次访问都会固定产生同样数量的查询。缓存、转发器、CNAME 链、网络策略和 QNAME minimisation 都可能改变实际路径。
现代递归解析器还可能采用 QNAME minimisation：对暂时不需要知道完整名称的上游，只发送获得下一次委派所需的最少信息。因此，不能武断地说每一层服务器都会看到完整域名。
三、递归查询和迭代查询，不是一回事
这两个概念经常被混在一起。
客户端对递归解析器通常表达的是：请替我得到最终答案，或者明确告诉我失败。这属于递归模式。
递归解析器向 DNS 层级继续查找时，通常采用迭代方式：某一层没有最终答案，就返回更接近目标区域的服务器信息，也就是 referral（转介）；递归解析器再继续问下一层。
所以，更准确的关系是：客户端提出递归请求；递归解析器代替客户端完成后续迭代查找。
不要把流程写成“浏览器依次访问根、顶级域和权威服务器”。普通浏览器通常没有亲自完成这条迭代链路。
四、缓存和 TTL：为什么第二次通常更快？
DNS 记录带有 TTL，表示一份记录允许被缓存多长时间，单位为秒。在缓存仍有效时，递归解析器可以直接回答，不必重新询问原始数据源。
缓存的也不只是最终 A 或 AAAA 记录。NS、CNAME、委派信息，甚至“名称不存在”的结果，都可能被缓存。因此一次热缓存查询可能绕过根服务器和顶级域服务器。
但 TTL 不是“全网统一倒计时”。不同递归解析器第一次缓存记录的时间不同；某些实现还可能在权威端暂时不可达时按规则使用 stale data（过期数据）。因此，更准确的说法是：TTL 控制缓存正常复用的期限，但 DNS 变更不会在某个整点让全世界同时刷新。
这也是为什么改完记录后，不同网络、不同递归 DNS 服务看到的新旧结果可能暂时不同。
五、A、AAAA、CNAME 到底有什么区别？
最常见的三类记录可以这样理解：
一句话记忆：A/AAAA 给地址，CNAME 给另一个名字。
如果 www.example.com 返回 CNAME，递归解析器可能继续追随别名链，直到得到目标类型的记录或遇到错误。因此，“查一个域名”不一定只对应一次上游查询。
六、HTTPS 加密了网页，DNS 查询还看得见吗？
HTTPS 保护的是 HTTP 内容在 TLS 通道中的传输。传统 DNS 通常在建立 HTTPS 连接之前发生，而且直接基于 UDP 或 TCP 的 DNS 本身不提供查询内容的机密性。
因此，网页正文已经由 HTTPS 加密，并不代表此前的传统 DNS 查询也自动加密。链路上的观察者仍可能看到 DNS 查询与响应。
但也不要反过来夸大：抓到 53 端口流量，不等于得到浏览器的完整访问历史。缓存可能让访问不产生新查询；应用可能使用自己的解析器或 DoH/DoT；一次网页加载也可能触发许多第三方域名。
谁能看到什么，还取决于观察位置：
- Stub 到递归解析器之间，是最集中的查询观察点；
- 递归解析器会看到客户端交给它的查询和相关网络元数据；
- 权威服务器通常只看到缓存未命中的查询，来源常常是递归解析器，而不是最终用户；
- 目标 IP、流量时序等网络元数据，不会仅因 DNS 加密就消失。
七、DoT、DoH 和 DNSSEC，解决的是三件事吗？
DoT 和 DoH 主要保护 DNS 客户端到 DNS 服务端这一段传输：
-
DoT（DNS over TLS）在 TLS 通道中承载 DNS，标准端口为 853；
- DoH（DNS over HTTPS）把 DNS 查询映射到 HTTPS 交换中。
它们能够降低该段链路被窃听或篡改的风险，却不能让所选递归解析器看不见查询，也不会自动加密递归解析器到权威服务器的所有后续查询。IP、连接时序、消息大小等元数据仍可能存在。
DNSSEC 解决的是另一类问题。它通过数字签名和信任链，帮助验证解析器判断 DNS 数据是否来自预期来源、内容是否被篡改，并可认证“不存在”的回答。
DNSSEC 明确不提供机密性。可以用一个不完全但好记的类比：DNSSEC 像验签，DoT/DoH 像加密信封。验签不负责藏住内容，加密信封也不替代对 DNS 数据来源的验证。
两者可以同时使用，因为它们保护的对象并不相同。
八、用 dig 分层定位 DNS 问题
真正排障时，不要只盯着“能不能打开网页”。先把 DNS 层单独拿出来验证。
建议按下面的顺序判断：
- 先看状态码、ANSWER、TTL，确认是否真是 DNS 问题；
- 对比系统默认解析器与指定解析器，观察是否存在缓存或路径差异；
- 检查 CNAME 链，确认目标名称是否还能取得 A/AAAA；
- 用 +trace 查委派在哪一层中断；
- 直接询问多台权威服务器，对比答案与 SOA serial；
- 最后检查 DNSSEC 信任链。
需要特别注意：dig +dnssec 只是请求返回 DNSSEC 相关记录，不等于本地已经验证通过。需要验证时，应使用具备验证能力的递归解析器或 delv，并检查 DS、DNSKEY、RRSIG 等信任链。
SERVFAIL 也不是“DNSSEC 错误”的同义词。上游不可达、配置故障、验证失败等多种问题都可能表现为 SERVFAIL，必须结合委派链和权威答案继续定位。
结语
DNS 解析真正值得理解的，不是“域名换成 IP”这一句，而是它背后的责任分层：客户端把问题交给谁，递归解析器如何寻找答案，权威服务器负责哪一段数据，缓存何时复用，安全机制又分别保护哪一段。
把这些边界分清之后，很多常见疑问都会变得具体：
- 访问变快，可能是命中了哪一层缓存；
- 记录未生效，应该查递归缓存还是权威数据；
- HTTPS、DoH/DoT 和 DNSSEC 分别保护什么；
- 一次 SERVFAIL 为什么不能直接下根因结论。
下次再遇到“域名解析有问题”，不要急着换 DNS 或清空所有缓存。沿着查询链，一层一层验证，答案通常就藏在边界里。
参考资料
本文关键定义与安全边界经以下权威资料复核：
- RFC 1034 — Domain Names: Concepts and Facilities
- RFC 1035 — Domain Names: Implementation and Specification
- RFC 9499 — DNS Terminology
- RFC 8767 — Serving Stale Data to Improve DNS Resiliency
- RFC 3596 — DNS Extensions to Support IPv6
- RFC 2181 — Clarifications to the DNS Specification
- RFC 9076 — DNS Privacy Considerations
- RFC 7858 — DNS over TLS
- RFC 8484 — DNS over HTTPS
- RFC 9156 — DNS Query Name Minimisation
- RFC 4033 — DNSSEC Introduction and Requirements
- ISC BIND 9 Manual Pages — dig / delv
声明：图文来源于“DJ.AI”公众号，转载在于传播更多优质信息，如涉版权问题，请联系删除！
推荐阅读：
