DNS的隐私与安全问题

一、传统DNS的隐私与安全问题催生安全DNS技术

DNS应该是家喻户晓的一个名词了，中文名叫作域名系统，用来实现域名和IP地址的映射，是互联网不可或缺的基石。DNS明文传输机制便于防火墙等安全设备进行安全检查和审计，但导致了严重的隐私问题和新的安全问题。先说说隐私问题，由于我们日常的DNS请求都经过运营商（ISP），明文传输的DNS信息在运营商那里都是全部公开透明的，用户毫无隐私可言。即使我们无条件相信运营商不会滥用我们的隐私数据，那么在整个互联网里明文传输的DNS信息也难免被第三方合法地、非法地窃听，后果难以意料。除了隐私问题，明文DNS还存在安全问题，比如域名劫持、重定向、钓鱼等。比如，你明明在浏览器输入的是招商银行，但却有可能被劫持到一个外观同招商银行一样的钓鱼网站。已经有充分的证据表明 [1]，DNS流量被用于非安全目的的过度审查、监管和其他非法目的。

由于安全性和隐私性的考量，对DNS进行加密的技术和方案并不少见。最早的有DNSSEC和DNSCrypt。

DNSSEC [2]通过增加签名验签机制以保护DNS数据的完整性，从而防止中间人攻击，但是DNS数据在网络流量中依然是明文格式，不能解决DNS数据机密性的问题。

DNSCrypt[3] 通过开源社区发起，同时解决了DNS数据的完整性和机密性，但是并没有提出RFC标准建议，且网络应用对其支持非常有限。

DNS over TLS (DoT) [4]于2016年正式提出并发布了RFC标准，DoT通过TLS协议对DNS请求和响应进行加密和封装，并工作于853端口。由于DoT在专门的端口提供服务，很容易被防火墙和其他安全设备识别、审查和阻断，可用性方面存在缺陷。

更引人注目和被寄予厚望的是本文的主角DNS over HTTPS (DoH)。这个方案获得IETF正式支持，于2018年10月发布了RFC 8484[5] 。DoH把DNS请求和响应数据包用HTTPS加密，从而防止第三方对明文DNS数据包的窃听和篡改。目前，DoH已经得到包括Cloudflare、Google、Quad9、阿里巴巴等代表性的公开DNS解析商的支持。主流浏览器（包括Chrome、Firefox、Edge等）和Windows11也正式支持了DoH。可以预计，尽管有监管机构和反隐私组织的反对和阻挠，DoH的使用率在未来依然会稳步提升。

二、DoH如何工作

DoH之所以被寄予厚望，主要原因是能良好融合到HTTP生态，网络应用对DoH的支持也更容易。得益于HTTP/2的特点，DoH可以允许服务端先发地把DNS响应push给客户端（早于客户端发起DNS请求），降低了DNS服务的时延，改善网络应用的性能。DoH将DNS请求和响应封装到HTTP请求的主体，客户端跟递归服务器之间建立一个TLS会话，通过HTTPS协议传输封装了DNS请求的HTTP请求。DoH的封装示意图见图 1。

图1：DoH封装示意图

DoH的工作示意图见图 2。跟传统DNS相比，DoH 通过 443 端口的加密 HTTPS 连接接受 DNS 查询将其发送到兼容 DoH 的 DNS 服务器（解析器），而不是在 53 端口上发送纯文本。这样，DoH 就会在常规 HTTPS 流量中隐藏 DNS 查询，因此第三方监听者将无法嗅探流量，无法获悉用户的 DNS 查询，也就无法推断他们将要访问的网站。

图2 ：DoH工作示意图

三、DoH成为隐蔽隧道攻击的利器

成也萧何败也萧何。DoH虽然具备绝佳的隐私保护能力和安全能力获得用户的青睐，也由于DoH被用于隐蔽隧道攻击而遭到政府机构和安全机构的警惕关注。

将DoH隐蔽隧道攻击之前，先说说DNS隐蔽隧道攻击。

由于几乎所有的网络应用都依赖于DNS作为前置条件，防火墙通常开放53端口供DNS服务正常运行，客户端可以连接到内部的DNS服务器或者外部DNS服务器。这就从根源上导致了DNS被攻击者视为天然的、优质的隐蔽通道。

一个简单的DNS隧道攻击流程，见图 3：攻击者首先接管控制一个目标域名的Name Server(NS)；客户端把C&C数据（命令与控制）或目标数据通过编码、加密、混淆等方法嵌入到一个DNS请求的子域名中；在一个TTL窗口中（窗口大小由递归服务器确定），发起的DNS请求的域名的子域名只要是不重复的，那么递归服务器就查询不到缓存数据，就会把请求转到权威域名服务器，并通过NS指派解析到攻击者所控制的域名服务器，攻击者就能收到C&C数据或者目标数据；攻击者在DNS响应数据包里同样可以嵌入C&C数据或者目标数据，并送达客户端。见图 4、图 5示意。

