PDFDNS 不是什么
Paul Vixie，互联网系统协会
对于很多人来说，DNS 有很多含义——或许对于太多人来说，DNS 的含义太多了。
DNS（域名系统）是一个分层的、分布式的、自治的、可靠的数据库。它是同类数据库中的第一个也是唯一一个，为全球受众和全球贡献者提供实时的性能水平。每一个 TCP/IP 流量，包括每一个万维网页面浏览，都始于至少一个 DNS 事务。简而言之，DNS 是辉煌的。
为了强调我们对 DNS *是什么* 的理解，我们必须将其与 *不是什么* 区分开来。互联网经济奖励在人类行为货币化方面的无限创造力，而且这通常以某种中介的形式出现。对于 DNS 而言，货币化的中介意味着说谎。将这种货币化中介带给我们的创新者不会称他们所售卖的东西为“谎言”，但在这种情况下，它走起来像鸭子，叫起来也像鸭子。
并非所有对 DNS 的误用都以说谎的形式出现。另一种常见的滥用是将 DNS 视为目录系统，但它不是。在目录系统中，人们可以提出近似的问题并获得近似的答案。想想这里印刷的电话黄页目录：用户通常在印刷目录中找到他们想要的东西，不是因为确切地知道列表是什么，而是从猜测或一般想法开始。DNS 没有类似的东西：所有问题和所有答案都是精确的。但是 DNS 至少有两种机制可能被滥用以支持近似匹配，这对其他人来说代价相当大，而且这种情况经常发生。
愚蠢的 DNS 技巧
DNS 谎言的第一种广泛形式是将 DNS 查找视为映射请求。CDN（内容分发网络），例如 Akamai 和 Web 优化器产品，例如 Cisco Distributed Director，将传入的 DNS 查找视为指导 Web 浏览器活动的机会。这些产品和服务使用 DNS 请求的 IP 源地址，尝试猜测请求者与多个复制内容服务器中每一个的接近程度。根据每个内容服务器的系统和网络的测量负载，以及对每个内容服务器与该请求者接近程度的估计，精心制作 DNS 响应，以将该请求者定向到最接近或最佳的内容服务器，以获取该 URI 域。
这种方法存在许多问题，但没有一个会影响 CDN 运营商的收入。首先也是最重要的是，有必要击败或严格限制这种基于策略的数据（“DNS 谎言”）的缓存和重用。曾经被认为是 DNS 性能和可扩展性必不可少的缓存和重用，将允许也让请求者 B 看到为请求者 A 设计的基于策略的响应，而请求者 B 可能不会收到相同的答案——例如，当服务器负载发生变化并且存在新的平衡时。这种非缓存的影响是更高的 DNS 请求率（可能导致按事务收费的 CDN 获得更高的收入）以及访问侧网络的更多网络负载，以及平均事务时间的略高下限。
此外，假设 DNS 请求的 IP 源地址给出任何关于终端系统 Web 浏览器网络位置的提示从来都不是明智的。这是因为 CDN 听到的 DNS 请求来自递归 DNS 服务器，这是缓存未命中的结果；它们不是来自终端系统本身。一些 ISP 将其递归名称服务器区域化，允许 CDN 编码规则以提高其估计的质量。然而，许多递归名称服务器是按国家或按大陆，甚至按半球划分的，因此 CDN 始终有必要部署连接良好的超级节点，而这些超级节点总是最终听到很多区域外的请求。
CDN 的主要好处与无噱头外包相同：如果事情进展不顺利，它可以让内容所有者起诉某人。DNS 系统性能和稳定性必须为此类责任保护付出代价，这充其量是不幸的。鉴于 CDN 仍然需要会听到许多区域外请求的超级节点，此处的无噱头方法是如实回答 DNS，并让现有的伪随机分发机制发挥作用。注意到现有的伪随机化技术没有专利，并且没有人因为购买 CDN 而被解雇，我们可以预期在未来几十年内看到越来越多的内容以这种方式分发。
NXDOMAIN 重映射
非常频繁地，就像在全球范围内每秒数百万次一样，有人在 DNS 中查找不存在的域名。也许这是 Web 浏览器的用户输入了印刷错误，或者 Web 站点上存在断开的链接，或者可能是硬件或软件错误导致不存在的名称进入 DNS 请求。无论如何，答案通常应该是 NXDOMAIN（有时写为 RCODE=3）。这些否定答案是可缓存的，就像任何其他类型的 DNS 信息一样，因为 DNS 旨在表达真理，而不是策略。网络应用程序（可能是 Web 浏览器、邮件服务器，或者实际上是任何使用 TCP/IP 流量来完成其业务的应用程序）收到这些否定响应之一后，应该将其视为错误，并拒绝导致此查找的自身底层工作项。对于 Web 浏览器，拒绝的形式是“错误页面”。对于邮件服务器，拒绝取代了“退回电子邮件”。每个 TCP/IP 应用程序，无论大小、新旧，都知道如何处理 NXDOMAIN。
万维网改变了规则。尽管 Web 很年轻——尽管互联网在 Web 之前就存在，并且在 Web 之后仍然存在，并且比 Web 大得多——但事实仍然是 Web 是最终用户正在查看的内容。广告商有一整套语言来描述最终用户的价值，使用的词语如“展示次数”、“点击率”和“眼球”。这些广告商问道，如果有可能获得展示次数，你为什么还要发回 NXDOMAIN？因此，越来越多地，如果请求一个不存在的名称，你将获得应用程序知道如何处理的肯定（欺骗性；虚假；谎言）答案，而不是你的应用程序知道如何处理的 NXDOMAIN。
例如，如果我向我自己的递归名称服务器询问一个不存在的名称，它会告诉我 NXDOMAIN。如果我向 OpenDNS 的递归名称服务器询问一个不存在的名称，它会向我发送一个 NOERROR 响应，其中包含指向广告服务器的答案。请注意，我使用 OpenDNS 作为一个方便的例子；它不是这项技术的发明者。事实上，Nominum 和其他 DNS 供应商现在销售对其递归名称服务产品的附加组件，以允许世界上任何 ISP 都这样做，并且越来越多的 ISP 正在这样做。为什么这么多？仅仅因为任何重映射这些 NXDOMAIN 响应的人都会获得展示收入。有未经证实的说法称，一些 ISP 正在阻止访问 OpenDNS 和/或所有非 ISP 名称服务器，以迫使其客户使用 ISP 自己的名称服务器。我说未经证实，但我认为这些说法是可信的——ISP 的利润非常微薄，如果他们看到这种意外之财流失，他们不能就让它发生。
为了证明捕捉这种收入的极端愿望，一个真实的故事：几年前，VeriSign（根据与 ICANN（互联网名称与数字地址分配机构）的合同运营 .COM 域名）在 .COM 区域的顶部添加了一个“通配符”(*.COM)，以便其权威名称服务器不再生成 NXDOMAIN 响应。相反，它们生成包含 SiteFinder 网站地址（一个广告服务器）的响应。来自社区（包括您卑微的叙述者）的强烈抗议声势浩大且持续不断，在 ICANN 有机会提起诉讼以阻止这种胡说八道之前，许多人已经修补了他们的递归名称服务器，以将来自 .COM 名称服务器的任何非委派响应（例如，告诉如何查找 GOOGLE.COM 名称服务器）重新映射回 NXDOMAIN。一些 ISP 将逻辑放入其基于策略的路由器中，以将 SiteFinder 响应转换为指向 ISP 自己的广告服务器的指针。
损害控制
NXDOMAIN 的设计目的不是为了成为收入来源——许多应用程序都依赖于来自 DNS 的准确错误信号。例如，考虑用于 Web Cookie 的“同源信任模型”。如果您持有 GOOGLE.COM 的 Cookie，并且您被愚弄去点击 KJHSDFKJHSKJHMJHER.GOOGLE.COM 的链接，并且生成的 NXDOMAIN 响应被重映射为对某个广告服务器的肯定回答，那么当您向该广告服务器发送 HTTP GET 请求时，您将把您的 Cookie 发送到该广告服务器。对于 GOOGLE.COM Cookie 来说，这并不是一件坏事，但对于 BANKOFAMERICA.COM Cookie 来说，这是一个真正的问题。（感谢 Dan Kaminsky 告诉我关于“同源信任模型”的问题。）
如果以这种方式捕获 MX（邮件交换器）请求，则重映射也可能导致电子邮件被捕获。许多 NXDOMAIN 重映射器尝试仅在 A（地址）请求上触发以避免这种情况，但是为了使其工作，他们必须关闭缓存，因为 NXDOMAIN 不是类型特定的，并且由于 SMTP 发起者如果在 type=MX 中没有得到答案，将回退到 type=A。类似的保护措施（旨在在仍然吸引收入的同时避免诉讼）包括仅当查询域以 WWW 开头时才触发重映射逻辑的想法——但据我所知，有很多印刷错误以 WW. 开头或以 .CM 结尾，因此我对它的长期效果不抱太大希望。涉及的资金太多了，没有人愿意把它留在桌面上（在这种情况下，它应该留在那里）。
标准不良实践
在撰写本文时，IETF 草案（想想：proto-RFC）正在讨论服务提供商推荐的 DNS 重定向配置和使用。本文档的目标是为如何交付 DNS 谎言提出一些规则，以便为这个不断增长的市场中的所有供应商和运营商提供一个共同的服务框架。一些勒德分子可能会觉得，该领域的“标准最佳实践”根本是不这样做，但这并不现实，我们现在面临着标准行动。作为 DNS 技术的一项标准功能，我们可以预期有一天所有 DNS 服务都将以这种方式交付，我们的孩子会像看待八轨磁带一样看待端到端 DNS。
本文档通过建议此服务的退出应为网络层属性（换句话说，与某人的以太网 [MAC] 地址或设备端口号关联），而不是传输层属性，从而为围绕此功能领域的辩论做出了重大贡献。注意到与任何其他类型的信息一样，垃圾邮件退出不如选择加入对经济有利，IETF 草案的作者表示 Web Cookie 不够好，这对辩论很有价值。其他人可能不同意，但至少这一点现在摆在桌面上了。本文档还讨论了“法律强制”的 DNS 重定向，这正是它听起来像的噩梦，我们都希望它能尽快成为历史的好奇心。
IETF 草案绝对最好的部分是第 10 节（DNSSEC 考虑因素），结尾如下
“因此，DNS 安全扩展给 DNS 重定向带来问题的唯一情况是使用验证存根解析器。这种情况现在没有广泛部署，并且可以通过使用由适用的 ISP 或 DNS ASP 配置的信任锚来缓解，该信任锚可用于签署重定向的答案。如上文第 9.7 节所述，此类对有效响应的不当重定向也可能导致 DNSSEC 信任验证问题。”
正在考虑的救援
十五年前，一群象牙塔理论家在 IETF 聚在一起说：“让我们保护 DNS。” 威胁模型随着时间的推移而演变，现在这套协议增强功能 (DNSSEC) 或多或少已准备好部署，并且或多或少允许捕获和忽略 DNS 谎言的可能性。注意到 DNSSEC 花费的时间太长，并且由于其笨拙和复杂性而成为基于委员会的恐怖，以下是它应该如何工作以及它如何帮助遏制当前 DNS 谎言市场。
在 DNS 中，数据生产者是权威名称服务器，每个权威名称服务器都是一个或多个区域的委派权威。对于今天而言，将 DNS 区域视为某个名称或低于某个名称的所有内容，因此，例如，WWW.GOOGLE.COM 在 GOOGLE.COM 区域中。DNSSEC 允许使用公钥加密对这些区域进行签名和验证。私钥（签名密钥）由区域的编辑器用于为每组真实记录生成签名记录。公钥由递归名称服务器使用，以验证它们接收的数据是否由相应私钥的持有者签名。公钥（验证密钥）使用 DNS 本身发布，方法是将每个区域的密钥包含在区域的父区域中——因此 GOOGLE.COM 区域的公钥发布在 COM 区域中，依此类推。我故意跳过关于 COM 的公钥应该在哪里发布的漫长而不愉快的故事，因为它与本文无关。
从理论上讲，不喜欢被欺骗的终端系统所有者可以与不喜欢他们的区域被谎报的区域编辑器合作，如果他们每个人都部署 DNSSEC。应该收到 NXDOMAIN 但今天收到指向广告服务器的应用程序将在 DNSSEC 世界中收到“签名不存在”错误。这将是一个错误，因为 DNSSEC 有一种方法来通知验证器应该存在签名。请注意，在绝大多数情况下，区域编辑器并不关心他们的区域是否被谎报，因此，DNSSEC 在大多数情况下将保持沉默。还要考虑到这不是最初的 DNSSEC 威胁模型；我们真的认为我们必须阻止在线路上的损坏，例如 Dan Kaminsky 在 2008 年发现的损坏，而阻止中间盒损坏，例如 NXDOMAIN 重映射，实际上只是额外的奖励。
DNSSEC 将使使用愚蠢 DNS 技巧的 CDN 提供商的生活复杂化，但这不会结束这场战争，因为仍然可以签署每个基于策略的答案并保持所有答案和签名的可用性，并且仍然根据请求者身份和策略向同一问题发送不同的答案，并且让所有签名都完全有效。
DNSSEC 也会使系统管理员和应用程序开发人员的生活复杂化。我们（ISC—BIND 的人）正在尽我们所能来改进 BIND9 9.7（预计在 2009 年 12 月之前发布），并且该领域还有许多其他服务和技术提供商。DNSSEC 的杀手级应用程序将是一个 Web 浏览器和 Web 服务器，它们可以在不使用 X.509 的情况下相互验证（特此鼓励志愿者聚在一起尝试实现这一点）。
目录服务
包括 Microsoft 和 Mozilla 在内的浏览器实现者已经开始在从图形前端收集 URI 的同时执行 DNS 查询，以便进行花哨的“自动完成”。这意味着在输入 URI（例如 http://www.cnn.com/）的时间内，浏览器将询问诸如 W、WW、WWW、WWW.C、WWW.CN、WWW.CNN 等问题。情况还不算那么糟糕，因为浏览器对顶级域名有一个预编译的想法。例如，它们实际上不会询问 WWW.C，但它们现在正在询问 WWW.CN（在中国）和 WWW.CNN.CO（在哥伦比亚）。
虽然一个听起来简单的解决方案是让 Microsoft 和 Firefox 为中国和哥伦比亚（以及无疑还有许多其他受影响的顶级域名运营商）购买一些名称服务器硬件和网络链接，但这不会阻止信息泄漏或从网络的其余部分删除这种愚蠢且无用的流量。由于真正最好的解决方案通常是停止做这种愚蠢的事情——我们都知道这不会发生——也许这种行为可以设置为可选，然后我们可以争论默认设置（选择加入与选择退出）应该是什么。这是 DNS 历史上第一次有人前瞻性地使用它来查找已键入的内容是否是有效域名，以支持类似自动完成的功能。与 DNS 的许多其他新颖用途一样，这不是它最初设计的用途。
如果 DNS 在设计时考虑了这种事情，我们可以判断的一种方法是域名将从最高级到最低级术语（COM.CNN.WWW）书写。这将允许部分名称完成，就像图形文件系统浏览器中发生的那样。在没有完全重新设计的情况下（由于已安装基础的大小和实用性，这在我们有生之年不会发生），我们所能做的就是要求浏览器实现者更聪明，并为我们网络上更多的 DNS 流量做好准备。
结论
DNS 不是映射服务，也不是用于传递基于策略的信息的机制。DNS 的设计目的是表达事实，而不是策略。然而，由于它运行良好且无处不在，企业家们常常将其视为一个全新的机会。我们这些致力于实施、增强和部署 DNS 以及保持全球名称服务器系统运行的人，将继续寻找方法来保持它的活力，即使所有这些创新者都在从中分一杯羹。
这些是不愉快的观察结果，并且由于已安装基础的规模非常庞大，因此无法找到解决方案。DNS 不足的任务，但人们仍然希望它能够完成的任务，在大多数情况下是当前设计的基础。现在将要上演的是一场信息战，其中足够早地挤进来并获得足够市场份额的创新者将阻止其他人也这样做——DNS 谎言与 DNS 安全只是一个例子。
问
喜欢它，讨厌它？请告诉我们
PAUL VIXIE 是互联网系统协会 (ISC) 的总裁，ISC 是一家运营 DNS F 根名称服务器的非营利公司，并且发布了 BIND 软件，该软件被互联网 80% 的用户用于 DNS 发布。他还是美国互联网号码注册机构 (ARIN) 的主席，ARIN 是一家在北美和加勒比地区分配互联网号码资源的非营利公司。此前，Vixie 先生是第一个中立商业互联网交换中心 PAIX 的创始人和总裁；AboveNet 的高级副总裁/首席技术官；以及 1996 年第一家反垃圾邮件公司 (MAPS LLC) 的创始人。
© 2009 1542-7730/09/1100 $10.00
最初发表于 Queue vol. 7, no. 10—
在 数字图书馆 中评论本文
更多相关文章
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 用户和应用程序也在增长和变化。在 2000 年代的互联网中，VPN 经历了一个尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。
© 保留所有权利。