this post was submitted on 12 Jun 2025
685 points (98.9% liked)
Technology
71457 readers
2510 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
We need to break up Cloudflare.
We just should not use cloudflare. Why is everybody still trying to use cloudflare.
It drives me nuts. The default answer on all network problems: why don't you just use cloudflare? No! No no.
Counterpoint: I find networking challenging, and I'm not particularly accountable for the natural consequences of not knowing how stuff works.
This could end fine for everyone? Maybe an AI will understand it for me. (This is sarcasm. I agree with you.)
It sucks because up until the "sales team" rugpull, they're the cheapest (and closest to reality) for bandwidth cost, virtually all the other CDN providers charge astronomical prices and their margins are hundreds to thousands of percentage.
If the costs are mostly variable in how much they serve up, and uptime is sufficiently important, maybe have two CDNs and use the other one as a fallback when things start going tits-up?
Cloudflare tries to enforce pretty strong vendor lock in by requiring you use their nameservers.
Also subdelegate domains are an "enterprise" feature, so no luck there.
Basically the CDN market sucks, not a shocker Netflix, Google, Valve, and many others operate their own.
Hmm.
I'm not familiar with the constraint.
I assume that the way that this works is that I host content at www.foo.com and they have their nameserver resolve www.foo.com to different IPs based on the geolocation of the browsing user's IP.
Is it possible to convert www.foo.com to a CNAME that can be redirected away from their nameservers? Like, I make www.foo.com be a CNAME directed at www.foo-cloudflare-cdn.com. They own www.foo-cloudflare-cdn.com, they serve A or AAA queries there on their nameservers. But if I want fallback, I update the CNAME to point at www.foo-backup-cdn.com, which is served by a different CDN.
Are there technical barriers to that, do you know?
The way CDNs and virtual hosts work in general is to read the
hostfield in the HTTP header, otherwise unless you dedicate an IP for each domain / "web site" there would be no way to know what to serve.The issue is if you put the CNAME of foo
www.foo-cloudflare-cdn.com.then it will just resolve to whatever the A/AAAA record is for that, and send the host ofwww.foo.com– which they will only service if that domain is hosted with their nameservers (they run automated checks to make sure you're actually doing so). So there isn't really an easy way to just give cloudflare some subdomain, unless you pay them $$,$$$+ for the privilege.Valve actually does that, ironically enough, for the steam community web assets they use Fastly, Akamai, and CloudFront, all on subdomains of course 🙃.
But the point of CDNs is to direct connections to a geographically-near IP, yes?
The domain name that any CDN webserver in different regions will get in the HTTP request headers is going to be the same, CNAME or no.
Ah, okay, I could see someone having automated checks that actively prevent it.
That's generally right enough, the goal of a CDN is to deliver content from a server close to the consumer as possible (ideally on their ISP network using cache servers to avoid going out over the "wider internet".) – however CDN networks typically also use Anycast IP addresses, which means that all of the CDN servers across their network use the same pool of IP addresses, and BGP / the routing table dictate what actual physical server you get routed to. This is typically the ideal closest server, however sometimes you want certain IP pools in certain regions for legal (China), or technical reasons, so the IP address returned by a given A/AAAA lookup for a CDN isn't a given. There's also ECN and other optimization CDNs can do on the lookup side but that's outside of the scope here.
Yeah, so the CNAME just says "whatever A/AAAA address that resolves to" and the HTTP client will send whatever
HOSTit thinks its connecting to, meaning you can't "mask" the actual domain you're using by using a CNAME record.Technically if you have a totally static IP serving a single site, it's possible to ignore the HOST field and always serve that site, since logically, any request is only meant for that given site (this is basically the default site on something like Apache).
My main point is that there's really no getting around that CloudFlare requires you to be locked in to their platform even if you just wanna serve R2 files from a subdomain, and I personally find that a bit spooky, migrating nameservers can have very long propagation times leaving your site unreachable if they decide they don't want you as a customer anymore, or as a shakedown.