图 3：DNS隧道拓扑图

图4：通过DNS隧道获取控制命令示意

图5：通过DNS隧道回传窃密信息示意

DNS 隧道可以利用多种记录类型来传输数据，例如 A、MX、CNAME、TXT、 NULL 等，见表 1。

表1：资源记录类型

DNS 隧道的实现工具有很多，表 2介绍了三种常见的。

表2：DNS隧道工具

当DoH技术出现后，为上述的DNS隧道攻击提供了新的利器。基于DoH协议构建隐蔽隧道，不仅通信内容可基于HTTPS协议加密，而且与高可信DoH服务的通信（而非本地DNS服务器）不会引发异常行为，避免了基于DNS的恶意行为检测机制。

随着DoH的使用范围日益扩大，基于DoH的隧道攻击势必成为网络安全领域十分棘手的问题。这个威胁并不是针对未来形势耸人听闻的预判，而是已经成为现实的威胁。利用DoH隧道实施数据外传的首款恶意软件Godlua在2019年被披露[6]；利用DoH实施数据外传的APT组织（APT34）在2020年被披露[7]；其他利用DoH隧道技术进行攻击的研究和开源项目参考[8][9][10]。

四、DoH流量识别技术

为了检测DoH隐蔽隧道攻击，需要做两件事。由于DoH流量隐藏在HTTPS加密流量中，首要任务需要把DoH流量识别出来。

来自SANS协会的Hjelm [11]提出了一种识别DoH行为模式的RITA框架，这种方法不采用网络流量，而是采用Zeek IDS的用户日志；作者认为DoH具备规律的行为模式。

图6：RITA实验环境示意图

但是，这个成果经过其他研究人员[12]进行复现发现，RITA并不能从HTTPS流量中识别DoH流量。

Patsakis等人[13]的研究主要集中在基于DNS隧道的DGA和僵尸网络的检测，也提到了DoH和DoT。作者利用Hodrick-Prescott滤波（H-P滤波）检测出基于DoH/DoT的僵尸网络规律的行为模式，并取得很好的效果，见图 7。但是，DoH往往不局限于僵尸网络场景，对于更一般的通用场景下，识别DoH流量更有迫切需求和研究价值。

图7：基于DNS隧道的DGA和僵尸网络的检

Bushart等人[14]的研究聚焦于识别DoH流量，但局限在于仅仅通过已知的DoH服务商的IP地址进行识别。目前，越来越多的DNS服务商也开始提供DoH服务，且标准DNS和DoH服务都使用一致的IP地址，如谷歌的8.8.8.8、Cloudflare的1.1.1.1。这就使得这种基于IP地址的识别方法不再有效。

图8：基于已知DoH服务商IP地址的识别

五、DoH隧道攻击检测技术

把DoH流量从浩瀚的HTTPS加密流量中识别出来之后，还需要进一步区分这些DoH流量是良性的还是隐蔽隧道攻击。

针对DoH隧道检测技术的研究并不多，大部分研究集中在传统的DNS隧道检测方面。

一些具备代表性的研究成果有：Paxson等人[15]研究开发了一种DNS隧道检测工具，计算DNS请求和响应数据包传递的信息量；Liu等人[16]利用DNS数据包的时间间隙、请求包大小等４个特征训练分类器，实现对DNS隧道的检测；文献[17]提出了一种称为Byte-level CNN的深度神经网络实现检测；Luo等人[18]提出一种可以检测利用A和AAAA资源记录的隧道攻击；Wu等人 采用一种半监督学习的自编码器实现流量特征自动提取，并检测隧道攻击。上述研究成果仅仅针对传统的、明文的DNS数据包发起的隧道攻击。

DoH流量的特征分析可以分为两个阶段：HTTPS客户端-服务端握手阶段、加密传输DNS请求应答阶段。在第一阶段的握手过程中，客户端和服务端之间有少量的数据包交互，且这些数据包包含了明文信息，可用于识别是什么应用发起了HTTPS连接。这个称为TLS指纹的一类技术是实现DoH识别、DoH隧道检测的基础性技术。

TLS指纹技术方面的研究成果颇丰。最具代表性的是Cisco的一些列研究成果[19][20][21][22]，通过对大规模TLS流量的分析，得到恶意软件、企业应用如何使用TLS的模式，提出一种基于目的地上下文和先验知识的精确的TLS指纹生成方法。

