DNSSEC的选择:Yes还是No.pdf
《DNSSEC的选择:Yes还是No.pdf》由会员分享,可在线阅读,更多相关《DNSSEC的选择:Yes还是No.pdf(6页珍藏版)》请在咨信网上搜索。
1、2023.2-3 中国教育网络 47文/Geoff Huston互联网早期的特点是技术的不断更新。例如,路由协议接二连三地出现和消失,传输技术处于不断变化的状态,我们用来与新兴数字环境交互的设备正在变化,我们使用的应用程序也在变化。因此有些令人惊讶的是,至少有一个协议在互联网四十多年的发展中保持相对稳定,那就是域名系统(DNS)和相关的 DNS 解析协议。也许我们可以将传输协议UDP(用户数据报协议)和TCP(传输控制协议)也放入同一类协议中。在互联网协议中,它们肯定是最古老的协议之一,并且今天仍在大量使用。这是对这些协议基本设计的肯定,虽然网络和它的使用者已经增长了十亿倍甚至更多,但这些协议
2、基本上保持不变。通常引用的 DNS 规范是两个 RFC,RFC1034,“域名概念和设施”,以及 RFC1035,“域名实现和规范”,它们都发表于 1987 年 11 月。然而,这两个核心规范只是一个相当大规范集合的冰山一角。涉及 DNS 的 RFC 协议大概有292 个。这意味着声称 DNS 在这四十年期间基本不变有点牵强,但无论如何,DNS的基本原理是不变的。这些额外的 292 个RFC 说明了我们在这四十年中花了大量的时间和精力来修补DNS协议的边边角角!在 DNS 发生的这些变化中,我必须提名 DNS 安全框架域名系统安全扩展(DNSSEC)作为最重要的 DNS 创新。DNSSEC 将
3、数字签名添加到 DNS 资源记录,允许客户端解析程序确认 DNS 应答的真实性。你可能会认为,随着人们对互联网攻击的广泛认识,让用户验证从DNS查询收到的响应的任何行为都将被视为向前迈出的一大步,我们都会主动要求使用它。但现实是,人们对 DNSSEC 的热情并不高。递归 DNS 解析程序的管理员并不愿意添加解析步骤来请求 DNS 记录的数字签名并对其进行验证,同时在网络终端节点很少有 DNS 存根解析程序提供类似的功能。在签名侧,将 DNSSEC 签名添加到DNS 域的做法同样不受欢迎。准确计算互联网中所有域名的数量实际上是不可能的,因此精确计算有 DNSSEC 签名的域名百分比同样是一个具有
4、挑战性的问题。DNSSEC 社区一致认为,大约只有 10%的 DNS 域 名 是 经 过DNSSEC 签名的。人 们 为 什 么 对DNSSEC 的反应如此缺乏热情?DNSSEC 已经存在了足够长的时间,所以对 DNSSEC 的无知不能成为借口。那些不在自己的管理域上签名的域管理员肯定有自己的理由。对于是否启用 DNSSEC 签名和验证,似乎有很多不确定性。一些解析器运营商似乎已经接受了 DNSSEC,包括由 Google和 Cloudflare 运营的大型开放解析服务网络。另一方面,有许多解析器不执行DNSSEC 验证。APNIC 实验室对 DNSSEC验证率的测量表明,如果已签名的 DNS
5、名称的 DNSSEC 签名无法验证,大约 30%的用户将不会加载 URL(图 1)。那么,DNSSEC 是个好主意吗?或者仅仅是事倍功半的努力?为什么亚马逊和微软没有为域名部署 DNSSEC 协议?为什么美洲银行网站、汇丰银行网站没有为其网站域名添加 DNSSEC 签名?相关在线服务用户的安全性完全依赖于域名可验证的真实性,你可能会认为,能够验证域名到IP 地址的 DNS 映射将是保证其在线服务真实性不可避免的第一步。然而,许多域名并没有 DNSSEC 签名。我认为,没有一个明确的答案来回答这个问题,即,使用 DNSSEC 来签署域名是否是一个好主意。虽然 DNSSEC 提供了DNSSEC 的
6、选择:Yes 还是 No?图 1 DNSSEC 验证比例Geoff HustonAPNIC 首席科学家研究与发展互联网技术48中国教育网络 2023.2-3一个更有弹性和更可靠的 DNS 服务,让用户可以信任他们收到的 DNS 解析答案与当前域名权威域的内容完全匹配。但这是有代价的,在 DNS 域中添加 DNSSEC签名和在 DNS 响应中验证这些签名的增量成本是否值得,是一个需要讨论的问题。让我们从“是”与“否”两个方面来看看是否要对DNS域名进行DNSSEC签名。DNSSEC 值得吗?“不!”我们很容易将DNSSEC 看作是 DNS中的又一个错误设计。对于 DNS 域管理员,DNSSEC
7、又增加了一组域管理任务,包括添加密钥管理、定期密钥更新、密钥滚动以及与父域/委托域(parentzone/delegatedzones)的密钥协调。鉴于即使是简单的域委托或者域配置在大部分 DNS服务器中都会被错误配置,那么将加密密钥和数字签名管理元素添加到管理任务集中,只会增加那些选择 DNSSEC 对其域进行签名的人无意中出现域名故障的可能性。对全域进行签名是首先要考虑的一个问题。全域签名在较小的域中可能很简单,但对于较大的域,即使将整个域作为一个文本文件的快照映像进行签名也是一项巨大的挑战。许多较大的 DNS 域都会不断更新,而整个 DNS 域的签名操作要求对更新进行批处理(冻结已签名的
8、域内容,直到下一次计划的更新和签名操作)。这种操作实践可能不适用于具有大量客户端的大型 DNS 域,因为这些客户端对更改条目的及时性有不同的需求。许多 DNS域利用了动态签名的优势,该区域的 DNS服务器和 DNSSEC 签名前端分别运行,如果查询请求DNSSEC 凭据,则将响应从DNS 服务器传递到 DNSSEC 签名前端,并将数字签名记录作为最后步骤添加到 DNS响应中。NSEC 记录(NextSecureRecord,下一个安全记录)为 DNSSEC 添加了新的挑战。通常NSEC 响应会列出与名称相关的所有资源记录,包括请求域名记录不存在时,域中排列的下一个记录名称。NSEC 记录可以通
9、过负向查询(不存在的记录)对域中内容进行枚举攻击。这给某些 DNS 运营商带来了一些问题,他们出于商业或安全方面的原因希望将域内容保密。这个问题导致了 NSEC3 记录的开发,它使用基于散列值的域标签排序来避免枚举攻击,但散列函数增加的复杂性比实际情况好很多,因为在当前的计算能力下,破解这个散列函数是可行的。最近拟议的NSEC5 记录将增加更多的复杂性对抗区域枚举的脆弱性风险,但这一提议尚未引起广泛关注。还有一个问题,就是如何在 DNSSEC签名的区域保障服务的健壮性。传统的方法是使用许多与主服务器配置相同的方式运行的辅助服务器,它们可以通过共享当前DNS域配置文件的副本来实现这一点。在使用
10、DNSSEC 的条件下,共享主服务器已签名的 DNS 域文件的副本是最简单的方法,辅助服务器不需要知道该 DNS 域的区域签名密钥(ZSK)以及 DNS 域的密钥签名密钥(KSK)的私钥信息。但是,如果使用前端动态签名器,则所有这些签名前端都需要配置ZSK 私钥。如果所有这些域名记录签署都由同一个实体操作,那相对简单;但如果区域管理员使用不同的实体来操作辅助域名服务器系统,那么就需要将 ZSK 公钥集合放入域的 DNSKEY(DNSPublicKey,域名公钥)记录中。这样就会增加DNSKEY 记录的大小,而DNSSEC 响应记录大小是DNSSEC 的主要问题之一,大型 DNS 响应记录会影响
11、DNS 的可靠性和性能。最早的 UDP 协议上的 DNS 响应记录大小为 512 字节。添加 DNSSEC 数字签名会导致 DNS 响应大小超过此限制,因此DNS 查询程序需要使用 EDNS(DNS 扩展机制)扩展来表示它们处理大型 UDP 响应的能力。但是 DNSSEC 可能会导致响应记录超过 IP 报文最大传输单元(MTU)的限制(1420 字节的 IPv4 报文或 1400 字节负载的 IPv6 报文),从而需要使用 IP分片进行报文传输。但是 IP 分片会让请求者暴露于 DNS 缓存中毒攻击的风险,并且在 IPv6 协议下可能需要重传报文,导致更大的时间延迟。另一种方法是截断响应转为
12、TCP 协议传输。但是 TCP 协议需要花费多个传输往返时延(RTT)的时间来建立握手和传输数据,同时并不是所有的客户端都支持 TCP 协议下的 DNS,这会带来更大的不可靠性。然而,花费在处理大型 DNSSEC 响应报文上的额外时间并不是唯一的问题,DNSSEC 的验证功能也需要额外的时间。为了验证 DNSSEC 记录的真实性,客户端需要沿着签名链一直向上验证到根域的签名者,这意味一个 DNSSEC 记录的验证需要产生大量的 DNS 查询。如果不进行解析结果的缓存,则需要将每个父域的DNSKEY 和 DS(DelegationSigner,委托签名者)记录组合起来进行验证,这将带来无法克服的
13、时间损失。大多数终端系统不直接执行 DNSSEC 验证。他们依赖 DNS解析器来代表他们执行 DNSSEC 验证,并且默认信任(implicitlytrust)解析器以适当的完整性级别执行此操作。但这里带来的问题是,在终端主机和验证解析器之间的中间人攻击仍然可能有效终端主机没有验证 DNS 响应,因此无法检测响应是否为真实响应或是否已被篡改。以上所有问题都说明了DNSSEC 在设计或操作上并不简单。在错误发生的时候,要纠正的地方很多,而容错的地方很少。这增加了 DNS 的脆弱性。还有一个棘手的问题DNSSEC 保护你免受什么威胁?最初的教科书上的答案是保护解析器不受所谓的“卡明斯基攻击(Kam
14、inskyattack)”,这种攻击将恶意数据注入递归解析器的缓存中。研究与发展 互联网技术2023.2-3 中国教育网络 49DNSSEC 当然可以提供针对这种攻击的保护,但仅限于有限的情况下。正如我们已经观察到的,DNSSEC 可以保护递归解析器,但是不验证 DNSSEC 记录的客户端存根解析器仍然像以前一样容易受到攻击。因此,这不是一个全面解决问题的办法。如果 DNS 响应未能通过DNSSEC 验证,DNS 将不会通知客户端“正确”响应可能是什么。它只是保留无法验证的响应,并将其留给客户端决定下一步要做什么。DNSSEC 反应的成本是否与威胁的性质相称?从负面的角度来看,DNSSEC还不
15、成熟。它并非安全性和 DNS 功能的完美结合,而是一种相当笨拙的调整,以一种不舒服的方式放置在 DNS 之上。DNSSEC 的增量成本和脆弱性远远超过了从一个相当模糊的威胁模型中减轻风险的潜在好处。但 也 许 我 夸 大 了“不”的 理 由。DNSSEC 的采用对用户和整个互联网都有非常现实的潜在好处。让我们看看这个话题的另一面。DNSSEC 值得吗?“是的!”互联网安全的总体情况是相当糟糕的。当用户识别屏幕上的 URL,点击它,并相信呈现的网站是用户打算访问的真正服务,这中间的路径依赖于相当多的盲目信任。我们相信 DNS 将域名映射到的 IP地址是真实的,相信路由系统将 IP 数据包传递到“
16、正确的”终端,相信屏幕上的网站名字是你打算访问的服务,相信 TLS(安全传输层协议)连接是真实的,相信你从未见过的人永远不会撒谎,而这只是一大堆盲目信任中的几个例子。这些关系和行为中不透明的信任都是以诚信为基础的,无法被审计,也不能被曝光。我们只能希望每个人的行为都是出于最好的意图。但当我们把越来越多的个人和社会功能放在一个由计算机连接的世界里时,我们对互联网的完整性的依赖也越来越大,而无论是高级黑客、犯罪团伙,都具备颠覆互联网基础设施运行的能力,并可以造成相当大的破坏。那我们现有的强大的名称基础设施和 TLS 证书难道没有任何意义吗?在我看来,DNSSEC 存在的理由在于现有互联网名称基础设
17、施信任模式的弱点。现有的信任结构基于域名的 X.509 公钥证书,它试图在域名、域名持有人和公钥/私钥对之间建立联系。如果客户端使用域名作为 DNS 查询的关键字,并使用响应结果的 IP 地址连接到服务器,那么只要服务器能够证明它知道与这个域名相关的私钥,域名证书就能向客户端保证它已经到达域名持有人提供的与这个域名相关的服务站点。在这种形式的认证中,用于访问该服务的IP地址其实是不重要的。TLS 协议的安全握手过程向客户提供了服务的公钥、域名证书和用服务的私钥生成的“谜题”,向客户提供了它已到达真实服务的保证。客户端并不是简单地信任这些提供的信息,它也被预先配置了一组可信的证书颁发者(认证机构
18、)的公钥集合。只要客户端能够验证所提供的域名证书是由这些受信任的证书颁发者之一颁发的,那么它就能够相信服务站点的真实性,认为它“属于”这个域名。这里的问题是,实际情况比设想的要糟糕的多。每个客户端有数百个受信任的证书颁发者,每一个颁发者都能够为任何域名颁发数字证书。如果任何一个证书颁发者被入侵并颁发假证书,那么这些假证书与所有其他合法颁发的真证书之间是无法区分的。只要一个证书颁发者被包括在客户信任的颁发者集合中,那么客户就无条件地信任这个颁发者,并无条件地接受其颁发的所有证书是真的。因此,我们有一个“最薄弱环节”:域名持有者使用的证书颁发者的工作有多好并不重要。重要的是一组证书颁发者中最不可靠
19、的那一个的工作质量;只要有一个证书颁发者被破坏了,那么它就会被迫为任何域名颁发假证书。还有其他一些因素也破坏了对域名证书框架的信任。第一个因素是价格的侵蚀。人们一直在努力降低证书的价格,理由是为在线服务提供安全保障不应该是少数人可以获得的昂贵的奢侈品,而应该是普遍可以负担的商品。例如,LetsEncrypt 运营的自动门户提供的免费域名证书已经将这一点推向了极端。这些免费服务只需要申请人证明他们可以将指定记录添加到相关的域名区域文件中,或在域名的网站空间内生成一个 URL 页面。这些免费证书的合法性等同于任何其他域名证书,而入侵网站或者 DNS 域服务器修改文件就可以导致假域名证书的颁发。研究
20、与发展互联网技术50中国教育网络 2023.2-3第二个因素是,尽管证书撤销可以减轻假证书带来的风险,但证书撤销不再被普遍支持。在证书撤销过程中,证书颁发者会定期公布一个不应再被信任的证书序列号列表。当客户验证一个证书时,它应该查阅证书颁发机构(CA)的证书撤销列表(CRL),检索这个 CRL 并通过其签名验证其内容,然后在这个列表中查找该证书的序列号。如果在 CRL 中找不到它,说明该证书没有被撤销,或者更准确地说在 CRL 创建(一般是过去几天)时,它还没有被撤销。撤销证书的数量越多,CRL 就越大。对于一个大型 CA 来说,提供所有废止证书的完整列表似乎是一种过度的回答,特别在查询者只是
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- DNSSEC 选择 Yes 还是 No
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【自信****多点】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【自信****多点】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。