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

Du hast DANE/TLSA nach Best Practices auf deinem 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 dir 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 du DANE noch nicht eingerichtet hast, beginne 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üfe, ob der DS-Record bei deinem Registrar mit deinem DNSKEY übereinstimmt. Wenn du Bind9 verwendest, prüfe die Ablaufdaten der Schlüssel mit dnssec-settime und konfiguriere 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: Generiere den neuen Hash mit unserem DANE TLSA Generator und aktualisiere den DNS
• Dauerhafte Lösung: Verwende SPKI-Selector (1) mit --reuse-key in Certbot, oder wechsle zu DANE-TA (2) mit dem CA-Zertifikat von Let's Encrypt. 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 du den Eintrag erstellt hast. 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öffentliche den TLSA auf _25._tcp.mail.captaindns.com (oder dem Hostnamen, den dein MX-Eintrag zurückgibt). Wenn deine 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üfe 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: Stelle sicher, dass alle deine NS-Server denselben TLSA-Wert zurückgeben. Wenn du den TLSA gerade aktualisiert hast, warte das Ablaufen der vorherigen TTL ab, bevor du den alten Eintrag löschst. Bei Zertifikatsrotationen veröffentliche 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: Aktiviere 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: Richte 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: Plane 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: Nutze die obige 5-Schritte-Methodik oder unseren DANE TLSA Checker, um das Problem zu identifizieren
2. Einordnen: Ordne den Fehler einer der 5 Kategorien zu (DNSSEC, Hash, DNS-Name, STARTTLS, Propagation)
3. Beheben: Wende die entsprechende Lösung mit den bereitgestellten Befehlen an
4. Verifizieren: Teste die Korrektur mit dig +dnssec und openssl s_client, bevor du das Problem als gelöst betrachtest
5. Vorbeugen: Richte 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