DNSSEC, DANE und MTA-STS im Blick behalten – warum mir Uptime Kuma nicht mehr reichte

Monitoring gehört für mich zum Pflichtprogramm, wenn man eigene Dienste betreibt. Jahrelang war Uptime Kuma mein Werkzeug der Wahl – zu Recht: Es ist schlank, hübsch, selbst gehostet und beantwortet die wichtigste Frage zuverlässig: Läuft der Dienst noch? HTTP, TCP, Ping, Zertifikatsablauf – alles da, alles grün.

Irgendwann habe ich aber gemerkt, dass genau dieses „alles grün" trügerisch sein kann. Die Ausfälle, die mir wirklich wehgetan haben, waren nämlich keine klassischen Down-Ereignisse. Der Server lief, der Port war offen, Uptime Kuma zeigte grün – und trotzdem war etwas kaputt, nur eben eine Schicht tiefer: in der DNSSEC-Kette und in der Mail-Sicherheit. Dort schaut Uptime Kuma schlicht nicht hin. Deshalb habe ich mir ein eigenes kleines Werkzeug gebaut, das genau diese Lücke schließt – und das stelle ich hier zum Download bereit.

Wo Uptime Kuma (bewusst) aufhört

Uptime Kuma ist ein Erreichbarkeits-Monitor. Das ist keine Schwäche, das ist sein Zweck. Aber es gibt eine Reihe von Fehlerbildern, die damit prinzipbedingt durchrutschen:

• Ablaufende RRSIG-Signaturen. DNSSEC-Signaturen haben ein Ablaufdatum. Läuft eine Signatur ab, ohne dass rechtzeitig neu signiert wurde, verschwindet die Domain für validierende Resolver – von einer Sekunde auf die andere, ohne dass am Server irgendetwas „down" wäre. Das ist der klassische stille Killer.
• Halbfertige Key-Rollover. Wenn nach einem Schlüsselwechsel nicht alle autoritativen Nameserver denselben DNSKEY-Satz ausliefern, validiert mal die eine, mal die andere Anfrage – ein sporadischer, schwer zu fassender Fehler.
• DS-Bruch am Parent. Passt der DS-Eintrag bei der Registry nicht (mehr) zum KSK der Zone, ist die Vertrauenskette unterbrochen.
• DANE/TLSA, das nicht mehr zum Zertifikat passt. Wird das Mailserver-Zertifikat erneuert, aber der TLSA-Record nicht aktualisiert, lehnen strikte Gegenstellen die Zustellung ab. Der Mailserver läuft weiter – Mails kommen trotzdem nicht mehr an.
• MTA-STS-Policy, die den MX nicht abdeckt. Steht in der Policy nicht der richtige MX (oder ist das Policy-Zertifikat ungültig), verwerfen Enforce-Sender die Zustellung.

Für all das brauchte ich einen Monitor, der die DNSSEC-Kette wirklich prüft, die Signaturlaufzeiten im Auge behält, DANE gegen das echte, live präsentierte Zertifikat abgleicht und die MTA-STS-Policy gegen die tatsächlichen MX-Hosts hält. Uptime Kuma nachzurüsten wäre der falsche Weg gewesen – also ist es ein eigenes, fokussiertes Tool geworden.

Was der DNSSEC-Monitor prüft

Pro Domain laufen im Hintergrund – in einstellbaren Intervallen von 5 Minuten bis 24 Stunden – diese Prüfungen:

• DNSSEC-Validierung aus Client-Sicht über frei wählbare, validierende Resolver (AD-Bit).
• Jeder autoritative Nameserver einzeln auf gültige, vorhandene Signaturen – und ein Konsistenz-Check, ob alle NS denselben DNSKEY-Satz liefern.
• DS am Parent gegen den KSK der Zone.
• RRSIG-Restlaufzeit mit Vorwarnung (gelb/rot), bevor eine Signatur abläuft.
• DANE/TLSA am Mailserver: TLSA vorhanden, DNSSEC-validiert und gegen das per STARTTLS präsentierte Zertifikat geprüft.
• MTA-STS: TXT-Record, Policy über HTTPS mit gültigem Zertifikat, Modus/max_age plausibel, und ob die Policy die echten MX-Hosts abdeckt.
• Erreichbarkeit wie gewohnt: ICMP-Ping, TCP-Port, HTTP(S) – inklusive Latenz-Verlauf.

Dazu gibt es eine tägliche Status-Mail und eine Alarm-Mail bei Fehlern (mit Entprellung, damit ein einzelner Timeout nicht sofort piept).

Wie es aufgebaut ist

Das Ganze ist ein einziger, selbst gehosteter Python-Prozess: Hintergrund-Poller, Web-Dashboard und Mail-Benachrichtigung in einem. Die Checks sind nativ mit dnspython und cryptography umgesetzt – ich lese die Signaturlaufzeiten also direkt aus den Records und gleiche DANE-Fingerprints selbst ab, statt dig-Ausgaben zu parsen. Das macht das Tool unabhängig davon, welche Kommandozeilen-Werkzeuge auf dem Host installiert sind.

