DNS resolve origin IP instead of proxy IP

Hey :wave:

I am currently prototyping a project for my company using CloudFlare SSL for Saas but I encountered an issue. We offer hosted websites to our customers, and we would like to try CloudFlare SSL for Saas to protect them with TLS. Those websites can be branded (ie. have custom domain like custom.awesomecustomer.com).

So here is the setup I have:

I have my company DNS setup in cloudflare as follow (using that doc):

  • Proxied A record proxy-fallback.mycompany.com to point to our internal origin IP
  • (Not proxied) CNAME record *.customers.mycompany.com to point to proxy-fallback.mycompany.com
  • I have enabled SSL for Saas, and setup proxy-fallback.mycompany.com as my origin. Also created a custom domain as custom.awesomecustomer.com. This domain has been verified and the SSL certificate has been issued and valid :white_check_mark:

Now my “fake” customer domain is setup like that in another registar (google domains):

  • CNAME custom.awesomecustomer.com to point to awesomecustomer.customers.mycompany.com

What’s happening now is interesting:
nslookup custom.awesomecustomer.com resolves the Origin IP instead of the proxy IP.

If instead I change the customer’s CNAME record to point to proxy-fallback.mycompany.com, everything works fine (ie nslookup custom.awesomecustomer.com resolves the proxy IP).

Do you have any idea what I could have done wrong here?

Thanks in advance

It’s been a month or so since I tried SaaS with the following directions (which look like what you did):
https://developers.cloudflare.com/ssl/ssl-for-saas/getting-started
Does that custom hostname show as Active?

I also don’t think I used a Wildcard CNAME for your customers hostname. I just made that CNAME something like saas.example.com. I know the docs say to use a wildcard, but I don’t think I did it that way since I don’t think it matters. Maybe that wildcard enables some special features I’m unaware of or couldn’t get to work.

*.customers.whatever isn’t proxies so it will resolve to the origin. Either the wildcard record should be proxies or a record specific to the customer can be created and proxied.

That’s what threw me off. Only Enterprise plans can proxy that. But as it points to a CNAME that’s :orange: Proxied, I wasn’t expecting it to flatten that record to the origin.

I didn’t even think it had to be specific to the client. But I may have done that nonetheless.

Thanks for your replies folks.

Everything works fine in my proto if my “client” points to the PROXIED A record (as expected).
What threw me off to is that:

  • If I have a CNAME *.customers to point to proxy-fallback.mycompany.com
  • and a PROXIED A for proxy-fallback.mycompany.com

Why does the DNS resolution of something.customers.mycompany.com resolve to the origin instead of the IP of the proxy? That’s not blocking our prototype at all, it’s really just for my curiosity at this point :slight_smile:

Because the record it is pointed to is not :orange:

OP says it is, and from what I’ve seen with email records, if example.com is :orange: proxied, then a :grey: CNAME for ‘mail’ that points to :orange: example.com won’t return the origin IP address.

So I’d expect this to behave the same, yet it isn’t…or there’s something wrong with the :orange:
proxy-fallback.mycompany.com record.

Without knowing the actual hostnames, that’s not something we can investigate.

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