DANE für den eigenen Mailserver auf einer netcup-Domain: DNSSEC, TLSA und Postfix

Mailserver verschlüsseln untereinander meist mit STARTTLS, prüfen das Zertifikat der Gegenseite aber nicht. Wer sich in die Verbindung hängt, kann die Verschlüsselung unterdrücken oder ein eigenes Zertifikat vorlegen. DANE schließt diese Lücke: Ein TLSA-Eintrag im DNS sagt, welcher Schlüssel zum Mailserver gehört, und DNSSEC sorgt dafür, dass niemand diesen Eintrag fälschen kann. Diese Anleitung zeigt den ganzen Weg für eine Domain bei netcup: DNSSEC im CCP einschalten, den TLSA-Wert berechnen, den Eintrag im CloudDNS oder per netcup-API anlegen, Postfix für ausgehendes DANE einrichten und alles mit echten Meldungen prüfen.

Dies ist Teil 16 der Reihe „netcup Spezial“.

Was DANE beim Mailversand leistet

Ein Absender mit DANE-Unterstützung fragt vor der Zustellung den TLSA-Eintrag für Port 25 des MX-Hosts ab, zum Beispiel _25._tcp.mail.example.de. Ist die Antwort per DNSSEC bestätigt, muss das Zertifikat des Empfängers dazu passen. Postfix beschreibt das Verhalten der Stufe dane so: Ohne TLSA-Eintrag arbeitet es wie may, also mit ungeprüfter Verschlüsselung. Gibt es brauchbare TLSA-Einträge, muss das Zertifikat passen.

Für Mailserver kommen nur zwei Arten von TLSA-Einträgen in Frage: 3 (DANE-EE, der Schlüssel des Servers selbst) und 2 (DANE-TA, eine eigene Zertifizierungsstelle). Postfix behandelt die Arten 0 und 1 bei SMTP als unbrauchbar. Diese Anleitung nutzt 3 1 1: Schlüssel des Servers (3), nur der öffentliche Schlüssel statt des ganzen Zertifikats (1), als SHA-256-Wert (1). Der Vorteil: Bleibt der Schlüssel bei der Erneuerung des Zertifikats gleich, bleibt auch der TLSA-Wert gleich.

Voraussetzungen

• Eine Domain bei netcup, die die netcup-Nameserver im CloudDNS nutzt (netcup.firstns.cc bis netcup.fifthns.com). Für den klassischen netcup-DNS gilt DNSSEC bei netcup aktivieren.
• Ein Mailserver mit Postfix, hier Postfix unter Ubuntu auf einem netcup-Server, mit Root-Zugang.
• A-Eintrag und MX-Eintrag für den Mailserver, zum Beispiel mail.example.de und MX 10 mail.example.de. Der Reverse-DNS der IP sollte auf denselben Namen zeigen, siehe Reverse-DNS im netcup SCP setzen.
• Ein gültiges Zertifikat für diesen Namen, das Postfix bereits für STARTTLS nutzt. Im Beispiel kommt es von Let's Encrypt, ausgestellt mit lego über die netcup-DNS-Challenge, wie in Teil 15 und in netcup DNS-API mit acme.sh.
• Zugang zum Customer Control Panel (CCP). Für den Weg per API zusätzlich ein Schlüssel für die netcup-REST-API.
• dig aus dem Paket bind9-dnsutils und openssl.

Schritt 1: DNSSEC im CCP einschalten

Öffnen Sie im CCP unter Domains die Domain. Seit der Umstellung auf CloudDNS gibt es dafür einen eigenen Reiter DNSSEC neben CloudDNS. Dort steht der Status „Deaktiviert“ und der Knopf DNSSEC aktivieren.

Das CCP fragt nach und warnt, dass eine falsche Konfiguration die Domain vorübergehend unerreichbar machen kann. Die Aktivierung soll laut Dialog bis zu 48 Stunden dauern.

Nach Bestätigen meldet das CCP „Der DNSSEC Eintrag wurde erfolgreich gespeichert“. Solange netcup die Änderung ausführt, sperrt der Reiter weitere Änderungen.

Im Test lief es deutlich schneller als angekündigt:

