在 DNS 协议下，计算机通过向域名服务器发送 UDP 消息，请求域名相关联的 IP 地址。而具体响应请求的 DNS 服务器，通常基于本地网络的推荐确定。计算机一旦连接到网络，一般情况下会使用网络管理员建议的 DNS 服务器。

DNS 历史悠久，但一直未对 DNS 查询提供任何防护， 难以防范中间人攻击、追踪和篡改等安全隐患 。当前，人们已经意识到这个问题，并给出了多种推荐的解决方案。

DNS over TLS

显而易见，解决 DNS 查询未加密的问题，首先考虑对查询本身做加密处理。DNS 查询可以 通过TLS 而非UDP 发送，并不会影响到其它操作。我们可以使用网络推荐的域名服务器，并尽可能通过TLS 进行通信，其它操作则如常进行。

这一机制提供了一定程度上的安全和隐私性改进。处于用户计算机和DNS 服务器之间的计算机，无法干扰、记录和篡改用户的DNS 通信流。

DNS over HTTPS

类似于 DNS over TLS 等机制， DNS over HTTPS 协议试图解决同样的安全和隐私问题。该机制并不考虑在原始 TLS 中包装 DNS 查询，而是包装在 HTTPS 中。而 HTTPS 协议本身是运行于 TLS 之上的。

该机制的合理性在于，用户无需防护未知中间者，只需防护恶意的网络管理员。如果网络管理员可以选择网络中通信的 DNS 服务器，那么用户就会在毫不知情的情况下被路由到某个恶意服务器。实话讲，根本无法相信咖啡店的 Wi-Fi 会有什么安全的 DNS 服务器。如果要加密的服务器并不符合你的利益，那么加密本身也起不了什么作用。

网络运营商可以强制人们始终使用他们所选择的服务器发出 DNS 请求，方法是针对其它服务器的请求实施中间人攻击（MITM），并自己回复它们，或者仅阻止 DNS 端口上与其他服务器之间的通信即可。DNS over TLS 可避免前者，并且由于 DNS over TLS 具有自己的服务端口，因此可以识别并阻止 DNS over TLS 流量。DNS over HTTPS 通过将 DNS 流量与所有其他 HTTPS 的流量混合在一起，完全避免产生上述问题。通常，管理者是无法禁止流向某个服务器的所有 HTTPS 流量。

DNS over TLS 和 DNS over HTTPS 之间的差异在于，某些人认为他们有权限制其所提供公用事业服务的用户，而一些用户则想直接让这些管控者“滚得远远的”。

混淆视听的 Mozilla 和 Cloudflare

Firefox Mozilla 在一定程度上依然支持用户自身去做出正确选择，它采取支持 DNS over HTTPS。Mozilla决定让Firefox 默认通过HTTPS 向受信任方发出DNS 请求，而不是寄希望于任何值得信赖的网络。为此，Mozilla 决定与Cloudflare 合作。

全面使用Cloudflare 提供的DNS over HTTPS 存在很明显的问题。Mozilla 的计划中，DNS 查询是来自于世界各地的，当前这些查询是通过许多独立的DNS 服务器进行分发的，所有这些查询都被路由到一个统一的服务提供者，部署在某个隐私法律薄弱且具有臭名昭著大规模监视系统的国家。Cloudflare 可以向大家保证，他们不并会记录所处理的每个DNS 查询的源IP 地址和请求的域名。但最终无法证明自己做到了这一点，因为他们仍在接收这些信息。

毫无疑问，处于另一端的反隐私网络管理员则对这一计划保持警惕。该计划将Cloudflare 作为唯一重要的DNS over HTTPS 服务器，无疑会使人对整个DNS over HTTPS 产生怀疑。通过一并提供DNS over TLS 的选项，可以轻松解决这一问题，尽管二者的技术路线迥异。

这里需要特别注意的是，没有其它开放DNS over HTTPS 服务器的理由是完全站不住脚的。DNS over HTTPS 的一个优点就是，由于HTTPS 是基于TLS 的， 所以不容易遭受DNS 放大攻击（ Amplification Attack ）。

事实上，运行一个 DNS over HTTPS 服务器非常简单，我自己就运行一个 DNS over HTTPS 服务器有一年多时间。你可以自己运行一个标准的 DNS 服务器软件，然后再运行一个简单的程序，将基于 HTTPS 请求的开放 DNS 请求转换为该服务器的内部 DNS 请求。

除没有人愿意运行这样的服务器外，没有其它理由可以解释为什么没有其它的开放 DNS over HTTPS 服务器。我不知道为什么 Riseup 、 Disroot 、 weho.st 等自动托管服务提供商也不运行 DNS over HTTPS 服务器。但是我怀疑，目前存在的各种争论令人对 DNS over HTTPS 敬而远之。也许本文的澄清对解决这一问题有所裨益。