Das Dashboard ist bewusst schlicht und ohne externe Abhängigkeiten (kein CDN, kein Fremd-JavaScript): eine vertikale Liste aller Domains, jede auf- und zuklappbar, darunter die Bereiche DNSSEC / Mail / Ping – ebenfalls einzeln aufklappbar. Pro Prüfung gibt es Heartbeat-Balken wie bei Uptime Kuma, eine Latenz-Sparkline und die Verfügbarkeit für 24 Stunden und 7 Tage. Es gibt ein helles und ein dunkles Theme mit Umschalter, einen optionalen Passwort-Login und – seit der letzten Ausbaustufe – einen Admin-Tab, über den man Domains direkt im Browser anlegt und per Häkchen entscheidet, was überwacht werden soll (nur Ping, nur Mail-Dienste, nur DNSSEC – ganz wie man mag). Gespeichert wird alles in einer SQLite-Datei, geplant über einen internen Scheduler.

Am besten in einem eigenen kleinen LXC-Container

Ein Punkt, der mir wichtig ist und den ich dir ausdrücklich empfehle: Lass den Monitor nicht auf demselben System laufen, das er überwacht. Ein Monitor sollte nicht dasselbe Schicksal teilen wie die Dienste, die er beobachtet. Läuft er auf deinem Mail-/Web-Host und der hat ein Problem – Reboot, Überlast, Netzausfall – dann ist der Monitor genau in dem Moment mit weg, in dem du ihn brauchst. Dazu kommt: DNSSEC und DANE will man aus einer möglichst unabhängigen Perspektive prüfen, nicht von genau dem Server, der die Zonen selbst ausliefert. Und die Alarm-Mails sollten idealerweise nicht über den Mailserver laufen, den du gerade überwachst – sonst verschluckt ein Mailserver-Ausfall seine eigene Alarmierung.

In der Praxis heißt das: ein kleiner, separater Container genügt völlig. Ich betreibe das Ganze als eigenen LXC-Container auf Proxmox – quasi als kleinen Testserver bzw. Monitor-Knoten neben allem anderen. 512 MB RAM, 1 vCPU und rund 1 GB Plattenplatz reichen dick aus. Wer es maximal unabhängig will, nimmt einen kleinen externen VPS; für den Hausgebrauch ist der separate LXC der beste Kompromiss.

Schnellstart

Auf dem (frischen) Container:

apt update && apt install -y python3-venv python3-pip unzip iputils-ping
unzip dnssec-monitor.zip -d /opt
cd /opt/dnssec-monitor
python3 -m venv venv && ./venv/bin/pip install -r requirements.txt
cp config.example.yaml config.yaml
./venv/bin/python tools/hashpw.py        # Passwort-Hash erzeugen -> in config.yaml eintragen
nano config.yaml                        # SMTP, Resolver, Grundeinstellungen
./venv/bin/python run.py -c config.yaml    # Dashboard: http://<container-ip>:8080

Läuft das Dashboard, richtest du es als Dienst ein (die passende systemd-Unit liegt bei) und legst deine Domains anschließend bequem über den Admin-Tab im Browser an. Wer davor ein sauberes HTTPS möchte, stellt einen Reverse-Proxy (Apache, nginx oder Caddy) mit eigenem Hostnamen davor.

Wenn alles läuft, dann einfach als Dienst starten:

sudo cp dnssec-monitor.service /etc/systemd/system/
sudo systemctl daemon-reload && sudo systemctl enable --now dnssec-monitor

Download

dnssec-monitor.zip – hier herunterladen

Eine ausführliche README mit allen Konfigurationsoptionen liegt dem Archiv bei.

Ehrliche Einordnung

Das ist ein persönliches Projekt, entstanden aus einem konkreten eigenen Bedarf – kein poliertes Produkt mit Support-Hotline. Ich stelle es „so wie es ist" zur Verfügung, ohne Gewähr. Prüfe es nach dem ersten Start einmal gegen eine bekannt funktionierende und eine bekannt kaputte Domain, damit du dem Ergebnis vertraust. Der DANE-Normalfall für SMTP (DANE-EE gegen das Server-Zertifikat) ist abgedeckt; sehr exotische Konstellationen musst du gegebenenfalls selbst nachschärfen. Rückmeldungen und Verbesserungen sind willkommen.

Wenn du selbst eigene Zonen mit DNSSEC signierst und einen Mailserver mit DANE oder MTA-STS betreibst, ist so ein fokussierter Monitor aus meiner Sicht eine sinnvolle Ergänzung – nicht als Ersatz für Uptime Kuma, sondern als das ehrlichere Auge auf die Schicht, die sonst niemand anschaut.