• 17:24 Uhr: DNSSEC im CCP eingeschaltet
• 17:27 Uhr: Schlüssel (DNSKEY 257 und 256, Algorithmus 13) auf dem netcup-Nameserver
• 17:30 Uhr: DS-Eintrag bei der DENIC, kurz darauf bestätigte Cloudflare (1.1.1.1) die Kette mit gesetztem AD-Flag

Verifizieren: Prüfen Sie Schlüssel, DS-Eintrag und Validierung einzeln. Ersetzen Sie example.de durch Ihre Domain:

dig +short DNSKEY example.de @netcup.firstns.cc
dig +short DS example.de @a.nic.de
dig +dnssec DNSKEY example.de @1.1.1.1 | grep '^;; flags'

Erwartet werden in der Regel zwei DNSKEY-Zeilen, eine DS-Zeile mit Algorithmus 13 und in den Flags ein ad. Im Test sah das so aus:

257 3 13 roSNxGBqMxgnwYk6su1kN8U9Whpah6O2Io+ABuOZbBSMnLtEHFQtu4/J 6rRcu1l8IYHfgdPyF/8nc49fFxZEbA==
256 3 13 Obcz5GqGpEj4Bx6D+chL+qHzImaJNrxIeXmDR+ynokHmQcKOLN35hrgh PP20tkznt2F/8Frbq6x1Js8JwQbJWQ==
28101 13 2 3A4BAE7539BFE525B147EECC61116151F467777B46DC3A2D85891E49 A7238EA4
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Ein ad in den Flags bestätigt die Kette. Fehlt es, ist sie noch nicht vollständig.

Schritt 2: Den TLSA-Wert berechnen

Der Wert für 3 1 1 ist der SHA-256-Wert des öffentlichen Schlüssels im DER-Format. Berechnen Sie ihn aus genau dem Zertifikat, das Postfix ausliefert. Den Pfad zeigt postconf smtpd_tls_chain_files (oder smtpd_tls_cert_file).

openssl x509 -in /etc/postfix/tls/mail.example.de.crt -noout -pubkey \
  | openssl pkey -pubin -outform DER | sha256sum | cut -d' ' -f1

Das Ergebnis ist eine Zeichenkette aus 64 Hexadezimalzeichen, im Test 14d26e07935312d0e6b07c554dc257f73494d21af44fcf831046c3d897abc314.

Verifizieren: Derselbe Wert erscheint später in der Ausgabe von posttls-finger als pkey_fingerprint, dort mit Doppelpunkten und in Großbuchstaben.

Schritt 3: Den TLSA-Eintrag anlegen

Der Eintrag gehört zum Namen des MX-Hosts, nicht zur Domain selbst. Bei MX 10 mail.example.de lautet er:

• Host: _25._tcp.mail
• Typ: TLSA
• Ziel: 3 1 1 14d26e07…c314 (der Wert aus Schritt 2)

Im CCP legen Sie ihn im Reiter CloudDNS wie jeden anderen Eintrag an, wie in DNS-Records bei netcup im CCP verwalten beschrieben. Per netcup-REST-API geht es mit einem Changeset. Die Domain-ID liefert GET https://api.netcup.com/v1/domain, den Schlüssel legen Sie vorher in der Variablen NETCUP_KEY ab:

curl -sS -X POST https://api.netcup.com/v1/domain/DOMAIN-ID/changeset \
  -H "Authorization: Bearer $NETCUP_KEY" -H "Content-Type: application/json" \
  -d '{"autoCommit":true,"strict":true,"create":[{"name":"_25._tcp.mail","type":"TLSA",
       "rdata":"3 1 1 14d26e07935312d0e6b07c554dc257f73494d21af44fcf831046c3d897abc314","ttl":3600}]}'

{"success":true,"errors":[],"messages":[],"meta":null,"result":{"identifier":"bd1806c5-…", …, "state":"active","serial":2}}

Mit "autoCommit":true wird das Changeset sofort aktiv und erhöht die Seriennummer der Zone. Senden Sie den Befehl von einem Rechner außerhalb des netcup-Netzes. Vom netcup-Server selbst kam die API im Test nicht an.

