【杂谈】jsDelivr域名遭到DNS污染

发布于 / 日常杂谈 / 38 条评论

在jsDelivr被吊销ICP许可证四个月后的4月28日,cdn.jsdelivr.net开始遭到污染,这一个赫赫有名的静态资源库面向中国大陆的服务最终倒在了政策和监管双重压力之下。

结束了三月的研究生复试,四月的博主更多是投身在荒废的大四生活和毕业论文撰写之中。很长时间没有更新博客了。恰好今天看到jsDelivr出现了如此严重的意外,就来简单聊聊jsDelivr的大陆服务是如何走向终点的,顺便给出一些博主建议的解决方案。


零、写在前面

虽然从四个月前那次宕机失去中国大陆CDN开始,很大一部分网站已经陆陆续续将静态资源切出jsDelivr,但是碍于jsDelivr多年的深耕以及服务的独特性,仍有不少场景下引用有jsDelivr的链接。不同于以往的短时间宕机,这次的“污染”几近于死刑,意味着cdn.jsdelivr.net在中国大陆服务的彻底终结,从此这个网站将不再是慢,而是不可及。

*再次提醒:建议各位站长细致检查个人站点前端主题、插件、脚本等内容中对jsDelivr的引用,以避免由于jsDelivr不可及导致的加载卡顿和前端无法正常加载的情况。


Update 2022.04.29

污染已解除,文章内容仅供参考,应该是当局发现影响范围实在太大了吧~

Update 2022.05.17

再次被污染,并且增加了伴随的sni阻断,hosts不再有效。二进宫实惨,尽快着手转移吧。


壹、jsDelivr的命运

2022年4月28日,jsDelivr得到了与Facebook、Twitter等如出一辙的安排,主要的服务域名遭到DNS污染。在正常状态下,当你请求网站域名域名时,你的DNS服务器会逐级向上寻找这个域名的解析记录,并通过这个链条将它指向的服务器返回给你,实现域名与服务器的融合。若你的DNS逐级向上请求记录的过程中,出现了一个中间人提前抢答了错误的记录,而非来自域名权威服务器的正确回复,导致返回的结果并不是指向正确服务器的,连接因此不能建立,这便是DNS污染。其中的原因,还是要从一开始说起。

惊艳四座的jsDelivr

不知道提到jsDelivr,大家都是从哪一项服务开始接触到它的?由中国最大的传统CDN提供商网宿(QUANTIL)赞助,支持cdnjsGitHub内容直接加速引用,它的应用可以说是迄今为止所有静态库中最为广泛的了。大到各种门户网站,小到个人博客,乃至去广告规则订阅、图床、插件静态库等等种种衍生场景,都能见到它的身影。

在网宿的协助下,2016年12月jsDelivr挂名在上海幻文信息科技有限公司下完成了企业ICP备案,取得了备案号【沪ICP备15005128号-2】。这是一家网宿用于代理备案的公司,通过天眼查等工具很容易看出来,历史上共有8个网站在这个公司挂名进行备案,目前除了所谓的主页已全部注销。

这是历史上第一个以较为正规的方式进入中国大陆的海外静态资源库项目,在网宿与诸多海外赞助商协同下,5年中jsDelivr提供了非常稳定且出色的服务。jsDelivr官方毫不掩饰对自己能够在中国大陆合法提供服务的喜悦,专门在节点页面中写下了“我们拥有中国政府的ICP许可证,拥有数百个服务节点的巨大中国网络”的字眼。

然而千里之堤溃于蚁穴,纵使拥有网宿这样强有力的支撑,也难抵运营以来遇到的重重阻碍。

一波三折的大陆服务

在网宿负责中国大陆的CDN节点这几年中,因为网宿方面的问题导致了几次SSL证书过期而宕机,博主有印象的在2019、2020年都有出现过。如果说那些都是网宿单方面的失误的话,2019年10月的暂时退出是jsDelivr官方面临的第一次危机。2018年工信部对域名备案政策颁布了新的规定,只有注册局在中国大陆拥有代理公司并完成申报、且域名停放在在中国大陆注册商的情况下才可以进行备案。jsDelivr挂名的公司在2019年需要进行了负责人信息的变更,备案主体信息需要进行修改,这在多个域名中都可以查到记录。

