01 · 发展时间线:从明文到默认加密
02 · 公共加密递归服务生态图谱
2.1 国际主要公共递归
| 服务 | 地址 | 协议支持 | 运营方与性质 |
|---|---|---|---|
| Cloudflare | 1.1.1.1 / 1.0.0.1 | DoH、DoT、DoQ、ODoH(与合作伙伴) | Cloudflare运营;1.1.1.1为其与APNIC的研究合作项目 |
| Google Public DNS | 8.8.8.8 / 8.8.4.4 | DoH、DoT | Google运营;2009年上线,DoH/DoT服务后增 |
| Quad9 | 9.9.9.9 | DoH、DoT、DoQ | 非营利组织运营(瑞士),默认拦截已知恶意域名 |
| AdGuard DNS | 94.140.14.14 | DoH、DoT、DoQ、DoH3、ODoH | AdGuard(广告过滤软件厂商),默认过滤广告与跟踪域 |
| Mullvad DNS | 194.242.2.3 | DoH、DoT、DoQ、ODoH、DoH3 | Mullvad VPN(瑞典),无日志承诺 |
注:各服务协议支持以运营方官方文档为准,且随时间演进;选型时应以当下官方文档复核。
2.2 国内公共递归现状:能力已具备,"默认未落地"
首先需要纠正一个流传甚广的误判:"国内公共递归不提供加密DNS"。事实恰好相反——国内头部公共递归早已面向公众提供DoH/DoT服务(以下信息以各官方文档为准,且随政策演进):
| 服务 | 明文地址 | 加密入口 | 备注 |
|---|---|---|---|
| 阿里公共DNS | 223.5.5.5 / 223.6.6.6 | DoH:https://dns.alidns.com/dns-query;DoT:dns.alidns.com(853) | 约2019年起提供加密传输服务,支持TLS 1.2/1.3 |
| 腾讯DNSPod | 119.29.29.29 | DoH:https://doh.pub/dns-query;DoT:dot.pub(853) | 含国密SM2加密端点;2024年9月起免费版DoH/DoT调整为域名接入 |
| 360安全DNS | 101.226.4.6 等 | DoH:https://doh.360.cn/dns-query;DoT:dot.360.cn | 按运营商线路提供多组入口 |
| 114DNS | 114.114.114.114 | 传统上以明文53为主,加密入口以官方最新信息为准 | 家用/政企存量场景占用量大 |
注:端点与接入策略持续演进(例:DNSPod官方公告自2024年9月29日起免费版公共解析DoH/DoT不再公开IP接入方式,改用域名接入),引用时应以当期官方文档复核。
因此,国内加密DNS的真实格局是"能力已具备、默认未落地",其特征可归纳为四点:
- 终端默认不启用:国内主流浏览器未默认开启DoH/DoT(与国际厂商策略相反),操作系统出厂配置以明文53为主——加密入口存在,但未成为默认路径;
- 协议谱系不全:国内公共递归以DoH/DoT为主,DoQ、ODoH等新协议支持基本缺位;
- 隐私承诺差异:国内公共递归受境内法律法规约束,其隐私政策表述与国际"零日志"品牌存在差异——数据留存于境内是合规优势,同时也意味着用户查询对运营者可见;
- 企业侧采用率低:企业自建加密递归(第6页方案)在国内尚处早期,DNS遥测仍主要依赖明文通道。
对研究的含义(修正后):国内加密DNS风险评估的重点,已不是"公共加密递归缺位",而是:①终端私自配置境外加密DNS带来的数据出境与审计缺口;②企业DNS遥测长期依赖明文通道,对加密化浪潮的架构准备不足;③国内"加密入口存在但不默认"的格局若长期延续,与国际默认化趋势的落差本身即构成韧性议题(衔接子课题06)。这决定了第5、6页治理与管控方案的设计重心。
03 · 操作系统与浏览器支持矩阵
3.1 操作系统层
| OS | 加密DNS能力 | 机制与说明 |
|---|---|---|
| Android 9+ | DoT原生支持 | “私人DNS(Private DNS)”设置:可填 hostname 或自动;机会模式可静默回退;国内定制ROM普遍保留该入口 |
| iOS 14 / macOS 11+ | DoH/DoT描述文件 | 通过.mobileconfig描述文件或App(如加密DNS客户端App)配置,无系统级全局默认开关 |
| Windows 10/11 | DoH客户端支持 | 可在网络适配器属性中手动指定支持DoH的服务器IP并选择“仅使用加密DNS”;默认关闭 |
| Linux | 组件化支持 | systemd-resolved支持DoT(opportunistic/strict);unbound/dnsmasq+stubby等可自建 |
| 路由器/网关 | 固件差异大 | OpenWrt可通过stubby/unbound配置DoT/DoH;主流家用路由器固件多数未开放配置 |
3.2 浏览器层
| 浏览器 | 策略 | 机制 |
|---|---|---|
| Firefox | 默认开启DoH(区域渐进) | 基于TRR(Trusted Recursive Resolver)模式,内置云厂商DoH白名单;2019年9月美国默认启用,后扩展至部分国家/地区;企业可通过canary域(use-application-dns.net)与企业策略关闭 |
| Chrome / Edge | “安全DNS”升级模式 | 默认尝试将当前系统DNS解析器升级为其提供的加密版本(doh-upgrade),失败则回退明文;非强制切换至第三方 |
| Safari | 无内置DoH | 依赖系统层(描述文件/第三方App) |
| 其他Chromium系浏览器 | 多继承"安全DNS"能力 | 具体策略随版本差异较大,应以当期版本实测为准 |
注:各浏览器策略随版本频繁调整,部署决策前应以当期官方政策文档与企业策略管理能力为准。
3.3 两个值得注意的治理设计
- Canary域机制(Firefox):网络管理员可在本地DNS应答中声明use-application-dns.net的特定结果,Firefox检测到后自动禁用其默认DoH——这是业界最早的“网络治理方退出协议”实践。
- Chrome的升级优先策略:与Firefox“切换到公共递归”不同,Chrome优先尝试为“当前网络原有递归”寻找其加密版本,这与DDR思想一致,治理冲突相对较小。
04 · 网络侧部署形态
| 形态 | 描述 | 典型场景 | 治理可见性 |
|---|---|---|---|
| 终端直连公共递归 | 终端绕过本地递归,直接配置/自动发现云厂商DoH | Firefox默认DoH;个人用户手动配置 | 最差:企业侧完全失明 |
| 网关代理转发 | 企业网关作为客户端向公共加密递归发起DoH/DoT,对内仍提供明文或加密服务 | 出口统一解析 | 最优:解析点在企业控制域内 |
| 路由器代答 | 家用路由器向公共递归走加密通道,对下明明文服务 | OpenWrt+stubby/unbound | 取决于路由器归属 |
| 客户端Agent托管 | ZTNA/SWG客户端在终端接管DNS并强制走受控通道 | 企业零信任架构 | 强:策略随Agent强制执行 |
第6页将围绕“网关代理转发”与“客户端Agent托管”两类可控形态给出详细工程方案。
05 · 默认化趋势与争议事件
5.1 英国"年度恶人"事件与Mozilla推迟
2019年,英国ISP行业组织ISPA(Internet Services Providers' Association)在其年度颁奖典礼上将Mozilla列为"Internet Villain of the Year(年度网络恶人)",理由是Firefox推广DoH将"绕过英国Web屏蔽与家长控制体系"。该奖项引发广泛报道与争议,ISPA随后撤回了Mozilla的提名并取消了整个"恶人"奖项类别。Mozilla在事件发生时即公开表示"暂无在英国默认启用DoH的计划"(2019年7月公开声明),此后Firefox默认启用DoH的国家/地区列表长期未覆盖英国。该事件是加密DNS治理冲突最具代表性的公开样本,本课题将其归类为"隐私增强机制与法定网络治理工具之间的结构性冲突"。
5.2 俄罗斯的阻断实践
据公开报道与研究文献,俄罗斯监管体系对加密DNS及加密握手的治理可分为三个阶段:
- 2020年立法授权:俄数字发展部公布法案草案,拟禁止TLS 1.3(含ESNI)、DoH、DoT等"隐藏网站名称"的加密协议;随后政府法令授予Roskomnadzor相应监管权限;
- 2021年9月阻断测试:Roskomnadzor通过部署于运营商网络的过滤设备(TSPU)对Google、Cloudflare公共DNS(8.8.8.8、1.1.1.1)实施约一小时的阻断测试;同期,国有运营商Rostelecom被报道向内部单位发文禁用上述公共递归与DoH服务,要求改用国家域名系统;
- 2024年起封锁ECH:TSPU开始封锁使用ECH扩展的TLS连接,导致大量经由Cloudflare的服务一度不可达(ECH已于2026年标准化为RFC 9849,此类封锁与标准的博弈仍在持续)。
该案例表明:当加密DNS/加密握手被感知为对国家级域名治理体系的系统性绕过时,中间方具备且会使用定向阻断手段——同时也警示,粗暴IP封锁会造成附带损害(共享CDN IP被波及正常服务)。
5.3 默认化的不可逆趋势
尽管存在争议,默认化趋势是明确的:ECH(RFC 9849,2026)标准化后,TLS层域名明文被消除,Web生态整体进入"加密默认"时代;DNS作为最后的大规模明文协议,其加密化在技术上已无回头路。治理争论的焦点已从"要不要加密"转向"谁来决定信任锚、如何保留合法治理点"——这正是DDR/ODoH等机制与第5页治理框架的立足点。
06 · 生态测量的公开数据现状
加密DNS采用率的公开测量主要来自三类来源:
- APNIC Labs测量:APNIC实验室(Geoff Huston等)长期通过嵌入式测量代码对加密DNS可达性与使用情况进行大规模测量,并公开方法与结果,是学术引用最多的来源;
- 云厂商透明度报告:Cloudflare与Google不定期披露其DoH/DoT服务的请求量与增长趋势;
- 浏览器遥测:Firefox/Chrome的统计平台提供加密DNS启用比例的聚合统计(如Firefox telemetry的DoH启用率)。
总体结论(与第7页方法学衔接):全球范围内DoH启用率呈持续上升但区域差异极大;中国大陆因终端默认策略保守、加密入口未默认化,加密DNS启用率处于全球最低区间,这使得国内相关风险的现实形态以"零散个体使用+企业员工私配"为主,而非大规模默认加密。
本节参考来源(第3页)
以下均为真实可查的公开来源(官方发布信息、IETF RFC、公开报道)。
RFC 7858 / 8484 / 9250 / 9460 / 9463 / 9335(IETF Datatracker可查询发布日期):datatracker.ietf.org
Cloudflare 1.1.1.1发布官方博客(2018-04-01):blog.cloudflare.com/announcing-1111
Google Public DNS官方文档(DoH/DoT支持):developers.google.com/speed/public-dns/docs/secure-transports
Mozilla Firefox DoH官方说明与策略文档:support.mozilla.org/kb/firefox-dns-over-https
Android“私人DNS”官方说明:support.google.com/android
Apple平台加密DNS支持说明(iOS 14/macOS Big Sur起):developer.apple.com(WWDC2020 “Enable encrypted DNS”)
ISPA UK “Internet Villain”事件公开报道(ZDNet, 2019-07-04;TechCrunch, 2019-07-05):zdnet.com/article/uk-isp-group-names-mozilla-internet-villain-for-supporting-dns-over-https;techcrunch.com/2019/07/05/isp-group-mozilla-internet-villain-dns-privacy
APNIC Labs测量博客(加密DNS采用率系列测量,Geoff Huston):labs.apnic.net
Roskomnadzor阻断公共DNS/加密协议(2021年9月TSPU测试与2024年ECH封锁)公开报道与研究:Access Now(2021-09);DGAP《Russia’s Quest for Digital Sovereignty》(2022)
Quad9官方服务说明(协议支持与过滤策略):quad9.net