DNS Over HTTPS 的优缺点

DNS，也称为域名系统，是一种将完全限定主机名 (FQDN) 转换为 IP 地址的 Internet 服务。之所以开发它，是因为域名比 IP 地址更容易记住。

2017 年，P. Hofmann（来自 ICANN）和 P. McManus（来自 Mozilla）向 IETF 提交了一份通过 HTTPS 发送 DNS 请求的互联网草案。这是朝着更安全的互联网迈出的积极一步，还是只会带来更多问题？

DNS Over HTTPS 的优缺点

在本文中，我们深入探讨了这个主题，解释了我们对通过 HTTPS 运行 DNS 的优缺点的看法。

什么是 DNS 及其工作原理？
首先，让我们回顾一下 DNS 的工作原理。当您访问 https://www.netsparker.com时，会发生以下情况：

您的浏览器向您计算机上配置的递归域名服务器 (DNS) 发送请求。我们将此 DNS 服务器称为 8.8.8.8。
由于 8.8.8.8 不知道 www.netsparker.com的 IP 地址，因此它查询互联网根服务器，该根服务器将 8.8.8.8 引用到负责 .com 顶级域 (TLD) 的名称服务器。
接下来，8.8.8.8 向 .com TLD 名称服务器询问 netsparker.com 域的名称服务器。
然后，8.8.8.8 向 netsparker.com 名称服务器询问 FQDN  www.netsparker.com的 IP 地址。服务器收到响应后，会将其转发到 Web 浏览器。
Web 浏览器连接到此 IP 地址并请求网站 www.netsparker.com。
DNS 落后了多远？
早在 1983 年，当 DNS 刚刚发明时，DNS 请求和响应都是以明文形式通过 Internet 发送的，现在仍然如此。现在，由于互联网上存在如此多的风险，因此还需要加密 DNS 流量。

然而，与现代网络的许多其他基本构建块一样，DNS 还没有准备好接受炒作！

与 HTTP 和 FTP 等其他协议不同，DNS 从未进行过安全升级以促使其广泛采用。相反，现代互联网最重要的功能之一在过去 35 年里一直使用相同级别的加密——根本没有！

最新的 DZone 参考卡

云原生应用安全

引入基于 HTTPS 的 DNS
2017 年，经过多年未加密的 DNS 请求，第一个针对 HTTPS 上的 DNS (DoH) 的 IETF 互联网草案 (ID) 发布了。它是官方 RFC 文档的前身，您可以查看初始草案的第 13 次修订版（基于 HTTPS 的 DNS 查询 (DoH)），尽管其 RFC 尚未最终确定。它并不是唯一旨在向DNS 协议（还有 DNS over TLS 和 DNSCrypt），但 Mozilla 和 Google 等公司选择将其集成到其产品中。

让我们看一下它是如何工作的，以及为什么它可能不能解决 所有 DNS 隐私问题。

HTTPS 上的 DNS – 技术基础
首先，让我们看一下最新的互联网草案中描述的以及在实际应用中实现的技术方面。

客户端通过加密的 HTTP 请求发送 DNS 查询——考虑到协议的名称，这并不令人震惊。有两种可能的方式发送数据——通过 GET 或 POST 请求。每个都有自己的特点和优势。

GET 和 POST 请求
如果您通过 POST 请求发送数据：

Content  -Type 头字段指示媒体类型：
ID 描述了一种媒体类型 ( application/dns-message )，但我们将讨论的主要 DoH 提供商使用另一种更适合 Web 应用程序的媒体类型 ( application/dns-json )。
DNS 查询在消息正文中发送：
这样做的另一个优点是您不需要对消息进行编码
消息大小小于使用 GET请求发送的消息大小：
如上所述，这与编码有关
如果您通过GET请求发送数据  ：

它比 POST 请求大：
您需要使用的编码是base64url，这意味着编码后的消息比原始消息大约大三分之一
它是 HTTP 缓存友好的：
 即使在较旧的缓存服务器中也能很好地支持缓存 GET请求
DNS 查询在GET 参数中发送 
这并不奇怪，因为 ID 提到“dns”作为 GET 参数名称
然而，尽管 GET请求比POST请求 更适合缓存  ，但仍然存在一个问题。通常，DNS 数据包具有 ID 字段，用于关联请求和响应数据包。它是一个唯一的随机标识符，对于本质上相同的请求会产生不同的请求 URL。因此，客户端应将此 ID 字段设置为“0”。

这表明，将 DNS 从明文 UDP/TCP 移植到加密的 HTTPS 需要进行一些调整，至少如果您想充分利用 HTTP 的潜力（这是明智的，因为与简单的、未加密的 DNS 有线协议相比，HTTPS 会带来相当多的开销） ）。

当今的 Web 是否已准备好使用 DNS Over HTTP？
现在您已经了解了有关 DNS over HTTP 的一些重要技术细节，那么 DoH 的基础设施又如何呢？

请记住，该技术仍处于实验状态，并且有许多旧的 DNS 基础设施不支持加密。当大多数名称服务器不加密其 DNS 响应时，您甚至可以部署 DoH 吗？HTTPS 上的 DNS 有意义吗？您是否不需要更改浏览器或操作系统的工作方式才能使用它？

事实证明，即使最新的夜间版 Firefox 添加了对 HTTPS 上的 DNS 的支持，但实际上并不需要更新所有内容。这是最新的前沿版本，可能包含最新稳定版本中尚未提供的功能。谷歌的 Android Pie 将具有内置的 DoH 功能。

不过，有一种方法可以在不更新操作系统或浏览器的情况下使用 DoH。显然，您应该保持浏览器和操作系统更新，但让我告诉您为什么大多数拥有 Android 手机的人需要很长时间才能使用 DoH（尽管 Google 在 Android Pie 中添加了它）。

