Das Osterprojekt dieses Jahr sollte sich mit EMail-Servern, Nameservern, DNSSEC und ACME (LetsEncrypt) beschäftigen.

Ich wollte mich dieses Jahr im Frühjahr (abgesehen von meinem Garten) mit Dingen beschäftigen, die ich viel zu lange links liegengelassen hatte: Ich wollte versuchen, im kleinen in meinem Heimlabor die automatische Verteilung von Zertifikaten ähnlich LetsEncrypt per ACME zu realisieren. Das war vor allem deswegen notwendig, weil ich eine neue Mailserverlösung namens Mailu ausprobieren wollte die versprach, direkt in Docker zu funktionieren (Bisher hatte ich ja vor allem mit iRedMail große Erfolge gefeiert).

Um einen MailServer ordentlich betreiben zu können ist es aber unbedingt nötig, den DNS-Server für die eigene(n) Domain(s) unter Kontrolle zu haben und dort die für den EMail-Server nötigen Records anlegen und verwalten zu können. Damit war Etappe 1 meines Projektes bereits definiert: Mein bisheriges Heimlabor wies nämlich noch keinen Nameserver auf - obwohl ich über Traefik erfolgreich diverse Server in meinem Docker-Zoo in verschiedenen Domains betreibe. Dafür habe ich mich bisher eines Tricks bedient: Ich benutzte einen DNSSEC-fähigen DNS Recursor namens PowerDNS Recursor, der die Eigenschaft hat, zur Auflösung ihm unbekannter Namen nicht nur autoritative Server zu benutzen, sondern - sofern man dies wünscht auch die Datei /etc/hosts dazu zu verwenden. Und so habe ich bisher alle meine Docker-Server in die entsprechende Datei eingetragen und war zufrieden. Nun sollte aber ein richtiger Nameserver her - ich überlegte kurz, hier ebenfalls PowerDNS (Authoritative Server) einzusetzen, stellte aber schnell fest, dass die mir vorschwebende Lösung damit nicht zu realisieren war. Es handelte sich schließlich immer noch um ein Heimlabor - und da einen DNS-Server aufzusetzen, der eine relationale Datenbank benötigt erschien mir doch ein wenig hochgegriffen. Daher entschied ich mich, wieder auf (mir) Vertrautes und Altbewährtes zurückzugreifen und setzte wieder auf BIND9. Nachdem ich die entsprechenden Zonen eingerichtet hatte, musste ich lediglich die Schlüssel erzeugen, die Zonen signieren und die Trust Anchors in PiHole eintragen. Pihole ist ja mein eigentlicher Nameserver, der als Fallback bei unbekannten Namen bisher PowerDNS Recursor angefragt hatte. Dort hatte ich in der Konfigurationsdatei /etc/powerdns/recursor.conf meinen neuen Authoritative Resolver für die neuen Zonen eingetragen. Für die Signierung der Zonen mussten zunächst in /etc/bind die entsprechenden Schlüssel mittels

dnssec-keygen -a RSASHA256 -b 2048 -n ZONE docker.lab
dnssec-keygen -f KSK -a RSASHA256 -b 4096 -n ZONE docker.lab

angelegt und mittels

for key in `ls Kdocker.lab*.key`; do echo "\$INCLUDE $key">>db.docker.lab; done

in die Zone-Files eingefügt werden. Anschließend konnte die Signierung mittels

dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N INCREMENT -o docker.lab -t db.docker.lab

durchgeführt werden. Nun musste man noch kontrollieren, ob named.conf.local wirklich auf die signierten Versionen der Zone-Files verwies. Damit funktioniert in meinem Szenario die Namensauflösung aber noch nicht: Am PiHole ist Schluss, da er die Signaturen der Zonen nicht als von einer vertrauenswürdigen Autorität stammend ablehnt. Man muss dem PiHole nun noch die Trust-Anchors beibiegen. In /etc/bin entstehen beim Prozess der Schlüsselerstellung Dateien, deren Namen mit dsset beginnen. Deren Inhalt ist das, was benötigt wird, einen oder mehrere neue Trust-Anchors zu definieren. Die Datei /etc/dnsmasq.d/01-pihole.conf kann als Vorbild dienen - allerdings ist hier Vorsicht geboten: diese Datei kann bei Updates überschrieben werden, daher ist es sicherer, die neuen Trust-Anchors in einer Datei neben dieser abzulegen - man könnte sie zum Beispiel /etc/dnsmasq.d/02-pihole.conf nennen...

Zum Abschluss nun noch einige Links, die mir dabei geholfen haben, dieses Gebiet zu durchdringen:

Links

Artikel, die hierher verlinken