Provide a subdomain for core infrastructure services

[garloff]

We have the sovereignit.cloud I have a subdomain gx-scs.sovereignit.cloud and plan to create further subdomains for each SCS cloud. We could easily add scs.sovereignit.cloud subdomain for our own central services. Does that work for you?

Sidenote: I also have sovereignit.tech which can be used to point subdomains to designate, allowing user-controlled subsubdomains in this namespace -- I would not use this as this is a namespace that has a lot of things neither under our nor under the provider's control.

Discussion:

1. We could just use the sovereignit.cloud namespace and share it between the SCS project and the operators (but not the users who have sovereignit.tech).
2. We could use a third domain. 2a: sovereignit.space: => For the SCS project itself 2b: sovereignit.cloud: => For the SCS cloud providers (operators) 2c: sovereignit.tech: => For the tenant users (designate) We could still swap 2a and 2c, maybe that would be a better naming.

[berendt]

If we use sovereignit.space for the SCS project itself we should use this domain accordingly for the registry. I would then suggest registry.sovereignit.space.

scs.sovereignit.cloud would then be the domain for the current gx-scs.okeanos.dev environment. This is not related to internal services of SCS. The internal services should not run on the demonstrator.

[garloff]

OK, so here's my current thinking: 1a: scs.community => Our public face 1b: scs.koeln => Internal (development) 2a: sovereignit.tech => Public SCS project infrastructure 2b: sovereignit.cloud => SCS partner cloud providers 2c: sovereignit.space => SCS customer domains (served by designate of SCS clouds)

[joshmue]

Another option may be to make use of subdomains extensively.

E. g.

1. scs.community -> Landing page
2. registry.scs.community -> Container registry
3. docs.scs.community -> Rendered documentation
4. providers.scs.community -> Partners cloud providers
5. plusserver.providers.scs.community -> Partners cloud providers (Plusserver Subpage)

(Does not have to be scs.community, these are just for example).

This IMHO makes it much easier to evaluate authenticity/ownership for anyone who is not too familiar with the project yet. For example: When sovereignit or scs is registered by SCS on many (but not all) TLD's, there is AFAIK no straight-forward way to validate that e. g. sovereignit.wiki is a domain owned by SCS or not. In this example, sovereignit.wiki would look very legit, but may be bought by anyone right now.

[berendt]

Would definitely put our core infrastructure on a different domain than the CSPs.

sovereignit.* I would prefer because then it is uniform everywhere.

But the argument about the mapping because of the other name is justified.

[garloff]

Hi Joshua, Christian,

so here's my current proposal:

1. Anything official from the SCS project => scs.community. Landing page, registry, docs, ...
2. SCS internal infrastructure continues to live in scs.koeln
3. Partner clouds go to sovereignit.cloud 4, Partner DNS domains can get subdomains in sovereignit.space

[joshmue]

Regarding the exact DNS setup for the core infrastructure services:

Next to the possibility of maintaining all DNS records manually in the registrar, it should be also possible to manage records dynamically via external-dns. Either writing (1) directly to the configuration at the registrar or (2) to a DNS service running on the infra K8s managing a domain like infra.scs.community via delegation. This may reduce the work of maintaining the records in the long run.

I'd be fine with any option - also in the current case of harbor/registry. @garloff @berendt What would you prefer?

[fkr]

this can be closed, corret?