Verifizieren: Fragen Sie alle fünf Nameserver direkt ab. Im Test lieferten alle den neuen Eintrag nach rund 3 Minuten.

for ns in netcup.firstns.cc netcup.secondns.at netcup.thirdns.de netcup.fourthns.systems netcup.fifthns.com; do
  echo "$ns $(dig +short TLSA _25._tcp.mail.example.de @$ns)"
done

Haben Sie Ihre Domain gerade erst auf CloudDNS umgestellt, kontrollieren Sie den TLSA-Eintrag ausdrücklich. Im Test kamen A-, MX- und CAA-Einträge bei der Umstellung mit, der vorhandene TLSA-Eintrag fehlte danach und musste neu angelegt werden.

Schritt 4: Einen prüfenden Resolver bereitstellen

DANE nützt beim Versand nur, wenn der Resolver des Absenders DNSSEC prüft und das Ergebnis mit dem AD-Flag meldet. Der vorgegebene Resolver auf dem netcup-Server liefert keine geprüften Antworten. Ubuntu fragt über systemd-resolved, und systemd-resolved prüft DNSSEC selbst nicht:

resolvectl dnssec
Global: no
Link 2 (eth0): no

Installieren Sie deshalb Unbound. Das Ubuntu-Paket prüft DNSSEC ab Werk mit dem Root-Schlüssel aus /var/lib/unbound/root.key und lauscht auf 127.0.0.1:

apt-get install -y unbound
dig +dnssec TLSA _25._tcp.mail.example.de @127.0.0.1 | grep '^;; flags'

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Das ad in den Flags zeigt, dass Unbound die Antwort geprüft hat.

Jetzt kommt die Stelle, an der es bei Postfix leicht hakt: Der Versanddienst smtp läuft unter Ubuntu in einem Chroot. Er liest nicht /etc/resolv.conf, sondern eine Kopie im Postfix-Verzeichnis:

postconf -M smtp/unix
smtp       unix  -       -       y       -       -       smtp
cat /var/spool/postfix/etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

Diese Kopie erzeugt /usr/lib/postfix/configure-instance.sh bei jedem Start von Postfix aus /etc/resolv.conf. Ein postfix reload lässt sie dagegen unverändert. Tragen Sie Unbound direkt in die Kopie ein. Postfix warnt danach, dass sich die beiden resolv.conf unterscheiden, das ist hier gewollt.

printf 'nameserver 127.0.0.1\noptions edns0 trust-ad\n' > /var/spool/postfix/etc/resolv.conf
postfix reload

Damit die Einstellung einen Neustart übersteht, muss auch /etc/resolv.conf auf einen prüfenden Resolver zeigen. Zeigt sie weiter auf 127.0.0.53, steht nach dem nächsten Neustart von Postfix wieder der alte Resolver in der Kopie. Das haben wir nach dem Test so beobachtet. Prüfen Sie vor dieser Umstellung, welche anderen Dienste auf dem Server den Systemresolver nutzen.

Verifizieren: cat /var/spool/postfix/etc/resolv.conf zeigt nameserver 127.0.0.1.

Achtung: Solange /etc/resolv.conf noch auf 127.0.0.53 zeigt, schreibt Postfix bei jedem Neustart, auch nach einem Paketupdate, den alten Resolver zurück in seine Chroot-Kopie. Stellen Sie den Systemresolver dauerhaft auf einen prüfenden Resolver um, bevor Sie Schritt 5 dauerhaft einsetzen.

Schritt 5: Postfix für ausgehendes DANE einrichten

Drei Einstellungen in main.cf genügen. smtp_dns_support_level = dnssec lässt Postfix DNSSEC-Antworten auswerten, smtp_tls_security_level = dane schaltet DANE ein, und smtp_tls_loglevel = 1 schreibt das Ergebnis jeder TLS-Verbindung ins Log. Ohne die dritte Zeile sehen Sie im Log nur die Zustellung, nicht ob das Zertifikat geprüft wurde.

postconf -e "smtp_dns_support_level = dnssec" \
              "smtp_tls_security_level = dane" \
              "smtp_tls_loglevel = 1"
postfix check && postfix reload

