DNS指向哪里？

在最近的注册操作研讨会上，我参加了一个主题为DNS隐私和加密的小组讨论。

我发现自己问的问题是：“DNS隐私与注册操作有什么关系？”注册功能是与某种形式的排他性控制所有权相关的公开证明过程的一部分。但是名称注册条目与该名称的解析方式几乎没有关系(如果有的话)。如果客户端使用普通DNS、TLS上的DNS、HTTPS上的DNS、QuIC上的DNS或其他任何东西上的DNS来将查询传递到递归解析器，至少应该没有关系。同样，递归解析器的注册表操作员使用加密隧道来查询权威服务器，这至少应该无关紧要。同样，对于注册表操作员来说，客户端是否使用查询名称最小化应该无关紧要。在注册表操作员可能或应该关心的所有事情中，在DNS隐私和加密中几乎找不到涉及其操作的东西。为什么这个话题会出现在注册运营研讨会的议程上？

但也许这有点过于简单化了。也许在今天的网络中，DNS解析的使用方式中有一些元素指向可能会影响名称注册功能和整个互联网名称空间的一致性的进一步变化。让我们看看我们是否可以建立一个可信的案例，即隐私和加密有可能促进DNS命名空间的碎片化。

首先，让我们退一步看一下“传统的”DNS名称解析(图1)。

在此模型中，DNS是Internet公共基础设施的一部分。应用程序不一定知道名称解析的性质。应用程序通过诸如gethostbyname的库调用来调用主机平台操作系统，并且在这一点上，名称解析过程成为该平台上的所有应用程序使用的公共过程。如果名称不在最近解析的名称的本地缓存中，并且名称不是在hosts.txt中本地定义的(是的，许多平台仍然支持这种现在已经过时的名称解析形式)，则它将把查询传递到递归解析器来解析该名称。哪个解析器？在此经典DNS模型中，解析功能作为本地网络服务的一部分执行。当转换到ISP环境中时，名称解析功能由本地ISP执行。

除了触发初始查询来解析名称之外，应用程序在名称解析过程中没有任何角色，并且名称解析过程完全独立于应用程序。同一平台上的任何应用程序都可以请求相同的查询，并且DNS响应大概是相同的。名称是此模型中常见网络基础设施的一部分。

这是一个有趣的问题，问这种模式在今天的互联网中有多普遍。终端客户端是否使用其本地配置的DNS递归解析器？我们可以使用APNIC实验室收集的测量数据来回答这个问题，或者是这个问题的一个微小变体。多大比例的客户端使用与客户端本身位于同一网络中的解析程序来查询权威服务器？这是随着时间的推移而上升还是下降呢？图2显示了可以回答这些问题的数据。

似乎略低于一半的用户使用在其本地网络内运行的解析器，其中解析器直接处理请求，而不将其转发到其他外部解析器。在过去的18个月里，这一数字下降了约5%。本地解析器的本地在周末稍显突出，而平日使用倾向于使用非本地解析器。

结论是，DNS的这种本地基础设施模型正在经历一些变化。是什么在改变？这里的一个主要因素是引入了开放式递归解析器。这类解析器包括Google的8.8.8.8服务、Open DNS、Cloudflare的1.1.1.1服务、Quad9(9.9.9.9)等服务。在该模型中，DNS递归解析R被提供为不同的服务，并且DNS名称解析功能被提升为以类似于任何其他因特网应用服务的方式操作的覆盖服务(图3)。

这种覆盖服务模式在今天的互联网中有多普遍？将其DNS查询传递给打开的DNS解析器的用户比例是多少？

这些问题的答案如图4所示。大约28%的用户通过开放解析器发送DNS查询。这在工作日更为突出，表明企业网络比消费者服务网络更倾向于使用开放式解析器。开放解析器的市场份额并不均匀，因为大约22%的用户使用谷歌的公共DNS服务。这不太可能是个别配置子解析器的结果。更有可能的是在基于网络的解析器中使用转发器功能，将所有客户查询传递到Google的服务上。这可能是由成本、服务可靠性、数据完整性或许多其他潜在原因驱动的选择，但结果是相同的。DNS看起来越来越像一种覆盖服务，而不是通用的基础设施。

现在让我们将隐私和加密引入到这张图片中。DNS当然是一个丰富的活动领域。DNS查询是开放的，很容易被拦截并替换为虚假响应。这种DNS拦截不仅是恶意软件工具集的一部分，而且是许多国家互联网过滤措施的固有组件。可以观察到，很多国家的内容政策都是通过DNS拦截来实施的。这不仅仅是将某些名字从用户活动的权限中删除。DNS是有关用户和应用程序的丰富数据源。如果观察者要在一段时间内整理来自单个用户的完整DNS查询集，那么就有可能构建该单个用户的非常准确的配置文件。在这种数字监视和控制的实践中，DNS似乎是一个自愿的合作者(图5)。

在DNS解析过程的几乎每一步，都有机会将DNS查询链接到原始最终用户，并有机会截取查询并替换为合成答案。

