风险与治理 | DNS 加密技术指南

真正的变化：观测点搬家了

加密没有「消灭」可观测性，而是把它从网络出口挪到了终端与解析器。治理上的绝大多数麻烦都源于这个错位。

这个视角能把几个看似无关的问题串起来： 企业内部终端 —— 终端在你手上，可以下发配置，所以观测能力可恢复； 员工自带设备 —— 终端不归你管，只能靠出口与解析器； 解析器是公共的 —— 它看得到，但记录不给你，于是这一段就真的丢了。下一节的风险分类，本质上都是这三种情形之一。

四类风险，以及缓解手段各自的边界

「有风险」不足以指导决策。更有用的是：这个手段能解决到什么程度、又换来了什么新问题。

风险	真实成因	缓解手段	手段的边界
审计能力下降	出口不再是观测点，而多数组织仍把审计建在出口上	把加密 DNS 网关作为统一入口；或自建递归解析器，把日志收在解析器侧	只覆盖「走了这个入口」的流量。终端若自行配置第三方 DoH，仍会绕过
策略绕行	加密通道让终端可以自行选择解析器，且这件事本身不容易被发现	提供受控加密通道，让合规路径比绕行更省事	无法完全封堵（见下一节）。目标是让绕行成为例外而非常态，并让例外可被发现
信任集中	把解析集中到少数公共解析器，等于把「谁能看到全部查询」重新分配	多上游 + 分流；对敏感类别走自建解析器	多上游通常由同一家运营，一次故障仍会一起挂。分流会增加配置复杂度与排障难度
合规争议	日志「记多少、留多久、谁能看」既是合规要求，也直接决定数据暴露面	最小必要日志 + 分级留存 + 访问审批	存在内在张力：留得少则事后审计不了，留得多则泄露风险与合规风险同时上升。需要按类别定策略，而不是全局取一个折中值

注意最后一栏 —— 四项缓解手段都有代价，没有一项是「装上就解决」。这也是为什么这一页不给出「最佳实践清单」：手段的选择取决于你的终端控制力，而这一点各组织差别极大。

为什么「禁止 DoH」通常不可行

这是治理讨论里出现频率最高、也最容易做错的一个决策。原因在于封堵的收益递减，而成本递增。

绕行手段不止一种

手机热点 —— 完全绕过企业出口
系统级或浏览器级配置 —— 与出口策略无关
应用内自带解析（部分应用内置 DoH）
加密隧道（VPN / 代理）—— 封 DNS 端口对此无效

只要有一种可行，封堵就只是提高了门槛，而不是关闭了路径。

封堵的代价会外溢

封 443 不可行 —— 会连正常 HTTPS 一起破坏
封 853 可行但收益有限 —— 只挡住 DoT/DoQ，DoH 走 443
按 IP 封解析器 —— 公共解析器普遍用 anycast，地址池大且会变；维护名单的成本持续上升
按 SNI 封 —— 遇到 ECH（RFC 9849）就失效

每一条措施都需要持续维护，且都能被一条新的绕行方式越过。

所以更现实的策略是把「合规路径」变得比「绕行路径」更省事：提供一个可用的加密解析通道（速度不差、配置由你下发、出问题有人管），同时把审计能力建在你能控制的那一处（自建递归解析器或受控网关）。封堵留给那些确实必须封的少数目标，而不是当作全局策略 —— 全局封堵会把大量正常流量也变成「例外」，最终拖垮的是运维本身。

分级治理：按类别定策略，而不是全局取折中

「隐私」与「可审计」不是二选一，它们可以按域名类别共存 —— 前提是你先分类。

类别	示例	建议策略	理由
必须可审计	内部系统、代码托管、财务与人事系统	强制走受控加密通道，记录可关联到人	这些域名的访问记录在事件响应与合规举证里是必需的
需要可观测但不针对个人	一般业务站点、CDN、公共云服务	记录聚合指标与失败率，不做逐条归因	目的是故障定位与容量规划，不需要知道「谁访问了它」
隐私优先	医疗、法律、社工服务等敏感类别	允许隐私增强通道，不记录查询内容	记录本身即产生风险，且对运维几乎没有价值
明确禁止	已知恶意域名、挖矿池	在解析器侧阻断并记录命中	这一类才是封堵的合理用途 —— 目标明确、名单可控

分级的价值在于把「要不要留日志」这个看起来无解的问题，拆成四组各自可回答的问题。全部一刀切（全留或全不留）都会在一部分类别上明显失当。

常见问题

都是实际评审里被问到的问题。回答尽量直接，并指明它在哪一节有展开。

启用加密 DNS 后是否等于匿名？

不等于，而且差距很大。它保护的是「你到解析器」这一段链路，但目标 IP、TLS 握手里的 SNI（未部署 ECH 时）、流量形状都还在，并且解析器本身看得到你的全部查询。详见基础与威胁模型。

企业能否完全禁止员工使用 DoH？

通常不能完全禁止。可用的绕行手段包括手机热点、系统级配置、应用内置解析与加密隧道，而封堵手段要么代价过大（封 443），要么需要持续维护（按 IP 名单）。

更现实的路径是提供受控通道，让合规比绕行更省事 —— 见本页上一节。

如何平衡隐私与合规审计？

按域名类别分级（见上一节的表），而不是全局取一个折中值。核心思路是：只对「事后确实需要追溯」的类别保留可关联记录，其余只保留聚合指标。

具体的日志保留期、脱敏方式与审批机制见治理与合规框架。

加密 DNS 会不会让内部威胁更难发现？

会，但影响比直觉小 —— 因为内部威胁的证据通常不在 DNS 层。真正受影响的是「通过异常域名访问外联」这类检测手段，而这可以靠解析器侧的统一出口补回来（前提是流量确实走了那个出口）。

把日志留得越久越安全吗？

不是。日志本身是一份敏感数据资产：留得越久，泄露时的暴露面越大，合规上的「数据最小化」要求也越难满足。

合理的做法是按类别定保留期，并为每一条留存记录写明「为什么需要留」—— 写不出理由的，就不该留。

这一页的结论

治理的目标不是「看见全部」，而是「关键可见 + 边界清楚」。追求看见全部会导向封堵，而封堵在这个议题上收益递减、成本递增，最后往往连正常的运维都被拖累；而「边界清楚」意味着：你知道哪些流量在你能观测的范围内、哪些不在，并且对不在的那部分有明确判断（接受它，或者收窄它）。

下一步：把上述判断落成可执行的制度（日志策略、权限分离、例外流程、审计闭环），见治理与合规框架。若想先看一遍完整的问题演进过程，可读长文 DNS 安全策略：从「能用」到「可治理」。