可逆 —— 放心试
- 系统或网关的解析器地址（改回去即可）
- 上游选择与权重（配置层面，随时可调）
- 监控阈值与告警规则
- 灰度范围（加一批、撤一批都容易）
这类改动适合用「先做再评估」的方式推进，不必反复评审。
DEPLOYMENT
部署实践
先说结论：部署方式由组织规模决定，而不是由协议决定。同一套协议，在个人设备和上千台终端的组织里，做法几乎没有共同点。本页讲「选哪种方案」；具体怎么推上去、怎么退回来，见部署运行手册。
三档规模，三种做法
关键不是「哪个方案更好」，而是「你的规模下哪个方案可行」。下表按规模列出可行方案与主要风险。
| 规模 | 可行方案 | 主要风险 | 不要做的事 |
|---|---|---|---|
| 个人 / 家庭 1–10 台设备 |
系统层或浏览器层直接指向公共加密解析器。无需自建。 | 几乎只有「配了但没生效」这一类，用抓包即可发现。 | 不要在浏览器、系统、路由器三层同时配 —— 会得到三条互不相干的解析路径，排障时无法归因。 |
| 中小企业 10–500 台终端 |
网关或统一递归解析器为主，终端层保持默认。DoT 或受控 DoH 网关。 | 内网域名解析失败（加密解析器不认识内部域名）；终端策略与 MDM 冲突。 | 不要靠「每台机器手工配置」。手工配过的机器迟早与文档不一致，而这类不一致极难排查。 |
| 大型 / 多地域 500 台以上 |
多上游 + 区域分流 + 分级缓存；需要专门的监控与回滚能力。 | 单点依赖（某区域实际只走一个上游）、监管与日志合规、内部权威域与加密解析器的边界。 | 不要在缺少协议层监控的情况下铺开。没有监控时，故障只能表现为「用户说慢」，而无法定位。 |
三档之间的差别不在「协议选哪个」，而在你能否控制终端。能统一控制（企业）就倾向可治理的 DoT + 自建解析器；
不能控制（个人、自带设备）就只能选可达性最好的 DoH / DoH3，并接受治理能力下降这个代价。
区分「可逆」与「不可逆」的决策
部署方案里有些改动随时能撤，有些撤不掉。把注意力放在后者上，前者出错了代价很低。
不可逆 —— 必须先想清楚
- 把解析器地址硬编码进镜像或固件 —— 已经发出去的终端改不了，只能等它们回来
- 把 DNS 配置与设备注册流程绑定 —— 新设备一上线就带上，想改要动注册流程
- 删掉旧的解析器配置 —— 回滚通道随之消失
- 对日志做无保留期的删除 —— 事后要审计就没有了
这类改动一旦铺开，回退成本远高于当初实施的成本。
性能影响：比直觉小，但有两个真实开销
「加密 DNS 会不会拖慢上网」是被问最多的问题。分开看：带宽几乎不是问题，握手与隔离才是。
带宽：可以忽略
DNS 查询平均不到 100 字节。即使加上 TLS 记录头与填充，加密带来的额外带宽也在千字节量级， 与网页内容相比可以忽略。
唯一要注意的：若对 DNS 启用了大比例填充（padding），单次查询体积会显著变大。 这在移动网络上有意义，在固定网络上通常不值得。
延迟：两个真实开销
- 首次连接多一个往返 —— 这是 DoQ / DoH3 存在的理由（见往返次数对比）。长连接复用后差别消失。
- 解析器变远 —— 若用了远处的公共解析器，每次冷查询的 RTT 都比本地递归解析器高。这一项通常才是主要影响，而且与加密无关，纯粹是选址问题。
因此「变慢了」的排查顺序应该是：先看解析器选址，再看缓存命中率，最后才怀疑加密本身的开销。 反过来查，往往会在协议上白费很多时间。
最容易被忽略的问题：单点依赖
加密 DNS 会把「本地递归」换成「远程解析器」，于是引入了一个新的外部依赖。这一节讲怎么发现它。
看起来
配置里写了两个上游
主：解析器 A 备：解析器 B
实际上
某些区域只走 A
而 A 挂了整片区域就断
原因：B 在该区域不可达
端口策略 / 路由不可达 / 证书问题
| 检查项 | 怎么确认 |
|---|---|
| 备用上游在每个区域都可达 | 在每个区域的实际出口上，对备用上游单独 dig，而不是从中心机房测 |
| 上游不是同一家的两个 IP | 查两个 IP 的归属。同一运营商的「两个上游」在一次故障里会一起挂 |
| 回落时不会掉到明文 | 主动让主上游不可达，抓包看是否出现 53 端口 |
| 内部权威域有明确出口 | 确认内网域名走条件转发，而不是全部交给外部解析器 |
上线前的四个硬条件
这四项不满足就不要开始灰度 —— 它们都属于「事后补代价很高」的类型。
| 条件 | 为什么是硬条件 | 怎么确认 |
|---|---|---|
| 回滚通道已建好并演练过 | 没有演练过的回滚方案，真用时才会发现步骤不可行。演练产出「切回需多久」这个数字，它决定告警阈值该设多严 | 实际执行一次切回，记录耗时 |
| 基线数据已采集 | 没有基线就无法判断「变差了没」。加密 DNS 的问题常表现为轻微劣化，不是明显故障 | 至少 7 天连续样本，含 P95 与分类失败率 |
| 协议层监控已就绪 | 只有应用层监控时，DNS 故障会表现为「应用变慢」，定位方向会完全错 | 能看到「走了哪个协议、问的哪个上游、结果如何」 |
| 内部域名出口已定义 | 全量交给外部解析器会导致内网域名解析失败，且现象像是「加密 DNS 有问题」 | 对内部域名单独验证，确认走条件转发 |
两个典型场景的完整取舍
把前面几节的结论落到具体场景里，看它们各自放弃了什么、换到了什么。
场景一：个人设备与家庭网络
做法：路由器或系统层指向公共加密解析器，只用一层。上游选两个不同运营商的，并在实际网络上各测一次可达性。
换到了：链路防窃听与防篡改，配置成本接近零。
放弃了：几乎没有 —— 家庭场景本来就没什么可审计的。顺带提一句：主要隐私风险不在这条链路上，而在「解析器是谁」（见链路上有谁在看）。
场景二：企业办公网络
做法：自建递归解析器为主，终端通过 DoT 指向它；内部域名走条件转发；保留一条不依赖加密的可控退路（而不是退回明文）。
换到了：既加密了终端到解析器的链路，又保留了逐域名审计与策略能力 —— 这两个目标本来被认为是对立的，DoT 让它们同时成立。
放弃了：配置简单性。需要有人维护解析器、证书、监控与回滚能力，这不是一次性的部署成本，而是长期运维成本。
接下来
方案定了、检查项也过了，接下来是可以照着执行的上线流程。