docs: document installation, secrets and setup steps

docs/README.md

@@ -42,7 +42,15 @@ Host specific configuration can be found at `nixos/hosts/tuxcord-XX`. This is us
 
 To learn how to get started, refer to the [Getting Started guide](./GETTING_STARTED.md).
 
-The guide contains basic instructions as to how to use Nix for this repository, as well as tools to help in certain tasks.
+The guide contains basic instructions as to how to use Nix for this repository, as well as tools to help in certain tasks, some of this tools might be assumed accross document resources.
+
+It might also be useful to read the [installation section](#installation) to learn how to configure your testing environment.
+
+# Installation
+
+Though the nix configuration already does most heavy-lifting already. There's some minor configuration that has to be done to the mutable state of the machine.
+
+Each aspect of it should be carefully explained in the [Setup Guide](./SETUP.md).
 
 # Contributions
 

docs/SECRETS.md

@@ -0,0 +1,28 @@
+# Secrets
+
+Secrets are managed with `agenix` in the `agenix/` directory. This allows to declaratively define secrets as well as which keys are allowed to decrypt them.
+
+# Usage
+
+The `agenix` help menu is already very helpful, but here you have a survival guide:
+
+- `agenix` commands should run relative to the `agenix/` direcotry.
+- `agenix -d` allows you to descrypt such file if you possess any of the decryption keys.
+- `agenix -e` decrypts (if present) and opens the file in your editor to re-encrypt when exited.
+- `agenix -r` re-encypts `*.age` files in the case you ever change its decryption keys.
+
+# Secrets
+
+<!-- TODO: missing ntfy.sh secret docs -->
+
+## DNS TSIG Keys
+
+The DNS server takes zone updates through `nsupdate` with symmetric TSIG keys.
+
+These keys can be generated using `tsig-keygen <key-name>` (historically they were done with `dnssec-keygen` and `HMAC` algorithms, but this is no longer supported).
+
+When DNS is enabled for a host, it will look for `dns/${fqdn}/${zone}.key` secrets.
+
+- The key whose zone matches the `${fqdn}` will be allowed to tramit updates for all the domain.
+- Keys restrained to a specific `${subdomain}` will only be allowed to edit records of such subdomain.
+- All keys must be named with the zone they affect, final dot included, so that (e.g. `tuxcord.net/javalsai.tuxcord.net.key` must be generated by `tsig-keygen javalsai.tuxcord.net.`).

docs/SETUP.md

@@ -0,0 +1,60 @@
+# Setup Steps
+
+The first configuration of the server needs some configuration of its mutable state:
+
+Setup also heavily relies on the secrets configured, make sure you [undestand agenix](./SECRETS.md) good enough.
+
+# SSH Keys
+
+Most agenix secrets have to be decrypted by the machine nixos is being installed to. For this, agenix uses the ssh host keys.
+
+This also means that no secrets will be accessible on the host right after a base installation, with the default fresh ssh keys.
+
+Will will need to either migrate ssh keys from another host, if you are doing a migration, or take the public keys of the new host out to encrypt agenix secrets against them. These keys, both public and private are present in `/etc/ssh/ssh_host_*`, we have a strong preference in favor of elliptic curve cryptography.
+
+Also note that ssh keys are persistent and will be saved across machine boots and virtual machine rebuilds, so you don't need to repeat this process every time.
+
+# DNS SOA Record
+
+If the DNS server is enabled for the host (`dns.enable`), the host will have a DNS server for itself that can take updates with `nsupdate`.
+
+This section assumes surface-level knowledge of DNS records, as well as a IPv4-only server.
+
+First of all, make sure that the secrets for `nsudpate` ([DNS TSIG Keys](./SECRETS.md)) are in place, otherwise the server won't be able to take updates and will remain on an empty useless state.
+
+You need to tell it it has authority over itself (`SOA` -> `Start Of Authority`) for it to take updates and serve changes properly, as well as configure the base `A` records.
+
+`/var/dns/${fqdn}.zone`:
+
+```zone
+$ORIGIN ${fqdn}.
+$TTL 14400 ; 4 hours
+@ IN SOA ${fqdn}. ${adminEmail} (
+                                2026050301 ; serial
+                                3600       ; refresh (1 hour)
+                                1800       ; retry (30 minutes)
+                                604800     ; expire (1 week)
+                                86400      ; minimum (1 day)
+                                )
+
+@ A ${ip}
+
+ns1 A ${ip}
+@ NS ns1
+ns2 A ${ip}
+@ NS ns2
+
+* CNAME ${fqdn}.
+```
+
+Note the template variables:
+
+- You need to place your FQDN in `${fqdn}` (there are shorter ways, but this guarantees functionality even if the hostname and domain don't match).
+- Also an IPv4 address at `${ip}`.
+- And lastly, `${adminEmail}` the SOA record has a `RNAME` field that takes the administrator's email address with dot notation (`test@example.com` would be written as `test.example.com.`).
+- The values related to serial number and lifetimes can and should be tweaked depending on the use-case. Especially `serial`, note that it resembles a date.
+
+Then restart bind with `systemctl restart bind`. Make sure that the file is owned by `named:named`.
+
+> [!NOTE]
+> This file is **mutable**, bind can and **will** change it with `nsupdate`s, it also tends to format and compact this template into a certain layout.