TLS上的DNS与HTTPS上的DNS

随着DNS加密需求的发展，TLS上的DNS(DOT)和HTTPS上的DNS(DoH)之间的争论似乎越来越激烈。随着Google(和Firefox)采用DoH作为他们浏览器的DNS加密方法，似乎有一种信念认为DoH优于DOT。

事实是，HTTPS上的DNS和TLS上的DNS是实现相同DNS保护的略有不同的标准。

欺骗-伪造的DNS请求，这些请求通常以中间人攻击的形式出现，恶意行为者会将用户临时重定向到虚假登录页面，以收集个人信息或登录凭据。

跟踪-当不值得信任的实体可以查看您的DNS请求并收集有关您的信息时，可以将此数据出售给广告商*。

为了进一步简化这一点，DNS加密的最终目标是防止DNS请求被读取和修改。

*隐私政策不仅仅是您需要勾选的框。他们确切地告诉你一家公司将如何使用你的数据。没有隐私政策是一个警告信号。我们在DNSFilter非常重视隐私，您可以查看我们的隐私政策和我们遵循的安全最佳实践，以确保我们客户的安全。

点和DoH之间的主要区别在于启用加密的层。HTTPS上的DNS应用于应用层(与Internet层相隔两层)，而DNS-Over-TLS应用于传输层(与Internet层相隔一层)。

当涉及到实现DOT或DoH时，这实际上取决于您要加密的确切内容和位置。

因为Google和Firefox都是浏览器，他们已经在使用HTTPS了，所以在HTTPS上实现DNS对他们来说是最有意义的。火狐和谷歌没有使用基于HTTPS的DNS，因为它优于DOT。之所以使用它，是因为默认情况下浏览器在HTTPS层操作，因此通过TLS进行DNS-over-TLS对于浏览器实现来说没有意义(就目前而言)。

谷歌不能在他们的浏览器中使用DNS-over-TLS，因为他们不能修改Windows或MacOS操作系统(目前只支持Dot)上的代码，以便加密在浏览器之外完成的DNS请求。这对谷歌和火狐都有效，因为它们只需要在浏览器内部加密DNS请求。

同时，在DNSFilter中，我们不仅需要在浏览器中操作DNS加密，而且还需要在操作系统级别操作DNS加密。这就是我们使用DNS-over-TLS的原因：因为它可以在较低层启用，并保护浏览器外部的DNS请求(例如，松弛消息、嵌入Excel中的链接或各种桌面应用程序)。目前，DOT是在操作系统级别启用标准化DNS加密的主要方式。

请注意，新版本的IOS、MacOS和Windows在操作系统级别启用了DoH。因为Android是Google产品，而Google Chrome使用DoH，所以Android设备已经在操作系统级别使用DoH了。

每个人都在想Doh，因为它是Google使用的，但它不一定比Dot更好。它只是不同，在某些方面，它实际上不如点。

在很多方面，由于在TCP/IP模型的哪一层中启用了DOT，因此DOT的效率更高。请记住，DoH是从互联网层移除的两层，而DOT只移除了一层。

以下是DNSFilter选择点而不是DoH的几个原因。基本上，我们需要通过另一层发送更多数据。尽管应该注意，点和DoH都会增加延迟，但点的延迟较低，因为它启用的位置不同。

但对我们和我们的用户来说，选择Dot的最重要原因是能够在尽可能低的层启用DNS加密，因为我们的用户不仅仅通过他们的浏览器发送DNS请求。这就是我们使用点的原因。

但这并不意味着我们认为点是唯一的答案。我们正计划为需要它的客户实施DoH。

例如，Chromebook等Android设备使用DoH。这是因为Android设备是由谷歌创造的。虽然Windows和MacOS目前不支持DoH，但Google能够修改他们的Android设备，使DoH成为可能。

然而，仅仅因为微软在其操作系统上支持DoH并不意味着更高的延迟或额外的编码需求消失了。无论如何，DoH仍然是在比DOT更高的层上实现的。唯一的变化是现在可以在操作系统级别实现DoH。

DOH支持的增加很可能不是因为微软给他们的用户提供更多的选择，更多的是关于他们跟随谷歌的领导。

DOH和DOT不是唯一可用的加密协议，尽管在这一点上它们更健壮，也是使用最广泛的。但在加密标准出现之前，也有DNSSEC。

DNSSEC是早期的DNS标准，不为您的DNS请求提供加密或隐私。它只能防止中间人攻击。如果应用不当，将会破坏您的网站。您可以在这里查看被不正确的DNSSEC实现破坏的网站的提要。

DNSSEC容易频繁停机，而且从未被广泛采用。正因为如此，并且因为它只做DoH和Dot所做的一部分，所以在DNSFilter我们不推荐使用DNSSEC，尽管我们确实支持它。

DNSCcrypt是另一种DNS加密选项，尽管远不如我们现在比较的两种协议流行。与TLS上的DNS一样，它在传输层应用。DNSCcrypt可防止本地化中间人攻击，并加密用户和递归DNS服务器之间的DNS通信，尽管它不提供端到端加密。

但DNSCcrypt与其他标准(如DOT)之间最大的区别是没有像DoH或DOT那样的RFC(请求注释)。这意味着它没有经过同行审查和战斗测试。实现可能有很大的不同，DNSCcrypt的所有定义和规范都来自单一来源。

当涉及DOT或DOH时，没有正确的答案，因为这些标准支持不同的用例。但如果DOH继续像以前那样被采用，我们可能会看到DOT被搁置一边。

话虽如此，这不仅仅是选择DOT或DOH的问题。在DNS加密和SNI(服务器名称指示)加密方面仍有需要完成的工作。

SNI是TLS之上的层，是TLS层的扩展。一旦您发出DNS请求，并且TLS与该IP地址建立了安全连接，SNI就会以明文(未加密)的形式告诉服务器该域的名称。虽然这不会影响中间人攻击之类的事情，但它确实会影响隐私。目前，SNI没有加密，尽管它是正在研究的东西。

虽然DOT和DoH是加密DNS的最安全、最标准化的方法，但它们不会加密发往权威DNS的请求。该请求以明文形式接收。这是DOT和DoH以及DNSCcrypt中的漏洞。目前还没有加密这些信息的标准。

作为DNS解析器，我们支持并欢迎将消息加密到权威DNS的标准，我们愿意与提供商合作，帮助实施这一标准。

但我想在这里指出的是，目前DOT和DOH都不是完美的DNS加密解决方案。还需要做更多的工作，比如为所有DNS-over-TLS和DNS-over-HTTPS实现启用0-RTT。

虽然每个人都在谈论DoH，但这并不是因为它是最安全或最有效的解决方案。这是因为现在，这是最受关注的解决方案。当VHS超越Betamax时，并不是因为VHS在各方面都更好。Betamax实际上提供了更好的视频质量，但VHS更便宜，允许人们录制更长的节目。VHS和Betamax都实现了相同的目的(录制和显示视频)，类似于Dot和DoH都通过略微不同的方法提供加密。

“DoH与Dot”争论的最大影响之一是MSP实现网络级DNS过滤的方式。随着DoH成为事实上的标准，它使得在系统级DNS设置上执行DoH旁路几乎是不可能的。目前还没有替代解决方法的标准方法。我们将在后面的博客文章中更详细地讨论这个主题，因为在讨论对MSP的影响时有很多需要考虑的问题。

有关DNS-over-TLS以及DNSFilter如何实现它的更多信息，请访问我们的支持文档。