DNS的演进 适应不断变化的互联网格局

早期的互联网体系结构使用名称作为IP地址的便捷别名。每台主机都维护一个由名称和地址对组成的本地列表文件。应用程序从该文件中查找主机名称，并在随后的数据包交换过程中使用相对应的地址。在许多方面，该文件都可以直接类比为电话网络中的电话簿。

这种简单的框架有一个重大的缺点，即可扩展性。随着网络中连接主机数量的增加，分发该文件更新副本的负担也随之增加，而且在所有这些本地名称文件副本间保持宽松一致性的任务也变得更具挑战性。描述互联网名称服务器的IEN61号文件于1978年发布，它似乎是当今DNS最基本的前身。

大约5年后，在1983年，RFC 882使用树形结构名称层次定义了分层名称空间。该文件还将名称服务器定义为一种服务：它拥有关于名称层次结构中某一部分的信息，并可转介到其他名称服务器，后者拥有关于名称层次结构中较低部分的信息。该文件还定义了域名解析器：该解析器能够通过遵循转介信息寻找到要查询的目标名称服务器，然后从服务器获取所需的信息，从而将名称解析为其所存储的属性。RFC 883将DNS查询和响应定义为一个简单的无状态协议。

这就是早期DNS规定的基本内容。仅此而已。

现今DNS的大部分内容都是在这些早期规范中定义的，而我们在这过去的40年间所做的只是填补其中的细节。在此期间，DNS并没有发生任何实质性的变化。

不过，我认为以上观点忽略了DNS世界已经出现的大量改进。

DNS并非完美无缺。DNS的域名解析速度极慢，将变更引入分布式数据框架的速度更慢。DNS查询的解析完全未考虑到用户隐私。任何一方只要能观测到用户的DNS查询数据包，便能轻易拼凑出用户活动的准确信息。用于解析名称的分布式无状态方案很容易受到各种企图窃听DNS解析事务和操纵DNS响应信息的影响。DNS不易抵御破坏性攻击，经常被用于开展高效的拒绝服务攻击（DoS）。由于客户端无法验证响应的真实性和时效性，它也并不安全。

DNS解析名称的操作可能极其不透明。使用并行服务器和解析器来提高DNS的恢复能力，会导致用于探索分布式数据结构的路径数量的组合“爆炸”。我们不可能事先知道哪些服务器可能被用于查询解析，也不可能知道一个原始查询可能会触发多少个附加查询。由于解析器可以直接从本地缓存对查询做出响应，因此无法预先知道响应来自何处或响应是否真实。

对于一项每个用户不仅会使用，而且会暗中依赖的常见基本服务来说，DNS在实践中远非一个可靠运行工程的典范。

技术社区已经在积极发展和改进DNS，旨在弥补其中的一些不足，包括加快DNS解析速度、改善DNS解析的隐私性、提升DNS响应的可信度以及抵御破坏DNS名称解析完整性的行为。

DNS并不是所谓的一个独立的协议。默认情况下，查询是明确的。查询者的IP地址、被查询的服务器和被查询的名称对任何有能力检查DNS流量的实体都是可见的。这不仅包括网络中潜在的窃听者，还包括发起DNS查询的应用程序所在的操作系统平台、接收查询的递归解析器以及递归解析器所使用的任何转发代理。根据本地缓存的状态，递归解析器可能需要在名称服务器层次结构中执行一定程度自上而下的探索，向每一级的权威服务器询问完整的原始查询名称。递归解析器通常会将自己列为这些查询的来源，因此原始用户的身份会被隐去，但查询名称仍然可见。

RFC 7858提供了通过传输层安全（Transport Layer Security，TLS）会话进行DNS的规范，简称为DoT。DoT允许客户端和服务器以安全的方式设置共享会话密钥，然后用于加密双方之间的所有后续交互。TLS还可用于验证服务器名称，以确保客户端连接到的是指定服务器的实例。设置TLS会话需要一定的开销，而这种方法最有效的应用是在存根（Stub）解析器到递归（Recursive）解析器的环境中。在这种环境中，单个TLS会话可以保持开放并在后续查询中被重复使用，从而在这些查询中分摊初始设置的开销。DoT标准规范定义其标准端口为TCP端口853，它允许旁观者识别DoT的使用，并通过IP地址识别终端双方，但不包括DNS查询和响应。

