Enable CF proxy with multi-level CNAME chain

What we are trying to accomplish

  • We currently use Cloudflare as our primary edge service
  • We have client applications in Azure with hypothetical CNAME of “myappcname”
  • We have multiple domains, some of which are in CF and controlled by us, some of which are with 3rd party DNR’s that we dont have control over - these are our customers domains. All of these domains need to point to the same Azure app.
  • To achieve this we are currently having all domains point to an intermediary CNAME, “redirectcname”
  • This CNAME “redirectcname” is in turn pointing to the CNAME of “azurecname”
  • We want to route all requests through a single CNAME in Cloudflare for 2 reasons
    1. Use CF edge security products like DDoS protection, WAF etc
    2. To create a stable CNAME, so infra and edge is decoupled. This makes it easier to do things like change cloud vendors for app hosting if we need to. Hypothetically we could just point the CNAME “redirectcname” to CNAME “awscname” and all domains shift to a different app host with zero changes required from our customers.

What am I asking?
3 questions:

  1. Is this the best/simplest approach - any critique is welcome
  2. This only seems to work when the CNAME entries are set to DNS Only. This obviously in turn means that the Azure IP is visible with a nslookup - not ideal. Assuming this is a valid approach, how can we turn the Proxy on?
  3. If we can’t turn the proxy on, aside from making the Azure IP visible, does this have any other impact in terms of products that CF offer that wont work with DNS Only? (like WAF or DDoS protection etc.)

Thanks in advance.

I mention “myappcname” and “azurecname”. They are supposed to be the same cname - i made a mistake and cant seem to edit the post

Sorry for any confusion!

Good question :smiley: I’ll make a few comments to get the discussion started.

In short, Cloudflare needs to be aware of all domains involved. Domains you own should be associated with your Cloudflare account. For third party domains, you might want to look into “Cloudflare for SaaS” available under SSL/TLS → Custom Hostnames in the Cloudflare dashboard.

Yes, if you use “Proxy status: DNS only” (grey-clouded) you bypass all Cloudflare functionality (except DNS). So no WAF, DDoS, and so on. For that to work you need “Proxy status: Proxied” (orange-clouded).

(commas used instead of periods as CF wont let me add periods because it thinks they are hyperlinks)

Thanks @svanlund. So just to confirm, for testing purposes we are using a cloudflare managed domain “bar,com” and testing by adding in the DNS tool:

“foo,bar,com” → “redirect,bar,com” → “my,azurewebsites,net”

So this is currently working, our list of domains is relatively static (our customers are actually subsidiary orgs - see them as like franchisee’s) so we have successfully provisioned TLS certs from Azure - we are happy to manage this ourselves as the list of domains (whilst long) is relatively static/unchanging.

What I really want is to be able to turn on the Cloudflare proxy to use Cloudflare Security products - it sounds like i cant do this until proxy is turned on.

When we turn the proxy on for any of the CNAME entries (in any order) it doesnt work. Im not entirely sure why (CNAME loop or invalidates the SSL cert?)

Are you saying that this is caused by a cert issue? How would CF for SaaS solve this problem?

thanks in advance

So in this setup the first two subdomains belong to your domain. This domain is signed up for a Cloudflare plan and you have a Cloudflare DNS configuration looking something like this:

foo CNAME redirect (DNS Only)
redirect CNAME my.azurewebsites.net (DNS Only)

This is working as long as these records are “DNS Only”, right? Using https and you’re seeing a valid certificate for “foo”?

(Let’s focus on the simplest use case involving your domain first, but Cloudflare for SaaS might be of interest when you have a domain like “foo” above that is not yours. Like your customer owns example.com, has no intention of moving to Cloudflare, and just wants to use foo.example.com with your service by doing an easy DNS record change on their side.)

Ok sounds good
(and i will reach out to CF regarding the SF for SaaS - more than happy to look into this if it solves an issue - sounds like there may be multiple issues here)

So yes correct. DNS only as you say and it is encrypted HTTPS and the cert is valid, as i said, managed from Azure.

If I flip to proxy for any of these CNAME redirects - it breaks.

I ran a nslookup in both scenarios.

When DNS only is active for both entries, it resolves as id expect:
waws-prod-lnXXXXXXXXX.someregion.cloudapp.azure.com
Address: 51.104.XX.XX (Azure IP)

When any entry is Orange Cloud I get:
Name: someurl.com
Address: 172.67.XX.XX
Name: someurl.com
Address: 104.26.XX.XXX
Name: someurl.com
Address: 104.26.XX.XXX

which i think is a CNAME loop

104.26.XX.XXX is the cloudflare IP so it looks like its basically disappearing inside cloudflare and not resolving correctly to Azure

Great, then we have a simple scenario to analyze! The “orange-clouded” DNS result looks fine to me. The client picks one of these, so no problem there. If you proxy “foo” and/or “bar” like you did previously, what happens in your browser? Any helpful error message?

thanks @svanlund I get

SSL_ERROR_NO_CYPHER_OVERLAP in Firefox
ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome

If we remove the 2nd CNAME redirect and point directly to Azure

foo.bar.commyapp.azurewebsites.net we can turn the proxy on and everything resolves and the certs are fine.

Nice catch! Feels like I’m hitting a wall over here though. Don’t know if you tested this, but is there any foo/redirect proxy status combination that works apart from all DNS only?

foo proxied
redirect proxied

foo dns only
redirect proxied

foo proxied
redirect dns only

Ive tried that - im wondering if this is a cert issue due to the CNAME chain. Im actually testing out CF for SaaS right now as it might be a good option for us and handles certing for us. I will post back here my findings for yours (and anyone elses) future reference

These two errors most likely have very little to do with what’s behind them. This is Cloudflare’s Edge Certificate for that hostname.

As long as the hostname is no deeper than one-below your apex domain, Cloudflare should issue a cert. When I talk about “deep”, I mean that Cloudflare will get you YOURDOMAIN.TLD, and SUB.YOURDOMAIN.TLD. Some people try WWW.SUB.YOURDOMAIN.TLD, but default certs won’t cover that.

Nah, that’s just redundancy. Some people get two IPv4 and two IPv6. Some people get three (or more) of each.

Thanks for the clarification there @sdayman so ive enabled CF for SaaS - this has resolved the issue and also solves the certing for the domains (which is probably what resolved the issue)

Funnily enough from a DNS perspective the setup is exactly the same as it was before

  • I created a DNS record that points CNAME redirect.bar.commyapp.azurewebsites.net. CF refers to this as the fallback origin. This has to be done first and ensure that Proxy is turned on.
  • In the Custom Hostnames tab in SSL/TLS (CF for SaaS has to be enabled first) I added the CNAME above redirect.bar.com as the fallback origin. I then added both CF-based domains and 3rd party domains in here after pointing the respective DNS records to the fallback origin CNAME, waited for the certs to provision and boom worked straight away!

Thanks so much for your help @sdayman

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