DANE/TLSA: die Komplettanleitung zur DNS-basierten Zertifikatauthentifizierung für E-Mail

⚡TL;DR

• DANE bindet TLS-Zertifikate über DNSSEC-signierte TLSA-DNS-Einträge an Domainnamen und eliminiert so die Abhängigkeit von Zertifizierungsstellen
• DANE-EE mit SPKI und SHA-256 (3 1 1) ist der Goldstandard zur Absicherung von SMTP
• DNSSEC ist eine zwingende Voraussetzung: ohne signierte Zone werden TLSA-Einträge ignoriert
• DANE und MTA-STS ergänzen sich: DANE prüft das Zertifikat per DNS, MTA-STS erzwingt TLS per HTTPS
• TLS-RPT (RFC 8460) ermöglicht die Überwachung von DANE-Fehlern im Produktivbetrieb und hilft, Rotationsprobleme frühzeitig zu erkennen

Wenn ein SMTP-Server eine E-Mail versendet, woher weiß er, dass der Zielserver der richtige ist? Standardmäßig weiß er es nicht. STARTTLS verschlüsselt die Verbindung opportunistisch, prüft aber weder die Identität des Servers noch die Echtheit des Zertifikats. Ein Angreifer im Netzwerk kann die Verbindung abfangen, ein gefälschtes Zertifikat vorlegen und deine Nachrichten mitlesen.

DANE (DNS-based Authentication of Named Entities) löst dieses Problem, indem die erwarteten Zertifikatsinformationen direkt im DNS veröffentlicht werden. Der sendende Server fragt den TLSA-Eintrag ab, prüft, ob das vorgelegte Zertifikat übereinstimmt, und verweigert die Verbindung bei Abweichungen. Der entscheidende Punkt: DNSSEC signiert diese Information und garantiert, dass sie nicht gefälscht wurde.

Dieser Leitfaden behandelt die Funktionsweise von DANE, den Aufbau eines TLSA-Eintrags, die empfohlenen Einsatzszenarien für E-Mail, das schrittweise Deployment, die Ergänzung durch MTA-STS und das Monitoring via TLS-RPT. Er richtet sich an E-Mail-Administratoren, Infrastruktur-Ingenieure und DevOps, die Mailserver betreiben.

Wie funktioniert DANE?

Das Problem des opportunistischen TLS

SMTP wurde ohne Verschlüsselung konzipiert. STARTTLS wurde nachträglich hinzugefügt (RFC 3207), damit Server eine TLS-Verbindung aushandeln können. Aber diese Aushandlung ist opportunistisch: Wenn der Zielserver kein TLS unterstützt, wird die Nachricht im Klartext gesendet. Schlimmer noch: Ein Angreifer kann den STARTTLS-Befehl aus der SMTP-Antwort entfernen (Downgrade-Angriff) und den Versand ohne Verschlüsselung erzwingen.

Selbst wenn TLS ausgehandelt wird, prüft der sendende Server das Zertifikat standardmäßig nicht. Er akzeptiert jedes Zertifikat, auch ein selbstsigniertes eines Angreifers. Die Verschlüsselung existiert, aber die Authentifizierung fehlt.

DANE: das Zertifikat im DNS

DANE dreht die Logik um. Anstatt einer externen Zertifizierungsstelle (CA) zu vertrauen, veröffentlicht der Domain-Inhaber im DNS den Fingerprint des Zertifikats, das sein Server vorlegen muss. Der sendende Server:

1. Löst den MX der Ziel-Domain auf
2. Sucht den TLSA-Eintrag zum MX-Server
3. Prüft die DNSSEC-Signatur der Antwort
4. Baut die TLS-Verbindung auf und vergleicht das vorgelegte Zertifikat mit dem TLSA-Fingerprint
5. Verweigert die Verbindung, wenn das Zertifikat nicht übereinstimmt

Die DNSSEC-Vertrauenskette

DANE funktioniert nur, wenn die DNS-Zone per DNSSEC signiert ist. Ohne DNSSEC könnte ein Angreifer den TLSA-Eintrag fälschen und seinen eigenen Zertifikats-Fingerprint einschleusen. Die Vertrauenskette reicht von der DNS-Root bis zum TLSA-Eintrag:

. (Root) → com. → captaindns.com. → _25._tcp.mail.captaindns.com. TLSA

Jedes Glied wird von der übergeordneten Zone signiert. Wenn ein einziges Glied bricht (unsignierte Zone, abgelaufene Signatur), schlägt die DNSSEC-Validierung fehl und der TLSA-Eintrag wird ignoriert.

