ANAME/ALIAS on 3rd-party providers not working with SSL for SaaS (Custom Hostnames)

What is the name of the domain?

ln.ki

What is the error message?

Custom Hostname does not CNAME to this zone

What is the issue you’re encountering

ANAME/ALIAS on 3rd-party providers not working with SSL for SaaS (Custom Hostnames)

Was the site working with SSL prior to adding it to Cloudflare?

Yes

What is the current SSL/TLS setting?

Full

We are testing SSL for SaaS (Custom Hostnames) to allow 3rd-parties to point their domains to our SaaS, instead of managing everything with nginx and letsencrypt.

We’ve configured everything successfully, including the fallback origin ( fallback [dot] oursaas [dot] com ) and the CNAME target ( to [dot] oursaas [dot] com ). The fallback is connected to a tunnel created with cloudflared.

Everything works perfectly for standard CNAMEs: any 3rd-party provider created a CNAME (e.g. sub [dot] domain [dot] com) pointing to to [dot] oursaas [dot]com and all is good.

Problems arise with those who need to use a root domain (e.g. domain [dot] com without any subdomain). Despite many providers supporting flattened CNAMEs (ALIAS or ANAME) Cloudflare seems unable to match them with the zone and configure the Custom Hostnames, always returning the error “Custom Hostname does not CNAME to this zone”.
We tested with multiple providers that all support flattened CNAMEs with different names/methodologies and it’s always the same: the records are shown correctly via dig, but Cloudflare doesn’t validate. Do note we’re not talking about SSL validation which can be probably performed in other ways, but the actual activation of the Custom Hostname and its routing.

The official documentation of Apex proxying (enterprise only) : clearly states: “In a normal Cloudflare for SaaS setup, your customers route traffic to your hostname by creating a CNAME record pointing to your CNAME target.
However, most DNS providers do not allow CNAME records at the zone’s root1. This means that your customers have to use a subdomain as a vanity domain (shop [dot] example [dot] com) instead of their domain apex (example [dot] com).”
And if you hover with the mouse over the note it specifies “Cloudflare offers this functionality through CNAME flattening.”

All this seems to indicate that Cloudflare should support root records, as long as the 3rd-party DNS provider supports flattened CNAMEs. However, this doesn’t seem the case.

Is there any additional setting or option for having simple flattened ALIAS/ANAME records work on Custom Hostnames?

If you’re on the Enterprise SaaS plan you should contact support for debugging. ANAME or CNAME flattening turns the host name to an IP address. So as long as it’s resolving to the expected IP address for an environment configured to support it, as long at the IP is correct it should resolve.

It’s required.

We’re not on the enterprise plan. From the documentation we read, this is not required. It’s only required for APEX records for DNS providers that don’t support ANAME/Flattened CNAMEs. We’re trying to have this working with a non-enterprise plan

Did we misunderstand the docs?

There’s no way for Cloudflare to determine if the original record is an ANAME or CNAME which has been flattened.

Apex proxying requires an Enterprise plan because it requires a designated IP address be made available which doesn’t change. Otherwise… Because 99% of your customers won’t have ANAME functionality available and will simply create a A record to the IP instead (and when Cloudflare changes the IP for whatever reason suddenly your have dozens/hundreds/thousands of customers whose sites are broken.).

Apex proxying (enterprise only)

Cloudflare has actually gotten better about enforcing the logic around this from what I understand. In the past folks found ways to proxy the Apex even though it wasn’t supported on their plan type (through failure to check by Cloudflare or poor logic. When they did) and in the end when the IP addresses changed it resulted in very mad customers who were using features they hadn’t paid for blaming Cloudflare in some extremely colorful language for their use of a feature in a manner which was destined to cause them pain.

Since you’re allowing 3rd parties to point to your host names (vs. domains you manage and control) you can’t be sure they would use an ANAME or CNAME flattening for their root domain. Assume your customers will lie to you and do stupid things. Further assume they will 100% blame you when their lies or stupid thing they did causes them inconvenience.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.