Overall, I suspect that there is some misunderstanding that leads to this question.
Is there any reason why you would want to split things between two DNS services like this at all?
DNS is a tree, where a zone is defined by the parent zone delegating some name within that zone to some set of nameservers, where the new zone starts.
You cannot delegate the apex of your zone from within your own zone. If you want your zone to be delegated elsewhere, you wouldn't have the zone in this other place in the first place, rather change the delegation in the parent zone according to where the zone should actually be.
Ie, if you have the zone myapp.example
you can delegate foo.myapp.example
(which means that foo.myapp.example
and everything below it is a new zone) from within your zone, but not myapp.example
itself (this would have to be done from the parent zone).
From your description, my impression is that what you actually want is to delegate myapp.example
to Cloudflare, and from there delegate foo.myapp.example
to DigitalOcean. This would be technically possible and does make sense if the delegation to DigitalOcean actually serves a purpose.
However, I would question even this setup, simply because it's unclear that the delegation to DigitalOcean serves any purpose.
You probably just need to delegate myapp.example
to Cloudflare and be done with it. You don't generally need delegations in DNS just because you are using different hosting providers for different hosts, etc.
You can simply add for example address records (A
/AAAA
) on the Cloudflare side referring to the addresses of your DigitalOcean hosts to have for example foo.myapp.example
resolve to the DigitalOcean host.
One provider-specific further complication with the original plan is that Cloudflare only allows you to set up registrable domains in their system (by policy, this is not an inherent technical limitation). So you can set up the domain myapp.example
in Cloudflare but not the domain test.myapp.example
, as the latter is not registrable in itself.