Eigenes Projekt: DNSSEC-, DANE- & MTA-STS-Monitor (Flask/LXC) – Weil netcup-DNSSEC manchmal seinen eigenen Kopf hat 😉

bori

Hi zusammen,

DNSSEC und Netcup, das ist ja leider ein schwieriges Thema , wer seine Domains und vor allem den Mailserver bei netcup (oder auch anderen Anbietern!) betreibt und dabei auf moderne Security-Standards setzt, kennt das leidige Thema: DNSSEC und Netcup ist ja historisch bedingt so eine Sache – mal läuft es wochenlang unauffällig, und plötzlich geht gar nix mehr..

Da klassische Monitoring-Tools wie Uptime Kuma bei solchen Protokoll-Tiefenprüfungen (RRSIG, DS-Records, DANE/MTA-STS) mangels passender Details leider schnell die Segel streichen, habe ich mir in den letzten Wochen (mit Hilfe von Claude) kurzerhand selbst Abhilfe geschaffen.

Herausgekommen ist ein kleiner, feiner DNSSEC- und Service-Monitor, der jetzt schlank in einem LXC-Container vor sich hin rödelt.

Ein paar Highlights aus der Praxis:

Blick unter die Haube: Prüft genau die kryptografischen Details und Validierungen, die für einen sauberen Mailserver-Betrieb absolut kritisch sind.
Dashboard: Modernes Dark-Mode-Design, Status-Pillen, Heartbeat-Historie und Latenz-Sparklines (optisch stark an bewährte Tools angelehnt, aber mit deutlich mehr DNS-Durchblick).
Technischer Unterbau: Geschrieben in Python (Flask) mit einer leichten SQLite-Datenbank. Frisst nahezu keine Ressourcen.

Wer genauer wissen will, warum mir Standard-Tools für diesen Anwendungsfall nicht mehr reichten und wie das Ganze gewachsen ist, kann gerne mal in meinem Blog vorbeischauen: DNSSEC, DANE und MTA-STS im Blick behalten auf alexnolte.de.

Vielleicht ist das ja für den einen oder anderen hier im Forum auch ein spannendes Projekt, um die eigene Infrastruktur besser im Blick zu behalten. Wie überwacht ihr eure Zonen und Mailserver? CheckMK und Co. geht natürlich auch, aber das war mir dann schon wieder zu viel...

VG Alex

debonner

Woher kommt mir die Idee nur bekannt vor , habe ich mir auch gebaut. Da die API bei netcup echt schrecklich ist liegen die Domains bei Cloudflare und mittels "vernünftiger" API Anbindung kann ich die Zonen abfragen und live validieren. Vorteil, ändere ich etwas in Cloudflare wird dies hier automatisch hinzugefügt und die Änderung protokolliert (siehe TXT).

Bildschirmfoto 2026-08-26 um 17.48.40.png

SiebenG

Ich habe dafür kleine Sktipte für uptime kuma mit Push-Monitor, ich mags einfach