随后的标准工作定义了基于QUIC（快速UDP互联网连接）协议的DNS，即RFC 9250（DoQ）。QUIC提供的加密功能与TLS提供的功能类似，而QUIC传输解决了TCP固有的链路阻塞问题，并提供比UDP（用户数据报协议）更高效的丢包恢复机制。

此外，DNS消息还可以通过HTTP（超文本传输协议）传输，即RFC 8484（DoH）。DoH使用端口443作为服务接收端口，在HTTP/2下使用TCP，而在基于QUIC的HTTP/3下使用UDP，因此DNS流量在很大程度上与Web流量没有区别。HTTP在传统DNS模型的基础上，增加了对象缓存、重定向、代理、身份验证和压缩的功能，但在DNS环境下如何使用上述功能尚不清楚。HTTP还允许服务器向客户端推送内容。在DoH方案中，可以允许使用无查询DNS，即服务器向客户端推送DNS响应，而无需触发任何初始DNS查询。

在这些DNS加密传输方法中，远程服务器会知道客户端的IP地址和客户端正在进行的查询。在存根到递归（stub-to-recursive）方案中，即使双方之间的网络路径是安全的，递归解析器也能知道用户的DNS操作。使用基于HTTPS的遗忘式DNS（Oblivious DNS，RFC 9230），可以获得更高的隐私级别。在这种情况下，没有一个DNS服务器能够同时知道客户端的IP地址和DNS查询的内容。在这里，双重加密与网络内的两个独立代理结合使用。客户端使用DoH向第一个代理发送加密DNS查询。该代理知道客户的IP身份，但无法解密DNS查询。该代理使用DoH向第二个代理发出自身的查询，隐去客户端的IP地址。第二个代理可以解密查询，并使用传统递归解析器的模式进行解析。

这四项技术规范表明，DNS交互有可能披上一层安全的神秘“面纱”，但这些技术的普及程度仍是一个值得猜测的话题。加密传输会话给DNS基础设施（递归解析器和权威服务器）的运行带来了更高的成本，目前尚不清楚如何将这些更高的成本纳入当前的DNS经济模式。因为在当前的模式下，客户端基本上无需为单个DNS查询产生任何花销。

DNS查询名称最小化（RFC 7816）则描述了一种完全不同的改善DNS隐私的方法。传统的DNS解析模式规定，递归解析器在DNS层次结构中自上而下交互时，会使用原始查询名称来询问权威名称服务器，从而将查询名称共享给一组服务器。而这种方法的基本原理是，客户端不一定事先知道在哪里可能存在区域切割（Zone Cut）。查询名称最小化建议通过向距离原始查询名称最近的、已知的祖先权威名称服务器发送请求，并要求提供委托记录（NS）而不是原始查询类型，从而最大限度地减少向权威名称服务器披露的名称信息量。这种方法不会增加DNS服务器基础设施的开销。它不提供通道安全，但限制了DNS名称解析过程中的信息“泄漏”量。

从更广泛的层面来看，这些DNS隐私保护措施都无法保证用户收到的DNS响应的真实性。这些措施限制了第三方窃听DNS查询和响应的能力，但检测（并可能拒绝）不真实的DNS响应是DNS的另一个问题。

DNSSEC（域名系统安全扩展）是对DNS的扩展，由RFC 4033规定，它将每条记录与加密生成的数字签名关联起来并存于DNSSEC签名区域。DNSSEC不改变DNS名称空间，也不改变DNS名称解析协议。支持DNSSEC的客户端可以要求DNS响应包含DNSSEC签名（如果该区域有DNSSEC签名），然后可以使用该签名验证响应的真实性。

