DANE/TLSA mit Postfix, Bind und Let's Encrypt konfigurieren

Q: Wie generiere ich einen TLSA-Eintrag für Let's Encrypt?

Verwenden Sie den Befehl openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | xxd -p -c 64 , um den SPKI-SHA-256-Hash zu extrahieren. Das 64 Zeichen lange Hexadezimal-Ergebnis bildet die Daten des TLSA mit den Parametern 3 1 1 .

Q: Muss ich den TLSA bei jeder Let's Encrypt-Erneuerung aktualisieren?

Nein, wenn Sie --reuse-key mit Certbot und die Kombination DANE-EE/SPKI ( 3 1 1 ) verwenden. Der SPKI-Hash hängt vom öffentlichen Schlüssel ab, nicht vom Zertifikat. Solange der private Schlüssel gleich bleibt, ändert sich der Hash nicht. Richten Sie sicherheitshalber einen Verifizierungs-Deploy-Hook ein.

Q: Wie aktiviere ich die DANE-Verifizierung in Postfix?

Fügen Sie smtp_dns_support_level = dnssec und smtp_tls_security_level = dane in /etc/postfix/main.cf hinzu. Postfix verifiziert dann automatisch die TLSA-Einträge der Empfänger-Domains über DNSSEC. Wenn der TLSA fehlt oder ungültig ist, fällt Postfix auf opportunistisches TLS zurück.

Q: Wie teste ich, ob DANE korrekt konfiguriert ist?

Drei Verifizierungsebenen: 1) dig +dnssec _25._tcp.mail.captaindns.com TLSA für das DNS, 2) openssl s_client -connect mail.captaindns.com:25 -starttls smtp -dane_tlsa_domain für die Übereinstimmung Zertifikat/TLSA, 3) der DANE/TLSA-Inspektor von CaptainDNS für einen vollständigen Bericht inklusive DNSSEC-Kette.

Q: Was passiert, wenn der TLSA nicht mehr zum Zertifikat passt?

Server, die DANE verifizieren (wie Postfix mit dane oder Gmail), werden die TLS-Verbindung ablehnen und je nach Richtlinie auf unverschlüsselt zurückfallen oder die Nachricht ablehnen. Deshalb ist die doppelte TLSA-Veröffentlichung bei Schlüsselrotationen essenziell. Wenn Ihr TLSA desynchronisiert ist, entfernen Sie ihn vorübergehend, um auf opportunistisches TLS zurückzufallen, bis das Problem behoben ist.

Von CaptainDNS
Veröffentlicht am 22. Februar 2026

Architekturschema mit Postfix, Bind9 und Let's Encrypt, verbunden durch DANE/TLSA

TL;DR

DANE/TLSA verknüpft das TLS-Zertifikat Ihres Mailservers mit einem DNSSEC-signierten DNS-Eintrag und eliminiert die Abhängigkeit von Zertifizierungsstellen
Die empfohlene Kombination ist 3 1 1 (DANE-EE, SPKI, SHA-256): der TLSA-Hash überlebt Let's Encrypt-Erneuerungen, solange der private Schlüssel unverändert bleibt
Postfix unterstützt die ausgehende DANE-Verifizierung nativ mit smtp_dns_support_level = dnssec und smtp_tls_security_level = dane
Die Automatisierung erfolgt über einen Certbot-Deploy-Hook, der den TLSA-Hash neu generiert und die Bind9-Zone bei jeder Erneuerung neu lädt
Überprüfen Sie Ihr Deployment mit dig TLSA, openssl s_client und dem DANE/TLSA-Inspektor von CaptainDNS

Sie betreiben einen Postfix-Mailserver und möchten Ihre SMTP-Verbindungen gegen Downgrade- und Man-in-the-Middle-Angriffe absichern? DANE (DNS-based Authentication of Named Entities) ist die Antwort. Indem Sie einen TLSA-Eintrag in Ihrer DNSSEC-signierten DNS-Zone veröffentlichen, teilen Sie entfernten Servern mit, welches TLS-Zertifikat Ihr Server vorlegen muss. Kein Mittelsmann, keine Zertifizierungsstelle, der Sie vertrauen müssen.