当时,jsDelivr暂时关闭了中国大陆的节点,转而使用网宿位于中国台湾和韩国首尔的节点提供服务,加载速度一落千丈。当时博主还向官方发送了一封邮件进行了咨询,官方也亲切地回应是在更新ICP备案,将在不久之后恢复。较早的issue中,官方人员进行了更详细的解释,他们在更新ICP备案的过程中遇到新规的要求将备案域名转入至中国大陆的服务商的问题,在评估后他们认为没有一种安全的方式能够确保在服务不中断的前提下将域名转移至中国大陆,因此暂时关闭中国大陆的节点等待进一步的探讨。最终在一个月后,jsDelivr恢复了位于中国大陆的节点,这次风波算是告一段落。

接下来的三年中大体相安无事,除了几乎每年一度的网宿忘记更新SSL证书。但是由于支持对GitHub项目的完整加速,对jsDelivr的滥用日趋严重,GitHub+jsDelivr图床、视频床甚至网盘层出不穷。如果说以上只是对免费资源的滥用,在GitHub中储存成人、邪教等文件通过jsDelivr向中国大陆分发,则是将jsDelivr一步步推向万丈深渊。

在2020年的8月15日,jsDelivr在官方GitHub项目中首次更新了使用限制说明(点击前往),我截取了其中较为重要的一部分,这是官方第一次明确表示禁止多种滥用行为并添加了对中国大陆政策的额外说明。在这之后,官方在网宿方向屏蔽了一系列不符合中国大陆法律内容的项目。但是由于是针对整个GitHub项目的通用加速,官方的封禁显然远远比不过肆意滥用的脚步。

命中注定的结局

jsDelivr对中国大陆的态度一直颇为暧昧,在2019年风波平息后,有不少人提议针对中国大陆的服务中GitHub加速项目应当审核开放或关闭此项以防止滥用,但官方认为将项目推送cdnjs也是很容易的事,单单禁用GitHub并不能解决不合理利用的问题,于是便没有了后文。

于是在2021年12月20日,当项目组成员在另一个半球睡得正香的时候,自上而下的命令压力下网宿直接关闭了jsDelivr的大陆CDN,几个小时后jsDelivr的ICP备案也被注销。当jsDelivr项目工作人员起来时,一脸茫然地发现网宿在未告知原因的情况下关闭了中国大陆的CDN,在愤怒之余将DNS记录切换至了Fastly恢复了jsDelivr的访问,这次的风波暂时告一段落。

但是网宿这次为何突然关闭CDN的原因依然众说纷纭,有内部人士称是因为网安部门发现了通过jsDelivr的链接传播邪教内容,但这些无从考证,官方自始至终也未对此给出任何解释。但无法改变的是,jsDelivr失去了ICP许可证,不再拥有位于中国大陆的CDN节点,加载速度大幅下降,官方也不再通过区域服务商对内容进行过滤。

在这之前有一个同样支持GitHub加速的静态资源库statically.io已被SNI阻断,与曾经的jsDelivr唯一的不同便是没有ICP许可证的保护。它走过的路,冥冥中暗示着jsDelivr注定的结局。

2022年4月28日,jsDelivr在中国大陆确认遭到DNS污染,乐章到此戛然而止。


贰、jsDelivr的替代方案

遭到DNS污染,基本宣告这个域名面向大众的服务失去价值,因为你无法让每个人学习像极客一样学会修改hosts、使用DoH分流。特别是前端引用这样面向用户的场景,应当更多考虑用户的便利性。以下博主提供几种可行的方案供大家参考,希望对大家有所帮助。

针对恢复访问主要分为服务和本地两种场景,服务场景修改则是替换jsDelivr资源到可访问的资源上,本地场景修改恢复访问的目的是针对海外引用jsDelivr的站点,这是两种不同的操作和目标。

服务·官方子域

这次的污染只针对cdn.jsdelivr.net这一个域名,jsDelivr有很多的CDN赞助商共同支持,每一个服务商都会有自己的专有子域名,通过替换访问资源到其他的二级域名可以恢复访问。但这些CDN普遍速度一般,而且前途并不明朗,建议仅供临时使用。

