课题研究 DNS解析安全研究 子课题03 · 第3页 / 共8页
03六大核心研究子课题 · 部署生态与默认化趋势

加密DNS部署生态全景

本页盘点加密DNS从标准化到默认化的完整生态图景:以公开官方信息重建发展时间线;编制国际主要公共加密递归服务图谱,并对国内公共递归服务"能力已具备而默认未落地"的真实格局进行校正与归因分析;给出操作系统与浏览器支持矩阵与四种网络侧部署形态;梳理默认化进程中的代表性争议事件(2019年英国ISPA事件、俄罗斯对公共加密递归的IP封锁实践),最后归纳公开测量数据的主要来源与总体结论。

公共递归1.1.1.18.8.8.89.9.9.9Private DNSTRR安全DNSDDRISPA事件APNIC Labs研究状态:研究中
生态主体公共递归 / OS / 浏览器 / 路由器
现状校正国内公共递归加密能力与默认化缺位
争议样本ISPA年度恶人事件 · 俄罗斯阻断实践

01 · 发展时间线:从明文到默认加密

加密DNS发展关键节点
以公开可查的官方发布信息为准(RFC发布日期见IETF Datatracker)
资料来源:IETF RFC公开记录、Cloudflare/Google/Mozilla/Apple官方发布信息、Android版本说明。

02 · 公共加密递归服务生态图谱

2.1 国际主要公共递归

服务地址协议支持运营方与性质
Cloudflare1.1.1.1 / 1.0.0.1DoH、DoT、DoQ、ODoH(与合作伙伴)Cloudflare运营;1.1.1.1为其与APNIC的研究合作项目
Google Public DNS8.8.8.8 / 8.8.4.4DoH、DoTGoogle运营;2009年上线,DoH/DoT服务后增
Quad99.9.9.9DoH、DoT、DoQ非营利组织运营(瑞士),默认拦截已知恶意域名
AdGuard DNS94.140.14.14DoH、DoT、DoQ、DoH3、ODoHAdGuard(广告过滤软件厂商),默认过滤广告与跟踪域
Mullvad DNS194.242.2.3DoH、DoT、DoQ、ODoH、DoH3Mullvad VPN(瑞典),无日志承诺

注:各服务协议支持以运营方官方文档为准,且随时间演进;选型时应以当下官方文档复核。

2.2 国内公共递归现状:能力已具备,"默认未落地"

首先需要纠正一个流传甚广的误判:"国内公共递归不提供加密DNS"。事实恰好相反——国内头部公共递归早已面向公众提供DoH/DoT服务(以下信息以各官方文档为准,且随政策演进):

服务明文地址加密入口备注
阿里公共DNS223.5.5.5 / 223.6.6.6DoH:https://dns.alidns.com/dns-query;DoT:dns.alidns.com(853)约2019年起提供加密传输服务,支持TLS 1.2/1.3
腾讯DNSPod119.29.29.29DoH:https://doh.pub/dns-query;DoT:dot.pub(853)含国密SM2加密端点;2024年9月起免费版DoH/DoT调整为域名接入
360安全DNS101.226.4.6 等DoH:https://doh.360.cn/dns-query;DoT:dot.360.cn按运营商线路提供多组入口
114DNS114.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/11DoH客户端支持可在网络适配器属性中手动指定支持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 · 网络侧部署形态

形态描述典型场景治理可见性
终端直连公共递归终端绕过本地递归,直接配置/自动发现云厂商DoHFirefox默认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、公开报道)。

[1]

RFC 7858 / 8484 / 9250 / 9460 / 9463 / 9335(IETF Datatracker可查询发布日期):datatracker.ietf.org

[2]

Cloudflare 1.1.1.1发布官方博客(2018-04-01):blog.cloudflare.com/announcing-1111

[3]

Google Public DNS官方文档(DoH/DoT支持):developers.google.com/speed/public-dns/docs/secure-transports

[4]

Mozilla Firefox DoH官方说明与策略文档:support.mozilla.org/kb/firefox-dns-over-https

[5]

Android“私人DNS”官方说明:support.google.com/android

[6]

Apple平台加密DNS支持说明(iOS 14/macOS Big Sur起):developer.apple.com(WWDC2020 “Enable encrypted DNS”)

[8]

APNIC Labs测量博客(加密DNS采用率系列测量,Geoff Huston):labs.apnic.net

[9]

Roskomnadzor阻断公共DNS/加密协议(2021年9月TSPU测试与2024年ECH封锁)公开报道与研究:Access Now(2021-09);DGAP《Russia’s Quest for Digital Sovereignty》(2022)

[10]

Quad9官方服务说明(协议支持与过滤策略):quad9.net