RPKI的DNS组件依赖性对系统弹性的影响

1413RPKI的幕后托马斯·赫拉瓦切克FraunhoferSITATHENE德国菲利普·杰特纳FraunhoferSITATHENE德国Donika Mirdita达姆施塔特工业大学FraunhoferSITATHENE德国哈亚·舒尔曼法兰克福歌德大学弗劳恩霍夫学院德国迈克尔·魏德纳达姆施塔特工业大学FraunhoferSITATHENE德国摘要使RPKI对故障和攻击具有弹性的最佳实践建议为发布点以及多个依赖方使用多个URL和证书。我们发现，这些建议已经支持63%的AS与RPKI。在这项工作中，我们将探讨其DNS组件上的RPKI部署的依赖性。我们发现RPKI的弹性可以通过DNS被颠覆。我们确定了两个关键因素。首先，我们发现，42.8%的AS与多个依赖方使用一个解析器查找RPKI发布点和82.9%的依赖方的DNS解析器都位于一个单一的AS。两者都引入了单点故障。其次，我们还发现DNSSEC部署存在问题：RPKI中超过24%的解析器遇到签名DNS响应失败，因此无法定位RPKI发布点，无法验证RPKI，60%支持DNSSEC的解析器不验证使用新算法签名的记录，接受无效签名的响应。我们的实验发现，对手可以禁用RPKI在56.7%的AS有脆弱的DNS组件。我们的模拟表明，禁用RPKI暴露AS前缀劫持攻击。 我们的工作表明，由于与其他系统的复杂的相互依赖关系，系统的弹性，如RPKI，不能孤立地实现。CCS概念• 安全和隐私→网络安全。关键词RPKI、BGP、DNS、DNSSEC、弹性ACM参考格式：TomasHlavacek，Philipp Jeitner，Donika Mirdita，Haya Shulman，andMichaelWaidner. 2022年。RPKI的幕后 在2022年ACMSIGSAC计算机和通信安全会议（CCS '22）的会议记录中，2022年11月7日至11日，美国加利福尼 亚 州 洛 杉 矶 。 ACM ， 纽 约 州 纽 约 市 ， 美 国 ， 14 页 。https://doi.org/10.1145/3548606.3560645允许免费制作本作品的全部或部分的数字或硬拷贝，以供个人或课堂使用，前提是制作或分发副本的目的不是为了盈利或商业利益，并且副本的第一页上有本声明和完整的引用。 本作品的版权归ACM以外的其他人所有，必须予以尊重。允许使用学分进行摘要以其他方式复制、重新发布、在服务器上发布或重新分发到列表中，需要事先获得特定许可和/或付费。请求权限请发邮件至permissions@acm.org。CCS©2022计算机协会ACM ISBN 978-1-4503-9450-5/22/11。. . 15美元https://doi.org/10.1145/3548606.35606451介绍边界网关协议BGP（Border Gateway Protocol）连接Internet上的网络，称为“自治系统”（AS）. 由于其中心作用，BGP经常成为前缀劫持攻击的目标[6，12，38，41，47，48，50]。 在前缀劫持期间，伪造的BGP公告声明属于另一个AS的IP地址。接受虚假BGP通告的AS将这些IP地址的流量发送到错误的目的地。为了防止劫持，互联网工程任务组（IETF）开发并标准化了资源公钥基础设施（RPKI）。RPKI认证BGP路由。 为了部署RPKI，AS需要将其公钥与IP前缀相关联[31]，然后验证其IP前缀并将其绑定到AS编号，从而创建路由源授权（ROA）。 ROA被加密签名并存储在RPKI发布点中。AS使用依赖方软件之一来检索和验证ROA。路由器从依赖方接 收 经 验 证 的ROA ， 并 执 行 路 由 源 验 证 （ Route OriginValidation，简称ROA）：根据它们接收到的BGP公告检查ROA，并过滤伪造的BGP公告。MySQL的输出可以是无效、有效或未知的。如果前缀的BGP公告与覆盖该前缀的ROA冲突，则该前缀的BGP公告将被丢弃使用路由器可以过滤具有无效起源的路由，从而阻止前缀劫持。逐步增加RPKI的采用。经过认证的网络前缀的数量正在逐渐增加[11，23，26，37，51]。与2017年6.5%的有效ROA相比，我们在2022年2月的测量发现，大约33.24%的IPv4地址空间被有效ROA覆盖类似地，强制执行代理的AS的数量也在增加。从2017年的600个AS [17]，我们在2022年 2月的测量中发现，强制执行AS的数量增加到1483个。RPKI的复原力 随着RPKI越来越多地被采用，使RPKI部署能够抵御攻击的意识也在不断提高。当前最佳操作规范（BCOP）1建议将依赖方放置在BGP路由器附近此外，应设立多个依赖方，以确保更好的复原力：即使某些依赖方的通信受阻或失败，只要有一个依赖方可用，仍然可以进行RPKI验证。 我们观察到AS越来越多地支持这些最佳实践，以避免攻击和单点故障。然而，尽管有最佳实践的支持，我们发现RPKI部署仍然无法抵御攻击。DNS是RPKI部署中的一个薄弱环节 在这项工作中，我们表明，DNS组件，依赖方在RPKI使用查找发布点，引入了一个薄弱环节，暴露1 https://www.manrs.org/isps/guide/CCSTomas Hlavacek、Philipp Jeitner、Donika Mirdita、Haya Shulman和MichaelWaidner1414····网络的拦截和拦截攻击，RPKI是弹性的。我们通过实验探索了RPKI部署中的核心问题以及它们使用的DNS组件，并发现了一些不同的问题：(1) DNS减少了运营商试图通过使用多个依赖方来实现的冗余。 我们发现，运营多个依赖方的AS中有63%使用来自单个AS的DNS解析器，而在具有多个依赖方的AS中，有42.8%的AS中，所有依赖方仅使用单个DNS解析器。(2) 依赖方使用的递归DNS解析程序不受DNSSEC保护首先，我们发现只有52%的依赖方使用验证DNSSEC的解析器。其次，我们发现52%中的60%使用易受攻击的DNSSEC配置。因此，攻击者可以发起缓存中毒攻击，以阻止依赖方定位发布点并检索RPKI验证所需的对象。对于24%的解析器遇到签名响应问题的AS来说，情况更糟：依赖方无法找到存储库。(3) 与位于BGP路由器附近的依赖方相比，57%的AS使用位于远程AS上的DNS解析器。这意味着依赖方中的存根解析器与递归解析器之间的通信将遍历远程网络。由于依赖方中的存根解析器不验证DNSSEC，并且默认情况下不受DoH/DoT2保护，因此存根和递归解析器之间的通信容易受到劫持攻击。(4) 最后，RPKI基础设施中的DNS组件通常位于ROA未覆盖前缀的网络上，这使它们容易被劫持：24%的RPKI依赖方的DNS解析器和10个根服务器以及50个发布点的我们的模拟表明，依赖于脆弱的DNS组件暴露RPKI部署的攻击。捐款. 我们确定的影响DNS的弹性RPKI。我们发现，虽然RPKI基础设施是弹性的攻击，它使用的DNS组件不是，并引入一个薄弱环节。 我们的研究结果不仅对RPKI有影响，而且对路径验证的建议也有影响，路径验证使用RPKI作为真理的来源来决定哪个AS有资格宣布特定的前缀。我们的技术贡献如下：RPKI和DNS的纵向测量 我们在RPKI部署中进行了DNS组件的第一次测量。我们解释了在RPKI中测量DNS组件的挑战，并开发了应对噪声的方法（例如，分组丢失）。我们提供两个测量点的结果，一个来自2021年4月，另一个于2021年9月收集。DNS组件上的DNSSEC 我们在RPKI中的DNS服务器上测量DNSSEC的弹性和正确性。支持BGP劫持的AS的RPKI攻击面我们进行模拟，估计分数的AS（在其中的可禁用的）容易前缀劫持。绘制RPKI生态系统。 我们展示了攻击者如何将RPKI生态系统与AS、其依赖方以及他们使用的DNS解析器进行映射。这使我们能够将易受攻击的DNS组件与依赖方以及使用2DoH/DoT是一个新软件，不能从分发储存库安装，默认情况下不会添加到依赖方。他们 因此，我们可以推断使用易受攻击的DNS组件的RPKI验证AS的范围。组织。 我们将我们的工作放在第2节中的相关工作的背景下，并在第3节中提供RPKI和相关组件的背景。我们在第4节中解释了我们的设置和实验-我们使用它们来收集数据，并在其余的工作中进行分析。在第5节中，我们开发了测量依赖方及其DNS解析器的方法，在第6节中，我们研究了解析器的DNSSEC验证 我们将易受攻击的DNS组件映射到依赖方，然后映射到AS，并在第7节中相应地评估易受攻击的AS的比例。在第8节中，我们提出了对策建议，并在第9节中得出结论。2相关工作DNS缓存中毒。缓存中毒攻击经常被用来将受害者重定向到错误的主机[13，44，46]，并且暴露于此类攻击的漏洞不断发展[14，15，22，27，33，34]。大多数缓存中毒攻击都是通过劫持受害者DNS服务器的BGP前缀来发起的。然而，只有大约11.5%的DNS服务器托管在受RPKI保护的网络上[9]。同样，我们发现RPKI部署中使用的大多数DNS组件都位于未受RPKI保护的网络上。DNSSEC验证。 DNSSEC验证可防止缓存中毒攻击。有大量的研究衡量DNSSEC的采用和实施在互联网上。 [32]在使用广告网络的Web客户端中测量DNSSEC。在他们的研究中，他们在Web客户端的浏览器中控制一个脚本，以触发对测量的递归解析器的查询。这允许他们控制查询（它们的时间和域），并在Web客户端和它使用的解析器之间进行关联。我们的研究在技术上更具挑战性，因为我们无法控制解析器的查询及其时间。 [10]在21个月的时间里，监控到达.com、.org、.net域名中的域名服务器的查询，以识别设置DO位并正确验证DNSSEC的解析器。同样，我们也监控到达我们的域名服务器的查询，但是，我们的重点是依赖方使用的DNS解析器，这些解析器无法通过跟踪顶级域名来捕获。最近[21]显示了DNSSEC降级攻击在签名域对验证解析器。签名DNS响应失败。DNSSEC部署被证明会增加DNS解析器中的查找失败[53]，而[16]注意到DNSSEC验证失败会增加对名称服务器的查询量我们还观察到RPKI使用的解析器中DNSSEC的故障。RPKI测量。ROA的部署在过去十年中显示出稳定增长[11，17，23，24，26，37，51]。同样，此外，在中国，也有越来越多的人加入到这一行列中来[40，43，45]。[29]从三个RPKI认证机构（AFRINIC，APNIC和他们自己的CA）收集数据，发现由于无法检索ROA，有时无法应用验证我们的测量结果证实，部署的ROA和ESTA的增加我们于2022年2月识别出约30%的IPv4前缀由ROA及3321个依赖方所涵盖。除了测量RPKI的部署，我们的工作是第一次研究RPKI和DNS部署中的各个组件，并开发技术来映射依赖关系RPKI的幕后CCS1415AS、它们的RPKI部署以及它们使用的DNS组件之间的关系。这使我们能够跟踪易受攻击的DNS组件到使用它们的AS，并评估它们对RPKI部署的弹性的影响。也有一些扩展前缀的建议，例如[25，36]，以处理错误并防止不同类型的前缀劫持。攻击，攻击。最近的一项研究确定了可被利用来导致依赖方验证器崩溃的可验证性，从而禁用验证器[35]。这项工作利用了在处理提供给依赖方的对象时存在的缺陷最近[24]开发了一种针对依赖方的低速率攻击，使用速率限制并使用无限嵌套委托优化了攻击。 我们使用类似的委托方法（将链限制为3），但目标不同-使依赖方及其解析器向我们的测量基础设施发送多个查询。与[24]相比，在我们的工作中，委托链扮演了次要角色-触发对我们的测量基础设施的多个查询。我们的方法的意义在于在区域文件中编码信息基础设施演进3RPKI概述RPKI的目标是提供一个认证的信息前缀所有权在互联网上，路由器可以使用它来作出路由决定在BGP。授权书。 RPKI将公钥与IP前缀相关联[31]。 在根处，区域互联网注册机构（RIR）将生成路由源授权（ROA）的权利授予拥有相应IP块的客户LIR（本地互联网注册机构）。ROA授权AS号码在BGP中通告这些 ROA存储在分层组织的发布点上托管的存储库中[RFC 6481]。发布点以托管模式操作，例如，由RIR或以委托模式由所有者AS来执行。使用依赖方软件进行验证。验证是通过依赖方实现来执行的，依赖方实现包含硬编码到RIR的根证书的。对象的检索通过RRDP或rsync协议执行。用于检索RPKI对象的两种协议都不安全，并且不对对象进行身份验证安全性依赖于X.509和清单，以确保存储库内容的完整性和完整性。出版点的翻译依赖方通过遍历五个RIR中的每一个的树，在每个刷新间隔期间周期性地获取RPKI对象。刷新间隔在依赖方实现中定义。在验证期间，依赖方联系它所知道的每一个TAL，并从它找到的每一个发布点下载RPKI对象。 依赖方有两种类型的数据缓存：rpki-cache包含从发布点（ROA，MFT，CRL等）下载的文件，ROA-cache包含经过验证的ROA。rpki缓存在下载时实时更新，ROA缓存在验证过程完成后更新。过滤器。 边界路由器通过RTR协议[RFC 8210]定期查询ROA缓存。路由器信任缓存，并使用缓存的对象来实施路由。边界路由器图1：RPKI流程与RIPE NCC Regional Internet Registry（RIR）和example.comLocal Internet Registry（LIR）。应该拒绝与ROA冲突的BGP公告，但接受无法获取ROA的公告RPKI中组件之间的交互。我们在图1中展示了部署RPKI并执行加密的网络中的组件以及它们之间的交互。在步骤（1）中，依赖方软件使用DNS解析器来查找硬编码TAL的地址，以定位所有5个RIR的发布点。DNS解析器向名称服务器（在图1的示例中，名称服务器位于RIPE NCC RIR的域中）发送查找请求，以获取发布点的IP地址（步骤2）。在步骤（3）中，依赖方通过RRDP或RSYNC连接到发布点，以获取RPKI对象（ROA、资源证书、清单、CRL等）。证书还可以将生成ROA的责任委托给另一个CA。在我们的示例中，LIR example.com使用委托的RPKI，在这种情况下，RIR的发布点仅包含将责任委托给LIR CA的证书，并且包含LIR发布点的主机名。因此，为了下载实际的ROA，依赖方必须查找LIR的发布点的IP地址（步骤4），这导致本地DNS解析器连接到相应的域名服务器以获取IP地址（步骤5）。然后，依赖方可以连接到LIR的发布点并下载ROA（步骤6）。最后，依赖方编制允许宣布这些IP前缀的IP前缀和AS的列表。边界路由器通过RTR协议从ROA缓存中检索该列表（步骤7）。该列表包含世界上任何网络的所有RPKI数据 BGP路由器使用RPKI数据来执行验证：验证它们从其他网络接收到的通知（步骤x）。如果步骤1-6中的任何一个失败，例如，由于良性故障或恶意攻击，依赖方回退到在最后更新周期中获取的高速缓存的ROA，只要这些ROA可用并且不过时。因此，在步骤（1-6）中完成的对连接的可用性的任何攻击可能导致从RPKI树检索ROA的失败，并且因此可以在接受BGP公告时改变受害者网络的行为。4实验在本节中，我们将开发用于测量依赖方及其使用的DNS解析器的设置和方法测量在实验中进行，每个实验都旨在研究DNS使用和DNS安全性的不同方面。在这RIRRIPE NCC名称服务器提到了其它连接网络路由器3XCA出版物点（PP）2出版物点（PP）6依赖缔约方（RP）7RTR路由器1,4CA解析器DNSLIR5名称受害者网络example.comserverBGPDNSCCSTomas Hlavacek、Philipp Jeitner、Donika Mirdita、Haya Shulman和MichaelWaidner1416≥····第二节我们解释了正确安排实验及其持续时间的挑战。我们将展示如何设置区域文件来测量递归解析器的DNSSEC验证行为。我们还开发了方法，以提高弹性的实验中存在的噪音或故障。在每个执行周期中，我们收集从我们的发布点检索RPKI对象的活动依赖方这是通过在我们的发布点监视传入的RRDP和rsync连接来完成的。我们通过监控到达我们的域名服务器的查询来收集DNS解析器我们分析来自解析器的查询和来自依赖方的连接，以了解RPKI部署的弹性4.1设置我们为研究互联网中的RPKI部署而建立的测量基础设施包括一个具有名称服务器的发布点和一个具有DNS解析器的依赖方委托发布点。 我们对AS的前缀进行认证，建立CA，并从RIPE NCC RIR获得RPKI证书形式的委托。该证书发布在我们RIR的RPKI发布点。委托包含发布点的URL和CA密钥指纹。 我们获得了RRDP和rsync [RFC 6492]协议的PKI证书。我们的设置确保所有正确操作的依赖方通过RRDP或rsync协议联系我们的发布服务器，以下载RPKI对象，用于RIR委托给我们的CA并因此委托给我们的发布服务器的资源。 为了找到我们的发布点，依赖方使用他们的解析器，该解析器查询我们的名称服务器来查找发布点。我们使用此设置来测量依赖方及其DNS解析器。依赖方。我们设置了一个依赖方来从RPKI发布点获取对象，并设置了一个DNS解析器来查找他们起来。4.2时间安排和持续时间由于[RFC 8183][4]中的要求限制每个支持LIR的RPKI只能发布rsync，RRDP和[RFC 8181]发布服务URL的3个URI，这相当于发布服务器的单个实例，因此实验是顺序执行的，而不是并行执行的。我们分析了每个实验应该跨越的时间间隔如果时间间隔太短，我们可能会错过一些尚未达到其刷新间隔的依赖方，这将导致低估依赖方的数量。我们在我们的网络上的实验室设置中安装了所有已知的依赖方软件包：Ripinator 3000，FORT，RIPRPKI，RIPE NCC RPKI验证器，Cloudflare RRDP。我们利用这些装置来建立它们检索行为的指纹。我们分析了检索间隔，缓存管理算法和频率，不同的软件刷新缓存通过联系发布服务器。表2列出了我们对不同流行软件的研究结果。使用我们的分析，我们计算的最大实验所需的时间来捕获所有活跃的依赖方。 我们发现两个连续查询之间的时间的第95百分位数是4。31小时为了确保我们在每个活动期间捕获所有活动的依赖方，在实验执行中，我们将持续时间设置为该时间段的3倍，并使用额外的1。5安全系数这导致24小时的实验4.3配置我们用DNSSEC的设置来增强我们的实验 为了评估递归解析器的DNSSEC验证行为，我们创建了多个区域文件，每个区域文件都具有不同的DNSSEC配置和算法，以执行以下实验：好的DNSSEC。 DNSSEC配置正确，所有记录签名正确，DNSKEY记录和签名有效，DNS解析器可以建立从信任锚到各个资源记录的信任链。DNSSEC错误我们打破了DNSSEC的信任链，通过改变我们的域的密钥签名密钥（KSK）的DNSKEY记录，而不更新父DS记录。DNSSEC验证解析程序应在来自此区域文件的响应上返回SERVFAIL。新的DNSSEC。我们创建使用新算法ed448（编号16，来自指定的DNSSEC算法3）签名的DNSSEC记录。ed448目前仅由PowerDNS 4.6.0支持，OpenDNS和Comodo安全DNS。没有DNSSEC。 此区域文件未签名，父域不提供DS记录。我们首先应用“无DNSSEC”实验。 这提供了依赖方使用的递归解析器数量的基准。随后，我们通过正确签名我们的域来运行“良好DNSSEC”实验然后，我们评估“坏DNSSEC”实验。最后，我们运行“新DNSSEC”。为了确保之前实验中缓存的记录不会影响后续实验的结果，我们将区域文件中记录的TTL设置为0。这使我们能够避免缓存。我们还验证了解析器不限制最小TTL值。我们比较了两个时间点（2021年4月和2021年9月）对该系列实验的评估数据我们在表1中列出了这两个数据样本的详细信息。具体实验的名称出现在最左边的一列，然后是实验的时间框架（2小时过渡期）和10天基线，联系我们发布点的活跃依赖方（RP）的数量，以及相邻实验之间的差异。 这些数字表示在两个单独的24小时内联系我们的发布点的依赖方（前3行），然后是基线测量，以评估变化是否具有统计学意义（后3行）。表1中具有Δ值的两列表示从先前相邻状态测量的增加或减少，其是在不同实验的区域文件配置之间的整个过渡期间连接到我们的发布点的依赖方之间的差异。例如，在执行2中，从“良好DNSSEC”到“无DNSSEC”示出了连接依赖方的+46增加，其对应于2.3%的增加。从“No DNSSEC”到“Bad DNSSEC”显示，与我们的发布点连接的依赖方增加了-1085，连接减少了约53.1%。3https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtmlRPKI的幕后CCS1417≥·实验执行1结果ΔExecution 2结果Δ|ex1-ex2|无DNSSEC2021-07-1316：30 + 24小时2011+199（+10.9%）2021-09-2021：30 + 24小时2042+46（+2.3%）+31（+1.5%）良好的DNSSEC2021-04-2816：00 + 24小时1812-2021-09-1920：22 + 24小时1996-+184（+10.1%）错误的DNSSEC2021-04-2916：00 + 24小时876-936（-51.7%）2021-09-2121：30 + 24小时957-1085（-53.1%）+81（+9.2%）绝对基线2021-05-2512：00 + 10天-= 1834。2= 28。92021-09-0821：30 + 10天-= 2008年。7= 30。0-成对日变化2021-05-2512：00 + 10天-= 25。6人（1.4%）= 24。72021-09-0821：30 + 10天-= 32。4人（1.6%）= 22。4-成对日唯一IP2021-05-2512：00 + 10天-= 70。8人（3.9%）= 23。82021-09-0821：30 + 10天-= 71。2人（3.5%）= 23。2-表1：2021年4月和9月从执行中收集的依赖方100806040200表2：请求之间的测量时间（中位数）。绝对基线是每天聚集的活动依赖方的IP地址的绝对数量;成对日变化比较间隔中每两个连续日的差的绝对值，并且成对唯一IP地址是间隔中每一连续对日的一天活动而另一天不活动的“无DNSSEC”实验中的绝对数量 从实验之间进行的测量，我们发现，这是由自然增长的积极依赖方的数量。事实上，在我们第一次和最后一次测量之间的这段时间里，发生了几次以推广RPKI4为重点的活动，这增加了对建立依赖方的兴趣。比较两个实验之间的依赖方IP地址集，我们得到以下波动数字良好DNSSEC：-185/+368（-10%/+20%）无DNSSEC：-148/+219（-7%/+10%）错误DNSSEC：-178/+385（-20%/+33%）我们所看到的是，所有组中的大多数依赖方都不会改变，但对于Bad DNSSEC，依赖方的集合也会出现有意义的波动为了确保小的差异不是影响依赖方的随机过程的产物，我们在多天内进行基线测试，并监控每天依赖方的数量（如表1所示）。每天的平均波动为25.6，因此小的变化主要是由于随机事件。然而，主要的结果，即， 坏的DNSSEC和好的DNSSEC之间的变化远远超过这个阈值。4RIPE82 https://ripe82.ripe.net/和MANRS RPKI Week https://www.manrs。org/resources/upcoming-events/rpki-week/2019 - 09 - 15 00：00：00 00：00 00：00 00：00：00 00：00：00图2：10分钟间隔内对名称服务器和发布点（KRILL）连接的A类查询4.4处决在本节中，我们将解释区域文件配置之间的转换对流量模式的影响在随后的第5节和第6节中，我们使用此流量来了解递归解析器的验证行为和弹性。图 3 显 示 了 “No DNSSEC” 、 “Good DNSSEC” 和 “BadDNSSEC”的区域文件配置对流量模式的影响。没有DNSSEC 在这个实验中，我们收集了所有活动的依赖方及其递归解析器。在图2中，我们绘制了对名称服务器的A资源记录的查询，以及通过RRDP或rsync到发布点（KRILL）的连接，时间为10分钟。我们的数据表明，查询是均匀分布的，没有模式可以观察到在正常操作。此外，我们域名的域名服务器的流量与发布点（KRILL）的连接量相对应。这与依赖方在连接之前使用DNS解析器查找发布点的IP地址的事实相一致好的DNSSEC 在这个实验中，由于对DNSSEC记录（密钥，签名等）的请求，对我们的名称服务器的查询数量显着增加。 以及由于某些解析器接收签名响应的失败，这增加了重传。我们在图6中绘制了查询到我们的名称服务器的模式，它捕获了“良好DNSSEC”，“无DNSSEC”和“不良DNSSEC”之间的转换。尽管我们的名称服务器的查询率更高，但到发布点的连接量略有下降，请参见图5。（b）.DNSSEC错误 当将区域文件的配置从正确部署的DNSSEC更改为缺少密钥的配置时，我们看到对名称服务器的查询进一步增加，并且执行严格DNSSEC验证的解析器的发布点减少。增加的查询一磷虾要求/秒··依赖方软件数量实例测量中位数预计值Cloudflare-RRDP-RPKIRIPE NCC RPKIValidator验证器堡未知（RRDP）RSYNC20025811505619591465.0158.0686.53834.53600.03599.012001206003600--CCSTomas Hlavacek、Philipp Jeitner、Donika Mirdita、Haya Shulman和MichaelWaidner1418解析器14Nameserver3解析器2Nameserver3servfail解析器24Nameserver3损失其次，AS使用多个依赖方，并且每个依赖方通常使用多个DNS解析器。在我们的研究中，为了能够得出有关RPKI基础设施弹性的结论，我们需要隔离底层组件并将其关联到1 1 4 1N56他们之间，也就是说，解析器到依赖方和依赖方到AS。依赖党(a) 无DNSSEC出版物点依赖党(b) 错误的DNSSEC出版物点依赖党(d)良好的DNSSEC出版物点为了消除噪声并准确地隔离RPKI生态系统中的组件，我们开发了一种新的增强方法，图3：（a）“No DNSSEC”、（b）“Bad DNSSEC”和（c）“Good DNSSEC”的消息交换是 由 解 析 器 的 重 传 引 起 的 ： 无 法 验 证 记 录 的 解 析 器 返 回SERVFAIL错误，这导致存根解析器在超时后拒绝查询在图4中，我们绘制了在名称服务器和发布点捕获的从“良好DNSSEC”到“不良DNSSEC”的转换 图4.（a）绘制到我们的名称服务器（A，DNSKEY）和我们的发布点（KRILL）的流量。 在过渡到“Bad DNSSEC”的开始（4月29日），DNSKEY查询大幅增加，A记录查询的增加略高，正如预期的那样，我们监控到我们发布点的连接减少。 在图4中。（b）我们更详细地绘制了与KRILL的连接 ， 区 分 了 不 同 的 原 型 （ rsync 和 RRDP ） 。 转 换 到 “BadDNSSEC”会影响两个协议，因为这两个协议的连接都会减少图4.（c）也显示了与我们的发布点的连接相应减少。与“良好的DNSSEC”类似，在从“ 无DNSSEC” 过渡到“ 不良DNSSEC”之后，到我们发布点的连接量会减少，如图5所示。（c）及5.（一）.4.5我们在实验中面临的主要挑战之一是我们无法控制依赖方的基础设施。在传统的测量中，例如，在开放式解析器中，测量基础设施对所研究的目标网络具有控制。具体地，测量基础设施控制查询的定时以及查询的域，并且可以使目标网络向测量服务器发出查询。这是通过将查询直接发送到开放解析器或通过可以通过系统上的存根解析器触发查询的脚本来完成的。 在我们对依赖方的测量中，我们不能触发对我们的测量基础设施的查询，我们既不能控制查询的时间，也不能控制查询中的域。数据包是在刷新间隔期间发送的，这是特定于每个设置和实现的，我们只能被动地监视到达测量基础设施的数据包4.5.1跨栏。 缺乏对目标网络的控制给精确测量带来了许多障碍。首先，在故障的情况下，我们不能导致依赖方或其使用的DNS组件发送后续数据包。这使我们无法探索失败的原因因此，我们无法区分故障，例如，由于分组丢失或连接失败、协议特定问题，例如，DNSSEC的失败 在这两种情况下，我们的测量基础设施都没有接收数据包，但是，根本原因是不同的。RPKI中度量的弹性4.5.2嵌套的委托链。我们的想法是创建一个复杂的RPKI发布点委托链，使依赖方及其DNS解析器向我们的测量基础设施发出多个查询创建嵌套委托。我们的CA的证书指示可以在哪里找到发布点。发布点还包含指向委托链中下一个发布点的证书。这些证书还可以包含指向下一级发布点的证书，依此类推。因此，每个发布点指向一个或多个子发布点，每个子发布点也指向一个或多个子发布点。RPKI验证要求依赖方从所有发布点收集完整的RPKI信息，这确保了所有依赖方都会遍历我们的所有授权级别。在验证期间，依赖方发送NS、A和AAAA查询，以查找发布点所在域中的名称服务器和发布点本身。 每个连接是每个发布点1个TCP连接，每个发布点至少5个（取决于DNS软件）DNS请求。 我们在表3中总结了依赖方实现的限制。可以看出，依赖方实现限制每个委托链的长度（到12或到32），但不限制宽度（即，每个代表团级别的儿童人数）。 这允许我们创建一个设置来触发任意数量的查询，以确保我们覆盖依赖方使用的所有解析器。一个例外是RPKI客户端依赖方，它将每个信任锚节点（TAL）的长度限制为12，宽度限制为1000需要多少代表团 给定32个限制，我们可以在一条链上创建最多32个发布点。每个级别的宽度不受限制，因此我们也可以在每个委托级别上创建任意数量的孩子。 我们的测量表明，分叉两个子树足以覆盖所有的解析器使用的依赖方在任何AS。我们从根创建了两个子树，每个子树有32层深，总共有62个委托发布点：第一层是根（RIR），它指向第二层的发布点然后我们在第三层创建两个子节点，每个子节点有30个节点深。这总共导致62个节点。在每个级别上，DNS解析器对依赖方软件深度宽度#DNS请求Cloudflare-RRDP-云计算RPKI32-∞∞∞2∞KRIPE NCC RPKI验证器--消泡器32-堡32-RPKI-client121000/TAL表3：RP和数据包容量的限制RPKI的幕后CCS1419RRDPrsync→3000250020001500100050002019 - 04 - 29 06：0004 - 2918：0004/3006：006005004003002001000605040302010时间（GMT）时间（GMT）图4：“好的DNSSEC”“坏的DNSSEC”：（a）A和DNSKEY查询与发布点流量（KRILL）。（b）过渡期间的RRDP和rsync(c)实验期间的请求量和主机活动80060600404002002000时间（GMT）时间（GMT）时间（GMT）图5：（a）RRDP和rsync查询在“无DNSSEC”→“坏DNSSEC”。（b）在“良好DNSSEC”→“无DNSSEC”期间连接到我们的发布点（d）在“No DNSSEC”→“Bad DNSSEC”期间连接到我们的发布点60005000400030002000100009-20 0009-20 1209-21 002009 -211209-22 002009 -2212我们用于实验的资源（IP分配，IP）被分配给我们的组织，我们在IRR公布行政和技术联系人，以便任何人在出现问题时与我们联系，以便我们能够立即做出响应并采取纠正措施。图6：A和DNSKEY在服务器上的配置（a）良好的dnssec，（b）没有dnssec，（c）坏的dnssec。相应的出版物。我们假设在最坏的情况下，在委托链的每个节点上，依赖方使用单个解析器来查找所有需要的材料。如果查询在多个解析器之间拆分，则在每个委托节点处，我们可以覆盖更多的解析器。因此，有32个节点，我们可以覆盖32个解析器，当我们创建两个子节点并从中派生两个链时，我们可以覆盖62个解析器。由于子节点的数量可以是任意的，我们总是可以扩展子节点的数量以覆盖更多的解析器。限制道德衡量的授权 虽然32的delegation链不足以进行攻击，但它可以减慢连接依赖方的速度[24]。因此，在我们的评估中，我们将我们在互联网上发布的委托链限制为3级委托。这不会使任何部署的依赖方过载，同时确保我们捕获故障并识别特定的通信丢失。要衡量具有大量解析程序的依赖方，三个授权级别可能不够。因此，我们用纵向数据收集来补充我们的短委托链：我们在一年的时间内重复了这个实验这使我们能够收集活动依赖方使用的所有解析程序伦理上的考虑。为了避免我们的实验对RPKI基础设施的潜在性能或安全性影响，我们设置了对基础设施的监控，如果检测到负载或故障，我们就使用它来停止实验5RPKI中DNS解析器的弹性实施DNS解析的AS的数量不断增加。在2022年1月，我们发现1483个依赖方使用了3321个依赖方（主要是顶级）AS来执行代理。这些大型AS互连多个网络，因此在互联网中发挥着核心作用因此，深入了解RPKI基础设施中的依赖方及其对DNS的使用越来越重要。在本节中，我们测量了依赖方之间DNS解析器的使用情况，发现它在许多网络中没有弹性我们将讨论用于阻止DNS查找的攻击向量最后，为了了解受影响的AS的比例，我们将AS链接到它们使用的依赖方，然后将依赖方链接到解析器。5.1依赖方2021年9月，在“无DNSSEC”实验中（表1），我们监测到2042个依赖方，比4月增加了31个依赖方。类似地，我们看到在“良好DNSSEC”实验期间联系我们的发布点的依赖方增加了184个（表1）。在从“好DNSSEC”到“坏DNSSEC”的过渡期间，我们观察到，在9月份，更多的依赖方使用非验证DNSSEC解析器，因为9月份有957个连接到我们的发布点，而4月份只有876个。我们发现，大多数新添加的依赖方不使用DNSSEC验证解析器。在这两个示例中，我们观察到，在我们的认证点上，不使用DNSSEC时的依赖方比使用DNSSEC正确签署我们的发布点的域时的依赖方多46个 这种增加用Δ表示，Δ是行之间的差，一个DNSKEYKRILLRRDPrsync要求/分钟RRDP请求/分钟RRDP请求/分钟rsync请求数/小时rsync请求数/小时RP IP地址RP IP地址RP IP地址CCSTomas Hlavacek、Philipp Jeitner、Donika Mirdita、Haya Shulman和MichaelWaidner1420不同ASes45%相同解析器19%相同ASes36%每个AS解析器AS的RP分解器放置图7：每个AS的依赖方（RP）使用的解析器上方和当前行，例如，2042-1996年=46人，执行2。这表明一些DNS解析器仍然遇到DNSSEC问题;请参阅第6.1节中的详细信息。尽管如此，在9月份的“良好DNSSEC”期间，依赖方的数量比去年同期有了更显著的增长。4月份“良好DNSSEC”期间的依赖方数量，比9月份“无DNSSEC”期间的依赖方数量的增加要多，4月（184 对31 ）。这表明，在9 月份，一小