<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>DoH on 飞鸽跳转</title><link>https://feige301.com/zh-cn/tags/doh/</link><description>Recent content in DoH on 飞鸽跳转</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Sun, 22 Mar 2026 01:40:20 +0800</lastBuildDate><atom:link href="https://feige301.com/zh-cn/tags/doh/index.xml" rel="self" type="application/rss+xml"/><item><title>DNS Over HTTPS (DoH) 在反劫持中的实战应用</title><link>https://feige301.com/zh-cn/posts/2026/dns-over-https-doh-anti-hijacking-practical-application.html</link><pubDate>Sun, 22 Mar 2026 01:40:20 +0800</pubDate><guid>https://feige301.com/zh-cn/posts/2026/dns-over-https-doh-anti-hijacking-practical-application.html</guid><description>&lt;h2 id="引言网络世界的电话簿与它的脆弱性">
 引言：网络世界的“电话簿”与它的脆弱性
 &lt;a class="anchor" href="#%e5%bc%95%e8%a8%80%e7%bd%91%e7%bb%9c%e4%b8%96%e7%95%8c%e7%9a%84%e7%94%b5%e8%af%9d%e7%b0%bf%e4%b8%8e%e5%ae%83%e7%9a%84%e8%84%86%e5%bc%b1%e6%80%a7">#&lt;/a>
&lt;/h2>
&lt;p>我们每天访问的网站、使用的应用程序，其背后都离不开一个基石性的服务——域名系统（DNS）。您可以将DNS想象成互联网的“电话簿”：当您输入一个网站域名（例如 &lt;code>feige301.com&lt;/code>）时，DNS系统会迅速将其翻译成一个机器能够识别的数字地址（IP地址），就像您在电话簿中查找一个人的名字，然后拨打他的电话号码一样。这个过程看似简单，却是所有网络连接的起点。&lt;/p>
&lt;p>然而，正是这个每天都在默默工作的“电话簿”，却面临着巨大的安全挑战。传统的DNS查询通常以明文形式在网络中传输，这就像您在公共场合大声询问某个电话号码一样，任何人都可以听到、记录，甚至篡改您的请求或响应。这种固有的脆弱性，使得DNS流量极易成为各种网络干扰和攻击的目标。&lt;/p>
&lt;p>在特定网络区域或复杂的网络环境中，网站管理员和运维工程师常常会遇到一些棘手的连接问题。例如，用户反馈无法访问网站，或者被意外重定向到错误的页面。这背后的元凶往往是 &lt;strong>ISP劫持&lt;/strong> 和 &lt;strong>域名污染&lt;/strong>。当中间设备（例如某些流量网关或某地区运营商的DNS服务器）恶意篡改DNS解析结果时，用户的请求就无法到达预期的服务器，导致访问中断或被导向不安全的内容。对于高度依赖用户访问和数据完整性的高并发商业站点、数字娱乐平台或内容密集型业务而言，这无疑是致命的打击，不仅影响用户体验，更可能造成数据损失和品牌信誉的严重损害。&lt;/p>
&lt;p>面对这些挑战，我们不禁要问：有没有一种方法，能够确保用户的“电话簿查询”始终是私密且准确的，无论他们身处何种网络环境？有没有一种技术，能够为我们的网站构筑一道坚实的防线，抵御来自DNS层面的干扰？答案是肯定的，这就是我们今天要深入探讨的——&lt;strong>DNS Over HTTPS (DoH)&lt;/strong>。它不仅仅是一种技术规范，更是解决域名解析完整性和反劫持问题的实战利器。&lt;/p>
&lt;h2 id="传统dns明文传输的开放秘密">
 传统DNS：明文传输的“开放秘密”
 &lt;a class="anchor" href="#%e4%bc%a0%e7%bb%9fdns%e6%98%8e%e6%96%87%e4%bc%a0%e8%be%93%e7%9a%84%e5%bc%80%e6%94%be%e7%a7%98%e5%af%86">#&lt;/a>
&lt;/h2>
&lt;p>要理解DoH的价值，我们首先需要回顾传统DNS的工作原理及其固有缺陷。&lt;/p>
&lt;h3 id="dns解析的寻路之旅">
 DNS解析的“寻路”之旅
 &lt;a class="anchor" href="#dns%e8%a7%a3%e6%9e%90%e7%9a%84%e5%af%bb%e8%b7%af%e4%b9%8b%e6%97%85">#&lt;/a>
