DANE TLSA Checker

Warum DANE TLSA prüfen

SMTP-Transport mit opportunistischem TLS lässt zwei stille Angriffsszenarien offen: einen Angreifer in Mittelposition, der STARTTLS entfernt, um Klartext zu erzwingen, oder ein gefälschtes Zertifikat, das von einem sendenden MTA akzeptiert wird, der das Original nicht von der Fälschung unterscheiden kann. DANE schließt diese Lücke, indem es einen Hash des erwarteten Zertifikats DNSSEC-signiert im DNS veröffentlicht.

DANE ist jedoch streng: Ein falsch platzierter TLSA Record, eine nicht DNSSEC-signierte Zone oder ein Hash, der nach einer Zertifikatserneuerung abweicht, reichen aus, um deine Bereitstellung still und leise ungültig zu machen. Beim sendenden MTA kommt keine Fehlermeldung an: Die Verbindung fällt geräuschlos auf opportunistisches TLS zurück, und dein SMTP-Fluss verliert den Schutz, den du zu haben glaubtest.

Eine Live-Prüfung deines DANE TLSA wird unverzichtbar:

• Nach der Erstveröffentlichung: bestätigen, dass der Record aufgelöst wird, DNSSEC-signiert ist und der Hash mit dem ausgelieferten Zertifikat übereinstimmt
• Nach jeder Zertifikatserneuerung: Die Ursache Nummer 1 von DANE-Ausfällen ist eine Hash-/Zertifikatsabweichung
• Mail-Sicherheits-Audit: prüfen, dass DANE alle MX-Hosts abdeckt und kein Pfad auf opportunistischem TLS verbleibt
• Vor Migration des Mail-Providers: Microsoft 365, Google Workspace und traditionelle Anbieter bieten unterschiedliche DANE-Unterstützung

So nutzt du diesen Checker in 3 Schritten

Schritt 1: zu prüfende Domain eingeben

Gib die Mail-Domain genau so ein, wie sie in deinen E-Mail-Adressen erscheint:

• captaindns.com (Hauptdomain)
• marketing.captaindns.com (Subdomain, falls du mehrere Zonen verwaltest)

Das Tool listet automatisch die MX-Hosts auf und fragt für jeden _25._tcp.<mx-host> ab. Die DNSSEC-Validierung läuft die vollständige Kette bis zur Root.

Schritt 2: Ergebnisse je MX lesen

Der Checker zeigt für jeden MX:

Schritt 3: Korrekturen anwenden

Die Diagnosen werden nach Schweregrad sortiert:

• Blockierend: DNSSEC fehlt, TLSA nicht gefunden, Hash abweichend. Die DANE-Bereitstellung schützt im aktuellen Zustand niemanden.
• Warnung: nicht empfohlene Kombination (Usage 0 oder 1 ohne kontrollierte CA), Matching Type 0 mit dem Rohzertifikat, ungewöhnlich lange TTL.
• Info: MX-Host ohne erwartete DANE-Unterstützung (Google Workspace), mehrere Records konsistent mit einem laufenden Schlüsselwechsel.

Passe die DNS-Zone an, warte auf die Propagierung (TTL) und starte den Checker erneut zur Bestätigung.

Anatomie eines TLSA Records

Der TLSA Record wird an einer präzisen Stelle veröffentlicht und enthält vier streng durch RFC 6698 spezifizierte Felder.

DNS-Position

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 2bb183af2e2b295b...

Der Owner Name folgt dem Muster _<port>._<protokoll>.<host>. Für eingehendes SMTP ist das stets _25._tcp.<mx-host>. Den Record am Apex der Domain statt am MX-Hostnamen zu veröffentlichen, ist der häufigste Fehler: Kein MTA findet ihn.

Die vier Felder

Die empfohlene Kombination für SMTP

3 1 1 bleibt der De-facto-Standard:

• Usage 3 (DANE-EE): Das Vertrauen ist in deinem Schlüssel verankert, unabhängig von einer Zertifizierungsstelle
• Selector 1 (SPKI): Der Record bleibt gültig, solange der öffentliche Schlüssel erhalten bleibt, auch nach einer Zertifikatserneuerung
• Matching Type 1 (SHA-256): 32 Bytes, universell unterstützt, robust genug

DNSSEC: die unverzichtbare Voraussetzung

Ohne DNSSEC wird ein TLSA Record von jedem konformen MTA ignoriert. Der Checker deckelt den Score explizit auf 30/100, sobald die DNSSEC-Kette gebrochen oder nicht vorhanden ist.

Zu prüfende Vertrauenskette

Root (.) -> TLD (.com) -> Domain (captaindns.com) -> _25._tcp.mail.captaindns.com
   DNSSEC       DNSSEC              DNSSEC                       Signiert

Jedes Glied muss signiert sein. Eine unsignierte Eltern-Zone macht alles Nachgelagerte ungültig, unabhängig von der Qualität des TLSA Records weiter unten. Der Checker läuft die Kette ab und ermittelt das fehlerhafte Glied.

Häufige DNSSEC-Fallstricke

• Domain-Zone signiert, aber nicht die MX-Host-Zone: Falls deine MX-Records auf eine Subdomain in einer separaten Zone zeigen, muss diese Zone signiert sein.
• Fehlende DS-Records beim Registrar: Eine lokal signierte Zone bleibt für externe Resolver unsichtbar, wenn der DS-Record nicht zum TLD hochgegeben wurde.
• Abgelaufene RRSIGs: DNSSEC-Signaturen haben ein Gültigkeitsfenster. Eine misslungene Erneuerung versetzt die Zone in den Bogus-Status.

Der Checker nennt dir, welcher Fall vorliegt.

Strategien für den Schlüsselwechsel

