Group of Software Security In Progress

Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned From the Mirai-Dyn Incident?

作者:Aqsa Kashaf,Vyas Sekar,Yuvraj Agarwal

单位:Carnegie Mellon University

出处:IMC 2020

资料:Paper

1 摘要

现在许多的网站都依靠第三方提供服务,但是这些第三方服务会使得原网站面临网络攻击(如DDOS)、级联故障(如GlobalSign撤销错误)的共享风险。本文主要分析了三种关键基础设施——DNS、CDN和CA的证书撤销检查,它们的流行程度及造成的影响,通过分析这些基础设施之间的直接依赖和间接依赖关系同时比对在2016年和2020年快照之间的差异得出了以下四个结论:(1)Alexa排名前十万的网站中,89%的网站严重依赖第三方的DNS、CDN或CA提供商,如果这些服务商倒闭,这些网站可能遭遇严重的服务中断;(2)第三方服务使用集中,CDN、DNS、CA服务的前三大供应商可以影响前10万网站的50%-70%;(3)间接依赖将流行的CDN和DNS提供商的影响放大了25倍;(4)2016-2020部分第三方依赖性和集中度略有增加。

2 主要关注的问题

访问一个网站的过程

  1. 像Dyn攻击、GlobalSign吊销错误事件和亚马逊DNS DDOS攻击影响了大量的web服务,对那些采用了第三方服务的网站是否可能成为影响流行服务的致命弱点?
  2. 网站与第三方服务提供商之间是否存在隐藏的传递或间接依赖关系,即集中度和第三方依赖程度?
  3. Dyn事件发生后,网站是否作出了调整,又是如何调整他们的,他们是否减少了对第三方服务的依赖程度,他们是否使用了多个第三方服务对同一服务进行了冗余供应?

3 工作的主要内容

主要研究了三个基础设施服务:DNS、由CA进行的SSL证书撤销和CDN,分析了两种依赖关系:直接依赖(例如spotify直接使用Dyn作为它的DNS服务提供商)和间接依赖(例如academic.edu需要使用的CDN-MAX依赖于AWS的DNS)。

3.1 针对基础设施的安全事件

  1. Dyn事件

DNS供应商Dyn遭受到用Mirai僵尸网络发起的分布式拒绝服务攻击(DDOS),由于Amazon,Netflix,Twitter等都把Dyn作为他们的权威DNS提供商,导致上述网站在几个小时内无法访问【直接依赖】。

另外,由于CDN提供商Fastly也使用Dyn作为其权威命名服务器,因此那些本身没有使用Dyn但是使用了Fastly的网站也受到了影响【间接依赖】。

  1. GlobalSign证书撤销错误

由于GlobalSign错误的配置了其OSCP(在线证书撤销协议)将有效的证书标记为已撤销的证书,导致了Drop等多家知名网站的HTTPS无法访问,并且由于缓存时间的限制,这个错误一直持续影响甚至超过了一周。

  1. 针对DNS的DDOS攻击

2019年亚马逊的53号DNS服务线路遭受到持续八个小时的DDOS攻击,导致亚马逊的其他业务服务被中断,同时使用亚马逊服务的网站和服务提供商也收到了波及。

3.2 量化指标

