Bear with me, this is a little complicated to explain.

Using an XC delegated domain, with automatic DNS and certificates, I can create a load balancer for the following:

my.domain

*.my.domain

I can now use routes etc. to host a service on my.domain, api.my.domain, static.my.domain, etc. and the DNS and certs will be taken care of. I can't automatically use a second level, e.g. service1.api.my.domain, because wildcard certs are innately only valid for one level, rather than multiple levels. (The DNS wildcard does allow this though.)

Now let's suppose I add an additional level to this, so my load balancer includes:

my.domain

*.my.domain

*.api.my.domain

I can now host on my.domain and static.my.domain, and anything under api, e.g. service1.api.my.domain. However, api.my.domain at its base level will no longer work with this configuration. This is because of the innate peculiarities of the DNS wildcard system.

In order to allow api.my.domain to be routed in this case, I would need to add api.my.domain explicitly as a domain to the LB. However XC does not allow me to do this, as it regards it as being already available via the *.my.domain entry. This is true in a certificate sense, but no longer true in a DNS sense, once I have also defined the child wildcard.

XC should allow both the parent and children to work in this case. One way would be to lift the restriction on adding the almost-but-not-quite-redundant api.my.domain and bypassing the warning that it's already covered by a wildcard in this case, as that is no longer entirely true. Another option would be to detect a scenario where both *.my.domain and *.something.my.domain are attached to an LB, and create an explicit A record for something.my.domain in this particular case to keep DNS working as one might have expected.