&lt;/h3>
&lt;p>当您在浏览器中输入一个域名并按下回车键时，一系列复杂的幕后操作便开始了：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>浏览器缓存与操作系统缓存：&lt;/strong> 浏览器首先会检查自己的缓存，如果找不到，会请求操作系统。&lt;/li>
&lt;li>&lt;strong>本地DNS解析器：&lt;/strong> 操作系统会将其请求发送给配置的本地DNS解析器，这通常是您的路由器或某地区运营商提供的DNS服务器。&lt;/li>
&lt;li>&lt;strong>递归DNS服务器：&lt;/strong> 本地解析器收到请求后，会作为“递归DNS服务器”的角色，开始向互联网上的其他DNS服务器（根域名服务器、顶级域名服务器、权威域名服务器）逐级查询，直到找到该域名对应的IP地址。&lt;/li>
&lt;li>&lt;strong>返回结果：&lt;/strong> 最终，IP地址会被返回给本地解析器，然后经过操作系统和浏览器，最终浏览器使用这个IP地址与目标服务器建立连接。&lt;/li>
&lt;/ol>
&lt;h3 id="明文传输的阿喀琉斯之踵">
 明文传输的阿喀琉斯之踵
 &lt;a class="anchor" href="#%e6%98%8e%e6%96%87%e4%bc%a0%e8%be%93%e7%9a%84%e9%98%bf%e5%96%80%e7%90%89%e6%96%af%e4%b9%8b%e8%b8%b5">#&lt;/a>
&lt;/h3>
&lt;p>这个“寻路”之旅中，绝大多数环节，尤其是本地DNS解析器与递归DNS服务器之间的通信，以及递归DNS服务器与权威DNS服务器之间的通信，都是通过UDP协议在端口53上进行的。UDP/53的特点是快速、高效，但它有一个致命的弱点：&lt;strong>不加密&lt;/strong>。这意味着，所有的DNS查询请求（您要访问哪个域名）和响应（该域名对应的IP地址）都是以明文形式在网络中传输的。&lt;/p>
&lt;p>这种明文传输带来的问题是显而易见的：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>窃听（Eavesdropping）：&lt;/strong> 网络中的任何中间设备或恶意攻击者都可以轻易地捕获您的DNS查询流量，从而得知您正在访问哪些网站。这直接侵犯了用户的隐私权。&lt;/li>
&lt;li>&lt;strong>篡改与劫持（Tampering &amp;amp; Hijacking）：&lt;/strong> 由于缺乏加密和身份验证，中间设备可以轻而易举地拦截您的DNS请求，并返回一个伪造的IP地址。例如，当您请求 &lt;code>example.com&lt;/code> 的IP时，它可能返回一个攻击者控制的服务器IP，从而将您重定向到恶意网站，这就是典型的&lt;strong>DNS劫持&lt;/strong>。&lt;/li>
&lt;li>&lt;strong>域名污染（Domain Pollution）：&lt;/strong> 在更广泛的层面上，某些流量网关或中间设备可能通过注入错误的DNS记录，使特定域名在局部局域网环境中无法被正确解析，或者解析到错误的IP地址，导致服务不可用。这使得网站管理员难以保证其内容的全球可访问性。&lt;/li>
&lt;li>&lt;strong>缓存投毒（Cache Poisoning）：&lt;/strong> 攻击者向DNS服务器发送伪造的响应，使其缓存错误的域名解析记录，影响后续的用户查询。&lt;/li>
&lt;/ul>
&lt;p>我们可以用一个生活化的比喻来理解：传统DNS就像您在邮局寄送一张明信片。上面的信息（您要寄给谁，对方的地址是什么）是完全公开的。邮局的员工（中间设备）可以随意查看，甚至在投递前修改明信片上的地址，将它寄往一个完全不同的地方。在某些特殊情况下，这种“修改”可能是为了进行流量管理，但在更多情况下，它会给用户带来困扰，甚至安全风险。&lt;/p>
&lt;h2 id="doh登场为dns查询穿上加密外衣">
 DoH登场：为DNS查询穿上“加密外衣”
 &lt;a class="anchor" href="#doh%e7%99%bb%e5%9c%ba%e4%b8%badns%e6%9f%a5%e8%af%a2%e7%a9%bf%e4%b8%8a%e5%8a%a0%e5%af%86%e5%a4%96%e8%a1%a3">#&lt;/a>