$w={w1,w2,\dots,w_n}$表示一组网站的集合,$s={s1,s2,\dots,s_n}$表示这些网站使用的一组服务的集合,$p^s$表示对于提供诸如CDN、CA、DNS等服务$s$的所有提供者的集合。

  1. 第三方依赖 如果一个网站$w\in W$使用了其他实体所提供的服务,就认为这个网站具有第三方依赖。比如twitter(twitter.com)和spotify(spptify.com)都使用了第三方实体Dyn为其提供DNS服务。
  2. 直接依赖 如果一个网站$w\in W$使用了服务提供商$p\in p^{s1}$为其提供服务$s1$,就认为网站$w$对于服务提供商$p$具有直接依赖。比如在Dyn事件中,twitter.com对Dyn具有直接依赖,因为twitter.com将Dyn设置为权威解析服务器。同样的,$p’\in p^{s2}$在获取服务$s1$的时候同样有可能对$p$具有直接依赖,比如Fastly[^1]在2016年的时候也将Dyn作为其权威域名解析服务器。 [^1]:一个著名的CDN提供商
  3. 间接依赖 当一个网站$w\in W$或者$p\in p^{s1}$与另一个服务提供商$p’\in p^{s2}$存在直接依赖,而$p’$与另一个提供商$p’‘\in p^{s3}$在服务$s3$上存在直接依赖时,就认为$w$或者$p$与$p’‘$之间存在间接依赖关系。比如在2016年Dyn事件中,printerest.com使用了Fastly CDN,而Fastly CDN使用了Dyn的DNS服务,printerest.com对Dyn就构成了间接依赖关系。还比如Certum CA使用了MAXCDN,而后者使用了AWS的DNS服务器。
  4. 严重依赖 如果一个网站$w\in W$或者一个提供商$p\in p^{s1}$使用了第三方服务商$p’\in p^{s2}$提供的服务$s2$,当$p’$提供的服务$s2$不可用时,会造成$w$或者$p$的服务受到影响,就认为网站$w$或者提供商$p$对于$p’$提供的服务$w2$具有严重依赖。比如在Dyn事件中,twitter严重依赖Dyn提供的DNS服务。 相反如果一个网站$w\in W$或者服务提供商$p\in p^{s1}$对于服务$s2$具有多个提供商,那么它们对其中任何一个提供商就不具有严重依赖并且还保持一定的冗余。比如twitter.com除了Dyn的DNS服务器之外,后来还通过增加部署私人DNS服务器增加了冗余性。
  5. 一个服务提供商的集中性程度(浓度) 浓度指标与指定提供商所关联的直接依赖和间接依赖的网站数目有关。比如一个有100个网站与Dyn具有直接依赖关系,有50个网站与Dyn具有间接依赖关系,那么提供商Dyn的浓度就是150。用$D_w^p$表示对提供商$p\in p^{s1}$具有直接依赖的网站的集合,用$D_s^p$表示提供与供应商$p$具有直接依赖关系的服务$s\in S$的所有供应商的集合。对于一个服务提供商浓度的计算如下: $$ C_p=|f_c(D_w^p,D_s^p)|=\vert D_w^P\cup\bigcup^m{s=1}\bigcup_{k\in D^p_s}f_c(D^k_w,D^k_s\backslash{p})\vert $$ 作者使用了提供商$p$的直接依赖度和与$p$具有直接依赖关系的其他提供商的直接依赖度的并集来计算一个服务提供商的集中性程度。
  6. 服务提供商的影响 这项指标统计的是对一个服务提供商具有严重依赖的网站的数量。比如如果有100个网站使用Dyn,其中80个网站严重依赖Dyn,那么Dyn就对80个网站具有影响。令$E_w^P$表示严重依赖提供商$p\in p^{s1}$的站点的集合,$E_s^P$提供严重依赖$p$所提供的服务$s\in S$的所有提供商的集合。同样$f_i$是关于$E_w^P$和$E_s^P$的函数,只要给定了严重依赖$p$的站点的集合,就可以通过一下得公式计算出服务提供商的影响指数$I_p$: $$ I_p=|f_i(E_w^P,E_s^P)|=|E_w^P\cup\bigcup^m{s=1}\bigcup_{k\in E_s^p}f_i(E_w^k,E^k_s\backslash {p})| $$ 同样的,作者在这里使用了提供商$p$的直接依赖性和与$p$具有关键依赖的其他提供商的直接依赖性的并集来计算影响度。

3.3 具体测量研究方法:

3.3.1 DNS测量

之前的工作有两个方法判断一个网站是否使用了第三方的域名域名服务器:一是将TLDs(顶级域名)与域名服务器匹配,二是匹配域名解析服务器与网站之间的权威解析记录SOA是否匹配,但这种匹配模式效果并不好,因为许多情况下当一个网站使用第三方DNS时,这些网站的SOA也会指向第三方DNS提供商。另一方面,尽管TLD的匹配在大多数情况下都很有效,但是它忽略了提供者使用别名的情况,比如YouTube.com的DNS服务器其实是*.google.com。

提供了一种检测方法如下:

DNS检测方法

首先还是利用TLDs进行匹配,接下来对于其他的网站、DNS服务器如果他们支持HTTPS的话可以查看网站的SSL证书出现的证书主题代替名称SAN,SAN列表中出现的所有顶级域名也属于同一个逻辑实体。对于剩下的匹配对,再获取根域名服务器和网站的SOA记录,如果SOA和DNS服务器不属于同一个逻辑实体则证明网站使用了第三方的DNS提供商。最后检查一下网站所使用的DNS服务器的集中情况,如果规模较大就意味着可能有第三方提供者。

