Infrastructure as Code to manage DNS configurations

[btlogy]

Scope

AsIs: The DNS configurations of tahoe-lafs.org are manually managed by Meejah and/or Brian via the ​admin WebUI provided by the DNS registrar and hosting 3rd party ​Gandi.

The current DNS configurations lack of visibility, reproducibility and agility, making it difficult, error-prone and slow to be audited, reviewed, changed or improved.

ToBe: The DNS configuration would be declaratively defined in a version-controlled repository and deployed using automated workflows, based on the principle of Infrastructure as Code (IaC).

Value

• Contributors would be able to see the current configurations and propose changes using a well known workflow (pull request).
• Maintainers would be able to approve and deploy changes w/o direct interact with the DNS provider.
• The configurations and the workflows would be consistent, repeatable, and easily auditable.

Requirements

• A fresh export of the DNS tahoe-lafs.org zone hosted by Gandi (optional)
• A valid Personal Access Token (PAT) to read/write this zone via ​API of Gandi
• Permissions to create/manage secrets in ​infrastructure repository
• ​OpenToFu plan defining the current state in the existing ​infrastructure repository (WiP ​here)
• Automated workflow (e.g.: using GHA) to continuously integrate and deploy the plan (WiP ​here)

Additional information

This enhancement is a very nice to have requirement for the execution of the MoveOffTrac project (in which we are already planning to re-use and expand the existing ​Infrastructure as Code repository:

• #4161

And has already been discussed here:

• #3742

In addtion, it could help making progress/improvement on those issues:

• #2717
• #2718
• #2719
• #2772
• #4142
• #4160

[btlogy]

The Gandi API allows to create Personal Access Token with some granularity in terms of:

• validity: for 7, 30, 60, 90 days or 1 year
• resources: the whole org. or only some specific domains (e.g.: tahoe-lafs.org)
• permissions, 16 levels of which the following 2 should suffice in our use case:
  • "See and renew domain names" (required by the next one):
    • See the organization's domain names, domain contact information, history and technical configuration.
    • Renew and restore domain names
    • See incoming transfers status, resend FOAs and update authinfo codes for incoming transfers.
  • "Manage domain name technical configurations":
    • Edit domain technical configuration (nameservers, DNS records, glue records, DNSSEC, and web forwarding).

[btlogy]

If this is not already the case (and if it still is possible), it would preferable to have the "tahoe-lafs.org" domain assigned to what Gandi defines as an organization (which does not have to be a legal entity).

Alternatively, the domain could stay assigned to the individual who's has first registered the name, because Gandi seems to treat each user account as an "user organization" anyway. Though, the steps below will then give access to all other domains (and products) own by that individual. Which may not be a problem as long as all those resources are solely related to Tahoe-LAFS...

Here are the proposed steps based on test made in the sandbox of Gandi:

1. Create a team under the selected organization (e.g.: "DomainOps")

2. Give this team only 2 additional permissions (on top of the default "View Organization") in the "Domains" scope: "See and renew domain names" and "Manage domain name technical configurations"

3. Add members to this team by inviting them via their email address.

This should allow new members to create and rotate Personal Access Token which will be used as secrets by (GitHub) runners to manage the DNS records (and nothing else).

Unfortunately, the sandbox does not allow to fully test the steps above. So it might be needed to add the permission to "Manage personal access tokens" from the "Organization" scope to the team...