Verifizieren: Lesen Sie das Log mit journalctl -u postfix@- -f, während Postfix an einen Server mit TLSA-Eintrag zustellt. Im Test stand dort:

postfix/smtp[207933]: Verified TLS connection established to mail.example.de[203.0.113.25]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256

„Verified“ heißt: Zertifikat und TLSA-Eintrag passen, und die DNS-Antwort war per DNSSEC bestätigt.

Den eigenen Mailserver von außen prüfen

Für die Gegenrichtung, also ob andere Server Ihren Mailserver per DANE prüfen können, bringt Postfix das Werkzeug posttls-finger mit. Es nutzt den Resolver aus /etc/resolv.conf. Damit Sie dafür nicht den Resolver des ganzen Servers umstellen müssen, startet der folgende Befehl posttls-finger in einem eigenen Mount-Namensraum, in dem nur für diesen Aufruf Unbound als Resolver eingetragen ist:

unshare -m sh -c 'printf "nameserver 127.0.0.1\noptions trust-ad\n" > /tmp/resolv.dane
  mount --bind /tmp/resolv.dane /etc/resolv.conf
  posttls-finger -t30 -T180 -c -l dane -L summary,certmatch example.de'

posttls-finger: mail.example.de[203.0.113.25]:25: Matched DANE EE certificate at depth 0: 3 1 1 14D26E07935312D0E6B07C554DC257F73494D21AF44FCF831046C3D897ABC314
posttls-finger: Verified TLS connection established to mail.example.de[203.0.113.25]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256

„Matched DANE EE certificate“ bestätigt, dass der Schlüssel zum TLSA-Eintrag passt.

Was bei einem falschen TLSA-Eintrag passiert

Wir haben den TLSA-Eintrag für den Test absichtlich verfälscht, nur das letzte Zeichen des Werts war anders. Spätestens nach 10 Minuten lieferten alle fünf netcup-Nameserver den falschen Wert. Damit Unbound nicht den alten Wert aus dem Cache nimmt, haben wir nur diesen einen Eintrag mit unbound-control flush_type _25._tcp.mail.example.de TLSA verworfen. Dann meldete posttls-finger:

posttls-finger: server certificate verification failed for mail.example.de[203.0.113.25]:25: num=65:no matching DANE TLSA records
posttls-finger: mail.example.de[203.0.113.25]:25: subject_CN=mail.example.de, issuer_CN=YE1, …, pkey_fingerprint=14:D2:6E:07:…:97:AB:C3:14
posttls-finger: Untrusted TLS connection established to mail.example.de[203.0.113.25]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256

Die Verbindung kommt zustande, gilt aber als nicht vertrauenswürdig. Ein Absender mit DANE stellt in diesem Fall nicht zu, denn laut Postfix-Dokumentation muss das Zertifikat passen, sobald brauchbare TLSA-Einträge vorliegen. Hilfreich für die Fehlersuche: pkey_fingerprint zeigt den Wert, der richtig wäre. Nach dem Zurücksetzen auf den richtigen Wert meldete posttls-finger wieder „Verified“.

Zertifikat erneuern, ohne DANE zu brechen

Let's-Encrypt-Zertifikate gelten derzeit 90 Tage, Let's Encrypt verkürzt die Laufzeit ab Februar 2027 schrittweise. Mit 3 1 1 hängt der TLSA-Wert nur am Schlüssel. Laut lego-Dokumentation erzeugt lego renew ohne die Option --reuse-key einen neuen Schlüssel, mit --reuse-key bleibt er gleich. Mit neuem Schlüssel passt der TLSA-Eintrag nicht mehr, und DANE-Absender stellen nicht mehr zu. Prüfen Sie deshalb nach jeder Erneuerung mit dem Befehl aus Schritt 2, ob der Wert noch derselbe ist.

Typische Fehler

