Right, CF For SaaS enables that. You can
Right, CF For SaaS enables that. You can't get apex proxying outside of Enterprise so you need to rely on alias records, but it should just work if you go through the prevalidation and such
15 Replies
So you would expect a Namecheap ALIAS record pointed appropriately to validate the "CNAME" requirement for SaaS worker stuff?
(It looks like just A records, much like Cloudflare's CNAME flattening)
I think last time I tested it, it was a bit weird, and you needed to add the prevalidation txt, wait for it to become active, and then add the cname
they're def not 100% equal, CF knows the exact target of the cname when it's on their platform
you're getting stuck with it not validating or something?
Ahhh interesting.
Right, that's kinda what I'm getting at. It feels like there is no industry standard for how to do this, so each company kinda does their own...
But there's no great way to communicate across providers that this is being done. I.e. there is no way to tell that I have a "Namecheap CNAME" / ALIAS record at the root
Yeah, exactly. It worked out ok for this case because I just flipped the domain over to being managed by Cloudflare, but I can't imagine that will always work haha
CF does have proper apex proxying they offer with Enterprise that they hand you IPs for, and then they just validate "hey this site is pointing at A/AAAA IPs belonging to this SaaS user"
Yeah, that makes sense.
It's just hard if I want someone to be able to use my service and they use another domain provider, my workers are sorta hosed haha
but yea that is Enterprise. I'd have to test again but I think the trick is just to do the prevalidation txt first, and wait (you can even keep your old origin active this way), and then swipe out the records
Ok cool - I'll give that a shot, thank you!
Just for completeness.. these are the ideas I was throwing around to improve this situation.
- get the industry to standardize on some mechanism of "CNAME at the root" that can be interpreted from the outside. I.e. Naively: a TXT record that indicates that a "CNAME" Is in place, even if it just looks like A records
- Teach Workers to be more savvy about recognizing "appropriate A records" as validating the "CNAME" requirement on root domains
- Create a TXT or other mechanism to short circuit Cloudflare's CNAME recognition and indicate that A records are really being resolved properly as a "CNAME at the root"
get the industry to standardize on some mechanism of "CNAME at the root" that can be interpreted from the outside. I.e. Naively: a TXT record that indicates that a "CNAME" Is in place, even if it just looks like A recordsiirc they're working on it with https svcb records, Fastly and a few others who use dns to route are pushing it
Create a TXT or other mechanism to short circuit Cloudflare's CNAME recognition and indicate that A records are really being resolved properly as a "CNAME at the root"That's what the prevalidation txt is!
That's exciting!! Thank you! 😄
The quirk with Cloudflare was that it got confused when you added both the cname and the prevalidation txt at the same time on apex, used to need to add prevalidaiton txt -> wait for hostname to be active -> then cname. I'm not sure if that was ever fixed
I did just test adding it that way (waiting for active) on an apex domain at an ext. dns and it worked fine, I'll clear it, give a bit and try doing it all at once
Ahh nice. Thanks! That's great to know! I also may have been too impatient - very used to how fast validation works for domains on Cloudflare haha. (and non-root CNAMEs)
the txt validation is pretty fast, less then 30s, but it's going to depend on your ext. authoritive dns provider too in how fast they update on their end
Or I may have skipped the pre-validation TXT... that seems like something I might have done haha 😅
the cname is enough on subdomains but it's not enough if it can't see it, like on the root where its flattened
Akamai talked a bit about svcb records here btw: https://community.akamai.com/customers/s/article/NetworkOperatorCommunityNewSVCBHTTPSResourceRecordsinthewild20201128135350?language=en_US
apparently support is further then I thought with some clients already supporting. It looks like Chrome and Firefox are being stubborn and not supporting the other features of the https/svcb record though, including the ability to use them as sort of cnames on apex. I haven't been following too closely
and yea, I tested it and it still gets confused if you try pointing to CF with an alias/flattened records first and then adding the TXT, you get "no cname to this zone" and then "The hostname is using Cloudflare and cannot be activated with an TXT or HTTP validation token". You can point to anything but Cloudflare to get it activated w/ prevalidation txt, and then add the alias record.
Ahh perfect. Thanks so much for your help! And the pointer to what's happening in the industry - I'm super interested in following those developments!