Recently I have noticed that cdn.jsdelivr.net has shorten the CNAME chain.
$ dig cdn.jsdelivr.net @1.0.0.1 +short CNAME
cdn.jsdelivr.net.cdn.cloudflare.net.
$ dig cdn.jsdelivr.net @8.8.8.8 +short CNAME
cdn.jsdelivr.net.cdn.cloudflare.net.
It seems that cdn.jsdelivr.net no longer uses PerfOps as load balancer. So is there any technical details about this change? Are jsDelivr simply using GeoDNS provided by NS1 & CloudNS? Also, StackPath & Fastly no longer shown up in DNS Propagation Map. Is the jsDelivr no longer considered using Fastly & StackPath.
Another problem is jsDelivr has down in China last year due to expired SSL certificate (#18148). Since cdn.jsdelivr.net has valid ICP License, is it possible to use both Cloudflare's China Network & QUANTIL in China? jsDelivr is using Cloudflare Universal SSL which could be auto renewed, which means jsDelivr could use Cloudflare's China Network as a failover in case SSL at QUANTIL expired again.
We're in the process of migrating away from PerfOps. Right now we use Quantil in China and Cloudflare everywhere else but the plan is to use additional geo-based and/or rum-based rules and bring back the other CDNs. We'll update the README/website once we know what's the final solution.
As for China, we don't have access to CF's Chinese network.
@MartinKolarik Is Cloudflare willing to provide jsDelivr with its China Network? As far as I know Cloverflare China Network doesn't require Enterprise Plan (Business Plan will be enough).
We are on the Enterprise Plan but AFAIK, they were not willing to sponsor the China Network because it would be too expensive for them and that's why we use Quantil. Nevertheless, we'll make sure the SSL issue doesn't happen again.
Well, I have noticed jsDelivr is enabling Fastly for those Countries:
Will jsDelivr start to bring up Multi CDN again?
For now it's based on static data and Fastly is used in locations where it's consistently better. Eventually we will move to another real-time LB solution.
@MartinKolarik
Thanks for your explanation!
BTW, what's wrong with PerfOps? Is it about the SLA? AFAIK PerfOps seems to be using the Cloudflare DNS Firewall (Cloudflare proxying DNS UDP request to origin server) which might be a bottleneck.
I am the founder of PerfOps. Unfortunately since I left the company I can no longer trust it enough to run such an important service.
But I'm curious how you found out about those rules we created :)
@jimaek
I am consistently watching jsDelivr performances and reachability (As I used jsDelivr for my blog and some other personal websites). And there are many DNS Propagation Check tools just like dnsmap.io could be used (I am using the one provided by tools.ipip.net)
I see, nice. Keep us posted if you think there is anything we could improve
Most helpful comment
For now it's based on static data and Fastly is used in locations where it's consistently better. Eventually we will move to another real-time LB solution.