Cloudflare I think calls this feature Subdomain Zones (LTZ) and it’s only available with the ‘Enterprise’ tier - see https://www.cloudflare.com/en-gb/plans/ then click ‘Compare all features’ button to see this feature. It is however prohibitively expense to consider upgrading to the ‘Enterprise’ for such a basic feature.
My company has been asked by a client to run a website as a subdomain of their root domain. This client uses a DNS provider other than Cloudflare and is unwilling to consider moving their domains to Cloudflare. They are however willing to delegate NS records to us to manage the subdomain.
Delegating NS records to our company logically makes sense - it allows the client to manage their own DNS records and allows our company to manage just these subdomains for them. I suggested the client should move the domain in question to Cloudflare, then create a restricted ‘API Token’ - see https://dash.cloudflare.com/profile/api-tokens - which would allow me access to manage just the DNS for these subdomains. However the client has 40+ domains and is unwilling to move all of them at this time.
The only solution at present is to use practically any other DNS provider such as Google Cloud DNS, Amazon Route 53 or Azure DNS. Using a DNS provider other than Cloudflare is not the preferred solution, but for the mean time will have to survice until Cloudflare allow non-‘Enterprise’ tier users to add subdomains as ‘New Sites’.
Any help or recommendations would be appreciated. Including suggesting alternative DNS providers I should use.
At the moment I’m considering Google Cloud DNS because;
I would rather say hosting provider, like you can add a sub-domain to any cPanel hosting provider itself, if so?
Okay, if so, may I ask why doesn’t he create a sub-domain and add a DNS record for that hostname at his current hosting (DNS) provider?
What and why current DNS/hosting provider does not allow you that, I am not aware.
You can try with a CNAME (requires a Business plan at least) if you are going to use Cloudflare.
Is your Client willing to pay you $200/monthly for Business plan to solve this issue for him, as using Cloudflare is yours preferred solution?.
If not, then I am afraid you would have to figure out some other solution as you already proposed few of them.
Kindly, more information about this can be read at the link from below:
Just adding static A/AAAA records to client’s account is a bad solution - we need to be able to update A/AAAA records ourselves and quickly during disaster recovery and other events.
Like an increasing proportion of the web, we use letsencrypt.org for DNS and we need to be able to add a TXT entry in an automated way to the client’s subdomains every 45-90 days. Just adding A/AAAA records or a CNAME doesn’t solve the SSL certificate generation issue.
My specific issue is not being able to add a subdomain to a non-‘Enterprise’ tier user. I’m hoping my post will encourage Cloudflare to fix this glaring omission for non-‘Enterprise’ tier users. Please limit your discussion to this.I’m aware of the A/AAAA/CNAME solutions and they don’t/can’t solve all the issues I need solved.
Unfortunately I don’t have access to the clients account. And they don’t want to give me access to their account either. I consider this quite reasonable.
I’m using letsencrypts DNS challenge at the moment, but you’re right I could use a CNAME and the HTTP challenge. Technically the HTTP challenge is a bit painful for me to implement though (would need to upload the token to multiple load-balanced servers). Non-issue: the HTTP challenge would also prevent me from generating wildcard certificates in the future if I ever needed them.
Technically the NS solution where subdomains are added to Cloudflare is still the technically best and simplest solution to implement.
Thanks for your replies, they’re appreciated - but as you’ve said, I’ll wait to hear from others now if that’s okay!
I am afraid, in terms of a related/linked article about CNAME cloacking, to me that is or was a web browser issue. It’s essentially a website masking external trackers (cookies) within their own subdomain, which browsers typically wouldn’t mind because it’s coming from the same domain.
We can use different DNS resolvers if so.
Furthermore, Cloudflare only flattens CNAMEs at the root level → Free plan, and that’s because CNAMEs at the root are not a standard. They have to convert it to an A record to be standards compliant. → yet, at Pro plan ang higher we can select to flatten all CNAMEs
Cloudflare nameservers also flatten CNAMEs pointing to workers.dev (a domain they own), for example.
Cloudflare’s denormalised API works great for simple cases, but quickly becomes a pain in the arse for more complex cases. Example: because Cloudflare denormalises it’s records it needs to add a “recordId” for each “value”. Whereas for Googles API the “domain”/“type” is simply the primaryKey.
Long story short - built an API where Cloudflares records are normalised and can access Cloudflare/Google DNS via a single consistent API. A little bit unnecessarily complex, would have been great if Cloudflare just had a second normalised API so didn’t need to do this.
The most annoying/hardest part of moving to Googles APIs was authentication. Firstly Google’s documentation on authentication is absolutely terrible. The docs spend the majority of their time explaining how not to authenticate, and why you shouldn’t do it yourself. Eventually you figure out it’s just a single JWT RS256 token encoded as described here: https://www.rfc-editor.org/rfc/rfc7523#section-2.1 . But the only way you figure this out is by reading through the overly verbose Google auth library: https://github.com/googleapis/google-auth-library-java (this library has an annoying number of dependencies - including a dependency on https://opencensus.io/ (google’s own telemetry api), uses old fashion JUL logging rather than SLF4J - everything about this is heavy). Seriously google, if you’re reading this, just write documentation that tells people you’re just using standard JWT to authenticate rather than insisting they use unnecessarily heavy auth libraries.