考虑到互联网实际场景的复杂性、客户端到递归服务器链路的多样性，基于TLS指纹技术的分类器性能会存在下降。另外，从攻击者视角，攻击者会想方设法逃逸检测。因此，需要构建模拟一些实验场景，通过放大攻击者的逃逸能力从而寻找到DoH隧道检测性能的下确界。如果攻击者需要付出极高代价才能进行逃逸，就能说明DoH隧道检测的有效性。

为数不多且有一定代表性的针对DoH隧道检测的文献，是来自加拿大University of New Brunswick的研究[23]，利用DoH流量特征和神经网络实现了99%的检测准确性。

图9：DoH隧道检测技术框架

六、总结——强盾在何方？

DoH的提出是隐私保护和安全提升的一个里程碑。但是，对于攻击者而言，把攻击活动隐藏到加密的DNS流量是个不错且必然的选择。由于DNS请求和响应的内容不再可见，现有基于域名特征的DNS隧道检测技术几乎全部失效。

构筑DoH隧道攻击的强盾，思路应聚焦于对加密DoH流量的特征分析。具体是采用各种机器学习模型，尤其是深度神经网络，对DoH流量的统计特征、时序特征进行分类。

需要强调的是，根据文献[24]的研究结论，对HTTPS加密流量进行代理解密会大幅降低连接的安全性。这种简单粗暴的代理解密方法难以持续。因此，采用中间人代理的方式对DoH流量进行解密从而把DoH隧道检测问题降级为传统DNS隧道检测的思路并不可行。

DNS解析：原理、常用解析器和优化方法

DNS解析作为互联网通信中不可或缺的一环，对于网站的可访问性和用户体验至关重要。本文将从DNS解析的原理、常用的DNS解析器和DNS解析的优化方法三个方向来介绍DNS解析。

一、DNS解析的原理

DNS解析是指将域名转换成IP地址的过程，它是互联网通信过程中不可或缺的一环。当我们在浏览器输入URL时，浏览器会首先检查自身的DNS缓存，若缓存中已有该域名的解析记录，则直接使用该记录；若没有则向它的默认DNS服务器发起查询请求，寻找到目标主机的IP地址，并将查询结果保存到自身的DNS缓存中。整个DNS查询的过程可以分为递归查询和迭代查询两种形式。

二、常用的DNS解析器

除了操作系统中自带的DNS解析器外，还有一些公共DNS服务可以使用，例如Google提供的公共DNS服务（8.8.8.8和8.8.4.4）、OpenDNS提供的DNS服务（208.67.222.222和208.67.220.220）以及114提供的DNS服务（114.114.114.114）等。

三、DNS解析的优化方法

1. DNS缓存：DNS缓存能够在网站有很多用户访问时，减轻DNS服务器的负担，提高网站的响应速度。对于网站管理员来说，应尽可能使网站支持HTTP Keep-Alive特性，避免每个连接都进行DNS解析，增加DNS缓存的有效期限，并使用CDN等技术来加速网站响应速度。

2. DNS负载均衡：DNS负载均衡技术可以将请求平均分配到多个DNS服务器上，减轻每个DNS服务器的压力，提高DNS解析的速度和可靠性。

3. DNS预解析：DNS预解析是指浏览器对网页中涉及到的链接进行DNS解析并缓存，以便用户点击链接时能够更快地加载网页。对于网站管理员来说，应尽量避免使用不必要的域名，以减少DNS解析次数，同时使用CDN等技术来提高网站访问速度。

总之，DNS解析是互联网通信过程中不可或缺的一环，对于网站的可访问性和用户体验至关重要。通过了解DNS解析的原理、常用的DNS解析器和DNS解析的优化方法，网站管理员可以有效地提升DNS解析的速度和可靠性，从而提高网站的性能和用户满意度。

图解基于HTTPS的DNS

译者丨胡红星

编辑｜张婵 - 高效开发运维公众号

本文主要介绍如何通过基于 HTTPS 的 DNS 和可信递归解析器来保护用户的数据。

用户面临的隐私和安全隐患与日俱增。 在 Mozilla，我们密切关注这些威胁。 我们相信我们有责任尽全力保护 Firefox 用户及其数据。

一些公司和组织想要秘密收集用户数据并拿来出售。 这就是为什么我们添加了跟踪保护并创建了 Facebook 容器扩展。 接下来几个月在保护用户数据方面我们会采取更多的措施。

另外两项要添加的保护措施：

• 基于 HTTPS 的 DNS，这是我们倡导的一项新的 IETF 标准方案
• 可信递归解析器，一种新的解决 DNS 安全的方案，该方案由我们与 Cloudflare 合作提供
  
  

通过这两项举措，逐渐解决了 35 年前创建的域名系统中一直存在的数据泄露问题。那么来看看如何通过基于 HTTPS 的 DNS 和可信递归解析器来保护我们的用户。