你可能会认为，允许客户端验证DNS响应的工具会立即流行起来。如果应用程序和服务使用的名称与协议层使用的IP地址之间的关系被破坏，那么用户就很容易被欺骗。然而，在最初的规范制定近30年后，DNSSEC仍难以获得主流采用。问题的部分原因在于DNS协议与UDP传输的强绑定，当附加签名和密钥导致响应大小膨胀时，就会产生一系列问题。有一些问题在于，管理加密密钥需要小心谨慎，以及加密验证的不可控性。还有很大一部分原因是，当网络开始使用TLS作为验证远程服务器身份的方法时，人们认为，DNSSEC在创建DNS会话时所带来的任何增量效益，与使用DNSSEC所花费的大量精力和成本相比，都显得不足为道。

由于这些原因，DNSSEC在DNS领域内仍是一项“正在进行的工作”。

DNS基本规范使用一种有限的数据格式，其中查询包含查询名称和查询类型，而DNS响应（如果通过UDP传输）的长度被限制为512字节。DNS基本规范中对若干标志字段、返回代码和标签类型的大小限制，阻碍了DNSSEC的发展。解决这一问题的方法是使用所谓的伪资源记录（OPT记录），该记录包含在DNS消息的附加数据区域。为确保向后兼容性，应答者不应使用OPT记录，除非它出现在查询中。这就是DNS的一般扩展机制（EDNS）。

迄今为止，EDNS选项已用于支持DNSSEC功能、填充、TCP保持设置和客户端子网字段。它还通过使用EDNS缓冲区来扩展基于UDP的DNS消息的最大容量。

通常需要将服务名称与提供服务的服务平台位置分开，而服务记录类型就是为了实现这一目的。服务记录（SRV记录）可以提供这种形式的灵活性。服务由主机名、端口标识符和协议标识符定义，相关的资源记录用以提供TCP或UDP端口号和目标服务平台的规范服务名称。SRV记录可以指定多个服务目标，并提供相关的使用偏好。使用SRV记录的功能转变是在DNS查询中加载服务配置文件，而不是简单的域名。相对应地，用户接收到足够的信息，能够直接连接到所需的服务，而无需执行进一步的DNS查询。

SVCB记录规范（RFC 9460）对此进行了进一步扩展。通过在客户端尝试建立连接之前向其提供更多信息，这些记录为性能和隐私提供了潜在的好处。这代表了DNS设计方法的转变，以前使用DNS资源记录类型是为了分割与DNS名称相关的信息，以便通过一系列查询获得有关服务名称的完整信息集合。SVCB记录高效地为服务查询提供了一个“总括式”响应，这样客户端只需进行一次DNS查询便可连接到服务，获取足够的信息。

授权（NS）记录是DNS数据结构的基本组成部分之一，它将DNS层次结构中整个子树的控制权从一个节点传递到另一个节点。

虽然NS记录自DNS诞生以来就一直为其服务，但它也有一些局限性。授权记录的目标是一个或多个DNS服务器名称，而不是它们的IP地址。在传统模式下，IP地址是作为“胶水记录”（Glue Records）提供的，被包含在DNS转介响应的附加区域中。但这种胶水记录的真实性无法确定，多年来一直是许多DNS攻击的焦点。NS记录的目标不能是CNAME别名。NS记录由父区域和子区域共享，子区域则被视为该记录的权威。这意味着，虽然父区域名称服务器可以（也必须）使用此NS记录作出转介响应，但不能为其提供DNSSEC签名，无法在转介响应中提供DNS服务配置文件。如果可以使用加密传输协议访问区域的权威服务器，NS记录则不能提供这种能力。

IETF的授权工作组（Deleg Working Group）正在开展工作，研究如何将现有的DNS服务器的服务绑定映射规范（RFC 9461）用作更灵活的授权记录，以解决现有NS授权形式中存在的部分或全部缺陷。