这些天我们谈论的是“知情同意”。用户允许以各种方式收集他们的数据是可以的，但用户的明确同意通常是必要的前提条件，并且这种同意需要被告知这些个人数据将被用于什么目的。这一切都很好，但用户如何防止未经同意收集此类数据呢？在没有用户明确同意的情况下，用户如何阻止第三方进入DNS并收集甚至更改DNS数据？

正是在这里，DNS隐私和加密进入了画面。隐私措施包括限制DNS的“闲聊”级别，并通过查询名称最小化停止向所有权威名称服务器暴露完整的查询名称。但最有效的工具是加密。近年来，互联网已经迈出了重要的一步。我们已经看到了免费域名证书的引入，它已经将会话级安全服务从一种昂贵的、充满异国情调的奢侈品变成了一种无处不在的商品。传输层安全(TLS)的引入改变了Web。现在，几乎每个HTTP会话实际上都是使用TLS的HTTPS会话。(图6)。

如果TLS在网络上工作得这么好，那么为什么不对DNS做同样的事情呢？对从用户设备到递归解析器的路径上的查询进行加密将阻止对DNS的监视和拦截。根本的变化是从数据报UDP协议转变为会话协议，但是存根解析器及其递归解析器之间的关系可以分摊在整个存根查询序列上通过TCP建立TLS会话的开销，因此对于存根解析器来说，这是一种几乎没有直接缺点的措施。递归解析器承受更大的负载以维护会话状态，并且从UDP到TLS上的DNS(或DOT)的转换对解析器有一定的成本影响。然而，如果我们可以让它在Web事务上工作，而且我们做到了，那么似乎没有理由不能在DNS递归解析器上工作。

如图7所示，提高DNS安全性的一种方法是加密本地板载存根解析器和远程递归解析器之间的路径，使用TLS作为DNS查询的包装器。通过使用TLS，可以防止两种非常广泛使用的拦截和监视机制，即当查询在存根和递归解析器之间通过网络时捕获它们。

为什么只停留在TLS？如果我们也添加一层HTML，会怎么样？从某种意义上说，这是一个很小的改变，行为应该是相似的。但从另一个意义上说，这是一个很大的飞跃。如果DNS查询和响应被包装在HTTPS中，那么任何HTTP引擎，即浏览器，都可以独立承担DNS查询并获得响应。为什么浏览器要这样做呢？

首先，它可以防止平台窥视应用程序的活动。DNS事务受到保护，不会被应用程序本身窃听。

其次，可以使用HTML向名称解析添加其他行为。HTML支持推送功能，其中对象由服务器推送到客户端。通过预先向用户提供服务器可能知道客户端可能会询问的名称解析结果，可以以类似的方式处理DNS响应并减少用户等待时间。

第三，可以通过向查询添加HTML属性来保存答案。通过EDNS(0)的道路是漫长而曲折的，到目前为止的结果(即客户端子网)并不完全是最好的结果。事实上恰恰相反。那么，如果DNS查询可以用HTML进行，那么为什么不也用HTML传递关于查询的元数据呢？

现在不只是HTTPS可以这样对待了。Quic可以以类似的方式使用，这导致了一种通用的方法来封闭客户端DNS，使其不被拦截器和窃听者窃听。(图8)。

如果每个应用程序都可以自由地与其自己的DNS名称解析程序通信，那么使用特定于应用程序的名称解析服务是非常简单的一步。通过这种方式，应用程序可以嵌入其自己的特定于应用程序的句柄和标识符的解析。应用程序在DNS中构造查询以将查询传递到特定于应用程序的服务器并不是特别必要的，也没有必要严格限制要委派给DNS名称的查询(我们过去称之为“全局DNS”)。每个应用程序都能够自定义名称空间以满足自己的要求。结果如图9所示，这是一个与原始DNS广告基础设施起点完全不同的场景。

在这一点上，我们已经将DNS作为公共基础设施的概念远远抛在了后面。这些保护事务并将其从打开视图中移除的机制伴随着将名称解析功能移到应用程序直接控制下的转换。一旦向特定于应用程序的服务转变，就不再需要使用通用DNS名称空间。然后，应用程序可以确定它们是否想要使用各种形式的定制来提高应用程序的性能，并用它们自己的聪明想法来增强命名空间。

这组新的基于应用程序的名称空间到底是什么样子？它是仍然具有凝聚力，还是已经全面碎片化？

如果使互联网成为单一网络的特征是单一的地址空间和单一的名称空间，那么很明显，我们已经放弃了连贯和统一的地址计划，因为NAT是如此无处不在。但是，如果一个统一的互联网只剩下一个连贯的名称空间，那么当我们将其拆散时会发生什么呢？

回到最初的问题：“DNS隐私与注册操作有什么关系？”如果注册功能是一种为Internet保留单个包含名称空间的一致性和完整性的功能，那么我们在DNS隐私方面的努力正在将我们引向有可能将所有这些都撕裂的方向！

如果名称空间的这种应用级碎片是DNS的发展方向，那么我不清楚接下来会发生什么！

上述观点不一定代表亚太网络信息中心的观点。

Geoff Huston AM，B.SC，M.SC是APNIC的首席科学家，APNIC是服务于亚太地区的地区互联网注册机构。