Die Herausforderung bei Let's Encrypt ist die automatische Erneuerung alle 90 Tage. Wenn der TLSA-Hash nicht mehr zum Zertifikat passt, werden Server, die DANE verifizieren, die Verbindung ablehnen. Dieses Tutorial deckt die vollständige Konfiguration des Stacks Postfix + Bind9 + Let's Encrypt + DANE ab, einschließlich der Automatisierung der Erneuerung, um jede Unterbrechung zu vermeiden.

Dieser Leitfaden richtet sich an Linux-Systemadministratoren, die einen selbst gehosteten Mailserver betreiben. Er setzt Grundkenntnisse in Postfix, DNS und der Kommandozeile voraus. Für die Grundlagen von DANE und TLSA lesen Sie unsere Komplettanleitung zu DANE/TLSA (erster Artikel dieser Serie).

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:

Komponente	Mindestversion	Überprüfung
Debian/Ubuntu	12+ / 22.04+	`cat /etc/os-release`
Postfix	3.4+ (native DANE-Unterstützung)	`postconf mail_version`
Bind9	9.18+ (DNSSEC inline-signing)	`named -v`
Certbot	2.0+	`certbot --version`
DNSSEC aktiv	Zone signiert + DS beim Registrar	`dig +dnssec captaindns.com SOA`

Wenn DNSSEC auf Ihrer Zone noch nicht aktiv ist, ist das die Voraussetzung. Bind9 9.18+ unterstützt inline-signing, was die Verwaltung vereinfacht. Aktivieren Sie es, bevor Sie fortfahren.

Ports und Netzwerkzugang

Postfix verwendet Port 25 (SMTP) und optional 587 (Submission). Let's Encrypt benötigt Port 80 oder 443 für die HTTP-01-Challenge (oder eine DNS-01-Challenge, wenn Port 80 auf dem Mailserver nicht verfügbar ist). Stellen Sie sicher, dass diese Ports in Ihrer Firewall geöffnet sind.

Architektur des Stacks Postfix, Bind9 und Let's Encrypt mit DANE/TLSA

DNSSEC mit Bind9 konfigurieren

Wenn Ihre Zone bereits per DNSSEC signiert ist, springe zum nächsten Abschnitt. Andernfalls finden Sie hier die minimale Konfiguration mit Bind9 und inline-signing.

Inline-signing aktivieren

In Ihrer Zonenkonfigurationsdatei (/etc/bind/named.conf.local oder Äquivalent):

zone "captaindns.com" {
    type primary;
    file "/var/lib/bind/captaindns.com.zone";
    dnssec-policy default;
    inline-signing yes;
    key-directory "/var/lib/bind/keys";
};

Die Direktive dnssec-policy default generiert und verwaltet automatisch die ZSK- und KSK-Schlüssel. inline-signing signiert die Zone im laufenden Betrieb, ohne die Quelldatei zu verändern.

DS beim Registrar veröffentlichen

Nach dem ersten Laden der Zone generiert Bind9 die Schlüssel. Extrahieren Sie den DS-Record:

# Generierte Schlüssel auflisten
ls /var/lib/bind/keys/

# DS-Record extrahieren (Dateinamen des KSK anpassen)
dnssec-dsfromkey /var/lib/bind/keys/Kcaptaindns.com.+013+xxxxx.key

Übermittle den DS-Record an Ihren Registrar (Weboberfläche oder API). Die Propagation dauert je nach Registrar wenige Minuten bis 48 Stunden.

DNSSEC-Kette überprüfen

dig +dnssec +short captaindns.com SOA
# Muss den SOA mit dem Flag "ad" (Authenticated Data) zurückgeben

dig +dnssec captaindns.com DNSKEY
# Muss die DNSKEY mit den RRSIG-Signaturen zurückgeben

Let's Encrypt-Zertifikat generieren

Zertifikat anfordern

# Certbot installieren (falls noch nicht installiert)
apt install certbot

# Zertifikat für den Hostnamen des Mailservers anfordern
certbot certonly --standalone -d mail.captaindns.com

Wenn Port 80 bereits von einem anderen Dienst belegt ist, verwenden Sie das Webroot-Plugin oder die DNS-01-Challenge:

# Alternative mit Webroot (wenn Apache/Nginx auf dem Server läuft)
certbot certonly --webroot -w /var/www/html -d mail.captaindns.com

# Alternative mit DNS-Challenge (wenn Port 80 nicht verfügbar)
certbot certonly --manual --preferred-challenges dns -d mail.captaindns.com

Postfix für die Verwendung des Zertifikats konfigurieren

Bearbeiten Sie /etc/postfix/main.cf:

# TLS-Zertifikat (Empfang - smtpd)
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Ausgehende DANE-Verifizierung (smtp)
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_loglevel = 1

Die beiden Blöcke dienen unterschiedlichen Zwecken: smtpd_tls_* konfiguriert TLS für eingehende Verbindungen (Ihr Server präsentiert sein Zertifikat), während smtp_tls_* TLS für ausgehende Verbindungen konfiguriert (Postfix verifiziert den TLSA des Empfängers).

Postfix neu laden:

postfix reload

TLSA-Eintrag erstellen

TLSA-Parameter wählen

Die von RFC 7672 für SMTP empfohlene Kombination ist 3 1 1:

Feld	Wert	Bedeutung
Usage	3 (DANE-EE)	Direkte Verifizierung des Serverzertifikats
Selector	1 (SPKI)	Hash des öffentlichen Schlüssels (nicht des gesamten Zertifikats)
Matching type	1 (SHA-256)	SHA-256-Hash

Der Vorteil des SPKI-Selectors (1): Der Hash ändert sich nicht, wenn Sie das Let's Encrypt-Zertifikat erneuern, solange der private Schlüssel gleich bleibt. Das ist entscheidend, um den TLSA nicht bei jeder Erneuerung aktualisieren zu müssen.

TLSA-Hash generieren

# SPKI-SHA-256-Hash aus dem Zertifikat extrahieren
openssl x509 -in /etc/letsencrypt/live/mail.captaindns.com/cert.pem \
  -pubkey -noout | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 64

Das Ergebnis ist ein 64 Zeichen langer Hexadezimal-String, zum Beispiel:

a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890

Sie können auch den DANE/TLSA-Generator von CaptainDNS verwenden, um den Eintrag ohne Befehlszeile zu generieren.

TLSA in die Bind9-Zone eintragen

Der Name des TLSA-Eintrags folgt dem Format _port._protocol.hostname. Für Port 25 (SMTP):

_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890

Fügen Sie diese Zeile in Ihre Zonendatei ein, erhöhen Sie die SOA-Seriennummer und laden Sie neu:

# Zone neu laden (Bind9 signiert automatisch mit inline-signing)
rndc reload captaindns.com

Veröffentlichung überprüfen

# Überprüfen, dass der TLSA veröffentlicht und signiert ist
dig +dnssec _25._tcp.mail.captaindns.com TLSA

# Erwartetes Ergebnis: der TLSA mit den RRSIG

Erneuerung automatisieren

Das ist der kritische Teil. Let's Encrypt erneuert das Zertifikat alle 90 Tage. Wenn Sie DANE-EE mit SPKI (3 1 1) verwenden, ändert sich der Hash nicht, solange Certbot denselben privaten Schlüssel wiederverwendet. Aber Sie müssen das sicherstellen und den Fall vorsehen, dass der Schlüssel sich ändert.

Strategie zur Schlüsselbeibehaltung

Standardmäßig generiert Certbot bei jeder Erneuerung einen neuen Schlüssel. Um denselben Schlüssel beizubehalten (und damit denselben TLSA-Hash), fügen Sie die Option --reuse-key hinzu:

# Wiederverwendung des privaten Schlüssels erzwingen
certbot certonly --standalone -d mail.captaindns.com --reuse-key

Oder fügen Sie in /etc/letsencrypt/renewal/mail.captaindns.com.conf hinzu:

[renewalparams]
reuse_key = True

Deploy-Hook für automatische Aktualisierung

Auch mit --reuse-key ist es ratsam, einen Deploy-Hook einzurichten, der den Hash überprüft und den TLSA bei Bedarf aktualisiert. Erstellen Sie das Skript /etc/letsencrypt/renewal-hooks/deploy/update-tlsa.sh:

#!/bin/bash
# Certbot-Deploy-Hook: TLSA aktualisieren, wenn sich der SPKI-Hash ändert

DOMAIN="mail.captaindns.com"
ZONE="captaindns.com"
ZONE_FILE="/var/lib/bind/captaindns.com.zone"
CERT="/etc/letsencrypt/live/$DOMAIN/cert.pem"

# Neuen SPKI-SHA-256-Hash berechnen
NEW_HASH=$(openssl x509 -in "$CERT" -pubkey -noout | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 64)

# Aktuellen Hash aus dem DNS abrufen
CURRENT_HASH=$(dig +short _25._tcp.$DOMAIN TLSA | awk '{print $4}')

