有不少互联网技术从一开始就没有得到热烈的采用。在许多情况下，这些技术被悄悄地抛弃，以支持下一项创新，但在某些情况下，这些技术就是不肯离开，而是处于部分采用的长期状态。在某些情况下，这种状态持续的时间太长，以至于许多最初支持该技术的理由已被事件所取代，支持采用的理由需要用更近期的术语重新表述。
IPv6 就是一个很好的例子，该协议的基本架构，即基于端到端地址的数据报架构，已经变得不再完美适合广泛使用复制服务交付平台的客户端-服务器网络。
当今的网络正在向基于名称的网络转变，地址耗尽以至于无法再对每个连接的客户端进行唯一寻址，这不再是我们曾经认为的灾难性事件。我们似乎已经在当今的互联网上连接了大约 300 亿台设备，但就 IPv4 的使用而言，我们仅使用路由系统中可见的 30 亿多台唯一 IPv4 地址就实现了这一目标。
在这种情况下，我指的是安全 DNS 或 DNSSEC，它已经与渐进式采用紧密相关了大约 30 年。在此期间，我们看到许多理论出现，解释 DNSSEC 的采用速度为何如此缓慢，包括缺乏认识、工具不佳、无法实现运营管理自动化、运营过于复杂以及总体上无法维持采用 DNSSEC 所带来的增量收益远远超过增加的运营成本和服务脆弱性。由于 30 年来缺乏普遍采用 DNSSEC 的明确信号，现在是时候承认 DNSSEC 不会有任何发展了吗？是时候结束 DNSSEC 并继续前进了吗？
诚然，这是一个极端的立场，我承认我故意提出这个问题以引起你的注意，但这里有一个令人不安的事实。作为服务运营商的集合，我们似乎并不太在意投资来支持运营 DNSSEC 安全的 DNS 的额外成本。在经历了 30 年的不安全的 DNS 基础设施之后，我们似乎对这种结果感到满意。
我们怎么会落到这个地步？
踏上 DNSSEC 之旅
早在 1990 年，就有研究人员报告称 DNS 容易受到缓存中毒攻击。这意味着攻击者可以将虚假的名称到地址映射信息植入 DNS 解析器，解析器随后会将这些信息保存在其本地缓存中，然后使用该信息回答后续查询。这对网络来说是一个重大问题，因为当时的信任框架基于 DNS 名称到 IP 地址的映射（DNS 解析）的完整性以及将 IP 数据包定向到“正确”目的地的路由系统的完整性。简而言之，只要您将数据包发送到正确的 IP 地址，您就一定会相信响应是真实的。此 DNS 攻击破坏了 DNS 名称到相应 IP 地址的映射，最终用户无法检测到。
互联网工程任务组 (IETF) 的响应是制定 DNSSEC 的安全框架：
通过将 DNS 中的每项信息与加密生成的数字签名相关联来提供安全性。通常，会有一个 RSA 密钥为整个区域签名。如果解析器可靠地了解该区域的 RSA 公钥，它可以验证读取的所有数据是否经过适当授权并且是合理的最新数据。
draft-ietf-dnssec-secext-00.txt，1994 年 2 月
该规范在随后的几年中在 IETF 流程中不断完善，并于 1997 年 1 月作为拟议标准RFC 2065发布。
然后什么也没发生。
为什么？
嗯，正如 RFC 本身所说：
需要注意的是，这些扩展最多只能保证从 DNS 检索到的资源记录（包括关键资源记录）的有效性。它们并不能神奇地解决其他安全问题。例如，使用安全 DNS，您可以对检索到的主机名的 IP 地址充满信心；但是，这并不能阻止某人在该地址替换未经授权的主机或捕获发送到该地址的数据包并使用看似来自该地址的数据包进行错误响应。任何相当完整的安全系统都需要保护互联网的许多其他方面。
RFC 2065，1997年 1 月
SSL 的兴起
与此同时，Netscape 也在研究同样的通用问题，只是角度不同。他们的成果被称为安全套接字层 (SSL)，于 1995 年发布 2.0 版。（早期版本 1.0 容易受到重放攻击）。SSL 试图回答的问题与 DNSSEC 提出的问题略有不同。这里的问题是：“我连接的服务能否证明它是 DNS 名称命名的服务的真实实例？”
成功的 SSL 连接所回答的安全问题不一定与 IP 地址相关联，连接的服务端使用什么 IP 地址也无关紧要。只要服务能够证明它是名称服务的真实实例，则该连接被视为真实。
他们的方法使用了更传统的 X.509 公钥证书应用，使用一组受信任的中介机构（证书颁发机构 (CA)）来保证服务运营商的公钥/私钥对与给定 DNS 名称之间的绑定的真实性。这种方法完全绕过了对 DNS 的名称到地址映射功能进行验证的需要，并提出了更直接的问题：“我的数据包是否最终到达了我希望它们到达的指定服务点？”
SSL（1999 年 IETF 接手维护该协议时，在后续修订中被称为传输层安全性 (TLS)）的使用确实蓬勃发展。但它也存在一些问题，包括协议中存在一系列安全漏洞、域名 x.509 证书颁发费用高昂，以及一些受信任的 CA 在颁发证书时不断出现错误和失误。
然而，紧密联系的浏览器开发者和 Web 内容服务器平台供应商社区能够保持框架的一致性。它能够承受通过使用免费域名证书将安全内容从昂贵的奢侈服务转变为免费商品所带来的扩展压力。根据一家流行的 Web 内容平台的数据，如今 TLS 在 Web 内容领域的渗透率已超过所有 Web 请求的 97% 。
相比之下，DNSSEC的采用情况则相当平淡。在DNSSEC的稳定规范RFC 4033发布二十年后，我们仍然在问：“为什么DNSSEC还没有被广泛采用？”
DNSSEC 与 TLS
这并不是说 TLS 和 DNSSEC 可以直接替代，因为它们执行不同的信任功能。而是 TLS 实际上提供了更有用的信任结果。如果远程服务点可以向连接客户端证明其真实性，即它实际上是客户端想要连接的命名服务的实例，那么客户端用于将数据包定向到此服务器的 IP 地址就不那么重要了。
TLS 几乎没有外部依赖关系。服务运营商需要满足任何受信任 CA 的证书颁发标准，这通常意味着它必须通过向 DNS 添加一次性令牌或执行一些类似的“控制证明”测试来证明它对相关 DNS 区域具有控制权。CA 将颁发证书并将其交给申请人。申请人将在初始 TLS 交换中使用此公钥证书，并使用其私钥执行某些功能，客户端可以使用证书中提供的公钥来验证该功能。只要 CA 受到客户端信任，并且客户端可以支持 TLS 交换中列出的加密功能之一，此功能就可以可靠地运行。
通配符 TLS 证书的运作方式与 DNS 中的通配符略有不同。DNS 通配符包含任意数量的层次结构，因此名称a.b.c.foo.example.com可以匹配通配符条目*.example.com。通配符域名证书只能包含一层，因此只有 foo.example.com 才能与名称 的通配符证书匹配*.example.com。相比之下，DNSSEC 匹配的范围与通配符的 DNS 范围相同。
这两种技术我们已经使用了三十年了。如果使用程度是比较这些信任框架的标准，那么这些技术的使用程度测量结果存在很大差异。图 1 取自Cloudflare Radar，显示了 HTTP 请求（不使用 TLS 访问）和 HTTPS 请求（使用 TLS 访问）的分布。
图 1 — TLS 采用（来自 Cloudflare Radar）。
我们如何衡量 DNSSEC 的采用情况？我们可以选取Tranco 排名前 100 万的域名，并对其进行调查，看看有多少域名已通过 DNSSEC 签名。最近对该域名列表的扫描显示，其中 94,317 个域名已通过 DNSSEC 有效签名，占 9.4%。这种平均统计形式的问题在于，它对所有这些百万个域名都进行了同等权重，而更相关的统计数据则是以某种方式根据每个域名的相对“使用”程度对其进行加权。也许有另一种方法可以将域名之间的相对使用权重考虑在内。
其中一种方法是查看位于 DNSSEC 验证解析器后面的用户比例（图 2），然后将其与查询数据相结合并检查 DNSSEC 签名的域名查询的相对数量（图 3）。
图 2 — 使用 DNSSEC 验证解析器的用户比例。
图 3 — DNSSEC 签名命名查询比例（使用 Cloudflare 1.1.1.1 递归解析器）。
Cloudflare 查询日志表明，约有 3.2% 的查询针对的是 DNSSEC 签名的名称，而 APNIC DNSSEC 验证数据表明，三分之一的用户正在使用执行 DNSSEC 验证的 DNS 解析器。结合这两个数据集，可以估算出，根据当今数据的 DNS 查询配置文件，DNSSEC 验证的执行时间约为 1%。
对比十分鲜明。TLS 在当今互联网上几乎是普遍使用，而 DNSSEC 的使用却并不常见。
为什么？
我怀疑这些截然不同结果背后的原因在于互联网的经济性，而不是这两种方法的技术优点（或其他方面）。
经济学
互联网并非是集中规划的技术产物。该领域在很大程度上不受管制，如果技术为提供商创造了机会，就会被利用。这些机会可能会降低商品和服务的生产成本，或增加服务对消费者的效用
安全框架如何适应这样的情况？这个问题的主要方面是成本效益问题。假设部署安全机制的增量成本低于对安全措施的估计收益。在这种情况下，支持部署的理由比相反情况要强得多。从表面上看，TLS 和 DNSSEC 都提供了类似的好处，因为这些技术旨在确保用户的数据包被定向到正确的目标地址。换句话说，确保您连接到您想要使用的服务。
我们已经注意到 TLS 和 DNSSEC 之间的保证略有不同，因为 TLS 尝试验证服务是否提供它是该命名服务的实例的保证，而 DNSSEC 提供用户正在将数据包发送到服务名称的地址的保证。
然而，更重要的区别是，DNSSEC是基础设施服务的一个实例，其中保证是作为网络连接服务的一个属性提供的，而TLS是应用程序服务的一个实例，其中保证由应用程序提供。
应用程序提供的服务与成本和收益有直接关系。对于 TLS，应用程序在初始连接时会产生延迟，以验证服务器的身份并建立安全会话上下文。它的好处是可以更高程度地保证服务的真实性以及加密会话。
对于 DNSSEC，成本和收益之间的差距更大。要为区域设置可用的 DNSSEC 凭据，所有父区域都需要签名。DNS 基础设施需要存储 DNS 数据和相关数字签名，DNS 名称解析协议基础设施需要支持使用附加的 DNSSEC 签名，这意味着要放弃几乎普遍使用的 UDP 和更大的 TCP 查询负载，而 TCP 查询负载本身也存在一系列性能和成本问题。这意味着一大批第三方在支持 DNSSEC 时会产生一定程度的增量成本，而直接收益却很少。
应用程序不一定知道本地 DNS 存根解析器提供的响应是否经过 DNSSEC 验证。DNSSEC 验证通常不是存根 DNS 解析器提供的服务，递归解析器通常用于执行 DNSSEC 验证。
结果是，应用程序无法假设 DNS 响应已执行 DNSSEC 验证，如果它想要确保所连接的服务器是真实的，它必须执行自己的措施来验证服务器，而不管 DNSSEC 验证的基础设施服务是否在服务名称解析上执行。这意味着 DNSSEC 为应用程序提供的任何增量收益对于应用程序来说都是不直接可见的。换句话说，应用程序被迫不重视 DNSSEC 验证过程，并采取自己的措施来提供这种真实性保证。
在成本和收益不一致的情况下，人们几乎没有动力去承担部署服务的成本，因为其他人会从此类行动中获得边际效益。这种不一致通常会导致市场失灵。这种情况似乎是 DNSSEC 面临的问题。
我们能修复这个问题吗？
我认为，我们无法通过 DNSSEC 目前的运作方式解决这一问题，而 TLS 继续提供更清晰的成本和收益平衡。TLS 应用程序可以验证其所连接服务的真实性，而无需多个外部依赖项。完成 TLS 握手结果所需的额外往返时间被服务的稳健性提高和使用 DNSSEC 本身无法提供的加密保护会话的好处所抵消。
这并不是说 TLS 是完美的。远非如此（例如，请参阅SSL/TLS 和 PKI 历史）。有一组受信任的 CA，每个 TLS 客户端事先都不知道哪个 CA 为给定名称颁发了域名证书。如果单个 CA 以某种方式被破坏，那么它可以为任何域名颁发虚假的域名证书。自动证书颁发者可能会因域名劫持而受到误导。
证书撤销处理不当，因此当使用被盗用的证书时，通常不存在安全地通知客户端这些证书不再受信任的手段。多年来，Web PKI 框架中的此类弱点已被证明难以解决，但由于缺乏可行的替代方案，无法为具有类似成本和收益平衡的应用程序提供类似的保证（我在此观察中包括 DNSSEC），这意味着我们继续依赖 Web PKI 和 TLS。
最有希望解决 Web PKI 框架的缺陷并为 DNSSEC 创造新利益主张的努力来自 IETF 的努力，即将 TLS 公钥放入 DNS（DANE，RFC 6698，2012 年 8 月）。DANE 采取的总体方法非常简单。无需依赖受信任的第三方注释（CA 颁发的 X.509 证书）将公钥/私钥对与给定域名关联，而是可以将密钥对的公钥部分放在该域名的 DNS 区域中。
TLS 客户端无需依赖公钥证书和受信任的 CA 来设置 TLS 会话，而是可以向 DNS 查询公钥的单个记录并执行 DNSSEC 验证以验证密钥的真实性和时效性。几年后，有人提出了对这种基于 DNS 的方法的改进，以提高 TLS 密钥验证过程的速度。此改进（RFC 9102，2021年 8 月）建议将 DNSSEC 验证材料添加到 TLS 握手中，以便在 TLS 握手中提供公钥、该密钥上的数字签名以及用于验证该密钥的 DNSSEC 验证路径。单个信任点（DNS 根密钥）取代了受信任的 CA 集合。
如果这种方法是在 20 世纪 90 年代中期提出的，DANE 可能会取代 SSL/TLS 中 Web PKI 的使用。但到了 2021 年，Web PKI 和相关的收集或受信任 CA 在 TLS 的使用中的地位已经根深蒂固，以至于转移到 DANE 存储这些公钥的成本被认为太高了。因此，DANE 无法获得任何部署动力。
DNSSEC 消亡了吗？
DNSSEC 将会面临怎样的处境？
毫无疑问，DNS 已发展成为互联网架构中更为突出的角色。曾经简单的名称到地址映射现在已同时向多个方向发展。服务绑定工作使 DNS 成为一种服务会合机制，向客户端指定服务可从何处访问以及如何访问。它是一种以域名形式验证远程方凭证的信号机制，并且似乎为分布式系统（无论是善意的还是恶意的！）提供了命令和控制通道。鉴于网络内部从基于地址的架构到基于名称的架构的整体转变，随着时间的推移，将验证添加到 DNS 名称解析过程中的必要性将得到加强，这似乎是合乎逻辑的。
然而，DNS名称解析过程的设计尽可能高效。该协议选择使用UDP作为传输协议，以允许服务器和客户端在无状态模式下运行。后续经验表明，只要DNS负载与UDP负载舒适匹配，不会触发IP数据包碎片，这种设计决策就是有效的。
当数字签名被添加到图片中时，可能会出现实质性问题，DNSSEC 正在 UDP 碎片、触发 TCP 重新查询所涉及的额外延迟以及组装签名验证路径所涉及的进一步延迟之间寻找一条困难的路径。DNS 解析器显然不太热衷于在这种情况下部署 DNSSEC 验证，DNS 名称服务器同样不热衷于启用其服务区域的 DNSSEC 签名。
一些较新的 DNS 功能扩展似乎会利用 DNSSEC 的存在，使其更能抵御各种外部操纵。TLS 握手的服务器名称指示 (SNI) 字段和 TLS 中更通用的客户端问候提供了用户正在访问的站点的明文指示。从隐私角度来看，通过加密隐藏此 SNI 信息当然是可取的，但以一种能够抵御外部篡改的方式传达用于加密初始 TLS 握手这一部分的公钥是一项挑战。
DNSSEC 显然是一种解决方案，客户端可以验证密钥的真实性和时效性，但 DNSSEC 部署状况不佳（无论是在签名区域还是在验证签名名称方面），因此只能采用零碎的解决方案。有人认为，在 DNSSEC 基础上分层添加其他功能和服务可以进一步增强更广泛采用 DNSSEC 的动机。
其他人则认为，提出一种依赖于 DNSSEC 的通用互联网服务会损害这种服务被采用的前景。指定 TLS 加密客户端 Hello (draft-ietf-tls-esni) 的工作草案努力证明，还有其他方法可以提高加密密钥值的防篡改能力，而这些方法不一定涉及 DNSSEC。
如果 DNSSEC 的采用完全基于一个通用命题，即安全且可验证的 DNS 系统在某种抽象意义上比不安全的 DNS更好，那么过去 30 年的证据表明，这一论点对 DNS 基础设施运营商来说并不具有说服力。谷歌、Facebook、Akamai、亚马逊、微软、苹果和 TikTok 作为其内容托管产品的一部分运营的最常用域名都是未签名的，而且 DNS 领域似乎没有明显的趋势会在不久的将来改变这一状况。
是的，对于名称发布者来说，使用 DNSSEC 签名的域名确实有一些好处，而客户执行签名名称的 DNSSEC 验证也有一些好处，但对于大多数服务运营商而言，他们目前对 DNSSEC 的增量成本和收益的评估结果根本不支持采用 DNSSEC。
我们得出的结论有些令人沮丧，即长期以来说服业界安全名称基础设施值得增加采用成本的努力并未取得压倒性成功。这方面的进展令人沮丧地缓慢，并引发了一些更根本的问题。在基于市场的服务环境中，基础设施安全是否是市场失灵？
如果这确实是市场失灵的一个例子，那么是否有理由表达监管利益，例如美国联邦通信委员会最近发布的有关路由安全的拟议规则制定通知？我们是否在错误的地方寻找解决方案？如果互联网越来越以应用程序为中心，那么可以由应用程序而不是基础设施本身应用的真实性测试有什么问题？
有人可能会说，互联网协议 (IP) 的真正创新不在于 IP 标头，而在于传输控制协议 (TCP)。TCP 并没有尝试为网络设计无损可靠数据链路服务，而是采用了不可靠的有损数据链路服务模型，并在传输层修复了损坏。DNSSEC 设计是否有值得借鉴的教训？
按照这种思路，我们如何重新考虑 DNSSEC？一种选择是提前放弃全区域签名，并使用前端 DNSSEC 签名器。我们可以放弃 NSEC 和 NSEC3 记录的复杂性，而改用紧凑的拒绝存在 ( draft-ietf-dnsop-compact-denial-of-existence )，从而消除复杂性和 DNS 响应膨胀的根源。
我们是否可以考虑关闭 DNSSEC OK 标志，并且只允许与 TCP 传输结合使用 DNSSEC 查询？这些前端签名者是否可以执行 DNSSEC 验证，并将 DNSSEC 验证路径与 CHAIN 查询 ( RFC 7901 ) 样式的签名捆绑在一起？我们是否可以考虑将这些 DNSSEC 前端签名者的操作外包给专门的 DNSSEC 提供商？
有一点似乎非常清楚（至少对我来说是这样！），即我们今天所熟知的 DNSSEC 不会消失。对于大多数服务及其用户来说，它太复杂、太脆弱、太慢。有些人非常看重它的好处，以至于他们愿意忍受它的缺点，但对于大多数域名持有者和大多数用户来说，情况并非如此，而且无论多少关于 DNSSEC 的热情劝告都无法改变这一点。在目前的形式下，我们可以帮自己一个忙，放弃 DNSSEC 并继续前进。但放弃保护命名空间的目标感觉不对。
我想我们应该问的问题是——如果我们想要一个安全的命名空间，我们应该在哪些方面改变 DNSSEC 的使用方式，以使其更简单、更快、更强大？
本站全部资讯来源于实验室原创、合作机构投稿及网友汇集投稿，仅代表个人观点，不作为任何依据，转载联系作者并注明出处：https://www.lvsky.net/335.html
评论