&lt;/h2>
&lt;p>面对传统DNS的诸多安全和隐私漏洞，互联网社区一直在寻求更安全的替代方案。其中，&lt;strong>DNS Over HTTPS (DoH)&lt;/strong> 应运而生，它为DNS查询提供了一种加密和认证的机制，旨在解决上述问题。&lt;/p>
&lt;h3 id="doh是什么">
 DoH是什么？
 &lt;a class="anchor" href="#doh%e6%98%af%e4%bb%80%e4%b9%88">#&lt;/a>
&lt;/h3>
&lt;p>简单来说，DoH是将传统的DNS查询请求和响应封装在&lt;strong>HTTPS&lt;/strong>协议中进行传输。这意味着，DNS数据不再是明文，而是像您访问加密网站（URL以&lt;code>https://&lt;/code>开头）一样，通过SSL/TLS加密隧道进行传输。&lt;/p>
&lt;h3 id="doh如何工作">
 DoH如何工作？
 &lt;a class="anchor" href="#doh%e5%a6%82%e4%bd%95%e5%b7%a5%e4%bd%9c">#&lt;/a>
&lt;/h3>
&lt;ol>
&lt;li>&lt;strong>端口443的优势：&lt;/strong> DoH利用标准的HTTPS协议，通过TCP端口443进行通信。这个端口通常用于安全的网页浏览，因此DoH流量可以与普通的Web流量混淆在一起，使得中间设备难以区分和单独阻断或篡改。&lt;/li>
&lt;li>&lt;strong>加密与认证：&lt;/strong> 当您的设备发起一个DoH请求时，它会首先与DoH服务器建立一个TLS加密连接。在这个连接中，所有的DNS查询和响应都会被加密。同时，TLS协议还提供了服务器身份验证，确保您正在与一个可信的DoH解析器通信，而非伪装的恶意服务器。&lt;/li>
&lt;li>&lt;strong>JSON格式的响应：&lt;/strong> DoH的响应通常以JSON格式返回，而不是传统的二进制DNS报文，这使得其与Web开发和API调用更加融合。&lt;/li>
&lt;/ol>
&lt;p>我们可以继续用“电话簿”的比喻来解释DoH：现在，您不再是在公共场合大声询问电话号码，而是通过一个安全的、加密的电话线路，直接拨打“电话簿公司”的客服热线。在电话中，您私密地询问您想知道的号码，并且客服（DoH服务器）也会通过这条加密线路，私密且准确地告诉您结果。整个过程是端到端加密的，任何中间的监听者都无法知道您询问了什么，也无法篡改客服给您的回答。&lt;/p></description></item><item><title>DoH与DoT：DNS查询的隐形斗篷</title><link>https://feige301.com/zh-cn/posts/2026/doh-dot-dns-query-invisible-cloak-firefox-controversy.html</link><pubDate>Mon, 09 Feb 2026 16:47:20 +0800</pubDate><guid>https://feige301.com/zh-cn/posts/2026/doh-dot-dns-query-invisible-cloak-firefox-controversy.html</guid><description>&lt;h3 id="前言互联网的电话簿与它的公开秘密">
 前言：互联网的“电话簿”与它的“公开秘密”
 &lt;a class="anchor" href="#%e5%89%8d%e8%a8%80%e4%ba%92%e8%81%94%e7%bd%91%e7%9a%84%e7%94%b5%e8%af%9d%e7%b0%bf%e4%b8%8e%e5%ae%83%e7%9a%84%e5%85%ac%e5%bc%80%e7%a7%98%e5%af%86">#&lt;/a>