Aufbau eines TLSA-Eintrags

Ein TLSA-Eintrag besteht aus vier Feldern:

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

Der Name folgt der Konvention _port._protokoll.hostname. Für einen SMTP-Server auf Port 25 ist das _25._tcp.mail.captaindns.com.

Usage (Feld 1): Was wird geprüft?

Wert	Name	Beschreibung
0	PKIX-TA	Prüft das CA-Zertifikat + die klassische CA-Kette
1	PKIX-EE	Prüft das Server-Zertifikat + die klassische CA-Kette
2	DANE-TA	Prüft das CA-Zertifikat, ohne die klassische CA-Kette zu verlangen
3	DANE-EE	Prüft das Server-Zertifikat direkt, ohne CA

Selector (Feld 2): Welcher Teil des Zertifikats?

Wert	Name	Beschreibung
0	Cert	Vollständiges Zertifikat (DER)
1	SPKI	Nur der öffentliche Schlüssel (SubjectPublicKeyInfo)

SPKI (1) wird empfohlen: Der öffentliche Schlüssel ändert sich nicht, wenn du das Zertifikat mit demselben Schlüsselpaar erneuerst. Das vereinfacht die Rotation.

Matching type (Feld 3): Datenformat

Wert	Name	Beschreibung
0	Full	Vollständige Rohdaten
1	SHA-256	SHA-256-Hash (32 Bytes, 64 Hex-Zeichen)
2	SHA-512	SHA-512-Hash (64 Bytes, 128 Hex-Zeichen)

SHA-256 (1) ist der Standard: kompakt, kollisionsresistent, überall unterstützt.

Welchen TLSA-Usage wählen?

DANE-EE (Usage 3): die empfohlene Wahl für SMTP

RFC 7672 (Abschnitt 3.1) empfiehlt DANE-EE für E-Mail. Die Kombination 3 1 1 (DANE-EE + SPKI + SHA-256) ist der Goldstandard:

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

Vorteile von DANE-EE:

• Keine Abhängigkeit von CAs: du kontrollierst das Vertrauen vollständig
• Selbstsignierte Zertifikate akzeptiert: die CA muss nicht anerkannt sein
• Vereinfachte Rotation: mit SPKI ändert sich der Hash nicht, solange du denselben Schlüssel verwendest
• Keine Kettenprüfung: nur das End-Entity-Zertifikat zählt

DANE-TA (Usage 2): Wann die CA verwenden?

DANE-TA (2 0 1 oder 2 1 1) ist nützlich, wenn du mehrere Server betreibst, die von derselben internen CA signiert sind. Anstatt einen TLSA pro Server zu veröffentlichen, veröffentlichst du den Fingerprint der CA, und alle von ihr signierten Zertifikate werden akzeptiert.

Nachteil: Wenn die CA kompromittiert wird, sind alle Server kompromittiert.

PKIX-EE und PKIX-TA (Usages 1 und 0): Sonderfälle

Diese Usages kombinieren die DANE-Prüfung mit der klassischen CA-Validierung. Sie werden für SMTP selten eingesetzt, da sie Komplexität hinzufügen, ohne einen klaren Vorteil gegenüber DANE-EE zu bieten.

DANE für E-Mail: RFC 7672

RFC 7672 passt DANE an den SMTP-Kontext an. Einige Besonderheiten:

STARTTLS und Port 25

Für E-Mail wird DANE auf Port 25 mit STARTTLS angewendet (nicht auf Port 465 mit implizitem TLS). Der sendende Server initiiert eine klassische SMTP-Verbindung, sendet EHLO, empfängt die Antwort 250-STARTTLS und handelt dann TLS aus. In diesem Moment vergleicht er das vorgelegte Zertifikat mit dem TLSA-Eintrag.

TLSA-Benennung für MX-Server

Der Name des TLSA-Eintrags wird aus dem MX-Hostname abgeleitet, nicht aus der E-Mail-Domain:

# E-Mail an user@captaindns.com
# MX von captaindns.com → mail.captaindns.com
# TLSA → _25._tcp.mail.captaindns.com

Wenn die Domain mehrere MX-Server hat, benötigt jeder MX seinen eigenen TLSA-Eintrag.

Auflösung: von der Domain zum Zertifikat

Der vollständige Ablauf für eine E-Mail an user@captaindns.com:

1. captaindns.com auflösen → MX → mail.captaindns.com (DNSSEC validieren)
2. _25._tcp.mail.captaindns.com auflösen → TLSA (DNSSEC validieren)
3. mail.captaindns.com auflösen → A/AAAA (DNSSEC validieren)
4. TCP-Verbindung → SMTP → STARTTLS → Zertifikat gegen TLSA prüfen
5. Wenn das Zertifikat übereinstimmt: zustellen. Andernfalls: ablehnen.

DANE in 6 Schritten deployen

1. DNSSEC für deine Zone aktivieren

Das ist die zwingende Voraussetzung. Kontaktiere deinen Registrar oder DNS-Hoster, um DNSSEC zu aktivieren. Prüfe, ob die Vertrauenskette vollständig ist, mit einem Tool wie dig +dnssec oder dem CaptainDNS DNSSEC-Checker.

2. TLSA-Eintrag generieren

Generiere deinen Eintrag mit einem dedizierten Tool (siehe CTA am Ende des Artikels). Stelle dein PEM-Zertifikat bereit oder lass das Tool es per STARTTLS abrufen. Wähle die Kombination 3 1 1 (DANE-EE, SPKI, SHA-256).

3. Im DNS veröffentlichen

Füge den Eintrag in deine Zone ein:

_25._tcp.mail.captaindns.com. 3600 IN TLSA 3 1 1 a0b1c2d3e4f5678901234567890abcdef0123456789abcdef0123456789abcdef

4. Konfiguration prüfen

Nach der Propagation (TTL beachten) validiere, dass alles korrekt ist: TLSA-Eintrag aufgelöst, DNSSEC gültig, Zertifikat passend. Der Inspektor am Ende des Artikels ermöglicht diese Prüfung in wenigen Sekunden.

5. TLS-RPT aktivieren

Veröffentliche einen TLS-RPT-Eintrag, um Fehlerberichte zu empfangen:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

6. Zertifikatsrotation planen

Das ist der kritische Punkt. Wenn du dein Zertifikat erneuerst:

• Mit demselben Schlüssel (Selector SPKI): Der Hash ändert sich nicht, nichts zu tun
• Mit einem neuen Schlüssel: Veröffentliche den neuen TLSA vor dem Deployment des neuen Zertifikats. Behalte beide Einträge während der Übergangszeit.

DANE und MTA-STS: Ergänzung, kein Wettbewerb

DANE und MTA-STS schützen beide vor Angriffen auf den SMTP-Transport, aber mit unterschiedlichen Mechanismen.

Was DANE kann, was MTA-STS nicht kann

• Prüft das Zertifikat per DNS: keine Abhängigkeit von CAs
• Akzeptiert selbstsignierte Zertifikate: das DNS ist maßgebend
• Resistent gegen CA-Kompromittierung: nur das DNS der Domain zählt

Was MTA-STS kann, was DANE nicht kann

• Funktioniert ohne DNSSEC: nutzt HTTPS als authentifizierten Kanal
• Einfacheres Deployment: eine Textdatei auf einem Webserver
• Testing-Modus: ermöglicht Monitoring vor der Durchsetzung

Die ideale Strategie: beides

DANE und MTA-STS gleichzeitig zu deployen deckt beide Fälle ab:

• Server, die DANE unterstützen, nutzen die TLSA-Prüfung
• Server, die nur MTA-STS unterstützen, nutzen die HTTPS-Richtlinie
• Server, die beides unterstützen, haben doppelten Schutz

DANE mit TLS-RPT überwachen

TLS-RPT (RFC 8460) ist der unverzichtbare Begleiter von DANE im Produktivbetrieb. Die täglichen JSON-Berichte enthalten DANE-spezifische Fehler:

• dane-required: Der sendende Server verlangt DANE, findet aber keinen gültigen TLSA
• tlsa-invalid: Der TLSA-Eintrag ist fehlerhaft
• dnssec-invalid: Die DNSSEC-Validierung ist fehlgeschlagen
• dane-policy-failure: Das Zertifikat stimmt nicht mit dem TLSA-Eintrag überein

Ohne TLS-RPT würdest du nicht erfahren, dass eine Zertifikatserneuerung die TLSA-Übereinstimmung gebrochen hat. Lies unseren vollständigen TLS-RPT-Leitfaden für die Einrichtung.

🎯 Empfohlener Aktionsplan

1. Prüfe dein DNSSEC: Deine Zone muss mit einer vollständigen Vertrauenskette signiert sein
2. Wähle Usage 3 1 1: DANE-EE + SPKI + SHA-256, der Standard für SMTP
3. Generiere und veröffentliche den TLSA: Nutze den Generator, veröffentliche, warte auf die Propagation
4. Validiere mit dem Inspektor: Prüfe TLSA + DNSSEC + Zertifikatsübereinstimmung
5. Aktiviere TLS-RPT: Empfange Fehlerberichte, um Probleme frühzeitig zu erkennen
6. Dokumentiere die Rotation: Prozedur zur Zertifikatserneuerung mit TLSA-Aktualisierung

