DANE/TLSA-Fehlerbehebung: häufige Fehler diagnostizieren und beheben

Sie haben DANE/TLSA nach Best Practices auf Ihrem E-Mail-Server eingerichtet, alles funktionierte, und dann werden eines Tages E-Mails von bestimmten Empfängern abgelehnt. Die Fehlermeldung erwähnt "failed DANE validation" oder "TLSA record not found", aber die Logs verraten Ihnen nicht genau, was sich geändert hat.

Dieses Szenario kennt jeder DANE-Administrator. Die Schwierigkeit liegt nicht in der Komplexität des Protokolls, sondern in der Anzahl der beteiligten Komponenten: DNSSEC, TLS-Zertifikat, TLSA-Eintrag, MTA-Konfiguration. Ein einziges schwaches Glied reicht aus, um die gesamte Kette zu unterbrechen.

Dieser Leitfaden behandelt die 5 häufigsten DANE/TLSA-Fehler mit jeweils dem Symptom, den Diagnosebefehlen und der Korrektur. Er richtet sich an Systemadministratoren und DevOps, die bereits eine DANE-Konfiguration betreiben. Falls Sie DANE noch nicht eingerichtet haben, beginnen Sie mit dem ersten Artikel dieser Serie (siehe "Verwandte Leitfäden" am Ende der Seite).

Die 5 häufigsten DANE-Fehler

DANE-Probleme lassen sich in 5 Kategorien einteilen. Jeder Abschnitt beschreibt das beobachtbare Symptom, den Diagnosebefehl und die Korrektur.

Fehler 1: DNSSEC nicht signiert oder Signatur abgelaufen

Symptom: Sendende Server melden "DANE required but not available" oder "no DNSSEC" in TLS-RPT-Berichten. E-Mails werden im opportunistischen Modus (ohne DANE-Prüfung) zugestellt oder abgelehnt.

Diagnose:

# AD-Flag (Authenticated Data) prüfen
dig +dnssec MX captaindns.com | grep flags
# Erwartetes Ergebnis: flags: qr rd ra ad

# Gültigkeit der RRSIG-Signaturen prüfen
dig +dnssec SOA captaindns.com | grep RRSIG
# Das Ablaufdatum steht im RRSIG-Feld

Häufige Ursachen:

• Der Registrar hat DNSSEC nach einem Domain-Transfer deaktiviert
• Die DNSSEC-Schlüssel (KSK/ZSK) sind ohne automatische Rotation abgelaufen
• Der DS-Record beim Registrar stimmt nicht mehr mit dem aktiven DNSKEY überein

Korrektur: Prüfen Sie, ob der DS-Record bei Ihrem Registrar mit Ihrem DNSKEY übereinstimmt. Wenn Sie Bind9 verwenden, prüfen Sie die Ablaufdaten der Schlüssel mit dnssec-settime und konfigurieren Sie die automatische Rotation.

Fehler 2: TLSA-Hash veraltet nach Zertifikatserneuerung

Symptom: "TLSA validation failed" oder "certificate mismatch" in den Logs. Dieser Fehler tritt typischerweise 60 bis 90 Tage nach der Ersteinrichtung auf, bei der ersten Let's-Encrypt-Erneuerung.

Diagnose:

# Hash des aktiven Zertifikats (Selector 0: Full cert)
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -outform DER \
  | openssl dgst -sha256

# Im DNS veröffentlichter Hash
dig TLSA _25._tcp.mail.captaindns.com +short
# Die 64 Hex-Zeichen vergleichen

Häufige Ursachen:

• Der Certbot-Renewal-Hook aktualisiert den TLSA nicht
• Der Selector ist Full (0) statt SPKI (1): bei jeder Erneuerung ändert sich der Hash
• Der Usage ist DANE-EE (3) ohne --reuse-key in Certbot

Korrektur:

• Schnelle Lösung: Generieren Sie den neuen Hash mit unserem DANE TLSA Generator und aktualisieren Sie den DNS
• Dauerhafte Lösung: Verwenden Sie SPKI-Selector (1) mit --reuse-key in Certbot, das ist die Standardwahl. Wenn Sie DANE-TA (2) vorziehen, pinnen Sie das Let's-Encrypt-Intermediate, das Ihr Server tatsächlich sendet (R10 oder R11), und nicht die Wurzel ISRG Root X1: RFC 7671 Abschnitt 5.2.2 verlangt, dass das gepinnte Zertifikat in der präsentierten TLS-Kette enthalten ist. Siehe unser Postfix/Bind/Let's-Encrypt-Tutorial (Artikel 2 dieser Serie) für die Konfiguration des automatischen Renewal-Hooks

Fehler 3: TLSA unter falschem DNS-Namen veröffentlicht

Symptom: "no TLSA records found", obwohl Sie den Eintrag erstellt haben. Das ist der häufigste Fehler bei DANE-Einsteigern.

Diagnose:

# MX-Hostnamen ermitteln
dig MX captaindns.com +short
# Ergebnis: 10 mail.captaindns.com.

# TLSA am richtigen Ort prüfen (MX-Hostname)
dig TLSA _25._tcp.mail.captaindns.com +short

# Typischer Fehler: TLSA auf der Domain statt auf dem MX veröffentlicht
dig TLSA _25._tcp.captaindns.com +short
# Dieser TLSA wird von sendenden Servern IGNORIERT

Ursache: Verwechslung zwischen der Domain (captaindns.com) und dem MX-Hostnamen (mail.captaindns.com). Der TLSA muss auf _25._tcp.<MX-Hostname> veröffentlicht werden, gemäß RFC 7672 Abschnitt 2.1.1.

