[!info] related notes

• 所属 MOC: DNS 知识地图
• 加密 DNS: DoH / DoT
• 自动发现: DDR / DNR
• 解析策略: Mihomo redir-host vs fake-ip

DNS Bootstrap 鸡蛋问题

一句话定义

DNS Bootstrap 问题 是指：当你用域名来配置 DoH/DoT 解析器时，要建立到该解析器的加密连接，本身又得先解析这个域名——于是产生「想用 DoH 解析域名，却得先解析 DoH 域名」的循环依赖。

核心机制 / 工作原理

配置：DoH 服务器 = dns.example.com
   ↓ 要建立到 dns.example.com 的 HTTPS 连接
   ↓ 但建立前又要先解析 dns.example.com
   ↓ 而解析它本该用这个 DoH……

这就是经典的「鸡生蛋、蛋生鸡」。

最小例子 / 最小场景

在 Mihomo/Clash 里若写：

nameserver:
  - https://dns.google/dns-query

dns.google 本身也需解析。代理客户端因此区分不同解析阶段：

default-nameserver      # 引导/基础解析（通常用稳定 IP 或系统 DNS）
proxy-server-nameserver # 代理服务器自身解析
nameserver              # 普通查询解析
direct-nameserver       # 直连域名解析

default-nameserver 常用硬编码 IP 或极稳的解析器，专门破解 Bootstrap。

边界与易混淆点

• 用 IP 配置 DoH 可绕开 Bootstrap：如 https://1.1.1.1/dns-query 比 https://one.one.one.one/dns-query 少了一次引导解析（但仍可能有证书 SNI/名称校验需求）。
• DDR/DNR 自动发现也可能触发 Bootstrap：发现流程本身要先解析发现端点（见 encrypted-dns-auto-discovery-ddr-dnr）。
• 在代理场景里，若「代理服务器用的解析器」也依赖还没建立的代理连接，会死锁——所以 proxy-server-nameserver 与 default-nameserver 要明确分开（见 mihomo-dns-redir-host-vs-fake-ip）。
• Bootstrap 失败的表现常是「整个加密 DNS 起不来」，而非单个域名解析错——排障要从引导解析器是否可达入手（见 dns-systematic-diagnosis）。