Subdomain delegation to second zone

The idea is to allow subdomain defined in a zone (let’s say in zone to be delegated to a different zone.
Right now this is possible to do only one by one using this setup
However, that is very limiting for more complex domains. It allows only one subdomain per subdomain zone. In complex domains with larger number of subdomains, it makes a lot of sense to group subdomains together and apply shared rules to them (and have different people configure them) to have for example:

root zone:

api zone:

support zone:

It seems that the basic pieces are already in place. It is possible to:

  1. add NS DNS records to domain to forward subdomain to different zone
  2. add second record as a CNAME of the first
  3. add the second hostname to the subdomain zone as a custom hostname

This seems to work, but it is very impractical. I’m proposing to wrap this into user friendly feature.

You can have the subdomains be in other accounts, they don’t need to be in the same account as the root zone. So in your example you can have 3 accounts then add those subdomains as zone to the desired account

I don’t think it matters whether they are in a different account or not. The point is that each subdomain will have to have separate zone. Which means even if you want the same rules for big part of them, you will have to duplicate the rules to each zone and manage them completely separately.

Hi there,

To me, it seems very practical and secure.
As is you have to have the administrators from both zones agreeing that a given hostname/subdomain is going to be in another zone:
The 1st one has to set up the DNS records from the desired subdomain pointing to the second zone, and the other has to create the custom hostname to receive it in their zone.
Any other way would not be as secure IMO.

Take care.

I suppose that is true, but at the very least it should be documented as a solution.
For example we can’t do this right now, because we didn’t buy Custom Hostnames, since we had no idea we would need them, because they are primarily meant for something completely different.

There are also some limitations to this solution involving custom hostnames. For example every hostname needs to have certificate, so it becomes hard to use one custom certificate for the whole zone. And there might be other limitations of custom hostnames, that I don’t know about.

Custom Hostnames are a feature of Cloudflare for SaaS. Is that what you are taking about here?

Yes. Like I mentioned in the original text, it looks like it can be used as part of an improvised substitute solution, but it is clearly not meant for it.

Cloudflare uses zones in the traditional DNS sense which is hierarchical. The domains in your first example (root zone) already take advantage of that. An API zone could be delegated if the naming structure was implemented in the same way and *

Custom hostnames are a valid use case for non-hierarchical settings (e.g. arbitrary hostnames). It could also be achieved using an infrastructure as code with something like Terraform.

I recognize this is a feature suggestion thread and it’s not a bad suggestion; but it goes against the existing design paradigm and would likely be a heavy development lift. You’ve identified the best existing solution in custom hostnames if you don’t want to go the IAC route.

1 Like

The explanation of hierarchical structure makes sense. But I suspect we won’t be the only ones where organizational structure and use cases don’t fully match it.
By clearly not meant for it I meant, that I haven’t found any documentation, that would suggest, that use case like this is expected.
What do you mean by IaC solution? Do you mean creating multiple zones and keeping them consistent using IaC?

That or managing exceptions / per hostname settings for groupings of hostnames using automation (e.g. per hostname TLS settings or WAF rulesets / rule exceptions).