但首先，让我们看看网页是如何在互联网中运作的。

如果你对 DNS 和 HTTPS 的工作原理已经非常了解，那么可以跳至"基于 HTTPS 的 DNS 的好处"这部分。

什么是 HTTP？

当我们解释浏览器如何下载网页时，通常会这样解释：

• 浏览器向服务器发出 GET 请求。
• 服务器发送一个响应，该响应是一个包含 HTML 的文件。
  
  

这个系统被称为 HTTP。

但是这张图有点过分简化了。 浏览器不会直接与服务器通话。因为浏览器和服务器可能并不接近。

相反，服务器可能远在千里之外。 因此你的电脑和服务器之间不可能存在直接连接。

从浏览器发出的请求需要经过很多次转手才能到达服务器。 对于从服务器返回的响应也是如此。

这就好比课堂上传递纸条。 纸条会表明应该传递给谁。 写下纸条的学生把纸条传递给相邻的学生。 然后，这个学生又把纸条传递给他相邻的学生 - 可能不是最终的接收者，但一定是到达接受者方向上的某个学生。

问题在于沿路的任何人都可以打开纸条。 而且没有办法事先确定纸条的传递路径，所以不确定会有哪些人访问到纸条。

纸条最后可能会落入想要干坏事的人手上.....

就像对所有人公开了纸条的内容一样。

或者改变响应。

为了解决这些问题，创建了一个新的安全版本的 HTTP，即 HTTPS。 使用 HTTPS，就像每条消息都上了一个锁。

浏览器和服务器都知道该锁的组合，除此之外没有任何人知道。

这样，即使消息在多个路由器之间传递，只有你和网站能够读取到内容。

这解决了很多安全问题。 但是浏览器和服务器之间仍然存在一些未加密的消息。 这意味着消息传递的路径上仍然有人可以窃取你的消息。

在与服务器建立连接的过程中，数据仍然有可能暴露。 当将初始消息发送到服务器时，也会发送服务器名称（在名为“服务器名称指示”的字段中）。 这让运行了多个站点的服务器仍然知道应该与谁通信。 此初始请求的一部分设置了加密，但初始请求本身未加密。

数据暴露的另一个地方是在 DNS 中。 但什么是 DNS？

什么是 DNS？

在上面的图解中，纸条接收者的名字必须放在纸条外面。 对于 HTTP 请求也是如此......HTTP 请求需要指明目的地。

但是不能为 HTTP 请求使用名字。 没有一个路由器会知道你在说什么。 相反，必须使用 IP 地址。 通过 IP 地址中间的路由器就知道应该将请求往哪发。

这会导致问题。 你不会希望用户必须记住网站的 IP 地址。 相反，你希望能够给你的网站一个吸引人的名字...... 用户可以记住的东西。

这就是我们拥有域名系统（DNS）的原因。 浏览器使用 DNS 将站点名称转换为 IP 地址。 这个将域名转换为 IP 地址的过程，称为域名解析。

浏览器是如何做到这一点？

一种选择是拥有一个大名单，比如浏览器中的电话簿。 但是，随着新的网站上线，或者当网站迁移到新的服务器时，很难将该列表保持在最新状态。

因此，不是有一个记录所有域名的列表，而是有很多较小的列表，这些列表相互关联。 这使他们能够独立管理。

为了获得与域名相对应的 IP 地址，必须找到包含该域名的列表。 像寻宝一样。

对于英文版维基百科（en.wikipedia.org）这样的站点来说，它们是如何“寻宝”的？

我们可以将这个域分成几部分。

通过这些部分，我们可以搜索包含该网站 IP 地址的列表。 不过，我们需要一些帮助。 为我们寻找 IP 地址的工具称叫解析器。

首先，解析器与一个称为根 DNS 的服务器通信。 它知道几个不同的根 DNS 服务器，因此它将请求发送给其中的一个。 解析器向根 DNS 服务器询问哪里可以找到有关 org 顶级域名的更多信息。

根 DNS 将为解析器提供一个知道.org 地址的服务器的地址。

下一个服务器叫做 top-level domain 顶级域名服务器 (TLD)。 TLD 服务器知道所有以.org 结尾的二级域名。

但它并不知道 wikipedia.org 下的子域名，所以它不知道 en.wikipedia.org 的 IP 地址。

TLD 名称服务器将告诉解析器询问维基百科的名称服务器。

解析工作快完成了。 维基百科的名字服务器及权限服务器。 它知道 wikipedia.org 下的所有域名。 所以这个服务器知道 en.wikipedia.org 和其他子域名，比如德文版 de.wikipedia.org。 权限服务器通知解析器哪个 IP 地址具有该站点的 HTML 文件。

解析器会将 en.wikipedia.org 的 IP 地址返回给操作系统。

