拓冰网站定制 
子域名挖掘前置基础 03DNS 解析流程详细版本篇定位上一篇讲了 DNS 解析的简单版——只说做了什么。本篇是详细版把每一步的输入、输出、参与者、缓存行为都展开配 mermaid 流程图。读完这一篇你应该能完整复述一个域名从输入到拿到 IP 的全过程。阅读建议先确保读懂了简单版文档 02再来读这一篇。本篇会反复提到递归解析器和权威服务器这些角色如果还分不清建议回去复习。一、详细版整体流程图下面这张图展示了一个完整的 DNS 解析流程标注了每一步的输入、输出、参与者。步骤1输入: 域名 api.example.com输出: 查本地缓存未命中未命中步骤2输入: api.example.com输出: 查解析器缓存未命中步骤3输入: api.example.com输出: .com 的 TLD 服务器地址.com 归 TLD 管步骤4输入: api.example.com输出: example.com 的权威 NS 地址example.com 归权威 NS 管步骤5输入: api.example.com输出: api 的 A 记录 IP1.2.3.4返回 IP步骤6输入: IP 1.2.3.4输出: 缓存 返回给浏览器步骤7输入: IP 1.2.3.4输出: 发起 HTTPS 连接用户浏览器输入: api.example.com浏览器 DNS 缓存操作系统 DNS 缓存含 hosts 文件递归解析器如 8.8.8.8 或 ISP DNS递归解析器缓存步骤3: 问根服务器根 DNS 服务器a.root-servers.net 等步骤4: 问 TLD 服务器.com TLD 服务器a.gtld-servers.net 等步骤5: 问权威服务器example.com 权威 NSns1.example.com后续 HTTP/HTTPS 请求下面逐步展开每一步都说清谁在做、输入是什么、输出是什么、缓存行为是什么。二、步骤 1浏览器查本地缓存2.1 这一步在做什么用户在浏览器输入api.example.com浏览器不会立刻去问 DNS 服务器——先查本地缓存看这个域名是不是刚查过。2.2 参与者层级说明典型缓存时长浏览器 DNS 缓存Chrome、Firefox 等浏览器自己的缓存几分钟到几小时操作系统 DNS 缓存系统级缓存取决于 OS 配置hosts 文件本地静态映射文件永久除非手动改2.3 输入与输出输入: api.example.com 输出: ├─ 命中缓存 → 直接拿到 IP流程结束不走后续步骤 └─ 未命中 → 转入步骤 2把请求交给操作系统2.4 缓存行为浏览器缓存按 TTL 老化操作系统缓存如 Windows 的 DNS Client 服务也按 TTL 老化hosts 文件是静态的优先级最高——如果 hosts 里有api.example.com永远命中挖掘者关注本地缓存会让你拿到上次查过的旧结果。这就是为什么你用dig或nslookup查同一个域名可能拿到不同结果——你的查询可能被本地缓存截胡了。三、步骤 2操作系统转给递归解析器3.1 这一步在做什么本地缓存没命中操作系统把这个查询请求转给配置的递归解析器。3.2 参与者角色说明操作系统根据配置决定把请求转给哪个递归解析器递归解析器通常由 DHCP 下发家庭/办公网络或手动配置如 8.8.8.83.3 输入与输出输入: api.example.com来自浏览器 输出: ├─ 递归解析器缓存命中 → 直接返回 IP流程结束 └─ 递归解析器缓存未命中 → 转入步骤 3递归解析器开始跑链路3.4 缓存行为递归解析器有自己的缓存按 TTL如果之前有人通过这个解析器查过api.example.com缓存里就有直接返回缓存未命中时递归解析器开始跑后面的链路挖掘者关注你用subfinder这类工具做 DNS 查询时默认走的就是递归解析器——拿到的是缓存数据。如果你想拿实时数据要直接向权威服务器查。四、步骤 3递归解析器问根服务器4.1 这一步在做什么递归解析器本地缓存没命中开始跑链路。第一站是根服务器。4.2 参与者角色说明递归解析器跑腿员替用户跑全程根 DNS 服务器全球 13 组A-M用 anycast 部署实际几百台4.3 输入与输出输入: api.example.com 输出: └─ 根服务器不直接给 IP 但告诉递归解析器: .com 归 .com TLD 服务器管 并返回 .com TLD 服务器的 NS 列表如 a.gtld-servers.net4.4 根服务器怎么知道要去哪问根服务器内置了所有 TLD 的指针——这是它的核心数据。只要你查的域名有顶级域.com、.cn、.org根服务器就知道该去哪个 TLD 服务器。4.5 缓存行为递归解析器会把.com的 TLD 在哪也缓存下来下次查任何.com域名不用再问根直接问 TLD挖掘者关注根服务器只做迭代应答——它不帮你跑全程只指路。全球几十亿用户的查询都打到根如果每个都帮跑全程根早就瘫痪了。五、步骤 4递归解析器问 TLD 服务器5.1 这一步在做什么递归解析器拿到 TLD 服务器地址后去问 TLD“api.example.com在哪”5.2 参与者角色说明递归解析器继续跑腿.com TLD 服务器管.com下所有二级域5.3 输入与输出输入: api.example.com 输出: └─ TLD 服务器不直接给 IP 但告诉递归解析器: example.com 归 ns1.example.com 等 NS 管 并返回 example.com 的权威 NS 列表5.4 TLD 服务器怎么知道权威 NS 是谁TLD 服务器存着它管辖的所有二级域的注册信息——当你注册example.com时注册商会把你的权威 NS 写到 TLD 的注册信息里。所以 TLD 知道example.com归哪些 NS 管。5.5 缓存行为递归解析器把example.com的权威 NS 是谁缓存下来后续查www.example.com、api.example.com都不用再问 TLD挖掘者关注通过查 TLD你能拿到目标域名的 NS 记录——这就是找到权威 NS的方法。子域名挖掘里知道权威 NS 是谁才能做针对性查询直接向权威查绕过缓存。六、步骤 5递归解析器问权威服务器6.1 这一步在做什么递归解析器拿到权威 NS 地址后终于去问权威“api.example.com的 A 记录是什么”6.2 参与者角色说明递归解析器跑腿员到终点了example.com 的权威 NS存着 example.com 及其子域未委派时的最终记录6.3 输入与输出输入: api.example.com查 A 记录 输出: └─ 权威服务器返回: api.example.com 的 A 记录 1.2.3.4 或返回 NXDOMAIN 这个子域不存在 或返回 CNAME 这是个别名再去查 CNAME 指向的域名6.4 权威服务器怎么知道答案权威 NS 存着example.com的区域文件Zone File。这个文件里写了example.com自己的 A 记录所有未委派子域的 A、CNAME、MX 等记录已委派子域的 NS 指针指向子域自己的权威 NS6.5 缓存行为递归解析器把这个结果缓存TTL 是由权威服务器在记录里指定的TTL 决定这个结果会在缓存里活多久挖掘者关注这是整个流程里唯一能拿到真实、最新数据的点。TTLTime To Live记录存活时间决定了数据新鲜度——TTL 很短说明目标经常变更 IP可能是 CDN 调度TTL 很长说明相对稳定可能是固定服务器。这个值应该记录下来。七、步骤 6递归解析器缓存并返回7.1 这一步在做什么递归解析器拿到权威服务器的 IP 结果后缓存一份然后返回给用户的浏览器。7.2 参与者角色说明递归解析器缓存 转发浏览器收到 IP准备发起 HTTP 连接7.3 输入与输出输入: api.example.com 的 A 记录 1.2.3.4来自权威服务器 输出: ├─ 递归解析器缓存: api.example.com → 1.2.3.4TTL300秒 └─ 返回给浏览器: IP 是 1.2.3.47.4 缓存行为递归解析器按 TTL 缓存结果后续在 TTL 内再查api.example.com直接返回缓存不再跑链路挖掘者关注这就是为什么被动 DNS 数据Passive DNS来自递归解析器缓存的历史数据可能不准——你拿到的可能是 TTL 还没过期的旧 IP而目标已经把 IP 改了。八、步骤 7浏览器发起 HTTP 连接8.1 这一步在做什么浏览器拿到 IP 后开始发起 HTTP/HTTPS 连接。这一步已经超出 DNS 解析的范围但为了流程完整简单提一下。8.2 后续动作动作说明建立 TCP 连接与 IP 的 80 或 443 端口三次握手TLS 握手HTTPS协商加密、验证证书、发送 SNI发送 HTTP 请求请求行、请求头、请求体接收响应状态码、响应头、响应体这一步后续会在Web 与网络层那篇文档里展开。九、特殊情况CNAME 链与委派上面讲的是最简单的情况——权威服务器直接给 A 记录。但实际查询中会遇到两种特殊情况需要多跑几趟。9.1 CNAME 链别名指向另一个域名如果api.example.com不是 A 记录而是 CNAME 记录指向另一个域名递归解析器要再去查那个域名的 IP。查询: api.example.com 权威返回: CNAME api.lb.amazonaws.com 递归解析器要继续查 api.lb.amazonaws.com 的 IP: → 问 .com TLD: amazonaws.com 的 NS 在哪 → 问 amazonaws.com 权威: api.lb.amazonaws.com 的 IP → 拿到 IP挖掘者关注CNAME 链是架构线索金矿——它指向*.cloudfront.net就知道用了 CloudFront CDN指向*.elb.amazonaws.com就知道后端是 AWS 负载均衡。每条 CNAME 都是一条架构线索。9.2 委派子域有自己的权威服务器如果api.example.com被委派了有自己的权威 NS主域权威服务器不会直接给 A 记录而是给 NS 指针。查询: api.example.com 主域权威返回: api.example.com 的 NS ns1.apiteam.net 递归解析器要继续问 ns1.apiteam.net: → 查询 ns1.apiteam.net 的 IP再去走一遍解析 → 问 ns1.apiteam.net: api.example.com 的 A 记录 → 拿到 IP挖掘者关注委派意味着子域有独立的权威服务器。子域名挖掘里发现一个子域有 NS 记录就要把它当成新的主域重新挖——这是 Zone Delegation 的核心概念下一篇会展开。十、完整流程的输入输出汇总把每一步的输入输出收拢成一张表方便对照。步骤参与者输入输出1浏览器/操作系统域名 api.example.com缓存命中则返回 IP未命中转交2递归解析器域名 api.example.com缓存命中则返回 IP未命中跑链路3根服务器api.example.com.com的 TLD 服务器地址4TLD 服务器api.example.comexample.com的权威 NS 地址5权威服务器api.example.comA 记录 IP1.2.3.4 或 NXDOMAIN 或 CNAME6递归解析器A 记录 IP1.2.3.4缓存并返回给浏览器7浏览器IP1.2.3.4发起 HTTP/HTTPS 连接10.1 特殊情况下的额外步骤场景额外步骤CNAME 链拿到 CNAME 后对 CNAME 指向的域名再走一遍完整流程委派主域权威给 NS 指针后向子域权威再查一次多级 CNAMEA → B → C → IP每跳都要查一次十一、本篇小结概念一句话完整解析流程浏览器 → 本地缓存 → 递归解析器 → 根 → TLD → 权威 → 缓存 → 返回每一步的输入都是要查的域名每一步的输出根/TLD 给下一步去哪权威给最终 IP缓存行为递归解析器按 TTL 缓存影响数据新鲜度特殊情况CNAME 链要再查一遍委派要向子域权威再查一次读懂了这一篇你就理解了 DNS 解析的完整机制。下一篇我们讲 DNS 里存的数据——记录类型、分级记录、树形结构与委派、通配符。附本篇关键术语速查术语简明解释浏览器缓存浏览器自己的 DNS 缓存操作系统缓存系统级 DNS 缓存hosts 文件本地静态域名映射优先级最高递归解析器缓存递归解析器按 TTL 缓存的结果NXDOMAIN域名不存在的应答CNAME 链域名指向别名别名再指向另一个域名委派子域有独立权威服务器主域权威只给 NS 指针TTLDNS 记录在缓存中的存活时间Zone File权威服务器存的区域文件含该域所有记录被动 DNS来自递归解析器缓存的历史 DNS 数据 子域名基础03_DNS解析流程_详细版
子域名挖掘前置基础 03DNS 解析流程详细版本篇定位上一篇讲了 DNS 解析的简单版——只说做了什么。本篇是详细版把每一步的输入、输出、参与者、缓存行为都展开配 mermaid 流程图。读完这一篇你应该能完整复述一个域名从输入到拿到 IP 的全过程。阅读建议先确保读懂了简单版文档 02再来读这一篇。本篇会反复提到递归解析器和权威服务器这些角色如果还分不清建议回去复习。一、详细版整体流程图下面这张图展示了一个完整的 DNS 解析流程标注了每一步的输入、输出、参与者。步骤1输入: 域名 api.example.com输出: 查本地缓存未命中未命中步骤2输入: api.example.com输出: 查解析器缓存未命中步骤3输入: api.example.com输出: .com 的 TLD 服务器地址.com 归 TLD 管步骤4输入: api.example.com输出: example.com 的权威 NS 地址example.com 归权威 NS 管步骤5输入: api.example.com输出: api 的 A 记录 IP1.2.3.4返回 IP步骤6输入: IP 1.2.3.4输出: 缓存 返回给浏览器步骤7输入: IP 1.2.3.4输出: 发起 HTTPS 连接用户浏览器输入: api.example.com浏览器 DNS 缓存操作系统 DNS 缓存含 hosts 文件递归解析器如 8.8.8.8 或 ISP DNS递归解析器缓存步骤3: 问根服务器根 DNS 服务器a.root-servers.net 等步骤4: 问 TLD 服务器.com TLD 服务器a.gtld-servers.net 等步骤5: 问权威服务器example.com 权威 NSns1.example.com后续 HTTP/HTTPS 请求下面逐步展开每一步都说清谁在做、输入是什么、输出是什么、缓存行为是什么。二、步骤 1浏览器查本地缓存2.1 这一步在做什么用户在浏览器输入api.example.com浏览器不会立刻去问 DNS 服务器——先查本地缓存看这个域名是不是刚查过。2.2 参与者层级说明典型缓存时长浏览器 DNS 缓存Chrome、Firefox 等浏览器自己的缓存几分钟到几小时操作系统 DNS 缓存系统级缓存取决于 OS 配置hosts 文件本地静态映射文件永久除非手动改2.3 输入与输出输入: api.example.com 输出: ├─ 命中缓存 → 直接拿到 IP流程结束不走后续步骤 └─ 未命中 → 转入步骤 2把请求交给操作系统2.4 缓存行为浏览器缓存按 TTL 老化操作系统缓存如 Windows 的 DNS Client 服务也按 TTL 老化hosts 文件是静态的优先级最高——如果 hosts 里有api.example.com永远命中挖掘者关注本地缓存会让你拿到上次查过的旧结果。这就是为什么你用dig或nslookup查同一个域名可能拿到不同结果——你的查询可能被本地缓存截胡了。三、步骤 2操作系统转给递归解析器3.1 这一步在做什么本地缓存没命中操作系统把这个查询请求转给配置的递归解析器。3.2 参与者角色说明操作系统根据配置决定把请求转给哪个递归解析器递归解析器通常由 DHCP 下发家庭/办公网络或手动配置如 8.8.8.83.3 输入与输出输入: api.example.com来自浏览器 输出: ├─ 递归解析器缓存命中 → 直接返回 IP流程结束 └─ 递归解析器缓存未命中 → 转入步骤 3递归解析器开始跑链路3.4 缓存行为递归解析器有自己的缓存按 TTL如果之前有人通过这个解析器查过api.example.com缓存里就有直接返回缓存未命中时递归解析器开始跑后面的链路挖掘者关注你用subfinder这类工具做 DNS 查询时默认走的就是递归解析器——拿到的是缓存数据。如果你想拿实时数据要直接向权威服务器查。四、步骤 3递归解析器问根服务器4.1 这一步在做什么递归解析器本地缓存没命中开始跑链路。第一站是根服务器。4.2 参与者角色说明递归解析器跑腿员替用户跑全程根 DNS 服务器全球 13 组A-M用 anycast 部署实际几百台4.3 输入与输出输入: api.example.com 输出: └─ 根服务器不直接给 IP 但告诉递归解析器: .com 归 .com TLD 服务器管 并返回 .com TLD 服务器的 NS 列表如 a.gtld-servers.net4.4 根服务器怎么知道要去哪问根服务器内置了所有 TLD 的指针——这是它的核心数据。只要你查的域名有顶级域.com、.cn、.org根服务器就知道该去哪个 TLD 服务器。4.5 缓存行为递归解析器会把.com的 TLD 在哪也缓存下来下次查任何.com域名不用再问根直接问 TLD挖掘者关注根服务器只做迭代应答——它不帮你跑全程只指路。全球几十亿用户的查询都打到根如果每个都帮跑全程根早就瘫痪了。五、步骤 4递归解析器问 TLD 服务器5.1 这一步在做什么递归解析器拿到 TLD 服务器地址后去问 TLD“api.example.com在哪”5.2 参与者角色说明递归解析器继续跑腿.com TLD 服务器管.com下所有二级域5.3 输入与输出输入: api.example.com 输出: └─ TLD 服务器不直接给 IP 但告诉递归解析器: example.com 归 ns1.example.com 等 NS 管 并返回 example.com 的权威 NS 列表5.4 TLD 服务器怎么知道权威 NS 是谁TLD 服务器存着它管辖的所有二级域的注册信息——当你注册example.com时注册商会把你的权威 NS 写到 TLD 的注册信息里。所以 TLD 知道example.com归哪些 NS 管。5.5 缓存行为递归解析器把example.com的权威 NS 是谁缓存下来后续查www.example.com、api.example.com都不用再问 TLD挖掘者关注通过查 TLD你能拿到目标域名的 NS 记录——这就是找到权威 NS的方法。子域名挖掘里知道权威 NS 是谁才能做针对性查询直接向权威查绕过缓存。六、步骤 5递归解析器问权威服务器6.1 这一步在做什么递归解析器拿到权威 NS 地址后终于去问权威“api.example.com的 A 记录是什么”6.2 参与者角色说明递归解析器跑腿员到终点了example.com 的权威 NS存着 example.com 及其子域未委派时的最终记录6.3 输入与输出输入: api.example.com查 A 记录 输出: └─ 权威服务器返回: api.example.com 的 A 记录 1.2.3.4 或返回 NXDOMAIN 这个子域不存在 或返回 CNAME 这是个别名再去查 CNAME 指向的域名6.4 权威服务器怎么知道答案权威 NS 存着example.com的区域文件Zone File。这个文件里写了example.com自己的 A 记录所有未委派子域的 A、CNAME、MX 等记录已委派子域的 NS 指针指向子域自己的权威 NS6.5 缓存行为递归解析器把这个结果缓存TTL 是由权威服务器在记录里指定的TTL 决定这个结果会在缓存里活多久挖掘者关注这是整个流程里唯一能拿到真实、最新数据的点。TTLTime To Live记录存活时间决定了数据新鲜度——TTL 很短说明目标经常变更 IP可能是 CDN 调度TTL 很长说明相对稳定可能是固定服务器。这个值应该记录下来。七、步骤 6递归解析器缓存并返回7.1 这一步在做什么递归解析器拿到权威服务器的 IP 结果后缓存一份然后返回给用户的浏览器。7.2 参与者角色说明递归解析器缓存 转发浏览器收到 IP准备发起 HTTP 连接7.3 输入与输出输入: api.example.com 的 A 记录 1.2.3.4来自权威服务器 输出: ├─ 递归解析器缓存: api.example.com → 1.2.3.4TTL300秒 └─ 返回给浏览器: IP 是 1.2.3.47.4 缓存行为递归解析器按 TTL 缓存结果后续在 TTL 内再查api.example.com直接返回缓存不再跑链路挖掘者关注这就是为什么被动 DNS 数据Passive DNS来自递归解析器缓存的历史数据可能不准——你拿到的可能是 TTL 还没过期的旧 IP而目标已经把 IP 改了。八、步骤 7浏览器发起 HTTP 连接8.1 这一步在做什么浏览器拿到 IP 后开始发起 HTTP/HTTPS 连接。这一步已经超出 DNS 解析的范围但为了流程完整简单提一下。8.2 后续动作动作说明建立 TCP 连接与 IP 的 80 或 443 端口三次握手TLS 握手HTTPS协商加密、验证证书、发送 SNI发送 HTTP 请求请求行、请求头、请求体接收响应状态码、响应头、响应体这一步后续会在Web 与网络层那篇文档里展开。九、特殊情况CNAME 链与委派上面讲的是最简单的情况——权威服务器直接给 A 记录。但实际查询中会遇到两种特殊情况需要多跑几趟。9.1 CNAME 链别名指向另一个域名如果api.example.com不是 A 记录而是 CNAME 记录指向另一个域名递归解析器要再去查那个域名的 IP。查询: api.example.com 权威返回: CNAME api.lb.amazonaws.com 递归解析器要继续查 api.lb.amazonaws.com 的 IP: → 问 .com TLD: amazonaws.com 的 NS 在哪 → 问 amazonaws.com 权威: api.lb.amazonaws.com 的 IP → 拿到 IP挖掘者关注CNAME 链是架构线索金矿——它指向*.cloudfront.net就知道用了 CloudFront CDN指向*.elb.amazonaws.com就知道后端是 AWS 负载均衡。每条 CNAME 都是一条架构线索。9.2 委派子域有自己的权威服务器如果api.example.com被委派了有自己的权威 NS主域权威服务器不会直接给 A 记录而是给 NS 指针。查询: api.example.com 主域权威返回: api.example.com 的 NS ns1.apiteam.net 递归解析器要继续问 ns1.apiteam.net: → 查询 ns1.apiteam.net 的 IP再去走一遍解析 → 问 ns1.apiteam.net: api.example.com 的 A 记录 → 拿到 IP挖掘者关注委派意味着子域有独立的权威服务器。子域名挖掘里发现一个子域有 NS 记录就要把它当成新的主域重新挖——这是 Zone Delegation 的核心概念下一篇会展开。十、完整流程的输入输出汇总把每一步的输入输出收拢成一张表方便对照。步骤参与者输入输出1浏览器/操作系统域名 api.example.com缓存命中则返回 IP未命中转交2递归解析器域名 api.example.com缓存命中则返回 IP未命中跑链路3根服务器api.example.com.com的 TLD 服务器地址4TLD 服务器api.example.comexample.com的权威 NS 地址5权威服务器api.example.comA 记录 IP1.2.3.4 或 NXDOMAIN 或 CNAME6递归解析器A 记录 IP1.2.3.4缓存并返回给浏览器7浏览器IP1.2.3.4发起 HTTP/HTTPS 连接10.1 特殊情况下的额外步骤场景额外步骤CNAME 链拿到 CNAME 后对 CNAME 指向的域名再走一遍完整流程委派主域权威给 NS 指针后向子域权威再查一次多级 CNAMEA → B → C → IP每跳都要查一次十一、本篇小结概念一句话完整解析流程浏览器 → 本地缓存 → 递归解析器 → 根 → TLD → 权威 → 缓存 → 返回每一步的输入都是要查的域名每一步的输出根/TLD 给下一步去哪权威给最终 IP缓存行为递归解析器按 TTL 缓存影响数据新鲜度特殊情况CNAME 链要再查一遍委派要向子域权威再查一次读懂了这一篇你就理解了 DNS 解析的完整机制。下一篇我们讲 DNS 里存的数据——记录类型、分级记录、树形结构与委派、通配符。附本篇关键术语速查术语简明解释浏览器缓存浏览器自己的 DNS 缓存操作系统缓存系统级 DNS 缓存hosts 文件本地静态域名映射优先级最高递归解析器缓存递归解析器按 TTL 缓存的结果NXDOMAIN域名不存在的应答CNAME 链域名指向别名别名再指向另一个域名委派子域有独立权威服务器主域权威只给 NS 指针TTLDNS 记录在缓存中的存活时间Zone File权威服务器存的区域文件含该域所有记录被动 DNS来自递归解析器缓存的历史 DNS 数据