if [ "$NEW_HASH" != "$CURRENT_HASH" ]; then
  echo "TLSA hash changed, updating zone..."

  # Hash in der Zonendatei ersetzen
  sed -i "s/\(IN TLSA 3 1 1 \)[a-f0-9]\{64\}/\1$NEW_HASH/" "$ZONE_FILE"

  # Seriennummer erhöhen (Format YYYYMMDDNN)
  CURRENT_SERIAL=$(grep -oP '\d{10}' "$ZONE_FILE" | head -1)
  NEW_SERIAL=$((CURRENT_SERIAL + 1))
  sed -i "s/$CURRENT_SERIAL/$NEW_SERIAL/" "$ZONE_FILE"

  # Zone neu laden
  rndc reload "$ZONE"

  echo "TLSA updated: $NEW_HASH"
else
  echo "TLSA hash unchanged, no update needed."
fi

# Postfix neu laden, um das neue Zertifikat zu übernehmen
postfix reload

Das Skript ausführbar machen:

chmod +x /etc/letsencrypt/renewal-hooks/deploy/update-tlsa.sh

Erneuerung testen

# Erneuerung simulieren (Dry-Run)
certbot renew --dry-run

# Erneuerung erzwingen (um den Hook zu testen)
certbot renew --force-renewal

Ablauf der automatischen Erneuerung: Certbot erneuert das Zertifikat, der Deploy-Hook überprüft den SPKI-Hash und aktualisiert den TLSA in Bind9 bei Bedarf

SPKI-Rollover-Strategie (Schlüsselwechsel)

Wenn Sie den privaten Schlüssel neu generieren müssen (Kompromittierung, Migration), veröffentlichen Sie den neuen TLSA vor dem Deployment des neuen Zertifikats. RFC 7671 empfiehlt eine Phase der doppelten Veröffentlichung:

Neuen Schlüssel generieren und seinen SPKI-Hash berechnen
Beide TLSA in der Zone veröffentlichen (alter + neuer)
DNS-Propagation abwarten (mindestens 2x TTL)
Neues Zertifikat deployen
Alten TLSA nach der Propagation entfernen

; Doppelter TLSA während der Übergangsphase
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <alter-hash>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <neuer-hash>

Konfiguration überprüfen

DNS-Verifizierung

# TLSA überprüfen
dig +short _25._tcp.mail.captaindns.com TLSA
# Erwartet: 3 1 1 <hash-64-zeichen>

# DNSSEC überprüfen
dig +dnssec _25._tcp.mail.captaindns.com TLSA | grep -c "RRSIG"
# Erwartet: >= 1

TLS-Verifizierung

# TLS-Verbindung mit TLSA-Verifizierung testen
openssl s_client -connect mail.captaindns.com:25 -starttls smtp \
  -dane_tlsa_domain mail.captaindns.com \
  -dane_tlsa_rrdata "3 1 1 $(dig +short _25._tcp.mail.captaindns.com TLSA | awk '{print $4}')"

Das Ergebnis muss Verification: OK und DANE TLSA 3 1 1 matched EE certificate anzeigen.

Ausgehende Postfix-Verifizierung

Überprüfen Sie, dass Postfix DANE für ausgehende E-Mails korrekt verifiziert:

# Test-E-Mail senden und Logs überprüfen
echo "Test DANE" | mail -s "DANE test" test@gmail.com
grep "Verified TLS connection" /var/log/mail.log | tail -5

Die Logs müssen dane im Sicherheitslevel erwähnen.

Online-Verifizierung

Nutzen Sie den DANE/TLSA-Syntaxprüfer von CaptainDNS, um die Syntax Ihres Eintrags zu validieren, und dann den DANE/TLSA-Inspektor für eine vollständige Überprüfung inklusive der DNSSEC-Kette.

Empfohlener Aktionsplan

DANE/TLSA mit Postfix, Bind und Let's Encrypt konfigurieren

Vollständiges DANE-Deployment auf einem selbst gehosteten Mailserver in 6 Schritten

