Draft: FQDNs for libre.moe #58

New Issue

lukas · 2024-12-02T12:38:52+01:00

lukas commented

2024-12-02 12:38:52 +01:00

Use FQDNs based on a unique definition of each service as well as a canonical name in addition to the common user-friendly names.

Take the example of git.libre.moe, which is a user-friendly name for the hostname of the server sahaquiel.libre.moe hosting this service. This change would use a different approach with additional names for all services.

user access point git.libre.moe is an alias of
canonical hostname gitea.service.libre.moe
FQDN: gitea-web.sahaquiel.infra.libre.moe

The service.libre.moe name could provide a web-service endpoint, listing all available services on libre.moe and their current system status

New Naming Rules

The new setup would follow these rules:

User Access Point:

<friendly-name>.libre.moe

Canonical Hostname

<service>.service.libre.moe

We use the canonical names to uniquely identify a target service to keep internal (back)links consistent in case the user-access-point changes. In case we ever have a HA system set-up, this would be the load-balancer hostname, routing to one of the available backend hosts. As long a service is hosted on this domain, this canonical name will stay the same (unless a service changes their name and a change of the canonical name would be useful, but in that case the legacy name would likely still remain routeable as an alias of the new canonical name)

Fully Qualified Domain Name

<service>-<role>[-<environment>].<host>.infra.libre.moe

We use the FQDN to refer to a specific instance, useful for migrating from one server to another or with potential HA setups. If an instance switches servers, the old FQDN will become invalid.

Hosts under libre.moe will drop the prefix before <host>.infra.libre.moe and become routeable soley under this name instead.

Definition

Where each of the components means the following:

friendly-name refers to a easily recognizable name (like "git" or "cloud") but can also just mean service (like "nextcloud") if applicable.
service is the exact name of a service (like "nextcloud" or "onlyoffice")
role defines the type of service (like web, ssh, api, ...)
environment differentiates between the various stages of readiness a service might be in (like prod, dev, staging, test) but can be optional if there is only one environment, where the lack of a service would refer to the production environment).
host refers to the hostname of the system hosting said service. Everything hosted on the server sahaquiel would therefore be a prefix of sahaquiel.infra.libre.moe, with this being the FQDN of the server itself.

Wildcard Certificates for FQDNs

With this approach, a wildcard certificate for each host will become very useful, as all services under this host can be added referenced by a DNS name without needing to request a new certificate.

Whether all hosts own wildcard certs for *.libre.moe and *.service.libre.moe or not is yet to be determined.

Use FQDNs based on a unique definition of each service as well as a canonical name in addition to the common user-friendly names. Take the example of `git.libre.moe`, which is a user-friendly name for the hostname of the server `sahaquiel.libre.moe` hosting this service. This change would use a different approach with additional names for all services. - user access point `git.libre.moe` is an alias of - canonical hostname `gitea.service.libre.moe` - FQDN: `gitea-web.sahaquiel.infra.libre.moe` The `service.libre.moe` name could provide a web-service endpoint, listing all available services on libre.moe and their current system status ## New Naming Rules The new setup would follow these rules: **User Access Point:** ``` <friendly-name>.libre.moe ``` **Canonical Hostname** ``` <service>.service.libre.moe ``` We use the canonical names to uniquely identify a target service to keep internal (back)links consistent in case the user-access-point changes. In case we ever have a HA system set-up, this would be the load-balancer hostname, routing to one of the available backend hosts. As long a service is hosted on this domain, this canonical name will stay the same (unless a service changes their name and a change of the canonical name would be useful, but in that case the legacy name would likely still remain routeable as an alias of the new canonical name) **Fully Qualified Domain Name** ``` <service>-<role>[-<environment>].<host>.infra.libre.moe ``` We use the FQDN to refer to a specific instance, useful for migrating from one server to another or with potential HA setups. If an instance switches servers, the old FQDN will become invalid. Hosts under libre.moe will drop the prefix before `<host>.infra.libre.moe` and become routeable soley under this name instead. ### Definition Where each of the components means the following: - `friendly-name` refers to a easily recognizable name (like "git" or "cloud") but can also just mean `service` (like "nextcloud") if applicable. - `service` is the exact name of a service (like "nextcloud" or "onlyoffice") - `role` defines the type of service (like web, ssh, api, ...) - `environment` differentiates between the various stages of readiness a service might be in (like prod, dev, staging, test) but can be optional if there is only one environment, where the lack of a service would refer to the production environment). - `host` refers to the hostname of the system hosting said service. Everything hosted on the server `sahaquiel` would therefore be a prefix of `sahaquiel.infra.libre.moe`, with this being the FQDN of the server itself. ### Wildcard Certificates for FQDNs With this approach, a wildcard certificate for each host will become very useful, as all services under this host can be added referenced by a DNS name without needing to request a new certificate. Whether all hosts own wildcard certs for `*.libre.moe` and `*.service.libre.moe` or not is yet to be determined.

lukas added the

labels 2024-12-02 12:38:52 +01:00

lukas self-assigned this 2024-12-02 12:38:52 +01:00

lukas added this to the Issue Board project 2024-12-02 12:38:52 +01:00

lukas referenced this issue

2024-12-11 11:13:50 +01:00