这个过程被称为递归解析，因为你必须来回询问不同的服务器，基本上是同一个问题。

我们需要这样的解析器来完成网络请求。 但浏览器如何找到这个解析器？ 一般来说，它要求计算机的操作系统提供可用的解析器进行设置。

操作系统如何知道使用哪个解析器？ 有两种可能的方法。

你可以为你的计算机配置一个信任的解析器。 但很少有人这样做。

相反，大多数人只是使用默认值。 默认情况下，操作系统将只使用网络告诉它的任何解析器。 当计算机连接到网络并获取其 IP 地址时，网络会推荐一个解析器。

这意味着解析器每天可以更改多次。 例如前往咖啡店参加下午的工作会议，就可能与早上使用的解析器不同。 即使你配置了解析器，这也是正确的，因为 DNS 协议没有安全性。

DNS 如何被利用？

那么这个系统如何让用户安全变得脆弱？

通常解析器会告诉每个 DNS 服务器你正在寻找哪个域名。 该请求有时会包含你的完整 IP 地址。 或者，如果不是完整的 IP 地址，请求中通常会包含你的大部分 IP 地址，这些 IP 地址可以轻松地与其他信息结合起来以找出你的身份。

这意味着进行域名解析的每台服务器都会查看你要查找的网站。 但更重要的是，这也意味着通往这些服务器的任何人都可以看到你的请求。

这个系统有几种方式会使用户的数据处于危险之中。 两大主要的风险是跟踪和欺骗攻击。

跟 踪

就像上面所说的那样，很容易获取全部或部分 IP 地址信息并找出谁在请求该网站。 这意味着 DNS 服务器和通向该 DNS 服务器的路径上的任何其他路由器 (路径路由器) 都可以创建一个关于你的文件。 他们可以创建一个你访问过网站的记录。

而且这些数据很有价值。 许多人和公司会花很多钱看你在浏览什么。

即使不必担心可能的恶意 DNS 服务器或路径路由器，仍有数据被收集的风险。因为解析器本身 - 网络提供给你的 - 可能并不可靠。

即使你信任网络推荐的解析器，可能也只在家中使用该解析器。就像之前提到的那样，每当你去一家咖啡店或酒店或者使用接入其他网络时，你可能会使用不同的解析器。谁知道它的数据收集政策是什么？

除了收集数据，然后在你不知情或不同意的情况下进行销售之外，还有更危险的方式。

欺骗攻击

借助欺骗，DNS 服务器和你之间的路径上的某个人将更改响应。而不是告诉你真正的 IP 地址，欺骗者会给你一个错误的 IP 地址。这样，他们可以阻止访问真实网站或将你引导至欺诈网站。

再次，解析器本身可能使坏。

例如，假设在 Megastore 购物。你想做一个价格对比，看看是否能够在 big-box.com 上获得更便宜的价格。

但是如果你使用 Megastore 的 WiFi，你可能正在使用他们的解析器。该解析器可能会劫持对 big-box.com 的请求并对谎称该网站不可用。

如何通过可信递归解析器（TRR）和基于 HTTPS 的 DNS（DoH）解决此问题？

在 Mozilla，我们强烈认为我们有责任保护用户及其数据。我们一直在努力解决这些漏洞。

我们引入了两项新功能来解决这个问题 - 可信递归解析器（Trusted Recursive Resolver ）和基于 HTTPS 的 DNS（DNS over HTTPS）。因为目前确实有三个威胁需要解决：

• 可能会使用跟踪你请求的不可信的解析器，或者篡改来自 DNS 服务器的响应。
• 路径上路由器可以以相同的方式跟踪或篡改。
• DNS 服务器可以跟踪你的 DNS 请求。
  
  

如何解决这些问题？

• 使用可信递归解析器避免不可靠的解析器。
• 通过基于 HTTPS 的 DNS 防止路径上的窃听和篡改。
• 传输尽可能少的数据，以保护用户免受匿名处理。
  
  

使用可信递归解析器避免不可靠的解析器

当网络提供了不可信的解析器来收集你的数据或进行欺骗攻击，网络服务的提供者依然可以全身而退，因为很少有用户知道风险或如何保护自己。

即使对于了解风险的用户，个人用户也很难与他们的 ISP 或其他实体进行协商，以确保他们的 DNS 数据得到负责任的处理。

但是，我们花时间研究这些风险...... 并且我们有了谈判权力。 我们努力寻找一家公司可以合作来保护用户的 DNS 数据。 我们找到了一个：Cloudflare。

Cloudflare 通过专业用户隐私政策提供递归解析服务。他们承诺在 24 小时后丢弃所有可识别个人身份的数据，并且决不会将这些数据传递给第三方。并会定期进行审计，以确保数据按预期清除。