DNSSEC auf der Bind9-Zone aktivieren
dnssec-policy default und inline-signing yes in der Bind9-Zone konfigurieren. Den DS-Record beim Registrar veröffentlichen. Die Vertrauenskette mit dig +dnssec überprüfen.
Let's Encrypt-Zertifikat anfordern
certbot certonly --standalone -d mail.captaindns.com --reuse-key ausführen, um das Zertifikat mit Schlüsselbeibehaltung zu erhalten.
Postfix für TLS und DANE konfigurieren
main.cf mit den Zertifikatspfaden bearbeiten (smtpd_tls_*), die ausgehende DANE-Verifizierung aktivieren (smtp_dns_support_level = dnssec, smtp_tls_security_level = dane).
TLSA in der DNS-Zone veröffentlichen
Den SPKI-SHA-256-Hash mit openssl generieren, den Eintrag _25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash> in die Zone eintragen, mit rndc reload neu laden.
Erneuerung automatisieren
Den Deploy-Hook /etc/letsencrypt/renewal-hooks/deploy/update-tlsa.sh erstellen, der die SPKI-Hashes vergleicht und den TLSA bei Bedarf aktualisiert. Mit certbot renew --force-renewal testen.
Deployment überprüfen
Mit dig TLSA, openssl s_client -dane_tlsa_domain, den Postfix-Logs und dem DANE/TLSA-Inspektor von CaptainDNS validieren.

FAQ

Wie generiere ich einen TLSA-Eintrag für Let's Encrypt?

Verwenden Sie den Befehl openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | xxd -p -c 64, um den SPKI-SHA-256-Hash zu extrahieren. Das 64 Zeichen lange Hexadezimal-Ergebnis bildet die Daten des TLSA mit den Parametern 3 1 1.

Muss ich den TLSA bei jeder Let's Encrypt-Erneuerung aktualisieren?

Nein, wenn Sie --reuse-key mit Certbot und die Kombination DANE-EE/SPKI (3 1 1) verwenden. Der SPKI-Hash hängt vom öffentlichen Schlüssel ab, nicht vom Zertifikat. Solange der private Schlüssel gleich bleibt, ändert sich der Hash nicht. Richten Sie sicherheitshalber einen Verifizierungs-Deploy-Hook ein.

Wie aktiviere ich die DANE-Verifizierung in Postfix?

Fügen Sie smtp_dns_support_level = dnssec und smtp_tls_security_level = dane in /etc/postfix/main.cf hinzu. Postfix verifiziert dann automatisch die TLSA-Einträge der Empfänger-Domains über DNSSEC. Wenn der TLSA fehlt oder ungültig ist, fällt Postfix auf opportunistisches TLS zurück.

Funktioniert DANE mit selbstsignierten Zertifikaten?

Ja. Bei DANE-EE (Usage 3) wird das Zertifikat durch den TLSA im DNS validiert, nicht durch eine Zertifizierungsstelle. Ein selbstsigniertes Zertifikat mit einem korrekten TLSA und einer gültigen DNSSEC-Zone wird von Servern akzeptiert, die DANE verifizieren.

Wie teste ich, ob DANE korrekt konfiguriert ist?

Drei Verifizierungsebenen: 1) dig +dnssec _25._tcp.mail.captaindns.com TLSA für das DNS, 2) openssl s_client -connect mail.captaindns.com:25 -starttls smtp -dane_tlsa_domain für die Übereinstimmung Zertifikat/TLSA, 3) der DANE/TLSA-Inspektor von CaptainDNS für einen vollständigen Bericht inklusive DNSSEC-Kette.

Ist Bind zwingend erforderlich oder kann man einen anderen DNS-Server verwenden?

Bind9 ist nicht zwingend. Jeder DNS-Server mit DNSSEC-Unterstützung funktioniert: NSD, Knot DNS, PowerDNS. Die Prinzipien sind identisch, nur die Konfigurationssyntax unterscheidet sich. Bind9 wird in diesem Tutorial verwendet, weil es auf Linux-Servern am weitesten verbreitet ist und sein inline-signing die DNSSEC-Verwaltung vereinfacht.

Was passiert, wenn der TLSA nicht mehr zum Zertifikat passt?

Server, die DANE verifizieren (wie Postfix mit dane oder Gmail), werden die TLS-Verbindung ablehnen und je nach Richtlinie auf unverschlüsselt zurückfallen oder die Nachricht ablehnen. Deshalb ist die doppelte TLSA-Veröffentlichung bei Schlüsselrotationen essenziell. Wenn Ihr TLSA desynchronisiert ist, entfernen Sie ihn vorübergehend, um auf opportunistisches TLS zurückzufallen, bis das Problem behoben ist.