Korrektur: Veröffentlichen Sie den TLSA auf _25._tcp.mail.captaindns.com (oder dem Hostnamen, den Ihr MX-Eintrag zurückgibt). Wenn Ihre Domain mehrere MX-Einträge hat, benötigt jeder Hostname seinen eigenen TLSA.

Fehler 4: STARTTLS nicht verfügbar oder falsch konfiguriert

Symptom: DANE ist DNS-seitig konfiguriert, aber der Server bietet kein STARTTLS an, oder das präsentierte Zertifikat stimmt nicht mit dem Hostnamen überein. Die Logs zeigen "TLS handshake failed" oder "certificate hostname mismatch".

Diagnose:

# Testen, ob STARTTLS angeboten wird
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp -verify 5

# Common Name und SAN des Zertifikats prüfen
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Häufige Ursachen:

• smtpd_tls_cert_file zeigt in Postfix auf die falsche Datei
• Das Zertifikat enthält den MX-Hostnamen nicht in seinen Subject Alternative Names
• Die Firewall blockiert STARTTLS oder Port 25 ist nicht per TLS erreichbar

Korrektur: Prüfen Sie in Postfix, dass smtpd_tls_security_level mindestens auf may steht und die Zertifikatspfade korrekt sind:

# /etc/postfix/main.cf
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

Fehler 5: unvollständige DNS-Propagation

Symptom: DANE funktioniert sporadisch. Einige sendende Server validieren den TLSA, andere melden einen Fehler. Das Problem tritt häufig nach einer kürzlich vorgenommenen DNS-Aktualisierung auf.

Diagnose:

# Antworten zwischen NS-Servern vergleichen
dig TLSA _25._tcp.mail.captaindns.com @ns1.captaindns.com +short
dig TLSA _25._tcp.mail.captaindns.com @ns2.captaindns.com +short

# Verbleibende TTL prüfen
dig TLSA _25._tcp.mail.captaindns.com +noall +answer

Häufige Ursachen:

• Unvollständiger Zonentransfer zwischen primärem und sekundärem DNS-Server
• Hohe TTL auf dem alten Eintrag (DNS-Caches behalten den alten Wert)
• Ein NS-Server antwortet nicht oder liefert eine veraltete Version der Zone

Korrektur: Stellen Sie sicher, dass alle Ihre NS-Server denselben TLSA-Wert zurückgeben. Wenn Sie den TLSA gerade aktualisiert haben, warten Sie das Ablaufen der vorherigen TTL ab, bevor Sie den alten Eintrag löschen. Bei Zertifikatsrotationen veröffentlichen Sie den neuen TLSA 2x TTL vor der tatsächlichen Rotation.

DANE in der Produktion überwachen

Einen einzelnen Fehler zu beheben reicht nicht aus. Die folgenden 3 Überwachungsmechanismen verhindern wiederkehrende Vorfälle.

TLS-RPT: Aktivieren Sie TLS-RPT-Berichte (RFC 8460), um Fehlermeldungen über DANE-Fehler von sendenden Servern zu erhalten. Das Feld failure-type im JSON-Bericht gibt den Fehlertyp genau an:

Zertifikats-Monitoring: Richten Sie einen Alarm 14 Tage vor Ablauf des TLS-Zertifikats ein. Die Let's-Encrypt-Erneuerung erfolgt automatisch, aber der TLSA-Hook kann stillschweigend fehlschlagen.

Automatische Prüfung: Planen Sie eine tägliche Prüfung mit unserem DANE TLSA Syntax Checker oder einem Cron-Skript, das den veröffentlichten Hash mit dem aktiven Zertifikat vergleicht:

#!/bin/bash
# Tägliche DANE-Prüfung
TLSA_HASH=$(dig TLSA _25._tcp.mail.captaindns.com +short | awk '{print $4}')
CERT_HASH=$(openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 | awk '{print $2}')

if [ "$TLSA_HASH" != "$CERT_HASH" ]; then
  echo "WARNUNG: TLSA-Hash weicht vom aktiven Zertifikat ab" | \
    mail -s "DANE TLSA mismatch" admin@captaindns.com
fi

Empfohlener Aktionsplan

1. Diagnostizieren: Nutzen Sie die obige 5-Schritte-Methodik oder unseren DANE TLSA Checker, um das Problem zu identifizieren
2. Einordnen: Ordnen Sie den Fehler einer der 5 Kategorien zu (DNSSEC, Hash, DNS-Name, STARTTLS, Propagation)
3. Beheben: Wenden Sie die entsprechende Lösung mit den bereitgestellten Befehlen an
4. Verifizieren: Testen Sie die Korrektur mit dig +dnssec und openssl s_client, bevor Sie das Problem als gelöst betrachten
5. Vorbeugen: Richten Sie TLS-RPT, Zertifikats-Monitoring und die automatische Prüfung ein

📚 Verwandte DANE/TLSA-Leitfäden

• DANE/TLSA: die Komplettanleitung zur DNS-basierten Zertifikatauthentifizierung für E-Mail: Funktionsweise, TLSA-Anatomie, empfohlene Verwendungen und Vergleich mit MTA-STS
• DANE/TLSA mit Postfix, Bind und Let's Encrypt konfigurieren: Schritt-für-Schritt-Tutorial mit kopierbaren Befehlen, automatischer Erneuerung und Überprüfung
• DANE für Exchange Online und Microsoft 365 bereitstellen

Quellen

• RFC 7672 - SMTP Security via Opportunistic DANE TLS
• RFC 7671 - The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• Postfix TLS README - DANE
• ISC BIND 9 DNSSEC Guide