Osterprojekt 2023: DNSSEC

23.05.2023

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:

Artikel, die hierher verlinken

Osterprojekt 2023: ACME

04.06.2023

Das Osterprojekt dieses Jahr sollte sich mit EMail-Servern, Nameservern, DNSSEC und ACME (LetsEncrypt) beschäftigen- in Teil 1 berichtete ich über die Einrichtung eines authoritative DNS server für die diversen Server in meinem Docker-Zoo. Heute soll es um die Einrichtung eines lokalen ACME Servers für die automatisierte Verteilung von TLS-Serverzertifikaten unter dem Trust-Anchor der eigenen PKI gehen.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Brian May, Kerry Ellis & Vittorio Grigolo: Bohemian Rhapsody

    19.05.2019

    Eine andere Sicht auf den schönen Queen-Klassiker

    Weiterlesen...

Neueste Artikel

  • sQLshell, SQLite und Redis - oh my!

    Ich habe in letzter Zeit hin und wieder mit der sQLshell und SQLite herumgespielt - Neulich wurde ich gefragt, ob die sQLshell eigentlich auch Redis kann...

    Weiterlesen...
  • bad-certificates Version 3.0.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern wurde um eine weitere Kategorie von Zertifikaten erweitert

    Weiterlesen...
  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.