Meldung oder Symptom	Ursache und Lösung
warning: DNSSEC validation may be unavailable, danach status=deferred (… Host not found, try again)	Postfix bekommt über den vorgegebenen Resolver keine geprüften Antworten. Im Test scheiterte danach die Adressabfrage des Mailservers, die Mail blieb in der Warteschlange. Unbound einrichten und in die Chroot-Kopie eintragen (Schritt 4).
num=65:no matching DANE TLSA records und Untrusted TLS connection	TLSA-Wert und Schlüssel passen nicht. Wert neu berechnen und mit pkey_fingerprint vergleichen.
Kein ad in der Antwort von dig	DS-Eintrag noch nicht bei der DENIC oder der befragte Resolver prüft nicht. Mit dig DS … @a.nic.de und einem prüfenden Resolver wie 1.1.1.1 gegenprüfen.
„Das Editieren der Daten ist derzeit nicht möglich“ im Reiter DNSSEC	netcup führt die Aktivierung noch aus. Prüfen Sie den Fortschritt mit dig wie in Schritt 1.
TLSA-Eintrag fehlt nach der Umstellung auf CloudDNS	Im Test wurde er nicht übernommen. Neu anlegen und an allen fünf Nameservern prüfen.
Die netcup-REST-API ist vom Server aus nicht erreichbar	curl bricht mit einem Zertifikatsfehler ab (Zertifikat für www.netcup.eu). Im Test kamen Anfragen von einer IP-Adresse aus dem netcup-Netz so an, auch über ein VPN mit netcup-Adresse, und das betrifft auch lego mit netcupv1. Von einem Anschluss außerhalb ging es. Den Eintrag sonst im CCP anlegen.
mail for … loops back to myself	Sie haben vom Mailserver an sich selbst gesendet. Postfix erkennt das vor dem Verbindungsaufbau. Für den Test eine fremde Domain mit DANE nutzen oder posttls-finger.

Häufige Fragen

Wie lange dauert es, bis DNSSEC bei netcup aktiv ist?

Das CCP nennt bis zu 48 Stunden. Im Test mit einer Domain im CloudDNS war der DS-Eintrag nach rund 6 Minuten bei der DENIC. Prüfen Sie es mit dig, statt pauschal zu warten.

Kann ich DNSSEC per netcup-API einschalten?

In der OpenAPI-Beschreibung der netcup-REST-API (Stand 2026.0921) gibt es dafür keinen Endpunkt. TLSA- und DS-Einträge kennt die API als Record-Typen, das Einschalten selbst geht über das CCP.

Muss ich für DANE den Resolver des ganzen Servers umstellen?

Für den Versand braucht Postfix einen prüfenden Resolver in seiner Chroot-Kopie. Damit das dauerhaft so bleibt, muss /etc/resolv.conf ebenfalls darauf zeigen, denn Postfix kopiert sie bei jedem Start. Für die reine Prüfung mit posttls-finger reicht der Mount-Namensraum aus dem Abschnitt oben.

Reicht DANE ohne MTA-STS?

Beide Verfahren schützen den Weg zwischen Mailservern auf unterschiedliche Weise: DANE über DNSSEC, MTA-STS über HTTPS. Beide lassen sich kombinieren, dann prüfen auch Absender ohne DANE-Unterstützung. Diese Anleitung behandelt nur DANE.

Fazit

Bei netcup ist DANE inzwischen schnell eingerichtet: DNSSEC per Klick, ein TLSA-Eintrag im CloudDNS oder per API, drei Zeilen in der Postfix-Konfiguration. Die eigentliche Falle liegt beim Resolver. Ohne prüfenden Resolver in der Chroot-Kopie von Postfix blieb die Mail im Test in der Warteschlange. Behalten Sie außerdem den Schlüssel bei der Zertifikatserneuerung im Blick, sonst passt der TLSA-Eintrag nach der nächsten Erneuerung nicht mehr.

Weiterführende Anleitungen und Quellen

• DNSSEC bei netcup aktivieren: Domain im CCP absichern und prüfen
• Reverse-DNS (rDNS/PTR) für IPv4 und IPv6 im netcup SCP setzen
• Teil 11: netcup-DNS-Zone sichern und zurückspielen mit DNSControl
• Teil 15: Wildcard-Zertifikat mit Traefik und Caddy über die netcup-DNS-API
• Mailversand vom netcup-Server mit msmtp über Port 587
• netcup: DNSSEC im CloudDNS
• Postfix: TLS_README, Abschnitt DANE
• Postfix: posttls-finger
• RFC 7672: SMTP Security via Opportunistic DANE TLS