此外还需要进行冗余度量,即一个网站可能使用了不同DNS提供商,但这些提供商实际上是同一个逻辑实体具有相同的TLD或SOA RNAME,比如.alicdn.com和.alibabadns.com虽然顶级域名不同但是都属于阿里巴巴,这种情况下这两个DNS服务器也是属于同一个实体的,即没有冗余备份。

3.3.2 证书撤销信息

从网站的SSL证书中提取分发点CDP和OCSP服务器信息,以此对第三方的CA进行分类寻找其依赖关系。与DNS一样,一般情况下TLD匹配性能很好,但在某些情况下它过度匹配了某些第三方CA,比如Google私有信任服务TLD.pki.goog就不会匹配许多Google的网站比如youtube.com。为了解决这个问题就需要额外的引入SAN列表和SOA信息。方法如下所示,作者比较了CA地址下的SOA记录,如果SOA记录与网站的域名并不匹配,则说明该网站可能使用了两个不同的DNS权威解析服务器,以此认为网站使用了第三方的CA。

证书撤销消息

测量OCSP的装订(stapling)

启用OCSP装订会将证书的撤销状态固定在WEB服务器中,这样用户就不必联系OCSP服务器或是CDP就可以获取到所请求证书的撤销信息,从而消除它对CA的严重依赖。一个OSCP响应被证书所固定就意味着网站支持OCSP装订,从而可以判断网站对OCSP服务器的依赖程度。

3.3.3 CDN的测量

大多数的CDN使用CNAME(规范化名称)重定向CDN的资源,比如www.example.com可能指向custom1234.example-cdn-company.net,因此检测CDN的一种方法就是查看网站内部(网站所有)资源的CNAME重定向,并且把这种指向关系与CNAME-TO-CDN的映射相匹配。

另一种方法是观察每个内部资源的自治系统(AS)数量,并且把这些AS映射到常见的CDN上。在第一种方法中,实际检测的效果取决于CNAME-TO-CDN映射表的准确性,而第二种方法,检测效果取决于AS-TO-CDN映射表的准确性。作者选取了第一种方法。

基于CNAME的CDN检测

寻找内部资源

首先作者使用了phantomJS(headless browser,一种缺省头部的浏览器)获取并呈现网站的登录页面,并且记录了至少服务一个网页对象的所有主机名。想要识别内部资源,基准线就是再次使用TLD匹配,它可以可靠的识别一些内部资源,但是会有遗漏。比如如果yahoo.com从*.yimg.com加载一个图像,那么这个就是一个内部资源。为此还需要加入一些其他的启发式识别方法来找到那些内部资源。比如SSL证书中的主题名称列表(SAN)、公共后缀列表和SOA记录(如果资源和网站的SOA是不同的,则说明这个资源的外部资源)。

接下来使用dig命令查询网页所有内部资源的CNAME信息,并且利用事先得到的CNAME-TO-CDN映射表提取CDN。如果一个提供商标榜自己是CDN作者就把他当作是CDN。同时作者并不通过确定加载一个网站的网页所必须的资源来确定CDN的严重依赖,而不是看一个网站是否使用一个或者多个CDN来确定严重依赖关系。

识别第三方CDN

匹配网站的TLD与CDN所使用的CNAME是判断一个网站是否使用了第三方CDN的一个基准方法,它很好用但是可能会有误报。比如雅虎使用一个私有的CDN把*.yimg.com作为CNAME,这就可能造成假阳性。FACEBOOK的CDN使用了FACEBOOK的DNS作为它的SOA,Instagram使用了FACEBOOK私有CDN,它的SOA则是AWS的DNS,这种技术也会导致对第三方CDN的高估。

为此作者开发了一种使用TLD匹配但避免了一些极端情况的启发式方法,它使用了SAN列表和SOA信息。对于每一个(Website,CDN)对,我们能够从使用某个CDN的网站的内部资源中获取CNAME的信息,比如从Akamai拉回的资源其对应的CNAME就包含了*.akamaiedge.net的信息。对于每一个CNAME,首先要应用TLD匹配,然后使用SAN列表,最后检查CDN的CNAME所记录的SOA和站点的SOA是否匹配,若两者不同,就意味着这是两个独立的实体。

CDN的检测

作者声称抽取100个网站随机样本并手动建立他们的(Website,CDN)映射对,最终进行分类的准确是100%,而使用TLD和SOA匹配的准确率分别为97%和83%。

3.4 内部服务的依赖性