&lt;/h3>
&lt;p>我们每打开一个网站，看似简单的操作背后，都离不开一个核心服务的支撑——域名系统（DNS）。你可以将DNS比作互联网的“电话簿”，它负责将我们易于记忆的域名（如&lt;code>feige301.com&lt;/code>）翻译成机器可识别的IP地址（如&lt;code>192.0.2.1&lt;/code>），从而引导我们的设备找到正确的服务器。没有DNS，互联网将寸步难行。&lt;/p>
&lt;p>然而，这个至关重要的“电话簿”服务，长期以来却存在一个“公开的秘密”：传统的DNS查询是未经加密的。这就好比你每次查电话号码，都要通过一张明信片发送请求，所有人都能看到你查询了什么号码，以及谁回复了你。这种明文传输的特性，使得DNS查询极易受到各种形式的监听、篡改和劫持。&lt;/p>
&lt;p>在复杂的网络环境中，这种脆弱性导致了一系列困扰网站管理员和用户的难题：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>域名污染（Domain Pollution）&lt;/strong>：恶意或非恶意的中间设备，通过篡改DNS响应，将用户导向错误的IP地址，导致网站无法访问或被劫持到钓鱼页面。&lt;/li>
&lt;li>&lt;strong>ISP劫持（ISP Hijacking）&lt;/strong>：某些运营商或网络服务提供商，出于各种目的（如插入广告、限制访问），在DNS层面篡改用户的查询结果，影响用户体验和网站的正常运营。&lt;/li>
&lt;li>&lt;strong>区域性网络封锁（Regional Network Blocking）&lt;/strong>：在特定网络区域内，通过对传统DNS查询的识别和干预，阻止用户访问某些域名，造成连通性障碍。&lt;/li>
&lt;/ul>
&lt;p>这些问题不仅损害了用户的上网体验，也给网站运营者带来了巨大的挑战：流量无故流失、用户信任度下降、安全风险增加，甚至直接影响商业利益。在这样的背景下，寻找一种能够保护DNS查询隐私和完整性的技术方案，成为了网络安全领域的重要议题。这正是我们今天要深入探讨的DoT（DNS over TLS）和DoH（DNS over HTTPS）技术诞生的核心驱动力。它们旨在为DNS查询披上一层“隐形斗篷”，使其在复杂的网络环境中能够安全、私密地穿梭。&lt;/p>
&lt;h3 id="传统dns明文传输的软肋">
 传统DNS：明文传输的“软肋”
 &lt;a class="anchor" href="#%e4%bc%a0%e7%bb%9fdns%e6%98%8e%e6%96%87%e4%bc%a0%e8%be%93%e7%9a%84%e8%bd%af%e8%82%8b">#&lt;/a>
&lt;/h3>
&lt;p>在深入了解DoT和DoH之前，我们有必要回顾一下传统的DNS工作方式。当你在浏览器中输入一个域名时，你的操作系统会首先向本地配置的DNS服务器（通常是你的路由器或网络服务提供商提供的服务器）发送一个DNS查询请求。这个请求通常使用UDP协议，通过53端口进行传输。&lt;/p>
&lt;p>整个查询过程是明文的，这意味着在你的设备和DNS服务器之间的任何“中间设备”——例如你家里的路由器、你所在局域网的流量网关，甚至是某地区运营商的DPI（深度包检测）设备——都能够轻松地读取你的DNS查询内容（你访问了哪个域名）和DNS服务器的响应（这个域名对应的IP地址）。&lt;/p>
&lt;p>这种明文传输的特性，虽然在互联网早期提供了高效便捷的服务，但在当今对隐私和安全日益重视的时代，却成为了一个明显的“软肋”：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>隐私泄露风险&lt;/strong>：你的上网行为轨迹，通过DNS查询记录一览无余。第三方可以根据这些记录分析你的兴趣、习惯，甚至用于精准广告投放或更敏感的数据收集。&lt;/li>
&lt;li>&lt;strong>篡改与劫持威胁&lt;/strong>：由于缺乏加密和身份验证机制，恶意的“中间设备”可以轻易地拦截你的DNS查询，并返回一个伪造的IP地址。这会导致用户访问错误的网站（例如钓鱼网站），或者被重定向到非预期的页面。这就是“域名污染”和“ISP劫持”的常见技术实现方式之一。&lt;/li>
&lt;li>&lt;strong>内容过滤与审查&lt;/strong>：在某些“局部局域网环境”中，流量网关或DPI设备可以识别并过滤特定的DNS查询，从而阻止用户访问某些域名。这种基于DNS的过滤机制，是实现“区域性网络封锁”的一种有效且成本较低的手段。&lt;/li>
&lt;/ol>
&lt;p>对于网站管理员和运维人员而言，这意味着即使他们的网站服务器本身配置安全，也可能因为DNS层面的问题导致用户无法访问。解决这一“软肋”，成为了网络安全演进的必然趋势。&lt;/p>
&lt;h3 id="隐私与完整性的追求dot与doh的崛起">
 隐私与完整性的追求：DoT与DoH的崛起
 &lt;a class="anchor" href="#%e9%9a%90%e7%a7%81%e4%b8%8e%e5%ae%8c%e6%95%b4%e6%80%a7%e7%9a%84%e8%bf%bd%e6%b1%82dot%e4%b8%8edoh%e7%9a%84%e5%b4%9b%e8%b5%b7">#&lt;/a>