CloudFlare:test1.jsdelivr.net
CloudFlare:testingcf.jsdelivr.net
Fastly:fastly.jsdelivr.net
GCORE:gcore.jsdelivr.net

服务·反向代理

如果一定要使用jsDelivr的资源的话,可以考虑通过NGINX反代cdn.jsdelivr.net这一个资源库自用。建议通过海外优化线路落地+国内中转缓存,不过要注意添加防盗链以及尽量隐藏反代路径,以防止被其他人滥用。具体配置这里给一个简单的范例,博主不是很推荐这样做,可靠性上很打折扣。

服务·切换国内静态库

推荐一些国内比较稳定、全面的静态资源库吧,其中不乏完全同步cdnjs内容的,可以逐步将静态资源替换过去。

#字节静态库:cdn.bytedance.com
*完整同步了cdnjs的内容,通过自家CDN加速,缺点是没有海外节点而且链接比较凌乱。

#360静态库:cdn.baomitu.com
*完整同步了cdnjs的内容,并且有提供Google fonts加速,通过自家CDN加速,前段时间启用了AWS CloudFront的海外节点,是目前国内公共CDN做的比较好的了。

#七牛静态库:staticfile.org
*通过自家融合CDN加速,海外节点较少不过也表现尚可,缺点就是担心org域名后续备案维护的问题。

本地·修改Hosts(失效)

一般情况下,DNS污染通常伴随着SNI阻断,不过比较幸运的是jsDelivr只是单纯的DNS污染,可以通过本地指定正常的IP恢复访问。这样操作可以解决作为用户本地无法加载页面包含jsDelivr资源的问题。Hosts文件在UNIX系统下位于/etc/hosts,Windows系统下位于C:\Windows\System32\drivers\etc\hosts,在末尾处添加适当的以下条目即可恢复访问。

本地·使用DoH/DoT(失效)

DoH/DoT博主研究的很少,因为jsDelivr只是单纯的DNS污染可以通过DNS分流走海外加密DNS绕过污染。比如CloudFlare的1.1.1.1都是可用的,但是修改DNS一定要做好分流,以免影响GeoDNS对日常上网导致的CDN分配的问题。

本地·其他可能的思路

目前有通过油猴替换reCAPTCHA使用的API中的google.comrecaptcha.net实现中国大陆加载,理论上也是可以通过这样的方法将jsDelivr替换到大陆可加载的链接上,期待各位大佬的实践。


叁、结语

于是,到底是谁杀死了jsDelivr呢?是jsDelivr审核不够严谨?是网宿的不辞而别?是政策的“一刀切”?博主不知道,相信各位看官自己心里都有自己的答案吧。

本来只是想简单讲几句,没想到就说了这么多,一篇文章难免会参杂有个人情感,文中如果有不够严谨的地方请多指点。

最后,晚安jsDelivr,感谢您和诸多的赞助商这么多年来为用户无偿提供这样便捷的服务~


*原创文章,本文转载请注明出处