现在，我们有一个可以信赖的解析器来保护用户的隐私。这意味着 Firefox 可以忽略网络提供的解析器，并直接转到 Cloudflare。有了这个可靠的解析器，我们不必担心流氓解析器出售我们的用户数据或用欺骗性 DNS 来欺骗我们的用户。

我们为什么选择这样一个解析器？ Cloudflare 与我们一样致力于构建隐私优先的 DNS 服务。他们与我们合作建立了一个 DoH 解决方案服务，以透明的方式为用户提供服务。他们一直非常乐意为服务添加用户保护，所以我们很高兴能够与他们合作。

但这并不意味着你必须使用 Cloudflare。用户可以配置 Firefox 使用他们想要的任何支持 DoH 的递归解析器。随着更多产品的出现，我们会让解析器的切换变得简单。

通过基于 HTTPS 的 DNS 防止路径上的窃听和篡改

虽然解析器不是唯一的威胁。路径上路由器可以跟踪和欺骗 DNS，因为他们可以看到 DNS 请求和响应的内容。但是互联网已经有了确保路径上路由器不能像这样窃听的技术。这是我之前提到的加密技术。

通过使用 HTTPS 加密 DNS 数据包，可以确保没有人能够监视用户正在做出的 DNS 请求。

传输尽可能少的数据以保护用户免受匿名处理

除了提供使用 DoH 协议进行通信的可信解析器之外，Cloudflare 正在与我们合作，使其更安全。

通常情况下，解析器会将整个域名发送给每个服务器 - 根 DNS 服务器，TLD 名称服务器，二级名称服务器等。但是 Cloudflare 会做一些不同的事情。它只会发送与当前正在与之通话的 DNS 服务器相关的部分。这被称为 QNAME 最小化。

解析器通常也会在请求中包含你的 IP 地址的前 24 位。 这有助于 DNS 服务器知道你的位置，并选择离你更近的 CDN。 但是这些信息可以被 DNS 服务器用来将不同的请求链接在一起。

Cloudflare 不会这样做，而是从用户附近的一个 IP 地址发出请求。 这提供了地理位置，而无需将其绑定到特定用户。 除此之外，我们正在研究如何以隐私敏感的方式更好的实现，非常细粒度的负载平衡。

这样做 - 删除域名中不相关的部分并且不包括你的 IP 地址 - 意味着 DNS 服务器所收集的关于你的数据要少得多。

基于 DoH 的 TRR 还未解决的问题

通过这些解决方案，我们减少了可以看到你访问网站的人数。但是这并不能完全消除数据泄漏。

在执行 DNS 查找到 IP 地址后，你仍然需要连接到该地址的 Web 服务器。为此，发送初始请求。该请求包含一个服务器名称指示，该信息指出要连接的服务器上的哪个站点。这个请求是未加密的。

这意味着你的 ISP 仍然可以找出正在访问的网站，因为它正好在服务器名称指示中。另外，将来自浏览器的初始请求传递给 Web 服务器的路由器也可以看到这些信息。

但是，一旦你建立了与 Web 服务器的连接，那么一切都是加密的。并且这个加密的连接可以用于该服务器上托管的任何站点，而不仅仅是最初要求的那个站点。

这称为 HTTP / 2 连接合并，或简单地连接重用。当你打开一个连接到支持它的服务器时，该服务器会告诉你它托管了哪些其他的站点。然后，你可以使用现有的加密连接访问其他网站。

这样有什么好处？ 无需启动新连接即可访问这些其他网站。 这意味着你不需要发送未加密的初始请求，其服务器名称指示正在访问的站点。 这样可以访问同一台服务器上的任何其他站点，而无需透露你正在查看的站点到网络服务提供商和路径路由器。

随着 CDN 的兴起，越来越多的独立站点由一台服务器提供服务。 由于可以打开多个合并连接，因此可以同时连接到多个共享服务器或 CDN，访问不同服务器上的所有站点而不会泄露数据。 这意味着隐私保护越来越有效。

想要上网体验有保障，如何设置一个更安全的 DNS？

我们很难记住所有人的电话号码，大部分时候我们都需要通讯录帮助我们把一个人的姓名和号码联系起来。而 DNS 服务器干的事情和通讯录差不多，帮助我们把网址转换成 IP，让程序知道他们需要链接的服务器具体在哪里（或是服务器不存在）。

最为简单的 DNS 请求过程
随着互联网技术的日新月异，大家上网的时候遇到下面的情况的概率却一点都没变少：

• 从官网下载内容的时候，下载的地址是一串 IP 而不是官网地址，而且下载下来的内容有的时候不是最新的。
• 打开一个网站以后，网站内有部分广告质量明显不如其他的广告，或者明显遮挡了网页中的内容
• 输错网站打开一个全是广告的页面
• 网站内的广告画风和整个网站完全不搭
• 经常性地遇到有些页面打不开（无法解析这个网址），但是过了一会儿又好了。
  
  

