DoH和DoT是什么？加密DNS能彻底解决DNS污染吗

　　直接说结论：DoH和DoT能有效防御“链路中间人篡改”这类DNS污染，但无法解决“权威侧污染”和“DoH/DoT服务器本身被阻断”这两种情况。很多人开了DoH之后发现某些网站还是打不开，就以为加密DNS没用。其实问题不在加密本身，而在污染发生的环节超出了加密能覆盖的范围。

　　传统DNS的问题：明信片式的通信

　　要理解DoH和DoT的价值，先得看清楚传统DNS的缺陷。

　　传统DNS查询走的是UDP 53端口，数据包完全明文。你在浏览器里敲了一个网址，这个查询请求从你的设备发到DNS服务器的过程中，中间经过的任何一个节点——运营商的路由器、公共Wi-Fi的网关、局域网里的其他人——都能看到你在查什么域名，也能往响应包里塞假数据。

　　打个比方：传统DNS就像寄一张明信片，路上谁都能看一眼内容，谁都能顺手把地址改掉。而DoH和DoT做的事情，就是给这张明信片套上一个加密信封，只有收件人能拆开看。

　　DoT：给DNS修一条专用加密通道

　　DoT的全称是DNS over TLS，它的思路很直接：保留DNS原有的协议结构，但把传输过程套进TLS加密隧道里。

　　具体来说，DoT使用TCP 853端口，客户端先和DNS服务器完成一次TLS握手，建立加密连接，之后所有的DNS查询和响应都在这个加密通道里传输。对于路径上的旁观者来说，只能看到有一串加密数据在传输，但看不到里面查了什么域名。

　　DoT的端口是专用的853。这既是优点也是缺点。优点是网络管理员可以清晰地识别853端口的流量，方便做策略管理;缺点是在限制严格的网络环境里，853端口可能被直接封锁。

　　从部署位置来看，DoT更适合系统级配置——路由器、操作系统、企业网关这些地方。它“纯粹”地只做DNS加密，不和其他流量混在一起，管理起来更清晰。

　　DoH：把DNS藏进普通网页流量里

　　DoH的全称是DNS over HTTPS，它的思路比DoT更“狡猾”：不另开端口，直接把DNS查询封装成标准的HTTPS请求，通过443端口发送出去。

　　因为HTTPS本身已经加密，DNS查询被包在里面自然也是密文。更关键的是，从外部看，DoH流量和普通网页浏览流量完全一样——都是443端口，都是TLS加密，都是HTTP请求。中间节点根本分不清哪串流量是在查DNS，哪串是在访问网页。

　　这个特性让DoH在对抗网络审查和干扰时优势明显。运营商很难通过端口特征来识别和阻断DoH流量，因为它就藏在海量的HTTPS流量里。

　　DoH的部署位置更多在终端层——浏览器、手机App。Chrome、Firefox、Edge都已经内置了DoH支持，用户开启后，浏览器的所有域名解析都走加密通道。

　　DoH和DoT的核心区别：一张“明信片”的两种寄法

　　用一个比喻来理解两者的区别：

　　DoT像是专门租了一条有安保的快递专线(853端口)来寄密信。保安知道这是“密信通道”，但不知道信里写了什么。这条专线是专用的，容易被注意到，但也方便管理。

　　DoH则是把信塞进一个普通的快递箱(443端口)，和成千上万个一模一样的箱子混在一起寄出去。没人知道哪个箱子里有你的信，也没人知道信里写了什么。隐蔽性更强，但管理起来也更麻烦。

　　总结两者的核心差异：

　　1. 端口不同。DoT用853，DoH用443。前者容易被识别，后者混在普通流量里。

　　2. 部署场景不同。DoT适合系统级(路由器、企业网关)，强调可控性和管理便利;DoH适合终端级(浏览器、手机App)，强调隐私和抗干扰。

　　3. 网络管理可见性不同。DoT的专用端口让管理员能监控和过滤DNS流量;DoH把一切藏进HTTPS里，传统的内容过滤和审计手段基本失效。

　　加密DNS到底能防住什么

　　能防的情况：链路中间人劫持

　　这是DoH和DoT最核心的防御场景。如果你的DNS污染发生在你到DNS服务器之间的链路上——比如运营商在骨干网节点篡改响应包，或者公共Wi-Fi的网关伪造解析结果——加密DNS能有效防御。

　　实测数据也支持这一点：在存在DNS污染的网络环境中，启用DoH后错误解析率可以从平均12.7%降至0.3%以下。Mozilla与Cloudflare的联合数据也显示，启用DoH后DNS查询泄露风险下降超过95%。

　　攻击者看不到你查了什么，也无法往加密通道里塞假数据。TLS的完整性校验保证了响应包在传输途中没有被篡改。

　　防不住的情况：三种场景DoH/DoT无能为力

　　场景一：DoH/DoT服务器本身被阻断

　　这是最现实的问题。加密DNS的保护范围仅限于“你设备到DoH/DoT服务器”这一段。如果你连DoH服务器都连不上，加密就无从谈起。

　　在某些网络环境中，知名DoH服务商的IP或域名可能被阻断。向这些服务发起的TLS连接会遭遇干扰或切断，DoH请求根本无法到达服务器。更关键的是，如果DoH连接失败，浏览器可能会回退到明文DNS，加密保护直接失效。

　　场景二：权威DNS服务器被污染

　　DoH/DoT服务器本身也需要向权威DNS服务器查询才能拿到解析结果。如果污染发生在权威侧——比如权威DNS服务器被入侵，或者DoH服务器与权威服务器之间的链路被篡改——DoH拿到的是错误结果，然后加密回传给你。

　　加密保护的是“传输过程”，不是“解析结果的正确性”。微软官方文档也明确指出：“有时返回错误解析的原因是DNS服务器本身被污染导致的，这是无法避免的”。

　　场景三：目标IP被直接阻断

　　DoH/DoT只负责把域名翻译成IP。翻译完了，你还要去连接那个IP。如果目标网站的IP本身被阻断了，加密DNS帮不上忙。它解决的是“翻译环节”的问题，不解决“连接环节”的问题。

　　实际配置：浏览器怎么开DoH

　　主流的Chrome、Firefox、Edge都内置了DoH支持。

　　Chrome：地址栏输入chrome://settings/security，找到“使用安全DNS”，开启后填入DoH接入点地址，例如https://dns.cloudflare.com/dns-query。

　　Firefox：地址栏输入about:preferences#privacy，找到“基于HTTPS的DNS”部分。有三种保护级别可选：默认保护(出问题回退到系统DNS)、增强保护(强制DoH)、最大保护(连接失败直接报错)。

　　Edge：地址栏输入edge://settings/privacy，开启“使用安全的DNS”，选择服务提供商或自定义接入点。

　　配置完成后，可以用检测工具验证DoH是否生效。如果检测结果显示DNS服务器地址已变为你配置的DoH服务商，说明加密已生效。

　　DoH和DoT是给DNS查询套上的“加密信封”，能有效防住链路中间的偷看和篡改。但如果污染发生在信封到达之前(权威侧)或者你根本寄不出这封信(服务器被阻断)，加密就无能为力了。 加密DNS是隐私保护的重要一步，但它不是DNS安全的万能解药。