2019年7月，网络安全研究人员发现了一种名为Godlua的后门程序。这个恶意软件的独特之处在于：它是首个被观察到利用DNS over HTTPS (DoH)协议来隐藏命令与控制(C2)通信的恶意软件。通过将DNS查询封装在HTTPS流量中，Godlua成功绕过了传统的网络监控工具——安全团队看着大量"正常"的HTTPS流量经过，却完全无法察觉其中隐藏的恶意DNS请求。
这个案例揭示了一个深刻的技术悖论：一个旨在保护用户隐私的协议，正在同时成为攻击者的隐身斗篷。
DNS的四十年明文困境
要理解DoH引发的争议，需要先理解DNS本身的"先天缺陷"。
1983年，Paul Mockapetris设计了Domain Name System，用以替代早期互联网的HOSTS.TXT文件。在那个互联主机数量尚以千计的年代，安全并非首要考量——DNS查询以明文形式在UDP端口53上传输，任何人都能读取、修改或拦截这些数据包。
这种设计延续了近四十年。当你在咖啡馆连接公共Wi-Fi，输入一个网址时，你的DNS查询会以明文形式穿过该网络。网络管理员、ISP、或者任何能够在网络路径上部署嗅探器的攻击者，都能看到你正在访问哪些网站。更危险的是，他们可以实施DNS劫持——将你的查询重定向到恶意服务器，把你引导到钓鱼网站。
Paul Vixie，这位在1989年至1999年间负责BIND（最广泛使用的DNS服务器软件）的先驱，曾经这样描述DNS的安全状况：“DNS是互联网的电话簿，但这个电话簿挂在公共场所的墙上，任何人走过都能看到你在查谁的号码。”
问题的核心在于：即使目标网站使用了HTTPS加密，DNS查询本身仍然是明文的。这就好比你要去银行，虽然银行金库固若金汤，但你在门口大声询问"银行在哪里"，任何路人都能听到。
DoH的技术架构
DNS over HTTPS的核心思想非常直接：将DNS查询封装在HTTPS请求中，利用TLS加密保护查询内容。
2018年10月，IETF发布RFC 8484，正式将DoH标准化为提议标准(Proposed Standard)。协议规定：
- DNS查询使用HTTP/2或更高版本的POST或GET方法发送
- 查询内容以wire format格式编码，MIME类型为
application/dns-message - 默认端口为443，与普通HTTPS流量相同
- 支持HTTP缓存机制
一个典型的DoH请求如下：
GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
Host: dns.example.com
Accept: application/dns-message
响应同样采用application/dns-message格式：
HTTP/2 200 OK
Content-Type: application/dns-message
Content-Length: 61
<DNS响应的wire format数据>
这种设计的巧妙之处在于：DoH流量与普通HTTPS流量完全无法区分。网络管理员看到的只是一堆通往cloudflare-dns.com或dns.google的HTTPS连接，无法判断其中是否包含DNS查询，更无法知道查询的内容。
两种部署哲学的碰撞
DoH的实现方式存在两种截然不同的哲学，这种差异直接影响着网络治理格局。
SPAU模式：渐进式升级
Chrome和Windows采用Same Provider Auto-Upgrade (SPAU)模式。其逻辑是：如果系统配置的DNS解析器（如8.8.8.8）在已知的DoH支持列表中，客户端会自动尝试升级到加密连接；如果失败，则回退到明文DNS。
这种模式的优点是不改变用户的DNS配置，企业可以继续使用自己的DNS服务器进行内容过滤和策略执行。缺点是安全性有限——如果本地网络被攻击者控制，他们可以轻易阻止DoH升级，强制用户使用明文DNS。
TRR模式：彻底信任转移
Firefox采用Trusted Recursive Resolver (TRR)模式。浏览器内置一份"可信解析器"列表，默认情况下会绕过系统配置的DNS服务器，直接连接到这些可信解析器（如Cloudflare的1.1.1.1）。
2020年2月25日，Firefox开始为美国用户默认启用DoH，使用Cloudflare作为默认解析器。此举引发了轩然大波——企业网络管理员发现，他们精心配置的DNS策略（如屏蔽恶意域名、内网域名解析、家长控制）突然失效了。
Firefox为此设计了一套启发式规则来缓解冲突：
- 检测到企业管理的设备时禁用DoH
- 检测到家长控制相关域名被屏蔽时禁用DoH
- 解析失败时回退到系统DNS
但这些规则并不完美。正如一位网络工程师在Reddit上抱怨的：“我们花了十年时间构建的企业DNS基础设施，被浏览器厂商一个版本更新就绕过了。”
企业网络的可见性危机
DoH对企业安全运营的影响是深远的。
传统的网络安全架构依赖于DNS层面的可见性。安全团队通过分析DNS查询日志可以：
- 检测恶意软件与C2服务器的通信
- 发现数据泄露的早期迹象
- 执行合规策略（如屏蔽赌博网站）
- 为内网服务提供域名解析
DoH使这一切变得困难。
SEI（Software Engineering Institute）在2021年发布的研究指出，DoH对企业网络可见性造成了三类核心影响：
- 监控盲区：传统DNS监控工具无法检测DoH流量
- 策略绕过：用户可以通过DoH绕过企业的内容过滤策略
- 恶意软件隐蔽信道：攻击者可以利用DoH隐藏恶意通信
2019年的Godlua事件只是冰山一角。后续研究发现，越来越多的恶意软件开始利用DoH进行C2通信。由于DoH流量与正常HTTPS流量无法区分，传统的网络防御工具对此束手无策。
CDN与地理位置路由的困境
DoH还带来了一个容易被忽视但影响深远的问题：地理位置路由的失效。
现代CDN（内容分发网络）依赖于DNS的EDNS Client Subnet (ECS)扩展来优化内容分发。当用户查询一个CDN托管的域名时，权威DNS服务器需要知道用户的大致位置，才能返回最近的服务器IP。
传统DNS架构中，本地递归解析器通常与用户地理位置接近，权威服务器可以根据解析器的IP推断用户位置。但当用户使用远程DoH服务（如1.1.1.1）时，这个推断就失效了——解析器可能位于地球另一端。
ECS试图解决这个问题：递归解析器在查询中附加用户IP地址的前缀信息（通常是/24），让权威服务器能够更准确地定位用户。但这又引发了新的隐私问题——用户的IP信息被暴露给了更多的权威服务器。
APNIC在2024年的研究发现，约12%的互联网用户在DNS查询中携带ECS信息，其中绝大多数（约90%）来自Google DNS服务。这种机制的复杂性在于：隐私保护与性能优化存在内在张力。
DoT与DoH：技术路线之争
在加密DNS领域，DoH并非唯一选择。DNS over TLS (DoT)早在2016年就作为RFC 7858发布，两者采用了不同的技术路线。
quadrantChart
title DoH vs DoT 特性对比
x-axis "易于识别/阻止" --> "难以识别/阻止"
y-axis "企业友好" --> "用户隐私优先"
quadrant-1 "隐私优先但可管理"
quadrant-2 "最大隐私保护"
quadrant-3 "易于管理"
quadrant-4 "企业优先但隐私受限"
"传统DNS": [0.1, 0.1]
"DoT (端口853)": [0.3, 0.6]
"DoH (端口443)": [0.9, 0.9]
核心差异在于端口选择：
| 特性 | DoT | DoH |
|---|---|---|
| 端口 | 853（专用端口） | 443（与HTTPS共享） |
| 协议 | TLS over TCP | HTTP/2 over TLS |
| 可识别性 | 容易（专用端口+ALPN标识） | 困难（与普通HTTPS无法区分） |
| 可阻止性 | 网络层面可阻止 | 需要深度包检测或IP封锁 |
| 部署者偏好 | 网络运营商、企业IT | 浏览器厂商、隐私倡导者 |
从网络治理角度看，DoT更"友好"——它保留了网络管理员对DNS流量的可见性和控制力。但这也意味着DoT更容易被审查者阻止。
在严格的网络治理环境下，DoH的"伪装性"反而成为用户突破限制的工具。当所有端口853的流量都被封锁时，端口443上的DoH仍然可以使用——除非封锁者愿意切断所有HTTPS流量，这基本上等于切断互联网。
性能考量：加密的代价
加密必然带来性能开销。但具体影响有多大？
2021年发表在ACM IMC上的研究提供了全球范围的测量数据：
- 首查询延迟：DoH比明文DNS慢约65毫秒（中位数），主要源于TLS握手开销
- 连接复用后：当HTTP/2连接建立后，后续查询的延迟差异降至10-30毫秒
- 网络条件影响：在丢包率高的网络中，DoH/DoT可能比UDP DNS表现更好（TCP的重传机制比UDP超时更高效）
值得注意的是，不同DoH提供商的性能差异显著。Cloudflare凭借其广泛的anycast部署，在大多数地区表现最佳；而一些部署较稀疏的服务商，查询延迟可能显著增加。
研究还发现一个反直觉的现象：约8.8%的经济体在切换到DoH后，DNS查询延迟反而降低了。原因在于这些地区的本地DNS基础设施质量较差，远程DoH服务商反而提供了更快的响应。
未来的技术演进
DoH的故事并未结束。几个重要的发展方向值得关注：
DNS over QUIC (DoQ)
2022年，IETF发布了RFC 9250，定义了DNS over QUIC。QUIC协议基于UDP，避免了TCP和TLS的握手开销，理论上可以提供更低的延迟。测量研究表明，DoQ在延迟敏感场景下比DoH/DoT表现更好。
Oblivious DoH (ODoH)
Apple已经开始部署Oblivious DoH。其核心思想是通过代理转发DoH请求，使得DNS解析器无法获知用户的真实IP地址。这解决了传统DoH的一个核心隐私问题：用户IP与查询内容在同一处汇集。
Discovery of Designated Resolvers (DDR)
IETF ADD工作组正在开发DDR协议，允许网络向客户端通告其支持的加密DNS服务。这可能为SPAU和TRR模式提供一个折中方案：网络可以告诉客户端"我有一个安全的DNS服务"，而不需要客户端盲目升级或绕过。
权衡与选择
DoH的争议本质上是一个价值排序问题。
对于个人用户，特别是在公共Wi-Fi等不受信任的网络环境下，DoH提供了实实在在的隐私保护。阻止ISP监控浏览记录、避免DNS劫持攻击，这些收益是真实的。
对于企业网络管理员，DoH代表着控制力的丧失。几十年构建的DNS层安全架构正在被绕过，而替代方案（如TLS解密）成本高昂且存在隐私争议。
对于网络治理者，DoH是一把双刃剑：它可以保护公民免受监控，也可以被恶意软件用来隐藏通信；它可以突破审查，也可以使合法的内容管控失效。
Paul Vixie曾批评DoH"是浏览器厂商试图接管网络基础设施的政治行为"。而Mozilla的工程师则反驳说：“我们不能因为企业需要监控，就让用户承担隐私泄露的风险。”
两种观点都有其合理性。技术本身不承载价值判断，但技术的部署方式确实反映了设计者的立场。DoH之所以引发如此激烈的争议，正是因为它触及了互联网治理中最敏感的神经：谁有权知道你访问了什么网站？
在这个问题上，没有完美的技术方案，只有基于具体场景的权衡选择。对于普通用户，启用DoH大概率是正确的选择；对于企业，可能需要配置策略来引导DoH使用本地安全解析器；对于安全研究人员，需要开发新的检测技术来应对DoH隐蔽的恶意流量。
DNS诞生于一个信任的环境。四十年后，我们仍在为那个时代遗留的安全债务买单。DoH是修复尝试之一，但它不是终点——下一个十年的挑战，或许是如何在保护隐私的同时，不丧失对恶意行为的可见性。
参考文献
- Hoffman, P. & McManus, P. (2018). DNS Queries over HTTPS (DoH). RFC 8484, IETF.
- Hu, Z. et al. (2016). Specification for DNS over Transport Layer Security (TLS). RFC 7858, IETF.
- Hounsel, A. et al. (2021). Measuring DNS-over-HTTPS performance around the world. ACM IMC 2021.
- Bortzmeyer, S. (2016). DNS Privacy Considerations. RFC 7626, IETF.
- Chhabra, R. et al. (2022). Measuring DNS-over-HTTPS performance around the world. APNIC Blog.
- SEI Carnegie Mellon. (2021). DNS Over HTTPS: 3 Strategies for Enterprise Security Monitoring.
- Deccio, C. et al. (2024). Privacy and DNS Client Subnet. APNIC Blog.
- Rescorla, E. (2022). DNS Security, Part IV: Transport security for DNS (DoT, DoH, DoQ). educatedguesswork.org.
- Qihoo 360 Netlab. (2019). Godlua Backdoor Analysis.
- Cloudflare. (2025). DNS over TLS vs. DNS over HTTPS.