0

Currently we have a cloud based SaaS application, that runs behind a domain on Cloudflare. Let's say example.com.

The main panel and application is located at cloud.example.com. When a customer signs up, they are allowed to choose a subdomain where they can access the control panel and the front end of the application. Let's say customer.example.com

As example.com is on Cloudflare, a simple call to the Cloudflare API to add a A record is all it takes to have one of these domains setup and Proxying through Cloudflare for all the CDN an DDoS goodness.

We now want to allow customers to provide their own domain, for cosmetic and branding reasons etc. Let's say the user wants to use app.customer.com, their own domain. In the usual fashion, the customer would be instructed to create a CNAME to map that domain, to the customer.example.com domain that we generated. But when we do that, we receive a DNS resolution error. Something that is only supported on Cloudflare Enterprise plan.

I feel there are 2 good options to work around this that I can think of:

  1. Create a separate Microservice, dns.example.com, that all custom domains are mapped to. Whatever domain is mapped to it, either by using some prefix like customer.dns.example.com or by trying to configure Nginx to take the host and use that. This dns.example.com is in the Cloudflare network but is "DNS Only".

    Requests hitting this are then mapped to customer.example.com (which is on the Cloudflare network and as it shares the same domain including name servers), using a CNAME record. So app.customer.com -> CNAME -> customer.dns.example.com -> CNAME -> customer.example.com

    Benefits of doing it this way means we can take advantage of Cloudflare's proxying, albeit making it a bit complicated.

  2. Use Cloudflare for DNS only. Customers are assigned their subdomain and a simple CNAME from their custom domain to the one assigned to them works fine because of no Cloudflare proxying. With this, take advantage of the host's DDoS protection.

    Perhaps serve static files from static.example.com, and proxy that on Cloudflare to take advantage of the CDN etc.

My question really boils down to, is not using Cloudflare for their services a good choice in this scenario? Public IPs are Public, hence the name, but is it fine to just have the IP of where the server is running on a public A Name? Plus, I don't want to enforce my customers to have to use Cloudflare to set it up, I want it to be seemless.

Any input, ideas, or designs, please share them!

Quick FYI: SSL Certificates isn't really an issue, either way I have them covered/generated easily.

Mark Barrett
  • 101
  • I don't understand what #1 is supposed to do. If the browser was given app.customer.com to connect to, the proxy still needs to know about it for both the SSL certificate and where to actually route the traffic. CNAME is just the DNS lookup for where to send the traffic. Everything else after has nothing to do with DNS. Cloudflare's proxy is going to say 'huh? What's app.customer.com?' #2 sounds like the obvious answer if you aren't going to use Cloudflare's (paid for) solution and don't want your customers to sign up for cloudflare on their own. –  Dec 22 '20 at 23:36
  • The first solution would be to allow dns.example.com to be reached by any CNAME record mapped to it because it would be DNS only and not Proxied. Then there would be a respective CNAME that maps that to the "customer.example.com", which is known by the proxy. I suppose by adding that extra step, it allows me to map an external domain to a sub domain that cloudflare knows about which can then be mapped to one thats proxied. Because the issues arises when you map an external domain directly to a proxied domain. But putting one in the middle removes that "huh" – Mark Barrett Dec 22 '20 at 23:39
  • I think you're missing my point. No matter how many CNAMEs you chain together (which is already bad practice), the browser is going to request app.customer.com. If you aren't going to redirect requests to a URL that is on customer.example.com (and NOT app.customer.com), your solution doesn't work. –  Dec 22 '20 at 23:41
  • Yes but is the whole point of a CNAME not so we can take a request to app.customer.com and alias it to another? I.e. take a cname record from a domain not known to Cloudflare and make it known my aliasing it to a domain setup with them? – Mark Barrett Dec 22 '20 at 23:46
  • 1
    No, a CNAME is so you can alias a DNS resource record name to that of the IP address of another DNS resource record. Whatever 'alias' you're talking about after that, cloudflare will not work. Hence, option 2 since option 1 buys you nothing but an extra DNS lookup. –  Dec 22 '20 at 23:57

0 Answers0