PDFDNS 复杂性
尽管 DNS 只包含一些简单的规则，但它已发展成为一个极其复杂的系统。
PAUL VIXIE，互联网系统联盟
DNS（域名系统）是一个分布式的、连贯的、可靠的、自主的、分层的数据库，是同类中的第一个也是唯一一个。DNS 创建于 20 世纪 80 年代，当时互联网还很年轻，但其原始的将主机名转换为 IP 地址的系统已经不堪重负。DNS 是使全球互联网（和万维网）成为可能的基础技术之一。然而，这一切并非一帆风顺，DNS 技术也经历了周期性的更新和改进。尽管仍然可以用简单的术语来描述 DNS，但其底层的细节现在已经非常精妙。本文探讨了 DNS（系统和协议）的假定定义和真实定义，并通过互联网协议开发哲学的视角展示了这两种定义之间的一些张力。
简化视图
DNS 命名空间具有树状结构，其中每个节点都有一个父节点，根节点除外，根节点是其自身的父节点。节点的标签长度为 1 到 63 个字符，根节点的标签为空。域是上下文中的节点，完全限定域名具有表示形式，即从下到上的节点名称，每个名称后跟一个句点 (.)。例如，www.google.com 是一个节点的完全限定名称，该节点的名称是 www，其父节点是 google，其祖父节点是 com，其曾祖父节点是 DNS 根。
节点被分组到区域中，每个区域的顶点被称为授权起始点，底部边缘被称为委托点（如果其下方存在其他区域），或者叶节点（如果下方没有区域）。区域由权威服务器提供服务，权威服务器可以是主要的（如果区域数据来自 DNS 外部）或辅助的（如果其区域数据通过区域传输过程来自主服务器）。例如，root、org、acm.org 和 hq.acm.org 是独立的管理权限区域。
每个节点都可以拥有 RR（资源记录），其中包含 DNS 的实际内容。根据其名称、类型和数据，RR 可以将主机名映射到 IP 地址或反之亦然，或者描述域的邮件服务器，或者服务于越来越多样的其他目的。每个 RR 都有一个名称、类、类型、TTL（生存时间）和数据。TTL 以秒为单位测量，并在 RR 从权威服务器传输时开始递减。此 TTL 最终在中间缓存服务器内部递减到零；因此，权威服务器声明的 TTL 为 RR 的重用生存期设置了上限。
DNS 客户端最常见于 TCP/IP 发起程序的运行时库中。这些运行时库被称为解析器，并且通常没有自己的缓存（因此，它们是存根解析器）。存根解析器从其指定的上游完整解析器请求递归服务。完整解析器能够缓存数据以供重用，并能够浏览区域层次结构以定位 DNS RR，无论它位于命名空间中的哪个位置或存储在哪个权威服务器上。
这种 DNS 视图可能听起来并不“简化”。请放心，它实际上被过度简化了。请继续阅读以了解其中真正发生了什么。
实际视图
DNS 标签的字符集是修改后的 US-ASCII。它是 8 位干净的，除了值 0x41 到 0x5A（大写字母）和值 0x61 到 0x7A（小写字母）。出于搜索和匹配的目的，这些被认为是等效范围，但为了支持可能编码为域名的混合大小写英语商标，它们在线路和表示中保留了它们的区别。因此，在一个八位字节可以包含的 256 个可能值中，只有 230 个是唯一的。在实践中，仅使用可打印的 US-ASCII 字母和数字，有时还使用连字符进行内部标点。DNS 协议的国际化已经进行了 10 年，但迄今为止还没有虚拟市场存在。
DNS 数据被缓存和转发时，标签大小写应该被保留，以支持可能的商标。然而，普遍用于支持 DNS 缓存的内部数据结构仅保留每个标签的一个副本。例如，DNS 缓存中将只有一个 com TLD（顶级域名）标签，即使数百万个其他域名可以存储在该 TLD 下。这里的净效应是，如果您遇到的第一个 .com 域名对其 TLD 域名标签使用所有大写字母，那么您遇到的所有其他 .com 域名将以相同的方式显示。因此，如果您首先缓存 vix.COM，那么您将缓存 example.COM，即使您实际上接下来听到的是 example.com。
完全限定域名的尾部句点 (.) 在表示中可以省略，这可能意味着该名称不是完全限定的，必须在默认上下文中搜索，或者它是完全限定的。例如，如果您在 世界总部内部并将 Web 浏览器指向 internal，您的解析器库可能会假设您的意思是 internal.hq.acm.org。消除歧义要么通过应用程序约定，要么通过实际搜索（也许您实际上指的是 internal.acm.org）。一种常见的应用程序约定是，“如果域名中存在其他句点字符，则假定该名称是完全限定的。”（因此，如果您在旧金山办事处，您的解析器库可能会假设 internal 意味着 internal.acm.org，但它永远不会猜测 internal.hq 意味着 internal.hq.acm.org。）
用于描述向下委托的 RR 必须同时存在于父（委托）区域的底部边缘和子（被委托）区域的顶点。这些记录预计是相同的，但差异很常见，并且此类差异的含义未定义。该系统在面对这种情况和其他未定义的条件时非常健壮，协议代理准备非常努力地重试，并尝试所有可能的数据路径，然后才放弃。（因此，本地配置错误转化为全球范围内的无声资源消耗。）
RR 以半原子集（<name,class,type> → {data}）存储和传输。如果消息无法包含完整的 RR 集，则传输代理可以指示已发生截断。接收代理应该选择省略的数据是否值得进行新的事务，但在实践中，截断总是会导致新的事务，因为接收者实际上不知道他们缺少什么。截断后重试事务很可能会使用更昂贵的传输协议（TCP 与 UDP）。
RR 集从缓存中原子地过期，但每个资源记录都有自己的 TTL。这意味着最低 TTL 控制过期，但这些单独的 TTL 在传输和存储期间被维护。TTL 可以钳制为特定于实现的值，以帮助管理缓存大小。接收到的 TTL 为 0 的记录在当前事务结束时过期，即使该事务花费了相当长的时间，可能是因为需要从其他服务器获取其他数据以收集完成所需的所有位和片段。
每个 RR 都有一个类，但协议规范不清楚类是 RR 集的元组指示符的一部分，还是像 rdata 字段一样，是每个记录的有效负载的一部分。现代软件将类解释为区域限定符，这样每个类都可以有自己的命名空间，并且任何区域内的所有记录（因此在任何 RR 集内）都将具有相同的类。圣经支持其他解释，但当前没有实现以任何其他方式工作。
查询消息的 question 部分允许包含多个 <name,class,type> 元组，但这在协议中未定义，并且普遍未实现。现代约定要求响应消息的 question 部分包含来自查询的 question 部分的副本。实施者认为，当事务速率非常高时，响应中存在 question 有助于消除响应的歧义。这个主题在 DNS 标准社区内进行了激烈的辩论。
响应可以包含一个附加数据部分，该部分携带未请求但响应者认为可能有助于解释或使用答案的信息。此数据是可选的，其缺失可能是后续事务的直接原因。然而，它的存在经常被忽略，因为这种可选数据本质上不如实际请求的答案安全。
两个具有不同父区域（msn.net 和 aol.com）的区域，其名称服务器彼此位于对方区域内（因此，msn.net 的名称服务器是 ns.aol.com，aol.com 的名称服务器是 ns.msn.net），将无法访问。这是因为来自 com 区域的 aol.com 委托中的附加数据记录（其中包括作为附加数据的 ns.msn.net 地址）将被视为不可信而被忽略，同样，来自 net 的 msn.net 委托包含作为附加数据的 ns.aol.com 地址也会被忽略。当您这样做时，没有警告消息，除非您将您的寻呼机不断发出的哔哔声视为警告消息（因为接下来会发生这种情况）。
此信息是从 BIND（伯克利互联网名称域）20 年的实现历史中收集的。其中大部分内容没有记录在任何地方，如果您让两三个 DNS 实现者在一个房间里讨论它，其中一些内容仍然被认为是值得商榷的。（而且，意外还在不断发生！）
复杂性
从这个概述中，可以得出结论，DNS 是一个规范不明确的协议，但这将是不公平和不真实的。DNS 是有意地宽松规范的。这种协议设计是 M.A. Padlipsky 在他 1984 年的惊悚小说《网络风格要素》（Prentice Hall）中提出的“描述性而非规定性”的一个很好的例子。功能互操作性和易于实现是 DNS 协议规范的目标，从 DNS 从其培养皿发展成为吞噬世界的怪物的相对容易程度来看，对我来说很明显，这些目标已经实现。更强大的文档集本可以消除 DNS 实现者面临的一些“陷阱”，但规范的本质和有意的宽松必须被视为一种优势，而不是弱点。
话虽如此，今天编写的更强大的文档集也无法将所有 DNS 精灵放回瓶子里。当面对宽松的规范时，太多的实现做出了不同的猜测，今天的互操作性是一个动态的、有机的目标。当我周期性地渴望从头开始重写规范时，我知道有太多的事情必须说，但也无法说。就好像在讨论某个位模式的含义时，对协议的现代描述（在充分了解 DNS 领域已完成的所有工作的情况下编写）将不得不说，“它可能意味着 x，但某些实现会认为它意味着 y，因此您必须谨慎。”
如果一组潜在状态、条件和模式的客观含义的复杂性索引是某种程度上这些状态、条件和模式的组合和排列以及多种解释和有意的不确定性的函数，那么 DNS 是一个非常复杂的系统，即使它的规则简单且很少，即使可以使用几千行软件代码构建一个新的 DNS 协议代理。
未来的复杂性
一个重要的复杂性考虑因素是，“所有这一切在未来会是什么样子？” 随着协议的不断发展，协议设计者将添加对今天的 DNS 客户端和服务器没有意义的新信令模式，并且他们可能会使新模式取决于协议级别的协商。我说“可能”是因为也可能某些新的信令模式将被认为是无害的，以至于即使在上一代协议代理将处理的消息中也可以包含它。根据这些协议代理的实现质量，应该无害的事情实际上可能是无害的。同样有可能的是，当互联网上的其他人正在做一些本应无害的事情，甚至可以在最新的互联网标准文档中描述的事情时，未经测试且有错误的代码路径将首次得到执行。让我们探讨一下该领域的一些已知可能性，包括一些已经成为互联网标准十年但仍被许多人视为“新”标准的可能性。
IDN（国际化域名）。互联网可能起源于母语为 US-ASCII 的国家，但它现在是一个全球网络。数十亿原本不了解或不使用 US-ASCII 的用户已经了解了它，因为 DNS 标签是用该符号表示的。要表达多语言符号集通常意味着 Unicode，其二进制表示形式与 DNS 标签所需的区分大小写“折叠”不直接兼容。因此，Unicode 名称必须首先转换为类似于 Base64 或 uuencode 的 US-ASCII 子集，然后在 DNS 中传输，然后在远程端转换回 Unicode 以进行表示。这些编码的域名对于任何不了解 IDN 的端点或中间盒来说都像随机的十六进制行噪声。
EDNS（扩展 DNS）。当 DNS 协议中的大多数固定二进制字段几乎同时填满时，我们想出了一种协商更大尺寸的方法。最重要的限制是 UDP（用户数据报协议）传输的 DNS 消息大小，该大小已被限制为 512 个八位字节。借助 EDNS，几乎所有现代 DNS 发起程序都声明了 1,500 个八位字节或更大的缓冲区大小。请注意，EDNS 规范的其他要素不太成功，例如支持扩展标签类型的建议，事实证明，扩展标签类型毕竟是不可协商的。
IXFR（增量区域传输）。如果 DNS 区域非常大，那么每当区域更改时，将整个区域从主权威服务器传输到所有辅助权威服务器的成本可能非常高昂（以计算和网络资源衡量）。借助 IXFR，可以仅传输区域增量。事实上，IXFR 事务有一个退化的情况，即整个区域增量都包含在单个 UDP 数据报中（如果它适合）。这避免了 DNS 区域传输通常需要的三次 TCP 握手。
动态更新。DNS 最初假设所有更改都将从 DNS 外部进入区域（例如，服务器计算机文件系统上的文本文件）。机器生成的更新（例如，如果 DHCP 服务器想要在成功分配地址后记录名称地址映射）没有通往区域的数据路径。动态更新使得在 DNS 协议本身内部传输 DNS 更新事务成为可能。在不断发展的访问控制方案的约束下，完全机械化的更新现在非常流行。
更改通知。在过去，辅助名称服务器必须轮询主名称服务器，以了解区域的序列号（以及因此，大概是区域的内容）是否已更改。对主名称服务器上的区域所做的任何更改都可能在轮询间隔之前保持未发布状态。现在，主名称服务器可以将入站更改通知传输到辅助名称服务器，从而触发早期轮询（并且很可能是立即增量区域传输）。
事务安全。由于 IP 源地址在设计上是不可否认的，并且由于 DNS 使用无状态 UDP，因此无法对声称的信令者的身份充满信心。TSIG（事务签名）允许使用对称密码术和先前建立的共享密钥对任何 DNS 事务进行数字签名和验证。尽管这在理论上可以用于控制查询访问，但其实际主要用途是控制动态更新和区域传输的访问。
数据真实性。再次参考 IP 源地址的不可否认性，用从未被管理权限区域的编辑者看到或发布或批准的数据污染缓存名称服务器在计算上是微不足道的。这需要非对称密码术，其中区域管理员生成密钥对，在区域顶点发布公钥，在父（委托）区域中发布公钥的哈希值，并使用私钥生成每个 RR 集的数字签名。选择验证这些签名的解析器将必须获取整个密钥-签名链，一直追溯到一些先前已知的信任锚点，这通常是根区域的公钥。DNSSEC（DNS 安全扩展）已投入生产 12 年之久，迄今为止尚未使用于生产，我们在互联网标准社区期待在未来许多年内解决和重新解决这个问题。（但是，我对此并不感到苦涩。）与此同时，DNS 没有受到更多攻击的唯一原因是没有人相信其真实性。（也许是一个两难困境？）
可预测性和建模
托马斯·J·瑞恩 1977 年的小说《P-1 的青春期》讲述了一个程序员出于违反操作系统安全策略的愿望而无意中创造人工智能的故事。故事中，类似于“囚徒困境”的博弈论软件实现仅使用具有已知和可预测行为的元素来创造不可预测性。
一方面，这种概念显然是虚构的，没有人暗示互联网甚至 DNS 已经实现或将永远实现意识。另一方面，协议中未指定的事物、协议中宽松指定的事物以及协议中无法强制执行的事物——以及该领域中以各种方式解释协议规范的实现——描述了一个丰富且多维的空间，在这个空间中，几乎不可能确切地知道正在发生什么或在可描述的情况下会发生什么。这对于互联网的路由系统也是如此，但在 DNS 中，每个轴上的变量都比我研究过的任何其他分布式系统都多。我们在这个领域工作的人认为 DNS 有点像活着的，我希望在阅读本文后，您能明白为什么。问
建议进一步阅读
Davis, C., Vixie, P., Goodwin, T., Dickinson, I. 1996. 一种在域名系统中表达位置信息的方法。IETF; http://www.ietf.org/rfc/rfc1876.txt。
Gulbrandsen, A., Vixie, P., Esibov, L. 2000. 用于指定服务位置的 DNS RR。IETF; http://www.ietf.org/rfc/rfc2782.txt。
Vixie, P. 1996. 一种及时通知区域更改的机制。IETF; http://www.ietf.org/rfc/rfc1996.txt 。
Vixie, P., et al. 1997. 域名系统中的动态更新。IETF; http://www.ietf.org/rfc/rfc2136.txt。
Vixie, P., et al. 2000. DNS 的密钥事务身份验证。IETF; http://tools.ietf.org/html/rfc2845。
Vixie, P., Kato, A. 2004. 现代 DNS 作为连贯的动态通用数据库。IEICE 通信学报 (十月)。
PAUL VIXIE 自 1980 年以来一直作为协议设计师和软件架构师为互联网协议和 Unix 系统做出贡献，并于 1994 年成为 ISC（互联网系统联盟）的联合创始人。在他的职业生涯早期，他开发并推出了 SENDS、proxynet、rtty、cron 和其他不太知名的工具。他被认为是 BIND8 的主要现代作者和技术架构师。1995 年，Vixie 与他人共同创立了 PAIX（帕洛阿尔托互联网交换中心），该公司于 1999 年出售给 AboveNet。他于 2000 年被任命为首席技术官，然后于 2001 年担任 PAIX 子公司的总裁。他还与他人共同创立了 MAPS（邮件滥用预防系统），这是一家成立于 1998 年的加利福尼亚州非营利公司，旨在阻止垃圾邮件发送者。
最初发表于 Queue 第 5 卷，第 3 期—
在 数字图书馆 中评论本文
更多相关文章
David Collier-Brown - 关于带宽，你一窍不通
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们拥有 50 到 100 Mbps 范围内的带宽，问题就是延迟，即 ISP 的路由器处理他们的流量所需的时间。如果您是一家 ISP，并且所有客户都讨厌您，请鼓起勇气。这现在是一个可以解决的问题，这要归功于一群敬业的人，他们找到了这个问题，解决了它，然后在家庭路由器中证明了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型进行设备入网
设备的自动入网是处理正在安装的越来越多的“边缘”和物联网设备的一项重要技术。设备的入网与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入网加快流程，必须在设备中形式化供应链中的信任关系，以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪进行分布式延迟分析
低延迟是许多 Google 应用程序（如搜索）的重要功能，延迟分析工具在以规模维持低延迟方面发挥着关键作用。对于包括功能和数据不断发展的服务的复杂分布式系统，将整体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实的分布式系统中，诸如 RPC 遥测、CPU 性能分析和分布式跟踪之类的现有工具对于理解整个系统的子组件很有价值，但在实践中不足以执行端到端延迟分析。
David Crawshaw - VPN 的一切都是全新的
VPN（虚拟专用网络）已有 24 年的历史。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也在增长和变化。VPN 在 2000 年代的互联网中经历了一个尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。
© 保留所有权利。