DNS im Homelab - This is the way!

Jeder echte Geek fängt irgendwann an, sich zuhause ein Home Lab einzurichten, die meisten haben sogar schon eins. Der Fernseher hat eine IP, der Laptop, hinzu kommt das NAS und vielleicht ein kleiner Server. Jetzt wird es spannend, denn echte Geeks kennen natürlich von allen Geräten die IP Adresse im 192.168.0.1/24 oder sonstigen Netzen, aber viel schönes ist es doch mit sprechenden Namen, spätestens wenn IPv6 zuhause einzieht.

In meiner Infrastruktur nutze ich inzwischen TP-Link Omada Hard- und Software und bin entsetzt, dass hier keine - zumindest rudimentäre - DNS-Verwaltung eingebaut ist. Entsprechend bin ich für einige Zeit mit dem Technitium DNS-Server gut gefahren.

Use-Case - Der Proxy regelt

Mein Use-Case ist relativ simpel: Ein nginx Reverse Proxy (I know, I am old-school) nimmt quasi alle Anfragen entgegen und schiebt sie großteils an die richtige Docker Container weiter (arcane über forgejo bis vaultwarden), aber auch an das NAS, den Hermes Agenten oder irgendein ESP32-Experiment, was gerade läuft. Prinzipiell total einfach und gut, Zone in Technitium anlegen, Catchall einrichten - also alle Anfragen an den nginx - und die wenigen Ausnahmen, die es gibt, händisch als Weiterleitungen einrichten. Blöd, wenn der nginx ausfällt, aber wozu habe ich mir alle IPs und Ports auswendig gemerkt, geht auch ;)

SSL-Zertifikate - Möglichst einheitlich

Spannend wird es dann, wenn ich über Zertifikate nachdenke. Um ein SSL-Zertifikat zu bekommen, braucht es einer vertrauenswürdigen Stelle, die das Zertifikat ausstellt, damit im Browser nicht immer die Warnung "unsichere Verbindung kommt". Aktuelle Best Practice ist irgendwas mit Let's Encrypt, ich regel das mit acme.sh. Natürlich kann man jetzt Zertifikate selbst signieren und das Zertifikat als gültig importieren, aber das fühlt sich aus unterschiedlichen Gründen wie eine Krücke an. Einer davon ist, dass im Home Lab auch die ein oder andere nach außen zur Verfügung gestellt werden soll. Dann muss ich schon zwei verschiedene Verfahren für Zertifikate nutzen, was ich gerne vermeiden würde. Alles gleich, nur die internen Dienste sollen auch wirklich nur intern erreichbar sein.

Dedizierte Domain für das Homelab

Auch hier ist die Überlegung spannend, wie benennt man die lokale Domain eigentlich? dienst.homelab.local oder dienst.homelab.internal oder ganz anders? Als ich Anfang des Jahres von Cloudflare zu zu deSEC.io gewechselt bin, habe ich auch die ein oder andere Domain mitgenommen, die ich bisher zwar "besitze", aber für nichts benutze. Nennen wir sie mein-homelab.de.

Im Domain Management kann ich nun statt öffentlich erreichbarer IPs auch interne aus meinem Heimnetz eintragen. Logisch, diese werden nicht aus dem freien Internet zugänglich sein, aber sobald ich im Heimnetz bin (physisch oder via Wireguard/VPN), funktioniert die Domain-Auflösung. Nehmen wir an ich habe drei physische Geräte:

1. Mini-Rechner mit Docker unter 192.168.0.15, die unter der Subdomain ovi.mein-homelab.de erreichbar sein soll
2. NAS unter 192.168.0.41, das unter der Subdomain gallimimus.mein-homelab.de erreichbar sein soll
3. Stationärer Rechner unter 192.168.0.51, den ich über gigantoraptor.mein-homelab.de ansprechen möchte.

Das Ganze sieht dann mit den korrekten A-Einträgen in etwa so aus, das * schickt alles, was nicht definiert ist an ovi (das spart Konfiguration für jeden neuen Service, der im Docker-Host angelegt wird):

DNS statt HTTP Mode für SSL

Ich erwähnte bereits, dass ich Old-School unterwegs bin mit dem nginx, somit habe ich auch immer old-school Zertifikate via HTTP verifiziert. Damit niemand außer dem rechtmäßigen Eigentümer von mein-homelab.de ein vertrauenswürdiges Zertifikat für einen Host dieses Namens anlegen kann, muss im Zertifizierungsprozess ein Besitznachweis in Form von "Leg diese Datei auf den Webserver mit folgenden Inhalt, wenn du das kannst glaube ich als Zertifizierungsstelle dir, dass du der Besitzer bist und stelle dir das Zertifikat aus".

In meinem Homelab klappt es aber ganz und gar nicht, dass jemand außerhalb meiner vier Wände eine Datei von ovi abfragen kann. Die Lösung heißt: DNS Mode.

Mein acme.sh läuft im Docker Container und da reicht es, folgende Environment-Variablen zu setzen:

  ACME_CHALLENGE: DNS-01
  ACMESH_DNS_API_CONFIG: |-
    DNS_API: dns_desec
    DESEC_TOKEN: ${DESEC_TOKEN}

Im Ergebnis habe ich jetzt eine "normale" Internetdomain, die jedoch unerreichbar ist für jedweden Hacker außerhalb meines eigenen Netzwerks, aber ansonsten genauso behandelt wird, wie jede andere Domain. Passwortmanager stolpern nicht über lokale Domainendungen, Docker-Dienste sehen sich als normale .de Dienste und es kommt zu keinen Konflikten zwischen local, internal, oder lan-Endungen und die Kosten für eine DE-Domain im Jahr liegen mit 6 Euro auch deutlich im bezahlbaren Bereich.

Dazu kommt, dass man den internen DNS-Server einfach ausschalten kann und ein Stückchen Komplexität reduziert hat. Yay!