在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

创作场景

超越 DoH（DNS over HTTPS）：看 DNS 隐私不可信任的问题