这些问题很多时候都是和你家的 DNS 设置有关系。

为什么会发生这些问题
只要你接入了互联网，互联网服务提供商（也被称为 ISP，以下简称： 运营商）都会下发两个 DNS 给你，这个就是运营商 DNS。

和电话对应起来，DNS 服务器则将网址和 IP 对应起来。随着互联网技术的日新月异，DNS 服务器也经过了一段漫长的发展，衍生出了更多更棒的功能，让用户能自由地在网上冲浪。

每个运营商在几乎在每个城市都会部署自己的独立的 DNS 服务器，这也是为什么同一个运营商在不同城市分发下来的 DNS 服务器的地址也都不一样。加上运营商是最了解 内容分发网络（也就是我们经常说的 CDN，CDN 主要起到两大作用，第一个是能让用户用最快的速度访问到用户想要访问的内容，第二点是能减少主服务器的所需要的带宽和维护成本）的位置和自家网络的情况，所以运营商 DNS 返回的结果应该是：最准确的、最合适的，响应时间短的以及 CDN 解析结果最准确的，简单来说就是：你能快速访问到位于你附近的有你想要访问到内容的服务器。

中国电信的路由表-图源 http://bgp.he.net




在每个城市都要维护一个 DNS 服务器开销自然不会小到那里去，所以运营商经常在 DNS 结果上进行改动，发生文章开头所说的问题。运营商那么做主要是为了减少成本。当然还有种情况是附近的 DNS 服务器没有及时扩容或者维护不善，导致了上述的情况。
利用公共 DNS 服务来解决这个问题解决上述这个问题的最快的办法就是使用公共 DNS 服务。
公共 DNS 服务器一般是由大公司搭建的，或者非盈利组织搭建的。公共 DNS 的本质上就是把你的查询请求转发给上游更权威的 DNS，所以一般这些公司或者组织提供的公共 DNS 服务器提供都是更安全、更准确的结果。
当然由于资金限制，公共 DNS 服务器不会每个城市都有一个。自然就会遇到使用公共 DNS 服务解析到的 IP 不是最快的情况。下图展示了相同网址使用运营商 DNS 解析到的结果和使用阿里云公共 DNS 解析到的两种延迟完全不同的结果（ time-ios.apple.com 是一个通过 CDN 优化了网站)：


DNS 返回结果对比


