In a hosted deployment, using the original design for multi-domain Kolab, each registered (parent) domain is assigned a separate root dn / database for its LDAP hierarchy.

This means that with thousands of domains being registered, the LDAP server spends a lot of time maintaining way too many databases, for otherwise separate legal entities that are not at all sufficiently large to justify the overhead.

A new structure for this would be to:

• in the domain base dn for the management domain:

dn: associatedDomain=%s,ou=Domains,dc=hoster,dc=com
(...)
inetdomainbasedn: ou=%s,dc=hosted,dc=com

should result in *@%s being resolved to use ou=%s,dc=hosted,dc=com.

Additional domains (aka. alias domains) should be considered child domains -- the parent domain is the boss over it, but the child domains are aliases that can separately be given a status of active (means ownership confirmed);

• in the domain base dn for the management domain:

dn: associatedDomain=%s,ou=Domains,dc=hoster,dc=com
(...)
objectclass: extensibleObject
inetdomainbasedn: ou=%s,dc=hosted,dc=com
inetdomainstatus: active

dn: associatedDomain=%s2,associatedDomain=%s1,ou=Domains,dc=hoster,dc=com
(...)
inetdomainbasedn: ou=%s1,dc=hosted,dc=com
inetdomainstatus: new

This structure could ultimately also allow resellers (tenants) to specify the child domain is to be administered separately:

• in the domain base dn for the management domain:

dn: associatedDomain=%s,ou=Domains,dc=hoster,dc=com
(...)
objectclass: extensibleObject
inetdomainbasedn: ou=%s,dc=hosted,dc=com
inetdomainstatus: active

dn: associatedDomain=%s2,associatedDomain=%s1,ou=Domains,dc=hoster,dc=com
(...)
inetdomainbasedn: ou=%s2,dc=hosted,dc=com
inetdomainstatus: active

The question is how various pieces of infrastructure need to be modified in order to be able to address this new structure.