是通过应用还是操作系统实现？

在 Firefox 的 DNS over HTTPS 实现中，另一个值得关注的问题是，在传统上一直是操作系统完成 DNS 的解析。Firefox 开发人员可能认为他们别无选择，大家普遍认为短期内并不会让 操作系统层面普遍提供 DNS over HTTPS。

毫无疑问，寄希望于操作系统提供 DNS over HTTPS 并非易事。在过去一年中，我一直在使用 DNS over HTTPS 作为系统 DNS 解析器，并且工作很好。同样重要的是要意识到，如果用户在通常情况下不愿意按网络管理员的偏好将 DNS 查询发送到某个服务器，那么 Web 浏览器在一些情况下无论如何都必须具备自己处理 DNS 的能力。这样用户才能浏览 captive portals 这类常常无法用自定义 DNS 解析的网站。

关心应用层面 DNS 的人也会指出，用户必须信任每个应用 ，确保它们都不会使用恶意 DNS 服务器。但是我认为这没有实际意义。如果你在这方面不信任某个应用，那么你也没有理由去信任应用执行的其它任何操作。我无法理解用户为什么会在 " DNS 正确是至关重要的 " 环境中运行这样的软件。

总而言之，我认为 DNS 解析在哪个层面实现并不重要。操作系统可以去处理 DNS，以减少应用间的重复工作，这是一个很好的选择。但是我们也应该认识到，操作系统无法采取措施以确保用户安全。并且对于自由软件而言，尤其是当用户担忧安全性和隐私问题时，这时更应关注软件本身的问题。为让用户放心使用，需修改那些信任操作系统层面 DNS 的软件发行版。

我的建议

虽然降低中心化通过选择信任 IP 地址和请求域名避免了隐私上的问题，但更好的做法是将不信任任何人作为第一原则 。一种广泛使用的解决方案是 Tor 。它能够与服务器进行交互，而又不会使任何交互可追溯到用户本身。Tor 甚至可以进一步避免用户连接到潜在的恶意网络，并且很难受他人干扰。Tor 连接的 DNS 服务器支持我们发出 DNS 请求，不必担心被识别。此外，如果我们使用 Tor 隐藏服务，而不是通过出口节点连接回明网，那么连接是端到端加密的，也就无需额外的 TLS 层。由于 Tor 仅适用于 TCP，而不适用于 UDP，因此我们必须在发送 DNS 请求给 Tor 之前，将 DNS 封装在 TCP 中。由此，我提出了 DNS over TCP over Tor（DTT）。

DTT 的确需创建对本地 Tor 守护程序的依赖关系，但是我认为这在 DNS 安全主要关注的操作系统和浏览器这两个场景中是合理的。这两个系统都足够大，因此添加 Tor 守护程序并不会造成很大的负担，并可能会带来其他好处，并更易于使用 Tor 轻松实现其它目的。实际上，Mozilla 已经着手实现将Tor 集成到Firefox 中的想法。DNS 流量足够低，以至于Tor 网络能够处理DTT 的大量请求，并且在Cloudflare 的落地应用已经表明在考虑Tor 开销的情况下仍会具有合理的性能，尤其是在DNS 服务器的IP 本身不需要保密的情况下（注：我并不想在此提供相应文章链接，因为该文中推荐使用非免费软件实现DTT，我尽量避免做商业推荐 ）。由操作系统和浏览器供应商集成Tor，也将为Tor 社区带来巨大的好处，因为运行中的Tor 守护程序会消除用户根深蒂固的一些顾虑。

随着隐私问题的解决，即使DNS 最终还是中心化的 ，用户也无需过于担心。这样的中心化服务的优点会越来越少，而且在其消亡后也易于替换。人们同样很容易运行其它各种规模的DNS 实例。软件供应商可以选择各种缺省方案，也能随机从列表中选择。即使他们没有这样做，并且服务也都是来自单一提供商的，其影响也不会很大 。

具有讽刺意味的是，我所知道的唯一提供Tor 隐藏DNS over TCP 服务，正是Cloudflare 运营的。但正如我所解释的，这并不重要。我正在考虑 Spectrum （一个我正在构建的、以安全性为重点的操作系统）默认使用Cloudflare DTT 的可能性。如果最终成型，我当然也愿意缺省使用其他可靠的开放DTT 服务器。但是我也不会对如此单独使用Cloudflare 感到不适。

当然，重要的是要记住，这都不是DNS 安全和隐私一劳永逸的解决方案。值得注意的是，我们不能保证DNS 服务器的响应是合法的。这应该是通过使用 DNSSEC 和 TLS 解决的。

但如果其它软件使用类似方法解决 DNS 查询，我们会认为因特网将更加安全。此外，也会使得 Tor 更加健壮地发展。

英文原文：

Beyond DNS over HTTPS: Trustless DNS Privacy