小知识：怎么快速知道我到某个服务器之间的延迟？?
使用 ping 指令
ping 是一种计算机网络工具，用来测试数据包能否透过IP协议到达特定主机。按时间和成功响应的次数估算丢失数据包率（丢包率）和数据包往返时间（网络时延，Round-trip delay time）
ping 会直接附带在任何的操作系统的内置终端（或者命令提示符）中，使用时，用户只需要使用 ping +网址/IP 地址(如 ping 17.253.84.251）并敲击回车即可得到结果。
因此，我们在挑选公共 DNS 的时候，要注意以下方面：

• 在线率：也被叫做 SLA 或者可靠性，DNS 服务器作为将网址和 IP 联系起来的唯一手段，如果在线率不够高，那么时不时就会遇到的无法解析网址的情况，大大降低网上冲浪的乐趣和连贯性。
• 响应速度：在访问一个新的网站时，DNS 对这个网站的响应速度会直接影响到当前网站的直观加载速度。
• 准确性： 即使不考虑 DNS 污染和投毒，DNS 对网站访问的结果是否准确是非常重要的。
• CDN 友好性：也被叫做 ECS 或是 EDNS，ECS 有助于帮助你获取最准确的 CDN 解析结果，这个也是我在挑选公共 DNS 最为看重的一点。
• DNS 出口位置： 在没有 ECS 的情况下，CDN 的权威 DNS 会根据公共 DNS 使用的请求 IP（也就是 DNS 出口）来判定你的运营商、你所在的位置，从而返回距离你最近的节点 IP。在有 ECS 的情况下，返回结果的所需要的时间会更低，CDN 判断会更准确。
  
  

受限于篇幅限制，下图只介绍符合 RFC 规范的（排除 IBM Quad9 DNS），拥有多个响应地点的（排除 360 公共 DNS）大型的，准确性也相对较好的（不会刻意投毒的），更重要的是 CDN 友好型的 公共 DNS 服务。延迟则由各个地方各个运营商决定，请自行测试。

推荐的公共 DNS 服务器


利用安全的公共 DNS 服务解决这个问题
不过在一部分 DNS 问题严重的地方，将运营商 DNS 更换为公共 DNS 可能还是不能解决本文开头的问题。


这是因为我们的 DNS 流量没有经过加密，就和曾经的 http 协议一样，运营商或是第三方还是能够清楚的知道：我们发起了一个 DNS 请求，我们想要知道 xxx 网站的地址。下图展示了一个 DNS 请求发起的过程，可以很清楚的看到，我请求了什么网址（用十六进制码显示，右侧是转义以后的结果）

一条普通的 DNS 查询


如果我们给我们的 DNS 流量加个密，就和 https 流量一样，那么运营商不就不知道我们我们的 DNS 请求了吗。这就是 DNS over HTTPS (下文简称 DoH )和 DNS over TLS (下文简称 DoT )技术要做的事。他们分别利用 HTTPS （超文本传输安全协议）和 TLS（传输层安全协议）这两种行业通用的安全协议，将我们的 DNS 请求发往 DNS 服务器。运营商或是第三方在整个传输过程中，只能知道发起者和目的地，除此以外别的什么都知道，甚至都不知道你发起了 DNS 请求。同时 HTTPS 和 TLS 都会使用网络数字证书确保对面的身份，这样传输的过程中无论是任何第三方都不能修改 DNS 的请求内容和最后的结果。保证你请求的结果就是你最后想要的。
DoH 和 DoT 不仅能为经常被运营商和第三方劫持 DNS 的人群提供安全可靠的 DNS 解析结果，还能给极为看重隐私人群补上上网隐私保护流程中的最后一块短板。
下图是目前支持 DoH 或者 DoT 的 DNS 服务器列表

推荐的安全 DNS 服务器


我应该怎么使用 DoH 和 DoT 技术对于 iOS 设备大家可以前往 App Store 中下载 Cloudflare App（也被称为 1.1.1.1），下载以后，打开应用，直接打开开关即可享用到来自 Cloudflare 提供的 DoH 服务。

通过 Cloudflare 使用安全的公共 DNS 服务器


Adguard iOS 版的用户可以手动选择 DNS 服务器（需要高级订阅），前往 Adguard iOS 版本的设置，选择 DNS，再选择合适的 DNS 服务器即可，当然你也可以选择手动输入自定义的 DNS 服务器（DoH 和 DoT 均支持）使用这项功能。

通过 Adguard iOS 使用安全的公共 DNS 服务器


对于 AndroidAndroid 9 以及以上的版本，你可以前往无线和网络，选择指定加密 DNS 服务(部分设备上可能被命名为：私人 DNS），输入 DNS over TLS 的地址即可。

Android 9 以及以上的版本直接能进行设置


对于 Android 9 以下的版本，或者没有指定加密 DNS 服务，你可以前往各大应用市场下载 Intra 应用，进行配置。前往 Intra 的设置，选择 DNS over HTTPS 服务器，输入或者选择 DNS over HTTPS 服务器即可。

通过 Intra 使用安全的公共 DNS 服务器


当然，如果你是 Adguard Android 版的用户，你可以前往 Adguard Android 版本的设置，选择 DNS，再选择合适的 DNS 服务器即可，和 iOS 版本一样你也可以选择手动输入自定义的 DNS 服务器，使用更适合自己的 DNS 服务器。

通过 Adguard Android 使用安全的公共 DNS 服务器


对于 macOS & Windows对于完全不熟悉终端命令的用户来说，现在想在 macOS 或者 Windows 上得到安全可靠的解析，那么 Firefox 浏览器是目前唯一的选择，前往 Firefox 的设置，常规-网络设置-设置，选择启用基于 HTTPS 的 DNS，这样就打开了 Firefox 上的 DoH 服务了。

通过 Firefox 使用安全的公共 DNS 服务器


当然，用户基数更大的 Chrome 在未来也会在实验性设置里提供对应的选项（本文写作时 Chrome 正式版本为 77，从 78 版本开始将在实验性设置里提供对应的选项，78 正式版本将在 10 月 22 日推送）。打开你的 Chrome，在地址栏中输入 chrome://flags/#dns-over-https，回车，在右侧下拉箭头中选择 Enable。这样就打开了 Chrome 78 上的 DoH 服务了。

在 Chrome 里打开 DoH
如果你自己有的代码基础，也可以选择DNScrypt 作为本地的 DNS 客户端，提供安全可靠的 DNS 解析。当然你对代码有更深入的了解，想要给全家或是全公司提供安全的 DNS，那么红鱼的这份文档就特别适合你。当然，希望在未来这两大操作系统能加入对应的设置，给我们提供额外的安全的选择。
以上就是这篇文章的所有内容了，希望能够让你能够了解到目前的 DNS 的发展情况，并帮助到因为 DNS 被劫持或是默认  DNS 不那么好用，备受苦恼的你。