转载原创文章请注明,转载自: Luminous' Home » 【杂谈】jsDelivr域名遭到DNS污染

  1. 这几天jsd在大陆完全崩溃了;看到报道指,有人搭建VPS给人改ip地址也能当做犯罪被拘捕,感觉现在官方对互联网的监管已经到了风声鹤唳的地步,感觉在浏览器按个F12都会接近法律的边缘……

    1. @MX 在境内开展代理服务需要增值电信业务许可证,也就是所谓的IDC证,个人玩一玩不太会管但是涉及盈利了就容易被冲业绩。jsd的死个人感觉是监管和官方不对等,现在依然有拿jsd加速GitHub上某邪教的宣传图片的人,网宿不管之后官方也不会主动去向大陆屏蔽这些,被阻断都是板上钉钉的。
  2. 今天早晨切换到内地网络的时候突然发现自家网站要40s+才能打开…排查了一下才发现是jsdelivr出问题了…
    这么好的服务最后还是遭到毒手了…挺难过的。
    这次应该没办法再复活了叭。
    切换到xTom节点之后网站又恢复正常了…但是网宿的CDN不是谁都有资格用的呀…
    中国有些人真的是…不知道该怎么说了

    1. @千羽 恢复的希望不是很大,最近也看到一个朋友发的某邪教用jsd分发的传单图,已经退出大陆服务了官方也不太可能着手处理这些了。xtom的资源对大陆有个小问题,IPv4环境基本看的过去,但是IPv6链路不是很好很拖后腿。
      1. @Luminous 为什么刚才那条评论被吞了!! 国内的IPv6链路都很乱的说——,到处跳,不只是xTom的说。 所以主要还是用IPv4叭,咱现在都不知道用IPv6有什么好处...
        1. @千羽 现在光猫/移网默认开启IPv6,并且有更高的优先级。xtom的服务开启了ipv6之后到大陆很不友好,这个问题从我第一次遇到已经三年多了,确有需要尽量还是选择大陆企业的静态站。
          1. @Luminous 怪耶,咱的网站做了IPv4和v6双解析到xTom的伺服器,但是从console的network查看,IP位址还是v4的呀
  3. 昨天发现公司的企业网络无法访问(突然),但家庭网络能访问,这又咋回事

    1. @Alan 不同的网络环境受到影响不是同步的,还有很多因素比如缓存那些,不过可以确认是绝大多数地区像你公司网一样已经凉了
  4. 博主,能不能出一期,批量下载网站中cdn.jsdelivr.net的文件

    1. @林木www.jsdelivr.com逐个包去搜索呀,选好版本就可以点右上角下载了
  5. 博主你好,这里是Neboer!您的这篇文章写得真好,我可以转载在我自己的站点上吗?(会标明来源哒)
    谢谢~

    1. @Neboer 可以哒,注明出处就好~
  6. 炸了 放github上的图都没了啊

  7. 好了

  8. 唉。Gitte加了防盗链之后,我转到github,没想到又出了事,真的就没有免费又稳定的东西了吗

    1. @enomothem 合理利用和滥用没有太明确的标准,不过用这些资源当图床、视频床、下载链接显然是有悖设计初衷的。免费稳定可以选择有限的对象存储,但是显然也满足不了很多人的需求。
  9. 昨天挂了,刚刚才好……

    估计将会和github一样经常挂。个人免费能用的CDN,看来是没什么了。

    1. @zengyl 我本地测了一下还能正常连接,拿itdog试了下确实红了一片,只能说可惜了……
  10. 今天jsdelivr一挂,好多博客都卡得要死QAQ

    1. @才半页 这个没有办法,之前jsdelivr失去国内CDN的时候就该准备迁移了,可能还是早年的包袱太重了吧
  11. 今天又挂了

    1. @Limour 是的,惨兮兮……
  12. 感谢您和诸多的赞助商这么多年来为用户无偿提供这样便捷的服务

  13. 之前在vs上用libman管理前端库,就jsDelivr速度最快,另外两个源很容易没反应,现在没了国内CDN确实难受啊

    1. @余弦G 没办法,现在都日常离不开代理了
  14. 我知道的一个博主因为提供GitHub文件反代加速也被人滥用去加速京东羊毛脚本地址,也是损失惨重,太多人不懂得珍惜了!

  15. 我又来了,用py把jsdelivr上的静态资源都下载下来了…网站恢复

  16. 我好像没用到过这个(博主还活着!

    1. @zgcwkj 在呢,就是比较忙也没什么想写的
  17. 可惜了

  18. 当看到它被玩坏的那一刻,我就大概猜到了结局,只是比我预想中晚了一些

  19. 感恩罢了

  20. 意识到我貌似的确做过滥用。我的话在第一次JSD之后迁移到了Vercel。尽管依然是某种意义上的滥用。
    https://github.com/Eden7Ba23/BlogBackup/commit/89255c51d63c3b52f912ef6a3adfcfd58a3e59c7
    只能说,滥用可耻。虽然可以说是“自取其辱”。

  21. 已经有国内服务商对 jsdelivr 进行反代了
    比如说小麦云服 https://jsdelivr.io (就是之前那个搞过 U-FILE 的,稳定性堪忧)

    1. @ack233 实话说,这种长期可靠性还不如自己搭一个
  22. 个站死了,让我想想 ,我该如何是好

  23. 唉……对免费服务无限制的滥用,最终影响的只能是所有人的体验……
    是谁杀死了 jsDelivr 呢?