Extend DNS documentation

Explain to users how to add their own nsupdate keys, allow the key to do
something and how our dnssec is handled.

Signed-off-by: Wachtl Enterprises LLC <tyrolyean@escpe.net>

docs/space/srv-acraze/dns.md

@@ -34,12 +34,56 @@ The `.cuco` TLD for the cunst subnet is also served on here.
 
 ### Configuration
 
-Configuration file is `/etc/named.conf`. The master zone files are located in
-`/var/named/zones/`. If you want to edit a zone file, first freeze them with
-`rndc freeze <domain>`, then edit the file, and unfreeze with `rndc thaw`.
-Root zones may be static, meaning there is no need to freeze them. In that case,
-you can get bind to reload the zone file using the `rndc reload <domain>`
-command.
+Configuration file is `/etc/named.conf`. It's permissions are supposed to be
+`600`, to protect the tsig-keys stored inside.
+
+#### Update records
+
+The master zone files are located in `/var/named/zones/`. If you want to edit a
+zone file, first freeze them with `rndc freeze <domain>`, then edit the file,
+and unfreeze with `rndc thaw`. Root zones may be static, meaning there is no
+need to freeze them. rndc will inform you via the
+`rndc: 'freeze' failed: not dynamic` message of this. In that case, you can get
+bind to reload the zone file using the `rndc reload <domain>` command.
+
+
+#### Add a key for nsupdate
+
+You need this if you want to perform letsencrypt dns challenges, or want to
+perform dyndns to an rr.
+
+First, generate a key using `tsig-keygen -a hmac-sha512 <NAME>` with NAME
+being, given our usage of this key further on, the non-FQDN name of the machine.
+It does not need to match the record the key is used further on, we set this
+relation further down by hand.
+
+Copy the key into your application and into `/etc/named.conf`. Next locate the
+`update-policy` section in your zone. If it doesn't have one, the zone is not
+dynamic. If you add a `update-policy` section, beware that this will alter the
+on-disk zone file and remove all hand formatting of the zone, which will
+afterwards be sorted alphabetically as well.
+
+You need to add a new rule to allow your nsupdate, which you need to craft by
+hand using
+[ISC's documentation](https://bind9.readthedocs.io/en/latest/reference.html#dynamic-update-policies)
+or from one of the examples below:
+
+```
+grant <NAME>. name _acme-challenge.<RR>.srv.it-syndikat.org. TXT;
+```
+
+The rule above allows the key <NAME> to perform a letsencrypt dns-01 challenge
+for `<RR>.srv.it-syndikat.org.` and `*.<RR>.srv.it-syndikat.org`.
+
+```
+grant <NAME>. wildcard *.srv.it-syndikat.org. A AAAA DHCID TXT;
+```
+
+This is what we use for our dhcp ddns setup. This DDNS key needs to be able to
+add TXT/DHCID records as well, to store information about the record and if it
+belongs to the DHCP server, or has been set manually. Kea uses the DHCID field
+for this, whilest ISC-DHCP uses the TXT record. We allow both, as to not break
+our future probable migration to kea.
 
 ### Zone transfers
 
@@ -58,4 +102,19 @@ zones are signed and the KSKs are delegated to us from the TLD NSes.
 Bind automatically manages DNSSEC keys and key rollovers using it's builtin
 `dnssec-policy`. Our current ed25519 based policy consists of a KSK which never
 expires and delegates the authority to the ZSK, which handles zone signing and
-is replaced every 60 days.
+is replaced every 60 days, which looks something like this:
+
+```
+dnssec-policy "its-policy" {
+	keys {
+		ksk lifetime unlimited algorithm ed25519;
+		zsk lifetime P60D algorithm ed25519;
+	};
+};
+```
+
+A zone is automatically DNSSEC signed, once you set it's `key-directory` and
+`dnssec-policy` fields. Whilest this option is cryptographically secure, some
+recursors do not support ed25519 at this time. All recursors we and our members
+operate do though, which is why we only sign using ed25519, and not any other
+key variant.