为什么您在 Android 手机上很长一段时间看不到本机 DoH
从痛苦的个人经历来看，我可以解释一下。前段时间，我买了一部新的三星智能手机。随后谷歌发布了新的Android版本。此次更新包括一个很酷的用户界面大修和一些新功能。

然后，我等待着。然而月复一月，我的屏幕告诉我，“你的手机是最新的”。这种恼人的延迟是由于三星在自己的手机上大量定制了 Android。当时，他们的 Android 版本称为 TouchWiz，里面充满了臃肿的软件。在接到投诉后，他们慢慢地删除了大部分烦人的功能和软件，以至于人们再也认不出它是 TouchWiz，他们不得不重新命名它。（这不是我编造的。）尽管现在他们需要调整以适应新的 Android 版本的三星特定功能减少了一些，但获得新的更新仍然需要很长时间。

我的一个朋友有一台来自同一制造商的旧版 Android 设备，并且 始终 安装最新的 Android 版本。那是因为他在手机上闪现了新的 CyanogenMod 操作系统。它是没有 TouchWiz UI 的第三方软件，但它是可用的最新 Android 版本。抛开其他问题不谈，讽刺的是，在 Android 发布几天或几周后，你可以通过刷新第三方软件来获得一部打完补丁、最新的手机，但你需要等待几个月才能让你的手机制造商完成这些工作。相同的。显然，这样做会使您的保修失效，并且普通用户甚至不会意识到这种事情是可能的。因此，尽管 Android 9 将支持 DoH，但您可能需要数月甚至数年才能使用它。

即使您的操作系统或浏览器不支持 DoH，是否还有其他方法可以使用它？
有几种选择：

您可以在本地网络的名称服务器上安装 DoH 代理，这意味着您的设备仍将传统的、未加密的 DNS 数据包发送到本地名称服务器。但是，该服务器将通过 Internet 上的 HTTPS 服务器查询 DNS 以便解决您的查询，这使您无需修改​​系统即可使用 DoH。尽管如此，它在您的本地网络中并未加密。
也可以在本地系统上安装 DoH 代理，尽管我不确定 Android 手机是否可以。使用此技术，代理将在与浏览器相同的计算机上运行，​​而不是依赖于本地网络中的第二台计算机。因此，即使您的本地网络中有攻击者，他也无法读取您的 DNS 请求，因为它们一旦离开您的计算机就已经加密。
DNS Over HTTP 是否可以增强安全性和隐私性？
这有待辩论。卫生部有一些问题值得一提。首先，由于 DNS 的工作方式，几乎不可能在不让中间服务器知道的情况下从浏览器到 example.com 的名称服务器建立端到端加密连接。

让我们回顾一下前面示例中的递归名称服务器如何解析 www.example.com 的 IP：

它询问互联网根服务器之一：
问题：“我想访问 www.example.com，你知道它在哪里吗？”
回答：“不，但这里是 .com 的域名服务器。在那里试试你的运气！”
然后它询问 .com 名称服务器：
问题：“那么，您能告诉我 www.example.com 的 IP 地址吗？”
回答：“您应该询问 example.com 名称服务器。”
最后，它询问 example.com 名称服务器：
问题：“www.example.com 的 IP 是多少？”
答案：“IP是123.123.123.123”
在每个查询中，完整的主机名都会发送到 DNS 服务器。现在，所有这些服务器都知道您想要访问 www.example.com，尽管此信息仅对 example.com 的名称服务器真正感兴趣——在隐私方面显然不太理想。

DNS 查询名称最小化
上述问题有一个解决方案，但它甚至不是卫生部特有的解决方案。这称为 DNS 查询名称最小化 ，这就是它的工作原理。

如果您想访问 example.com，您的递归名称服务器和其他名称服务器之间的对话将如下所示：

它会询问互联网根服务器：
问题：“您知道 .com 的域名服务器吗？”
回答：“是的，这是他们的 IP 地址”
接下来，它会询问 .com 域名服务器：
问题：“您知道 example.com 的名称服务器吗？”
回答：“是的，这是 example.com 名称服务器的 IP 地址”
最后，它会询问 example.com 名称服务器：
问题：“你知道www.example.com的 IP 吗 ？”
回答：“是的，是123.123.123.123”
唯一知道完整主机名的名称服务器是 example.com，因为它也是唯一需要知道该主机名的服务器。所有其他服务器只知道查询的一部分。这并不能帮助您保持完全匿名，但它确实减少了您泄露的数据量。这是 Firefox DoH 实现及其可信递归解析器 (TRR) 技术的一部分。

存在一些信任问题
卫生部的第二个问题是威胁模型。威胁建模涉及识别潜在漏洞并提出对策建议。这意味着忽视低级风险。尽管它们是信息安全的重要组成部分，但我通常不喜欢它们，至少对于普通用户来说是这样。当然，如果您只使用计算机玩蜘蛛纸牌，那么将您的电脑设置气隙并将其放置在两层防弹玻璃和电动鳄鱼坑后面有点过分了。但是，如果您需要决定是否应该为主页启用 HTTPS，您实际上不需要花费数小时思考您的威胁模型。Let's Encrypt 的设置时间不到 15 分钟，因此只需设置即可。

不幸的是，TRR 是一个完全不同的野兽。我不知道 Mozilla 做出这一决定的理由，但我认为，由于它需要大量带宽，而且 Mozilla 可能希望在未来版本的 Firefox 中默认启用 TRR，因此他们希望构建既可靠又可靠的基础设施并免受 DDoS 攻击。如果您考虑可靠性和 DDoS 防护，您会立即想到 Cloudflare。Mozilla 与他们合作并使用他们的 1.1.1.1 服务器来实现 DoH。