---

Prüfe jetzt deine DANE-Konfiguration: Nutze unseren DANE/TLSA-Inspektor, um die DANE-Konfiguration deiner Domain in wenigen Sekunden zu analysieren. Du musst einen Eintrag erstellen? Der DANE/TLSA-Generator erzeugt einen publikationsfertigen TLSA-Eintrag.

---

FAQ

Was ist DANE und wie funktioniert es?

DANE (DNS-based Authentication of Named Entities) ist ein Internetstandard (RFC 6698), der es ermöglicht, die erwarteten TLS-Zertifikatsinformationen eines Servers im DNS zu veröffentlichen. Der sendende Server fragt den TLSA-Eintrag ab, prüft die DNSSEC-Signatur und vergleicht dann das vom Server vorgelegte Zertifikat mit dem veröffentlichten Fingerprint. Wenn das Zertifikat nicht übereinstimmt, wird die Verbindung verweigert.

Was ist der Unterschied zwischen DANE und MTA-STS?

DANE nutzt DNSSEC und TLSA-Einträge zur Authentifizierung von Zertifikaten. MTA-STS nutzt HTTPS und Zertifizierungsstellen. DANE bietet höhere Sicherheit (keine Abhängigkeit von CAs), erfordert aber DNSSEC. MTA-STS ist einfacher zu deployen. Beide Mechanismen ergänzen sich und können auf derselben Domain koexistieren.

Ist DNSSEC für DANE zwingend erforderlich?

Ja, DNSSEC ist eine zwingende Voraussetzung. Ohne signierte Zone sind TLSA-Einträge nicht vertrauenswürdig, da ein Angreifer sie fälschen könnte. RFC-7672-konforme Sendeserver ignorieren TLSA-Einträge, deren DNSSEC-Kette nicht gültig ist.

Welchen TLSA-Usage sollte man für E-Mail wählen?

RFC 7672 empfiehlt DANE-EE (Usage 3) mit SPKI (Selector 1) und SHA-256 (Matching Type 1), also die Kombination 3 1 1. Das ist der Goldstandard für SMTP: keine Abhängigkeit von CAs, vereinfachte Rotation mit SPKI und maximale Kompatibilität.

Funktioniert DANE mit Let's Encrypt?

Ja, DANE funktioniert mit Let's Encrypt. Mit DANE-EE und dem Selector SPKI (3 1 1) ändert sich der Hash nicht, solange du das Zertifikat mit demselben privaten Schlüssel erneuerst. Let's Encrypt erneuert alle 90 Tage, aber wenn du den Schlüssel beibehältst, bleibt der TLSA gültig. Wenn du den Schlüssel neu generierst, veröffentliche den neuen TLSA vor dem Deployment des Zertifikats.

Welche E-Mail-Anbieter unterstützen DANE?

Zu den wichtigsten Anbietern, die DANE im Versand (ausgehende DANE-Prüfung) unterstützen, gehören Postfix, Gmail (teilweise Prüfung) und mehrere europäische ISPs. Microsoft hat DANE-Unterstützung für Exchange Online angekündigt. Beim Empfang ist jeder Server mit DNSSEC und veröffentlichtem TLSA kompatibel. Die Verbreitung ist in Europa (Deutschland, Niederlande) stärker als in den USA.

Wie überwacht man DANE-Fehler im Produktivbetrieb?

Aktiviere TLS-RPT (RFC 8460), indem du einen DNS-Eintrag _smtp._tls mit einer Empfangsadresse veröffentlichst. Sendende Server schicken dann tägliche JSON-Berichte mit Details zu DANE-Fehlern: nicht übereinstimmendes Zertifikat, ungültiges DNSSEC, fehlender TLSA. Ohne TLS-RPT bleiben Fehler unbemerkt.

📚 Verwandte DANE/TLSA-Leitfäden

• DANE/TLSA mit Postfix, Bind und Let's Encrypt konfigurieren (demnächst)
• DANE/TLSA-Fehlerbehebung: häufige Fehler diagnostizieren und beheben (demnächst)
• DANE für Exchange Server oder Microsoft 365 deployen (demnächst)

Quellen

• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
• RFC 8460 - SMTP TLS Reporting
• Microsoft - SMTP DNS-Based Authentication of Named Entities (DANE)