&lt;/h3>
&lt;p>为了应对传统DNS的这些安全与隐私挑战，互联网工程任务组（IETF）相继推出了两种加密DNS查询的新协议：DoT（DNS over TLS）和DoH（DNS over HTTPS）。它们的核心目标都是为DNS查询提供加密保护，确保查询内容不被窃听，响应结果不被篡改。&lt;/p>
&lt;h4 id="dotdns-over-tls加密的直连通道">
 DoT（DNS over TLS）：加密的直连通道
 &lt;a class="anchor" href="#dotdns-over-tls%e5%8a%a0%e5%af%86%e7%9a%84%e7%9b%b4%e8%bf%9e%e9%80%9a%e9%81%93">#&lt;/a>
&lt;/h4>
&lt;p>DoT，即DNS over TLS，顾名思义，它将DNS查询封装在TLS（传输层安全协议）之上。TLS是当前互联网上广泛用于加密通信的协议，例如我们访问HTTPS网站时，就是通过TLS来保障数据安全的。&lt;/p>
&lt;p>&lt;strong>工作原理：&lt;/strong>
DoT协议将传统的DNS查询数据包（通常是UDP 53端口）放入一个TLS加密隧道中，并通过TCP 853端口进行传输。这意味着你的DNS查询不再是明文的，而是经过加密的，只有你的设备和DoT服务器能够解密并读取内容。&lt;/p>
&lt;p>&lt;strong>优点：&lt;/strong>&lt;/p>
&lt;ul>
&lt;li>&lt;strong>加密保护&lt;/strong>：防止“中间设备”监听你的DNS查询内容，保护用户隐私。&lt;/li>
&lt;li>&lt;strong>身份验证&lt;/strong>：TLS协议提供了服务器身份验证机制，可以确保你连接的是合法的DoT服务器，而非伪造的恶意服务器，从而有效抵御DNS劫持。&lt;/li>
&lt;li>&lt;strong>数据完整性&lt;/strong>：加密同时保障了数据传输的完整性，防止DNS响应被篡改。&lt;/li>
&lt;/ul>
&lt;p>&lt;strong>局限性：&lt;/strong>
尽管DoT提供了强大的安全保障，但它也有其特点：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>专用端口&lt;/strong>：DoT使用专用的853端口。这意味着“中间设备”仍然可以通过识别这个端口来判断正在进行的是DNS查询，即使内容被加密，它们也知道这是一次DNS请求。在某些严格的“局部局域网环境”中，如果853端口被直接阻断，DoT服务将无法使用。&lt;/li>
&lt;li>&lt;strong>流量特征&lt;/strong>：虽然内容加密，但DoT的流量模式和握手过程仍可能与其他HTTPS流量有所区别，理论上仍有可能被高级的DPI设备识别并进行针对性干预。&lt;/li>
&lt;/ul>
&lt;p>你可以将DoT想象成一个专为电话簿查询设计的加密信封，你把查询请求装进去，通过一个私密的邮递员（TLS）送到电话局。虽然邮递员知道你在查电话簿，但不知道具体查了谁，也无法篡改回复。&lt;/p>
&lt;h4 id="dohdns-over-https隐形斗篷下的秘密通信">
 DoH（DNS over HTTPS）：隐形斗篷下的秘密通信
 &lt;a class="anchor" href="#dohdns-over-https%e9%9a%90%e5%bd%a2%e6%96%97%e7%af%b7%e4%b8%8b%e7%9a%84%e7%a7%98%e5%af%86%e9%80%9a%e4%bf%a1">#&lt;/a>
&lt;/h4>
&lt;p>DoH，即DNS over HTTPS，是另一种更具“隐蔽性”的加密DNS查询方式。它将DNS查询封装在标准的HTTPS（超文本传输安全协议）请求中，并通过TCP 443端口进行传输。&lt;/p>
&lt;p>&lt;strong>工作原理：&lt;/strong>
DoH巧妙地将DNS查询伪装成普通的网页浏览请求。当你的设备发起一个DoH查询时，它实际上是向一个支持DoH的HTTPS服务器发送一个HTTPS GET或POST请求，而这个请求的URL或请求体中包含了DNS查询的信息。服务器收到请求后，解析出DNS查询，执行解析，然后将结果封装在HTTPS响应中返回。&lt;/p>
&lt;p>**核心优势：**&lt;strong>混淆与隐蔽&lt;/strong>&lt;/p></description></item></channel></rss>