Zertifikatswechsel ohne Dienstunterbrechung ist die zentrale operative Herausforderung von DANE. Drei Strategien existieren.

Strategie 1: SPKI-Selector + Schlüsselwiederverwendung

Mit --reuse-key (Certbot) oder einem gemeinsamen --key-type rsa bleibt der öffentliche Schlüssel über Erneuerungen hinweg identisch. Der SPKI-Hash ändert sich nie, und der Record 3 1 1 <spki-hash> bleibt unbegrenzt gültig. Das ist die einfachste Strategie.

Strategie 2: DANE-TA auf die Zertifizierungsstelle

2 0 1 <sha256-des-CA-Zertifikats>

Du pinnst das Root-Zertifikat deiner CA (z. B. Let's Encrypt ISRG Root X1) statt deines eigenen Zertifikats. Vorteil: keine DNS-Aktualisierung bei Erneuerung. Nachteil: Vertrauen an die CA delegiert, also weniger streng als DANE-EE.

Strategie 3: Doppelter Record während des Übergangs

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 <aktueller-Schlüssel-Hash>
_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 <nächster-Schlüssel-Hash>

Veröffentliche den Hash des nächsten Schlüssels 7 Tage vor der Rotation (mindestens das Doppelte der maximalen TTL). Konforme MTAs akzeptieren eine Verbindung, wenn mindestens ein Record zum ausgelieferten Zertifikat passt. Nach der Rotation den alten Hash entfernen.

Der Checker erkennt das Vorhandensein mehrerer Records und kennzeichnet sie als laufenden Schlüsselwechsel statt als Fehler.

DANE und SMTP: Was bei der Zustellung passiert

1. Der sendende Server löst die MX-Records von captaindns.com auf
2. Er fragt _25._tcp.<mx> ab, um den TLSA Record zu holen
3. Er validiert die DNSSEC-Kette bis zur Root
4. Er öffnet STARTTLS auf Port 25 und holt das ausgelieferte Zertifikat
5. Er berechnet den Hash des Zertifikats gemäß dem veröffentlichten Matching Type
6. Stimmt der Hash überein: gesicherte Verbindung bestätigt
7. Andernfalls: Zustellung verweigert (grundlegender Unterschied zu opportunistischem TLS)

DANE vs. opportunistisches TLS

Häufige Diagnosen und Lösungen

Kein TLSA Record gefunden

Ursache: Die Domain hat DANE nicht konfiguriert, oder der Record ist am falschen Ort veröffentlicht.

Lösung: Erzeuge und veröffentliche einen TLSA Record unter _25._tcp.<mx-host>. Unser DANE-TLSA-Installationsleitfaden für Postfix, BIND und Let's Encrypt deckt die Schritt-für-Schritt-Bereitstellung ab.

DNSSEC fehlt oder ist defekt

Ursache: Die Zone ist nicht signiert, oder die DS-Records wurden nicht an den Registrar hochgegeben.

Lösung: Aktiviere DNSSEC bei deinem DNS-Anbieter, exportiere die DS-Records und veröffentliche sie beim Registrar. Prüfe die Propagierung mit einem dedizierten DNSSEC-Tool, bevor du diesen Checker erneut startest.

Zertifikats-Hash-Abweichung

Ursache: Das TLS-Zertifikat wurde erneuert, und der veröffentlichte Hash ist nicht mehr aktuell.

Lösung: Nutze den SPKI-Selector (1) mit --reuse-key, um den Record gegenüber Erneuerungen invariant zu machen. Andernfalls aktualisiere den Hash sofort und übernimm die Doppel-Record-Strategie für künftige Rotationen.

TLSA an falscher Stelle

Ursache: Record am Domain-Apex statt am MX-Hostnamen veröffentlicht, oder am falschen Port.

Lösung: erneut genau unter _25._tcp.<mx-host> veröffentlichen. Für einen MX mail.captaindns.com lautet das _25._tcp.mail.captaindns.com. Nichts anderes.

Microsoft 365 / Google Workspace ohne eingehendes DANE

Ursache: Diese Anbieter signieren ihre DNS-Zonen nicht, deshalb ist DANE auf der Eingangsseite nicht anwendbar.

Lösung: Setze MTA-STS statt DANE für diese Anbieter ein. MTA-STS stützt sich auf HTTPS statt DNSSEC und wird von Google Workspace und Microsoft 365 unterstützt.

DANE und MTA-STS: komplementäre Ansätze

Beide Protokolle bilden eine Verteidigung in der Tiefe, keine exklusive Wahl.

Empfehlung: beides einsetzen. DANE für Domains, die auf Postfix oder Exim gehostet sind, MTA-STS für Domains, die an Microsoft 365 oder Google Workspace delegiert sind. Maximale Abdeckung erfordert die Kombination.

Ergänzende Tools und Ressourcen

Verwandte Leitfäden

• DANE TLSA: der vollständige Leitfaden - DANE von Anfang bis Ende verstehen, von DNSSEC bis zur SMTP-Bereitstellung.
• DANE TLSA auf Postfix, BIND und Let's Encrypt - Schritt-für-Schritt-Einrichtung mit Schlüsselwechsel.
• DANE TLSA und Microsoft 365 Exchange Online - Eingehende und ausgehende DANE-Unterstützung auf Exchange Online.
• DANE TLSA: 12 Troubleshooting-Fallstudien - Diagnose und Behebung von DANE-Vorfällen.
• MTA-STS vs. DANE: detaillierter Vergleich - Eines wählen oder beide kombinieren.

Spezifikationen

• RFC 6698 - DANE TLSA (Originalspezifikation)
• RFC 7671 - Updates to DANE (operative Klarstellungen)
• RFC 7672 - SMTP Security via DANE (DANE für SMTP)