Zum Inhalt

Unsere Zonen

Diese Seite beschreibt unsere beiden DNS-Zonen, wer sie betreibt, was darin steht und warum jedes Caddy ein eigenes, eingeschränktes Token für deSEC hat. Wie die Zonendateien aufgebaut sind und wie sie zu deSEC kommen, steht in Verwaltung mit desync.

Wer was macht

Aufgabe Wer Verwaltet über
Domains registrieren (garage-lab.de, garage-lab.net) Webhoster hosting.de als Registrar Web-Oberfläche von hosting.de
Nameserver für beide Zonen betreiben deSEC –
Einträge (Records) und Token-Policies wir Repo, Ordner desec/, ausgerollt mit desync
Domains und Tokens bei deSEC anlegen wir Web-Oberfläche von deSEC

Beim Registrar ist für beide Domains eingetragen, dass deSEC ihre Nameserver stellt. Wer im Internet einen Namen wie md.garage-lab.de nachschlägt, bekommt die Antwort also von deSEC, und dort steht, was wir im Repo eintragen.

Warum wir die Domains in der Web-Oberfläche von hosting.de verwalten und nicht per Code, steht in hosting.de.

Unsere Nameserver betreibt deSEC, nicht hosting.de. Auch hosting.de bietet Nameserver und eine vollständige API an. Tokens lassen sich dort aber nicht auf einzelne Einträge beschränken, und es gibt kein Werkzeug wie desync dafür. Bei deSEC geht beides: desync setzt über die API alle Einträge und die Rechte der Tokens, und die Tokens lassen sich auf einzelne Einträge beschränken; darauf bauen die Token-Policies auf.

Die DNS-Einträge liegen im Repo. Wie bei den Hosts sieht man im Repo, was eingetragen ist, wer es wann geändert hat und warum. Einträge, die jemand an der Datei vorbei bei deSEC anlegt, zeigt der nächste plan.

Die Zonen

garage-lab.de (desec/desec_garage_lab_de.cue)
Die öffentliche Domain des Vereins. Darin stehen die Adressen von allem, was aus dem Internet erreichbar ist: die Webseite und das Wiki beim Webhoster, die Apps auf werner und login für Authentik bei server.camp. Dazu kommen die Einträge für E-Mail (Postfächer beim Webhoster, siehe Eingehende E-Mails, und Versand über Mailjet, siehe Ausgehende E-Mails) und Nachweise für externe Dienste, die prüfen wollen, dass uns die Domain gehört.
garage-lab.net (desec/desec_garage_lab_net.cue)
Die Domain für das Netz im Maschinendorf, also für containerhost, das NAS und die Apps auf containerhost. Bei deSEC stehen für diese Namen keine Adressen; aufgelöst werden sie vom DNS-Server auf dem Gateway im Maschinendorf, also nur im Netz vor Ort und über den WireGuard-Tunnel (siehe Netzwerk). So lässt sich von außen nicht nachschlagen, welche Geräte und Dienste es im Maschinendorf gibt. Die öffentliche Zone enthält nur, was von außen gebraucht wird: die _acme-challenge-Einträge für die Zertifikate, die Einträge für den Mailversand über Mailjet und einen CAA-Eintrag, nach dem nur Let's Encrypt Zertifikate für die Domain ausstellen darf.

Token-Policies

Beide Caddy-Instanzen holen ihre Zertifikate per DNS-Challenge: Sie schreiben für jeden Hostnamen kurz einen TXT-Record _acme-challenge.<subdomain> über die API von deSEC (siehe Caddy). Dafür hat jedes Caddy ein eigenes Token bei deSEC.

Was ein Token darf, legt seine Token-Policy fest, und die steht am Ende der Zonendatei unter desec: tokenPolicies. Für das Caddy auf werner ist das der Block "2262403e-…" in desec/desec_garage_lab_de.cue, zum Beispiel:

Text Only
1
{domain: "garage-lab.de", subname: "_acme-challenge.md", type: "TXT", permWrite: true},

Das Token darf also den TXT-Record _acme-challenge.md in garage-lab.de schreiben, den Caddy für das Zertifikat von md.garage-lab.de braucht. Für jeden Hostnamen auf werner gibt es so eine Zeile. Alles, was nicht ausdrücklich erlaubt ist, darf das Token nicht; diese Grundregel ergänzt desync von selbst. Der Block "2f198c18-…" in desec/desec_garage_lab_net.cue macht dasselbe für das Caddy auf containerhost.

Die lange Zeichenfolge ist die ID des Tokens bei deSEC, nicht das Token selbst; das liegt verschlüsselt als Secret caddy-desectoken beim jeweiligen Host.

Jedes Caddy hat ein eigenes, eingeschränktes Token. Ein Token liegt im Klartext auf dem Host, auf dem sein Caddy läuft (siehe Podman Secrets). Wird ein Host kompromittiert, lassen sich mit dem Token nur die _acme-challenge-Einträge dieses Hosts schreiben. Die Webseite, die Mail-Einträge oder die Apps des anderen Hosts lassen sich damit nicht umbiegen. Mit einem Token für die ganze Zone ließe sich dagegen jeder Name auf einen fremden Server umleiten.

Neue App: zuerst DNS und Token-Policy

Eine neue App mit eigenem Hostnamen braucht in der Zonendatei zwei Dinge: den Eintrag für den Namen selbst und die Zeile _acme-challenge.<subdomain> in der Token-Policy des Caddy auf ihrem Host. Fehlt die Zeile, bekommt die App kein Zertifikat, und Caddy versucht es erst nach langer Wartezeit erneut. Die Reihenfolge steht in App hinzufügen.

Weiterlesen