DNS、CDN、CA服务也是相互依赖的。比如CA的OCSP服务器、CDP和CDN都将使用DNS来进行IP解析,CA同时也有可能把OCSP服务器、CDP放在CDN上。对于CDN-DNS依赖性,如果一个DNS服务器的CNAME是一个制定的DNS服务器地址,就能够判断CDN所使用的DNS究竟是第三方还是私有的。对于CA-DNS依赖性,同样通过检查OCSP和CDL地址是否与DNS的地址相一致可以判断两者相互关系;对于CA-CDN依赖性,主要是对比OCSP和CDP的CNAME是否与CDN的地址一致。

3.5 目前工作的局限性

现在的观察方法依然存在一些局限性,可能会在一定程度上影响最终结果,表现在:

  • 只使用了单一有利位置点(vantage point),也就是说观察的节点不够全面,可能忽略了特定区域之间的依赖关系。比如亚洲的网站对亚洲的客户有不同的依赖结构,作者的研究结果可能会低估某些供应商的影响。
  • 没有物理环境与网络基础设置之间的依赖性考虑在内,比如物理托管、路由或容量。
  • 没有关注网络服务本身之间的一些依赖关系,比如网站加载的第三方小部件或是脚本。虽然这些部分也会带来一些影响,不过本文主要研究的是基础设施之间(DNS、CAs、CDN)的依赖关系。
  • 只分析了登录界面上的依赖关系。之所以这么做是因为之前有文章研究表示,那些需要从外部域名获取的资源87%在访问主页的时候就已经加载完毕,因此作者表示他们忽略了在内容结构中更深层体现的依赖关系。

4 直接依赖关系

作者通过分析直接依赖关系尝试解决最开始的三个问题:

  1. 第三方依赖关系的普遍程度;
  2. 观察网站与第三方提供商之间的浓度,识别互联网中的单点故障
  3. 比较2016年Dyn事件之后第三方依赖关系的变化

4.1 第三方依赖关系

  1. 不太流行的网站对第三方DNS的严重依赖程度更高。 排名前10万的网站中有89%使用第三方DNS,而排名前100的网站中只有49%使用第三方DNS,此外28%的网站严重依赖于排名前100的网站,而排名前10万的网站有85%严重依赖于排名前100的网站。 图2就显示,低排名网站的第三方严重依赖程度更高。这可能是因为不太受欢迎的网站负担不起私人基础设施的费用,同时还可以发现网站的冗余性随着受欢迎程度的增加而减少,即越受欢迎的网站越关注可用性。总的来说,只有很少的一部分网站有冗余,可能是因为使用多个提供商的配置十分关键,比如使用多个DNS提供商需要供应商的支持,因此目前只有有限的供应商提供或者支持冗余配置。

  2. 与2016年相比,2020年对DNS供应商的严重依赖性增加了4.7%。

表3显示,2016年对第三方DNS供应商具有严重依赖的排名前10万网站中有6%在2020年改用了私有DNS。另一方面,2016年使用私有DNS的网站中,有10.7%在2020年转向使用单一第三方DNS供应商(比如espn.com、flickr.com)。在这些快照之间冗余性大致保持一致。总体上讲,到2020年严重依赖程度增加了4.7%,但对于受欢迎的网站则减少了它们的关键性依赖。

  1. 在使用CDN的33.2%网站中,人气较高的网站对CDN的依赖性较低。 在使用CDNs的网站中,有85%(TOP 100K)和43%(TOP 100)严重依赖第三方CDN。

排名前10万的网站中只有33.2%使用CDNs。图3显示,使用CDNs的网站中有97.6%使用第三方CDN,对第三方的依赖程度增加。换句话说,在美国,那些不太受欢迎的网站可能无法负担建立私人CDN的费用。

此外,在样本集合中有85%的网站严重依赖第三方的CDN提供商,占据总数的28%。同时CDN的冗余度随着受欢迎程度的减少而减少,即在美国排名前100的网站比排名前十万的网站CDN的冗余程度更高。

  1. 相比于2016年,2020年CDNs的关键依赖性没有明显变化。

2016年TOP100K有28.4%使用了CDNs,到了2020年,这一数字上升到39.9%,有18.6%的网站开始使用CDN,有6.8%已经停止使用CDN,有0.5%的网站已经转向了单一的第三方CDN,没有一个转向私有CDN。此外1.1%的网站放弃了冗余配置,有1.6%采取了冗余配置。总体上讲,有1.6%的网站对于CDN关键依赖提升,有1.6%的网站提高了冗余性,因此关键依赖性总体没有明显的改变。

  1. 更受欢迎的网站对第三方CAs的依赖度稍低。

