Mail-Transport & Reputation

Was ist DANE? DNS-based Authentication of Named Entities (TLSA) erklärt

DANE veröffentlicht den Fingerabdruck des Mailserver-Zertifikats per DNSSEC-gesichertem TLSA-Record. Sendende Server erzwingen damit eine verschlüsselte Verbindung zum echten Server.

So funktioniert DANE

Für jeden MX-Host gibt es einen TLSA-Record unter _25._tcp.<mx-host>. Er enthält drei Parameter und einen Hashwert. Empfohlen sind „3 1 1“ (Hash des öffentlichen Schlüssels des Serverzertifikats) oder „2 1 1“ (Hash des Schlüssels der ausstellenden Zertifizierungsstelle).

Weil der TLSA-Record per DNSSEC signiert ist, kann ihn ein Angreifer nicht fälschen. Ein sendender Server, der DANE unterstützt, stellt nur zu, wenn das präsentierte Zertifikat zum TLSA-Record passt – ohne auf öffentliche Zertifizierungsstellen angewiesen zu sein.

DANE setzt DNSSEC für die Zone des MX-Hosts voraus. Genutzt wird es u. a. von web.de, GMX, Posteo und Microsoft Exchange Online.

Beispiel

_25._tcp.mx1.example.com.  TLSA  3 1 1 8f2d6a…c41e

Der Hash ändert sich, wenn das Zertifikat mit einem neuen Schlüssel erneuert wird.

Typische Fehler

Zertifikatserneuerung mit neuem Schlüssel ohne vorher veröffentlichten neuen TLSA-Record – Mails werden dann nicht zugestellt. Abhilfe: neuen Hash vorab zusätzlich veröffentlichen oder den Schlüssel bei der Erneuerung wiederverwenden.
TLSA-Records ohne DNSSEC – sie werden dann ignoriert.
Nur einige der MX-Hosts haben TLSA-Records.

So bewertet der Domain Trust Check DANE

Kriterium „DANE/TLSA für Mail“ (Gewicht 4 von 5): MX-Hosts per DNSSEC signiert, TLSA-Records unter _25._tcp für alle MX und empfohlene Parameter (3 1 1 oder 2 1 1).

Standard: RFC 6698, RFC 7672