Custom Hostname - Issue with Apex CNAME
I'm trying to set up a custom hostname from one of my other apex domains outside of Cloudflare into my one inside of it, and despite having the apex domain pointed towards the CNAME (flattened) and the returned IPs being the same as the custom hostname, it's saying it's using cloudflare and can't be activated and sometimes even that it isn't pointed towards it, which it is, is there any way to fix this?
33 Replies
Interesting, it should work as long as the other provider supports proxied CNAMEs/ANAMEs. What's the url of the domain you're trying to link, and the exact error in the Custom Hostnames tab for it?
The thing is my DNS is self hosted and doesn't support ANAME/flattened CNAME, I manually flattened it by grabbing the IPs from dig.
Any idea?
What's the url of the domain you're trying to link, and the exact error in the Custom Hostnames tab for it?
i told you, it said its using cloudflare and cant be activated. it was my root apex domain millistice.com
either that or it'd say sometimes that it isnt pointed at the zone
It says "its using Cloudflare"?
I don't see that domain pointing at CF IPs right now.
I've never tried apex proxying without the other domain using CF DNS, will have to try that sometime. CF does offer a proper way to do this, but Enterprise only: https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/apex-proxying/
Apex proxying Β· Cloudflare for Platforms docs
Apex proxying allows your customers to use their apex domains (example.com) with your SaaS application.
could just have some server handle redirects from apex -> www and have the custom hostname be www, another option
then how am i supposed to protect the apex with CF?
to avoid downtime i actually took it off that and i am waiting for a fix before i try again
you wouldn't, you'd just have something silly handling the redirect and all your app logic/etc live on www which would be behind proxy
so you expect me to leave the apex exposed to DDoS?
no thank you
i don't see why i can't just use dig and get the IPs like i have done before
that's basically what cname flattening is
It's not officially supported without using the enterprise addon and even more you're doing it really hackily by manually flattening it, Proxy IPs are not guaranteed/can change
what kind of logic is that? why on earth would they not allow the apex to be protected without enterprise? i am sorry but that makes 0 sense
Some of it is just internal pricing stuff I imagine, but they also would need to assign you static IPs that would never change
i dont see why i cant just use any ips that come off of the cname
dig milliecdn.com A
dig milliecdn.com AAAA
that ran consistently using crontab should be sufficient
this is clearly a bug
doing it via a cron is better, basically cname flattening if you run it often enough
my backend server literally does cname flattening on its own already for my existing protection provider
so i dont see why the dashboard won't just activate my domain and that be it
if it's pointing to the same IPs as the cname it doesnt matter if the CNAME is there or not
It might be strictly looking for the CNAME. I know it works if the DNS Provider is Cloudflare itself (maybe because they can actually see the target even if flattened), not sure about other providers. It's not setup right now so there's not much that can be debugged
i literally do this currently:
dig geo-routing.nexuspipe.com +short
that gives me an IP
i then use sed to replace it
i can try it but dont expect it to work haha
same exact IPs as yesterday
would you look at that, the AAAA is the same too
seeyea that wording sounds like it's strictly looking for a CNAME
I wonder if adding the pre-validation txt would bypass
and now it says this
its added already
the mixed up error messages clearly show this is a bug
that shouldnt be the case
if it is, whoever coded that is a bit of a bad programmer (no offence)
I would imagine that is happening is that it's realizing the txt is set and then moving onto that
there's various stages of validation and such, it takes a sec to check things
if i spam refresh it says uh ya know
this again
now back to the other error
Refresh restarts that process so that makes some sense
Curious though, was trying to find more info on that error
the DNS target needs to point to the SaaS zoneit literally DOES lol i mean... if you dig millistice.com that's what you'll get lol @Chaika someone had this same issue 2 years ago and they were ignored https://community.cloudflare.com/t/the-hostname-is-using-cloudflare/404681 found this too https://community.cloudflare.com/t/apex-proxying-works-for-one-host-with-com-tld-but-not-co-uk/425973 is there no way someone from CF could manually verify it?
Yea I saw a few of those before, lots of moving parts though.
I was testing myself to see if I couldn't repro. It does work fine if I cname apex from a domain using CF DNS, was waiting for DNS Propogation on one not using CF DNS. After that could ask for clarification, it does kind of imply that it would work with DNS Providers who support flattening CNAME records and that was my previous understanding.
yeah thats weird why it doesnt work for me then
i literally flattened it myself
to clarify right now all I've confirmed is it does work from a domain using CF DNS, the one using third party DNS is still pending/waiting for it to propagate so I can add it to CF
ah gotcha
I tried adding an apex of an unrelated domain on my Enterprise account and it gives a different error
None of the A or AAAA records are owned by this account and the pre-generated ownership verification token was not found.So it seems to me it might just be an Enterprise thing, but we'll see
ah
@Chaika I've noticed it's now not giving off the whole "not pointed to the zone" error
I've spam refreshed about 50 times and it's stuck on "is using cloudflare", seems like a case of spaghetti code π
@Chaika this is really funny, so guess what?
if I remove all my A records and vice versa it works
then I just add them back and job done
LOL
That's really weird, I can repro that. It looks like you're slipping through the activation conditions. Either CNAME equals, or Prevalidation TXT is set, but even if txt is set if it's pointed at Cloudflare but can't verify what, it fails, hmm
problem with all the shared IPs is that it has no idea which account you could be pointing at (and why apex proxying assigns you your own static ones)
you can get it to become active with just the TXT (a pre-validation method), but it gets blocked because it think its not pointing at the zone (real-time validation)
Yea
A potential fix is to just ignore if the CNAME isn't there
Or perhaps, just check what the backend IPs are and check those are there
Eg
I'll ask later, I'm guessing they had a security reason to implement that block if its pointing to CF but not your zone. Those IPs are not unique to your account/don't identify your zone.
But yea for now the workaround is just to use the txt prevalidation, add custom hostnamme, add txt record for prevalidation, wait until active and then add cname
Yep
Maybe they could improve the UX by editing the UI to tell people to do what you stated