通过数据表明,TOP 100K的网站中有78%支持HTTPS,77%依赖第三方CA,60%严重依赖CA,图4显示了不同Rank段支持HTTPS的百分比,对于受欢迎的网站支持HTTPS的百分比有轻微的提高。这可能是因为受欢迎网站庞大的用户基础,更加关注用户的信任关系。相比于受欢迎的网站,那些不太受欢迎的网站使用第三方CAs的比例也较高(77%,前者是71%)。与DNS和CDN相比,对CAs的关键依赖(指对OCSP stapling的支持)在TOP 100K的网站中都很低,只有17%的网站支持,也就是说还有61%的网站对CAs具有关键依赖性。OCSP stapling的低支持率可能是由于浏览器和Web服务器(Apache、Nginx)之间的兼容性问题所引发的,同时OCSP本身还存在一些设计问题。

  1. 2020年网站对CAs的严重依赖性与2016年相比没有明显变化。

2016年TOP 100K网站中有46529家支持HTTPS,到2020年有69725家支持,有23196家网站放弃了HTTPS其中的5%是支持OCSP stapling的。另外在2020年,在之前不支持OCSP stapling的HTTPS网站中有9.9%启用了OCSP stapling。总的来说,在关键依赖方面,排名前十万的网站没有明显变化,然后在受欢迎的网站中,我们看到了对CAs关键依赖度的增加。

4.2 供应商集中程度

  1. 有4家(总共10000家)DNS供应商为50%的TOP 100K网站提供关键服务,2家(总共86家)CDN厂商为50%使用CDN单位网站提供关键服务,2家(总共59家)CA与50%支持HTTPS的网站存在关键依赖关系。

图5(a)表示了主要的第三方DNS提供商对排名前10万网站的集中程度和影响力表现,可以发现DNS生态系统高度集中,一家DNS(CloudFlare)就占据了总访问量的23%,排名前三的DNS供应商占据了排名前10万网站总访问量的40%。另一方面,根据网站受欢迎的程度不同,更加偏好的DNS供应商也有所区别,尽管CloudFlare为23%的TOP 100K网站提供了关键服务,但是对于TOP 100的网站他们更偏好Dyn,它们中有17%使用Dyn,但只有2%严重依赖。

除此之外,DNS的集中程度(C)和影响力(I)的差值实际反应了网站对于特定服务提供商的冗余表现。以CloudFlare为例,它的冗余程度只有1%(C-I=24%-23%),CloudFlare用户几乎没有冗余,这是因为它要求DNS流量必须要通过CloudFlare自己的网络路由以抵御DDOS和其他攻击,此种方法不允许网站域名使用其他的辅助DNS服务。与之相反,Dyn、NS1等则为消费者提供了更高程度的冗余配置。

图5(B)则显示了排名前10万网站的主要第三方CDN提供商。30%使用CDN的网站都是由CloudFront提供支持,前三大CDN厂商覆盖了56%使用CDN的网站,占TOP 100K中的18.6%。而在使用CDN的TOP 100K中,CloudFront覆盖了30%,Akamai只覆盖了18%,但在最受欢迎的网站(TOP 100)中,Akamai更占有主导地位。

同样的,CDN供应商的冗余度可以通过集中程度减去影响力得到,与Akamai或Fashtly的客户相比,使用CloudFront和CloudFlare的网站很有提供冗余性。同时由于使用多个CDN比不总是需要供应商的支持,因此和DNS相比,使用CDN的消费者往往具有更高的冗余度。

最后从图5(C)可以看出,CAs之间也存在显著的集中性,在TOP 100K中,有60%支持HTTPS的网站(46.25%)主要依赖于排名前三的CAs。DigiCert覆盖了TOP 100K支持HTTPS的32%,TOP100中的44%,因此它在所有受欢迎等级的网站中同样受欢迎。

  1. 2016年至2020年,DNS和CA供应商的集中程度有所提高,而CDN提供者的集中度有所下降。

2016年2705个DNS服务商服务了总网站中的80%,2020年这一数字变成了54,同样的2016年5家CA服务总体的80%,2020年变成了3家。CDN则恰好相反,2016年3家CDN厂商影响了前十万网站中的26%,而到2020年前三名影响了46.25%。

5 间接依赖关系