互联网协议套件可被视为一系列元素的集合，包括寻址、路由、转发和命名，用不同的技术替代某一元素并不一定会对其他元素产生影响。例如，在寻址领域，从IPv4过渡到其它IP版本并不要求对路由、转发或命名进行任何根本性的改变。DNS名称系统也是如此。替代名称系统可以使用，而且在某种程度上可以与DNS共存。

在传统的DNS解析模式中，用户几乎无法控制自己的DNS设置。一些懂技术的用户可能会选择与默认设置不同的设置，但这样做的动力不大，绝大多数用户的DNS设置都是由管理员通过DHCP（动态主机配置协议）等协议配置的。

目前使用的许多替代名称系统都与使用它们的特定应用程序捆绑在一起：特定的替代名称系统通常与相应的应用程序绑定，而该应用程序通常会绕过管理员控制的设置和任何预先配置的DNS设置。例如，Tor项目使用自己的名称系统，绕过了传统的DNS解析。用户可以安装Tor浏览器，它将对以.ONION结尾的名称使用Tor名称系统，而将其他任何名称转发给本地DNS解析库。应用程序开发人员可以选择使用哪种名称系统，而用户甚至不知道他们正在使用另一种名称系统，也不了解潜在的影响。

各种形式的试验都采用了去中心化模式，这种模式摒弃了单一名称层次结构，允许单个名称存在于非结构化的扁平名称空间中。将名称与“所有者”关联起来的底层注册框架通常依赖于某种类似于区块链的方法，将名称与公钥值的关联存入区块链中。目前存在许多这样的替代名称系统，包括以太坊名称服务的ENS（在其区块链中使用所谓的“智能合约”）和Unstoppable Domains（使用区块链平台，但将名称空间作为一个集中运营的空间）。GNU名称系统（GNS）也是一个提供名称持久性的去中心化平台。GNS没有根区的概念。相反，GNS使用“起始区域”（Start Zone）的概念，由本地配置并决定从哪里开始解析。由于本地用户可以完全控制自己的起始区域，因此每个GNS用户都可能使用不同的名称空间。因此，GNS无法保证名称的全局唯一性，也无法保证特定名称对不同用户的解析结果相同。GNS唯一能保证的是，具有相同起始区域的用户将拥有相同的名称空间视图。每个唯一的起始区域都定义了自己的名称空间。这实际上与使用不同根区的DNS解析类似。GNS的主要创新之处在于用分布式哈希表取代了搜索层次结构，而分布式哈希表可以包含与其他哈希表的链接。

这些替代名称系统与现有的DNS名称空间的交互方式多种多样。有些系统试图与DNS共存，其替代名称是DNS名称空间某种形式的扩展，可能与不同的名称解析协议相关联。而其他系统则完全独立，不与DNS共存。这种情况多见于特定应用环境，即应用环境只与替代名称空间相关联。

只有完全奄奄一息的技术才能不受变化的影响！随着数字技术和服务的发展，对相关名称空间的要求也在以新型和不可预测的方式发生变化。

DNS是一个有趣的例子，因为到目前为止，它能够在不需要对其名称空间的结构、分布式信息模型或名称解析协议进行根本性修改的情况下，对不断发展的互联网做出反应。迄今为止，DNS中的大多数演变都是以保持向后兼容性的方式进行的，而且在很大程度上保持了基本名称空间的内聚性。

然而，展望未来，在整个互联网上保持这种内聚性并不是必然结果。国家和地区层面对内容访问设置限制的压力，往往表现为对内容服务名称的解析设置选择性阻碍，而DNS却要承担支持互联网中这种选择性碎片化的担子。EDNS客户端子网扩展可能被用来实施这一点，其中对查询的响应可能不仅依赖于查询的名称，还依赖于查询者是谁。很可能这种更精确且更碎片化的名称空间模型将持续存在，并导致一个日益碎片化的互联网。

来源：APNIC

作者：Geoff Huston

翻译：李想（南开大学）

责编：项阳