Habe ich mir auch mal vor einiger Zeit mit Hilfe von KI zusammengebastelt, so sieht es aus, falls für jemand hilfreich. Die Skripte einfach per cron aufrufen (Ausgabe nach dev/null, da einige echo's drin haben zum debuggen).

DNSSEC (delv muss installiert sein):

Bash

#!/bin/bash

DOMAIN="example.com"
RESOLVER="9.9.9.9" # Quad9 unterstützt DNSSEC-Validierung streng
PUSH_URL="https://kuma.example.com/api/push/TOKEN?status=up&msg=OK"

# DNSSEC-Validierung via delv durchführen
# Sucht nach dem Indikator "; fully validated" in der Ausgabe
OUTPUT=$(delv @"$RESOLVER" "$DOMAIN" +multi +dnssec 2>&1)

if echo "$OUTPUT" | grep -q "; fully validated"; then
    # Erfolg: Sende Signal an Uptime Kuma
    curl -s "$PUSH_URL" > /dev/null
    echo "DNSSEC für $DOMAIN erfolgreich validiert."
else
    # Fehler: Skript bricht ab, Kuma erhält keinen Push und geht "Down"
    echo "FAIL: DNSSEC-Validierung für $DOMAIN fehlgeschlagen!"
    echo "$OUTPUT"
    exit 1
fi

Alles anzeigen

DANE (danetool muss installiert sein):

Bash

#!/bin/bash

DOMAIN="mail.example.com"
KUMA_URL="https://kuma.example.com/api/push/TOKEN"

# DANE-Prüfung über STARTTLS auf Port 25 ausführen
# danetool gibt bei Erfolg 0 zurück, bei Fehlern einen Wert > 0
danetool --check "$DOMAIN" --proto tcp --port 25 --starttls-proto=smtp > /tmp/dane_result.txt 2>&1
STATUS=$?

if [ $STATUS -eq 0 ]; then
    # Erfolg: Kuma mit "up" signalisieren
    curl -s "${KUMA_URL}?status=up&msg=DANE+and+DNSSEC+valid" > /dev/null
    echo "Okay: "$STATUS
else
    # Fehler: Letzte Zeile des Fehlers auslesen und an Kuma senden ("down")
    ERROR_MSG=$(tail -n 1 /tmp/dane_result.txt | tr ' ' '+')
    echo "Error: "$ERROR_MSG
    curl -s "${KUMA_URL}?status=down&msg=DANE+Error:+${ERROR_MSG}" > /dev/null
fi

Alles anzeigen

MTS-STS:

Bash

#!/bin/bash

DOMAIN="example.com"
MX_HOST="mail.example.com"  
KUMA_URL="https://kuma.example.com/api/push/TOKEN"
# ---------------------

# 1. DNS TXT-Eintrag prüfen
echo "[1/3] Prüfe DNS TXT-Eintrag (_mta-sts.$DOMAIN)..."
DNS_CHECK=$(dig +short TXT _mta-sts."$DOMAIN" | grep "v=STSv1")

if [ -z "$DNS_CHECK" ]; then
    echo "-> ERROR: Kein '_mta-sts' TXT-Eintrag im DNS gefunden!"
    echo "Sende Status 'down' an Uptime Kuma."
    curl -s "${KUMA_URL}?status=down&msg=MTA-STS+Error:+Kein+_mta-sts+TXT-Eintrag+im+DNS+gefunden." > /dev/null
    exit 1
fi
echo "-> OK: DNS TXT-Eintrag vorhanden ($DNS_CHECK)."

# 2. HTTPS Policy-Datei herunterladen
echo "[2/3] Rufe Policy-Datei ab (https://mta-sts.$DOMAIN/.well-known/mta-sts.txt)..."
POLICY_CONTENT=$(curl -sSf "https://mta-sts.${DOMAIN}/.well-known/mta-sts.txt" 2>&1)
CURL_STATUS=$?

if [ $CURL_STATUS -ne 0 ]; then
    echo "-> ERROR: Policy-Datei über HTTPS nicht erreichbar oder HTTP-Fehler!"
    echo "Sende Status 'down' an Uptime Kuma."
    curl -s "${KUMA_URL}?status=down&msg=MTA-STS+Error:+Policy-Datei+ueber+HTTPS+nicht+erreichbar." > /dev/null
    exit 1
fi
echo "-> OK: Datei erfolgreich heruntergeladen."

# 3. Inhalt der Policy validieren
echo "[3/3] Validiere den Inhalt der Policy-Datei..."

# Prüfen, ob der Modus auf "enforce" oder "testing" steht
if ! echo "$POLICY_CONTENT" | grep -qE "mode:[[:space:]]*(enforce|testing)"; then
    echo "-> ERROR: Kein gültiger Modus (mode: enforce/testing) in der Datei gefunden!"
    echo "Sende Status 'down' an Uptime Kuma."
    curl -s "${KUMA_URL}?status=down&msg=MTA-STS+Error:+Kein+gueltiger+mode+(enforce/testing)+in+Datei." > /dev/null
    exit 1
fi

 Prüfen, ob Ihr Mailserver als erlaubter MX gelistet ist
if ! echo "$POLICY_CONTENT" | grep -qF "mx: $MX_HOST"; then
    echo "-> ERROR: Der MX-Host '$MX_HOST' ist in der Policy-Datei nicht als 'mx:' erlaubt!"
    echo "Sende Status 'down' an Uptime Kuma."
    curl -s "${KUMA_URL}?status=down&msg=MTA-STS+Error:+MX-Host+${MX_HOST}+nicht+in+der+Policy+erlaubt." > /dev/null
    exit 1
fi

# Wenn alle Prüfungen bestanden wurden
echo "SUCCESS: Alle MTA-STS-Prüfungen bestanden! Sende Status 'up' an Uptime Kuma."
curl -s "${KUMA_URL}?status=up&msg=MTA-STS+vollstaendig+validiert" > /dev/null

Alles anzeigen

notfound404

Zitat von SiebenG

Habe ich mir auch mal vor einiger Zeit mit Hilfe von KI zusammengebastelt, so sieht es aus, falls für jemand hilfreich. Die Skripte einfach per cron aufrufen (Ausgabe nach dev/null, da einige echo's drin haben zum debuggen).

DNSSEC (delv muss installiert sein):

Bash

#!/bin/bash

DOMAIN="example.com"
RESOLVER="9.9.9.9" # Quad9 unterstützt DNSSEC-Validierung streng
PUSH_URL="https://kuma.example.com/api/push/TOKEN?status=up&msg=OK"

# DNSSEC-Validierung via delv durchführen
# Sucht nach dem Indikator "; fully validated" in der Ausgabe
OUTPUT=$(delv @"$RESOLVER" "$DOMAIN" +multi +dnssec 2>&1)

if echo "$OUTPUT" | grep -q "; fully validated"; then
    # Erfolg: Sende Signal an Uptime Kuma
    curl -s "$PUSH_URL" > /dev/null
    echo "DNSSEC für $DOMAIN erfolgreich validiert."
else
    # Fehler: Skript bricht ab, Kuma erhält keinen Push und geht "Down"
    echo "FAIL: DNSSEC-Validierung für $DOMAIN fehlgeschlagen!"
    echo "$OUTPUT"
    exit 1
fi

Alles anzeigen

Von dem verstehe ich nicht den Sinn.

Kann ich da nicht einfach in Uptime Kuma als Monitortyp DNS auswählen und dann als Hostname die zu überprüfende Domain und als Resolver-Server einen DNSSC-validierenden wie eben 9.9.9.9? Wenn dann DNSSEC kaputtgeht müsste doch ein SERVFAIL zurückgeliefert werden und damit ich mir den Umweg über das Skript sparen(?).

Oder habe ich da einen Denkfehler?

SiebenG

Zitat von notfound404

Von dem verstehe ich nicht den Sinn.
Kann ich da nicht einfach in Uptime Kuma als Monitortyp DNS auswählen und dann als Hostname die zu überprüfende Domain und als Resolver-Server einen DNSSC-validierenden wie eben 9.9.9.9? Wenn dann DNSSEC kaputtgeht müsste doch ein SERVFAIL zurückgeliefert werden und damit ich mir den Umweg über das Skript sparen(?).
Oder habe ich da einen Denkfehler?

Die Idee war damals, möglichst schnell zu erfahren, sobald DNSSEC kaputt ist. Die KI hatte hier delv empfohlen, da es wohl das caching der resolver umgeht und die ganze Kette direkt überprüft.

Nachdem ich mir das aber gerade nochmal nach deinem heads-up angeschaut habe, ist das aber wahrscheinlich so nicht der Fall, da delv ja auch beim quad9 nachfragt...

Vermutlich wäre es schlauer, da direkt den NS der Domain zu verwenden (?). Ist dann jetzt die Frage, ob dann ein direkter kuma-Monitor, welcher auch den NS direkt befragt, nicht doch auch gleichschnell einen Ausfall melden würde... ich bin überfragt...

Weitere Überlegungen willkommen, bei mir steht der Feldtest bald an (da noch alle Domains im alten Netcup DNS und beim Umzug wird's ja bekanntermaßen Scheppern.. )

NaN

Du kannst nicht einfach einen der autoritativen Nameserver als Resolver verwenden, weil die keine rekursiven Abfragen erlauben. Der Test muss ja gerade die fehlerhaften Records in der übergeordneten Zone erkennen, also reicht die autoritative Antwort für die Domain selbst nicht aus. Mit einem einfachen "löst das noch auf" Test kommst du nicht am Caching vorbei. Schneller geht es nur, wenn du die Nameserver der übergeordneten Zone direkt nach den DS Records für deine Domain fragst, aber die werden nicht glücklich darüber sein, wenn da jetzt jeder ständig direkt nachfragt und die TTL ignoriert.

Wenn ihr DNSSEC nutzt oder nutzen wollt, lasst eure Domains auf das Clouddns System migrieren. Im alten System ist DNSSEC nach Berichten hier im Forum nicht mehr aktivierbar, aber es ist ein beworbenes Feature, also fordert es ein (aber nett bleiben). Vielleicht wartet ihr damit bis nach dem Wochenende.

bttr

Zitat von NaN

Im alten System ist DNSSEC nach Berichten hier im Forum nicht mehr aktivierbar

Ich hatte gestern keine Probleme es für zwei Domains zu aktivieren.

notfound404

Zitat von bttr

Ich hatte gestern keine Probleme es für zwei Domains zu aktivieren.

Nicht CloudDNS? Sicher?

Beitrag

RE: DNSSEC Status - funktioniert es mittlerweile?

Antwort auf mein Support-Ticket:

[…]

Wie komme ich auf eine funktionierende Nameserverinfrastruktur?

m3um25z

5. November 2026 um 14:08

bttr

Zitat von notfound404

Nicht CloudDNS? Sicher?

Woher weiß ich, ob ich CloudDNS nutze? Bewusst habe ich jedenfalls keinen Wechsel angestoßen.

Habe bei DNSSEC die von deSEC gelieferten Daten eingetragen. Das war zumindest kein Problem.

notfound404

Zeig einfach mal einen Screenshot wie dein DNSSEC-Menü ausschaut. Ist DNSSEC ein separater Tab? Dann ist es CloudDNS.

Zitat von bttr

Habe bei DNSSEC die von deSEC gelieferten Daten eingetragen. Das war zumindest kein Problem.

Dann ist es aber sowieso kein Problem. In den ganzen Beiträgen hier im Forum ging es fast immer um die netcup-Nameserver.

bttr

Zitat von notfound404

Zeig einfach mal einen Screenshot wie dein DNSSEC-Menü ausschaut. Ist DNSSEC ein separater Tab? Dann ist es CloudDNS.

Nein, kein separater Tab.

Gibt nur den Tab "DNS". Oben die beiden deSEC-DNS-Server und drunter dann der DNSSEC-Schlüssel.

Zitat von notfound404

Dann ist es aber sowieso kein Problem. In den ganzen Beiträgen hier im Forum ging es fast immer um die netcup-Nameserver.

Verstehe. Hatte das hier nur nebenbei mitbekommen und habe mich dann aus Neugier bei deSEC angemeldet, die Domains hinterlegt, die Records bei Netcup abgeschrieben und per DNSControl zu deSEC gepusht. Zuletzt dann DNSSEC aktiviert. War ziemlich straight forward.

notfound404

Zitat von bttr

Nein, kein separater Tab.
Gibt nur den Tab "DNS". Oben die beiden deSEC-DNS-Server und drunter dann der DNSSEC-Schlüssel.

Dann ist es tatsächlich das alte/Legacy-System.

Interessant, dann scheint es da zumindest mit externem Nameserver noch zu funktionieren (wobei das ja eigentlich nicht nur da selbstverständlich sein sollte)

SiebenG

Zitat von NaN

Du kannst nicht einfach einen der autoritativen Nameserver als Resolver verwenden, weil die keine rekursiven Abfragen erlauben.

Das ist mir dann auch aufgefallen 🤣

Zitat von NaN

Schneller geht es nur, wenn du die Nameserver der übergeordneten Zone direkt nach den DS Records für deine Domain fragst, aber die werden nicht glücklich darüber sein, wenn da jetzt jeder ständig direkt nachfragt und die TTL ignoriert.

Genau das habe ich mir jetzt mal als Skript zusammen zimmern (lassen). Abfrage der NS der übergeordneten Zone nach DS, Abfrage meines autoritativen NS nach dem DNSKEY und dann lokale Berechnung mit "dnssec-dsfromkey" ob's passt.

Scheint soweit zu laufen, Danke für die Idee!

NaN

Zitat von SiebenG

Danke für die Idee

Do you want rate limits? Because that's how you get rate limits.

SiebenG

Zitat von NaN

Do you want rate limits? Because that's how you get rate limits.

Meinst Du?

Es ist eine de-Domain und da gibt's 6 NS. ich wähle einen davon zufällig aus und den frage ich alle 5 Minuten einmal ab. Ich denke nicht, dass ich damit Unmut auf mich ziehe...

NaN

Zitat von SiebenG

Meinst Du?

Praktisch? Nein. Aber wenn das jeder machen würde...

m3rl1n

Ja, klar ... kommt immer auf die Summe an.

Aber für das kurzfristigere Monitoring bei schon bekannten Problemen ...? Hmm.

Ich hab mir das ganze auf jeden Fall mal gebookmarked, falls ich es ggf. mal brauchen sollte. Bisher habe ich mich da mit dem Thema DNSSEC eher zurückgehalten. Ich warte da auch wohl besser mal noch ein bisschen ab, wenn ich die Beiträge dazu hier im Forum so lese

Eigenes Projekt: DNSSEC-, DANE- & MTA-STS-Monitor (Flask/LXC) – Weil netcup-DNSSEC manchmal seinen eigenen Kopf hat 😉

RE: DNSSEC Status - funktioniert es mittlerweile?

Tags

Benutzer online in diesem Thema