这一部分讨论服务之间的依赖关系,主要关注几点:

  1. 服务提供商之间是否也想网站之间一样存在关键依赖关系?
  2. 服务之间的关键性依赖是否会影响网站的第三方依赖性和提供商的集中程度?

5.1 CA->DNS依赖性

在59家CA当中,有27家(48.3%)使用第三方DNS提供商,在这27家CA中,有18家没有使用前三大的DNS服务商(Digicert、Let’s Encrypt和GlobalSign),因此这18家CA使用特定第三方的集中程度较低。

同时还发现有三家网站使用私有CA但是却使用了第三方的DNS服务,比如godaddy.com使用了私有CA Godaddy CA,但是CA却使用了Akamai作为DNS。

  1. 当我们考虑CA->DNS的依赖性时有72%的网站严重依赖于前三大DNS提供商,而对于Website->DNS这一数字只有40%。

2016年到2920年之间观察到的CAs的依赖程度是有所下降。在2020年观察的时候,有9个严重依赖第三方DNS的CAs(GeoTrust、Symantec等)已经转移到私有DNS,有一个CA(Trust Asia)由私有DNS转移到单个的第三方DNS供应商,此外还有两个本来是冗余供应的CA(Digicert、Internet2)转移到了单独的第三方DNS供应商。总体来说关键依赖度下降了8.6%,9个转移到私有DNS,3个转入到第三方DNS。

5.2 CA->CDN依赖性

在59个CAs中有24(40.6%)个使用CDNs,其中有21(35.6%)个只使用一家厂商的CDN服务。那些严重依赖CAs的网站中有73.8%使用了HTTP,Akamai和CloudFare是五个CA的主要CDN提供商。正是由于这种间接依赖关系,使得有32个网站尽管使用了私有的CA,还是具有第三方的依赖关系——它们间接使用了第三方的CDN,其中就包括了一些流行的网站比如microsoft.com、godaddy.com等。

  1. 当我们考虑CA->CDN的依赖性时有56%的网站使用了前三大CDN提供商,而对于Website->CDN这一数字只有18%。

图8已经表明了,当考量CA->CDN的依赖性时,CDN提供商的集中程度有所增加。

表8则表明在2016年到2020年期间,CAs对第三方CDN依赖程度总体没有发生大的变化。

5.3 CDN->DNS依赖性

在观察到的86个CDNs中,有31个(36%)使用了第三方DNS提供商,有15个(17.4%)严重依赖第三方,但这些严重依赖第三方DNS的CDNs并不是十分重要的提供商,因为在TOP100K的网站中只有1.5%在使用它们。 同时还发现有290个网站依赖于第三方,它们使用的是私有的CDN,而这些CDN使用了第三方的DNS提供商,这些网站包括twitter.com、airbnb.com等。

  1. 因为大多数的CDN提供商都使用私有的DNS服务器,因此在观测中几乎没有看到CDN对DNS依赖性的发生变化。

图9(a)和9(b)分表表示了在对排名前五的DNS提供商进行CDN->DNS依赖性测量时,DNS提供商集中性程度和影响力的变化。排名前五的提供商只有Fastly使用了第三方的DNS服务商Dyn。另一方面AWS DNS服务了16家CDNs,其中有7家是只使用AWS的,而在TOP 100K的网站中,这7家CDN提供商只服务了其中的2%。

在2016年作者有观察到47个不同的CDNs,在这47个不同的CDN中有12个(25.5%)使用了第三方DNS提供商,有8个(17%)是严重依赖第三方DNS的。在这8个CDNs中有2个(Netlify,Kinx CDN)在2020年使用了冗余配置,有1个(GoCache)已经转移到私有DNS,如表9所示。另外有一个本来是冗余配置的CDN(Zenedge)在2020年转到单一的第三方CDN。总得来讲,CDN对DNS的关键依赖性下降了4.25%。

6 总结

6.1 趋势

  • 服务间内部的严重依赖:基础服务供应商之间的严重依赖关系会进一步增加用户所面临到的风险。由于间接依赖关系的存在,使得每个网站的关键依赖关系数量增加。同时间接依赖放大了提供者的影响。
  • 对经验教训的吸收:在Dyn事件中直接受到影响的供应商已经有所调整,但是受到间接影响的供应商并没有做改进和加固。
  • 集中程度正在增加:单点故障带来的潜在影响也在增加。
  • 横跨部门间的流行

6.2 建议

  • 对于网站:需要在使用第三方服务时建立更多的弹性和冗余
  • 基础服务提供者:服务提供者应该支持和鼓励冗余配置